TMG-L Archives

Archiver > TMG > 2002-02 > 1013815575


From: Wade Oram <>
Subject: Re: [TMG] InterGED/Event GEDCOM
Date: Fri, 15 Feb 2002 23:26:15 +0000
References: <3C6D0E1E.4138.AA08DA@localhost>
In-Reply-To: <3C6D0E1E.4138.AA08DA@localhost>


In message <>, Ed Dunn <>
writes
>Way back in 1994 Commsoft (UFT) developed what was originally called
>InterGED, and later called Event GEDCOM 1.1. Roots IV (and later UFT)
>allowed for "nonstandard" GEDCOM tags for events, roles, sources, etc.
>Virtually all data could be exported from the UFT program, including
>sentence templates and even custom events, but, of course, the only
>program that was designed to import all of it was another UFT program.
>
>As I see it, that wasn't the fault of Commsoft, but the fault of its
>competitors, who could have developed their software to reject or to
>import and direct the incoming data to the most appropriate place. If
>the integrity of the data had been somehow *corrupted* when imported,
>then the importing program would have been at fault, not the exporting
>software. To claim that no adequate exporting function can be
>developed because someone who receives it might misunderstand what was
>intended by the original input in the exporting program, or misdirect
>it, is not a valid argument, in my opinion. That's trying to *control*
>what someone else does with a program's output.

I don't think that anyone has made this claim. Certainly no one has said
that no exporting function can be developed - just that it can not be
done by one company alone - witness the InterGED/Event GEDCOM example
that you quoted. What has been said - quite correctly - is that GEDCOM
is not an adequate method for transferring the rich data held within
TMG. No one company is going to be able to introduce a new standard to
information interchange on their own. In fact, Wholly Genes have done as
much as they are able to allow others to import TMG data. They support
all of the standard aspects of GEDCOM, they have published their own
database structure and they have made the GedBridge technology available
to anyone that wishes to use it. The fact that no other company has
picked up on any method other than GEDCOM has little to do with Wholly
Genes.

The danger that was pointed out is that if you try to extend the use of
a standard (in this case GEDCOM) beyond what it was intended to do, then
you significantly increase the risk of the information being
misinterpreted and misrepresented in the receiving programs. Even with
the best will in the world, using GEDCOM, you will lose the ability to
see, for example, how many people were present at an event. This is a
corruption that occurs when generating the GEDCOM - not when
interpreting it. If in addition you add elements of the export that are
not directly under the users control - such as the automatic note
generation that has been proposed elsewhere - then you risk putting a
slant on the data that you can export that was not intended by the
original user. This is another corruption that occurs at the export
stage - not the import stage.

If a system for exporting, in this case witness data, were to be
developed, then as we have seen in other threads, there is more than one
way of doing it and no one way would suit all situations - so which do
you choose? In any event both of the methods discussed have a serious
problem - whilst they can be used to identify that a person was a
witness to, say, the birth on John Smith on 12 August 1762, they will
not identify which of the multiple John Smiths born on the 12 August
1762 in the data set is the correct one. It is admittedly quite unlikely
that I would have two with the same name born on the same day - but it
is not impossible. It is 'possible' to get around this by inventing
reference numbers for people who have events that were witnessed by
other people and then quoting this reference number in the invented
witness tag/note but this invention could be considered a form of
corruption in itself because it is impossible to guarantee that your
invented reference numbers will not interfere with the reference number
system used by the original TMG user or even that of the person
receiving the data.

If it were to be done, then to do it properly, I would imagine that you
would have to dramatically extend the tag definitions to define how the
'pseudo' tag for the witness data should be exported. This would likely
involve yet another sentence definition which in turn would mean that
you would have to provide a means of overriding the default sentence for
individual tags - possibly even individual witnesses to tags. As soon as
you start thinking like this, the whole thing starts getting very messy
and complicated and - worst of all - it complicates basic operations -
such as custom tag creation - with no real advantage for the majority of
users for the majority of the time.

But even if you did manage to export witness data to GEDCOM in an
acceptable form - what are you going to do about the research logs and
the flags and all of the other pieces of data that make up a data set.

Whilst I must admit, that I would like to be able to get more of the
witness data exported from TMG, I must conclude that I don't think that
this is necessarily best done by TMG itself. I must also concede that
the system that I would *need* for my intended purposes would be
entirely inadequate for the purposes of others. The converse is equally
true.


--
Wade T. Oram


This thread: