* [Wish List 631] Add titles to citations

[rcpettit]

In family tree maker and rootsmagic you are allowed to create a short title description for a citation to make it easier to find. FH7 doesn't have this feature even though the gedcom standard does allow for the Name field under the source entry for this. It seems this would be a nice feature for FH in have also.

[LornaCraig]

FH does have the facility to add a Short Title. Generic sources have this field, and I make great use of it. (I use only generic sources, having started with FH many years ago. ) It is also possible to add a Short Title field to templated sources if you want to. There was a long discussion about titles and short titles, and whether they are useful with templated sources, here: Source Record Title confusion (21603)

[tatewise]

FYI: I cannot find a standard GEDCOM 5.5.1 specification for a source citation Name field.

The Source record Short Title field Lorna described is the GEDCOM ABBR <SOURCE_FILED_BY_ENTRY> field.

[Mark1834]

I think the request is for the actual citation to be given a title. This is permitted in RM8 and later (but not earlier), and is useful in managing the "Shared Citation" concept, whereby common citations to a lumped source are linked and managed as one entity.

Citation titles are silently discarded by FH when importing from RM8/9, as it has no corresponding ability (which is probably much easier to implement in the RM and FTM relational database models than in FH GEDCOM).

[rcpettit]

I generated a gedcom using rootsmagic and family tree maker. Both use a name field under the source field for the citation. Read the Gedcom 5.5.1 and 7.0 and both show the use of name under the source field. Looking at the gedcom I see the following:

2 SOUR @S263@
3 PAGE Douglas County || Douglas Co.; Kanwaka Twp.; p 87; dw 530, fm 518; Gilbert Griswold; downloaded; 22 October 2023
3 _TMPLT
4 FIELD
5 NAME Jurisdiction
5 VALUE Douglas County || Douglas Co.
4 FIELD
5 NAME CivilDivision
5 VALUE Kanwaka Twp.
4 FIELD
5 NAME ED
4 FIELD
5 NAME PageID
5 VALUE p 87
4 FIELD
5 NAME HouseholdID
5 VALUE dw 530, fm 518
4 FIELD
5 NAME Person
5 VALUE Gilbert Griswold
4 FIELD
5 NAME AccessType
5 VALUE downloaded
4 FIELD
5 NAME AccessDate
5 VALUE 22 October 2023
3 NAME Griswold, Gilbert Jr. - Douglas County
3 DATA

Where 3 Name Griswold, Gilbert Jr. Douglas County is the title for the citation.

But I'll take a look at short title, but it looks like I have to open the all tab to be able to enter it.

[Mark1834]

Check the GEDCOM carefully. The NAME fields are under 3 _TMPLT, which is the Source Template. They are exactly analogous to citation level fields in FH Source Templates.

[ColeValleyGirl]

Check the GEDCOM carefully. The NAME fields are under 3 _TMPLT, which is the Source Template. They are exactly analogous to citation level fields in FH Source Templates.

That's true of all except the last NAME which is the item under discussion.

[rcpettit]

Sorry about that, I should have highlighted the line I was talking about. I did modify my census templates to change short title to something similar to what I wanted but citation to source only shows the long title. But it's still workable.

[tatewise]

The relevant part of your example GEDCOM file is:

Code: Select all

2 SOUR @S263@
3 PAGE Douglas County || Douglas Co.; Kanwaka Twp.; p 87; dw 530, fm 518; Gilbert Griswold; downloaded; 22 October 2023
: : : : : : : : : : : : :
3 NAME Griswold, Gilbert Jr. - Douglas County
3 DATA

i.e. the PAGE, NAME & DATA tags are all at the same level 3.

In GEDCOM 5.5.1 on page 39 there are matching PAGE and DATA tags but no NAME tag:

SOURCE_CITATION:=
[ /* pointer to source record (preferred)*/
n SOUR @<XREF:SOUR>@
+1 PAGE <WHERE_WITHIN_SOURCE>
+1 EVEN <EVENT_TYPE_CITED_FROM>
+2 ROLE <ROLE_IN_EVENT>
+1 DATA
+2 DATE <ENTRY_RECORDING_DATE>
+2 TEXT <TEXT_FROM_SOURCE>
+3 [CONC|CONT] <TEXT_FROM_SOURCE>
+1 <<MULTIMEDIA_LINK>>
+1 <<NOTE_STRUCTURE>>
+1 QUAY <CERTAINTY_ASSESSMENT>

The GEDCOM 7 page 60 specification is virtually the same again with no NAME tag:

SOURCE_CITATION :=
n SOUR @<XREF:SOUR>@
+1 PAGE <Text>
+1 DATA
+2 <<DATE_VALUE>>
+2 TEXT <Text>
+3 MIME <MediaType>
+3 LANG <Language>
+1 EVEN <Enum>
+2 PHRASE <Text>
+2 ROLE <Enum>
+3 PHRASE <Text>
+1 QUAY <Enum>
+1 <<MULTIMEDIA_LINK>>
+1 <<NOTE_STRUCTURE>>

Please specify the GEDCOM page where the NAME tag is defined as a valid citation field.
The GEDCOM you posted is invalid and I suspect would fail a GEDCOM validity check.

[rcpettit]

Thank you for pointing that out. I downloaded a validator and you are right. This is the reason why I hate gedcoms. The standard isn't a good standard if you have to deviate from it to accomplish a simple task. I did find a somewhat workaround using the short footnote field.

[KFN]

Thank you for pointing that out. I downloaded a validator and you are right. This is the reason why I hate gedcoms. The standard isn't a good standard if you have to deviate from it to accomplish a simple task. I did find a somewhat workaround using the short footnote field.

Why do you need to have a “Title” for a citation? This does not make sense to me! A GEDCOM source_citation is usually part of the “fact” (it can be part of a record instance too) and in general only carry’s information about that fact (or record instance), therefore in GEDCOM to find the source_citation all you need to do if look at the fact for the Source_citation! The standard/specification is very specific in how it is used and does not need a title, the source_record contains the title for the source!

[rcpettit]

It's easier to find a citation that says

Doe, John - 1940 U.S. Census - Lee County, Florida

as a title, then

1940 U.S. Census, Lee County, Florida; population schedule; Fort Myers; enumeration district (ED) 12, pg 1A, dw 12, fm 22; John Doe; digital images, Ancestry.com (www.ancestry.com : downloaded 21 Oct 2023).

This is because I'm a Lumper.

[tatewise]

Thank you for pointing that out. I downloaded a validator and you are right. This is the reason why I hate gedcoms. The standard isn't a good standard if you have to deviate from it to accomplish a simple task. I did find a somewhat workaround using the short footnote field.

If it were not for the GEDCOM specification it would be very difficult to migrate genealogy data among products.
At least the majority of the most relevant data does migrate well. It is product idiosyncrasies that might not.
It would be even better if all products implemented the full specification correctly but most don't, c.f. NAME tag.
If a citation Name field is required then the GEDCOM 5.5.1 specification allows the _NAME tag form with an underscore prefix to make it clear it is an extension to the standard and recognised as such by other products.
That would pass the GEDCOM validity checks.
The GEDCOM 7 specification allows such extensions to be more formally specified in the GEDCOM file.

If you need searchable name data in citations rather than the Source record then in the citation local Note field use a labelled note that can be found by the Edit > Find... command or =GetLabelledText(...) function in a Query.
A custom plugin should be able to move the NAME text to the labelled local Note.

[KFN]

This is because I'm a Lumper.

I have nothing against what you refer to as “lumping”. When using a specific program that supports and/or encourages lumping rather than splitting you should go with the way they designed their database, data input and reporting methods.

GEDCOM v5.5.1 and future releases of the Standard uses a “Splitting” design (as define here https://www.fhug.org.uk/kb/kb-article/ ... -method-2/ where the Source_Record contains the general information about the source and the Source_Citation contains the specific information about where in the source the writer/collector found the information being cited.

As Tatewise indicated the GEDCOM Standard specification was devised so that data can be consistently transferred from program to program (more specifically so that a program can transfer data to the LDS database). The Specification allows for non-standard tags to be added that are not part of the specification by adding a “_” before any non-standard tags, but with the caveat that they may not have “context” in the receiving program and that they should be transmitted in a more universal way by using a NOTE.

The GEDCOM Specification is not a fault, the sending program should better follow the specification as outlined so that the receiving program has a chance to understand the data! Should GEDCOM in the future support lumpers better, this is a discussion that the GEDCOM design team has had and at present does not have a solution for supporting both lumped and split sources in the same file and still follow good design principles.

[AdrianBruce]

... Should GEDCOM in the future support lumpers better, this is a discussion that the GEDCOM design team has had and at present does not have a solution for supporting both lumped and split sources in the same file and still follow good design principles.

Philosophy: Maybe a more fruitful approach would be to look in the opposite direction and examine how sources could be grouped into collections? Collections being part of bigger collections. That is, after all, what happens to "sources" in Archive Catalogues. This could be designed to allow for inheritance of stuff from the level "above". And I hope that the attributes of a collection would look very like the attributes of a source...

Then the lumpers could cite the census class / collection as their source record and their lowest level would be the source record for the household. Which sounds just like the splitters who have the source record for the householders but use a higher-level source record to define the collection.

[KFN]

... Should GEDCOM in the future support lumpers better, this is a discussion that the GEDCOM design team has had and at present does not have a solution for supporting both lumped and split sources in the same file and still follow good design principles.

Philosophy: Maybe a more fruitful approach would be to look in the opposite direction and examine how sources could be grouped into collections? Collections being part of bigger collections. That is, after all, what happens to "sources" in Archive Catalogues. This could be designed to allow for inheritance of stuff from the level "above". And I hope that the attributes of a collection would look very like the attributes of a source...

Then the lumpers could cite the census class / collection as their source record and their lowest level would be the source record for the household. Which sounds just like the splitters who have the source record for the householders but use a higher-level source record to define the collection.

In database terms we call this a “bill of materials”, which is an endless string of something made up of other something’s. This is similar to the approach I’d like them to take with PLACe hierarchy. It is less SQL friendly than the current approach for sources.

[AdrianBruce]

..In database terms we call this a “bill of materials”, ...

Thanks - I'd not heard that phrase (in that context).

.. It is less SQL friendly than the current approach for sources.

Err - yes. I can imagine.

[ColeValleyGirl]

This received a fair bit of discussion which petered out a couple of months ago.

Is there any support for the proposal?

[Vyger]

I generated a gedcom using rootsmagic and family tree maker. Both use a name field under the source field for the citation. Read the Gedcom 5.5.1 and 7.0 and both show the use of name under the source field. Looking at the gedcom I see the following:

2 SOUR @S263@
3 PAGE Douglas County || Douglas Co.; Kanwaka Twp.; p 87; dw 530, fm 518; Gilbert Griswold; downloaded; 22 October 2023
3 _TMPLT

I'm guessing from the look that your Gedcom example is Rootsmagic generated? That is because the non-standard templated data following the "3 _" is concatenated into the PAGE line.

If it were not for the GEDCOM specification it would be very difficult to migrate genealogy data among products.
At least the majority of the most relevant data does migrate well.

Do be aware that FH does not concatenate templated data into a PAGE line in such a manner and CP are aware. The result is that any Templated sources/citation data is essentially lost when using Gedcom to My Heritage, Legacy Family Tree and the like as there is no standard Gedcom PAGE line.

[tatewise]

I'm guessing from the look that your Gedcom example is Rootsmagic generated? That is because the non-standard templated data following the "3 _" is concatenated into the PAGE line.

Why should 3 _TMPLT be concatenated into the 3 PAGE line?
They are simply unrelated sibling values at level 3 and the following would be perfectly valid:
2 SOUR
3 _TMPLT
4 FIELD
5 NAME Jurisdiction
3 PAGE

For comparison consider:
1 NAME
1 RESN
1 NOTE
They are sibling values and should not be concatenated.

The only concatenation feature is the CONC and CONT tags that only apply to NOTE and some other tags and use different level digits:
1 NOTE
2 CONC
2 CONT

[Vyger]

Why should 3 _TMPLT be concatenated into the 3 PAGE line?

It's the non-standard templated data following the 3 _TMPLT line which needs to be preserved for cross platform compatibility.

Presently Rootsmagic concatenates this templated data into the standard Gedcom PAGE line, FH does not.

[KFN]

Why should 3 _TMPLT be concatenated into the 3 PAGE line?

It's the non-standard templated data following the 3 _TMPLT line which needs to be preserved for cross platform compatibility.

Presently Rootsmagic concatenates this templated data into the standard Gedcom PAGE line, FH does not.

As tatewise indicated a level 3 tag is not concatenated to another level 3 other than when the tag name is CONC. Even a CONT is not a true concatenation it represents a newline or a new paragraph!

As an aside, the CONC tag has been eliminated in GEDCOM v7 and above!

[Vyger]

Do be aware that FH does not concatenate templated data into a PAGE line in such a manner and CP are aware. The result is that any Templated sources/citation data is essentially lost when using Gedcom to My Heritage, Legacy Family Tree and the like as there is no standard Gedcom PAGE line.

Another go and perhaps some testing required by those who have not grasped the issue I describe. Whilst the issue is Template related, it is not directly related to this valid Wish.

Firstly a templated source from Family Historian and relatively few fields;

fh-source.PNG (44.74 KiB) Viewed 772 times

Going back to Rootsmagic where this source was originally created Rootsmagic 7 exports the Gedcom format below;

2 SOUR @S520@
3 PAGE 1901; Moutraghs; Aghagallon; Antrim, Ireland
3 _TMPLT
4 FIELD
5 NAME CensusYear
5 VALUE 1901
4 FIELD
5 NAME Townland
5 VALUE Moutraghs
.....

The point I am making is that Rootsmagic concatenates the templated source detail components into a standard Gedcom "3 PAGE 1901; Moutraghs; Aghagallon; Antrim, Ireland" line before going non-standard Gedcom for the template and templated data. The result of this is that templated source detail is not lost on Gedcom export from Rootsmagic and therefore remains compatible with other genealogy software.

Ref, non-standard Gedcom is where you see the underscore character being used.

Family Historian exports the same Templated Source as;

2 SOUR @S521@
3 _FIELD DT-CENSUSYEAR
4 DATE 1901
3 _FIELD TX-TOWNLAND_STREET
4 TEXT Moutraghs
3 _FIELD TX-DED
4 TEXT Aghagallon
3 _FIELD TX-COUNTY
4 TEXT Antrim, Ireland
3 _QUAY 0xa4

There is nothing legacy compatible in that format and yes Family Historian does offer the option to copy templated data fields to the First or New Note. It's not ideal and most users will miss that option in my opinion.

The Family Historian Gedcom export of this same templated source goes straight to non-standard Gedcom on the second line and is therefore alien to other programs with no standard Gedcom concatenation of templated citation details exported to maintain cross platform compatibility.

To further illustrate this compatibility problem I imported the Family Historian derived Gedcom into Family Tree Maker 2019 and you can see the blank citation details in the image below.

ftm-source.PNG (75.39 KiB) Viewed 772 times

Lets not get bogged down in pedantics, this is the fact and please do your own testing.

Getting back to this valid Wish I can also confirm that Rootsmagic 8 & 9 export the standard Gedcom;
3 NAME 1901; Moutraghs; Aghagallon; Antrim, Ireland (in this case example) after the non-standard Gedcom templated components, adding that is the essence of this Wish and I agree.

For reference Rootsmagic 7 did not export a NAME field for citation data.

Perhaps this is a case of Splitters failing to understand what is essentially a Lumper problem but I do hope the graphics and long winded explanation clears up any residual confusion, DYOR

[tatewise]

Thank you for that explanation of what you mean by concatenation which makes the request much clearer.
I would prefer to say that the Template Field values are migrated into the PAGE/NAME value.

It seems that RootsMagic 7 used the PAGE field but RootsMagic 8 & 9 use the NAME field.
But as explained on Tue 31st Oct 2023 22:57 and agreed by others, NAME is not a standard GEDCOM Citation field and should have an underscore prefix such as _NAME. So RootsMagic 8 & 9 are producing invalid GEDCOM.

Mostly, the FH Export > GEDCOM File... command exports all the non-standard GEDCOM fields unaltered.
A few options allow some adjustments to be made for a tiny number of field types as you mentioned.
So in general, very few of the custom FH features will export to other products.
Notable exceptions are _SHAR and _SDATE.

To overcome those limitations the Export Gedcom File plugin tries to cope with all those non-standard anomalies.
It seems reasonable that it could have an option to migrate the Citation Template Field values into the PAGE field or even an invalid NAME field.
Would that satisfy this request? It would probably get implemented far sooner than in FH.

[ColeValleyGirl]

Mike, the original request has nothing to do with exporting so, while changes to your plugin would I suspect be welcome, they can't meet the reqeust.