* GEDCOM 7.0

[KFN]

FHISO seems to have gone very quiet of late.

Some of the key people from FHISO are participating in GEDCOM v7.

Some genealogy software developers may see a standard GEDCOM as an easy way for their users to migrate to another product so not in their commercial interest.

so new, improved GEDCOM has zero sales benefits, so no-one was going to make the first move.

In some cases, developers are very reluctant to rewrite code and redesign a database that will never work with changes suggested in GEDCOM v7.

There is already discussion on V7.1 which is proposed to include things like root individual.

Why is having a “root individual” important in a GEDCOM? What happens in a merge with different root individuals? Does root individual change with every report, or based on who is viewing the database? If the GEDCOM v7 committee thinks this is a good concept they have not thought it through or beyond small local databases.

[AdrianBruce]

...

so new, improved GEDCOM has zero sales benefits, so no-one was going to make the first move.

In some cases, developers are very reluctant to rewrite code and redesign a database that will never work with changes suggested in GEDCOM v7. ...

My comment about not making the first move applied to a time when FamilySearch had, so far as anyone could see, totally given up on GEDCOM in favour of their own FamilySearch FamilyTree site. Your comment might very well apply now, though I might add that reluctance to make a move in case something else comes along will always apply. Anyone that reluctant shouldn't be in software development.

[Valkrider]

Why is having a “root individual” important in a GEDCOM? What happens in a merge with different root individuals? Does root individual change with every report, or based on who is viewing the database? If the GEDCOM v7 committee thinks this is a good concept they have not thought it through or beyond small local databases.

This was just an example of the ongoing development of Gedcom V7 there are others.

@KFN if you think this is such a bad idea then contribute to the discussions on GitHub. However, most genealogy products have the concept of a root individual and when moving from one product to another via gedcom there is currently no way of identifying the root individual.

[KFN]

I have been in contact with GEDCOM since 7.0.1 was issued and contributed to Better GEDCOM in the past!

The concept of “root individual” can have multiple meanings!

1) Current report, the individual to start the report from.
2) The individual that started the local genealogy.
3) The first individual that used the surname in a surname study.
4) The individual that emigrated to the country.
5) In a multi-user collaborative application this could be the person currently signed on to the application.

[kfunk_ia]

I have been in contact with GEDCOM since 7.0.1 was issued and contributed to Better GEDCOM in the past!

The concept of “root individual” can have multiple meanings!

1) Current report, the individual to start the report from.
2) The individual that started the local genealogy.
3) The first individual that used the surname in a surname study.
4) The individual that emigrated to the country.
5) In a multi-user collaborative application this could be the person currently signed on to the application.

None of those meaning have anything to do with the concept of the root individual in the GEDCOM file. As was previously pointed out, various program have the concept of a root individual, which in a lot of cases is the person doing the genealogy, but it doesn't have to be. So I use RM7 where I am currently the root person. If I had to transfer my data to FH7, I would want to be the root person their also. In the above example, it isn't really relevant since FH does a direct import from RM7 and 8. So I am the root person after transfer.

[tatewise]

Currently, when importing a GEDCOM, many genealogy products assume the first Individual record in the file is the root.
FH does not, and has a custom GEDCOM tag that may refer to any Individual record.
GEDCOM V7 is simply standardising that existing custom concept.
It is nothing to do with reports, surnames, emigration, etc.
Merging GEDCOM into existing data is outside the scope of GEDCOM as a communication standard.
If performing such a merge has a root conflict then it is up to the genealogy product to resolve.

[KFN]

Currently, when importing a GEDCOM, many genealogy products assume the first Individual record in the file is the root.

What is a “first individual record in the file”. Is this the first physical INDI record? What if someone is importing a subset of another GEDCOM? The first physical record could be anyone!

Merging GEDCOM into existing data is outside the scope of GEDCOM as a communication standard.

I beg to differ. I see a lot of users wanting to take a partial GEDCOM and merge it into their database. This is very much communicating.

