What is your practice with GrampID?

Help
1

Genealogical objects stored in the database are internally identified by their “handle” which is assigned when the object is created and never changes whatever the modifications to the object.

For obvious reasons of DB reliability and integrity, this “handle” is invisible to users.

Primary objects (not all objects, only those which are listed in the left pane of the main window) have a GrampsID in the default form of I1234 for persons (Individual 1234), F5678 for families (Family 5678), etc. This GrampsID can be modified at will. There is even a tool to bulk renumber the objects and reclaim “holes” in the numbering.

The fact that a GrampID may change prevents them from being used in notes to refer permanently to another object.

The only use I can see for them is a disambiguation role to uniquely identify homonyms (person, family, place, …). They are also involved in labelling GEDCOM data blocks, but this is external to Gramps. Apart from this, I see no safe usage for them.

May it be that in the very first versions of Gramps such GrampsIDs were in fact the true identity of the objects? Later this role was secured into the “handle”?

Have you an effective use of GrampsID? Which one?

What would be the consequences of dropping them?

2

The GetGOV addon creates a Gramps ID that is the GOV id (from the GOV gazetteer) rather than using the default Gramps pattern. This addon will import (and create if needed) the specified place and all parent places with attributes. This allows the addon to not duplicate an upload of a place (assuming the ID is not reset - this is documented in the wiki page) . This was more efficient than using the GOV id as an attribute of a Place and scanning the complete place list before import/creating a new place.

1 Like
3

As you mentioned, they’re used in GEDCOM exports. I don’t know if the handles could be used there instead.

You’re probably aware that you can go ahead and remove them from most of the views in Gramps, in the View - Configure - Columns dialog.

4

You can see an example here:

or those:

I really wouldn’t want that, I guess I’d stick with the current version of Gramps at least for a while

5

Good point. You use this “visible-by-default” field for a valuable piece of information. Logically, it is an attribute but this avoids the pain of creating one through a dialog and numerous clicks.

Personally, I never store Sosa or other such numbering because it is not “absolute”. It depends on the root. Since I use my data to generate multiple ascendant/descendant trees, this would require to recompute the full labelling each time.

Side remark: how do you handle lateral branches? Say your first cousin would be 4AB? And what about non-connected people?

Could you explain the scheme in Families?

In Notes, the ID seems to take part of its encoding from note type. I guess the media ID is a shortened form of repository+description.

6

Yes. My only first cousin, named Francis, is from my mother’s sister named Andrée. Its ID is 6aF.

They continue to have the standard Innnnn generated GrampsID

F for family
FGN is the trigram for Francois VangoN
Hn for hypothesis #n

When I’ll find what is the true couple I’ll merge then to keep only one family and I’ll delete the ID to let Gramps to generate a standard one.

…

NRef stand for Note of Reference, PLX is my trigram to find them easily then it’s just followed by a growing number.

7

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