TMG-L Archives

Archiver > TMG > 2002-02 > 1012623561


From: Bob Velke <>
Subject: Re: [TMG] Witness and Roles and V5.0
Date: Fri, 01 Feb 2002 23:19:21 -0500
References: <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.0.20020201194114.00a07e70@pop.sprynet.com>


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.

>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.

(Of course, _anything_ can be said in the form of a note. And you can use
custom tags but other programs are not expected to understand them).

>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.

>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.

>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?).

>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. 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.

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

This thread: