TMG-L Archives

Archiver > TMG > 2002-02 > 1012934730


From: "Richard Damon" <>
Subject: RE: [TMG] Long discourse on GEDCOM and witness data
Date: Tue, 5 Feb 2002 13:45:30 -0500
In-Reply-To: <5.1.0.14.2.20020205062443.0598c830@mail.hwrd1.md.home.com>


This thread has been going on for a long time now and there are obviously
multiple points of view.

I think we can agree that the user community wants, a technology to transfer
genealogical data from one program/user to another. The existing standard is
GEDCOM. GEDCOM, since it is lineage based, can not express the fullness of
expression that a dataset in TMG can.

It has been brought up that if other people would adopt GenBridge then this
problem will go away. I would not hold my breath on this happening. I assume
that Bob has not offered it "free to everyone", he has put real effort into
it and it is a valuable commodity. I doubt many other genealogy packages
really care how well they can get data from TMG, they are not that apt to
get users switching. Utility packages tend to be lower volume and very cost
sensitive, many are free. I also have some questions on how well GenBridge
would be able to import the event linked mode TMG file into a lineage linked
model program, it would require the program solve the conversion question
with less opportunity for input then if TMG did the conversion under
direction of the user of that data set.

There is also been talk of the GENTECH model, or revisions of GEDCOM, this
may be good when it arrives, but our needs are more immediate.

If we are going to export to GEDCOM what can we do:

1) We can definitely output the basic BDMB information, as this is what
GEDCOM is designed for.

2) We can massage our data to fit the lineage model

3) We can invent our own extensions to allow the event based model to be
expressed. This may be of use to get data to utilities which are updated or
written to these extensions, but would not help getting to most programs.

I think the second option is where we can get the biggest bang for our
effort, if our needs are not meet by the first.

We do have the option to do the massaging of the data by hand, but that
greatly increases the effort of data entry, and makes us loose many of the
advantages of the event driven model. This would be done by things link not
using witnesses to tie people in a census together or adding GEDCOM export
tags to generate the information.

I would much prefer if the program could do these operations, and I think
with a little effort it can be made to do so. As I have thought about it,
there needs to be a little more information in each role to support good
output.

I would like to define a little terminology to describe this procedure:

Events have 1 or 2 principals (as they do now) plus an unlimited number of
addition participants (currently called witnesses). Every person connected
to an event has a role, if not otherwise specified principals have the role
Principal, and the other participants have the role Witness. Each role would
have a flag to indicate if the person in that role is a Key Participant.
Every event-type would have a GEDCOM compatibility rating used below.

GEDCOM output could be set to several different levels.

Basic output level would be similar to what we have now, but any tags not
marked compatible with basic GEDCOM would be excluded. These tags would be
any tag which connect two or more people other then by familial
relationship. Tags would only be generated for the principals as they are
now.

Intermediate output level would output a tag for every Key Participant. Thus
a census tag could exist once in TMG and generate multiple tags in GEDCOM.
The event-type definition would need to indicate if the tag should be put
into a family if it exists, or possible create a family (like a marriage
group tag). Otherwise tags would not be linked together as GEDCOM has no
support for this. An enhancement might be to allow specifying differing
GEDCOM output tags for each role. Non-key participants (like Witnesses)
would be ignored.

Advanced output level (if implemented) would output a tag for every
participant (for non-key participants it would likely be just a note) with a
note attached with a sentence built like a report.

I know that this won't be in 5.0 but it is a possible goal to reach for.
What might be possible in 5.0 is relabeling the witness box to read
additional participants.

Just my thoughts,

Richard Damon


This thread: