Web based family history software

Question Integration of gedcomx in webtrees

  • darwtyman
  • Topic Author
  • Visitor
  • Visitor
9 years 1 month ago #1 by darwtyman
Integration of gedcomx in webtrees was created by darwtyman
I saw that FamilySearch has created a php library for working with gedcomx.

I wonder if webtrees in the future will support the gedcomx format.

Project webpage:
www.gedcomx.org
Gedcomx PHP: github.com/FamilySearch/gedcomx-php

Thank you very much

Please Log in or Create an account to join the conversation.

  • bertkoor
  • Away
  • Platinum Member
  • Platinum Member
  • Greetings from Utrecht, Holland
More
9 years 1 month ago #2 by bertkoor
Replied by bertkoor on topic Integration of gedcomx in webtrees
I don't think there are currently any plans, bu who knows the future...

The main reason to stick with traditional GEDCOM is it's the de-facto standard to transfer data inbetween genealogical editing & representation software. If somehow GedcomX gets very popular, that would only increase chances it will be incorporated into webtrees.

stamboom.BertKoor.nl runs on webtrees v1.7.13

Please Log in or Create an account to join the conversation.

  • darwtyman
  • Topic Author
  • Visitor
  • Visitor
9 years 1 month ago #3 by darwtyman
Replied by darwtyman on topic Integration of gedcomx in webtrees

bertkoor wrote: I don't think there are currently any plans, bu who knows the future...

The main reason to stick with traditional GEDCOM is it's the de-facto standard to transfer data inbetween genealogical editing & representation software. If somehow GedcomX gets very popular, that would only increase chances it will be incorporated into webtrees.


You say it is a de-facto standard but from what little I've seen of the gedcom format, it has many compatibility issues between versions and compliance with the standard ( www.tamurajones.net/GEDCOMVersionDetection.xhtml ).

For example, I made a demo webtrees with standard elements but when I import in Gramps the gedcom file generated with webtrees, Gramps throw a lot of errors.

In contrast with Gedcomx that uses xml and json which makes it much easier data exchange between applications, not just genealogical but otherwise as may be cms (joomla, drupal, etc).

Anyway, thank you very much for reading.

Please Log in or Create an account to join the conversation.

More
9 years 1 month ago #4 by fisharebest
Replied by fisharebest on topic Integration of gedcomx in webtrees
I look at the GEDCOM-X project every now and then...

Some bits look interesting, but I see that for dates, it still says "Dates MUST be specified using the proleptic Gregorian calendar."

webtrees has many users of the Jewish, Arabic, Persian and French calendars. Much of my own data is in the Julian calendar.

Perhaps the author(s) of GEDCOM-X have simply dismissed calendar handling as "too hard"?

Greg Roach - greg@subaqua.co.uk - @fisharebest@phpc.social - fisharebest.webtrees.net

Please Log in or Create an account to join the conversation.

  • norwegian_sardines
  • Offline
  • Platinum Member
  • Platinum Member
More
9 years 1 month ago #5 by norwegian_sardines
Replied by norwegian_sardines on topic Integration of gedcomx in webtrees
If you want to use GEDCOMX, the developers over there have a conversion tool you can look at.

Moving to an XML based data transfer platform has some very important advantages. Data typing and schema control are some of the first that come to mind.

However, the current issues with GEDCOM are primarily the fault of software companies not following the standard from the get go. Many programs don't perceve a need for understanding or supporting the standard as written, and forge their own "dialect" of the standard. It is not the issue of "version" differences as you noted but the misunderstanding of the version that they claim to support.

Before webtrees supports any other "new" GEDCOM standard a real standard must be created that all software companies must follow. This standard must support constructs that go beyond "Western" usages for name, dates, places. Support languages that use various character sets, allow for time and place centric variations in data. XML can do this but I don't see the design of the NEW standards (their are several contenders) doing this yet.

I'd rather see webtrees develop a database that supports the data that professional and commited genealogist need to record their information, be it an Evidence-Based or a Conclusion-Based schem, then output that data to whatever "newfangled data transfer schem" the world needs.

Ken

Please Log in or Create an account to join the conversation.

More
9 years 1 month ago #6 by Tel
Replied by Tel on topic Integration of GEDCOM-X in webtrees

norwegian_sardines wrote: <snip>
However, the current issues with GEDCOM are primarily the fault of software companies not following the standard from the get go. Many programs don't perceve a need for understanding or supporting the standard as written, and forge their own "dialect" of the standard. It is not the issue of "version" differences as you noted but the misunderstanding of the version that they claim to support.

Before webtrees supports any other "new" GEDCOM standard a real standard must be created that all software companies must follow. This standard must support constructs that go beyond "Western" usages for name, dates, places. Support languages that use various character sets, allow for time and place centric variations in data. XML can do this but I don't see the design of the NEW standards (their are several contenders) doing this yet.

I'd rather see webtrees develop a database that supports the data that professional and commited genealogist need to record their information, be it an Evidence-Based or a Conclusion-Based schem, then output that data to whatever "newfangled data transfer schem" the world needs.



I agree. Having also occassionally looked at GEDCOM-X since it was first announced in 2013 it has not received much in the way of public support by software vendors. This is key as it needs vendors to switch from GEDCOM en-mass - so everybody is working towards the same 'Standard'. At present GEDCOM-X doesn't have any widespread support.

However, I did check again for any updates today on progress in evolving from GEDCOM and did notice that Family Search are developing an API based on the GEDCOM-X specifications: familysearch.org/developers/docs/guides/about . Given that they (the Mormons) were instrumental in developing the original GEDCOM standard the heavy-weight support from FamilySearch may yet get vendors moving over to GEDCOM-X at some point in the future - certainly some work seems to still be going on in the background.

Terry
running webtrees 2.1.16 at mynorfolkancestors.net
on PHP 8.2, MySQL 5.7.

Please Log in or Create an account to join the conversation.

More
9 years 1 month ago #7 by Tel
Replied by Tel on topic Integration of gedcomx in webtrees

fisharebest wrote: I look at the GEDCOM-X project every now and then...

Some bits look interesting, but I see that for dates, it still says "Dates MUST be specified using the proleptic Gregorian calendar."

webtrees has many users of the Jewish, Arabic, Persian and French calendars. Much of my own data is in the Julian calendar.

Perhaps the author(s) of GEDCOM-X have simply dismissed calendar handling as "too hard"?


Surely, this is just an attempt (perhaps misguided) to steer the majority? And easily rectified. Are not all dates subject to a similar format at a basic data recording level comprising: Year - Month - Date (+ BC - that's Before Calendar - for negatives that count backwards from the point of adoption of a particular calendaring system). The distinction, I think, from a recording perpective of recognising a date vs a Calendar System?

Terry
running webtrees 2.1.16 at mynorfolkancestors.net
on PHP 8.2, MySQL 5.7.

Please Log in or Create an account to join the conversation.

More
9 years 1 month ago #8 by fisharebest
Replied by fisharebest on topic Integration of gedcomx in webtrees

And easily rectified


There are lots of problems with forcing everyone to use the proleptic gregorian calendar (or indeed any other calendar).

Firstly, there is a difference between precise and imprecise dates. If a census record shows someone was aged 26 in the 1871 census, then you might typically record the date of birth as 1850. (Even though it may be 1849, depending on the exact birthday). This "1850" carries an implicit degree of uncertainty. If you were forced to convert "1850" to another calendar, say the hebrew one, you'd have to pick a conversion based on some middle date, and you might come up with 5775 (or 5776 or 5774), which carries a different implicit uncertainty.

Secondly, some caledars (e.g. Gregorian, Julian) start a new day at midnight. Others (e.g. Arabic, Jewish) start at sunset. You cannot accurately convert dates without also knowing the time - and you may never know the time. If soemone was born on "11 Adar 5610", you wouldn't know whether to convert this to "22 February 1850" or "23 February 1850".

Thirdly, it prevents us from recording invalid information. In my tree, I have a parish register entry for "31 JUN 1740". Quite clearly wrong. The priest probably meant to write "1 JUL 1740". (Or maybe he meant 30 June, or 21 June, or something else entirely!).

It is good genealogical practice to record information as it was written in the sources. If my sources say "31 June 1740" or "11 Adar 5610", then I
want to record exactly this.

Greg Roach - greg@subaqua.co.uk - @fisharebest@phpc.social - fisharebest.webtrees.net

Please Log in or Create an account to join the conversation.

More
9 years 1 month ago - 9 years 1 month ago #9 by Tel
Replied by Tel on topic Integration of gedcomx in webtrees

fisharebest wrote:

And easily rectified


There are lots of problems with forcing everyone to use the proleptic gregorian calendar (or indeed any other calendar).<snip>


I don't disagree. What I meant was it is easily rectified by amending the GEDCOM-X specification. After all, GEDCOM 5.5 allows for the other calendar systems you mention. I don't know the % of GEDCOM files which currently use these alternate calendar systems but assume LDS will know with some degree of accuracy. I would be surprised if this particular aspect of the specification will be allowed to stand as it currently reads (ie. a stipulation to use the proleptic gregorian calendar).

As for imprecise dates, I think most genealogists accept there is a certain amount of approximation (eg. born c. 1850) until they can prove / estimate a more precise date. I would always record an invalid value in the source record and approximate in the date field e.g. 31 June 1850 becomes 30 June 1850 or simply c. June 1850. Recording the actual written text in the source record enables you to copy the date as written - most family history software now allows you to qualify dates with approximations (circa, approximately, estimated, month+year, quarter date, year only, etc.) or illegible original dates such as 31 ? 1850 where the month is eligible.

Terry
running webtrees 2.1.16 at mynorfolkancestors.net
on PHP 8.2, MySQL 5.7.
Last edit: 9 years 1 month ago by Tel.

Please Log in or Create an account to join the conversation.

  • bertkoor
  • Away
  • Platinum Member
  • Platinum Member
  • Greetings from Utrecht, Holland
More
9 years 1 month ago #10 by bertkoor
Replied by bertkoor on topic Integration of gedcomx in webtrees
Xml and Json don't nescessarily solve current problems.
For example look up what the "X" in Xml stands for ;-)
That implies a schema might not be obeyed.

stamboom.BertKoor.nl runs on webtrees v1.7.13

Please Log in or Create an account to join the conversation.

  • norwegian_sardines
  • Offline
  • Platinum Member
  • Platinum Member
More
9 years 1 month ago #11 by norwegian_sardines
Replied by norwegian_sardines on topic Integration of gedcomx in webtrees
@bertkoor,

You are correct. And if you read many of the discussions on the GEDCOM X or "Better GEDCOM" blogs (as well as the very old discussions in the 1990's for GEDCOM) they are having problems with "required" and "Should not Provide" statements as they relate to specified data.

Many of the designers are reluctant to require, for example, Name Part (SURN or GIVN) in their specification. Believing that the user/programmer will know when to use and not use these elements. This of course leave the inclusion of these fields open for interpretation in each applications internal schema.

In this example the GEDCOM standard does not require SURN or GIVN so most programs only parse the primary NAME tag using the // to denote surname, but in my world most of my relatives never had a surname and the applications have trouble dealing with this "anomaly". Yet the GEDCOM field is very useful indexing and should be required. I'd love to have geographic names, patronymic names, clan names and occupational names, all are supported in many of the new GEDCOM replacements but, they refuse to say that the field is required to be supported, rather leaving it up to application to decide if it is to be used or imported. The wording they use is "Should Not" or "Not Recommended", so a application programmer can interpret this as: "I don't understand the need for this, and I don't have to support this so I won't."

Likewise, as you state the open-end design of transfer allows mangling of the standard and therefore leaving data in places that they decide it makes more sense for them than the place that others think it should go.

Sorry for the rant!!!

Ken

Please Log in or Create an account to join the conversation.

  • darwtyman
  • Topic Author
  • Visitor
  • Visitor
9 years 1 month ago #12 by darwtyman
Replied by darwtyman on topic Integration of gedcomx in webtrees
First of all, thank you for the attention given, I see that this issue is too big for me because I don't have enough experience in Genealogy and Gedcom.

I see that there are problems with some details of this format such as date.

It is true that the format does not solve all problems, but I think that these formats (XML and JSON ) make our applications become more interoperable, but it is true that if companies do not implement properly the standards or format does not cover all needs, will always see incompatibilities.

I do not know how rigid is the team behind this project or if they want to impose this format to the community, I only read that they invite people to help in this projects www.gedcomx.org/Community.html .

And finally I copy and paste a piece of the project FAQ ( www.gedcomx.org/FAQ.html ):

Is GEDCOM X backwards-compatible? Can GEDCOM X be read by consumers of legacy GEDCOM?

No, a new parser is needed. But there is a lossless conversion from legacy GEDCOM to GEDCOM X. And there are open source libraries available for working with GEDCOM X to help ease the pain of migration.

Does GEDCOM X define a file format so I can save my data on my computer and work with it using my favorite applications?

Yes. And it's designed to address the major issues with legacy GEDCOM such as the lack of a well-defined source model, insufficient support for the proof standard, and no way to enclose multimedia files (e.g. images, audio, video, etc.).

What's up with the name "GEDCOM X"?

Well...

"GEDCOM X" denotes a clean break from "legacy" GEDCOM and clearly communicates a new revision that is different in scope and technology.
"GEDCOM X" doesn't imply a project-level versioning scheme, making it convenient as an "umbrella" name for sections that can each be revisioned independently.
The "X" is a loosely-coupled reference to "XML", which is a major technology being used to define the standard.
The "X" has a generally accepted reference to the 'x' in "next", implying the "next" generation of a genealogical tools and specifications.
The "X" has a precedent in the genealogical space, e.g. "Generation X".
The "X" has a precedent in the technology space, being used quite successfully to denote a new version or platform or system, e.g. "Apple OS X", "Droid X", "X11", and all over the place by the W3C.
The "X" is simple, brief, one-syllable, and easy to pronounce.


Now I leave to comment because as I say, I have insufficient level to discuss with you, but I'm going to follow this thread.

Please Log in or Create an account to join the conversation.

More
9 years 2 days ago - 9 years 2 days ago #13 by WGroleau
Replied by WGroleau on topic Integration of gedcomx in webtrees

current issues with GEDCOM are primarily the fault of software companies not following the standard

Indeed, even PAF's version sucks. However, some issues are with the GEDCOM data model. The last time I looked at the LDS-suggested XML (aka GEDCOM), it was merely an XML version of the same model. This sounds even worse.

"lossless conversion" is a lie if the target doesn't allow things (dates) in the source. And it is highly unlikely that their conversion supports all the extensions, much less all the violations.

--
Wes Groleau
UniGen.us/
Last edit: 9 years 2 days ago by WGroleau.

Please Log in or Create an account to join the conversation.

Powered by Kunena Forum
}