W3C has just published two RDFa 1.1 documents. In the W3C jargon these are called “First Public Working Drafts”, which means that they are by no means complete and features may still change based on community feedback. However, they document the intentions of the Working Group as for the direction it thinks it should take. (Note that another FPWD, namely an RDFa API specification, should follow very soon; hopefully a new version of the HTML+RDFa will be issued soon, too, incorporating these changes.) It may be interesting to summarize some of the important changes compared to the previous version of RDFa; that is what I will attempt to do. By the way, if you want to comment on RDFa 1.1, I would prefer you commented on the Group’s dedicated mailing list rather than on this blog: email@example.com (see also the archives).
So, what are the new things?
1. Separation of RDFa 1.1 Core and RDFa 1.1 XHTML. This is one of the differences visible immediately: instead of one specification (which was the case for RDFa 1.0) we have now two. This comes from the fact that the RDFa attributes may be, and have already been, used in XML languages other than XHTML (SVG or ODF are good examples). Separation of the Core and the XHTML specific features is just a to make such adaptations cleaner. (I will use XHTML examples in this blog, though.)
2. Default term URI (a.k.a. @vocab attribute). RDFa 1.0 has a number of terms that can be used with attributes like @rel or @rev without any further qualifications. Examples are ‘next’ or ‘license’. These values were “inherited” by RDFa 1.0 from HTML; the spec simply assigned a URI for each of those to use them as RDF properties (eg, http://www.w3.org/1999/xhtml/vocab#next or http://www.w3.org/1999/xhtml/vocab#license).
However, a more flexible way of defining such terms, ie, not sticking to a fixed set and URI-s, is very useful for HTML authors in general. That is achieved by the new @vocab attribute: it defines a ‘default term URI’ that is concatenated with any term to form a URI. The mechanism can be applied to most of the RDFa attributes, not only to @rel and @rev. For example, the following RDFa 1.1 code:
<div vocab="http://xmlns.com/foaf/0.1/"> <p about="#me" typeof="Person" property="name">Ivan Herman</p> </div>
will generate the familiar FOAF triples:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . <#me> a foaf:Person; foaf:name "Ivan Herman" .
The effect of @vocab is of course valid for the whole subtree starting at <div> (unless another @vocab takes it over somewhere down the line). This makes simple annotations with RDFa very easy for authors who do not want to deal with the intricacies of URI-s and CURIE-s.
3. Profile documents for terms. The problem with the @vocab mechanism is that it works only with one vocabulary. However, in many cases, one want to mix vocabularies: after all, this is one of the main advantages of using RDF (and hence RDFa). Eg, one would like to encode something like:
@prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix rel: <http://vocab.org/relationship/> . <#me> a foaf:Person; foaf:name "Ivan Herman" ; rel:spouseOf <http://www.ivan-herman.net/Eva_Boka> .
A solution is to use a profile document. This is a simple RDF document that can be made available in various serializations (though only RFDa is mandatory for an RDFa processor) and describes the mapping of terms to URIs. Eg, one could define the http://example.org/simple-profile.ttl file (using here Turtle syntax for simplicity):
@prefix rdfa: <http://www.w3.org/ns/rdfa#> .  rdfa:uri "http://vocab.org/relationship/spouseOf"; rdfa:term "spouse" .  rdfa:uri "http://xmlns.com/foaf/0.1/name"; rdfa:term "name" .  rdfa:uri "http://xmlns.com/foaf/0.1/Person"; rdfa:term "Person" .
and use that document in an RDFa file as follows:
<div profile="http://example.org/simple-profile.ttl"> <p about="#me" typeof="Person" rel="spouse" resource="http://www.ivan-herman.net/Eva_Boka" property="name">Ivan Herman</p> </div>
yielding the triples we wanted. Note that the @profile attribute allows for several URIs, ie, for several profile documents, and the corresponding term definitions are merged. Here again, a @profile attribute down the tree will supersede term definitions.
Of course, using the profile document is a heavier mechanism and requires, at least conceptually, an extra HTTP request. I am sure there will be community comments on that. However, I personally do not expect average authors to fiddle around much with those profile files. Instead, vocabulary publishers like Google, Yahoo, Facebook, Dublin Core, or Creative Commons may publish the terms they use and understand in the form of such profile documents, and authors could simply refer to those. RDFa tools could (and are encouraged to) cache the information stored in those widely used profile documents which alleviates the HTTP request issue in practice.
4. Profile documents for prefixes. Using profile documents for terms is great but it does not scale very well. If the vocabularies are large then publishers of those vocabularies would have to create and maintain fairly large files. In such cases the CURIE mechanism, already defined in RDFa 1.0, becomes a good alternative: instead of having a separate URI defined explicitly for each term, one can use an abbreviations for the “base” URIs of those vocabularies via prefixes.
In RDFa 1.0 this required an author to add a series of ‘xmlns:XXX’ attributes to the RDFa content. That mechanism is still valid in RDFa 1.1, but one can also define prefixes as part of a profile document. Eg, the previous turtle fragment could have been written as
@prefix rdfa: <http://www.w3.org/ns/rdfa#> .  rdfa:uri "http://vocab.org/relationship/"; rdfa:prefix "relation" .  rdfa:uri "http://xmlns.com/foaf/0.1/"; rdfa:prefix "foaf" .
and the RDFa fragment would then look like:
<div profile="http://example.org/simple-profile.ttl"> <p about="#me" typeof="foaf:Person" rel="relation:spouse" resource="http://www.ivan-herman.net/Eva_Boka" property="foaf:name">Ivan Herman</p> </div>
to generate the same triples as before. This mechanism may become important, as I said, when several large vocabularies (or simply a large number of vocabularies) are used.
5. Usage of @prefix to define CURIE prefixes. Actually, the usage of the xmlns:XXX syntax to set CURIE prefixes was (and is) controversial; there may be host languages that do not work with such attributes. RDFa 1.1 provides therefore an alternative which, though semantically identical, avoids the usage of a ‘:’ character in the attribute name. Using this @prefix attribute an alternative to the previous RDFa could be:
<div prefix="relation: http://vocab.org/relationship/ foaf: http://xmlns.com/foaf/0.1/"> <p about="#me" typeof="foaf:Person" rel="relation:spouse" resource="http://www.ivan-herman.net/Eva_Boka" property="foaf:name">Ivan Herman</p> </div>
which looks very much like an RDFa 1.0 document but using the @prefix attributes instead of @xmlns:foaf and @xmlns:relation. The old @xmlns: approach remains valid, of course, but the new one is preferred from now on.
6. URIs everywhere. The final item I mention is the possibility to use URI-s everywhere, ie, to bypass the CURIE abbreviation mechanism if so desired. Whereas some of the RDFa 1.0 attributes required the usage of CURIE-s (eg, @rel or @property), this is no longer true in RDFa 1.1. The rules are fairly simple: if an attribute value is of the form ‘pp:xxx’ and the ‘pp’ string cannot be interpreted as a CURIE prefix then the string ‘pp:xxx’ is considered to be a URI and is treated as such in the generated RDF. That also means that CURIE-s can be used in @about and @resource without the slightly awkward ‘safe’ CURIE-s.
The development of RDFa 1.1 is obviously not done yet; lots of details are to be checked, and some additional minor features (eg, possible changes on the handling of XML Literals) are still to be worked out. And, first and foremost, community comments on the directions taken are important. But these First Public Working Drafts give the general direction…