TMG-L Archives

Archiver > TMG > 2002-02 > 1012650862


From: "Darrell A. Martin" <>
Subject: [TMG] Long discourse on GEDCOM and witness data
Date: Sat, 02 Feb 2002 05:54:22 -0600
References: <5.1.0.14.0.20020201194114.00a07e70@pop.sprynet.com><5.1.0.14.2.20020201152415.0f2f8c50@mail.hwrd1.md.home.com><Springmail.105.1012591652.0.90606200@www.springmail.com>
In-Reply-To: <5.1.0.14.2.20020201220033.0d5d2a50@mail.hwrd1.md.home.com>


At 11:19 PM 2/1/02 -0500, Bob Velke wrote:
>Darrell said:
>
>>But fair, bad, or awful, GEDCOM is the best we have for the moment for
>>transferring data between different programs or systems.
>
>That is exactly the gross misconception that I am trying to dispel. It is
>NOT the best we have. If "best" is measured by complete and accurate
>communication (?), then it is arguably the _worst_ that we have. It is
>the most _convenient_ that we have but that is not the same thing at all.

Hi, Bob:

OK, to dive right in. I am not measuring GEDCOM by "complete and accurate
communication", that would be a joke. Even GenBridge is none too good at
that, based on my UFT > TMG experience, and it is light-years ahead of
GEDCOM. I am measuring GEDCOM by universality and - YES! - convenience.
What you seem to regard as a trait to be dismissed is a virtue that many of
us have found crucial to some of the most important genealogical tasks we
perform. Nothing even begins to compete with GEDCOM in that area.

>>I understand that you can't use the BAPL or BAPM tags in GEDCOM for a
>>witness to a baptism. But I certainly hope you don't mean that GEDCOM 5.5
>>affirmatively prohibits any mention of a baptism event in any way -
>>except for the principal using one of those two GEDCOM tags?
>
>If you change the last part to:
>
>"GEDCOM 5.5 affirmatively prohibits any mention of a baptism event in any
>way that is expected to be recognized by another program as a baptism -
>except for the principal using one of those two GEDCOM tags"
>
>...then that's exactly what I'm saying.

Bob, you changed what I said to something which at the heart is very
different, and then proceeded to demolish a position I didn't take. Not
only do I NOT expect the witness information "to be recognized by another
program as a baptism", but I would regard any process with that result as
flawed.

The definitions of the BAPL and BAPM tags in GEDCOM differ in a crucial
respect from the "Baptism" tag in TMG. The GEDCOM tags are defined as
connected to exactly one individual. The TMG tag provides for the
possibility of an indefinite number of individuals connected to the event,
and they can be connected in an indefinite number of ways (to include the
possibility of Roles in the discussion). It is therefore "translation" to
use a GEDCOM BAPM or BAPL tag to represent the data contained in a TMG
"Baptism" tag - even for the principal. But the "translation" that you seem
to object to in theory is in my opinion good, and proper. It is at the very
least extremely useful, if not downright necessary, but it can still be
done badly or well. To say that the witnesses were "baptized" would be to
do it badly indeed.

>(Of course, _anything_ can be said in the form of a note.

Hooray! That is *exactly* what I have asked for. Get the data to GEDCOM in
the way that is the least misrepresentative of what is in TMG, and let the
receiving user decide what to do with it. A NOTE would be one way. There
*might* be others, but there is at least this one way.

By the way, I do indeed mean "least misrepresentative" and not something
else. The only way to completely eliminate misrepresentation of the data in
TMG during a transfer would be to transmit all of the connected records in
a data set to another copy of the same version of TMG using the same TMG
configuration.

To require exact and complete correspondence of the data at both ends of a
transfer, is to argue against data transfer itself on principle, at least
between programs with different data structures. That argument would be
philosophically sound, and in theory would have a lot of merit. TMG might
be a better program in some ways if it did not include data transfer unless
the recipient also used TMG. It just wouldn't be a program I would use.

> And you can use custom tags but other programs are not expected to
> understand them).

I have little or no interest in custom tags. They are limited in all sorts
of ways, including the touchstone convenience (universality).

>>We should expect the same distinction from the GEDCOM export function.
>
>And my armchair should fly <g>. There is no such distinction in GEDCOM
>and I'm afraid that all of our collective wishing doesn't make it so.

The distinction is between the person who gets wet at the baptism, and
those that don't. GEDCOM actually makes communicating the distinction
easier than making the connection between the participants (because it
doesn't provide for that at all). Use the BAPM or BAPL tag for the one
getting wet, use some other tag for the rest. I am not wishing for the
distinction, I am insisting on it - if the data is to be transferred. I am
arguing that the witness data *should* be transferred.

>>One could make the equivalent of a TMG "Biography tag" out of the
>>resulting text from a "Baptism" tag witness sentence (I am talking about
>>results, not programming methodology), add all the disclaimer text one
>>wants, and be in spec.
>
>I suggested exactly that and you can do it now in v4.0d. But the
>importing program wouldn't recognize it as a baptism.

Please, take off the "recognize it as a baptism" blinders; if you are going
to tell me I'm crazy for something, let it be what I *do* want. I *do* want
the witness data to be included in the GEDCOM. I do *not* want it done by
calling a witness a principal (or the translated equivalent). I do *not*
want to create superfluous Biography tags for every event with witnesses. I
*do* want the computer to create the appropriate GEDCOM records, at the
time I create the data transfer, from my existing TMG records. I do *not*
want to abandon the basic event-based structure of my own data in TMG.

>>It seems to me that misrepresenting data by omission is at least as bad
>>as misrepresenting it by inference.
>
>OK, well we will have to disagree on that. I don't know much Cherokee but
>let's say for the sake of argument that it doesn't have a term for the
>Social Security Death Index <g>. If I tell you that I'm speaking in
>Cherokee, I tell you everything that I can about my data given the
>limitations of that language, and I'm careful that what I *do* say is
>accurate, then I don't think that I've misrepresented anything. I never
>claimed any responsibility for what you might understand. And I never
>claimed that my intent was to tell you everything that I know! If that
>was my intent, then I think that it would be irresponsible for me to
>simply make up a Cherokee term for the SSDI. That wouldn't improve our
>communication. In fact, it deliberately introduces real risks of
>misunderstanding. No, if I wanted to talk to you about the SSDI, then I'd
>make darned sure that we didn't try to communicate in Cherokee because I
>know that it is a poor choice of medium for our purposes.
>
>(No offense to the Cherokee nation as I suppose maybe it does have a term
>for the SSDI <g>. Tim Cook where are you when I need you?).

You have conceded that it is not necessary to communicate all that is in
your data in order to avoid misrepresentation. I would like you to apply
that principle to witnesses. If the language of GEDCOM does not have the
concept, it is at least possible to construct a *different* tag, if only a
NOTE, that communicates as much as possible of the witness information
without falsely identifying it as the same as principal information.

It is one thing, and true, to say that GEDCOM does not permit linking
people who were present at a baptism, but did not get wet, to a BAPM or
BAPL tag. It is quite another, and false, to say that there is no way
whatever in GEDCOM to communicate the information that there were people
present other than the one who got wet. The NOTE tag is one way. There may
be other ways.

>>And as I and others have said, for us abandoning GEDCOM is simply not an
>>option without an alternative in hand.
>
>I think that you mean a _convenient_ alternative.

Yes I do, of course! There is no other excuse for GEDCOM as it is currently
used. For convenience, meaning universal availability, there is no
competition for GEDCOM now in transferring data to other programs. You may
argue that this is an undesirable thing to do, even in principle, but the
genealogical computing user community as a whole has enthusiastically
embraced the concept, even if there is grumbling about the limitations.

> There are plenty of alternatives as I have outlined. Your concern for
> data integrity is defined by how important it is to you when it gets
> inconvenient. That's when the rubber hits the road, as they say.

You say there are plenty of alternatives. Well, sure, collecting stamps is
an alternative to using GEDCOM too. But a 3 cent blue airmail won't get my
data to my sister in Tennessee in a format she can, and will, use. You are
right, on the other hand, about my concern for data integrity. It just does
not force me to the conclusion you seem to imply it should. In fact, if I
could get 95% of the data integrity I get from TMG from another program,
but it took me only 20% as much time to use it for the tasks that are
important to me, I would switch. And if TMG couldn't do something I *need*
(which is not currently a problem) then its data integrity wouldn't be
worth two cents to me.

If you could make an automobile that was realistically guaranteed never to
have an occupant killed in an accident, and would never rust or break down,
but it couldn't make a left turn or go faster than 15 kilometers per hour,
who would buy it? In the same way, data integrity (like a fully normalized
database) is a very fine goal. But within the basic limits required for a
program's usability, having more data integrity does not guarantee a better
program, nor does having less of it guarantee a worse one.

>Besides, you talk about "abandoning GEDCOM" as if it ever WAS designed for
>what you are using it. It is not appropriate to use that as a baseline
>and then say that other people are interfering with communication if they
>don't validate your bad decision.
>
>-Bob

I understand the original purpose of GEDCOM, but couldn't care less. My
interest in it is based on its current usefulness. The idea of abandoning
GEDCOM has nothing to do with its design, just with the possibility that
something both more convenient and more accurate might come along.

TMG already validates GEDCOM by providing export in that format. That being
the case, I would like TMG to do a better job of it. If TMG version 5
arrives without GEDCOM export, it will not become my genealogy program of
choice until someone develops a utility to provide the function. If that
didn't happen, I would be forced to wait to upgrade until something better
than GEDCOM arrived, and was implemented in TMG. By that point, my use of
TMG would probably have long been mooted. And that would *not* make me happy.

I'm turning off my alarm clock now.

Darrell


Darrell A. Martin
a native Vermonter currently in exile in Addison, Illinois



This thread: