Jo is organizing one last summer Barbecue, which she hopes all of her friends and family will attend. She blogs an announcement of her talk at her private blog, http://jo-blog.example.org/. Her blog also includes her contact information:

This short piece of mark-up contains important structured data.

The markup describes an event: a Barbecue that Jo is hosting. This Barbecue starts at 4pm on September 16th. A summary of the event is "one last summer Barbecue." We also have contact information for Jo: she works for the organization Example.org, with job title of "Web Hacker." She can be contacted at the email address "jo@example.org."

At the moment, it is very difficult for software — like web browsers and search engines — to make use of this data's implicit structure. We need a standard mechanism to explicitly express it, so that it can be extracted consistently. This is precisely where RDFa comes in.

Jo would like to label this blog entry so that her friends and family can add her Barbecue directly to their calendar. RDFa allows her to express this structure using a small handful of extra attributes. Since this is a calendar event, Jo will specifically use the iCal vocabulary to denote the data's structure.

The first step is to reference the iCal vocabulary within the XHTML page, so that Jo's friends' web browsers can look up the calendar concepts and make use of them:

then, Jo declares a new event:

Note how the instanceof attribute is used here to define the kind of the data being expressed. The use of this attribute on the P element ensures that, by default, data expressed inside this element refers to the same event. Thus, inside this event declaration, Jo can set up the event fields, reusing the existing XHTML. For example, the event summary can be declared as:

The property attribute on the span element declares the data field cal:summary. The existing content, "one last summer Barbecue", is the value of this field. Sometimes, this isn't the desired effect. Specifically, the start time of the event should be displayed pleasantly — "September 16th" —, but should likely be represented in a machine-parsable way, the standard iCal format: 20070916T1600-0500 (which is clearly not pleasant for human display). In this case, the markup needs only a slight modification:

The actual content of the span element, "September 16th at 4pm", is ignored by the RDFa portion of the browser: it has been replaced by the explicit content attribute. The full markup is then:

Note that Jo could have used any other XHTML element, not just span, to mark up her event. In other words, when the event information is already laid out in the XHTML using elements such as h1, em, div, etc..., Jo can simply add the instanceof data type declaration, the property attribute, and optionally the content attribute, to mark up the event.

(For the RDF-inclined reader, the RDF triples that correspond to the above markup are available in Section .)

Now that Jo has published her event in a human-and-machine-readable way, she realizes there is much data on her blog that she can mark up in the same way. Her contact information, in particular, is an easy target:

Jo discovers the vCard RDF vocabulary , which she adds to her existing page. Since Jo thinks of vCards as a way to publish her contact information, she uses the prefix contact to designate this vocabulary. Note that, although Jo already imported the iCal vocabulary, adding the vCard vocabulary is just as easy and does not interfere:

Jo then sets up her vCard using RDFa, by deciding that the P with class set to contactinfo will be the container for her vcard. She notes that the vCard schema does not require declaring a vCard type. Instead, it is recommended that a vCard refer to a web page that identifies the individual. Jo thus uses RDFa's special attribute about for just for this purpose, indicating that all contained XHTML pertains to Jo's designated URI. Note how the about attribute is inherited from parent elements in the XHTML: the about attribute on the nearest containing element applies.

"Simple enough!" Jo realizes. She adds her first vCard fields: name, title, organization and email.

Notice how Jo was able to use the rel attribute directly within the anchor tag for designating her organization and email address. In this case, the rel indicates the type of relationship between the current URI, designated by about, and the target URI, designated by href. Specifically, contact:org indicates a relationship of type "vCard organization", while contact:email indicates a relationship of type "vCard email".

For simplicity's sake, we have slightly abused the vCard vocabulary above: vCard technically requires that the type of the email address be specified, e.g. work or home email. In Section , we show how rel can be used without a corresponding href, in order to create subresources and provide the correct markup for expressing a true vCard.

Jo's complete XHTML with RDFa is thus:

If Jo changes her email address link, her organization, or the title of her talk, RDFa-enabled browsers will automatically pick up these changes in the marked up, structured data. The only places where this doesn't happen is when the content attribute must override the rendered content, which is inevitable when the human-rendered data and the machine-readable data must differ.

(Once again, the RDF-inclined reader will want to consult the resulting RDF triples .)

What if Jo does not have complete control over the XHTML of her blog? For example, she may be using a templating system which makes it particularly difficult to add the vocabularies in the html element at the top of her page without adding it to every page on her site. Or, she may be using a web provider that doesn't allow her to change the header of the page to begin with.

Fortunately, RDFa uses standard XML namespaces, which means that the vocabularies can be imported "locally" to an XHTML element. Jo's blog page could express the exact same structured data with the following markup:

In this case, each p only needs one vocabulary: the first uses iCal, the second uses vCard. However, just as before, more than one vocabulary can be imported into any element. This makes copying and pasting XHTML with RDFa much easier. In particular, it allows web widgets to carry their own RDFa in a self-contained manner.

All field names and data types in RDFa are URIs, e.g. http://purl.org/dc/elements/1.1/title is the "Dublin Core title" field. In RDFa, we often use compact versions of those URIs, by

• defining a prefix using XML namespaces, and
• using the prefixed notation to designate the URI.

This helps keep the markup short and clean:

Because concepts are simply URIs, it is trivial to create one's own vocabulary: simply mint new URIs in a domain you control, and use them in RDFa markup. This is, in fact, the power of RDF, RDFa's underlying technology.

Consider a (fictional) photo management web site called Shutr, whose web site is http://www.shutr.net. Users of Shutr can upload their photos at will, annotate them, organize them into albums, and share them with the world. They can choose to keep these photos private, or make them available for public consumption under licensing terms of their choosing.

Shutr chooses to mark up its photos with RDFa, so that browsers may be able to extract information automatically. Some concepts, such as dc:title, dc:date, etc. can be clearly reused from the Dublin Core vocabulary, but other concepts, such as lens settings, camera model, and other photographer parameters, may need to be defined from scratch. For this purpose, Shutr defines a vocabulary namespace URI:

http://shutr.net/vocab/1.0/

Shutr can then publish terms such as http://shutr.net/vocab/1.0/takenWithCamera, http://shutr.net/vocab/1.0/aperture, etc.

Shutr may choose to present many photos in a given XHTML page. In particular, at the URI http://www.shutr.net/user/markb/album/12345, all of the album's photos will appear inline. Structured data about each photo can be included simply by specifying an about attribute, which indicates the resource that fields refer to within that XHTML element.

, Sunset in Nice

, W3C Meeting in Mandelieu

]]>

This same approach applies when the field value is a URI. For example, each photo in the album has a creator and may have its own copyright license. We can use the convenient inheritance of the about attribute to refer to the photo once, and add as many fields as we need:

, Sunset in Nice taken by photographer Mark Birbeck , licensed under a Creative Commons Non-Commercial License .

W3C Meeting in Mandelieu taken by photographer Steven Pemberton , licensed under a Creative Commons Commercial License .

]]>

While it makes sense for Shutr to have a whole web page dedicated to each photo album, it might not make as much sense to have a single page for each camera owned by a user. A single page that describes all cameras belonging to a single user is more appropriate. For this purpose, RDFa provides ways to mark up document fragments using natural XHTML constructs.

Consider the page http://www.shutr.net/user/markb/cameras, which, as its URI implies, lists Mark Birbeck's cameras. Its XHTML contains:

and the photo page will then include information about which camera was used to take each photo:

... using the Nikon D200, ...

... ]]>

The RDFa syntax for formally specifying the relationship is exactly the same as before, as expected:

... using the Nikon D200, ...

... ]]>

Then, the XHTML snippet at http://www.shutr.net/user/markb/cameras is:

Notice, again, how text can serve both for the human and machine readable versions: there is no need to keep a separate file up-to-date.

