After following a link from one of Nad’s tweets, read Jeni Tennison’s “SPARQL & Visualisation Frustrations: RDF Datatyping“. Jeni had been having problems processing RDF of MP’s expense claims, because the amounts were plain RDF strings rather than as typed numbers. She suggests some best practice rules for data types in RDF based on the underlying philosophy of RDF that it should be self-describing:
- if the literal is XML, it should be an XML literal
- if the literal is in a particular language (such as a description or a name), it should be a plain literal with that language
- otherwise it should be given an appropriate datatype
These seem pretty sensible for simple data types.
In work on the TIM project with colleagues in Athens and Rome, we too had issues with representing data types in ontologies, but more to do with the status of a data type. Is a date a single thing “2009-08-03T10:23+01:00″, or is it a compound [[date year=”2009″ month=”8” …]]?
I just took a quick peek at how Dublin Core handles dates and see that the closest to standard references still include dates as ‘bare’ strings with implied semantics only, although one of the most recent docs does say:
“It is recommended that RDF applications use explicit rdf:type triples …”
and David MComb’s “An OWL version of the Dublin Core” gives an alternative OWL ontology for DC that does include an explicit type for dc:date:
<owl:DatatypeProperty rdf:about="#date">
<rdfs:domain rdf:resource="#Document"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#dateTime"/>
</owl:DatatypeProperty>
Our solution to the compound types has been to have “value classes” which do not represent ‘things’ in the world, similar to the way the RDF for vcard represents complex elements such as names using blank nodes:
<vCard:N rdf:parseType="Resource">
<vCard:Family> Crystal </vCard:Family>
<vCard:Given> Corky </vCard:Given>
...
</vCard:N>
From
This is fine, and we can have rules for parsing and formatting dates as compound objects to and from, say, W3C datetime strings. However, this conflicts with the desire to have self-describing RDF as these formatting and parsing rules have to be available to any application or be present as reasoning rules in RDF stores. If Jeni had been trying to use RDF data coded like this she would be cursing us!
This tension between representations of things (dates, names) and more semantic descriptions is also evident in other areas. Looking again at Dublin Core the metamodal allows a property such as “subject” to have a complex object with a URI and possibly several string values.
Very semantic, but hardly mashes well with sources that just say <dc:subject>Biology</dc:subject>. Again a reasoning store could infer one from the other, but we still have issues about where the knowledge for such transformations resides.
Part of the problem is that the ‘self-describing’ nature of RDF is a bit illusary. In (Piercian) semiotics the interpretant of a sign is crucial, representations are interpreted by an agent in a particular context assuming a particular language, etc. We do not expect human language to be ‘sef describing’ in the sense of being totally acontextual. Similarly in philosophy words and ideas are treated as intentional, in the (not standard English) sense that they refer out to something else; however, the binding of the idea to the thing it refers to is not part of the word, but separate from it. Effectively the desire to be self-describing runs the risk of ignoring this distinction.
Leigh Dodds commented on Jeni’s post to explain that the reason the expense amounts were not numbers was that some were published in non-standard ways such as “12345 (2004)”. As an example this captures succinctly the perpetual problem between representation and abstracted meaning. If a journal article was printed in the “Autumn 2007” issue of quarterly magazine, do we express this as <dc:date>2007</dc:date> or <dc:date>2007-10-01</dc:date> attempting to give an approximation or inference from the actual represented date.
This makes one wonder whether what is really needed here is a meta-description of the RDF source (not simply the OWL as one wants to talk about the use of dc:date or whatever in a particular context) that can say things like “mainly numbers, but also occasionally non-strandard forms”, or “amounts sometimes refer to different years”. Of course to be machine mashable there would need to be an ontology for such annotation …
