TMG-L Archives

Archiver > TMG > 2002-02 > 1012709180


From: Lee Hoffman <>
Subject: Re: [TMG] Long discourse on GEDCOM and witness data
Date: Sat, 02 Feb 2002 23:06:20 -0500
References: <4.2.2.20020202173803.01350e68@pop3.norton.antivirus><3C5C47B0.1830.B27A9C@localhost>
In-Reply-To: <3C5CA1EE.1391.F22174@localhost>


F. Langset wrote:
---clipped---
>interpreted, said someone). I don't like the approach of imposing a
>specific structure on my data to accommodate other peoples needs more
>than my needs. So the question is: Do I have to?

No.

>And is that because
>of some problems of more philosophical concern or are there actually
>real insoluble problems? Although I haven't read every message in
>this thread down to the last punctuation, I cannot see that anybody
>has shown anything that suggests real problems (terms like lost data
>integrity, form of corruption, etc. etc. don't scare me unqualified
>into a wheelchair ;) )

The question that began this thread was how one could transfer data (e.g.,
Witnesses) from TMG via a protocol that does not accommodate that data to
another program that also does not accommodate that data. The argument is
that since TMG cannot transfer Witnesses, then it results in lost
data. However, since the means of transfer nor the destination can
accommodate Witnesses, then the question is who is at fault -- TMG, GEDCOM,
or the destination program.

TMG does provide certain capabilities (e.g., Witnesses) that neither GEDCOM
nor other programs have. On the other hand, if the user intends to
transfer data (including Witnesses) to other programs, then the user must
realize that some TMG capabilities should not be used until GEDCOM (or its
equivalent) and the other program support that or similar
capabilities. Thus Witnesses would not be entered in the TMG Witness area,
but in the Memo field.

On the other hand, if one wishes to use the full capabilities of TMG, they
may do so realizing that some data will not transfer via GEDCOM. Thus they
should determine some other means to either transfer the data. It has been
suggested that one may use GEDCOM and supplement it with a narrative report
which will show all the data.

>I can agree on this one, but, as I see it, there is a limited set of
>possible, still usable data models. And TMG has (should have!)
>selected a one of them. That is the GEDCOM data model I'm talking
>about. I just don't hope that is the same one that TMG is using
>internally because that one cannot be implemented in GEDCOM (at least
>that is the message of this thread).

But, as I said, GEDCOM is _NOT_ a data model. It is a conglomeration of
requests by users and vendors to transfer data from one program to
another. Primarily designed for use by the LDS Church, it has been revised
and added to without any real consideration as to the total result for the
_entire_ genealogical community. That is, there is no data model on which
GEDCOM is based.

The LDS Church has since created a data model called Futureview (or
something like that, I forget the details right now). It has many
similarities to the GENTECH data model although there are also many
differences. At the meeting where they announced no more updates to
GEDCOM, they also essentially sounded the death knoll for their data
model. I suspect that they will continue to use the basics of their data
model in developing the follow-on to GEDCOM that will be designed _only_
for use by the LDS Church.


----------
Lee Hoffman/KY
E-mail:
TMG Tips: <http://www.tmgtips.com>;
My website: <http://www.tmgtips.com/lhoffman>;
--------------
A user of the best genealogy program, The Master Genealogist (TMG)


This thread: