TMG-L Archives

Archiver > TMG > 2000-06 > 0962255126


From: Bob Velke <>
Subject: [TMG] "Event-oriented"
Date: Thu, 29 Jun 2000 01:05:26 -0400
References: <00cf01bfe036$05fd85e0$0e4ac0d8@charliexi>
In-Reply-To: <4.3.2.7.2.20000627151549.00ad4b50@mail.skynet.be>


I hope that those involved in related threads (deliberately not quoted
here) will not be too offended when I say that, IMHO, all this talk about
"event-oriented" programs is a bunch of hooey.

Ask five people who claim to know what the term means and you'll get six
different answers.

Back in 1992, TMG/DOS v1.0 offered the ability to attach any kind and any
number of events to each person. For most people, this was seen as a
breakthrough and many hailed TMG as offering the first "event-based"
program. (Roots IV hurriedly hit the street about 8 months later). By
"event-based" they meant that you could "build" a person by recording
events in his life. The resulting chronological view of events was quite
different than the "fill-in-the-blank" style used by programs before
that. Nowadays, however, MOST programs are "event-based" (or try to be
<g>) by that definition.

Also back in 1992, relationships between people in most genealogy software
were implicit by virtue of those people being linked into the same
"family." To the extent that such programs supported sources at all, you
could record a source for the fact that the event _happened_ (and maybe its
date or place) but you couldn't site a source precisely about the assertion
that someone named John Smith _participated_ in that event. And more
importantly, you couldn't site a source for the claim that YOUR John Smith
was the SAME John Smith that participated in that event. That is, there
wasn't any way to document the sources of the relationships between people
as distinct from sources about the events in their lives.

Enter TMG/DOS v1.0 which distinguished itself by handling the
_relationship_ a distinct piece of genealogical data about which you could
make comments and, most importantly, record *sources*. You could still see
"families" but each family was an aggregate of a bunch of one-to-one
relationship records (mother/child, father/child, and husband/wife).

Then came Roots IV which was sort of a hybrid of those two strategies. In
Roots IV, the mechanism to record a relationship between mother and child
was to record a birth event and link the two people to that event. The
blood relationship was implied by the roles that the two people had in the
event. COMMSOFT started calling this "event-oriented" as opposed to
"family-oriented" or "lineage-oriented" (where people were linked into
families). Some people falsely put TMG into one or the other of those
categories when, as described above, it was really neither.

In my mind, it is one thing to have evidence of a relationship and another
to have evidence that two people participated in specific roles in an
event. Roots IV's strategy had other awkward side-effects - like the
requirement that everyone have a birth event record. That's a debate that
we'll leave for another day <g>. Suffice it to say that the successors to
TMG/DOS and Roots IV still follow their respective strategies today. So by
COMMSOFT's definition, TMG is NOT "event-oriented". It is different (and
we think better <g>) than "event-oriented" as they used the term.

Add to this confusion the fact that programmer-types often talk about
"event-oriented" or (these days) "object-oriented" programs...which means
an entirely different thing. For programming languages that use an
event-oriented strategy, everything that the user does is an
"event." Clicking the mouse is an "event" and typing a key is another
"event," etc. Developers must anticipate and then program appropriate
responses to each of those interactive "events." So those who use the term
"event-oriented" in this way are talking about an entirely different kind
of "event" which has no _genealogical_ meaning whatsoever.

One of the characteristics of these "event-oriented" programs is that they
tend to allow the user to pause in the middle of an activity, do something
entirely different (an unrelated interactive "event"), and then resume the
first activity where they left off. If the interim activity affected other
open screens, those screens would be updated to reflect the change(s). When
done right, that approach gives a lot of advantages to users - but it means
that users frequently find the screen full of unrelated windows with no
clear direction about which direction to proceed. Most programs that are
designed for sale to the mass market opt instead for a "linear" approach
because it is usually easier for users to understand. Here again, "linear"
doesn't mean "lineage" and has no genealogical meaning <g>. It means that
there is typically one way in and one way out of each screen.

As if there wasn't enough confusion about terminology <g>, COMMSOFT seems
to have designed Roots IV with the idea that (in addition to its own
genealogical definition of "event-oriented" as described above) it would be
"event-oriented" as programmers use the term. Without getting into the
debate about whether or not it was a good idea, the fact is that changes in
one screen weren't reflected in other screens until the user manually
refreshed them - which made it not truly event-oriented as I think most
programmers use the term. (I had occasion yesterday to discover that the
same condition holds true for UFT.)

So if you're following me so far ... nearly every program is
"event-oriented" and, at the same time, none of them are <g>, depending on
what definition you use.

Then in 1994, COMMSOFT released "InterGED" which conformed syntactically to
the "GEDCOM" that researchers knew - but it differed semantically. That
is, the syntax or literal building blocks was the same (it used tags, level
numbers, etc.) so in many ways it LOOKED like a typical GEDCOM file - but
it used tags and other conventions that other programs didn't
understand. For instance, it supported the communication of template
languages, roles, etc.

The thing that made it most different, however, was the way in which it
communicated a parent/child relationship. "GEDCOM 5.3 Draft Specification"
(the version promoted by the LDS at the time) linked parent to child
through a "family." InterGED continued to allow that - but it also
permitted parent and child to be linked by giving them distinctive roles in
the same birth event. For this reason, COMMSOFT described their
proprietary form of GEDCOM as the "event-oriented form of lineage-linked
GEDCOM." (Note here that, despite common misconception, "event-oriented"
and "lineage-linked" are NOT mutually exclusive.)

Shortly thereafter, InterGED was renamed "Event GEDCOM v1.0" in order to
"strengthen its tie to GEDCOM," as COMMSOFT put it.

By the way, it was perfectly "legal" for COMMSOFT to invent its own "form"
(or model) using GEDCOM syntax and to publicize their own "Event GEDCOM"
specification document. For better or worse, the GEDCOM documentation from
the LDS specifically allowed developers to do just that. I commended
COMMSOFT for doing so at the time. After all, over the years a lot of
developers have implemented their own "forms" of GEDCOM without bothering
to document them <g>. Of course, the catch is that in order for two
programs to effectively communicate, they need to have implemented the same
"form" of GEDCOM.

So why didn't "Event GEDCOM" catch on as a "standard?" As Forrest Gump
would say, "Standard is what standard does" <g>. I'm sure it doesn't
surprise anyone that "Event GEDCOM" was patterned after COMMSOFT's vision
of genealogical data as implemented in Roots IV. But while they said that
it was developed "in cooperation" with the LDS, COMMSOFT didn't consult any
other developer, to my knowledge. And, of course, since no other developer
(then or now) implements relationships in the same way, developers didn't
line up to use "Event GEDCOM."

Without any other developers on board with the project, "Event GEDCOM" was
relegated to a means by which UFT users could communicate with each
other. But, of course, it was more effective for those users to just send
their projects back and forth in their native format (or backup/SQZ) ... so
"Event GEDCOM" dwindled on the vine.

So there you have the whole story as I see it, for what it is worth.

-Bob


This thread: