Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#425 TEI using outmoded ISO 5218 for sex value attribute

AMBER
closed-accepted
5
2014-07-12
2013-01-21
Melissa Terras
No

TEI uses ISO 5218:2004 to assign sexuality of persons in a document ( with attributes being given as 1 for male, 2 for female, 9 for non-applicable, and 0 for unknown). This is an outmoded and problematic representation of sexuality, and in particular formally assigns women to be secondary to men.

There are other discussions online regarding how best to tackle sexuality in markup, and the problems in using ISO 5218 - see the w3c lists here: http://lists.w3.org/Archives/Public/public-contacts-coord/2010JulSep/0010.html .

I would like to see TEI move away from enshrining women as the second sex in their markup - as Steven Ramsay tweeted:
<author>Simone de Beauvoir</author> <sex value="2">female</sex> *sigh*

Can a discussion be had about how best to achieve this? Your current approach is both outmoded and offensive.
best,
Melissa

Related

Feature Requests: #487

Discussion

1 2 3 4 > >> (Page 1 of 4)
  • BODARD Gabriel
    BODARD Gabriel
    2013-01-21

    I have long argued that ISO 5218 was inadequate for recording sex, not only because of the precedence of "male" in the numbering (although I've heard people interpret it the other way around--female is double the value of male--but that's a derailment), but because the values "unknown" and "not applicable" (which presumably can only refer to things like an anonymous blogger and a robot, respectively) are completely inadequate for representing the many other sexes and sexual-identities possible, including intersex, genderqueer, gender-neutral, fluid, trans* and many others.

    I did ask around various online queer communities if there were other proposed open standards for representing sex more inclusively, but no one could think of any. (The problem being, of course, that any such standard would be inadequate.)

    I agree very strongly with Melissa that we need a discussion about how to improve this situation, both at the TEI level, where we have a chance to improve the situation in the short term, and at ISO (which will no doubt takea lot longer). Failing any other external standard to adopt, I suggest the datatype of @sex be changed from data.sex to enumerated, allowing project-specific definition of sex (with documentation). This would allow anyone who is currently using ISO 5218 validly to continue doing so, but anyone who wants to do better to definte their taxonomy in the teiHeader (perhaps a sexDesc element provided for the purpose?).

     
  • Elena Pierazzo
    Elena Pierazzo
    2013-01-21

    I have been arguing for this for the past 6 years, since the presentation of P5, and I don't buy the retrospective argument that 2 is assigned to a woman because it is twice as good as a man. The TEI should not accomplice of the sexism of ISO. Agreed with Melissa and Gabby.

     
  • Martin Holmes
    Martin Holmes
    2013-01-21

    I agree with Gabby's proposed solution to go to data.enumerated for sex/@value in the short term, and revise the prose of the Guidelines. Then we need a working group to come up with a proper solution.

     
  • My feeling is that we should stick to the principle that we re-use external standards where at all possible. There isn't an obvious other contender to a categorisation of sex than ISO, so if thats inadequate, lobby ISO, not TEI.

    Why do people care? if you want to ignore the nornalization to ISO, use the body of the element to say whatever is needed. If you want to use another normalization schema, redefine data.sex in your customization as usual.

    by the way, I don't regard TEI as "them" or "you". It's "we" and "our" standard. Similarly, ISO.
    lets not fall into the "leave the EU, they take away all our rights" trap....

     
  • James Cummings
    James Cummings
    2013-01-22

    I don't seriously make the argument that '2' is better than '1' because it is more. When I've said that it is to point out how silly I find it to make the assumption that a numbering system of 1 and 2 somehow implies precedence or order (especially when '9' is also used). IMHO, I don't think it truly 'assigns women to be secondary to men', just like if ISO 5218 was expanded to have , let's say, trans ppl as '3' that they would be considered tertiary and below women. I'm sorry that you find it offensive. I've always felt that It is just a different number. It is simply an agreed machine-processable label -- yes people can get offended by that, but that isn't inherent to the number itself but the interpretations people place on it. I'm not saying those interpretations aren't real or don't have weight, validity or consequences. But that has to be balanced against using some adhoc linguistically-specific system which is why we moved away from 'm', 'f', 'u', and 'x'. There are many, many, other possible ways that people could record the information about sex and/or gender using TEI should they wish to do so on point of principle. (Using @ana to point to a full taxonomy of possibilities, for example.) Or as Sebastian points out local implementations are free to change the values associated with data.sex if they wish. I've always felt unease at the limitation of the 4 values and would happily argue for updating it if an agreed standard could be formalised.

    I'm not saying the TEI shouldn't change this, but I would instead be trying to get ISO to redefine the standard in some appropriate way and then TEI would, happily and without argument, implement that.

    No one has suggested what possible values we *should* use, so discussion would need to develop a clear proposal. Part of the problem is that any numerical system has the perception of ordering, and alphabetic ones have linguistic culture-specific assumptions that we'd prefer to shy away from if possible. One possibility suggested to me was to code for chromosome types XY for males and XX for females (which nicely gets a way to deal with sex chromosome abnormalities like Klinefelter syndrome), however, while this may work for biological sex identification it does not deal with gender and/or sexual identification such as the list proposed by Gabby. I honestly do not know what the right values should be. If I was encoding texts where it was felt important to have more than the four categories, as I suggested I would probably use a <taxonomy> with a range of values suitable to the task.

    [Since Gabby has already done some research in this area, I'm assigning the ticket to him to make sure we don't lose sight of it. Marking it as group 'RED' at the moment because we'd need a clear proposal to discuss and it isn't all clear what that proposal should be.]

     
  • James Cummings
    James Cummings
    2013-01-22

    • assigned_to: nobody --> gabrielbodard
    • milestone: --> RED
     
  • BODARD Gabriel
    BODARD Gabriel
    2013-01-22

    I agree that TEI is not--and shouldn't be--in the business of creating new standards, but we are currently in the business of recommending the use of existing standards, and we should be careful that the standards we recommend are fit for the purpose our users are going to employ them for. It's clear that for several reasons ISO 5218 is not fit.

    I do have a concrete proposal, in fact: change the datatype of person/@sex and sex/@value to data.enumerated, with instructions in the classSpec to use a project-defined or other standard taxonomy of sex (e.g. ISO 5218, or something better if it arises). This is backward compatible and doesn't prevent anyone who likes the current scheme from continuing to use it as their default normalization; it just deprivileges it.

    Those of us who care can also petition ISO to improve or remove the inadequate standard (but good luck with that), or work with other communities to come up with a rival standard. It's not TEI's business to do that, though.

     
  • Martin Holmes
    Martin Holmes
    2013-01-22

    Having thought about this a bit more, Gabby's proposal (changing data.sex to data.enumerated) won't work transparently, because data.enumerated is data.name, and data.name is an XML name which cannot begin with a digit, and so ISO 5218 numerical values would become invalid. They could be prefixed with a letter, of course, but such a change would break backwards compatibility.

     
  • BODARD Gabriel
    BODARD Gabriel
    2013-01-22

    That's a problem. This isn't the first time that the datatype of data.enumerated has turned out to be a problem (cf discussion of datatype of @ed). Is there some other some other value we can use (e.g. data.code) that allows arbitrary enumerated values?

    Why does data.enumerated need to start with an alphabetic character anyway?

     
  • Martin Holmes
    Martin Holmes
    2013-01-22

    The discussion Melissa has pointed to advocates an open-ended approach in which there are some suggested values ("male", "female") but the category is open so that users can express their sexuality or gender in a way that suits them. One option would be to create a new attribute with open data.enumerated values, and suggest some values. This could coexist alongside the @sex and sex/@value, which could then be deprecated if we wanted to make a clear statement of disapproval of 5218.

    Naming this attribute would be problematic. @gender springs to mind, but the potential confusion between sex and gender, transsexual vs transgendered, etc. would probably rule it out. We need a lot of input from the community here.

     
1 2 3 4 > >> (Page 1 of 4)