Jo is organizing one last summer Barbecue, which she hopes all of her friends and family will attend. She blogs an announcement of this get-together 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 @instanceof is used here to define the type of 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. There, Jo can set up the event fields, reusing the existing XHTML. For example, the event summary can be declared as:

@property on span 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, "September 16th at 4pm", is ignored by the RDFa portion of the browser: it has been replaced by the explicit @content. 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, @property, and optionally @content 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 adding the vCard vocabulary is just as easy and does not interfere with the already added iCal vocabulary:

Jo then sets up her vCard using RDFa, by deciding that the p 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 @about for just for this purpose, indicating that all contained XHTML pertains to Jo's designated URI. @about is inherited from parent elements in the XHTML: the value of the @about on the nearest containing element applies.

"Simple enough!" Jo realizes, noting that RDFa does not interfere with her existing markup, in particular the @class she uses for styling. She adds her first vCard fields: name, title, organization and email.

Notice how Jo was able to use @rel directly within the anchor element to designate her organization and email address. @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 correct markup for expressing data such as full vCards.

Jo's complete XHTML with RDFa is thus:

If Jo changes her email address link, her organization, or the description of her event, 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 @content overrides the element's content, which is inevitable when human and machine readability are at odds.

(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 content management 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 compact URIs, where prefixes can be declared using standard XML namespace conventions. Thus, 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. When needed, more than one vocabulary can be imported into any element, not just html. 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 namespace conventions, 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.

The main benefit of RDF is precisely that all vocabulary components are simply URIs. anyone can define a vocabulary, extend it with a few additional concepts, make these new concepts immediately accessible to others, and provide a description of the concept simply by "filling in" the web page that is returned when the concept URI is accessed. No centralized organization is needed to coordinate the creation and extension of vocabularies: RDF allows one to declare relationships (including full equivalence) between concepts that develop organically in the community.

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 @about, 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 @about 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:

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.

The RDF interpretation of the above markup can be found in .

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:

RDFa uses XML schema data types .

The RDF interpretation of the above markup can be found in .

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:

The above markup uses the FOAF (Friend-Of-A-Friend) vocabulary which includes the field foaf:depicts that relates a photograph with a person depicted in the photograph. The use of @rel without @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 (e.g. the photo) to a subresource (e.g. each of the two persons depicted).

The RDF interpretation of the above markup can be found in .

Shutr authors 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 @about for marking up the photo's fields. In order to minimize markup, RDFa allows authors to make use of @src 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, RDFa provides @rev, which can be applied to img or any other element. @rev functions much like @rel, except the direction of the relationship is reversed:

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.

The RDF interpretation of the above markup can be found in .

When the displayed content is not quite the correct machine-readable data, we used @content to override it. In some cases, the navigable 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, another RDFa attribute, @resource, is used.

The XHTML written above can then be transformed to:

Mark Birbeck's Photos

... ]]>

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

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

The RDF interpretation of this markup can be found in

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 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 in corresponds to the following triple:

while the complete camera descriptions yields:

Finally, @datatype as in indicates a datatype as follows:

The subresources example in , with photos annotated with the individuals depicted, correspond to RDF blank nodes 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, as per , yields exactly the same triple as if @src were @href:

@rev specifies a triple with the subject and object reversed:

Where @resource is present, as per , 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: