Jump to content


Photo

GEDCOM 5.5.5

GEDCOM

  • Please log in to reply
20 replies to this topic

#1 BradleyinDC

BradleyinDC

    Advanced Member

  • Members
  • PipPipPip
  • 123 posts

Posted 02 October 2019 - 12:13 PM

Will RM 7 and 8 be compliant with GEDCOM 5.5.5? I had no idea this was in the works. Has anyone looked at it?

https://www.gedcom.org/gedcom.html



#2 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6256 posts

Posted 02 October 2019 - 04:10 PM

That was a surprise. It's a non-mainstream attempt to progress GEDCOM with laudable goals. However, no major developers are listed as having participated. So take-up by RM is hardly assured.

Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#3 BradleyinDC

BradleyinDC

    Advanced Member

  • Members
  • PipPipPip
  • 123 posts

Posted 02 October 2019 - 06:17 PM

That was a surprise. It's a non-mainstream attempt to progress GEDCOM with laudable goals. However, no major developers are listed as having participated. So take-up by RM is hardly assured.

Agreed, on all parts. But definitely laudable and should be adopted.



#4 Dick-TMG

Dick-TMG

    Advanced Member

  • Members
  • PipPipPip
  • 51 posts

Posted 03 October 2019 - 11:23 AM

I just downloaded  the new GEDCOM spec 5.5.5. I am a strong believer that we need to resolve the data exchange between software platforms, however this specification does not correct or enhance several items that I think are needed.

 

The quality or QUAY value is still just a single byte with values of 0 - 3. Totally inadequate for today's needs and certainly RM with the ESM values will not conform to this standard.

 

I also feel that the limit of 90 characters for the description of an event is also too small. It should be up around the 65000 limit that RM has in it's note field.

 

Just a couple of quick observations.



#5 RWells1938

RWells1938

    Advanced Member

  • Members
  • PipPipPip
  • 216 posts

Posted 04 October 2019 - 05:56 AM

I also took a look at the specs. I suspect there are several items that need corrections. But If you look at Tamura Jones, the editors, web site you will see that they did not make major changes from the last version and why they started this way

 

I think it is a great start as other starts to make a new GEDCOM have seemed to fail for lack of activity but this one is a great start.

 

Roger



#6 Trebor22

Trebor22

    Advanced Member

  • Members
  • PipPipPip
  • 192 posts

Posted 04 October 2019 - 06:32 AM

Any improvements in exporting / importing data to / from other programmes would be welcome. Sure this attempt at a 'better gedcom' is far from perfect, but perhaps a small step. I would have thought it has the advantage of being fairly easy to implement alongside existing gedcom so if implemented it would at least 'show willing' to let me transfer my data when I want to.

That said I won't be holding my breath and it would only be useful if other software adopts it as well -  so RM, please  be a leader on this one :-)



#7 BradleyinDC

BradleyinDC

    Advanced Member

  • Members
  • PipPipPip
  • 123 posts

Posted 04 October 2019 - 09:53 AM

I think it's a great way to jumpstart the stalled GEDCOM evolution. Yes, very deficient for updates that need to be incorporated, but great to make a statement for fixing some of the mistakes in the long-stalled standard.



#8 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3595 posts

Posted 04 October 2019 - 12:08 PM

A better GEDCOM would be great, but the deeper problem is radically different data models between different genealogy software - not just desktop software but also various Web services.

 

For example, ancestry.com and I think FTM don't have fact notes. FamilySearch doesn't have the concept of a source for a birth fact, and I think it doesn't really have the concept of fact sources at all. Rather, it has sources for a very few specific "concepts" such as "sources for the concept of a birth". It's very hard for me to see how a better GEDCOM will provide much help in resolving these kinds of problems.

 

Jerry



#9 Jim Byram

Jim Byram

    Advanced Member

  • Members
  • PipPipPip
  • 71 posts

Posted 05 October 2019 - 03:01 AM

Then  you've got to get your models straight. <g>

 

Ancestry has fact notes if the fact Description field is a fact note. The more recent versions of FTM have fact notes. The fact note tab just isn't enabled by default in the Options.

 

