Ivan’s private site

December 16, 2011

Where we are with RDFa 1.1?

English: RDFa Content Editor

Image via Wikipedia

There has been a flurry of activities around RDFa 1.1 in the past few months. Although a number of blogs and news items have been published on the changes, all those have become “officialized” only the past few days with the publication of the latest drafts, as well as with the publication of RDFa 1.1 Lite. It may be worth looking back at the past few months to have a clearer idea on what happened. I make references to a number of other blogs that were published in the past few months; the interested readers should consult those for details.

The latest official drafts for RDFa 1.1 were published in Spring 2011. However, lot has happened since. First of all, the RDFWA Working Group, working on this specification, has received a significant amount of comments. Some of those were rooted in implementations and the difficulties encountered therein; some came from potential authors who asked for further simplifications. Also, the announcement of schema.org had an important effect: indeed, this initiative drew attention on the importance of structured data in Web pages, which also raised further questions on the usability of RDFa for that usage pattern This came to the fore even more forcefully at the workshop organized by the stakeholders of schema.org in Mountain View. A new task force on the relationships of RDFa and microdata has been set up at W3C; beyond looking at the relationship of these two syntaxes, that task force also raised a number of issues on RDFa 1.1. These issues have been, by and large, accepted and handled by the Working Group (and reflected in the new drafts).

What does this mean for the new drafts? The bottom line: there have been some fundamental changes in RDFa 1.1. For example, profiles, introduced in earlier releases of RDFa 1.1, have been removed due to implementation challenges; however, management of vocabularies have acquired an optional feature that helps vocabulary authors to “bind” their vocabularies to other vocabularies, without introducing an extra burden on authors (see another blog for more details). Another long-standing issue was whether RDFa should include a syntax for ordered lists; this has been done now (see the same blog for further details).

A more recent important change concerns the usage of @property and @rel. Although usage of these attributes for RDF savy authors was never a real problem (the former is for the creation of literal objects, whereas the latter is for URI references), they have proven to be a major obstacle for ‘lambda’ HTML authors. This issue came up quite forcefully at the schema.org workshop in Mountain View, too. After a long technical discussion in the group, the new version reduces the usage difference between the two significantly. Essentially, if, on the same element, @property is present together with, say, @href or @resource, and @rel or @rev is not present, a URI reference is generated as an object of the triple. I.e., when used on a, say, <link> or <a> element, @property  behaves exactly like @rel. It turns out that this usage pattern is so widespread that it covers most of the important use cases for authors. The new version of the RDFa 1.1 Primer (as well as the RDFa 1.1 Core, actually) has a number of examples that show these. There are also some other changes related to the behaviour of @typeof in relations to @property; please consult the specification for these.

The publication of RDFa 1.1 Lite was also a very important step. This defines a “sub-set” of the RDFa attributes that can serve as a guideline for HTML authors to express simple structured data in HTML without bothering about more complex features. This is the subset of RDFa that schema.org will “accept”,  as an alternative to the microdata, as a possible syntax for schema.org vocabularies. (There are some examples on how some schema.org example look like in RDFa 1.1 Lite on a different blog.) In some sense, RDFa 1.1 Lite can be considered like the equivalent of microdata, except that it leaves the door open for more complex vocabulary usage, mixture with different vocabularies, etc. (The HTML Task Force will publish soon a more detailed comparison of the different syntaxes.)

So here is, roughly, where we are today. The recent publications by the W3C RDFWA Working Group have, as I said, ”officialized” all the changes that were discussed since spring. The group decided not to publish a Last Call Working Draft, because the last few weeks’ of work on the HTML Task Force may reveal some new requirements; if not, the last round of publications will follow soon.

And what about implementations? Well, my “shadow” implementation of the RDFa distiller (which also includes a separate “validator” service) incorporates all the latest changes. I also added a new feature a few weeks ago, namely the possibility to serialize the output in JSON-LD (although this has become outdated a few days ago, due to some changes in JSON-LD…). I am not sure of the exact status of Gregg Kellogg’s RDF Distiller, but, knowing him, it is either already in line with the latest drafts or it is only a matter of a few days to be so. And there are surely more around that I do not know about.

This last series of publications have provided a nice closure for a busy RDFa year. I guess the only thing now is to wish everyone a Merry Christmas, a peaceful and happy Hanukkah, or other festivities you honor at this time of the year.  In any case, a very happy New Year!

Enhanced by Zemanta


  1. Great summary! I just noticed a small error: “@profile” is mentioned in two places where it should be “@property” (in the section about how @property now behaves like @rel in the presence of a resource attribute). Anyway, thanks for the writeup!

    Comment by Niklas Lindström — December 16, 2011 @ 16:35

    • Oops… thanks Niklas. I have changed the text accordingly…

      Comment by Ivan Herman — December 16, 2011 @ 17:31

  2. […] Where we are with RDFa 1.1? […]

    Pingback by Distributed Weekly 133 — Scott Banwart's Blog — December 16, 2011 @ 16:40

  3. Thanks for this helpful summary. I especially liked “In some sense, RDFa 1.1 Lite can be considered like the equivalent of microdata, except that it leaves the door open for more complex vocabulary usage, mixture with different vocabularies, etc.” Makes perfect sense. However, regarding the current state of RDFa 1.1 I’m somehow struggling with the question how Google Search (resp. schema.org) is seeing my markup. The Rich Snippets Tool does not seem to recognize RDFa 1.1 while it does work with 1.0. Am I wrong here? And, if not, do you have any further information on RDFa 1.1 support by Google resp. the snippets tool? Thx.

    Comment by Hendrik Bunke — December 20, 2011 @ 16:32

    • Hendrik,

      I cannot really comment on the details. What we know, ie, what has been announced, is that the schema.org participants (Google, Yahoo!, Bing, and, I possibly, Yamdex) would ‘parse’, ie, interpret for their own purposes, RDFa 1.1 Lite the same way as they will use the microdata syntax with schema.org terms. How and when is something I do not have information on. Mind you, schema.org and its usage is an evolving technology, and we should be watchful for new announcements. I also do not know whether Google would retrofit this to Rich Snippets or not.

      The best is… to ask them:-). Maybe some of the schema.org people (DanBri?) read these lines…

      Comment by Ivan Herman — December 20, 2011 @ 17:23

      • Ivan, thanks for replying. I think I’ll rely on your Distiller and hope that some Google people will come up with an answer somewhen or somewhere.

        Comment by Hendrik Bunke — December 20, 2011 @ 17:35

  4. […] his private website, Ivan Herman recently commented on the current status of RDFa 1.1. Herman stated, “There has been a flurry of activities around RDFa 1.1 in the past few months. […]

    Pingback by The Current State of RDFa 1.1 - semanticweb.com — December 20, 2011 @ 20:01

  5. Personally, I am anxiously awaiting the “end of the drama” for RDFa. I want to use RDFa because I see it as more of a “specialization” than as a specification.

    XML allows the creation of arbitrary data containers and, based on my understanding, RDFa would provide all the necessary semantics for those containers. If fully specialized and implemented, RDFa would place XML at the top of the markup food chain where it rightfully belongs.

    The problem I see is that the big three who could make RDFa (and, collaterally, XML) a viable option are devising their own syntax that obviously usurps the RDFa agenda. The developers of schema.org are all members of W3C and, yet, instead of working to implement RDFa, they have come up with a seemingly more attrative (based on SEO purposes) alternative to the plan suggested by the W3C…and the W3C is accommodating schema.org’s effort.

    RDFa (in its full version) would make it so easy to incomporate semantics into almost every element imaginable. With RDFa, a hyperlink could easily be defined as, for example, Some Site; not traditional, but well-formed, semantic, and potentially valid.

    Why is schema.org (of which the creators are members of the W3C) being celebrated by the W3C when schema.org could help push RDFa and semantics to full acceptance and realization?

    This blog is informative, but what happens when schema.org decides not to support RDFa? Will RDFa be placed on the shelf? Is it worth adding RDFa to web documents if schema.org more easily recognize their own syntax?

    schema.org attracts more web authors because of its connection to SEO. What is the selling point for RDFa after that? If the W3C will not fully back up RDFa and allow its members to usurp its efforts towards a semantic web, then what can be said about RDFa to convince web authors to inflate their documents with it?

    Comment by H.E.A.T. — December 23, 2011 @ 4:54

    • First of all, to be fair: schema.org did not invent their own syntax. That syntax (microdata) had been around for a while, in parallel to RDFa, and schema.org made the choice, in around April this year, to adopt microdata first. The choice was controversial indeed, and started a lot of discussion, of course, but the fact remain: they did not invent something. In other words, the question on that level is why were there two syntaxes in development, namely RDFa and microdata. And the reasons for that are really very complicated and I am probably not the appropriate person to answer that: first of all, I am active member of the W3C RDFa Working Group (i.e., biased) but, maybe even more importantly, I am also part of the W3C staff. But I would prefer to leave this to history.
      However… there is a public blog of schema.org that puts an end to the discussion: schema.org will use RDFa Lite alongside microdata. I.e., it becomes a matter of choice which syntax to use. There is also a document in preparation (at this moment, only an editor’s draft is available) which looks at the different syntaxes to help in this choice. Finally, there is no issue around “W3C will not fully back up RDFa”: RDFa is fully backed by W3C.

      Comment by Ivan Herman — December 23, 2011 @ 8:06

      • I understand that schema.org did not actually create or invent a new syntax, but the point I wanted to make is that schema.org is a member of the W3C and the W3C is working on RDFa. I would think, as a member, schema.org would have worked towards implementing RDFa. If not, then maybe I am not understanding the goal of membership in the W3C.

        If my understanding is correct, RDFa is supposed to supply a generic syntax whereby other, individually developed, vocabularies could be used. Syntax aside, stablilizing a vocabulary appears difficult enough, especially considering the 8 stable terms of FOAF. schema.org makes sense as far as developing a search vocabulary, but why use a different syntax? Why not fully support their own consortium?

        Now, even before RDFa 1.1 is finalized, we have RDFa Lite; another specification to muddle the waters. If RDFa is generic, then why do we need a watered-down, or streamlined, version? RDFa Lite appears to accommodate schema.org more than anything else.

        Having multiple choices does not produce an efficient semantic web. As have already been proven, having many alternate choices to do the same things often result in more things being done wrong.

        If schema.org found something that it did not like about RDFa, maybe the more “member-loyal” approach would have been to revise RDFa and use that revision. One syntax and multiple vocubalaries: with schema.org backing up this effort, the semantic web would become more stable.

        Thanks for responding and no disrespect intended.

        Comment by theheatexchange — December 24, 2011 @ 5:33

        • First of all, referring to your last remark: no disrespect taken! 🙂

          In the interest of fairness: schema.org, more exactly the members of schema.org, have chosen one W3C spec over the other, i.e., they chose microdata (part of the HTML5 standard-to-be) over RDFa 1.1 (another standard-to-be). In other words, the blame should not be on the fact that they’ve made a choice. The work on RDFa 1.1 of the past few months have done a lot (o.k., this is my subjective assessment) to bring these two closer, and this was done, to a large extend, because the schema.org members have given us very clear comments on RDFa 1.1. to make it usable for them. A bit late, I agree, but better late than never. And schema.org now acknowledges this duality and simply lives with it by accepting both syntaxes. From their point of view, that is a very pragmatic reaction.

          The blame, if we want to understand the situation, is rather on us, i.e., W3C at large, to allow two, parallel standards in developments that clearly overlap in functionality. Put it another way, W3C members (including of course the members of schema.org, but others, too) could have, or should have, intervened on that issue way earlier. The blame is… on all of us, really, including all W3C members. B.t.w., this is not a totally unheard-of situation: we do have SVG and Canvas within HTML5, we did have CSS and XSLT side-by-side… But, at this point, this is history, which cannot really be changed.

          Actually, I do not regard RDFa Lite as a “watered-down” version; it is simply a subset of RDFa that is suited for authors who do not know about Semantic Web, nor are they interested by it. Because Lite is a strict subset of RDFa 1.1, authors can later “upgrade” their content if they wish to, but they can adhere to Lite and do a lot already. Yes, schema.org benefits from that but not only; for example, adding Dublin Core terms to a page can be done, I think, with RDFa Lite easily, and I would not be surprised if DCMI would advise authors to use that level. I regard this type of authors’ simple view as helpful; I would, to take again a different example, be pleased to have such a subset of CSS at my disposal if all I want is to do simple formatting and I would not have to go through the maze of the full CSS specification (which I do find daunting sometimes). RDFa Lite is between a good Primer and a full spec, in some way…

          Merry Xmas and a very Happy New Year!

          Comment by Ivan Herman — December 24, 2011 @ 9:51

RSS feed for comments on this post.

Blog at WordPress.com.

%d bloggers like this: