Question Get rid of GEDCOM's limitations

Well my subject is quite clear.

I've tried many genealogical softwares, and it seems lot of them are always based around GEDCOM (and so many interpretations) !

Am I the only one who find this "strange", "incomprehensible" and even more entirely "STUPID" ?

As you can read on Wikipedia GEDCOM "is a de facto open file format specification to store genealogical data, and import or export it between compatible genealogy software.".
But don't forget who create this "data model", mainly for their needs !

Genealogy is not restricted to the limited needs of the LDS Church !

If you really want a software for Genealogy, you should consider GEDCOM as a "option" (plugin, module or extension) to import and export, not like the main structure of your software.

Today, writing an genealogical software with GEDCOM as main structure, it's like building a house starting with the roof.

Don't you think it's really time a have a software for Genealogists' needs first with more feature, and considering import and export in GEDCOM as is should be, a simple feature ? (for webtrees 3)
 

first: GEDCOM has gone way beyond the original needs of the LDS-Church. The upcoming standard 7.x is in fact no longer based on their needs.

second: GEDCOM had become the nowadays international standard for every serious genealogist around the world. It has the flexibility for almost every social culture and has only a few limitations (which hopefully will be reduced with the upcoming new standard).

third: the main purpose of GEDCOM is to have a standardized and open data exchange format. No propriertary software can forfill that need, unless it follows this standard. We can see that problem on allmost every modern other software. 

So NO, I don't think your idea is good. I even think it's a really bad idea, it would throw us back. 

What parts of GEDCOM have restricted your use of any software program to support your genealogy needs?

What features are you looking for that are not supported by the software programs you have tried? What features are needed in webtrees that you don’t see?

I ask this because you indicate a desire to move away from GEDCOM, but offer no examples or reason for you dismay, and more so no solutions!

I’ve done genealogy for myself for over 40 years, volunteered in a non-LDS genealogy center in that time period, helped others research their family tree and even got paid for my efforts. Ive used multiple programs over those years, and participate in forums relating to genealogy and GEDCOM currently and advise some of their developers!

Please provide constructive examples and solutions to any issues you have!

Sorry, but this time, I'll answer in french (the English version follows) :

Merci pour vos réponses, mais comme je le craignais, webtrees reste et restera trop attaché aux spécifications GEDCOM plutôt qu'aux besoins de recherches généalogiques.

Car en restant attaché à un modèle qui n'est qu'un protocole d'échange de données ferment beaucoup trop de perspectives d'évolutions comme celle mentionnée ici sur github . Ce simple exemple donné sur github reste pour moi un frein à ma volonté d'aller plus loin avec Webtrees.

Ce qui me permet de classer webtrees comme un simple visualiseur et éditeur de fichier GEDCOM et non comme une solution de recherche généalogique.

Je continuerai à suivre l'évolution de webtrees qui reste une très bonne application (la meilleure en version web de toutes celles que j'ai pu tester) .

En attendant, je poursuis ma généalogie avec une autre solution applicative qui n'est (pas encore) en version en ligne mais locale. (Donc, ne supprimez pas mon compte trop vite )

Merci aux membres de l'équipe webtrees et à sa communauté de m'avoir bien accueilli aidé sur plusieurs points et surtout supporté.

Quoi qu'il en soit, longue vie à Webtrees.

English*

Thanks for your answers, but as I feared, webtrees remains and will remain too attached to GEDCOM specifications rather than to genealogical research needs.

Because remaining attached to a model that is only a data exchange protocol closes far too many prospects for evolutions like the one mentioned here on github . This simple example given on github remains for me a brake on my desire to go further with Webtrees.

This allows me to classify webtrees as a simple GEDCOM file viewer and editor, and not as a genealogical research solution.

I'll continue to follow the evolution of Webtrees, which remains a very good application (IMHO : the best web version of all those I've tested).

In the meantime, I'm continuing my genealogy with another application solution which is not (yet) in an online version, but local. (So don't delete my account too quickly )

I'd like to thank the webtrees team and its community for welcoming me, helping me on several points and, above all, supporting me.

Whatever the case, long life to Webtrees

--
Fabrice

* Since I used it this time, I prefer to mention it: Translated with DeepL.com (free version)

 

fdejaigher wrote:

Because remaining attached to a model that is only a data exchange protocol closes far too many prospects for evolutions like the one mentioned here on github . This simple example given on github remains for me a brake on my desire to go further with Webtrees.

This allows me to classify webtrees as a simple GEDCOM file viewer and editor, and not as a genealogical research solution.
 

Dear Fabrice,
Don't be so quick to jump to conclusions. I often experience same situation you mentioned on github and I have no trouble handling it using webtrees.

To summarize your failure case, you have one published document (for example, a marriage record) that includes information about more than one Individual (bride, groom, maybe also parents, etc) and for each of those Individuals, there is information about multiple Facts and Events (for example, birth date, birthplace, occupation, mother's maiden name, etc).

In my tree, I follow the same convention you described, where the source is a collection of marriage records (e.g., "Registre des mariages de Lille [1948]"), and the specific marriage record (e.g., "Acte de mariage de DUPONT X MARCHAND") is a source citation. As a result, my tree has several sources (such as a census) cited by thousands of Individuals.  Years ago, under webtrees 1.7.x, this created some problems where I had trouble opening the most popular Sources pages due to resource limits...

It seems that some other webtrees users have instead chosen a different interpretation, where each specific marriage record is a separate source, and each source is cited by only a small number of Individuals and Families.  If you did that then your problem of trying to use pointers to objects instead of duplicating those objects would not exist.

Nevertheless, I don't feel like I have a problem that needs fixing.  From my earlier career I am familiar with the methods for adding footnotes and references to scholarly publications, and thus remind you of the Latin phrases "ibid" and "op cit."  Therefore, when I encounter the situation described above, i.e., a marriage document containing lots information about multiple people, I start by attaching the full source citation to the marriage event, including a stable URL in the "citation details" field and the text I copied from the document in the "text" field. If the same document also provides useful information about other Facts and Events for the same people, I simply add separate citation to the same source, without filling in all the details -- like "op cit.".  In my experience, using webtrees and printing various reports, this makes the role of the marriage document perfectly clear.

As an alternative, I would also like to point out that if you really want to use pointers and objects, you can store the information contained in the marriage document as a shared note, and link it to all the Facts and Events.

@fdejaigher:

Thanks for your answers, but as I feared, webtrees remains and will remain too attached to GEDCOM specifications rather than to genealogical research needs.

Because remaining attached to a model that is only a data exchange protocol closes far too many prospects for evolutions like the one mentioned  here on github . This simple example given on github remains for me a brake on my desire to go further with Webtrees.

Yes, GEDCOM is not very well “normalized”. This concept has been discussed in the GEDCOM GitHub design forum, and will in the future probably be realized.

HOWEVER, if the condition you described in your link happens regularly, you could write a module similar to the “Census Module” that inputs multiple source_citations based on a single census source record. The “Census Module” takes as input a single census record based on year and country, asks for the individuals that are named in the census, and creates a new CENS tag with source_citation attached to the Source for each participant, and a NOTE record with a table of information from the census document. You can also attach an image of the census page!

This new module that you would write (or have written for you) would do for you what you want without changing anything in GEDCOM or the way webtrees uses GEDCOM internally. This would also not cause issues with other users who desire to use multiple programs that support GEDCOM preventing the dreaded user lock-in!

I'd like to come out from the other side of this question. Full GEDCOM support is essential. Not sure what is the bus factor for webtrees, but I believe it is not too distant from 1 (see  github.com/fisharebest/webtrees/graphs/contributors )

Which means that most of this is on Greg's shoulders and may easily crash down if something prevents him from contributing to webtrees. I want my data to be easy to transfer to some other genealogy program without data loss. GEDCOM provides that capability, and I do not know any other data format that is supported by all the genealogy programs.

That to say, if the ability to export data via GEDCOM is lost, I'd probably stop using webtrees at that point, as I don't want my data to become hostage to vendor-specific data format. The fact that I can easily migrate out of webtrees was one of the factors why I chose to use webtrees (and PhpGedView) in the first place.
 

@fdejaigher:
You say: "In the meantime, I'm continuing my genealogy with another application solution which is not (yet) in an online version, but local. (So don't delete my account too quickly )

"What is the desktop or local software you use ? 

OlivierM wrote:

"In the meantime, I'm continuing my genealogy with another application solution which is not (yet) in an online version, but local. (So don't delete my account too quickly )
"Quelle application locale utilisez-vous qui répond à vos besoins ?

Can we assume that you are/were the user called "fdejaigher" and "chtiland" in github.
Enjoy getting your genealogy off the program you are now using without the aid of GEDCOM!

No. i am not! I was curious to know what is the local desktop program he (fdejaigher)  uses, since he seems so happy with it.
As far as I am concerned, I have no problem with gedcom based programs, whatsoever, and I am a very happy and intensive user of Gedcom to switch between my programs (webtrees being one of them)

Hello !

Can we assume that you are/were the user called "fdejaigher" and "chtiland" in github.

I don't think there a user called "fdejaigher" on github, but I'm the user called  "chtiland" on github.

Enjoy getting your genealogy off the program you are now using without the aid of GEDCOM!

I'm still using Gramps, and I never use GEDCOM files(1) so why should I care about any "aid of GEDCOM protocol / model" ?
One or two years ago I tried to work on export and import of GEDCOM files from many software programs (Heredis, Ancestris, Gramps, TNG, ELIE, Family Tree, Webtrees, ...)
For each one with the same set of data I never get the same GEDCOM file, and when importing results was so awful due to interpretations of GEDCOM for each software (even when exporting and importing a GEDCOM file of the same tree on the same software)  !

Sometime, exporting and importing GEDCOM files it's like making a photocopy of photocopy of photocopy of... !

Most of the time, these problems are due to
  - interpretations of each about events vs facts
  - Allowing or not creation of personal type of EVENT -> GEDCOM : Can be done with tag EVEN followed by the name of this specific event.
  - Allowing or not creation of personal type of facts (ATTRIBUTE) -> GEDCOM : through tag FACT
  - Allowing dates on facts, attributes of a person -> GEDCOM : Yes of course, and even for physical description (this particular tag (DSCR) is "multi lines"
  - Allowing citation (source) on notes -> GEDCOM : Yes !
  - Allowing notes on family, individual, media, repository, source, citation, submitter, places -> GEDCOM : Yes, and more, like on links between individuals
  - Interpretation of places vs addresses(2) (some software allows creation of <<ADDRESS_STRUCTURE>> in <<INDIVIDUAL_ATTRIBUTE_STRUCTURE>> : GEDCOM : No, this must be stored in an attribute (RESI) of individual record)
  - Missing information in HEAD, like PLAC:FORM (not set on export or not read on import)

The use of specifics tags (prefixed by an underscore "_") in many software, everyone knows, but when importing, nothing is proposed how to use them (push in a note, create an event (EVEN) or an attribute (FACT) etc.).

If you ask (on some forums or socials network groups) : "Should an occupation be considered as an event or an attribute ?" You should have many answers from users but you'll probably see that some users would have the same answer because they are using the same genealogical software !
In fact I think with a few questions like this to one user, you will be able to "guess" which software he uses for it's genealogy.

The more I read GEDCOM, the more I realise that it's easy to have different interpretations. Sometimes I find it easier to exchange CSV files than to have to take data from a GEDCOM.

Have a nice day.

(1) I don't import GEDCOM, I use them (opening in Ancestris or any GEDCOM reader, but this one is really good), and use them to complete my data by check each information. It may be time-consuming, but it's certainly less time-consuming than having to recover an error that you realise you've made much later.
(2) IMHO about addresses vs places in events records :
  * Addresses (ADDR) for contemporaries purposes as a kind of address book for people you can have contact with about your genealogy researches.
  * Places (PLAC) for Historical and Geographical purposes

fdejaigher:  
1) You should care about the GEDCOM model because if the genealogy program you are using goes bust you can move your data to another program
2) All GEDCOM facts have the ability to add addresses, not just the RESI fact!
3) As we move forward in GEDCOM design the difference between Attributes and Events will go away.  
4) GEDCOM v7.0 requires all software that creates a none standard tag (with a preceding _) to have a definition!

The differences between software and how they use GEDCOM is the fault of the software NOT GEDCOM.  GEDCOM was designed so programs could interchange with a central database based on the same protocol, so following that protocol is a must! This is why the initial premise you introduced about not using GEDCOM as the basis of an application is ridiculous unless you are happy to stay with one single program forever AND when that program goes bust you are happy to lose all you work!

Ive been doing genealogy for 40 or so years, actually worked for a company the designed and created application interface protocols.  I’ve use 10 or so different genealogy programs and seen half of them go bust and most of the others make it hard to leave them once someone starts using the program due to their lack of GEDCOM compliance.  My hope is that GEDCOM V7.1 and beyond will (if followed) will make transfer easier and more reliable!  My hope is that the designs proposed for v7.1 will make PLAC and sourcing better if followed!