To document the source of each fact about a person or event in my tree, when I cite a source I include the relevant text from that source. If the text is simple and short (such as a one-line city directory entry) I quote it verbatim; if the text is longer I summarize the facts from the source that are relevant to the person or event, while otherwise staying close to the source text (not interpreting, only reproducing). That enables easy review of how I know a fact without having to consult the actual source.

The best place I’ve found in Gramps to put this source text is a citation’s volume/page field. (I use sources in an idiosyncratic way, a side effect of which is that I never enter actual volumes and pages, so I have no other use for that field.) That works fairly well but looks bad, and seems likely to confuse readers of GEDCOM generated from my Gramps tree.

I considered using an attribute or a note, but both are more cumbersome to enter and are not displayed as nicely as an actual citation field, and an attribute would not be exported to GEDCOM.

The GEDCOM 5.5.1 draft’s SOURCE_CITATION has a DATA.TEXT field, type TEXT_FROM_SOURCE, exactly what I need. Does it seem like a good enhancement to add a source-text field to Gramps’ notion of a citation?

SOURCE has a similar field, so we might consider adding that as well for consistency, though I don’t have as strong a need for it myself.

Be welcome Dave !

I thought about several techniques without getting complete satisfaction - not sure which would give me complete satisfaction ! But, probably not just an extra field; maybe by adding a Reference between the Citation and the object in which it is used, in which some of these concepts could find their place.

Here I use a pipe sign to separate the quote (the page if you want) from what interests me inside to source a given event:

There, I made the replication of a citation with Supertool in order to show if it is Direct or Indirect, Primary or Secondary information, and the 3rd character: Derivated or Original

A few days ago I tried (I shouldn’t have taken as a first source a letter that gives too much information) to bring out triplets (Type of data: [Element of information, Allegation], Event domain: [Death, Military, Family, …], Information taken from source) to associate them to the citation to event attributes, conclusive or not. Each triple is in a note of its own, I found this to be easier than making attributes to the citation:

I haven’t experimented enough with the latter yet to know whether or not it’s an interesting method, but I can already tell that it takes time… And I think the gedcom once released with all these notes is going to be horrible !

The first is not bad but does not have enough granularity, the second has some other purpose, and the third remains to be seen. The first seems understandable by those who read it.

Maybe a mix of the 3 would be more satisfying?? In any case, I’m still looking for a method that does what I want, in particular to prove - or not - things, and then to be able through filters to know whether or not I have things left to do. to verify this or that event (if I’m only hearsay allegations, it’s not the same as a contract signed at a notary concerning someone’s property for example…)

I upload a lot to WikiTree so this method is customized for that.
In the Page/Vol I put the specific info regarding the citation like the page/vol, film number or folio, etc. I put a comma and the URL. Sometimes just the source URL. This comes through as a block citation in WT.
I copy the transcribed text of the citation to a citation note. This allows me to review it later if a question comes up. In WikiTree, the note comes through as a note. I very rarely save copies of the images since I have saved the URL to the image.


I know that it is too early for final docs… but…
Are there any design docs, Discourse threads, eMail threads that might pertain to this discussion and the new 5.2 Citation plugin type? Something that gives a rough idea of what it could do?

Would a developer be able to construct of a Citation model that store data the way they describe? Or can there be one that simply has an override text when the user could enter a hand-composed citation? (Maybe with Footnote, ibid, endnote and bibliography forms.)

e.g., the user has a single edge-case source being cited. They want to use the format described in Evidence Explained by Elizabeth Shown Mills and hand-compose the citation.

There is no documentation yet.

Citation formatter plugins allow citations to be formatted using any data the developer chooses and possibly using external tools. There is only one plugin of this type that is publicly available which formats citations in exactly the same way they were formatted in v5.1.


In our current data model, and GEDCON import, data blocks are ignored, and the text referenced by @DaveSchweisguth is part of the data block, that can be found in sources and citations. The contents of these data blocks can be found in GEDCOM import notes, and these blocks are quite rare. I found these GEDCOM import notes when two fellow Dutchmen complained about imports from GensDataPro. I have never found these data blocks in GEDCOM files exported by the big American programs.

The definitions of these data blocks are a bit messy. For sources they are:

+1 DATA {0:1}
+3 DATE <DATE_PERIOD> {0:1} p.46
+2 <<NOTE_STRUCTURE>> {0:M} p.3

And for citations:

+1 DATA {0:1}

And as you can see, in the citation, the text is called text, and in the source it’s a note structure. And in the citation, they can be accompanied by a date, and in the source by a date and a place, embedded in an event block. And all these extra’s don’t exist in our source and citation objects.

If you look further, in GEDCOM 5.5.1, you will notice that the source has a text and a note structure, where the text is supposed to be the text from the source, and the note is just that, a note, whatever that may be. Is that a research note? The standard allows 1 text, and multiple notes. And in the citation, you can have multiple notes, but no text. And here I mean at the top level, not inside the data block. And in the data block of the citation, you can multiple texts, where you can have only one at the top level of the source, but that one allows for multiple notes, to compensate …

Texts and notes outside the data blocks are imported by Gramps, as notes, probably with different types, but notes anyway. And that’s good, because both can have multiple lines, so they don’t fit well in a field, entry wise.

