TMG-L Archives

Archiver > TMG > 2002-02 > 1012591521


From: Bob Velke <>
Subject: Re: Fwd: Re: [TMG] Witness and Roles and V5.0
Date: Fri, 01 Feb 2002 14:25:21 -0500
In-Reply-To: <F91kutnLNGmQ5QcYAYK00018cf9@hotmail.com>


Gene said:

>Yes, I agree with you that this is a problem. (Yeah, Bob we agree on
>something!) It's not a problem in UFT because the user controls who gets
>exported ...

It certainly IS a problem for anyone reading that file because it doesn't
communicate what the researcher thinks it communicates.

>... by who was marked principal.

GEDCOM supports some kinds of event participants and not others. The
problem lies in whether or not the user has the option to override that,
manipulate GEDCOM, and miscommunicate the data. I happen to think that
they shouldn't and you apparently think they should. But the problem is
not HOW they do it. The fact that TMG and UFT both have a feature called
"principal" leads people to the misconception that they do (or should) have
the same meaning - but that only detracts from the real problem.

If I believed that there was a legitimate way to transfer children in a
household by GEDCOM then I'd offer you an option to do it - whether or not
those children happened to be marked principal. The one thing has nothing
to do with the other.

>Bob, we have many areas of agreement. I hope you will consider GEDCOM to
>be a form of a report and kindly consider how witness data may be exported
>to it as well as to printed charts and reports.

Witnesses cannot be transferred by GEDCOM, period. If you want to design
another transfer protocol (call it something else, etc.) then I'm all
ears. But why do you insist on carrying a leaky bucket and then complain
that the carpet gets wet?

>1) Simply allow the user to export witnesses to GEDCOM if he/she wishes.
>After all it's my data and this is what I want to do with it. Load it up
>with all kinds of notes, warnings, and caveats if you wish, but then let
>me do it. PLEASE! In this instance I really don't want to be "protected"
>by you.

What I am doing is not changing your data from the way you entered it. You
are free to change the way that you entered it or to transfer it in a
different way. But it is not reasonable to suggest that I'm standing in
your way by honoring what you entered and by adhering to the transfer specs.

It is a terrible, terrible, thing that no data transfer protocol exists
which honors witnesses (among many other problems with GEDCOM). I'm doing
my part by being involved in various industry projects designed to produce
a better alternative to GEDCOM. In the meantime, don't shoot the messenger.

>2) Create a new type of indicator similar to principal, but used to
>control GEDCOM output. i.e. "GEDME". Or allow GEDCOM output to be
>controlled by some kind of a flag.

As above, the problem is not how to choose who to export.

>3) Make some other suggestion as to how this information can be preserved
>upon transfer of data to other software.

My suggestion for transferring data from A to C is to not do it through a
middle-man that doesn't support some of those data types. That's why we
developed GenBridge. Failing something like that, data integrity (if not
convenience) would be better served by re-entering the data or waiting for
a better transfer protocol.

>4) Issue strong warnings to users that witness information cannot now and
>never will be exported via GEDCOM and that if they wish to preserve such
>data electronically they really should not use that feature of TMG. (Kind
>of negates the reason for using TMG in the first place in my mind, but
>you're in control here.)

I don't have any control over what is or might some day be supported by
GEDCOM. But I think it is shortsighted to limit your _recording_ of data
to what is supported by a particular kind of transfer. You couldn't
electronically transfer the Census household out of UFT either without
corrupting it (by GEDCOM's definition) until GenBridge came along.

It is no secret that if your intention is to transfer from TMG to FTW, for
instance, then there are LOTS of data types that you will lose. That would
be true even if FTW read data directly from TMG. Add GEDCOM as a
middle-man and the amount that you can reliably transfer is even less. If
that leads you to the conclusion that you should only enter that which
meets the lowest common denominator, then I'd have to agree with you that
TMG and UFT are overkill and you should be using FTW. Thankfully, most TMG
and UFT users don't let FTW or the LDS dictate what is important for them
to record.

I _understand_ the frustration, Gene. It is one thing to complain that
there aren't good enough transfer tools in the world. But it is something
else altogether to deliberately use the wrong tool for the job (GEDCOM) and
then blame _me_ that it doesn't do what it wasn't designed to do.

-Bob

This thread: