This is indeed an interesting question! I think that I can safely say that
most genealogical systems (including, but not limited to, computer-based)
are focussed on how one arrived on the planet. That is, such systems tend
to look backwards in time. Hence the strong support for traditional family
units. I would think that most of us participating in this very discussion
were born or adopted into such units: a father, mother and children -- the
Today we know far more about what makes a person a male or a female on both
biological and psychological levels -- enough that we cannot honestly
divide the human race into strict male and female categories. I too think
that sex and sexual identity are two different things but that really goes
to how the terms are defined. I define sex based on one's mix
of chromosomes. That can be complicated enough now that we know that there
are more combinations than XX and XY and even then, they do not tell the
whole physical story, and that indicates that we may need to allow for
sexes other than "Male" and "Female."
Kinsey's famous research and resulting scale indicate that there is a range
of sexual identity and behaviour and that not everyone (far from it) is
exclusively hetero- or homo-sexual. Combining his insights with the
physical dimension can lead to a wide variety of possible sexual identities
and possible family structures.
Coming back to serious genealogical research, though, the idea (at least
for me) is to capture ancestry and descendancy. That may mean that we do
not need to capture every conceivable (and inconceivable) type of
relationship, since if said relationship leads to neither biological nor
legal offspring, we can choose to record the relationship as something
other than a family. (e.g. for generations gone by, we might not record a
person's lovers if they produce no offspring, though we might include an
historical note for a significant relationship.)
I do feel that we should have a system flexible enough to record offspring
from any legally-recognized union. Of course, that depends entirely on the
law where the union was established and is maintained. For example, I have
friends whose daughter is in a same-sex marriage. Recently the young woman
gave birth after being artificially inseminated and the baby is the legal
child of that relationship and grandchild to my friend. I should be able
to record that child in any system I use (including Gramps, of course!) .
That means that we need (at least) to be flexible with the labels "Father"
On Sun, Aug 26, 2012 at 11:40 AM, Nattily Pigeonfowl <
> I feel a bit responsible for this, as I was the creator of this particular
> complaint, although I have no doubts that it has been lodged many more
> times before. I regret that I created that page and wasn't able to maintain
> it and keep up the work required to really make it happen by myself. I do
> still hope to take the time to learn all about GEDCOM and how to make
> changes on GRAMPs and more python so that I can push this through in the
> future, if it's still not been done by anyone else with more experience
> with the database or with python. But I really haven't had the time and
> inspiration to try and force it thru yet, especially since I imagine that
> even if I had got it working on my own, there would be a different type of
> resistance that I'd have to push thru.
> Just some of my thoughts about comments I read in the emails:
> I really think it would be difficult to list all the possible genders.
> Would a larger system be affected negatively if someone did put 'lala' in
> as their gender? Would people's decisions automatically be public or do
> people only upload their data by choice?
> I don't agree with the statement about sex and gender identity being
> separate things. Especially not in regard to chromosomes. Have you ever
> actually gotten your chromosomes checked? I haven't. People with XY
> chromosomes sometimes are born without the typical level of testosterone,
> and develop internal reproductive organs rather than external. They grow up
> indistinguishable from other non-trans girls, are they biologically male?
> Also, I really appreciate what Benny said. Trans people (in your families)
> often see ourselves as entirely our gender, not as a _____ trapped in the
> body of a ______, so it really will allow the researcher to side-step
> future conflict and disagreement if they can set the point right at the
> Anyway, I appreciate that we're talking about this, and if anyone would
> like to direct me to the right spots to learn about the biggest technical
> issues making this difficult, I would love that. When I was working on this
> before, I made a new grampstype called GenderType and allowed it to be a
> fill-in box that could autocomplete for words like Female, Genderqueer, or
> Male. Would this cause problems for the GRAMPS database? This was the type
> of unanswered question that discouraged me before. I intended to use the
> symbol U+26A5 for all genders not male and female (although I like the idea
> of letting people choose their symbol separate from the text that they
> On Fri, Aug 24, 2012 at 6:55 AM, Benny Malengier <
> benny.malengier@...> wrote:
>> 2012/8/24 Tim Lyons <guy.linton@...>
>>> I tend to agree with the discussion page on GEPS 027:
>>> "My concern here is that this idea conflates two separate pieces of
>>> information: Sex (biological context: XX or XY), and sexual identity
>>> context: how they view themselves sexually). I have no objection to
>>> adding a
>>> field for sexual identity (or orientation), which would necessarily be an
>>> entry field, but do not agree with having it replace the existing field
>>> biological sex. To do so would leave it impossible to capture both the
>>> biological and social aspects of a person, just as it is currently. In
>>> short, it would be just as wrong, but in the other direction."
>> But there are transgenders, in a biological sense, who don't want to be
>> pushed in male/female.
>> You are right nevertheless that much might come from sexual identity, but
>> even then, can we ignore that? We all know the discussion of family members
>> when you publish something (book, ... ) and they complain about how you
>> recorded something in the family tree, and force you to promise to change
>> it. Big fights can enshew which are better avoided. Now, you have to put
>> the person private so as not to have him show up, but even that is actually
>> an affront. Allowing a way to the researcher to step around these issues is
>> not bad. Some transgenders will want to show up as male/female, and you
>> could store a private attribute, some will want to show as something else,
>> and that becomes possible.
>>> Tamura seems to think that "U" for "unknown" would be a legal GEDCOM
>>> but I don't see any support for that in the standard. There only seems
>>> to be
>>> M or F, despite the fact that it allows up to 7 characters.
>> Yes, but the GEDCOM standard should not limit us also. One could claim a
>> standards body would already have resolved this issue one way or the other.
>> Officially 7 characters are allowed as you indicate, so we could have
>> nothing (=unknown which is probably not by accident 7 long), F, M and O.
>> Other programs would import that then as unknown I suppose, but the
>> attributes would still be present.
>>> If you want to make a change, then Doug's suggestion to treat it like the
>>> other GrampsTypes, including allowing Custom with text seems the least
>>> disruptive. (This would allow the user to input XXY or XXX for example).
>>> http://en.wikipedia.org/wiki/Intersbut the GEDCOM standard should not
>>> limit us also. One could claim a standards body would already have resolved
>>> this issue one way ex#Conditions<http://en.wikipedia.org/wiki/Intersex#Conditions>.
>>> Perhaps some guidance
>>> should be provided to encourage users to decide for their own database
>>> whether they are going to record genotypic (chromosomal) and phenotypic
>>> or something else such as sexual identity in the existing field.
>>> Adding another field to the already crowded individual input screen seems
>>> complicated and unnecessary for the majority of cases. If one wants to
>>> separately record sexual identity, then this could be done with an
>> Yes, well, I would have the line with this hidden, only to show when
>> other is selected. Note that making gender a grampstype would be very
>> disruptive for all the code using gender, just adding other not.
>>> I am not sure why the title of this discussion includes the words "same
>>> sex". This seems to imply that it is related to the discussion about how
>>> insert same sex marriages, but again this is an entirely different topic.
>> Yes, I mixed up. The reason I start about it here is that I added colors
>> for boxes in the preferences based on gender, and will use that in pedigree
>> and fanchart. There I need to consider same sex, but was wondering about an
>> 'other' gender. So I mixed up
>>> My favoured option is to provide guidance to user that they should decide
>>> for themselves what they are going to record, and if the existing fields
>>> inadequate for that they should use one or more attributes.
>>> View this message in context:
>>> Sent from the GRAMPS - Dev mailing list archive at Nabble.com.
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> Gramps-devel mailing list
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> Gramps-devel mailing list
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> Gramps-devel mailing list