TMG-L Archives

Archiver > TMG > 2002-02 > 1012676986


From: "F. Langset" <>
Subject: Re: [TMG] Long discourse on GEDCOM and witness data
Date: Sat, 2 Feb 2002 20:10:24 +0100
References: <5.1.0.14.0.20020202022259.00a0d590@pop.sprynet.com>
In-Reply-To: <5.1.0.14.2.20020202071024.0d30fdb0@mail.hwrd1.md.home.com>


-----
Ref: Bob Velke, 2 Feb 2002 9:57, "Re: [TMG] Long discourse on GEDCOM
":
-----

> >I do *not* want to create superfluous Biography tags for every event
> >with witnesses.
>
> It isn't superfluous. It is a different kind of data. And while you
> recognize that that's what's necessary to transfer it with GEDCOM, you
> insist that it should be created ... but not by you <g>. I think
> that's really the only point on which we disagree.
>

Hi Darell A Martin and Bob Velke, and hi list,

I hope this is not regarded as an undue interference in your
discussion.

Question (rhetorical): Assuming the eventually new standard, if it
appears, will not match TMG's data model 100%, how do I use TMG to
day in order to be able to use the new transfer standard when it
appears? What tags do I need to create? How do I structure my data?
And it must not conflict with me using GEDCOM until then (might be
until forever ;) ). Or do you suggest that I take the work the day
the new standard eventually appears?

Obviously, well from my point of view, this isn't the way to solve
the problem. TMG must be able to use the current transfer standard
_as_it_is_ and say _as_much_as_it_can_ through it (alteration of
the standard is another issue). The disagreement can be on what TMG
can say (infer) from the specific data entered by the user into TMG,
and how to say it, not on wether it should say it at all in GEDCOM. I
simply cannot see that it is _wrong_ that TMG should 'look' at a
baptism tag and see that I was connected to that tag as a witness and
say so in a GEDCOM-file. It _can_ be said in a wrong way, but that
must not disregard us (TMG) from saying it the right way (if TMG can
do that in a way that ensures that no invalid data is produced).

In my opinion TMG must itself convert the data between its own data
model and the GEDCOM data model, retaining data integrity within the
GEDCOM file and, as far as the different models and the approach one
uses allow, between TMG and GEDCOM (through constraints put on the
user if needed, but I think they can be more relaxed than today's TMG
enforces). There is no need to make an exact copy of the TMG data
_model_ in the gedcom data model, and we should not need to create a
GEDCOM-like data model in the TMG data model (as suggested in the
above citation) in order to be able to transfer what we need via
GEDCOM, because then TMG could make a near exact copy. We must not
let the holes in GEDCOM reflect into TMG.


-----
Regards,
Frode Langset
Norway

This thread: