/usr/portage

Microformats and sex/gender 11

In reply to Tantek’s thoughts about OpenID reinventing the hCard wheel and in consideration of Queering Gender: the microformat for gender could be a) a range between 0 and 10 (0 is male and 10 is female) or “OTHER” if the range does not fit it al. “XA” for locations etc. is fine. So users can express a little bit more than just “OTHER”.

Filed under , , & eleven comments & no trackbacks

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

  1. Tantek Çelik answers:
    published on November 4th 2007, 05:23:49 pm *

    Lars, first, thanks very much for your blog post. It is good to see that there is additional interest in having a gender property that is not just a M/F boolean value.

    Second, as we’re trying to avoid as much reinvention as possible, if you think something about hCard or hCard itself is being reinvented, please specify precisely what you think is being reinvented so we can fix it.

    And finally, I think perhaps I didn’t make it explicit enough in my blog post that my proposal for a gender property takes an arbitrary string value which simply comes with a "starter kit" of four enumerated values with predefined semantics (M,F,OTHER,NA). Since the property is an arbitrary string value, other values are of course permitted which would easily represent for example the plethora of gender values in the Pownce and Digg profile interfaces.

    Reply

  2. Lars Strojny supposes:
    published on November 4th 2007, 05:29:04 pm *

    Reinvention: no, I do not think that microformats reinvented anything or at least, I can’t say :-)

    Abitrary string: allowing an abitrary string seems nice but in the business I’m in (dating), gender (or more likely sex) is pretty important as it is maybe the most basic search criteria for near to 100% of our users. So we could not allow a user to specify an abitrary string because our software would become unusable. On the other hand from theoretical viewpoint a really appreciate all these gender theories/debates. So I tried to bring both together. Allowing a bit more flexibility but making sure a platform can do something with the gender value of a user.

    Reply

  3. Tantek says:
    published on November 5th 2007, 08:29:49 pm *

    >Reinvention: no, I do not think that microformats reinvented anything or at least, I can’t say :-)

    That’s good hear, as I took your reference to my post as "reinventing the hCard wheel" to imply that there is/was some reinvention occurring. Thanks for the clarification :)

    >gender (or more likely sex) is pretty important as it is maybe the most basic search criteria for near to 100% of our users. So we could not allow a user to specify an arbitrary string because our software would become unusable.

    One thing to keep in mind is that just because the format may allow an arbitrary string, it does not mean that your user-interface must allow a user to specify an arbitrary string.

    The point of allowing an arbitrary string in the format is to support the data across a wider variety of sites that may provide additional values. Even Pownce and Digg don’t allow an "arbitrary" string, but they do allow other values like "lady", "dude", and "transgender" for example.

    Your point about search is a good one and by basing it real world behavior of users, you make a strong point.

    If we made the gender type structural, that is a required enumerated value from the four values (M,F,OTHER,NA) and an optional arbitrary string, then for example Pownce could represent those values respectively as (in vCard syntax) :
    GENDER:F;lady
    GENDER:M;dude
    GENDER:OTHER;transgender

    This would also allow the search example you stated to find "dudes", "guys" and other male-gendered values from Pownce when looking for "males", and similarly for female-gendered values.

    As far as the "OTHER" value, even with only some reading of the articles about queering gender etc. it is clear that once you go outside of traditional/majority M/F expressions of gender, there is a plethora of ways that people describe themselves, thus it makes more sense to simply allow the arbitrary string value to represent that existing diverse behavior. Search user interfaces for such values may be more challenging than a simple binary M/F (perhaps an OTHER gender heat map representing frequency of term use?) yet have to take that diversity into account anyway, since that diversity is due to existing real world practices as per the referenced reading. The format proposal simply reflects those practices.

    Reply

  4. Lars Strojny returns:
    published on November 6th 2007, 12:16:45 pm *

    I like the idea of making it structural. I’m not 100% firm with the syntax you used, can you give me an example how this would look like in XHTML?

    Reply

  5. Lars Strojny states:
    published on November 6th 2007, 12:38:04 pm *

    Is this how you intend it?

    span class=gender
  span class=m
    Some string
  endspan
endspan

    Reply

  6. Andy Mabbett says:
    published on November 5th 2007, 12:07:23 am *

    By Celik’s own "80/20" rule, non-traditional genders are "edge cases" and need not be considered; an issue he has so far neglected to address.

    Reply

  7. Lars Strojny responses:
    published on November 5th 2007, 08:50:29 am *

    Hi Andy, thanks for your remark. I honestly think this is not a topic where to apply the 80/20 ratio. Problem here is, that it matters who to count. The reason is, that gender identities are an urban phenomenon (has a lot to do with urban anonymity etc. pp.) and therefore I would guess it is not hard to find a group of people where the 80/20 is a reasonable argument for a more diverse gender expression scheme. So 80/20 becomes a 70/30 or something (just a guess, of course) for that group. You could answer, that 80/20 must be counted overall, ok, but I’m not sure wheither it is worth ignoring. I mean, for a german web project I could easily apply the 80/20 rule for the color of the skin, but I just would not do it because it is my willing to represent minorities.

    Reply

  8. Tantek means:
    published on November 5th 2007, 07:53:41 pm *

    Lars, you make excellent points.

    Andy is correct that the microformats process does try to focus a microformat on representing the approximate 80/20 of published examples in the wild. This is the 80/20 principle that is referenced in the process page:

    http://microformats.org/wiki/process

    When applying to information about arbitrary data or objects, this helps focus an effort on "real world" uses rather than spending lots of time solving edge cases.

    I do think there may be a class of exceptions to the 80/20 rule however that are worthy of considerations, and those have to do with attributes of people or individuals. The general reasoning being that while 80/20 is a fine simplifying rule for objects, technical solutions should at least allow for diversity in people.

    In this class of exceptions I can see the following:

    • 1. cultural/linguistic background – internationalization
    • 2. (dis)ability – accessibility
    • 3. and gender

    These are the specific areas where I think it is worthy of merit to consider exceptions to the 80/20 rule, and I think it echoes the same sentiment you give about willing to represent minorities.

    Reply

  9. Lars Strojny says:
    published on November 6th 2007, 12:14:45 pm *

    Yes, your three points sum up pretty well what I meant by willingness to represent minorities.

    Reply

  10. Andy Mabbett reckons:
    published on November 6th 2007, 04:51:53 pm *

    You thank me for my comment, but have deleted it?

    Reply

  11. Lars Strojny supposes:
    published on November 6th 2007, 05:31:50 pm *

    Oh, sorry. Think I’m not able to run a weblog. I will readd it from my backup.

    Reply

Add a Comment & let me know what you think