There are two points about the Gedcom model I think are important to point out and they both apply to a new genealogical model and a better Gedcom.

First, Gedcom is both a syntactic language and a semantic one. At the syntactic level Gedcom is a set of rules for constructing and arranging into a tree a collection of Gedcom lines. There is nothing in this language that specifies what the tags are, what the tags mean, what tags are required, what formats values should have and so on.

It is only at the semantic level that rules about tags, arrangements of tags, and values of lines mean anything. The Gedcom standards try to point this out by saying they primarily add "lineage linking semantics" to the Gedcom syntax.

As a syntax Gedcom is essentially isomorphic to XML as a general purpose language for structuring information. They are both representations of the same things; you can transform back and forth between Gedcom and XML formats pretty much at will. As old computer scientists like myself say, "it's just syntactic sugar."

Second point concerns whether Gedcom is a language for data interchange or a language for data storage and representation. If you read the Gedcom documents it is clear that the intention was the former. But if you look at how Gedcom has often been used it often includes the latter. A VERY important point lurking behind this issue is that if Gedcom is JUST a data transfer language, that data in a different format must be translated to Gedcom before a transfer, and translated from Gedcom to a third format after transfer. In almost all cases, and lamented by millions of genealogists around the world daily, both these translations are LOSSY operations. If Gedcom were the storage language at both ends of the transfer then no information would ever be lost. This is such an obvious point and screams you so insistently over the years, that at some point it pays to notice it and do something about it. As far as I know LifeLines and GeditCom are the only two programs that have listened.

There are lessons from both these points to learn from when thinking about the better Gedcom. First the underlying textual format in which model objects eventually are represented in must have the same general purpose syntax equivalent to that of Gedcom or XML; it could have either format. Personally I would recommend a new syntax because 1) Gedcom syntax at this point in time just has too bad of a connotation/taste to too many peoples' mouths; they would think the better Gedcom effort had really not done something very useful or significant; and 2) XML has TOO MANY WORDS, TOO MANY POINTY THINGS, and IS TOO DARNED HARD TO READ. You don't have to read them you say, because that's what computers are for. Baloney. And anyway, it's just syntactic sugar after all.

Tom Wetmore

Here is the contents of a file that I use in the DeadEnds program to check the validity of a Gedcom file against the 5.5 specification, which was the latest one to be officially sanctioned by the LDS. This file is the most succinct form I have found for showing all the allowed relationships between tags within 5.5. You can use this when you want to make a quick check of some fine point about the Gedcom rules when you don't want to open of the full document and go rooting around in it.


header_record: HEAD [SOUR [VERS NAME CORP DATA [DATE COPR]]
DEST DATE [TIME] SUBM SUBN FILE COPR GEDC [VERS FORM] CHAR [VERS] LANG PLAC [FORM] NOTE [CONT CONC]];

submission_record: SUBN [SUBM FAMF TEMP ANCE DESC ORDI RIN];

family_record: FAM [family_event [HUSB [AGE] WIFE [AGE]] HUSB WIFE CHIL NCHI SUBM
sealing source medialink note REFN [TYPE] RIN change];

individual_record: INDI [RESN name SEX individual_event attribute ordinance child_family spouse_family
SUBM association ALIA ANCI DESI source medialink note RFN AFN REFN [TYPE] RIN change];

multimedia_record: OBJE [FORM TITL note BLOB [CONT] OBJE REFN [TYPE] RIN change];

note_record: NOTE [CONC CONT source REFN [TYPE] RIN change];

repository_record: REPO [NAME address note REFN [TYPE] RIN change];

source_record: SOUR [DATA [EVEN [DATE PLAC] AGNC note] AUTH [CONT CONC] TITL [CONT CONC] ABBR
PUBL [CONT CONC] TEXT [CONT CONC] repository medialink note REFN [TYPE] RIN change];

submitter_record: SUBM [NAME address medialink LANG REFN RIN change];

address: ADDR [CONT ADR1 ADR2 CITY STAE POST CTRY] PHON;

association: ASSO [TYPE RELA note source];

change: CHAN [DATE [TIME] note];

child_family: FAMC [PEDI note];

event_detail: TYPE DATE place address AGE AGNC CAUS source medialink note;

name: NAME [NPFX GIVN NICK SPFX SURN NSFX source note];

family_event: (ANUL CENS DIV DIVF ENGA MARR MARB MARC MARL MARS EVEN) [event_detail];

note: NOTE [CONC CONT source];

place: PLAC [FORM source note];

attribute: (CAST DSCR EDUC IDNO NATI OCCU PROP RELI RESI SSN TITL NCHI NMR) [event_detail];

individual_event: indi_event1 indi_event2 indi_event3;

indi_event1: (BIRT CHR) [event_detail FAMC];

indi_event2: (DEAT BURI CREM BAPM BARM BASM BLES CHRA CONF FCOM ORDN NATU EMIG IMMI CENS PROB WILL GRAD RETI EVEN)
[event_detail];

indi_event3: ADOP [event_detail FAMC [ADOP]];

ordinance: ordinance1 ordinance2;

ordinance1: (BAPL CONL ENDL) [STAT DATE TEMP PLAC source note];

ordinance2: SLGC [STAT DATE TEMP PLAC FAMC source note];

sealing: SLGS [STAT DATE TEMP PLAC source note];

medialink: OBJE [FORM TITL FILE note];

source: source1 source2;

source1: SOUR [PAGE EVEN [ROLE] DATA [DATE TEXT [CONC CONT]] QUAY medialink note];

source2: SOUR [CONC CONT TEXT [CONC CONT] note];

repository: REPO [note CALN [MEDI]];

spouse_family: FAMS [note];

A common criticism of Gedcom is that it is a conclusion only language, an argument I have made for twenty years. One of the main reasons (I believe) the better Gedcom effort exists is to encompass more of the evidence aspects of the genealogy process into its new model.

That being said, let me take a brief devil's advocate position, and mention that there are some ways one can use current Gedcom to support the evidence model; certainly not as well as one would want, but we do live in a beggars can't be choosers world for genealogical standards right now.

Consider a Gedcom INDI record and all the event substructures within it. Let's say we're careful researchers and for every event we discover for someone we record the source of that event. So a basic INDI record might have someone's name and his or her BIRT and DEAT events and each of the two events has its own 2 SOUR line. Later you find another source that gives a birth for the same person. You add a second BIRT event to the same INDI record with its own 2 SOUR line. The main issue that arises now is choosing the "preferred" birth event. The best solution I have found to this problem, now hold your criticism for a moment, is to add a THIRD BIRT event with a 2 SOUR line that indicates that it is your own conclusion. You then make that third BIRT event physically first in the record (assuming your software is sane enough to use the physically first birth event in a record to be the one that is displayed in windows and shown in reports). Now you have an INDI record containing one conclusion BIRT event and two evidence BIRT events.

Admittedly there are problems with this approach. I suppose the main one is that most genealogical systems don't give you any say at all about the Gedcom that it will generate. But most programs do allow you to add more than one event of the same type to a person, and they might put them all in a Gedcom export file, so you could try this approach with your program and see.

Another problem that comes from the approach involves names. What if the evidence for the two BIRT events have slightly different names for the person. How do you choose a preferred name and how do you encode it in your Gedcom? Well, I'll say how I do it in LifeLines. I stick a 2 NAME line (note the level 2) inside the 1 BIRT events, using the (excellent in my opinion) convention that a person's name should often be an attribute of an event (the name the person had when the event occurred), but 5.5 Gedcom does not allow a 2 NAME line. This is not a problem for me with LifeLines since there is no barfing with new conventions. Without this addition to Gedcom you would probably do do things -- first put a NOTE in each BIRT saying what the name recorded with the event was, and you would put in multiple 1 NAME lines at the start of the INDI record, with the physically first 1 NAME line being the one you feel is the preferred name for display and reports.

Another problem with this approach, fairly serious in my opinion, is what happens when a user decides that some of those events in the INDI really happened to DIFFERENT people with the same name. Software could handle it, but it's pretty subtle, and I doubt any current software has tried to solve it this problem. For example, what would Gramps do if a user wanted to remove an event from one of the existing persons and create a new person with that event? Might work fine; I just don't know.

The final problem with this stems from the basic fact that in Gedcom all events must be iniside INDI records and don't stand on their own. In the better Gedcom (presumably) there will be event records.

Well, no, the real problem is that the "evidence records" are stuck inside the "conclusion records" (they're all part of one big INDI record), and therefore the "evidence records" have all lost their own identity and integrity.

A reason to point this out in the better Gedcom context is that better Gedcom could presumably decide to simplify its model by finding analogous short-cuts for double-dutying the same entties to represent conclusions and evidence at the same time. I don't recommend this, but I guess concensus could end up flowing in that direction.

It would be interesting if a Gramps user would explain how Gramps users have found ways to support evidence and conclusion within the Gramps context.

Tom Wetmore

You can read the entry here:

http://bettergedcom.blogspot.com/2010/12/bettergedcom-test1-ftm-to-tmg-place.html

I have been reading the GEDCOM Future Directions Document. On page 15 starts the description of the "Genealogical Information Model." It's kind of a kitchen-sink model; you get the idea the authors felt they couldn't let the GenTech Data Model outdo them!

But once you select some of the key records types, and after you go off on a lot of tangents trying to figure out what it all means, it seems to me that the core model is consistent with points we have discussed for Better GEDCOM. And since it IS a GEDCOM model, Louis will be pleased.

If you like pictures you can get an overview of the model starting on page 16. For any one planning to contribute to the Better GEDCOM model I think the model part of this document should be considered required reading.

A few comments.

The model has an Event record that can be used for multi-role events. The Event records don't point to their role players, but the role players point to the Events. Because the LDS created the model, of course they have to have special records for their LDS Ordinance events, which I find somewhat offensive, but so what.

The model still has the family record, but it is now called the Family/Couple record. Interestingly this record no longer points to the father/husband, mother/wife, children, as done by GEDCOM, but the father, mother and children Individual records do still point to the Family/Couple records. This is the same as GEDCOM except that the links are just now one-way.

But the model also has a Social Group record.

Simple attributes have been turned in big characteristic substructures, but that's okay.

The source model is interesting. There are three basic records in the source hierarchy, first Repository and Source, similar to GEDCOM. But then there is the Document record. This record represents specific information taken form a Source, so it's what we've been calling evidence. Note that all records that point to sources point to these Document records, so it is these Document records that serve the role of sources for all other records.

But that's not all about sources. The model also has a record called the Extracted Detail record. This is a record that holds very specific information that is extracted from a Document, given a fourth level to the sourcing hierarchy. The Extracted Detail records refer to the Document records they come from. Other records can refer to the Extracted Detail records, indirectly referring to a Document, thus Source, thus Repository.

Then there are a whole bunch of other record types that seem to be heading into gibberish land to me. It really looks like the authors were given free range to wander all over the place and they sure did. I think this was written at almost the same time the GenTech model was circulating and it seems this had a very unwelcome infulence. Frankly I think the author of this document just went a little nuts with all the power he temporarily possessed, and it's no wonder none of this stuff really made it to the light of day.

Now comes a VERY INTERESTING feature of the model. Event and Individual records can have "BasedOn" structures that are defined as follows:

"+0 BasedOn
+1 Ref=<Record#> /* Record of the same type */ {1:1}
When records which represent the same thing are merged, the original records and a history of how they were merged can be kept by: Merging the duplicate records into a new record, Keeping the old duplicate records, or Linking the new record to the duplicate records from which it was derived. This process, called “merging forward”, uses the BasedOn Link substructure links the old records to the new record."

Follow all that? It's pretty awkwardly stated but this is that link that I have in the DeadEnds model for allowing the building of evidence and conclusion trees of records. This is the first time (other than in the Assertion record of the GenTech model) have I seen this link, the one I find critical to implementing the genealogical process. I was rather pleased to find that. Note that the final statement in the quote they got wrong, it's the new records that point to the old ones, as it should be.

Enough for now.

Tom