Dan Brickley wrote:
> Does it make sense to carry through that 'x'?
> http://tools.ietf.org/html/draft-resnick-vcarddav-
vcardrev-01#section-5.2.9
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:
http://buzzword.org.uk/cognition/uf-plus.html#hcard
> 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:[EMAIL PROTECTED]>
<http://tobyinkster.co.uk>
_______________________________________________
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
