Introduction to RDFa II
Issue № 287

Introduction to RDFa II

In part I of this series, we looked at how semantic features normally confined to the head of an HTML document can be used to add semantic richness to the elements of the body. Along the way, we defined six rules of RDFa:

Article Continues Below
  1. The link and a elements imply that there is a relationship between the current document and some other document; the @rel attribute allows us to provide a value that will better describe that relationship.
  2. The @rel and @href attributes are no longer confined to the a and link elements, but can also be used on img to indicate a relationship between the image and some other item.
  3. In ordinary HTML, properties are set in the head of the document, using @content with meta. In HTML documents with RDFa, @content can be used to set properties on any element.
  4. Although HTML uses the @name property to set the name of a property on meta, it can’t be used on other elements, so RDFa provides a new attribute called @property.
  5. If no @content attribute is present, then the value of a property will be set using the element’s inline text.
  6. If the @content attribute is present, it overrides the value in the element’s inline text to set the value of the property.

In part II, we’ll learn how to add properties to an image, and how to add metadata to any item—and we’ll add a few more rules to that list.

Adding properties to an image#section2

In part I, we discussed the fact that in ordinary HTML, @rel is used to specify a relationship between the current document and some other document. We also noted that RDFa generalizes this function so that @rel can be used on an img element; the relationship expressed is between the image (in the @src attribute) and the other document. The same principle applies when properties are placed on the img tag: they too will apply to the image, rather than the current document.

For example, to indicate when an image was created, we might do this:

(Line wraps marked » —Ed.)

<img src="image1.png" property="dc:created"
  content="2009-03-22" />
<img src="image2.png" property="dc:created" 
  content="2009-05-01" />

Rule 7:#section3

Ordinary HTML can only set properties that relate to the page itself, but RDFa allows properties to be set for image URLs, too.

RDFa also allows both a property and a relationship to be expressed for the same image:

<img src="image1.png" rel="license" 
  property="dc:created" content="2009-05-01" />

Adding metadata about any item#section4

Broadly speaking, we’ve made three important steps so far, as we’ve followed the evolution from basic HTML to RDFa:

  • We’ve noted that any of the metadata features that can be used in the head of the document can now be used in the body—although we had to change the @name attribute to @property to do so.
  • We’ve seen how RDFa allows the property and relationship names to come from clearly defined vocabularies, using prefix mappings.
  • We’ve learned that RDFa allows properties and relationships to be expressed about images, as well as about the current document.

If you’re not sure about any of these steps, you might want to go back and take another look before you carry on.

The ability to add properties and relationships to images is something we’ll surely want to generalize to other things. If I can indicate the license for the current document, and the license for images, why can’t I indicate the license for anything I make a reference to in my web page?

For example, let’s say I have some links to a couple of RDFa-related SlideShare presentations:

<a href=" »
gandon/rdfa-in-a-nutshell-v1">RDFa in a »

<a href=" »
/the-5-minute-guide-to-rdfain-only-6-minutes-40- »
seconds">The 5-minute guide to only 6
minutes and 40 seconds</a>

If you look at either of these pages on SlideShare, you’ll see that the licensing information is clearly displayed. But what if we wanted to add the licensing information to the current document, so that a smart browser could do something with it? (The page might be a set of search results, for example, so we might want to show the license to the searcher, as a way to help them when choosing documents.)

We might think that we just use @rel="license" on these anchors, as normal. But recall that this will imply that the current document has a license that is identified by the item in the @href attribute; in this case the “other document” is a SlideShare page, not a license.

So, to make it possible to add more information about any resource we like, RDFa adds a new attribute, called @about. It follows exactly the same pattern as the @src attribute on img—it can have @rel and @property information attached to it—but it can be used on any HTML element. Here’s how we’ll use @about to help us add licensing information about our slides. Our first link:

<a href=" »
/rdfa-in-a-nutshell-v1">RDFa in a nutshell</a>

…is licensed this way by adding the following mark-up:

<a about=" »
/rdfa-in-a-nutshell-v1" rel="license"
  CC BY</a>.

Note that as far as an RDFa processor is concerned, this extra markup can appear anywhere in the document—it doesn’t need to appear next to the presentation link. Of course, from the standpoint of human readability, it would usually go next to the link.

The second presentation:

<a href=" »
/the-5-minute-guide-to-rdfain-only-6-minutes-40- »
seconds">The 5-minute guide to only 6 »
minutes and 40 seconds</a>

…is licensed by adding this markup to the document:

<a about=" »
/the-5-minute-guide-to-rdfain-only-6-minutes-40- »
seconds" rel="license" 
  CC BY SA</a>.

Once again, this markup could appear anywhere.

Note that the reference to each license is still a clickable link, so from a user’s perspective, nothing changes when we add @about to an anchor. However, from a metadata perspective, each license is now being applied to an external document that contains a presentation, rather than being applied to the current document.

Of course, in a real example the clickable links would probably contain the Creative Commons icons, like this:

<a about=" »
/the-5-minute-guide-to-rdfain-only-6-minutes-40- »
seconds" rel="license" 
<img src="" />

And as you have probably realized, just as we use @property and @content to add properties for the document and images, we can also add them to the resources referenced by @about. For example, if we wanted to add creator information to a presentation, we could do this:

<a about=" »
fabien_gandon/rdfa-in-a-nutshell-v1" rel="license"
  property="dc:creator" content="Fabien Gandon">
<img src="" />

So, to recap, our rule would be:

Rule 8:#section5

Properties and relationships can be specified for any resource, not just the current document and images, using RDFa’s @about attribute.

Using @about to set the context for many properties and relationships#section6

Setting a number of properties and relationships for the current document is easy. In ordinary HTML, we just place a number of meta and link elements in the head of the document, and perhaps a few a tags with @rel in the body. Now that we can add @property and @content in the body, they too can be sprinkled throughout.

But what’s the equivalent technique for setting many properties when using @about? The examples we’ve seen so far have only used one property and one relationship for each item, because that’s the limit imposed by the structure of HTML itself: each attribute on an element must have a unique name, so it’s not possible to specify multiple property values and multiple relationship values on a single element.

The answer is however, quite straightforward. In RDFa, the @about attribute on an element actually sets the context for any RDFa that appears on any child elements. Before we illustrate this, let’s recap our last example:

<a about=" »
/rdfa-in-a-nutshell-v1" rel="license" 
  property="dc:creator" content="Fabien Gandon">

<img src="" />

You recall that this markup is effectively saying two things. First, “The SlideShare presentation at the specified URL has the license CC BY” and second, “The SlideShare presentation at the specified URL was created by Fabien Gandon.”

To make the problem we’re trying to solve a little more tangible, imagine that we now also want to add the date that the presentation was published to our markup—with the limiting factor that we’re not allowed to add another @property attribute to the anchor.

Now to the solution.

The easiest way to accomplish this is to begin by creating an element that contains the context in which we want all of our RDFa to operate, which in this case is the address of the presentation:

<div about=" »

Once we have this, we can place all the properties we want to add inside it:

<div about=" »
 <h1>RDFa in a Nutshell</h1> 
     <em property="dc:creator">Fabien Gandon</em></li>
     <em property="dc:created" content="2007-01-01">
     Jan 1st, 2007</em></li>
     <a rel="license" href=" »
/licenses/by/2.5/"><img src=" »
/l/by/2.5/80x15.png" /></a></li>

If this layout looks familiar to you that’s good, because it’s exactly the layout we saw near the beginning, when we were adding properties about the ‘current document’:

<html xmlns:dc=""> 
 <title>RDFa: Now everyone can have an API</title> 
 <h1>RDFa: Now everyone can have an API</h1>
     <em property="dc:creator">Mark Birbeck</em></li>
     <em property="dc:created" content="2009- »
 05-09">May 9th, 2009</em></li>
     <a rel="license" href="http:// »">
   <li>Previous version: 
     <a rel="dc:replaces" href="rdfa.0.8.html">
     version 0.8</a></li>

The only difference between this and our new example—the RDFa for Fabien’s presentation—is that the context for all of the properties and relationships that we’ve added is defined with @about, while in the first example, the context was simply the document itself. This gives us another rule:

Rule 9:#section7

The @about property sets the context for all contained properties and relationships. If there is no @about value set, then all properties and relationships will be in reference to the current document.

If any aspect of this last step is not clear to you, then I urge you to give it another read; this technique is probably the most important difference between RDFa and other methods of embedding structured data in HTML, such as Microformats and eRDF.


In the first two parts of this series, we’ve looked at the basics of RDFa, which are essentially:

  • generalizing HTML’s existing metadata features so they can be used in any part of the document (head or body) and on any element;
  • adding a prefix-mapping mechanism which allows us to be very precise about the origin of any terms we are using; and
  • adding the @about attribute so that properties and relationships can be specified for any resource, not just the current document or the images it contains.

If you’d like to go beyond the basics and look at some of the more advanced aspects of RDFa, then take a look at the RDFa Handbook over at Backplane.

About the Author

Mark Birbeck

Mark is managing director of Backplane Ltd., a London-based company involved in a number of RDFa/linked data projects for UK government departments. He is the original proposer of RDFa, and has spoken on the subject at various events.

10 Reader Comments

  1. It seems that RDFa is an HTML upgrade from a simple object to a language. Up until now an HTML tag would just state :”This is a link” or “This is an image”. Now, with RDFa, every object tell a whole story: “This is a link about.. that was created on..”

    This will probably change search engines results dramatically. No more out dated articles or images, and much better mapping of the web.

  2. It seems like RDFa is missing some consistency:

    @href: a link betwen two documents
    img@href: the license of the linked element
    [@rel=license][@about]: the license of the linked element

    Seems confusing. What’s wrong with img@about?


    – this document was created on 1 April 2009
    – this image was created on 1 April 2009

    It’s hard enough getting users (e.g. content editors) to use semantic markup. Confusing and contradictory semantic markup? Forget about it. Is there a saving grace that I’m missing?

  3. First of all, great set of intro articles! Though I am confused on one example (I even tried it).

    bq. Note that the reference to each license is still a clickable link, so from a user’s perspective, nothing changes when we add @about to an anchor…

    Unless I am completely missing something here, it completely changes — there is no longer a link to the slide! Now the slide title links to the license… users will definitely notice that — again I might be missing something here.

  4. @inoni and @somerain

    Sorry for the delay in getting back to you, but @somerain is exactly right — the problem with the mark-up is that we have extra code that is to be inserted, but in all of my previous snippets I’m showing how the mark-up evolves.

    I’ll see if that part can be rephrased a bit to make it clearer, and apologies for the confusion.

    Oh, and many thanks for taking the trouble to point this out!


  5. I understand that you can’t have multiple properties in attributes because attributes must be unique. It seems logical, therefore, to break it out into a big ol’ structure of tags, as illustrated. This makes sense in my mind as we are representing the data both to humans in the standard HTML and to machines in the RDFa additional markup.

    So I guess what seems weird to me is the ability to provide extra information only to machines by using the property/content combination. Shouldn’t that information also be being represented visually? And if it’s perfectly OK to hide potentially useful information from the visual consumers of this data, why is there no neat way to do it for more than one property? (I’m presuming the only way to provide multiple properties only to machines is to include empty spans or similar tags with the information in the attributes.)

    Having got my blustering confusion out of the way, thanks for these articles – I’m finding them very interesting and useful.

  6. Firstly thanks for a pair of great articles. RDFa is entirely new to me but having read both articles carefully I think I now have a grasp of the potential power of this level of markup. It’s seems common sense to be able to apply attributes to specific elements of a page rather than to the document as a whole. The final @about example in the article brings it all together nicely showing the power and neatness of RDFa used in this way. It is clear that this will allow both for better browser use of data – I like the example of search results / lists pages where the organizing of data in this way makes perfect sense – and also potential benefit for Search Engines to enhance their results. With Google only just beginning to make use of RDFa it will be interesting to see how it’s use propagates. It will also be interesting to see how Google (and the others Search Engines) handle the inevitable attempts to abuse the power of RDFa if it becomes an important part of the ranking algorithms.

  7. I’m all for semantic markup, but I agree with what a couple of others have posted in this discussion; how are we going to get content editors to apply semantic markup to what they write? Currently there are some great WYSIWYG editors out there that transform standard text to HTML – now we need some smart cookie to develop the next generation of editor that transforms standard text to apply RFDa markup to what people write. Otherwise I see a big chasm in the adoption of this markup.

    Also, who is going to decide on which standard to use? “RFDa vs Microformats”: there are many developers already using Microformats, but I’m hoping that RFDa will become the preferred choice using XML namespaces to create a scalable form of markup. Will the development community or standards community win out?

  8. Really clever, but come on, like most people say, how are we going to get an ordinary user to use this? How horrible is this syntax to learn? How many levels of inconsistencies and wierdness can we build on just to bow down to the XML/HTML altar?

    Name or Property – Ugh!
    href meaning different things depending on it’s element? – BIFF!, OW!
    More horrible xmlns syntax to learn? – Arrgh!!!
    Massive maintenance of the symantic ns register – No!!!

    Is this where XML finally jumps the shark? How long before we have to admit that every problem cannot be fixed with the XML hammer?

    Is it time to evolve?

    (Throws bomb – runs!) 😉

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA