TMG-L ArchivesArchiver > TMG > 2011-03 > 1300209719
From: "Darrell A. Martin" <>
Subject: Re: [TMG] design question
Date: Tue, 15 Mar 2011 12:22:05 -0500
References: <firstname.lastname@example.org> <4D7EF6D6.email@example.com> <4D7F1007.firstname.lastname@example.org> <4D7F7B30.email@example.com><00a201cbe32a$724558b0$56d00a10$@com>
On 3/15/2011 11:02 AM, Teresa Elliott wrote:
> Darrell and Rick,
> First off, let me state, I do not disagree with anything you have said so
> But let me ask a few questions that would need to be answered IF TMG were to
> allow multiple witnesses to a tag to be PRIMARY (let's not say principal,
> but rather we'd prefer them to be able to be PRIMARY to the tag)
You have fallen on the terminology sword
already. "Primary" is used in TMG for a
different purpose. In the "normal speech"
use of the word, I agree.
> How would charts work at that point? Part of only allowing two people to be
> PRIMARY to a tag, is that charts only have so much room.
Some Tag Types have hard-coded meanings
for the principal witness position(s).
If TMG were changed to allow for more
than two principal/primary person links
then some other way might have to be
found to select people for charts. I
don't think it would be necessary.
> While I would love
> to be able to make my 3rd great grandfather, his wife and all 11 children
> living with him primary to the tag and be able to add that census tag to a
> chart for each of them, currently I cannot do so. Only P1 and P2 can be
> primary. The chart only prints the census tag for P1 and P2.
For a census, this does not make any
sense to me. If one puts census data
onto a chart, why would you not want
to include everybody who is part of
the record? If that is too awkward
for a chart, why use a chart in that
I can see why the Head of Household
might be treated differently, but
for all others (I emphatically
include the possible spouse of the
HoH) there is no rational reason --
in my own approach to the data --
to limit the principal/primary
designation to one or two persons.
> There are lots of events where we all admit that it's difficult to pick who
> should be P1 and P2, and therefore have a primary tag of that type. Census,
> wills, deeds all come to mind. I have one deed where a woman's 6 children
> and spouses made a deed relinquishing their share of their mother's estate
> to two other children and their spouses. Who should be primary here?
That is the question, indeed.
> Now coming from UFT and having given birth, I do think the parents (the
> mother at least) should be a primary person in a birth tag of the children.
The Birth Tag Type is perhaps the best
argument for three or more principal/
primary person links in a Tag.
> I do think children's birth tags should print in parent's narratives and
> have jumped through a lot of hoops (attaching two parents to 16,000+ people)
> to get that to happen. Not only is having children a major life change, for
> most people it determines decisions they make and can lead to more research.
Preaching to the choir, lady....
> So I think for TMG to ever be able to accomplish what we are discussing, it
> would need to give up limits on number of people who can be PRIMARY (not P1
> or P2) to CUSTOM tags.
There is little question that the P1-P2
designation is so ingrained into TMG
and many of its loyal users' data that
it cannot be abandoned. What we may be
saying is that there is a need for P3+
-- or something like that.
> I am a witness
> to my grandfather's death tag. But I am not primary to that tag. I didn't
> die, he did.
That distinction would need to be
maintained. Certain Tags -- BMDB
and a few others, perhaps -- would
remain special cases.
> If a person wanted the burial tag to allow multiple people to be primary,
> they could always create it in the custom group.
Shouldn't be necessary.
> Pedigree charts use the relationship tag (not changing) and the marriage tag
> (not changing). What would change are how other tags are viewed.
> Now having said all that, that would take a complete rewrite of the TMG tag
I do not believe that is correct. The
existence of the History Tag shows us
that there is more flexibility in the
basic design than it might appear.
> None of it would GEDCOM to another program.
It could. No, not an easy programming
change, but there are ways. Again, the
History Tag does GEDCOM, as an "EVEN"
> Are we sure this is a
> design change we'd want to spend programming time one when there are so many
> other features that we don't even have yet?
Yes, I am sure *I* want it. I don't
lose sleep over not having it.