Methods of reading and writing Genealogical data in Gramps

Help
1

There are many ways to reading and write data in Gramps. But it can be hard to find each one. The thought occurred that a cross-reference to the various elements would be useful.

It could start with the Gramps Data Model as a checklist and have that link to to a table with rows of data elements and columns of links to docs for that method… with create, read/get, and write/set.

How many columns should be included?

Here are the methods I was thinking:

It could probably include GEDCOM in the future but compiling that list is already WAY too much work.

My particular interest is the CSV. The thought being that perhaps an Tutorial example of could be written for adding an object to the CSV parser. (Currently, the CSV can write a Source but cannot write a Citation or CitationID. That seems like an obvious expansion since EVERY piece of data needs a specific Citation. So EVERY record imported by CSV has to be touched again.)

1 Like
2

Do you have a use case for this? I don’t see much use in importing citations, except when referenced from other pieces of data, in which case the citation columns may be included with that.

3

A use case? Certainly. Entry of data from an Obituary or biography.

You would want to create a Source (the newspaper or book of biographies) and Citation (the article with a date and page number), then every entry thereafter uses that citation. The citation creation is probably best done via the interface. Then you have an ID for reuse.

We can use an obit transcribed in another Posting:

Let us assume that I had none of these people in the Tree yet, or that the IDs were easily found,

Entering just the surviving children and siblings plus their Residence Events at this date is tedious: 8 people dialogs, 8 place dialogs, 6 place dialogs, and the citation dragged from the clipboard at each step. Easily 40 minutes of error-prone work.

This task is quickly accomplished in less than 5 minutes with the recently (Tab delimiters) enhanced Text Importer in concert with a spreadsheet. But since there is no Citation ability in the CSV, You have to go back to open each Event or Person and drag a Citation into sources for each.

4

Ah, I see. We’re thinking in opposite directions again.

My interest is not in bulk import of CITATIONS.

It is in reuse of the same citation when transcribing a source that is dense with family information.

If Gramps had an option to autofill repeating info, it would be just as good. But enabling Citations wouldn’t have to be nearly so intelligent nor be an interface design challenge.

The Data Entry gramplet comes close… but is does Sources instead of Citations too. And it is limited to Birth & Death Events. The CSV also has Burial, baptism, occupation, marriage & Residence Events.

Can’t think of a single case where I’d add a Source to an Event instead of adding a Citation.

5

I don’t try that idea but I think the Form gramplet could probably do this easily. You will have only one citation but all people referenced by it will share the same event.

2 Likes
6

It doesn’t seem like that would work.

Although all the people have a Residence Event and it is on the same date with the same Citation, they are in different Places (even those enclosed in the same administrative division). So it cannot be a shared Residence event (unless specifically stated to be a shared Residence … such as “at home”).

1 Like
7

These personal informations like residence could be stored in personal attributes of that event like census does. I don’t see any issue here.

Event could be an Orbituary event (Type: Orbituary, Description: Orbituary of xxx McCullough, Date: September 5, 1917, Place: New Castle, Pennsylvania). All persons cited could share that event, their personal information like residence stored in attributes. Each one having its own role (deceased spouse, son/daughter of deceased, …)

2 Likes
8

That’s not logical. There’s no justification for adding custom Attributes for standard data that is in a Event like Residence.

Being an Attribute would just make that data harder to find. It would be ignored in reports too.

An obituary isnt an Event… it is a secondary Source to be cited. (Or an Authored Narrative, by Evidence Explained terms.) A funeral is an Event… but the Obituary doesn’t say they attended.

1 Like
9

You’re right, and that is one of the reasons why I avoid the forms gramplet like the plague. Attributes can be used as a backdoor to store all sorts of external ID’s, but they should not be used for anything with genealogical relevance, which is one of the reasons why I’m very much against attributes with dates. The thing is, that they will only lead to more pollution in our data model, which has some messy sides already. Keep it clean!

An obituary is a source, with meta data, describing one or two events (death and burial), and people, who are mentioned, but that does not always mean that they were there, except for the deceased. And for some associated people you may not really know how they relate to the deceased, or to each other, but as far as I’m concerned, I do want to import them as persons, with associated facts, where available, not attributes.

I don’t really like to use the CSV format for this, largely because of the narrative, but I do see your point, about the clumsiness of entering all this by hand.

I know at least one (Dutch) site that offers GEDCOM exports of such things to paying subscribers, and although these are quite primitive, it is a a start. XML or JSON woould probably be a better format, and I deliberately don’t say Gramps XML here, becauss I really like to keep it simple. GEDCOM is not a good choice, because it doesn’t have room for a citation ID, which is just the thing that you want all persons to be linked to, regardless of their relation to the deceased.

If I’m allowed to choose, I opt for a text file with a minimal amount of tags, so that an importer can recognize the meta data, which can be stored in source and citation objects, the source text (narrative) and the persons and associated facts, like residence, etc.

10

There is the option to have ChatGPT parse the transcription into a twig in GEDCOM format and import that. (I haven’t tried to have it compose a Gramps XML yet. It would probably make sense to export the immediate family as a .gramps file for it to use as reference.)

All that would necessary is to do is compose detailed instructions of how to cite and what event types to extract. The instructions can be recycled for future parsings of obits.

In this particular obit, it would be interesting to use Merge if the people already existed in the tree… because each person has alternative names to their birth name. And merge would preserve the aka and married name forms.

11

Attributes are intended to store genealogical information. This is why they allow citations to be attached. Evidence stored in attributes can support a conclusion. For example, it is common for census returns to give a place of birth that is more broad than on a birth certificate. In this case it is useful to have a single birth event with the place of birth being a conclusion based on all the evidence. However, it is still useful to store the other place of birth information in a structure manner linked to individual sources.

Although attributes can be used to store external IDs, this is not their purpose. We intend to implement the Gedcom identifier structure with its UID and EXID tags to store IDs.

Forms are one method of source driven data entry. All the relevant information from a single source can be entered at once. This also means that events and attributes can automatically have the correct citation attached.

For free format text, such as an obituary, forms are probably not the best approach. Applying markup to a transcription is an approach that has been suggested in the past.

12

For me, forms have always been too tedious, so I really like the idea of having a simple mark-up.

13

Nope. Does not work. The learning is not retained for enough steps within a session. So a correction painfully taught to an all-too-literal fool recur as you work with it on the next refinement. Even having the problem restated for refinement does not work… it ignores parameters unpredictably.

14

I knew that, because I tried that myself too. And since CSV is not the best format when narratives are involved, I still prefer some sort of free text with tags, name value pairs, or simple mark-up.

1 Like
15

But I went off-track again into specific example. This was to be a generic.

The initial post is about a x-ref of methods to touch specific objects of the Gramps database

So you might bring up the Data Model, select the Python Source version & it switches to a diagram where the block header for the Person object linked to the the Person object source then switch to the Python Sphinx diagram and the same header link points to the gramps.gen.lib.person or SimpleAccess.person doc, then on the GUI the diagram links to the Edit Person docs. Then the XML and you go to Person object section of those (DTD? Schema? Sample file?) documents. Then maybe a QuickReport, Report or Gramplet plugin diagram that show samples of interacting the Person in that way.

So you can flip to GUI and confirm that this is the kind of object data you want to touch, then discover how to touch it directly in an alternate tool.

image
image1920×3765 491 KB

https://www.gramps-project.org/wiki/images/a/ae/GrampsDataModel.svg

16

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