I have completed my diagrams about the classes representing genealogical data. They are attached to this post for comments and improvement.
Primary objects:
Secondary Objects:
Note: from reading the code, there is no reason why Attribute and AttributeRoot are distinct.
Secondary Objects (references):
Gramps types:
If you find this kind of diagram useful, I can send them for publication in the wiki.
The Address & Researcher connection to the LocationBase feels wrong. Like Internet, LDS & Associations, these record elements seem to be more idiosyncratic than implied by the graphs.
Not that much. The inheritance is in the class creation. On a âlogicalâ point of view, both the Researcher and Address dialogs request a âphysicalâ address which is ultimately described in the LocationBase class.
These diagrams show what is under the hood. What a user sees through the UI (net yet analysed) can be radically changed by programmerâs intent. I.e. a UI dialog may involve several core classes.
I think these would be nice to have on the wiki; especially for new contributors. Nice job!
I do wonder: are these made manually or are they generated? Because if they are made manually, I would also clearly indicate on the wiki from which commit they are made, so it can be clear if they are outdated or not.
Diagrams are made manually. I move the boxes until the connector crossings are minimised. I could probably have used GraphViz but the preparation phase would have been much more user-unfriendly and I am not sure GraphViz would have laid out the diagrams as cleanly. Note also Iâve used both straight and curved connectors while GraphViz would have used only one brand.
All were done in LibreOffice Draw.
I have cloned the GitHub repo but I work on the 5.1.4 release. Nevertheless, you are right, Iâll add a caption with the reference.
For information, the SVG diagram on wiki, was a quick overview, by using âpyreverseâ (from pylint package).
$ pyreverse -A -S /home/blabla/gramps/tree/master/gramps/gen/lib/*.py -o > jpeg
When looking for the Association data structure, its connection to the Person object seems to be missing from the Gramps Data Model wiki diagram by @Nick-Hall .
The GEPS 13 model overview diagram for the WebApp by DSBlank has has its resolution degraded⌠so it is not actually readable enough to check.
Does the Association appear in any of these newer model diagrams?
Association information is stored in the PersonRef secondary object stored in the person_ref_list in the Person object. The PersonRef in the first person points to the second, so to setup a two way association you have to add a PersonRef to the second person pointing back to the first.
Just a tip, not a comment on the diagrams themself:
If you use the application âDiagrams.netâ (there is a desktop version for any of the desktop OS), you can actually save the diagram as a CSV file and just add or edit the diagram in CSV and then import it and generate new âmapsâ.
It has a similar syntax as Graphviz just in CSV.
It can save the diagrams in both jpg and svg, and also has functions for advanced interactive graphs.
It also have a plugin for VSCode and VSCodium if that is of interest.
PS. I know Draw in LibreOffice/OpenOffice is a really good diagram/drawing software, so this is just a tip for a software that has much of the same feature as Microsoft Visio.
Requested a starting point for a workflow document to update the existing style of Gramps Data Model wiki page as the model evolves.
As an expert in pyreverse and the Gramps data model, Perplexity AI outlined the workflow to create the final diagram starting from the pyreverse command. By using SVG output, we can take advantage of the vector format for easier manual editing and refinement of the diagram.
The command you provided is a good starting point:
pyreverse -A -S $HOME/gramps/tree/master/gramps/gen/lib/*.py -o jpeg
However, letâs modify it to use SVG output and include additional useful flags:
pyreverse -ASmy -o svg $HOME/gramps/tree/master/gramps/gen/lib/*.py
This updated command uses the following flags:
-A: Generates all ancestors and associated classes for the analyzed classes-S: Shows only the classes in the specified packages-m: Adds module names to the generated classes-y: Creates a more compact layout-o svg: Specifies SVG as the output formatGenerate Initial Diagram
Run the modified pyreverse command to create an SVG diagram.
pyreverse -ASmy -o svg $HOME/gramps/tree/master/gramps/gen/lib/*.py
Open in Vector Graphics Editor
Use a vector graphics editor like Inkscape or Adobe Illustrator to open the generated SVG file.
Clean Up and Organize
Remove unnecessary classes and reorganize the layout for clarity.
Apply Color Coding
Use the vector editor to color-code primary objects (blue) and secondary objects (black).
Group Related Objects
Create groups for related objects, using dotted lines to enclose hierarchies stored in database tables.
Add Annotations
Insert text boxes or labels to provide additional explanations where needed.
Verify Against Documentation
Cross-check the diagram with the latest Gramps documentation to ensure accuracy.
Refine Layout
Adjust positions, sizes, and connections for optimal readability.
Export Final Versions
Save the final diagram in both SVG and PNG formats for different use cases.
By following this workflow and leveraging the SVG format, you can create a comprehensive and accurate representation of the Gramps data model, starting from the pyreverse command and refining it using vector graphics editing tools for optimal clarity and detail.
I have improved the diagrams shown in the first post because they could not be used to study easily the data model (too many arrows crossed).
As an example, here is the Person ârecordâ:
What the color codes in this diagram means?
These colours are kind of personal annotations from code reading.
This was an attempt to classify the various Gramps objects into âspecificâ objects and âgenericâ annotation objects which are drawn at right.
This lead me to discover that Graps record definition is not as much generalised as it could be. Attributes, media, notes, tags, URLs and citations could be attached to any record (of course, taking care not to create loops such as attaching a citation to a citation or a media to a media, âŚ).
I think this kind of generalisation would answer many questions.
This also suggested that events could be added to Place to attach historical facts not related to individuals. This would certainly be better than notes.
These additions need no big code changes. They are quite easy to include in the JSON record description and only a few high-level modifications are necessary in the dialog managers to handle the extra tabs.
Thank you for all your answer but you canât know how much you please me by talking about these events attached to places. I really expect them in Gramps, and I know that I am not the only one waiting for this functionality, for example I know genealogists working on Basque families, whose surname is that of the house that is given to the eldest on the death of his father, who need these events. I hope we will see them in V6.0
There are not going to be any schema changes in v6.0.
There are 9 primary objects: Person, Family, Event, Place, Repository, Source, Citation, Media , Note.
The Tag object is a table object. This is closely related to a primary object, but doesnât contain and Gramps ID and is not intended to store genealogical information.
All other objects are secondary objects.
Classes with the âBaseâ suffix are used to extend the functionality of an object in an easy and consistent manner. For example, PrivacyBase adds the âprivateâ field and associated methods; and NoteBase is specified in objects that can contain notes.
Reference objects inherit from RefBase and are used to link to another object where the link itself contains fields and/or objects. Some objects just contain a list of handles that link to secondary objects.
Granted, but Gramps is FOSS. This allows anybody to experiment with the code. All needed tools are already there. My only problem is I am not versed in GTK+ subtleties.
Since this is personal exploration, I donât mind being incompatible with future releases (I give a different schema version to my DBs, noting that my âproductionâ tree is strictly conformant as it is handled by an âofficial Grampsâ). This can however be handled easily because my code is a fork of main line under Git. All I have to do is to rebase on a specific commit and manage potential conflicts.
Is this evolution of events associated to places in the roadmap for a future version v6.n?
Is this evolution of events associated to places in the roadmap for a future version v6.n?
I would certainly consider such an enhancement for v6.1.