TMG's GenBridge technology provided complete access to all fields of the source and destination programs. With that, you could import all of the source program data that could be fit into the destination program. When Ancestry redesigned FTM, GenBridge was used to import TMG data and it worked fine for me. It had some bugs that some users encountered but those could have been fixed and never were.

 

The beauty of GenBridge was that the modules for each program could be adjusted until they covered all of the fields in each program's data model. And you could add new modules for additional programs. GenBridge could have been used to build a stand-alone universal genealogy database converter. Even then, there would be some data loss because of the differences in each program's data model.

 

The problem of GEDCOM (5.5, 5.5.1, 5.5.5) is that it's static and has no ability to be adjusted for the data models in different programs. There have been GEDCOM XML proposals with more universal designs to accommodate different database models.



#10 Trebor22

Trebor22

    Advanced Member

  • Members
  • PipPipPip
  • 192 posts

Posted 05 October 2019 - 06:37 AM

I do agree we need a much much better solution than just a minor gedcom update!!

Perhaps the 'elephant in the room' is, would we be happy if RM8 does not include any gedcom export at all? I don't think I would be and my previous comment was really intended as a friendly reminder to RM that data transfer is important to me and I expect to others, in truth I would be surprised if 5.5.5 ever appears in RM.



#11 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3595 posts

Posted 05 October 2019 - 06:40 AM

Ancestry has fact notes if the fact Description field is a fact note. The more recent versions of FTM have fact notes. The fact note tab just isn't enabled by default in the Options.

 

 

As is frequently the case in such situations, the devil is in the details. In the case of ancestry, if the Description field is a fact note, then where is the fact note field for the same fact since ancestry has a Description field but not a fact note field? RM has both the Description field and a fact note. In the case of TreeShare, RM puts the RM Description field in the ancestry Description field and it puts the fact note in Other Sources. That's not an ideal solution, but it's the best RM can do since ancestry doesn't have a fact note field. 

 

Well, ancestry introduced a LifeStory field for each fact in 2015. The LifeStory field would seem to be an obvious place for TreeShare to store RM's fact notes in ancestry. However, the TreeShare API apparently does not support LifeStory.

 

There are other problems. For example, ancestry (probably the TreeShare API) loses both RM's formatting flags such as <i>.... </i> for italics and carriage returns for making paragraphs. So such data is gone if the data makes a round trip from RM to ancestry and back.

 

The round trip is the real test - data goes from system X to system Y and back to system X. The data is then the same as it was originally (SUCCESS!) or it's not the same as it was originally (FAILURE!). I had never heard of GenBridge, but it sounds like a very interesting concept. But better still would be a much richer and a much more uniform data model. A least common denominator data model would be of little value if it were not rich enough.

 

Jerry



#12 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3595 posts

Posted 05 October 2019 - 06:42 AM

I do agree we need a much much better solution than just a minor gedcom update!!

Perhaps the 'elephant in the room' is, would we be happy if RM8 does not include any gedcom export at all? I don't think I would be and my previous comment was really intended as a friendly reminder to RM that data transfer is important to me and I expect to others, in truth I would be surprised if 5.5.5 ever appears in RM.

 

My modest hope for RM8 is that it might be able to export GEDCOM and import the same GEDCOM back into itself without any data loss. RM7 does not pass this rather basic test.

 

Jerry



#13 Trebor22

Trebor22

    Advanced Member

  • Members
  • PipPipPip
  • 192 posts

Posted 05 October 2019 - 07:12 AM

 

My modest hope for RM8 is that it might be able to export GEDCOM and import the same GEDCOM back into itself without any data loss.

 

Jerry

I too would think that a welcome improvement :-) 



#14 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 213 posts

Posted 05 October 2019 - 08:22 AM

I see two distinct issues with GEDCOM interoperability and data transfer.

1). Jerry points this out very well. Each genealogy program uses different database structures. These different database designs do not have the same fields or the same field definitions.

2). Many GEDCOM tags and concepts are not supported in the most common genealogy programs. For example: GEDCOM does not have a “Description” field. For example: None of the most common programs support “Fact/Event” TYPE tags and therefore don’t generate correct custom facts or allow subfact values.

XML and GEDCOM 6 has some advantages regarding the allowing for the exporting of all data from any given database structure but has one major flaw. The import of the data still requires a data definition layer that the receiving program can understand and use to map data to the receiving database. This requires an open architecture and knowledge of the data use of the receiving program. Pure data transfer is not always a “slam dunk”. This is the same thing you will find when using (as noted) when using GenBridge.

#15 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6256 posts

Posted 05 October 2019 - 01:27 PM

 

My modest hope for RM8 is that it might be able to export GEDCOM and import the same GEDCOM back into itself without any data loss. RM7 does not pass this rather basic test.

 

Jerry

 

My more (or less?) modest hope is that RM abandons GEDCOM as the medium through which it transfers data between its format of databases and does it directly using SQLite. No need to bend itself out of shape going through translation to/from another language and data structure.  


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#16 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3595 posts

Posted 05 October 2019 - 02:01 PM

 

My more (or less?) modest hope is that RM abandons GEDCOM as the medium through which it transfers data between its format of databases and does it directly using SQLite. No need to bend itself out of shape going through translation to/from another language and data structure.  

 

I agree. Also, the idea of transforming data from one RM database to another via SQLite and a lossless GEDCOM transfer between RM databases are not mutually exclusive. RM needs to be able to do it one way or they other. I wouldn't expect both. I hope for at least one.

 

Jerry



#17 BradleyinDC

BradleyinDC

    Advanced Member

  • Members
  • PipPipPip
  • 123 posts

Posted 05 October 2019 - 03:21 PM

would we be happy if RM8 does not include any gedcom export at all?

RM has to be able to import and export a GEDCOM



#18 KFN

KFN

    Advanced Member

  • Members
  • PipPipPip
  • 213 posts

Posted 05 October 2019 - 04:13 PM

My more (or less?) modest hope is that RM abandons GEDCOM as the medium through which it transfers data between its format of databases and does it directly using SQLite. No need to bend itself out of shape going through translation to/from another language and data structure.


Tom, without GEDCOM or some other common interface how would other programs import RM data? The RM SQLite database is NOT available to users on remote platforms such as the internet or non-linked or non-networked computers. It would also require programs that already use SQL to create intermediary formats to do the import. RM would have the same issues when it try’s to import other program’s data via SQL.

I just finished a project that uses SQL as the only interface between to disparate databases that were based on different DB-engines to transfer data in one direction from one to the other and it required a lot of thought and a little data manipulation to get the right data out and into the right place. Some fields in the sending DB contained two pieces of data that the receiver needed to have split. This was particularly troublesome.

#19 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6256 posts

Posted 05 October 2019 - 04:14 PM

the idea of transforming data from one RM database to another via SQLite and a lossless GEDCOM transfer between RM databases are not mutually exclusive.

Agreed. I would say that doing so via GEDCOM seems to me to be from the DOS era. At some point in the Windows GUI era, drag'n'drop could trigger a process more sophisticated than simply popping something into the clipboard and pasting it. I regard RM's process of a behind-the-scenes GEDCOM export-import as a Kluge from DOS and for it to be lossless is probably infeasible, if not impossible.


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.


#20 TomH

TomH

    Advanced Member

  • Members
  • PipPipPip
  • 6256 posts

Posted 05 October 2019 - 04:18 PM

Tom, without GEDCOM or some other common interface how would other programs import RM data?

I am talking about drag'n'drop between RM databases, not data transfer between distant or unconnected RM databases or between RM and some other system. For that, an intermediary format is required and GEDCOM is the current mostly-common denominator. 


Tom user of RM7550 FTM2017 Ancestry.ca FamilySearch.org FindMyPast.com
SQLite_Tools_For_Roots_Magic_in_PR_Celti wiki, exploiting the database in special ways >>> RMtrix-tiny.png app, a bundle of RootsMagic utilities.