So my question is again, What does a “root individual” provide in a GEDCOM. Or more to the point What value, if not the functions listed above, does it have in FH? I don’t see a need to identify the person doing the Genealogy. Even more so in a collaborative environment. A better place to identify the Submitter is the SUBM record! How is a “root individual” selected and what other use does it have beyond identifying the Genealogist. The genealogist may not even be in the database.

[AdrianBruce]

...
So my question is again, What does a “root individual” provide in a GEDCOM. ...

Important question... Given that the concept isn't in current (i.e. pre-v7) GEDCOM Standards, it doesn't provide anything. Currently. From v7 it provides whatever v7 says it does... We hope.

From my viewpoint, it bases diagrams and reports in the same way that 0℃ bases the Centigrade temperature scale and 32℉ bases the Fahrenheit temperature scale (except it doesn't, I know!). It is so easy to re-base the root individual in FH that I can't get remotely excited about providing it in GEDCOM.

...

Merging GEDCOM into existing data is outside the scope of GEDCOM as a communication standard.

I beg to differ. I see a lot of users wanting to take a partial GEDCOM and merge it into their database. This is very much communicating. ...

Yes, merging the partial GEDCOM is communicating but the GEDCOM Standard should be about data definition - how to deal with merging is not about data, it's about the functions that operate on that data. If the GEDCOM Standard were indeed only about data definition, then it shouldn't define functionality.

In truth, it's very difficult to define data without speaking about the functionality, but I would suggest that every reference in the GEDCOM data specification to functionality represents a bit of a failure. And I've failed in a similar manner many times...

[mjashby]

Purely my personal view, but I've never believed that the concept of a "Root individual" carries any specific meaning or purpose in a GEDCOM datafile (or database), but is purely a family history software concept which, when required, identifies a current focus individual for a particular line of research/reporting. Why else would it be possible in most, if not all, family tree software products to constantly redefine the the identity of the Root individual, or have no Root individual at all?

This seems to be born out by this very recent discussion on the FamilySearch GEDCOM Github Forum: https://github.com/FamilySearch/GEDCOM/discussions/191

Mervyn

[KFN]

This seems to be born out by this very recent discussion on the FamilySearch GEDCOM Github Forum: https://github.com/FamilySearch/GEDCOM/discussions/191

This discussion is the reason why I’m questioning the value of a “Root Individual”, and based on this comment:

From my viewpoint, it bases diagrams and reports in the same way that 0℃ bases the Centigrade temperature scale and 32℉ bases the Fahrenheit temperature scale (except it doesn't, I know!).

I suspect that no-one actually knows why it is “a thing” except it is, and someone wants it.

This concept of “some-one wants it” or “because <xyz software> has it” is really no reason to put it in the specification without providing a meaning to its use. So I keep asking, “ What value does identifying a root individual have to the sending and/or receiving program?”

Yes, merging the partial GEDCOM is communicating but the GEDCOM Standard should be about data definition

Yes I agree, I bring up merging not as a function of GEDCOM but that defining a data-point should require a definition for that data-point that states it’s use or what is to be populated in the data-point. Hence, all of my questions above, is the data-point a representation of the exporter of the GEDCOM, is it the author/submitter of the GEDCOM, is it the individual that is the earliest known ancestor? If the receiving program does not know what the data-point represents or defines the value differently then it is useless to the importing program and should be dropped!

[AdrianBruce]

... If the receiving program does not know what the data-point represents or defines the value differently then it is useless to the importing program and should be dropped!

Totally agree.

As an aside - maybe - any data model such as the one that GEDCOM implies is liable to fall into two areas. Firstly, the real world entities, attributes, relationships, etc. Secondly, the entities, attributes, relationships, etc., that are there to support the system in dealing with the real world stuff - for instance, "last updated" information. Call these the system derived entities etc. (If there is a proper term in data analysis, I've forgotten it, sorry!)

The root individual is not a real world concept, it's at best a system derived attribute of the "Individual" entity. Whether or not it makes any sense to include it in a GEDCOM specification, I doubt.

[tatewise]

It seems that Heredis 2023 now imports GEDCOM 7 files!
See https://help.heredis.com/en/creating-a- ... om-7-file/