-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add substructures to SOUR.PAGE #529
Comments
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! |
Any better idea? |
Yes, working on a concept right now! |
https://github.com/dthaler/gedcom-citations/blob/main/templates-extension.md contains my proposal for this issue and other closely related issues. |
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. |
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. |
I think your desire could be met by defining "varname" in my proposal as an enumset. 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. |
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:
The text was updated successfully, but these errors were encountered: