Family Historian User Group

This thread is a derivative of the Customise Source Pane? (14572) thread.

There may also be a distinction between the terminology used in genealogy products, and that used in other contexts. For example, some users misunderstand the formal meaning in Gedcom terms of an Event and an Attribute and other items such as a Name and a Citation, compared to their everyday meaning or their formal meaning in other contexts. That is a recurrent problem when using computers where everyday words are used but with a very formal definition.

GEDCOM? Oh, you don't even want me to get started on that 'standard'! I remember the copyright holder's written comments about the GEDCOM not needing further development as it met their needs. Unfortunately, the standard did not, and still does not, meet the needs of the genealogical community. I really wish the efforts to produce a replacement had gone far beyond the 'look at replacing' efforts.

I sympathise with your comments about GEDCOM and generally agree.
But without it there would be virtually no chance of migrating thousands of records of research from one product to another, when for example a product ceases to exist, as has happened to several products recently.
At least most products follow the GEDCOM record structures of Individuals, Families, Sources, Media, etc, and their major relationships. Without that, when switching products we most probably would be faced with entering everything again from scratch. Yes, not all GEDCOM data migrates perfectly from one product to another. But in my experience that is more to do with poor implementation of the GEDCOM standard, than deficiences in the standard. So although I agree it does not fully meet all the modern needs, it does provide a useful skeleton database model, and a practical solution to migrating the bulk of ones genealogy data between products.

Yes, interpretation of GEDCOM is a problem between different genealogy software. However, as each genealogy software has added its own code to account for features beyond that 'standard' additional problems have occurred. For example, GEDCOM does not include mlti-individual events (witnesses) and definitely not same gender relationships. Yet these are common features today. Except for FTM, all common genealogy software today have implemented multi-individual, shared events. Even Genbox (on which development ceased a decade ago) includes multi-individual sharing of events.

Until an xml stylesheet and Document Type Definition are described for genealogy software (or some other SGML extension designed specifically for genealogy software), with provision for expansion, the genealogy software industry will be held hostage by the copyright holders of GEDCOM who have no desire to expand and improve that markup language.

Denise

Yes, there are new demands on the aged GEDCOM standard. But the two features you mention have remarkably consistent GEDCOM implementations in many popular products. Same gender partnerships need only a small tweak, and Fact Witnesses used legal GEDCOM extensions. It is all the illegal GEDCOM structures that cause most problems.

Yes, GEDCOM is definitely 'aged'. New hardware and OS changes in the future, plus new requests for changes / features / analysis capabilities from the genealogy market will only show that age more. While I would really like to see the arrival of an xml language that would be capable of expanding to meet the probable needs of the market, I doubt I'll see that happen. It has been, what?, a decade to a decade and a half now that promises of a new transfer format would be available? Instead, what the market has seen is the demise of several genealogy applications.

Denise

deniselmf wrote:... the genealogy software industry will be held hostage by the copyright holders of GEDCOM who have no desire to expand and improve that markup language. ...

Diversionary Rant Warning - Having been somewhat involved with the work on the BetterGEDCOM attempt at a replacement for GEDCOM, I think I hold the cynical view that the genealogy software industry are not held hostage by FamilySearch, the copyright holders of GEDCOM. They could agree a set of extensions quite happily among themselves. But they haven't... I suspect that a number of them aren't interested in extending or improving GEDCOM. Others are indeed interested - but why would they be first? It is, after all, a rather curious thing to do - to improve your software to better allow someone to take data out of it!

Replacing GEDCOM could be done without the need to involve FS - however, the investment necessary to program an XML based replacement led a number of software suppliers to dismiss XML based solutions instantly.

Life would be much simpler if FS would pick up the case and run with it again. For a while it looked like they were going to do that with GEDCOMX. However, having tied up BetterGEDCOM with that prospect, they seemed to retreat into their own shell again - and looking at FamilySearch FamilyTree, they have gone backwards in many aspects with no ability to cite sources for non-vital events such as occupations.

A quick check online yielded - "GEDCOM was developed by The Church of Jesus Christ of Latter-day Saints (LDS Church)". So while FamilySearch is a function of the Family History Library, both are part of the LDS church who is the legal holder of the copyright, not "FamilySearch, the copyright holders of GEDCOM."

If you were "somewhat involved" you are aware that some of the developers involved have since 'retired' from the genealogy software industry and their software is no longer available. The end of several genealogy software - UFT, Genbox, PAF, TMG, Roots, Ancestors & Descendents, and Family Origins to name those I remember - I also suspect hurt the effort to develop a replacement to GEDCOM. If the industry does not have people available and interested in developing a replacement to GEDCOM, that development will not happen.

Hostage? Yes. If the genealogy software industry either cannot or will not look to develop a GEDCOM replacement; and, the copyright holder of GEDCOM is not interested in further developing or expanding the data transfer capabilities of GEDCOM (whether because of costs or interest), than as users we are stuck with GEDCOM. Read the various genealogy software lists to see some of the problems people have in transferring data from one software to another, or from one software to an Ancestry tree (or the reverse).

This website http://www.gedcomx.org/About.html seems to indicate that GEDCOMX is not dead.

David

David,

Thanks for the GEDCOM X link. I've just had a look, and I'm not sure where Gedcom X is now at. The last blog is dated October 2015. It may well exist as a working specification but that is of no use if none of the major genealogy software companies are planning on implementing it.

This statement or variants of it has also been posted on a number of sites discussing Gedcom X :

"In August 2012 FamilySearch employee and GEDCOM X project leader Ryan Heaton dropped the claim that GEDCOM X is the new industry standard, and repositioned GEDCOM X as another FamilySearch open source project".

FamilySearch and some smaller outfits may well be using it.

It's also unclear how active the FHISO are at present. Their website reports minutes of a board meeting back in March 2016.

Also, just had a quick forage and I can't tell what state the betterGEDCOM project is in. Their Wiki subscription seems to have expired.

If anyone has a clear idea of the status of any of the Gedcom replacement projects it would be great to have an update! I don't think anyone should hold their breath. A new industy standard may be some way off.

Simon

The FamilySearch take on this can be found here https://familysearch.org/developers/doc ... s/gedcom-x and all the indications are that this is an ongoing project connected with the FamilySearch API (and please don't ask me about the aim of that). Looking at the Change Log this is a very active project, the most recent change being on 10 January 2017.

David

My personal views
My understanding is that GEDCOM-X is very much alive but that its sole external purpose now is to describe the API to FamilySearch FamilyTree. At one time there was a view that GEDCOM-X would come in 2 flavours - as an internal IT product with the sort of bells and whistles that provide access to lists of codes, and as an external version that could be used as a file to replace GEDCOM without the bells and whistles. The user relevant content would have been the same but the list of codes for Events (say) would have been text in a manual in the external version but codes in the internal. (There is a correct IT phrase for the sort of concept I'm attempting to describe - possibly it's name-spaces????)

I've no idea which version that used for the API is but basically the API usage is now it, I suggest. So if FS need a change (i.e. if the LDS need a change), it will progress but if the rest of us want one - forget it. And that is absolutely their right to decide that's what the situation should be. Just leaves the rest of us sitting here....

BetterGEDCOM basically died. People were beginning to take a cautious interest in the idea of a GEDCOM successor and then FamilySearch revealed its development of GEDCOM-X - whether this reveal was from simple embarrassment that 2 projects were proceeding in the same direction, or some other reason, I can't say, but everyone's attention switched to GEDCOM-X.

BetterGEDCOM attempted to put itself on a more formal footing and turned into FHISO but both elephants in the room (Ancestry and FamilySearch) seem to have declined active participation.

I would say, personally, that there is no chance of a new industry standard - nobody has yet worked out how to break into the chicken and egg situation to get someone to move first.

Thanks for your updates, Adrian and David. My reading of the situation is very much the same as Adrian's. And, unless the other major players go with Gedcom X, it really doesn't matter what FamilySearch do with it internally - even if it is a better specification!

Simon

deniselmf wrote:... {It is} the LDS church who is the legal holder of the copyright, not FamilySearch...

Just checked that - quite true, should have remembered, thanks. (I sometimes get the idea that FamilySearch gets inspired and would like to run with things but then gets reminded who pays the bills and why. It's called reality!)

deniselmf wrote:... If the industry does not have people available and interested in developing a replacement to GEDCOM, that development will not happen...

Absolutely.

deniselmf wrote:Hostage? Yes. If the genealogy software industry either cannot or will not look to develop a GEDCOM replacement; and, the copyright holder of GEDCOM is not interested in further developing or expanding the data transfer capabilities of GEDCOM (whether because of costs or interest), than as users we are stuck with GEDCOM. ...

Oh I agree that we, the users, are hostages - my point was that the software suppliers aren't held hostage - they could move. However, as I was suggesting, of those who are left, many aren't interested and of those who are interested - who moves first? How do they agree? What's in it for them? Those are not meant to be cynical or flippant questions, they are serious issues... The only way that we got to GEDCOM was because of the elephant in the room called FamilySearch.

One small step that would help, is to eliminate the conflict between GEDCOM Standard Release 5.5 and Draft 5.5.1 and everyone agree to work to ONE of them, OR fully support the import & export of BOTH.

tatewise wrote:... eliminate the conflict between GEDCOM Standard Release 5.5 and Draft 5.5.1 and everyone agree to work to ONE of them, OR fully support the import & export of BOTH.

Good point. My belief is that it has to be the BOTH option on the basis that:
- No-one would agree to downgrading to 5.5 from 5.5.1 Draft;
- Going to 5.5.1 Draft would still require the import of 5.5;
- There are issues with 5.5.1 Draft such as the debate over whether the EVENt tag should be allowed an EVENT_DESCRIPTOR as per the example on p.48 of the draft, or not, as per the definition on p.35 of the same document (using Mike's example from ages ago). Plus inconsistencies between Individual and Family Attributes. Therefore one might care to be cautious;

Yes, the ideal would be:
1) Export to allow a choice of either format.
2) Import to tolerate the different interpretations of the inconsistencies.
i.e. allow EVEN &/or FACT for custom facts, and allow both Events & Attributes to have value descriptors.

There are a few other issues regarding character encoding, same gender partnerships, fact witnesses, etc.
But there is widespread de facto acceptance of standards for them.

tatewise wrote:... allow both Events & Attributes to have value descriptors. ...

Agreed - in truth Events should be able to have a value descriptor. My example is Inheritance. That's an Event in English terms - it might have a value descriptor to describe what was inherited, or it might not if you knew only that they had some sort of inheritance, but not what.

I suspect Attributes must always have a value descriptor because otherwise how do you have an attribute? (Though Residence is a bit dodgy).

Actually Events versus Attributes is more to do with Dates than values.
An Event typically only happens on one day and if unsure which day uses a Date Range between X and Y.
An Attribute typically applies over a period time and so uses a Date Period from X to Y.
Residence Attribute is a Gedcom 'exception' because it is not allowed a value (it is already in the Address & Place fields).
However, it fits the Date criteria above.
Two Attributes I can think of that don't need a value are Military Service and Circumcision from Ancestry/FTM/TMG.

Only just come across this thread so I'd like to add an update for the record.

FHISO have recently re-established communication with Ancestry and Findmypast -- and in fact with most of their Founding Member organisations -- and will be keeping close ties with them from now on.

FHISO have (finally, some might say) produced a number of draft standards -- see http://parallax-viewpoint.blogspot.com/ ... fhiso.html for the history. One that's particularly relevant to this thread is their forthcoming ELF standard that is designed to carry GEDCOM into a more modern and standardised future. It was due this month but is currently delayed -- but it will become available for public comment.

Just to emphasise: this will only be a first draft, and anyone with a stake in GEDCOM data or software really needs to get involved.

...remember, FHISO was all about "community", and not dictating anything or selling anything.

Tony

That is a brilliant update Tony.
In my opinion, the FHISO concept of component standards assimilated into various data models with forward & backward compatibility is a stroke of genius.