Design inconsistencies

Continuing with my reverse engineering of Gramps, I have sketched the relationships between “genealogical objects”, namely what is desgnated as “array” in the JSON schemas. My drawings do not include “scalar” fields which are usually “integer” or “string”.

Here are the two main “objects”, Person and Family:

At left, there are the specifics of the object. At right, we find the annotation tools, attributes, citations, media, notes and tags. These annotation tools are offered as a way to explain, prove and illustrate the facts recorded in the specifics. Conceptually, they are so general that they come “naturally” as complement to any object.

This is the case for the next important object, Event:

However, when you consider Place objects, there is no provision for attributes (boxes and arrows shown in dark gold are missing components – drawings were created by copy/paste of a generic object model). I don’t see why there couldn’t be attributes on a place.

Similarly, no event can be attached to a place. Presently, I must use a note which is semantically not the same and is perhaps less flexible. This is a real nuisance when you try to follow a village history in addition to its inhabitants (events such as fire, flooding, drought, battle, plague, … are not related to people in particular but to the place itself). Is this a shortsighting?

Similarly a Repository has no attribute. I understand it has no Media (though we could record a photo of the building or location) as a repository is a store for media.

Also Source has no Citation because it is a “descendant” of a citation. But why was a specific SrcAttribute class ever created? It has the exact same definition as Attribute. The only consequence is to segregate attributes into distinct name spaces. I don’t think this is necessary.

When it comes to Location and Address, they are nearly identical (see this question). Address can be annotated but many tools are not allowed:

I don’t see the reason.

Regarding the existence of Location, I assume it was kept from earlier releases before the present nesting feature of Places (Enclosed by). Documentation does not mention locations nor how to use them. It is likely it can be dropped safely.

Would a unified approach to object annotation bring a substantial improvement to Gramps usage? Note it is quite easy to implement it by modifying the JSON schemas and adating the serialize() and unserialize() methods.

I think I read somewhere that is part of the 5.2 enhancements?

But you can create an Event with a Place, and just not add the Event to any People. It would be considered an “unused object” but would be there in the database, potentially usable by some new code. I understand that’s not the same as what you’re asking for, just mentioning it as a possible workaround for your own queries.

Does it have something to do with the fact that, although Sources and Citations can have Attributes, those Attributes can’t have Citations (unlike other Attributes which can)? I guess that is to prevent circular references?

I thought there was also some discussion of that in the 5.2 enhancements but not sure of the outcome.

1 Like

I neglected this fact. But, a Source has Media’s and a MediaRef can include a Citation. Therefore the potential circular reference you mention may occur through the media. Here is the drawing I didn’t attach in the question (for volume purpose):

@pgerlier A note of thanks for the work you’ve done documenting the classes and sharing that here.

@GeorgeWilmes mentioned changes that are on the roadmap for Gramps 5.2, and indeed, there are planned changes to the Places objects which might interest you. Sharing GEPS 045: Place Model Enhancements, associated issue in Mantis: 0011617, and the GitHub PR#809 in case you haven’t seen them yet.

1 Like

@codefarmer Thanks for the info. I’m presently focusing on a true SQL schema for Gramps data. This is a lot of work because the internal design didn’t change since the beginning: BSDDB concept simulated under SQLite. And also I think there is not enough separation between the three traditional layers: UI, DB storage and “specific purpose” (i.e. genealogical processing). They are too much interconnected and this complicates demangling the Python objects.

Don’t take my drawings above as the Truth because I discovered yesterday I misinterpreted code and this changes the relations everywhere an LdsOrg is referenced. There are also minor changes in Media.

I’ll have a look at the enhancements as soon as I can record something in the SQL database.

I think diagrams like these would be really usefull for people that are new to working/looking at the gramps code, and dont have experience with anything similar. (If that exist, I dont know, I am not a coder currently).

Events for places has been asked for by me and others since version 5 was released, there are multiple threads in this forum about it.

Same comes to “Main and SUB-Events”.

I was told that I could fork Gramps and do it myself and not be so demanding when I asked if it was possible to implement those two features.


Maybe you can look at the mongodb api, as far as I have looked at the data in the mongodb database I have, it looks like at least most of the objects are “de-serialized” and stored as Json objects.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.