When dealing with fields of structured data, one may well want (or need) to specify a data type so that computer programs that read the data can make sense of it. Consider the expression of a date. We have already seen how the human-rendered and machine-readable data may not be the same, and how we can use content to provide a machine-readable value. Adding a datatype is only one more attribute: datatype. For example, when expressing the date on which a photo was taken:

Note how we use XML data types.

Sometimes, one may need to mark up a resource with a number of fields, all without giving it a URL, or even a fragment identifier. Consider the case where Shutr decides to let users annotate photos in order to indicate which individuals are depicted in the photo. The barebones XHTML is:

The simplest way to mark this up without attempting to resolve unique identities for photo subjects is to define subresources, effectively new resources that are not given a name. (In RDF, we call these blank nodes.) The following markup will do just that, thanks to the FOAF (Friend-Of-A-Friend) vocabulary which includes the handy field foaf:depicts for just this purpose:

The use of the rel attribute without an href triggers the definition of a new subresource, which is then the value of the foaf:depicts field. Then, all contained markup applies to this new subresource. In RDFa-speak, we call this "chaining," as it allows one to easily chain one resource to a subresource.

Shutr may notice that, in a number of cases, the URI of the photos it displays inline using the IMG element is actually the same as the about attribute for marking up the photo's fields. In order to minimize markup, RDFa allows Shutr to make use of the src attribute on an IMG element: it behaves just like href.

Consider Mark's profile page on Shutr, which lists all of his albums and cameras. This page will likely include a picture of Mark himself:

Mark Birbeck's Photos

... ]]>

Shutr may want to indicate that this is Mark's photo, using the FOAF field foaf:img defined specifically for this purpose. This can be accomplished as follows:

Mark Birbeck's Photos

... ]]>

Shutr then notes that the profile photo isn't only Mark's profile photo, it also happens to depict Mark, since Mark obviously appears in his own profile photo (hopefully). This requires expressing an inverse relationship, where the field is actually added to the image's URI, not to Mark's profile.

For this purpose, Shutr uses the rev attribute, which can be used on IMG or any other element. The attribute rev functions much like rel, except the opposite relationship is expressed:

Mark Birbeck's Photos

... ]]>

In other words, Mark has, as his main image, /user/markb/profile_photo.jpg, which of course happens to depict Mark.

When the displayed content is not quite the correct machine-readable data, we used the content attribute to override it. In some cases, the clickable link is not quite the right machine-readable data, either. Consider, for example, the case where the displayed photo on Mark Birbeck's profile is, in fact, just a thumbnail, while his official FOAF image is the full-sized version. In this case, and in any case where href or src appears and needs to be overridden by another URI, RDFa offers the attribute resource.

The XHTML written above can then be transformed to:

Mark Birbeck's Photos

... ]]>

Here, the loaded image will the thumbnail, but an RDFa-aware browser will know that the machine-readable data only cares about the full-sized version specified in resource.

The resource attribute can be particularly useful in cases where the URI is not clickable in any way, e.g. a book's ISBN number represented as URN:ISBN:0-395-36341-1.

In Section , Jo published an event without giving it a URI. The RDF triples extracted from her markup are:

In Section , Jo published contact information. The RDFa is parsed to generate the following RDF triples:

The XHTML+RDFa in the first Shutr example yields the following triples:

The more complete example, including licensing information, yields the following triples:

The example that links a photo to the camera it was taken with corresponds to the following triple:

while the complete camera descriptions yields:

Finally, the datatype attribute indicates a datatype as follows:

The subresources example, with photos annotated with the individuals depicted, correspond to RDF bnodes as follows:

Note specifically how the bnode, in this example, is both the object of a first triple, and the subject of a number of follow-up triples. This is specifically the point of the layered markup approach: to create an unnamed subresource.

The use of src on an image yields exactly the same triple as if the src were href:

The rev attribute specifies a triple with the subject and object reversed:

Where resource is present, the same triples are generated, with the value of resource replacing the value of href. Even though the href points to /user/markb/profile_photo_thumbnail.jpg, the corresponding triple is: