The modern Web is made up of an enormous number of documents that have been created using HTML. These documents contain significant amounts of structured data, which is largely unavailable to
tools and applications. When publishers can express this data more completely, and when tools can read it, a new world of user functionality becomes available, letting users transfer structured data
between applications and web sites, and allowing browsing applications to improve the user experience: an event on a web page can be directly imported into a user's desktop calendar; a license on a
document can be detected so that users can be informed of their rights automatically; a photo's creator, camera setting information, resolution, location and topic can be published as easily as the
original photo itself, enabling structured search and sharing.

RDFa is a syntax for expressing this structured data in XHTML. The rendered, hypertext data of XHTML is reused by the RDFa markup, so that publishers don't repeat themselves. The underlying
abstract representation is RDF [RDF-PRIMER], which lets publishers build their own vocabulary, extend others, and evolve their vocabulary with maximal
interoperability over time. The expressed structure is closely tied to the data, so that rendered data can be copied and pasted along with its relevant structure.

The rules for interpreting the data are generic, so that there is no need for different rules for different formats; this allows authors and publishers of data to define their own formats without
having to update software, register formats via a central authority, or worry that two formats may interfere with each other.

This document is a detailed syntax specification for RDFa, aimed at:

those looking to create an RDFa parser, and who therefore need a detailed description of the parsing rules;

those looking to recommend the use of RDFa within their organisation, and who would like to create some guidelines for their users;

anyone familiar with RDF, and who wants to understand more about what is happening 'under the hood', when an RDFa parser runs.

For those looking for an introduction to the use of RDFa and some real-world examples, please consult the RDFa Primer.

If you are already familiar with RDFa, and you want to examine the processing rules—perhaps to create a parser—then you'll find the Processing Model section of
most interest. It contains an overview of each of the processing steps, followed by more detailed sections, one for each rule.

If you are not familiar with RDFa, but you are familiar with RDF, then you might find reading the Syntax Overview useful, before looking at the Processing Model since it gives a range of examples of XHTML mark-up that use RDFa. Seeing some examples first should make reading the processing rules easier.

If you are not familiar with RDF, then you might want to take a look at the section on RDF Terminology before trying to do too much with RDFa. Although RDFa is
designed to be easy to author—and authors don't need to understand RDF to use it—anyone writing applications that consume RDFa will need to understand RDF. There is a lot of
material on RDF on the web, and a growing range of tools that will support RDFa, so all we try to do in this document is provide enough background on RDF to make the goals of RDFa clearer.

And finally, if you are not familiar with either RDFa or RDF, and simply want to add RDFa to your documents, then you may find the RDFa Primer [RDFaPRIMER] to be a better introduction.

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of
this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is an internal draft produced jointly by the Semantic Web Deployment Working Group [SWD-WG] and the XHTML 2 Working Group [XHTML2-WG]. Initial
work on RDFa began in the XHTML 2 Working Group [XHTML2-WG].

This document has no official standing within the W3C. It is also a work in progress, which means it may change at any time, without warning, and you shouldn't rely on anything in this
document.

RDF/XML [RDF-SYNTAX] provides sufficient flexibility to represent all of the abstract concepts in RDF [RDF-CONCEPTS]. However, it presents two
challenges; first it is difficult or impossible to validate documents that contain RDF/XML using XML Schemas or DTDs, which makes it difficult to import RDF/XML into other markup languages. Whilst
newer schema languages such as RELAX NG [RELAXNG] do provide a way to validate documents that contain arbitrary RDF/XML, it will be a while before they gain wide support.

Second, even if one could add RDF/XML directly into an XML dialect like XHTML, there would be significant data duplication between the rendered data and the RDF/XML structured data. It would be
far better to add RDF to a document without repeating the document's existing data. For example, an XHTML document that explicitly renders its author's name in the text—perhaps as a byline on a
news site—should not need to repeat this name for the RDF expression of the same concept: it should be possible to supplement the existing markup in such a way that it can also be interpreted
as RDF.

Third, as users often want to transfer structured data from one application to another, sometimes to or from a non-web-based application, it is highly beneficial to express the web data's
structure "in context." The user experience could then be enhanced, for example by providing contextual information about specific rendered data, perhaps when the user "right-clicks" on an item of
interest.

In the past, many attributes were 'hard-wired' directly into the markup language to represent specific concepts. For example, in XHTML 1.1 [XHTML11] and
HTML [HTML4] there is @cite; the attribute allows an author to add information to a document which is used to indicate the origin of a
quote.

However, these 'hard-wired' attributes make it difficult to define a generic process for extracting metadata from any document since a parser would need to know about each of the special
attributes. One motivation for RDFa has been to devise a means by which documents can be augmented with metadata in a general rather than hard-wired manner. This has been achieved by creating a fixed
set of attributes and parsing rules, but allowing those attributes to contain properties from any of a number of the growing range of available RDF vocabularies. The values of those
properties are in most cases the information that is already in an author's XHTML document.

RDFa alleviates the pressure on XML format authors to anticipate all the structural requirements users of their format might have, by outlining a new syntax for RDF that relies only on XML
attributes. This specification deals specifically with the use of RDFa in XHTML, and defines an RDF mapping for a number of XHTML attributes, but RDFa can be easily imported into other XML-based
markup languages.

RDFa in XHTML makes use of a number of XHTML attributes, as well as providing a few new ones. Attributes that already exist in XHTML will have the same meaning as in XHTML, although their syntax
may be slightly modified. For example, in XHTML, @rel already defines the relationship between one document and another. However, in XHTML there is no clear way to add new
values; RDFa sets out to explicitly solve this problem, and does so by allowing URIs as values. It also introduces the idea of 'compact URIs'—referred to as CURIEs in this document—which
allow a full URI value to be expressed succinctly.

The XHTML attributes that are relevant are:

@rel,

a whitespace separated list of CURIEs, used for expressing relationships between two resources (a 'predicate' in RDF)

@rev,

a whitespace separated list of CURIEs, used for expressing reverse relationships between two resources (also a 'predicate')

@href,

a URI for expressing the partner resource of a relationship (the 'object' in RDF)

@src,

a URI for expressing the partner resource of a relationship when the resource is
embedded (also an 'object')

The new—RDFa-specific—attributes are:

@about,

a URIorCURIE, used for stating what the data is about (the 'subject' in RDF terminology)

@property,

a whitespace separated list of CURIEs, used for expressing relationships between the subject and some literal text (also a 'predicate')

@resource,

a URIorCURIE for expressing the partner resource of a relationship that is not intended to be 'clickable' (also an 'object')

The previous section gave examples of typical mark-up in order to illustrate what RDFa in XHTML looks like. But what RDFa in XHTML represents is RDF. In order to author RDFa in XHTML you
do not need to understand RDF, although it would certainly help. However, if you are building a system that consumes the RDF output of an RDFa in XHTML document you will almost certainly need to
understand RDF. In this section we introduce the basic concepts, and terminology of RDF. For a more thorough explanation of RDF, please refer to the RDF Concepts document [RDF-CONCEPTS] and tne RDF Sytax Document [RDF-SYNTAX].

The structured data that RDFa provides access to is a collection of statements. A statement is a basic unit of information that has been constructed in a specific format to make it
easier to process. In turn, by breaking large sets of information down into a collection of statements, even very complex metadata can be processed using simple rules.

To illustrate, suppose we have the following set of facts:

Albert was born on March 14, 1879, in Germany. There is a picture of him at
the web address, http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg.

This would be quite difficult for a machine to interpret, and it is certainly not in a format that could be passed from one data application to another. However, if we convert the information to a
set of statements it begins to be more manageable. The same information could therefore be represented by the following shorter 'statements':

Albert was born on March 14, 1879.
Albert was born in Germany.
Albert has a picture at
http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg.

To make this information machine-processable, RDF defines a structure for these statements. A statement is formally called a triple, meaning that it is made up of three components. The
first is the subject of the triple, and is what we are making our statements about. In these examples the subject is always 'Albert'.

The second part of a triple is the property of the subject that we want to define. In the examples here, the properties would be 'was born on', 'was born in', and 'has a picture at'. These are
more usually called predicates in RDF.

The final part of a triple is called the object. In the examples here the object values are 'March 14, 1879', 'Germany', and
'http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg'.

Breaking complex information into manageable units helps us be specific about our data, but there is still some ambiguity. For example, which 'Albert' are we talking about? If another system has
more facts about 'Albert', how could we know whether they are about the same person, and so add them to the list of things we know about that person? If we wanted to find people born in Germany, how
could we know that the predicate 'was born in' has the same purpose as the predicate 'birthplace' that exists in some other system? RDF solves this problem by replacing our vague terms with URI
references.

URIs are most commonly used to identify web pages, but RDF makes use of them as a way to provide unique identifiers for concepts. For example, we could identify the subject of all of our
statements by using the DBPedia [?ref] URI for Albert Einstein, rather than 'Albert':

<http://dbpedia.org/resource/Albert_Einstein>
has the name
Albert Einstein.
<http://dbpedia.org/resource/Albert_Einstein>
was born on
March 14, 1879.
<http://dbpedia.org/resource/Albert_Einstein>
was born in
Germany.
<http://dbpedia.org/resource/Albert_Einstein>
has a picture at
http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg.

URI references are also used to uniquely identify the objects in metadata statements. The picture of Einstein is already a URI, but we can also use one to uniquely identify the country Germany
(note that we put literals into quotes to distinguish them from URIs):

<http://dbpedia.org/resource/Albert_Einstein>
has the name
"Albert Einstein".
<http://dbpedia.org/resource/Albert_Einstein>
was born on
"March 14, 1879".
<http://dbpedia.org/resource/Albert_Einstein>
was born in
<http://dbpedia.org/resource/Germany>.
<http://dbpedia.org/resource/Albert_Einstein>
has a picture at
<http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg>.

URI references are also used to ensure that predicates are unambiguous; now we can be sure that 'birthplace', 'place of birth', 'place de nee' [???] and so on, all mean the same thing:

Although URI resources are always used for subjects and predicates, the object part of a triple can be either a URI or a literal. In the example triples, Einstein's name is represented
by a plain literal, which means that it is a basic string with no type or language information:

Some literals, such as dates and numbers, have very specific meanings, so RDF provides a mechanism for indicating the type of a literal. A typed literal is indicated by attaching a URI
to the end of a plain literal, and this URI indicates the literal's datatype. This URI is usually based on datatypes defined in the XML Schema Datatypes specification [XMLSCHEMA]. The following syntax would be used to unambiguously express Einstein's date of birth as a literal of type <
code>http://www.w3.org/2001/XMLSchema#date:

RDF itself does not have one set way to express triples, since the key ideas of RDF are the triple and the use of URIs, and not any particular syntax. However, there are a number of
mechanisms, such as RDF/XML, N-Triples [N-TRIPLES], and of course RDFa. Most discussions of RDF make use of the N-Triple syntax to explain their ideas, since it is
quite compact. The examples we have just seen are already using this syntax, and we'll continue to use it throughout this document when we need to talk about the RDF that could be generated from some
RDFa. There is one small change that we make to N-Triples, which is to allow long URIs to be abbreviated by using a URI mapping. This is indicated by expressing a compact URI as follows:

In order to allow for the compact expression of RDF statements, RDFa allows the contraction of all [URI reference]s into a form called a 'compact URI', or [CURIE]. Until recently QNames [QNames]
have been the most common way to abbreviate URIs, but there is a well-known limitation that the syntax for QNames does not allow all possible [URI reference]s to be expressed. CURIEs have been
specificially designed to look like QNames, but at the same time to get around their syntactic limitations.

Note that CURIEs are only used in the mark-up and N-Triples examples, and will never appear in the generated [triple]s, which will always use [URI reference]s.

The following is a brief description of RDFa in terms of the RDF terminology introduced here. It may be useful to readers with an RDF background:

The aim of RDFa is to allow a single [RDF graph]s to be carried in XML documents of any type, although this specification deals only with RDFa in XHTML. An [RDF graph] comprises [node]s linked by
relationships. The basic unit of a graph is a [triple], in which a subject [node] is linked to an object [node] via a [predicate]. The subject [node] is always either an [URI reference] or a [blank
node], the predicate is always an [URI reference], and the object of a statement can be an [URI reference], a [literal], or a [blank node].

In RDFa, a subject [URI reference] is generally indicated using @about, and predicates are represented using one of @property, @instanceof, @rel, or @rev. Objects which are [URI reference]s are represented using @href, @resource or @src, whilst objects that are [literal]s are represented either with @content (with an optional [datatype] expressed
using @datatype), or the content of the element in question.

The start tag of the root element of the document must explicitly contain an xmlns declaration for the XHTML namespace [XMLNS]. The namespace URI for XHTML is defined to be http://www.w3.org/1999/xhtml.

Sample root element

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" >

There MUST be a DOCTYPE declaration in the document prior to the root element.If present, the public identifier included in the DOCTYPE declaration
must reference the DTD found in Appendix B - XHTML+RDFa Document Type Definition using its Public Identifier.The system identifier may be
modified appropriately.

Note that in this example, the XML declaration is included. An XML declaration like the one above is not required in all XML documents. XHTML document authors should use XML
declarations in all their documents.XHTML document authors must use an XML declaration when the character encoding of the document is other than the default UTF-8 or UTF-16
and no encoding is specified by a higher-level protocol.

XHTML 1.1 documents SHOULD be labeled with the Internet Media Type "application/xhtml+xml" as defined in [RFC3236]. For further
information on using media types with XHTML, see the informative note [XHTMLMIME].

A conforming user agent MUST support all of the features required in this specification.A conforming user agent must also support the User Agent
conformance requirements as defined in XHTML Modularization [XHTMLMOD] section on "XHTML Family User Agent Conformance".

A conforming RDFa Processor MUST make available to a consuming application a single RDF [graph] containing all possible triples generated by using the rules in the Processing Model section. This is the 'default [graph]'.

A conforming RDFa Processor MAY make available additional triples that have been generated using rules not described here, but these triples MUST be made available in one or
more additional RDF [graph]s, and not in the default [graph].

A conforming RDFa Processor MUST process whitespace according to the rules of [CSS2].Note that this same requirement is imposed
upon conforming User Agents via [XHTMLMOD].

Test Suite

We have a test suite - we should likely reference it here, but I need to find the exact way to do that. -Shane

Assertion Annotation

All the assertions in this spec need to be annotated with the appropriate markup (must, should, etc.).

This section looks at a generic set of processing rules for creating a set of triples that represent the structured data present in an XHTML+RDFa document. Processing need not follow the DOM
traversal technique outlined here, although the effect of following some other manner of processing must be the same as if the processing outlined here were followed. The processing model is
explained using the idea of DOM traversal which makes it easier to describe (particularly in relation to the 'evaluation context').

Parsing a document for RDFa triples is carried out by starting at the root element of the document, and visiting each of its child elements in turn, applying processing rules. Processing is
recursive in that for each child element the processor also visits each of its child elements, and applies the same processing rules.

As processing continues, rules are applied which will either generate triples, or change the [evaluation context] information which will be used in subsequent processing. Some of the rules will
be determined by the host language—in this case XHTML—and some of the rules will be part of RDFa.

Note that we don't say anything about what should happen to the triples generated, or whether more triples might be generated during processing than are outlined here. However, to be conformant,
an RDFa processor needs to act as if at a minimum the rules in this section are applied.

During processing, each rule is applied within an 'evaluation context'. Rules may further modify this evaluation context, or create triples that can be established by making use of this
evaluation context. The context itself consists of the following pieces of information:

The [base]. This will usually be the URL of the document being processed, but it could be some other URL, set by some other mechanism, such as the XHTML base element. The important
thing is that it establishes a URL against which relative paths can be evaluated.

The [current resource]. The initial value will be the same as the initial value of base, but it will usually change during the course of processing.

The [current element identifier]. This is an identifier for the current element, which will not always be the same as [current resource].

Processing would normally begin after the document to be parsed has been completely loaded. However, there is no requirement for this to be the case, and it is certainly possible to use a
stream-based approach, such as SAX [http://en.wikipedia.org/wiki/SAX] to extract the RDFa information. However, if some approach other than the DOM traversal technique defined here is used, it is
important to ensure that any meta or link elements processed in the head of the document honour any occurrences of base which may appear
after those elements. (In other words, XHTML processing rules must still be applied, even if document processing takes place in a non-HTML environment such as a search indexer.)

At the beginning of processing, the [current evaluation context] is initialised as follows:

the [base] is set to either the URL of the document or the value specified in the base element, if present;

the [current resource] is set to the [base] value;

the [current element identifier] is cleared;

the [list of URI mappings] is cleared;

the [language] is cleared.

Processing then begins with the root element, and all nodes in the tree are processed according to the following rules, depth-first:

Any changes to the [current evaluation context] are made first:

the [current element] is parsed for [URI mappings] and these are added to the [list of URI mappings]. Note that a [URI mapping] will simply overwrite any current mapping in the list that has the
same name;

These mappings are provided by @xmlns. The value to be mapped is set by the XML namespace prefix, and the value to map is the value of the
attribute—a URI. Note that the URI is not processed in any way; in particular if it is a relative path it is not resolved against the [current base]. Authors are advised to follow best practice
for using namespaces, which includes not using relative paths. (See [xyz].)

the [current element] is parsed for any language information, and [language] is set in the [current evaluation context];

Language information can be provided using the general-purpose XML attribute @xml:lang.

the [current element] is parsed for any subject information, and it is used to set the [current resource] value, in the [current evaluation context];

The [current resource] can be set using @about. Note that the final value of the [current resource] is an absolute IRI, which means that if @about contains a relative path the value must be normalised against [base] in the [current evaluation context], using the algorithm defined in RFC 3986. The value can also be
provided by a CURIE, and is processed as defined in CURIE Syntax Definition. Note that since this attribute can take both URIs and CURIEs, the latter will have been expressed
using the [safe CURIE] syntax.

the [current element identifier] is set;

The [current element identifier] is set to the value of @about, if present, or the value of @resource, if
present, or the value of @href, if present, or the value of @src, if present, or a [blank node]. Note that this means
that the value of the [current element identfier] will not be the same as the [current resource], since in the absence of an attribute to set its value it will be set to a [blank node], whilst
[current resource] inherits from its context.
Note that the final value of [current element identifier] is an absolute IRI, so any relative paths must be normalised against [base] in the [current evaluation context], using the algorithm defined
in RFC 3986. The value might also have been provided by a CURIE, and if so, it is processed as defined in CURIE Syntax Definition.

the [recurse] flag is set to true;

Processing will generally continue recursively through the entire tree of nodes available. However, if an author indicates that some branch of the tree should be treated as
an XML literal, no further processing should take place on that branch. This flag is used to inhibit this processing.

the [chaining] flag is set to false;

If a collection of statements is contained by a [URI reference] then this may become the subject of further statements.

Once the [current evaluation context] has been set, object resolution is carried out, as follows:

the [current object resource] is established;

Since only one [current object resource] is set per element then some attributes will have a higher priority than others. The highest priority is given to
@resource. If there is no @resource then @href is used, and if that is not present, @src is used. If none of these
are present then a unique identifier or [blank node] is created. Note that the final value of the [current object resource] is an absolute URI or a [blank node], which means that if any of these
attributes contain relative paths they must be normalised against [base] in the [current evaluation context], using the algorithm defined in RFC 3986. Note also that since
@resource can take both URIs and CURIEs, the latter will have been expressed using the [safe CURIE] syntax.

the [current object literal] is established;

The [current object literal] will be set as a [plain literal] if @content is present, or the body of the [current element] contains only
text (i.e., there are no child elements), or the body of the [current element] does have child elements but @datatype has an empty value. Additionally, if
there is a value for [current language] then the value of the [plain literal] should include this language information, as described in [RDFCONCEPTS]. The actual literal is either the value of @content (if present) or a string created by concatenating the text content of each of the child elements of the [current element] in document order, and then normalising
white-space according to [WHITESPACERULES].

Whitespace normalising

So far we defer to CSS2, but I think we should copy the prose into here, so that it's clearer.

The [current object literal] will be set as a [typed literal] if @datatype is present, and does not have an empty value. The actual literal is
either the value of @content (if present) or a string created by concatenating the inner content of each of the children in turn, of the [current element]. The
final string includes the datatype, as described in [RDFCONCEPTS].

The [current object literal] will be set as an [XML literal] if the [current element] has child elements, and @datatype is not present, or is set to
rdf:XMLLiteral. The value of the [XML literal] is a string created from the inner content of the [current element], i.e., not including the element itself, with the datatype of
rdf:XMLLiteral.

Once object resolution is complete the processor will have two objects, one a resource and the other a literal. These objects can now be used to create triples with the [current resource],
depending on the presence of other attributes. This is achieved using the following processing steps:

Predicates for the [current object literal] are established;

Predicates for the [current object literal] can be set by using @property. If present, the attribute must contain one or more [curie]s, each of
which is converted to an absolute URI using CURIE processing rules, and then used to generate a triple as follows:

subject

[current resource]

predicate

expanded value from the curie

object

[current object literal]

Note that literal may include language and datatype information as discussed in the section on object resolution. Once the triple has been created, the [recurse] flag is set to false.

predicates for the [current object resource] are established. If any triples are generated then the [chaining] flag is set to true.;

Predicates for the [current object resource] can be set by using one or both of the @rel and @rev attributes. If present,
@rel must contain one or more [CURIE]s, each of which is converted to an absolute URI using CURIE processing rules, and then used to generate a triple as follows:

subject

[current resource]

predicate

expanded value from the curie

object

[current object resource]

If present, @rev must contain one or more [CURIE]s, each of which is converted to an absolute URI using CURIE processing rules, and then used to generate a triple as
follows:

subject

[current object resource]

predicate

expanded value from the curie

object

[current resource]

Type values for the [current element identifier] are established. If any triples are generated then the [chaining] flag is set to true.;

One or more 'types' for the [current element identifier] can be set by using @instanceof. If present, the attribute must contain one or more
[curie]s, each of which is converted to an absolute URI using CURIE processing rules, and then used to generate a triple as follows:

subject

[current element identifier]

predicate

http://www.w3.org/1999/02/22-rdf-syntax-ns#type

object

expanded value from the curie

If the [chaining] flag is set to true then the [current resource] is set to the value of the [current object resource], and the [chaining] flag is set to false.

If the [recurse] flag is true, the [current evaluation context] is pushed onto a stack, and all nodes that are children of the [current element] are processed using the rules described here. Once
all of the children have been processed then the [current evaluation context] is popped back off the stack.

This section provides an in-depth examination of the processing steps described in the previous section. It also includes examples which may help clarify some of the steps involved.

@instanceof situation

This section still needs the detail on whether @instanceof should use @about if it is present, or use the subject from chaining.

NOTE: There isn't quite enough detail on chaining yet.

In the following examples, for brevity assume that the following namespace prefixes have been defined:

cc:

http://creativecommons.org/ns#

dc:

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

ex:

http://example.org/

foaf:

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

rdf:

http://www.w3.org/1999/02/22-rdf-syntax-ns#

rdfs:

http://www.w3.org/2000/01/rdf-schema#

p:

http://dbpedia.org/property/

rdfa:

http://www.w3.org/ns/rdfa/

svg:

http://www.w3.org/2000/svg

xh11:

http://www.w3.org/1999/xhtml

xsd:

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

biblio:

http://example.org/biblio/0.1

taxo:

http://purl.org/rss/1.0/modules/taxonomy/

The key to processing is that a triple is generated whenever a predicate/object combination is detected. The actual triple generated will include a subject that may have been set previously, so
this is tracked in the [current evaluation context] and is called the [current resource]. Since the subject will default to the current document if it hasn't been set explicitly, then a
predicate/object combination is always enough to generate one or more triples.

The attributes for setting a predicate are @rel, @rev and @property, whilst the attributes for setting an object are
@resource, @href, @content, and @src.

Note that there are actually two special cases—the use of @instanceof to set type information, and @rel or @rev
appearing on an element on its own. Both of these cases are discussed in more details below.

As processing progresses, any @about attributes will change the [current resource]. The value of @about is a URI or a CURIE. If it is a relative
URI then it needs to be resolved against the current [base] value. In this mark-up the properties cal:summary and cal:dtstart become part of the 'event' object, rather than
referring to the document:

Note that this requires that a URI mapping for the prefix rdf has been defined. To make authoring easier, if there are child elements and no @datatype
attribute, then the effect is the same as if @datatype have been explicitly set to rdf:XMLLiteral:

<h2 property="dc:title">
E = mc<sup>2</sup>: The Most Urgent Problem of Our Time
</h2>

In the examples we've been using the sup element is actually part of the meaning of the literal, but there will be situations where the extra mark-up means nothing, and can therefore
be ignored. In this situation an empty @datatype value can be used to override the XML literal behaviour:

Note that the value of this [XML Literal] is the exclusive canonicalization of the RDFa element's value.

Although the RDFa processing model requires visiting each node in the tree, if the processor meets an [XML literal] then it MUST NOT process any further down the
tree. This is to prevent triples being generated from mark-up that is not actually in the hierarchy. For example, we might want to set the title of something to some XHTML that includes
RDFa:

This does effectively mean that the presence of @property without @content will inhibit any further processing, so authors should watch out for
stray attributes, especially if they find that they are getting fewer triples than they had expected.

One or more [URI object]s are needed when @rel or @rev is present. Each attribute will cause triples to be generated when used with @href, @resource or @src.

@rel and @rev are essentially the inverse of each other; whilst @rel establishes a relationship between the [current
resource] as subject, and the [object resource] as the object, @rev does the exact opposite, and uses the [object resource] as the subject, and the [current resource] as the
object.

It's also possible to use both @rel and @rev at the same time on an element. This is particularly useful when two things stand in two different
relationships with each, for example when a picture is taken by Mark, but that picture also depicts him:

When a triple predicate has been expressed using @rel, and no @href, @src, or @resource
exists on the same [RDFa element], then the CURIE represented by this element is used as the object. This CURIE is affected by @about, but if none is present the object is a [blank node] (blank nodes are discussed further in @@@section bnode [REF]@@@). In
all cases, the subject resolution for child elements is affected: where they do not override the subject, their subject is this same CURIE here
resolved as the object.

Consider, for example, a simple fragment of XHTML for describing the creator of a web page, with further information about the creator, including his name and email address:

To establish relationships between [blank node]s, the [unique anonymous ID] must be set explicity using a CURIE [blank node] as subject or object. For example, if our desired output is the
following [triple]s:

Note that this syntax definition will ultimately be defined in an external document [CURIE].

The key component of RDF is the URI, but they are usually long and unwieldy. RDFa therefore supports a mechanism by which URIs can be abbreviated, called 'compact URIs' or simply, CURIEs.

A CURIE is comprised of two components, a prefix which maps to a URI, and a reference. The prefix is separated from the reference by a colon (:). It is possible to
omit the prefix, and make use of the default prefix. It is also possible to omit both the prefix and the colon, leaving just a reference.

In some situations an attribute will allow either a CURIE, or a normal IRI. Since it is difficult to distinguish between CURIEs and IRIs, RDFa adds the notion of a [safe CURIE]. The syntax is
simply to surround the CURIE with square brackets:

safe_curie := '[' curie ']'

NOTE: The following language-independent prose will be removed shortly, once we have finalised this.

To evaluate CURIEs during processing the following context needs to be set:

a set of mappings from prefixes to URIs;

The prefix mappings are provided by the current in-scope namespace declarations of the [current element] during parsing.

a mapping to use with the default prefix (for example, :p);

The mapping to use with the default prefix is the current default namespace.

a mapping to use when there is no prefix (for example, p);

The mapping to use when there is no prefix is http://www.w3.org/1999/xhtml#.

a mapping to use with the '_' prefix, which is used to generate unique identifiers (for example, _:p).

the mapping to use with the '_' prefix is not explicitly stated, but should be chosen by the processor to ensure that there is no possibility of collision with other
documents.

clarify the 'no prefix' situation

The advantage of setting the 'no prefix' mapping to the XHTML namespace is that we no longer need a preprocessing step to handle XHTML link types, such as a next. However, this does have
the effect of moving all other values into the XHTML namespace, such as openid.delegate. An alternative is to prohibit unprefixed CURIEs, other than those defined by XHTML.

A CURIE is a representation of a full IRI. This IRI is obtained by taking the currently in-scope mapping that is associated with prefix, and concatenating it with
the reference. The result MUST be a syntactically valid IRI [IRI].

The XHTML+RDFa document type is a fully functional document type with rich semantics. It is a superset of [XHTML11]. See that document for the details of
the underlying language.

The XHTML+RDFa 1.0 document type is made up of the following XHTML modules. The elements, attributes, and content models associated with these modules are defined in "XHTML Modularization" [XHTMLMOD]. The elements are listed here for information purposes, but the definitions in "XHTML Modularization" should be considered authoritative. In the
on-line version of this document, the module names in the list below link into the definitions of the modules within the current versions of "XHTML Modularization".

The Metainformation Attributes Module defines the Metainformation attribute collection. This collection allows elements to
be annotated with metadata throughout an XHTML-family document. When this module is included in a markup language, this collection is added to the Common attribute collection as defined in [XHTMLMOD].

This attribute specifies a value of type CDATA that defines the metadata associated
with an element. If not specified, then the metadata for an element is its content. If it is specified, and there is no property attribute, then the property is considered to be
reference.

The list of predefined values (in the XHTML namesapce) is given below. Users may extend this collection of relationships, however new values must be defined in their own vocabulary, and the
relationship names must be referenced in documents as CURIEs (e.g., dc:creator for the Dublin Core "creator" relationship).

<html .... xmlns:dc="http://purl.org/dc/elements/1.1/">

description

Gives a description of the resource.

generator

Identifies the software used to generate the resource.

keywords

Gives a comma-separated list of keywords describing the resource.

reference

The default value, gives no explicit information about the relationship with the resource.

robots

Gives advisory information intended for automated web-crawling software. This specification does not define values for this property.

title

Specifies a title for the resource.

Note that previous versions of XHTML included an author property; this has now been replaced with the Dublin Core creator property.

This attribute describes the relationship between the resource specified by @about (or its default value) and the resource referred to by @href
as defined in XHTML. The type for this attribute is a space-separated list of CURIEs.

<link href="top.html" rel="contents" />

This example defines a link to a table of contents for the current document.

This example defines a link to an alternate version of the document especially suited to printing.

Authors may use the following relationship names, listed here with their conventional interpretations.

User agents, search engines, etc. may interpret these relationships in a variety of ways. For example, user agents may provide access to linked documents through a navigation bar.

Users may extend this collection of relationships. However, extensions must be defined in their own vocabulary, and the relationship names must be referenced in documents as CURIEs (e.g., dc:creator for the Dublin Core "creator" relationship).

Note that in order to reference relationship definitions via CURIE, their prefix must be defined via an xmlns attribute somewhere suitable:

<html .... xmlns:dc="http://purl.org/dc/elements/1.1/">

alternate

Designates alternate versions for the document.

appendix

Refers to a resource serving as an appendix in a collection.

bookmark

Refers to a bookmark. A bookmark is a link to a key entry point within an extended document. The @title attribute may be used, for example, to label the bookmark. Note
that several bookmarks may be defined for a document.

cite

Refers to a resource that defines a citation. In the following example, the cite is used to reference the book from which the quotation is taken:

cite as book reference

As Gandalf the White said in
<span rel="cite" about="http://www.example.com/books/the_two_towers">
The Two Towers
</span>,
<quote xml:lang="en">"The hospitality of
your hall is somewhat lessened of late, Theoden King."</quote>

cite to reference another specification

More information can be found in
<span property="cite" about="http://www.w3.org/TR/REC-xml">[XML]</cite>.

chapter

Refers to a resource serving as a chapter in a collection.

contents

Refers to a resource serving as a table of contents.

copyright

Refers to a copyright statement for the resource.

glossary

Refers to a resource providing a glossary of terms.

help

Refers to a resource offering help (more information, links to other sources of information, etc.)

icon

Refers to a resource that represents an icon.

index

Refers to a resource providing an index.

meta

Refers to a resource that provides metadata, for instance in RDF.

next

Refers to the next resource (after the current one) in an ordered collection.

This attribute takes a URIorCURIE, and can be used to define the resource referenced by a @rel, @rev, or @property attribute. When provided, the value of @resource supercedes any value for the @href
attribute on the same element.

This attribute is the complement of the @rel attribute and describes the reverse relationship between the resource specified by the @about
attribute (or its default value) and the resource referred to by the @href attribute. Its value is a space-separated list of
CURIEs. For a list of relationship names, see the @rel attribute.

<link href="doc.html" rev="contents"/>

This example states that the current document is the table of contents for the referenced document.

While outside the scope of this specification, RDFa is intended to be extensible for use in host languages beyond XHTML 1.1. The XHTML 2 Working Group is producing a separate specification [XHTMLRDFA] that defines the XHTML Modularization-compatible [XHTMLMOD] modules to facilitate such host languages.

If a language includes @xml:base [XMLBASE], an RDFa parser for that host language must process it, and use its value to set
[base].

This appendix includes an implementation of the XHTML+RDFa 1.0 language as an XML DTD. It is implemented by by combining the XHTML 1.1 DTD with the XHTML Metainformation Attribute Module. This is
done by using a content model module, and then a driver module:

2007-09-04: Migrated to XHTML 2 Working Group Publication System. Converted to a format that is consistent with REC-Track documents. Updated to reflect current processing model. Added normative
definition of CURIEs. Started updating prose to be consistent with current task force agremeents. [ShaneMcCarron], [StevenPemberton], [MarkBirbeck]

2007-04-06: fixed some of the language to talk about "structure" rather than metadata. Added note regarding space-separated values in predicate-denoting attributes. [BenAdida]

2006-01-16: made the use of CURIE type for @rel, @rev, @property consistent across document (particularly section 2.4
was erroneous). [BenAdida]