This is an internal draft produced by the Semantic Web
Deployment Working Group , in cooperation
with the XHTML2 Working Group . Initial
work on RDFa began with the Semantic Web Best Practices and
Deployment Working Group and the HTML
Working Group .

This document is for internal review only and is subject
to change without notice. This document has no formal
standing within the W3C.

Current web pages, written in XHTML, contain inherent structured data:
calendar events, contact information, photo captions, song titles, copyright
licensing information, etc. When authors and publishers can express this
data precisely, and when tools can read it robustly, a new world of user
functionality becomes available, letting users transfer structured data
between applications and web sites. An event on a web page can be directly
imported into a desktop calendar. A license on a document can be detected to
inform the user of his rights automatically. A photo's creator, camera
setting information, resolution, and topic can be published as easily as the
original photo itself.

RDFa lets XHTML authors express this structured data using extra XHTML
attributes. Where the data is already present on the page, e.g. a photo
caption, the author need not repeat it. A web publisher can easily reuse
concepts, e.g. an event's date, defined by other publishers, or create new
ones altogether. RDFa gets its expressive power from RDF, though the reader
need not understand RDF before reading this document.

RDFa uses Compact URIs, which express a URI using a prefix, e.g.
dc:title where dc: stands for
http://purl.org/dc/elements/1.1/. In this document, for
simplicity's sake, the following prefixes are assumed to be already
declared: dc for Dublin Core, foaf for
Friend-Of-A-Friend, cc for Creative Commons, and xsd
for XML Schema Definitions:

dc: http://purl.org/dc/elements/1.1/

foaf: http://xmlns.com/foaf/0.1/

cc:
http://web.resource.org/cc/

xsd:
http://www.w3.org/2001/XMLSchema#

We use standard XHTML notation for elements and attributes: both are
denoted using fixed-width lowercase font, e.g. div, and attributes
are differentiated using a preceding '@' character, e.g. @href.

Simple Data: Publishing Events and Contacts

Jo keeps a private blog for her friends and family.

The Basic XHTML, before RDFa

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:

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.

Publishing An Event

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:

one last summer Barbecue,
]]>

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

September 16th at 4pm
]]>

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:

Jo's Friends and Family Blog
...

I'm holding
one last summer Barbecue,
on
September 16th at 4pm.

...
]]>

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 .)

Publishing Contact Information

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.

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.

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: