From: "ray whidden" <ray.whidden@canrem.com>
Subject: new ideas?
Reply-To: "ray whidden" <ray.whidden@canrem.com>
Organization: Canada Remote Systems
Distribution: soc
Date: 8 Oct 92 19:33:42 EST


In an article by Dave Tait on SOC.ROOTS:

DT>  artificial insemination, two fathers - one mother
DT>  surrogate mothers, two mothers - one father
DT>  homosexual relationships - same sex marriage

Hi Dave,

Human biology hasn't changed in all of human history in this respect.
It takes a sperm and an ovuum developing into a fetus and thence a
human being.  In the past we have had multiple partners.  Only the reasons
have changed: used to be one died, sometimes in child birth, often from
one of the epidemics.  THAT is what I have realised from my pursuit of
genealogy; and given me a whole new appreciation for the wonders of modern
medicine.  Now we have muliple partners for the reasons you mention
and usually it's by CHOICE.  That is what we've gotten from all the
progress.

The programs that I use nicely handle things from the past and I don't see
any problem with the three cases you mention, unless you're asking for
some wierd and wonderful new report.  I already have a display in PAF
which shows one person and all of his spouses.  In two cases, you may want
to show one individual as UNKNOWN for your own reasons.  Do you want one that
shows all of a persons spouses and their spouses, too?  There is a phrase
which I'll santitize here: KISS - Keep It Simple S<fill in your own
expletive>.  Actually, I have wanted to show multiple marriages and
am in the process of developing a modification of the register style
report to handle it.  Unfortunately, in the real world, we create our
information on paper, which leaves us with across the page and down
the page.  Usually the pile of pages gets pretty high.  It's hard
to do hyper-text on paper.  It's otherwise called a library.

Actually, the program I use will also show a polygimous marriage: it
doesn't care when the marriages occurred or ended.  The fact that they
are concurrent is just an entry in the date field, not excluded by some
logic in the program.

In the case of same-sex partners, one program won't allow me to enter
M-M or F-F in a "marriage" but after you define M-F, it doesn't further
report which sex either partner is, except the <M-name> is printed first
and the <F-name> is printed below on reports.  If one partner doesn't mind
being entered as F in my program, I don't mind them conducting their affairs
the way they want.  I don't expect to request a programming change just for
this.  I also don't expect to see a great rush to including this partnership
in genealogies, unless that segment of the population developes an interest
in writing their own. And my friends aren't the least interested in my
genealogy, and neither, I suspect are theirs.  Thus, if their families
don't buy them, they're not likely to be written.

For special displays and expensive presentations, you may well have a
case but for daily works, Family Group Sheets, Ancestor charts,
descendant charts and register reports do just what I want just fine.

One other point: sensitive circumstances alway have to be dealt with
with consideration.  Thus, if the parties involved don't want info
published, then you really cannot publish it.  We all have run into
events that we were not free to recount because we still want to be
included in family events and we do EXPECT to sell our books to these
same family members.  Thus, you find sensitive AND accurate ways to
say what we want BUT we leave out the whole truth in the process in order
to remain on speaking terms with our family.

Ask anyone who has had the circumstances you describe how willing they are
to have the WHOLE story printed in a genealogy: I doubt you get many takers.
Thus, why have programs written expecting these to be the norm?  NOTES
is a great place.  I've come to doubt the usefulness of fields for the
likes of "GRADUATED: date/place" because that means you devote that field
to that event for ALL the members of your database.  I'm not likely to
have the graduated: date/place for all the individuals, so for 99% of the
database, it is a wasted field.  Now if a program could have GRADUATED:
date/place for a dozen, LIVED AT: date/place for a few hundred, MOVED:
date/place for a few more hundred and so on, ALL IN THE SAME FIELD,
then I would consider it a benefit.  However, systems analysts and
programmers would call me crazy and have plenty of good reasons why I
shouldn't do that.  And I would likely agree with them.  We just haven't
seen their rationale discussed, lately.

Thus, back to using NOTES.  Now, do you hide them, like some programs
do or just show them, the way other programs do?  That's about the only
real question.  Vive la difference.

Good discussion......

Regards, Ray

Internet: ray.whidden@canrem.com : RIME    : ->CRS : 46 Campania Crescent,
UUCP: canrem!ray.whidden FidoNet: 1:229/15  : Scarborough, Ontario M1V 2E9

 * DeLuxe2 1.21 #4419 * After all is said and done, more is said than done
--
Canada Remote Systems  - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044