Extend predefined Event, Attribute and Role types based on GedcomX and other suggestions #117
Comments
|
The thought just popped in my head it would probably make sense to also add attributes for DNA related information and add a role type for shared DNA match as well. |
|
Thanks for this list! A few that I think we already have:
I think we have these too, but am not sure I understand the nuance enough to be confident:
Given the current definition of DNA was discussed at length when designing 7.0, and the conclusion of our team at the time was that there was not enough consensus on what DNA evidence looked like to be able to propose adding structures to represent it. I'd be excited if that's changed; your proposal of a ROLE for "DNA match" might be one we could add without needing too much consensus on what constitutes a match, for example. |
|
I mentioned I think you also need Another suggested event would be Another suggested attribute would be Another suggested role that comes to mind is
Looking again quickly I mostly agree. I wish these were used consistently, why is
In my mind Regarding the use of
I am not sure anyone actually uses it. That is certainly not the same as GedcomX differentiates between Regarding I understand about the DNA evidence question and agree, but there should probably be |
|
I propose adding mtDNA and yDNA data support for GEDCOM 7.x (since they are MUCH smaller datasets). Programs like AncestralQuest 6.x already support this, so having this in the GEDCOM format would be a natural extension and support for what some vendors are already doing and allow for greater interoperability between programs and websites. https://ancquest.com/index.htm See here: |
|
Discussed in steering committee, 2022-04-12. At a high level, we want
We mentioned several approaches that might reach these goals, but did not converge on any one in particular. |
|
So reference some public, centralized master event and attribute registry which would ideally be managed as a Github repository so anyone can contribute to it as needed. Registry data could be stored as structured yaml perhaps. Maybe 1 file per event or attribute type to prevent any single document from getting too large. In addition to allowing for hints you would certainly want to allow for the inclusion of translations as well for the short name/label and the longer description. |
|
And perhaps if FamilySearch or someone else is willing then host some free online REST API read only service to make the data available for applications that might perfer to consume it that way. |
I would rather this information be deduced by code rather than an event. We have individual Residence dates then we can deduce they moved from point a to b.
|
|
To make sure that |
|
At RootsTech I spoke with several developers about the proliferation of event types. General observations:
I propose the following event and attribute hierarchy, in which I think I have included all 7.0, X, and other suggested values from this thread and from a private email I received. But it's a huge list so I likely omitted something inadvertently. If we like the organization then next steps would be to decide how to encode the organization in the spec, followed by a verification that nothing was inadvertently omitted. I have not included DNA, which appears to require significantly more structure than any other attribute or event and for which we have competing proposals; see #118 for more.
|
|
I am glad to hear this. I like to think of events as experiences and attributes as characteristics, I think it makes the distinction clearer sometimes. So I'd tend to think of newspaper articles maybe falling into the attribute category. Anyway here are some more possibilities for consideration: Possible parner events:
Possible child events:
Possible death / burial events:
Possible religious events:
Other possible events:
Possible attributes:
Possible roles:
For pedi:
|
|
The GEDCOMX-Page states:
(btw: You will find this text below the type In what kind of context should There are different international definitions and interpretations of the term race, which are intensively discussed in their respective environment and context. Besides the historical inhuman race-ideological view, this term is nowadays also used for socio-cultural classifications in some countries. I personally find the latter a very awkward choice, however, others decide this. For the above reasons, however, I think that in GEDCOM the term Personally I don't see any need for "Race", because I certainly won't spread any (historical) racist ideologies - for which there is no legitimation at all - any further. For a socio-cultural classification the term "Ethnicity" is better suited. |
"Race" is a common descriptor on historical documents in the colonial and post-colonial European diaspora. While some researchers share your attitude of recording only legitimate information, others wish to encode every historical descriptor found. If we chose to remove it from 7.1 then it will still be recorded by those researchers either with the generic I believe this is why GEDCOM-X defines it as the declaration of race, rather than of race itself, a distinction it does not make for any other of it's "fact" types.
The defining document for this URI is is https://github.com/FamilySearch/gedcomx/blob/master/specifications/fact-types-specification.md. The documents served at the various gedcomx.org URLs have several errors, including the duplicate religion and missing race, presumably because they are not automatically extracted from the spec the way those served on gedcom.io are. |
|
Some thoughs on event and attribute categories. Maybe for events something broken down like: Vital (birth and death related) And then for attributes maybe something along the lines of: Biological (sex, haplogroups, etc) |
|
I’d like to know and understand how several of these facts are actually used. For example: To me these are not facts or attributes, they are sources. I think we also need to be careful that “facts” are not just a different type of the same major concept. For example: DomesticPartnership Are all variations on the concept of marriage or at least the overarching concept of a union between two people. Currently I use the Another one would be MILITARY, is should have aspects of the military like: Draft Registration, Induction, Service, Deployment, Discharge all as This is what I believe the best use of the |
|
Of course they can be considered sources. But it is also a fact that the article ran on a specific date and it referenced one or more people, or that the autopsy was performed on the remains by someone on such and such a date. Having those as enumerated types and enabling someone to use them to record things does not mean you have to choose to use it to record something. Perhaps some users want to see those on a timeline with everything else. I follow your point on the With regards to military, it really is a category and not a specific type of event. I think it was perhaps not given enough thought years ago. Marriage you have me thinking more about now. Personally I'd prefer separate event types for Civil Marriage and Religious Marriage, they are two different things. Indeed if going the |
|
Personally I think that those programs that don’t support the GEDCOM While the DB designer in me would like the change of If we are wanting more FACT and ATTR tags, I’d want additions like NOTE: I’m just kidding, but driving home a point about taking standard facts and attributes too far! I do use some of these but use Having more tags does have one advantage, they can be translated to other languages easier, but how many programs actually do translation of these tags? |
|
I would rather see GEDCOM move to supplying a list of enumerated values for 1 MARR This way they can be easily added to the specification and translated by receiving programs. Additional concepts not known today can be added in the future as well! This would work as well for other concepts as well that would eliminate variations of BIRT, BURI and others. I have family members who’s remains were never found and I currently use a |
The question at hand here and in the discussion thread as well on this issue seems to be should the standard try to keep a flat enumerated type space, with one specific type per tag, or not. I suppose in the end it does not matter, what matters is that the types are enumerated so the intended information content is identifiable when being transferred between applications.
I would argue yes, probably should have a |
I don’t think that I am, a burial is a disposition of a decedent, this would be mutually exclusive of either, Inhumation, Burial at Sea, Cremation, Donation to Research, Lost, Natural, Green, Burial Tree or Scaffolding, cave and probably many other ones depending on culture. If GEDCOM is to support multi-cultural habits of individuals and family groups then we need to expand the definition of items to be inclusive and adding a new |
|
I’ve add some comments to the #301 regarding this proposal. |
|
The steering committee is committed to resolving this issue, but the conversation here is getting too long to be effectively used. We've added a new directory of files to hopefully help guide this conversation and proposals: the attribute and event requests. We invite contributions to those files, as described in the README in that directory. As adequate evidence of use, value, and absence of specific event and attribute types are documented there we'll add them to future minor versions of the specification. We are also discussing revising the entire event/attribute system to something easier to maintain for a future major version. We did not copy all of the items listed here to those documents, but are open to others doing so if they wish. |
|
Luther, I’m not familiar with “pull requests” in GitHub. Also I would not know how to suggest the use of the TYPE tag to support a specific suggested new Attribute. Specifically, GEDCOM 5.5.1 and 7.x have an attribute called For example: |
Note that pull requests are proposed changes that will be reviewed and possibly edited by the steering committee prior to merging. We appreciate fully formatted PRs, but can fix formatting and styling fairly easily if you have trouble there.
There are a few examples of this, with different levels of assertion. In the table,
In addition to the table, add appropriate text in the Absence subsection of the corresponding section. (see, e.g. Stillbirth. If that level of editing is uncomfortable for you, you're also welcome to file an issue requesting one of the steering committee make the edit for you. A separate issue (rather than a comment here) will let us track progress on fulfilling that request.. |
|
While a few other issues have been opened on this topic, wanted to include here as well that the CompGen group has compiled an extensive summary of GEDCOM custom tags that also identifies the applications that make use them that is worth reviewing. |
|
Discussion in GEDCOM Steering Committee meeting: |
This German group has done a lot of work regarding extending and using GEDCOM. If they were not on your radar before, you have missed out on a lot of information. I would note that some use cases are not complete but very close! |
|
Child event:
|
|
I believe that Places should be an item of level 0. |
I notice that no attempt was made to even try to align the predefined Event, Attribute and Role types with those in the GedcomX specification. I think it would be beneficial to have a much richer set of predefined values to cover as many use cases as possible to help avoid the use of custom types unless absolutely necessary.
There doesn't seem to be a clear mapping between the two especially as GedcomX includes some items under both categories, but perhaps something like the following would make sense:
Suggested Individual Events taken from GedcomX:
Other suggested commonly used Individual Events:
Suggested Family Events taken from GedcomX:
Suggested Attributes taken from GedcomX:
Other suggested Attributes:
Some additional suggested Roles:
It would probably make sense to survey the more popular third party genealogy applications and websites to see what other non-Gedcom defined events and attributes they have added to fold in others that may be commonly used.
It also isn't clear to me if the GedcomX documents are being kept current. For example I notice on FamilySearch website Affiliation, Religious Affiliation, Title of Nobility, and Occupation are events that can be added but they do not appear in the GedcomX event types specification. Furthermore the Title of Nobility is an attribute in Gedcom but I do not see it under the GedcomX fact types either.
The text was updated successfully, but these errors were encountered: