[uf-discuss] collaboration between FOAF and Microformat approaches on representing gender

Toby A Inkster mail at tobyinkster.co.uk
Thu Apr 3 03:40:17 PST 2008

Dan Brickley wrote:

 > Does it make sense to carry through that 'x'?
 > http://tools.ietf.org/html/draft-resnick-vcarddav- 

I've not seen that draft. Looks interesting. Right now, Cognition's  
extensions to hCard are all "x-" prefixed. It will *parse* them  
without the "x-", but will include the "x-" in output. Cognitions's  
hCard extensions are documented here:


 > I'm very interested to have collaboration between FOAF and
 > Microformat approaches on representing gender

The way that Cognition resolves the differences between FOAF/RDF and  
hCard is this:

1. RDF requires that each triple has a subject URI. For hCard that  
subject URI is the hCard's "uid" property. If no UID property exists,  
a fake one is created using the "fn" and the "ldap:" URI scheme.
2. RDF requires that predicates must be a URI. hCard properties are  
simply namespaced into "urn:ietf:rfc:2426#".

That's pretty much it. hCalendar and hAtom are handled in pretty much  
the same way. All data gleaned from microformats is just internally  
represented as RDF triples.

Because of the intermediate triple-store which is shared by all of  
Cognition's parsers (microformats, RDFa, eRDF, GRDDL, etc), when  
output is being generated (e.g. vCard output), Cognition doesn't make  
any distinction as to where the data came from. So an hCard without  
any e-mail addresses might actually pick up (from RDFa, etc) some e- 
mail addresses when output as vCard.

I like to call this "gainy" conversion (in contrast to lossy). For an  
example of gainy conversion take a look at the hCard to jCard  
implementation I just posted. In the example output, the mobile phone  
number (amongst other properties) wasn't included in the input hCard.

In terms of gender, Cognition basically just accepts any string. The  
only special handling for gender is that if the subject has an  
rdf:type of w3cpim:Male or w3cpim:Female, then the gender string is  
taken to be "Male" or "Female" respectively. w.r.t. inclusiveness,  
accepting a free-form string is pretty much the only option.

Toby A Inkster
<mailto:mail at tobyinkster.co.uk>

More information about the microformats-discuss mailing list