This note is both an earlybird (and partial) technical review of the new SPARQL RDF query spec and a proposal to the DC-Architecture Working Group for a possible representation language that captures some rules that explain how some different forms of DC relate to each other. As a review, I have to say that I now find CONSTRUCT more useful than I originally expected. Maybe a full W3C RDF Rules language would be a useful thing to do after all… :)
The Dublin Core metadata vocabulary is used sometimes as a set of relationships between documents (etc.) and other resources (entities, things); and sometimes as a set of relationships to textual strings associated with those things. The DCMI Abstract Model document gives some more detail on this, and proposes a model to explain DC thinking on this issue. Appendix B of that
document describes the mapping of this abstraction into RDF.
One option (todo: find url of Andy’s doc listing options) being explored by the DC-Architecture WG is for Dublin Core to publish explicit guidelines explaining how the two representational idioms can be interconverted. What I try to do below is capture DC community concensus about how the two styles of using properties from the http://purl.org/dc/elements/1.1/ vocabulary compare.
The rules in prose:
Rule 1: Whenever we see a DC property from http://purl.org/dc/elements/1.1/ applied to some resource ‘x’, and the value of that resource is something that is not a literal (ie. a string or markup), then any values of the rdfs:label property which apply to that thing, are also values of our DC property. eg. if a document has a dc:creator whose value is a thing that has an rdfs:label “Andy Powell”, then it is also true that the document has a dc:creator property whose value is the literal string “Andy Powell”.
Rule 2: As above, but reversed. Whenever there is some string that is an rdfs:Literal that is the value of a DC property for some resource ‘x’, then it will also be true that there exists some resource that is not an rdfs:Literal, and that has an rdfs:label whose value is that string, and that ‘x’ stands in the same DC property relationship to that resource.
Problem statement: this sort of thing is (see above) hard to express in prose, we’d like a clean machine-readable way of expressing these rules, so that test cases can be formulated, mailing list discussions can be made more precise, and (perhaps) so that software tools can directly exploit these rules to use with RDF.
The SPARQL query language is a W3C work-in-progress for querying RDF data. It mainly provides some mechanisms for specifying bits of RDF to match in some query, but also provides a basic mechanism for CONSTRUCTing further RDF statements based on combining matched data with a template structure. This is a preliminary investigation into the possibility of using SPARQL’s CONSTRUCT mechanism to express the rules being discussed in the DC community. Readers should note that both SPARQL and the DC “idiom conversion rules” are both works in progress, and that I might not have full grasp of either.
Anyway, here goes:
Rule 1 in SPARQL: generate simple form from explicit form
PREFIX dc: <http ://purl.org/dc/elements/1.1/> PREFIX rdfs: <http ://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http ://www.w3.org/1999/02/22-rdf-syntax-ns#> CONSTRUCT ( ?x ?relation ?string ) WHERE ( ?x ?relation ?thing ) ( ?thing rdf:type x:NonLiteralResource) ( ?thing rdfs:label ?string) ( ?relation rdfs:isDefinedBy http://purl.org/dc/elements/1.1/)
Rule 2 in SPARQL: explicit form from string form (harder)
PREFIX dc: <http ://purl.org/dc/elements/1.1/> PREFIX rdfs: <http ://www.w3.org/2000/01/rdf-schema#> PREFIX rdf: <http ://www.w3.org/1999/02/22-rdf-syntax-ns#> CONSTRUCT ( ?x ?relation ?thing ) ( ?thing rdfs:label ?string) WHERE ( ?x ?relation ?string ) ( ?string rdf:type rdfs:Literal) ( ?relation rdfs:isDefinedBy http://purl.org/dc/elements/1.1/)
See also: comments in SPARQL draft on “what if construct graph includes unbound variables”…
followup: Dan Connolly and others have noted that I should be careful not to advocate the use of SPARQL as a Rule language. I lost his specific comments due to problems with WordPress, but agree entirely. What I was trying to do here was see how it might look if one did try to express rules using these queries, to better understand how the two technologies relate. Please don’t consider SPARQL a rule language (but please do share your experiences with having RDF Rule, Query and OWL languages work together…).