TMG-L Archives

Archiver > TMG > 2011-03 > 1299774662


From: Rick Van Dusen <>
Subject: Re: [TMG] design question
Date: Thu, 10 Mar 2011 08:31:02 -0800
References: <132253.43081.qm@web88307.mail.re4.yahoo.com>
In-Reply-To: <132253.43081.qm@web88307.mail.re4.yahoo.com>


The qualities you've listed comply with normal database design. And tags
are not automatically created. However, tags when created (and stored in
their own table) must necessarily join to data in other tables, e.g. an
address tag must be joined to the Person in the Person table or it won't
have any meaning. This is very different from an automatically-created
tag, but yet there is something happening in the background (as most
database apps are programmed, and as TMG is programmed).

I was referring to this joining as I discussed a possible data entry
form. Note that in virtually any database application, a form allows
entering new data and calling existing data, and linking them together.
(Where the new data type is connected logically to the existing data
type, that is called a "join".)

So for example, if I want to enter an address for a person, I call a
form to create the new entry (in TMG it's called a Tag). Within that
form I enter the address data (new data, in this case forming a record
in the table that we users conceive of as the Master Address List), and
I link that to a person (already existing in the Person table).

Without such links, any data we entered would be as useless as the
sports scores in the old gag.*

Since presently TMG allows two people to be designated Principals, most
forms have space for two Principals. If Terry's idea were to be
implemented, the two-space approach wouldn't work, as there might be any
number of Principals (see below on that topic). So instead, we could
have a box showing a list of Persons, and the ability to designate any
of them as a Principal. The lines in this box could scroll so that we
could enter a person being born, two people marrying, or all the people
attending a college reunion.

Now on the issue of Principal: The problem as I see it is not that the
concept of Principal is mere artifact, but that TMG was set up for one
or two only. I believe the concept matches reality; nearly every event
has at least one principal. The baby being baptized is the principal
(the subject or key person of the event); all others are witnesses. Both
groom and bride are principals in their wedding. All alumni are
principals in their reunion (spouses are witnesses). For 9/11, most of
the people that most of us have in our genealogies were witnesses, but
those who were directly impacted (literally or figuratively) were
principals. It's just really hard to get away from that dichotomy, and
therefore, I believe it continues and will continue to have a place.

(BTW, most of the traffic in this arch-thread relates to the fact that
we TMG users have this issue whereas very few gen apps allow the
connection of multiple people to one event.)


----------------
* Sports announcer: "And now today's football scores: 28-53, 13-5, 17-19."




Pierce Reid wrote:
> Rick said:
>
> <<The problem is, that your concept wouldn't logically fit within the
> present interface. The main problem would be that having any possible number of principals would be incompatible with having fields on the form for only two principals.
>
> However, it wouldn't be that difficult to design an input form that has, say, an expandable/scrollable data entry area with a line for each person, with each line having a field for "Principal", in addition to ID, name, role, etc.>>
>
> To a large extent, individual records and tag records should be kept independent for data entry purposes. For most, individual records have a bunch of links to tags, and tags have a bunch of links to individuals, with some role information to describe the links.
>
> There may be a few individual-tag combinations where special processing is useful, but that should be kept to a minimum.
>
> I don't think tags should be generated automatically, at least not without the user's permission.
>
> Address information should be just another tag that we can create. I have resides/resided tags that I use whenever I think I have useful address information. I can have any number of people linked to one resides tag. I also include address information as part of a census tag, where that is available. But I make the decision whether is is worth the effort to record that data.
>
> TMG's "principal" designation is, in my opinion, a hold-over from its earlier design and offers me nothing useful. UFT's "principal" indicator is basically for report production - is this event printed for certain reports for this individual. Any number of individuals can have this flag.
>
> Pierce


This thread: