TMG-L Archives

Archiver > TMG > 2002-02 > 1012749748


From: "F. Langset" <>
Subject: Re: [TMG] Long discourse on GEDCOM and witness data
Date: Sun, 3 Feb 2002 16:23:13 +0100
References: <3C5CA1EE.1391.F22174@localhost>
In-Reply-To: <4.2.2.20020202224222.01313d60@pop3.norton.antivirus>


-----
Ref: Lee Hoffman, 2 Feb 2002 23:06, "Re: [TMG] Long discourse on
GEDCOM ":
-----

Hi Lee Hoffman,

New day, new chance.

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

[clipped from lower down the message]
> 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.

Now, this "No." _cannot_ be unqualified according to yourself. If I
want to communicate my data by other means than paper (or word
documents etc.), the answer is "Yes."

Assuming that I have used the TMG witness feature extensively (witch
I have), Ihave the following options:
1) I either cannot communicate a (relatively) large part of my data
-- or --
2) I have to "impose a specific structure on my data to accommodate
other peoples needs more than mine"
(-- or --
3) I have to communicate those data by other means, letter, phone,
email, witch is always an "option")

If we follow some arguments in this thread (and another similar
thread), this is independent of wether we communicate by GEDCOM or
its eventual replacement, because the reason for not being able to
communicate the witness events (not witnesses!), is that it could be
misinterpreted by the receiver. This argument does not depend solely
on GEDCOM. It depends on the transfer between two incompatible data
models. You don't solve that by extending the transfer format with
witnesses, _except_ for those programs that have the same feature
implemented. You just move the responsibility for the interpretation
from the sender to the receiver. Now, remember that it is not me that
argues that one should not perform such an interpretation by other
means than a QWERTY-keyboard (so, I have to move along with my data
;) )

Or: Do you argue that it is better that the receiver program
interpret my data than TMG doing it? (as seen from the TMG-user's
point of view, her concerns about data integrity etc. etc.) You can
have my opinion now: I would feel better if I am able to understand
what could be inferred from my data. I go for the NOTE approach if I
do not know if the receiver can tackle witnesses. Second best: paper
(yes, I can have the NOTE provided I etc. etc, see above about
imposing unwanted structures on my data).

Actually, as seen from a user's point of view, I think this cries for
an option in TMG: "[x] I want to export data to another program", the
default value is _checked_ and the result is that the witness feature
is disabled in TMG. Any other features that also should be disabled?
You (well I) actually have to have used TMG for quite a long time to
see the problems you might get by using witnesses. There was an
argument somewhere about "encouraging the user..." (yes of course I
would uncheck it ;), but I would/should have tried to understand the
implications)

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

Yes, I suppose we (I) have altered the question a bit ;) I think
the question now might be something like: if we can skip the
witnesses, but can we have the events for which an individual was
assigned as a witness, as a note for that individual without actually
having to make that note in the data in TMG? (lets call it the
pragmatic solution). I suspect the final answer will be "No, but
almost" 8)

I am going to implement option 1 above (a day have only 24 hours: 8-
for sleeping, 8 for earning money, 8+ for the rest of my life, and
I'm not going to use those last 8 for making a utility program, I
make enough programming in the earning money part).

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

Me who started using witnesses! Well, honestly, I don't know. Now, if
one wants to solve the problem, this is hardly of any interest
(except perhaps financial). Of course I do see the point that there
might be other tasks that have much higher priority and deserve much
more attention. 8)

[clipped]
> >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.

Yes, I still agree that GEDCOM does not provide a data model (which
it probably should have). I do not think FoxPro provides one either
(shouldn't). And I still think that TMG does not have the option of
not using a data model (designed/known or inherent/unknown) when it
produces data for GEDCOM.

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

Yes, I agree: GEDCOM is not state of the art, and will never be.

> A user of the best genealogy program, The Master Genealogist (TMG)

I haven't met any serious rival 8)

I think it might be time to end this discussion on GEDCOM. Do you?
Regards,
Frode Langset
Norway
----
P.S. If this didn't make any sense: Print it out and
throw it in the waste basket, then give me a notice.

This thread: