FOAF functional datatype properties
Aidan Hogan
Just a not-so-quick email about FOAF functional datatype properties, namely
foaf:age, foaf:birthday, foaf:gender
I'm wondering if it might make sense for the FOAF documentation to be a
little more explicit/strict on what forms the values of these properties
should take?
If a person has two slightly different values for the same such property
(e.g., "Male", "male", "male"@en for gender; or "12-04", "12-4",
"--12-04"^^xsd:gMonthDay for birthday; or so forth) this causes an
inconsistency. Actually, this is great: we've been using this for
figuring out when smushing goes wrong (e.g., smushing male and female
users of opera).
However, I think the FOAF documentation should make it a little clearer
what values it expects for these properties to avoid inadventent
clashes. There is some guidance for gender and for birthday in the docs,
so maybe it's sufficient to highlight the importance of keeping to
recommended values, and maybe to discourage use of language tags for
gender, make datatype (or lack thereof) recommendations explicit, etc.
Find attached stats extracted from use of these properties from the BTC
11 corpus; a summary:
* foaf:age is very rarely used.
* foaf:gender is mainly used by opera and hi5, and keeps largely to
"male"|"female" values; few language tags at the moment
* foaf:birthday is mainly used by hi5, but breaks the spec
recommendation for "MM-DD" values, having instead e.g., "1-1", "3-12".
In summary, it's not a big problem at the moment, but it might be a good
time to clarify issues around these properties earlier rather than
later, and to emphasise the importance of consistency in values.
Cheers,
Aidan
P.S.,
Aside from legacy data, my preferences would be:
* a nonNegativeInteger value for age (or deprecate the property since it
tends to go stale)
* a gYearMonth for birthday, and
* "male"|"female"|<other lowercase value> for gender. [no language tags]
...but it might be too late for that.