Recent changes in RDFa 1.1

Part of Data

Author(s) and publish date

By:
Published:

The past few months have been busy for RDFa 1.1. Although the RDFWA Working Group has published a 2nd Last Call in Spring, new issues came up in summer that forced the group to continue its technical work (which will result, hopefully soon, in a 3rd Last Call). These issues were the results of implementation experiences, but also the outcome of discussions that followed the schema.org announcements, e.g., on looking more closely at the relationships between HTML5 microdata and RDFa. (The blog series of Jeni Tennison is probably the best summary of these discussions.) The changes outlined below are not yet published in an official Working Draft, but the editor’s draft is of course available (as well as the editor’s draft of the RDFa 1.1 Primer which also reflects the latest changes).

There are three noteworthy changes compared to previous versions: removal of profiles with, in parallel, some additional, though not mandatory features with vocabularies; introduction of a syntax to generate RDF lists; and a change in the behavior of the @src attribute.

The change in handling @src is minor, but the original behavior in RDFa 1.0 was considered as a major source of errors and misinterpretations in RDFa 1.0. Essentially, @src behaved as @about in RDFa 1.0; from now on, it will behave like @resource (or @href). This creates a backward incompatibility with RDF 1.0 but only in some border cases; on the other hand, it will avoid many unexpected triples.

Introduction of a syntactic sugar for the generation of RDF Lists has been on the agenda for a long time, but the “sweet spot” in terms of syntax and processing was never properly explored. Triggered also by Jeni’s post, this work was now done. As a result, in RDFa 1.1, it is possible to say, for example:

<p prefix="bibo: http://purl.org/ontology/bibo/
           dc: http://purl.org/dc/terms/ typeof="bibo:Chapter">
  “<span property="dc:title">Semantic Annotation and Retrieval</span>”, by
  <span inlist="" property="dc:creator">Ben Adida</span>,
  <span inlist="" property="dc:creator">Mark Birbeck</span>, and
  <span inlist="" property="dc:creator">Ivan Herman</span>.
</p>
which will result in:
@prefix bibo: <http://purl.org/ontology/bibo/> .
@prefix dc: <http://purl.org/dc/terms/> .
[] a bibo:Chapter ;
   dc:title "Semantic Annotation and Retrieval" ;
   dc:creator ("Ben Adida" "Mark Birbeck" "Ivan Herman") .
There are some more examples on the list syntax in the Editor’s draft.

The removal of the profile feature is, of course, the most fundamental change. I have blogged about profiles elsewhere. Suffices it to say that profiles were a mechanism whereby prefix and term declarations could be stored in an external file; RDFa 1.1 processors were supposed to get those files and add the prefix declarations to the local ones. Although the concept is very elegant, its implementation raised a number of issues. After some discussions (and soul searching:-) the Working Group decided to remove this feature altogether except for what was called the default profiles (not clear whether the same terminology will be used, but that is only an editorial issue).

To help linking to external vocabularies nevertheless, RDFa 1.1 introduced a new optional feature. By default, the behavior of the @vocab attribute remains unchanged. However, RDFa 1.1 processors may use the URI in the @vocab to retrieve an RDFS vocabulary, perform a very simple entailment, and the entailment results to the output graph. “Very simple”, because all an RDFa 1.1 is expected to do is to follow subclass and subproperty relationships (of course, processors may choose to perform a complete RDFS or OWL entailment, but that is outside of what the RDFa 1.1 specification requires). Essentially, an RDFa 1.1 processor may implement a “follow-your-nose” mechanism on vocabularies.

Let us take an example. One may have:

<span vocab="http://www.example.org/myvocab/" property="title">Nice title</span>
which, by default, results in:
<> <http://www.example.org/myvocab/title> "Nice title" .
however, the http://www.example.org/myvocab/ may contain the RDFS relationship:
<http://www.example.org/myvocab/title>
  rdfs:subPropertyOf <http://purl.org/dc/terms/title>
If the RDFa 1.1 processor implements the vocabulary expansion and if the user instructs it to do so, the original RDFa 1.1 markup will then result in:
<> <http://www.example.org/myvocab/title> "Nice title" ;
   <http://purl.org/dc/terms/title> "Nice title" .
In other words, the author of http://www.example.org/myvocab/ can link his/her vocabulary to the widely used one, without complicating the task of the end-user.

The new RDFa 1.1 features are, as I said, already documented. There are also implementations: Gregg has updated his Ruby based implementation to reflect, as far as I know, all the recent changes, and I have also updated my “shadow” RDFa distiller to do the same (with the usual caveat of possible errors…).

As usual, comments are very welcome but, if possible, on the RDFa mailing list rather than on this post: public-rdfa-wg@w3.org.

Related RSS feed

Comments (0)

Comments for this post are closed.