About Gramps usage and organization to store and research (2)

After a few spoiled my question and someone else closed it manually (he did well), so here’s the topic again. I hope it will be quieter this time.

I’m sorry for those who have answered my questions in the first post.

Not totaly related to the “Do i need more than one tree for this?” thread (but a little bit anyway) so I open this new one, and regardless of reports, I think gramps needs us to define our usage of it, our workflows, take how to notes of our own usage, define what tags are used for, define how to use user defined attributes or events or… Gramps is a set of tools everyone can use in its own way but to be powerful using it in an advanced manner we have to standardize things -researches attributes, tags, filters, …- and take notes, describe, what we want and what we have to do to get them working that way.

I think too there are at least three data flows to record and one set of tools to define to work on with them:
Data flows:

  • Genealogical data : Gramps is made for, we just have to store these data into all gramps predefined objects
  • Informations about genealogical data: stored into standard gramps objects or into user defined objects based on standard ones (non standard attribute or event name/type, non standard family relationship type, etc)
  • Hypotheses informations : fully stored into user defined objects (research notes, research attributes and tags, …) may be with something special to recognize them (some prefix like RESEARCH or something like that --> needs naming conventions)

Work flow:

  • tools to make it possible to match/to work with the previous data ; fully user defined using previous objects, standard ones or user defined ones. Uses a lot of filters which needs to be standardized too (naming conventions…)

I tend to think that tags are to be used to follows worflows (birth found/to be searched, …) and data container quality (name normalization/convention, etc), attributes to contribute to them and why not some special user defined events we can use to join them to multiple other objects (persons, …) to store researches in them, more than in a simple note. Then we can apply some filters to follow what we have to do, to correct something or to work on our genealogy.
There is some lacks too. Filters don’t fully permit to research everything we need (i.e attributes into top part of events or medias, media filters can’t search using persons filters, etc.)

I don’t know if I need or not two databases, one to store researches, another one to publish (for the moment I’ve made the choice to have only one database and to publish everything, even researches state, hypotheses, notes…)

I’ve to use external tools to manage more efficiently my researches, so I need to include them in my workflow description so that the information that I need or that I have found passes from one tool to another (data flow)

I’m not fully organized that way but I think it is the way to go for me. I’m doing all of this description work then I apply it to my objects in Gramps.

And you, what do you think about that? What is your own organization to use Gramps? Do you have to take notes of it? Does something miss you, reports as this post began or filters or something else (like working with external tools) to make Gramps a fully genealogical researches tool?


Are there any open feature requests for that? I would like to monitor them, and maybe add to them.

How/where do you see open feature requests?


When I started using Gramps, I created a “style guide” which I am continually updating. It is not a formal document, just my scribbled notes about how I want to organize places, how “deep” vs. “wide” I want my source/citation references to be, what I want to store in attributes and notes, how I want to use tags, etc.

I try something more formal using Notion page and databases. I began it some days ago but, yes, I should have done it earlier.

I will maintain it because I’m sure my Gramps use will probably change again in the future as I’ve changed my sources and citations sometimes, filters often, etc.

Filters really needs to have a special focus because it is really to be loose when you have a lot of filters, for projects, usual usages, etc

Tags and attributes i use for specific research too.

Bugs and feature requests are added here:

1 Like

Is there a specific keyword to filter bug tracker only on feature requests?

This is why I over and over again have asked for export/import in interchangeable export formats, so it would be easier to have a good workflow with external tools, also for none-developers that use Gramps, and talked about all the benefits for Gramps supporting this formats.

I have talked about this for more than a year now, but it seems that only 3 other users here have ever supported it.

Same about research and analyzing tools, like an “everything” network graph, that shows connection multiple hops through Event’s, Places and Sources, and where you can define what you want to use as Nodes and Edges, i.e.:

  • Would you like to use Citations as Edges or Nodes
  • What objects types would you like to add as Nodes
  • Do you want to calculate Internal links as Edges and add the Notes as Nodes.

or a configurable Timeline for multiple subjects and objects, with dependencies lines (connector between the different Events) and color coding for each person/object defined as “in focus” with a configurable time span.

With this features added, I will see Gramps as a near perfect research tool:

  • Import/Export to JSON-LD and Graphml. where you define what you want to use as Edges.
  • Main Event and Sub-Event
  • quadruples for Attributes on all subjects/objects
  • Events on Places
  • Citations and Sources on all data
  • Support for Bibliography tools (CiteProc) i.e. Zotero with i.e. pyzotero, betterbibtex, jabref, mendeley
  • Backup and reuse of user settings including settings for gramplets and Types.
  • One Graph View with similar data as the “deep connection” - gramplet, but that also shows Places, Events, Sources and Repositories as Nodes, and where Edges can be user defined.
  • A DNA tool, with support for i.e. the python library lineage that already have most of the features needed, and that are actively developed.
  • Change from Blobs to json objects or “normal” tables for storing objects, including serialized data.
  • Implement the mongodb backend and update the drivers.
  • Add support for a graph database or linked data database as a backend.