In theory part of the fields that exist in the data block can be stored in attributes, and one can say that the Forms Gramplet does just that, and more, because attributes can have sources. Data blocks are so rare however, that I don’t see much reason to import those, except for the ones found in exports from GensDataPro.

At the same time, I do understand the idea that it’s quite cumbersome that you need to open a new window to enter or view a source text (or note). But at the same time, if you follow the standard, one text field is not enough for a citation, because that can have multiple notes, and multiple texts too, if we’d support data.

Long story short: If we ignore data blocks, because they’re rare, I think that we can still think about ways to make source/citation data entry a bit easier.

PLegoux, your third method is closest in spirit to what I do. I’m not diligent enough to distinguish “element of information” and “allegation”, or perhaps I’m too skeptical of all documents. But the information taken from the source is exactly my case.

I don’t explicitly track the relation of a citation to person or event attributes since it is often obvious (if a source says that a person was born on a date it is clear what attribute is relevant), but you’re making me think I could be more systematic about doing so when it is not (for example as when the presence of a person at an event constrains their birth, death, etc. dates).

@Davesellers I might indeed have to move my transcribed text from Page/Volume to the citation notes for export. Page/Volume is so much more convenient within Gramps that I’ll probably write a tool to create citation notes for export if I need them.

@ennoborg When I posted I thought that the presence of data blocks in the standard might be a strong argument for supporting them, so thanks for clarifying that Gramps is more parsimonious than that. I might reraise the issue if I found that something that I want to export to supports data blocks. Overall this discussion has made it clear to me that I should prototype export to the services that I care about before I finalize how I’m using Gramps.

And I just found out that I need to make a correction, because Gramps does support DATA.DATE and DATA.TEXT in citations, and I made a mistake in my previous scan for the DATA tag in GEDCOM files exported by Gramps. We actually need to do that, because without that, we wouldn’t be able to export the citation date, and I find it a bit odd that the citation page sits outside the data block.

What’s left is that we don’t support the the DATA block in source records, where it is indeed quite rare. I just ran another check with a file exported from the Dutch GensDataPro program, and the error log clearly showed that the whole SOUR.DATA block was ignored.

This GDP GEDCOM file was the 1st one where I found that SOUR.DATA block, and it has more facilities that we don’t support in Gramps, like source templates, which are also exported as a part of the SOUR.DATA block.

As said before, I do support your wish to make the text field more accessible.

And if you find another program that makes heavy use of the SOUR.DATA block, please let us know.

@ennoborg what does “support” mean here? If citation data blocks are imported, where do they appear in Gramps? And are they supported in the UI and/or in GEDCOM export? Thanks!

Support means that the data will be imported to the proper fields, so DATA.DATE will show up in the citation date field, and DATA.TEXT will be imported as a note of type source text, attached to the citation. And if the importer finds more texts, they will also be attached as such notes.

The net result is that no data is lost, and you don’t have to look for it in GEDCOM import notes either, but to actually see the text, or texts, you will need more mouse clicks than you may like.

1 Like

@ennoborg also, just to spell it out, importing GEDCOM with a data block with text into Gramps and and exporting it will change the data block text to a GEDCOM note. As I said elsewhere in this discussion I’ll have to look at how other software I use imports data blocks and notes, and how it handles my abuse of “Volume/Page”.

Well, no. Although texts and notes are the same, technically speaking, in the sense that both can have multiple lines, and are stored as notes in Gramps, they are exported properly, so the text that was imported as a source text, in the citation, will be exported as such too.

Here’s an example for a late uncle, for whom the naturalization source can be found on FamilySearch:

2 DATE 23 SEP 1963
2 PLAC U.S. District Court, Boston, Suffolk, Massachusetts Bay Colony, British Colonial America
2 SOUR @S5788@
3 PAGE Herman Borgsteede, 1963
4 TEXT Herman Borgsteede, “Massachusetts, Naturalization Index, 1906-1966”

What you see here is a direct quote from a GEDCOM export that I did earlier today. And in that same file, I also see citation (research) notes exported as NOTE.

What is that other software that you use? I use Ancestral Quest and RootsMagic for FamilySearch.

1 Like

You should check your enclosed by dates. By 1963, Massachusetts was no longer a British colony.

Ah! I just found the “Source text” note type. (I had been using Citation.) So GEDCOM SOURCE_CITATION TEXT is fully supported in Gramps, but as a “Source citation” note rather than as a field of Citation.

I export to Ancestry and FamilySearch.

You got that right, and you can say that part of the GEDCOM citation structure is flattened by Gramps, because it shows (and stores) the citation date and page as direct subordinates of the citation object, and also links all notes directly to that, regardless of their type, and there is no data object in our model. The GEDCOM importer uses it to find the citation date and text, and the exporter inserts it to make sure that citations comply to the standard.

It would be difficult to turn the text into a field, because there can be multiple instances of it, and it is not a field like the other ones, because it can have an unlimited number of lines, exactly like the notes.

I just checked how the source that I mentioned looks on Ancestry, and in that the citation text is shown in the transcript field, which is a multi line control on-line.

Do you ever import new finds from Ancestry back into Gramps?

1 Like

No, I haven’t imported from Ancestry into Gramps yet. I might in the future.

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