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

[Feature][enhancement] Citations as specific "objects" #5006

Closed
chtiland opened this issue Jul 7, 2024 · 7 comments
Closed

[Feature][enhancement] Citations as specific "objects" #5006

chtiland opened this issue Jul 7, 2024 · 7 comments

Comments

@chtiland
Copy link

chtiland commented Jul 7, 2024

Hello

Since "proofs" on an event or a fact comes from the "Citation" of a "Source" (witch is "stored" in a repository), it would be nice to to consider them as specific "object" linked to "Source", because a citation of a source is often the same for many events.

Example (in french) :

  • Repository : "Archives départementales du Nord"
    • Source : "Registre des mariages de Lille [1948]"
      • Citation : "Acte de mariage de DUPONT X MARCHAND"

In "Acte de mariage de DUPONT X MARCHAND" we found (in braces events that should be attached to the same citation):

  • Information about marriage itself.
  • Information about Husband and Wife {Birth, Residence, Occupation} x 2
  • Information about their parents {Birth, Death, Residence, Occupation} x 4
  • Information about witnesses where some can be members of the family {link, occupation, birth}
  • Sometimes information about "recognition and legitimization of a child or more" (individual changing family name, Recognition, legitimization)
  • Rarely (but should happen) registar (employee, mayor etc.) is a member of the familly

This citation could be "attached" to more than 20 events.

I took a marriage as an example, but it also happens with many kind of documents :

  • Recensement (census) : Family (Parents, Children, sometimes other members) => Birth, Occupation, Residence, Employee*
  • Dossier professionel (Professional file) : Individual, Familly => Birth, Death, Occupation
  • Military file : Individual => Birth, Death, Occupation (in civilian life), Residence, Physical description (height, eye colour, hair, etc.)

So when, later, adding any information about a citation, (eg. : enter TEXT, not NOTE, from the digital version of the document, or its translation) would require only one modification, and not as much as there are event linked to "Source".

Or do I missed something about Citations in Webtrees ?

@fisharebest
Copy link
Owner

This is a good idea - but it is not part of the GEDCOM specification.

It has been discussed for inclusion in a future version. e.g. FamilySearch/GEDCOM#455

When it is part of the standard, I will include it in webtrees.

@Norwegian-Sardines
Copy link

Until GEDCOM normalizes the Source_Citation someone could write a module that adds a citation to a set of specific INDI. tags!

@chtiland
Copy link
Author

Not in GEDCOM specs... but Gramps does it (and probably other software), and Gramps Web too... so I no longer use Webtrees.

@Norwegian-Sardines
Copy link

Not in GEDCOM specs... but Gramps does it (and probably other software), and Gramps Web too... so I no longer use Webtrees.

Enjoy your use of Gramps.

@fisharebest
Copy link
Owner

I agree this would be useful.

The GEDCOM maintainers are considering this - FamilySearch/GEDCOM#348

When a they define the structure, I will add support for it. Until then, I'm afraid this is a won't-fix.

@StoltHD
Copy link

StoltHD commented Feb 8, 2025

Maybe it's time to consider other formats for data exchange in genealogy in addition to the extremely limiting GEDCOM format that only a few software programs manage to follow.

GEDCOM has always been a format designed for the data collection of the LDS Church, and nothing else. People started using it for data exchange because there were no other formats available in this niche of research, not even a good way to export to CSV in most niche software.

If you look at the broader historical research communities, no one uses GEDCOM; they use XML, JSON, CSV, and most of them use known standardized versions of these formats.

It says it all when people in other forums argue with statements like, "I have been doing this for 40 years and it's all I need."

The fact is, when you move from the very limiting lineage-linked research approach defined by the LDS Church to more fulfilling and historically correct research ideas like event-based research or document-based research, GEDCOM can no longer be used without data loss. Even today, in most lineage-linked research software, there is a large amount of data loss when exporting data via the GEDCOM standard.

Another fact is that when you follow the lineage-linked approach, you are actually falsifying history. You rewrite history by making events person-dependent, not place-dependent; only the vital events of a person are actually person-dependent.

So, when you relate an event to a person and simply link it to a place, this is historically incorrect.


I few years back I tested Webtrees and a few other similar software, but because of these limitations, I could not use it, because my research goes beyond lineage-linked research...
For the same reason I had to stop using Legacy, the closest I come to a flexible software was actually Gramps, but today I actually use Obsidian and Foam for VSC for most of my genealogy and historical research, both gives me a much better way of linking object, subject, items, places, events etc. etc. in a historical correct way than any genealogy software does... and I don't need to write hundreds of lines of code to create reports and views, like I need to do when using neoj4 or orangeDB, or even a realation database.


To support a wider field of research do not mean that the software has to drop the gedcom export, but the software can gain more users if it supports a broader field of historical research/researchers.

All the software needs to do is to notify the users that if exporting using gedcom, there might/will be dataloss, until a gedcom format is released that do not have any limitations at all.

@Norwegian-Sardines
Copy link

StoltHD,

Please explain to me how XML, JSON and CSV would be better as a transfer protocol than the current GEDCOM protocol.

Please explain the data loss in GEDCOM you are experiencing when use "event-based" research vs "lineage-linked" research.

Please explain the data loss you are noting that is directly related to the design of GEDCOM vs data loss that can be attributed to misuse of the GEDCOM Standard. What data points are not being transimitted by GEDCOM in the current v7.0 Standard that should be included in v7.1 GEDCOM currently being worked on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants