Skip to content
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

Open
albertemmerich opened this issue Aug 10, 2024 · 7 comments
Open

Add substructures to SOUR.PAGE #529

albertemmerich opened this issue Aug 10, 2024 · 7 comments
Labels
citations working group See https://github.com/dthaler/gedcom-citations for the working group's activities

Comments

@albertemmerich
Copy link
Collaborator

albertemmerich commented Aug 10, 2024

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
Copy link

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
Copy link
Collaborator Author

Any better idea?

@Norwegian-Sardines
Copy link

Any better idea?

Yes, working on a concept right now!

@dthaler
Copy link
Collaborator

dthaler commented Aug 12, 2024

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

@dthaler dthaler added the citations working group See https://github.com/dthaler/gedcom-citations for the working group's activities label Aug 12, 2024
@Norwegian-Sardines
Copy link

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.

#534

@albertemmerich
Copy link
Collaborator Author

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

  • possibility of correct interpreting the "varname" independent of the language used
  • exchanging the values (payloads of these standard tags) without doubt whether the correct _FIEL in receiving application was taken

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
Copy link
Collaborator

dthaler commented Aug 13, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
citations working group See https://github.com/dthaler/gedcom-citations for the working group's activities
Projects
None yet
Development

No branches or pull requests

3 participants