FamilySearch / GEDCOM

Apache License 2.0
160 stars 20 forks source link

Add substructures to SOUR.PAGE #529

Open albertemmerich opened 1 month ago

albertemmerich commented 1 month ago

Citing a source we have a lot of different data to put in SOUR.PAGE. It may be the volume, the chapter, the year, the page number, the record number, a film number, an url link or whatever. I see the problem, that differentiating those entries by labels like "chapter:" within the PAGE payload is language dependant. An example for a payload, written by a German user: 2 PAGE Band: III, Kapitel: Heiraten, Jahrgang: 1888, Seite: 178, Nummer: 478 Any tasks like interpreting this payload, sorting the citations by the various data in page, and even translating to other languages are difficult to do. I propose to add subtags to SOUR.PAGE to be language independant and to enable interpreting the page data, like:


2 PAGE
3 VOLM <volume>
3 CHAP <chapter>
3 YEAR <year>
3 PGNR <page number>
3 ETNR <entry number>
3 FLNR <film number>
3 URL <url link>
...
Norwegian-Sardines commented 1 month ago

I agree with your identification of the problem, but disagree with your solution! The use of specific tags to represent data points is too restrictive for general use!

albertemmerich commented 1 month ago

Any better idea?

Norwegian-Sardines commented 1 month ago

Any better idea?

Yes, working on a concept right now!

dthaler commented 1 month ago

https://github.com/dthaler/gedcom-citations/blob/main/templates-extension.md contains my proposal for this issue and other closely related issues.

Norwegian-Sardines commented 1 month ago

Please see my alternative view on what a “citation” is as apposed to what several software applications misuse and misunderstand what a citation is with their use of the Source_Record as a makeshift citation.

https://github.com/FamilySearch/GEDCOM/discussions/534

albertemmerich commented 1 month ago

Daves proposal does not offer what I am looking for. See in his document: source citation is proposed as

1 SOUR @S12@
2 PAGE 123
3 _FIEL varname
4 TEXT value
3 _FIEL varname
4 TEXT value

This is possible with any GEDCOM standard allowing extension _TAGs, as 5.0, 5.5.1, 7.1. However: The transfer of data in between applications is difficult as it would depend on a common agreement on the _FIEL varnames. It would give all problems we have with extension tags!

What I am looking for is a set of standard tags defining the most often used elements within a PAGE payload, which would ensure

Any template can use these standard tags, and their payloads to build a citation in text form, in any language the template supports.

Only in case we missed a PAGE element when defining the standard tags the extension solution should be used.

dthaler commented 1 month ago

Daves proposal does not offer what I am looking for. See in his document: source citation is proposed as

1 SOUR @S12@
2 PAGE 123
3 _FIEL varname
4 TEXT value
3 _FIEL varname
4 TEXT value

This is possible with any GEDCOM standard allowing extension _TAGs, as 5.0, 5.5.1, 7.1. However: The transfer of data in between applications is difficult as it would depend on a common agreement on the _FIEL varnames. It would give all problems we have with extension tags!

What I am looking for is a set of standard tags defining the most often used elements within a PAGE payload, which would ensure

I think your desire could be met by defining "varname" in my proposal as an enumset. Instead of standard structure tags, you'd have standard enum values, and still allow extensibility since enumsets can have extension values already.

Still the enumset would grow to be quite large (I expect on the order of a couple hundred). If that were done, the considerations in #518 would apply to this discussion.