RDF/A Syntax They went in single file, running like hounds on a strong scent, They went in single file, running like hounds on a strong scent, They went in single file, running like hounds on a strong scent, They went in single file, running like hounds on a strong scent,
RDF/A Syntax
A collection of attributes for layering RDF on XML languages
Editor's Draft 27 October 2005
This version:
Latest version:
Previous version:
Editors:
Mark Birbeck, x-port.net Ltd.
Steven Pemberton, CWI
Ben Adida, Creative Commons
W3C
MIT
ERCIM
Keio
), All Rights Reserved. W3C
liability
trademark
document use
, and
software licensing
rules apply.
Abstract
The aim of this document is to outline a syntax for layering RDF information on any XML document, via attributes.
Status of this Document
This is an internal draft produced by the RDF-in-HTML
task force
[RDFHTML]
, a joint task force of
the Semantic Web Best Practices and Deployment Working
Group
[SWBPD-WG]
and HTML Working Group
[HTML-WG]
Last Modified: 2005-10-27
Table of Contents
Motivation
Terms and Abbrevations
2.1
Namespaces
2.2
RDF Terminology
2.2.1
N-Triples
2.3
Using xml:base
2.4
Using CURIEs
Introduction to the structure of RDF/A
3.1
General Approach
3.2
Qualifying document components
3.3
Relating document components
3.4
Global RDF statements
RDF/A in detail
4.1
Processing
4.2
Establishing the predicate
4.2.1
Using the property attribute
4.2.2
Using the rel attribute
4.2.3
Using the rev attribute
4.2.4
Using both rel and rev attribute
4.3
Establishing the subject
4.3.1
The about attribute
4.3.2
Inheriting the about attribute
4.3.3
meta and link elements
4.3.3.1
meta or link inside the head in XHTML2
4.4
Establishing the object
4.4.1
Literal object resolution using the content attribute
4.4.2
URI object resolution using the href attribute
4.5
Summary
RDF Concepts
5.1
Literals as Objects
5.1.1
Without datatype
5.1.1.1
XML Literals
5.1.1.2
Language Tags
5.1.2
With datatype
5.1.2.1
Literal from string value of meta
5.2
Blank nodes
5.3
Reification
Examples
6.1
Creative Commons
6.2
FOAF
Rules
Bibliography
Change History
1 Motivation
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 DTD's, 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 actual data and the RDF/XML
metadata. 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
"Mark Birbeck" should not need to repeat this name for RDF
expression of the same concept: the existing markup should
be augmentable to RDF with minimal data repetition.
In the past, some attributes were 'hard-wired' directly
into the markup language to represent specific concepts.
For example, in XHTML 1.1 and HTML there is
cite
attribute. The attribute allows an author
to add information to a document to indicate the origin of a
quote. The following example comes from
[HTML]
, although it has been reformatted as XHTML
[XHTML]
and an eager light was in their eyes. Nearly due west the broad
swath of the marching Orcs tramped its ugly slot; the sweet grass
of Rohan had been bruised and blackened as they passed.
The problem here is that we have had to add a specific attribute to designate citation, and further, both the browser and some
metadata processor need to have knowledge of this attribute, and its position within the mark-up.
The RDF/XML solution is to take the citation out as a
specific statement about the quote. Our source document may
now look like this:
and an eager light was in their eyes. Nearly due west the broad
swath of the marching Orcs tramped its ugly slot; the sweet grass
of Rohan had been bruised and blackened as they passed.
and the RDF/XML looks like this:
Whilst this approach gives unlimited flexibility, it has not
been widely adopted outside the RDF community. Part of the
reason is the complexity of RDF/XML. A more fundamental
problem is that RDF/XML often requires duplicating data
already expressed in the original XML dialect. The
motivation of RDF/A was to devise a means by which documents
could be augmented with metadata, using property values from
the growing range of available taxonomies, reusing existing
content from the host language. In RDF/A, one way that the
example given above could be marked-up is as follows:
and an eager light was in their eyes. Nearly due west the broad
swath of the marching Orcs tramped its ugly slot; the sweet grass
of Rohan had been bruised and blackened as they passed.
Or, if the publisher wishes to give the user a clickable
link with the same embedded RDF:
taken from href="http://www.example.com/tolkien/twotowers.html">
Tolkien's Two Towers.
and an eager light was in their eyes. Nearly due west the broad
swath of the marching Orcs tramped its ugly slot; the sweet grass
of Rohan had been bruised and blackened as they passed.
We feel this proposal contributes to standardisation, and
takes the pressure off language authors to anticipate all
the metadata requirements users of their language might
have -- in this example we have used "source" from the
Dublin Core
[DC]
list, rather than inventing
our own citation attribute which would be unknown to other
languages. For example, the source could still be determined
if the same quote were marked-up in SVG:
They went in single file, running like hounds on a strong scent,
and an eager light was in their eyes. Nearly due west the broad
swath of the marching Orcs tramped its ugly slot; the sweet grass
of Rohan had been bruised and blackened as they passed.
We feel these aspects of our proposal are crucial to the future of the Semantic Web, and the place of mark-up documents
within it.
This proposal therefore outlines a new XML syntax for RDF that relies only on XML attributes, and so can be easily imported
into other markup languages allowing them to carry arbitrary RDF.
2 Terms and Abbrevations
2.1 Namespaces
In the following examples, for brevity assume that the following namespace prefixes are defined:
cc:
dc:
ex:
foaf:
rdf:
rdfs:
svg:
xh11:
xsd:
2.2 RDF Terminology
This document uses the following terminology defined in
[RDF-CONCEPTS]
URI reference
literal
plain literal
typed literal
XML literal
XML value
node
blank node
triple
RDF graph
We also add two further concepts, an [RDF/A element] and the [context statement] both of which are explained in the
processing section.
The aim of RDF/A is to allow [RDF graph]s to be carried in XML documents of any type. 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
[RDF URI reference] or a [blank node], the predicate is
always
an [RDF URI reference], and the
object of a statement can be an [RDF URI reference], a [literal], or a [blank node].
In RDF/A, a subject [RDF URI reference] is
indicated using the attribute
about
and
predicates are represented using one of the
attributes
property
rel
, or
rev
. Objects which are [RDF URI reference]s
are represented using the attribute
href
, whilst objects that are [literal]s are represented either with the
attribute
content
, or the content of the element in question.
2.2.1 N-Triples
Most of the examples in this document are shown translated into N-Triples
[N-TRIPLES]
syntax, with a slight variation
in that QNames can be used to replace a URI reference. To tell them apart, the QName will have no angle brackets, e.g. the triple:
should be read as an abbreviation for the N-Triples syntax:
"Mark Birbeck" .
Datatypes can also be abbreviated, so the following:
<> dc:title
"E = mc2: The Most Urgent Problem of Our Time"^^rdf:XMLLiteral .
should be read as an abbreviation for this N-Triples statement:
<>
"E = mc2: The Most Urgent Problem of Our Time"^^
2.3 Using
xml:base
All [RDF URI references] are subject to
xml:base
[XML-BASE]
. Note
that this means that in the absence of an
xml:base
attribute, the document containing the RDF statements is
itself
the base.
An example follows to show how
xml:base
affects the subject:
The triples generated would be as follows:
dc:creator
dc:title
"Internet Applications" .
2.4 Using CURIEs
In order to allow for the compact expression of RDF
statements, RDF/A uses CURIEs (Compact URIs)
[CURIE]
. The
rel
rev
and
property
attributes accept CURIE-only
datatypes, while
href
and
about
accept mixed CURIE/URI data. In particular, the
following notation is a valid RDF/A statement:
This document is licensed under a
rel="cc:license"
href="[cclicenses:by/nc-nd/2.5/]">
Creative Commons License
.
which generates the following triple, as expected:
<> cc:license
3 Introduction to the structure of RDF/A
3.1 General Approach
The main idea behind the syntax for RDF/A is that existing
data should be easy to update to convey RDF triples. Thus,
the bulk of RDF/A can be expressed using only attributes
applied to existing elements within the XML document,
specifically
about
rel
rev
property
and
content
. In addition, it should be possible
to represent a [triple] using only one XML element. In
this way it owes more to 'flat' syntaxes like RDF/N3
[N3-PRIMER]
than it does to RDF/XML
[RDF-SYNTAX]
, despite its use of XML.
For example, given an XHTML chunk as follows:
This photo was taken by
.
a simple attribute augmentation can yield an RDF triple:
This photo was taken by
.
which yields:
Note that, in the above example, had "Mark Birbeck" not been
enclosed in an existing
span
element, a new one could
have simply been used with
about
and
property
as its only two attributes.
Similarly, links can be augmented to express RDF triples. Consider an XHTML chunk:
This photo was taken by
Mark Birbeck.
When the RDF object is a URI, the RDF predicate is designated using
rel
This photo was taken by
href="http://www.blogger.com/profile/1109404">Mark Birbeck.
which yields:
It's important to note that the various RDF/A attributes can be used
on any existing element of the XML dialect. Note also that one can
express a reverse relationship using the
rev
attribute. For example, if the photo in question is actually a
depiction of Mark, one could write:
This photo was taken by
href="http://www.blogger.com/profile/1109404">Mark Birbeck.
which would yield:
Both relations can be expressed simultaneously:
This photo was taken by
href="http://www.blogger.com/profile/1109404">Mark Birbeck.
which then yields both triples:
And it's also possible to go further and add the attributes used for
denoting statements in which the object is a [literal]:
This photo was taken by
content="Portrait of Mark" rel="dc:creator"
rev="foaf:img" href="http://www.blogger.com/profile/1109404">Mark Birbeck.
which would then yield:
It's possible to do all of this without ambiguity, since
the
property
attribute always denotes a predicate in a
statement in which the object is a [literal], whilst
the
rel
and
rev
attributes always denote a
predicate in a statement in which the object is a [URI reference]. Put
a different way,
property
always works
with
content
, whilst
rel
and
rev
work with
href
Of course, the more natural way to express the three
above triples is to strive to make all metadata literals
and URIs meaningful within the host XML
dialect. Specifically, in the case of XHTML2, it makes
sense to render as much of the useful metadata as
possible and use RDF/A to mark up this rendered data. The
following XHTML thus generates the same triples shown
above.
This photo, entitled
Portrait of Mark
was taken by
href="http://www.blogger.com/profile/1109404">Mark himself.
As expected, an empty string in the
about
attribute
designates the current URI. In addition, the value of
the
about
attribute is inherited from parent
elements. The following XHTML thus generates the very same triples as
the XHTML above.
This photo, entitled
Portrait of Mark
was taken by
href="http://www.blogger.com/profile/1109404">Mark himself.
3.2 Qualifying document components
A second feature of RDF/A is that it is possible to use
parts of the host document to provide the [subject] of a
[triple]. This marks RDF/A from other approaches to
serialising RDF, in that the the same syntax can now be
used to make statements about parts of a document, and
external documents.
It is possible to make such statements using the syntax
introduced in the examples above:
Rodion Romanovitch! My dear friend! If you go on in this way
you will go mad, I am positive! Drink, pray, if only a few drops!
However, two problems arise: the
href
causes
the entire quotation to become a clickable link, which may
not be the desired visual effect, and only one triple can
be expressed. Thus, RDF/A provides another mechanism,
using the special
link
or
meta
element without a specified [subject]. In such cases, the
[triple] concerns the parent element. This allows the
example above to be recast as follows:
Rodion Romanovitch! My dear friend! If you go on in this way
you will go mad, I am positive! Drink, pray, if only a few drops!
This syntax (omitting the
about
attribute to
refer to the parent element) only applies to the
elements
link
and
meta
, which means
that even without an
id
attribute, the
following statement is still 'about'
the
blockquote
element, and not the document as
a whole:
Rodion Romanovitch! My dear friend! If you go on in this way
you will go mad, I am positive! Drink, pray, if only a few drops!
If more than one piece of metadata needs to be attached to the same
element, then additional
link
or
meta
elements can be added:
Rodion Romanovitch! My dear friend! If you go on in this way
you will go mad, I am positive! Drink, pray, if only a few drops!
Now we have attached two pieces of metadata to
the
blockquote
element -- the source of the
quote, and its author.
Note:
We say nothing here about how this metadata is used. In
the previous example, the information may be of use to
an RDF/A-aware browser, and it could be made available
to the user accessing the page via a mechanism such as
tooltips. But it may also be the case that the document
is parsed by some external processor and the output
stored as a set of [triple]s. In the latter case the
[triple]s generated by the previous example would have a
[unique anonymous ID] as the subject of each statement,
as follows:
_:a dc:source
_:a dc:creator "Fyodor Dostoevsky" .
If one wishes a non-anonymous node to represent the blockquote,
one only needs to add an additional attribute to
the
blockquote
, namely the usual XML
id
attribute:
Rodion Romanovitch! My dear friend! If you go on in this way
you will go mad, I am positive! Drink, pray, if only a few drops!
which then yields:
<#q1> dc:source
<#q1> dc:creator "Fyodor Dostoevsky" .
3.3 Relating document components
Using qualifying statements, RDF/A allows a single XML dialect
document to include multiple RDF entities. Relations between the
various entities of a given page can also be defined using RDF/A
notation.
Consider the following XHTML, which defines two RDF entities of
type
taxo:topic
, two RDF entities of
type
biblio:Publication
, metadata pertinent to each
publication, including
dc:title
and
dc:creator
, and relations of
type
taxo:topics
between the publications and tags:
Tags
Standards
XForms
Publications
A Standards-Based Virtual Machine
XForms and Internet Applications
This yields the expected triples:
<#tag_standards> rdf:type taxo:topic .
<#tag_xforms> rdf:type taxo:topic .
<#publication_1> rdf:type biblio:Publication .
<#publication_1> dc:creator
<#publication_1> dc:title "A Standards-Based Virtual Machine" .
<#publication_1> taxo:topics <#tag_standards> .
<#publication_2> rdf:type biblio:Publication .
<#publication_2> dc:creator
<#publication_2> dc:title "XForms and Internet Applications" .
<#publication_2> taxo:topics <#tag_standards> .
<#publication_2> taxo:topics <#tag_xforms> .
Beyond this theoretical example, this application of RDF/A is
particularly useful for formats like FOAF. (See examples.)
3.4 Global RDF statements
The previous series of examples may mislead one to think that RDF/A
statements are only contextual, only meant to qualify existing
elements. However, as the first examples implied, a
fixed
about
attribute can be used to specify a global
subject. It is actually quite easy to make independent, global RDF
statements. Statements like:
This document is licensed under a
href="http://creativecommons.org/licenses/by-nc-nd/2.5/">
Creative Commons
.
will produce the same triple no matter where they're located in the document:
<> cc:license
4 RDF/A in detail
In this section we look in more detail at the [triple]s that are
generated when using RDF/A attributes and elements. We've already
said that the aim is to make it possible to generate a [triple] with
one element. However, we also saw that parent elements may have an
effect on the triple represented by their children elements. We
therefore need to understand how the subject, predicate and object
parts of a [triple] are established from our syntax.
4.1 Processing
An [RDF/A element] is defined as any XML element
that contains one or more RDF/A
attributes:
about
property
rel
rev
href
content
Processing proceeds by examining each [RDF/A element] in
turn. The [RDF/A element] under consideration at any time
is the [current statement], and its parent element is the
[context statement]. Note that the [context statement]
does not need to be an [RDF/A element]. RDF/A also
includes a
datatype
attribute. The presence of that
attribute does not by itself designate an [RDF/A element].
As each [RDF/A element] is examined, the processor tries
to establish the RDF triples it generates. There is
exactly one triple generated
per
rel
rev
, or
property
attribute. Thus, an [RDF/A element] can generate at most 3
RDF triples, one for each of those three attributes. (For
now, we do not consider the effects of reification.) It
makes sense, then, for the processor to start with
identifying the predicate of a triple, then to figure out
the triple's subject and object.
4.2 Establishing the predicate
The predicate of a statement is specified using
property
rel
or
rev
attribute. These attributes can be placed on any element in a
document, and -- although readability may suffer -- can even
co-exist on the same element. The processor rule is simple: each of
these attributes generates exactly one triple. The specific type of
predicate indicates the type of resolution to use for the subject
and object of the triple.
4.2.1 Using the
property
attribute
property
attribute indicates a new statement whose
predicate is the value of that attribute. The subject of the triple
will be decided using subject resolution (Section 4.3). The object
of the triple will be decided using [literal] object resolution
(Section 4.4). The following example indicates the name of the
author responsible for the text being quoted:
Rodion Romanovitch! My dear friend! If you go on in this way
you will go mad, I am positive! Drink, pray, if only a few drops!
4.2.2 Using the
rel
attribute
rel
attribute indicates a new statement whose
predicate is the value of that attribute. The subject of the triple
will be decided using subject resolution (Section 4.3). The object
of the triple will be decided using [URI reference] object
resolution (Section 4.4). The following example indicates that one
'FOAF person' knows another:
rel="foaf:knows" href="mailto:libby.miller@bristol.ac.uk" />
The triple generated is:
foaf:knows
4.2.3 Using the
rev
attribute
rev
attribute indicates a new statement whose
predicate is the value of that attribute. The subject of the triple
will be decided using [URI reference]
object
resolution
(Section 4.4). The object of the triple will be decided
using
subject
resolution (Section 4.3). Note that
resolution is effectively the same as if the
rev
attribute had been a
rel
attribute with object and
subject reversed. The following example indicates that one 'FOAF
person' knows another:
rev="foaf:knows" href="mailto:libby.miller@bristol.ac.uk" />
and the [triple] generated is essentially a reversal of our previous example:
foaf:knows
4.2.4 Using both
rel
and
rev
attribute
It is perfectly acceptable to use both
rel
and
rev
attributes within the same
element. According to the rule that every predicate
generates a triple, this approach predictably yields two
triples. For example:
rel="foaf:knowns" rev="foaf:knows" href="mailto:libby.miller@bristol.ac.uk" />
generates:
foaf:knows
foaf:knows
The predicates need not be the same, of course.
4.3 Establishing the subject
Once a predicate has been established, subject resolution can begin,
using as a basis the [RDF/A element] that contains the
predicate-generating attribute. The [context statement] may also be
relevant in determining the subject. If the predicate was established
using the
property
or
rel
attribute, then
the subject is determined by the
about
attribute,
including inheritance and some exceptions for
meta
and
link
elements, as detailed in this section. If the
predicate was established using the
rev
attribute, then
the subject is determined using
object resolution
in the next
section.
4.3.1 The
about
attribute
The subject of a triple is usually indicated using the
about
attribute, as follows:
rel="foaf:knows" href="mailto:libby.miller@bristol.ac.uk" />
rel="foaf:knows" href="mailto:ian.sealy@bristol.ac.uk" />
The value of the
about
attribute is of type CURIE/URI
[REF], meaning it can either be a URI, absolute or relative, or a
CURIE in square brackets. Some example values of an
about
attribute include:
#person
: the base URI
with
#person
appended to it. Refers to the
XML element with
id="person"
, if such an
element exists.
: the absolute URI as indicated.
[finance:GOOG]
: the
CURIE
finance:GOOG
4.3.2 Inheriting the
about
attribute
Note that this section does not apply to [RDF/A statement]s whose
predicates are defined in
meta
or
link
elements. Section 4.3.3 deals with
meta
and
link
specifically.
If the [RDF/A element] that includes the predicate
attribute does not have an
about
attribute,
then the subject of the [triple] is determined by the
[context statement]'s
about
attribute. The
resolution of the
about
attribute is
recursive: if the [context statement] has no such
attribute, then the processor must continue up the DOM
tree to find the closest ancestor with
an
about
attribute.
For example, the following XHTML:
this photo was taken by
Mark Birbeck
will inherit the
about
attribute from the
enclosing
div
and yield the expected triple:
If no such parent is ever found all the way up the DOM tree, then the
default value for the
about
attribute is the empty
string, which effectively indicates the current document.
4.3.3
meta
and
link
elements
@@TODO: make sure the treatment of
the
id
attribute is precise here. In
particular, what happens with an
id
attribute on a
meta
or
link
If an [RDF/A statement] is generated by a predicate attribute of
meta
or
link
element, and this element
does not contain an explicit
about
attribute, subject
resolution is slightly different. Only the immediate [context
statement] is considered, whether or not it has its
own
about
attribute.
If the [context statement] is a
meta
or
link
element itself, the [RDF/A statement] represented by the [context
statement] is reified as the subject of this new [RDF/A
statement]. More details on reification in RDF/A are found in Section
5.3.
Otherwise, if the [context statement] is neither a
meta
nor a
link
, two cases should be considered. The [context
statement] may have an
about
attribute, in which case the
[RDF/A statement]'s subject is resolved as the value of this attribute
(exactly as if the current [RDF/A statement] weren't
link
or
meta
.) However, if the [context
statement] does not have an
about
attribute, the subject
of the current [RDF/A statement] is the parent element itself. If this
parent element is not identified with
xml:id
, it is
treated as a [unique anonymous ID].
For example, the following XHTML:
This photo was taken by Mark Birbeck.
will generate one triple corresponding to the
property
attribute of the
meta
element, whose subject is resolved
as the value of the
about
attribute of the immediate
parent element (
div
).
However, the following, slightly different, XHTML:
This photo was taken by
Mark Birbeck
.
will yield the possibly unexpected:
_:span0 dc:creator "Mark Birbeck" .
The
meta
and
link
elements should be thought
of as mechanisms for applying metadata to any existing element in the
XML document. Thus, to recover the previous triple, one could simply
switch the
meta
to a
span
, which will
trigger the recursive search up the DOM tree for the
closest
about
attribute (this is exactly the same example
as that of the previous section):
This photo was taken by
Mark Birbeck
.
4.3.3.1
meta
or
link
inside the
head
in XHTML2
meta
or
link
without its
own
about
attribute and positioned
directly within the
head
of a document will
automatically apply to the document
itself. Effectively, the
head
of an XHTML2
document contains an implicit
about=""
Note also that this isn't exactly the same thing as
having the subject eventually default -- all the way
up the DOM tree -- to the current
document. A
meta
or
link
element
applies to the parent element, never inheriting
further up the tree than the
head
element,
in this case. Thus, this additional detail about
the
head
element is not redundant with any
other instruction in this document.
4.4 Establishing the object
The object of the statement can be set using one of the
attributes
content
or
href
. Which
attribute is used depends on how the predicate was
set. If the predicate was set using
property
then the object will be a [literal], and its value will
come from the
content
attribute or the
element content. If the predicate was set with
the
rel
attribute, then the object will be a
CURIE/URI whose value is obtained from
the
href
attribute. If the predicate was set
with the
rev
attribute, then the object will
be obtained using
subject resolution
as defined
in the previous section.
4.4.1 Literal object resolution using the
content
attribute
The
content
attribute can be used to indicate a [plain literal] as follows:
property="dc:creator" content="Mark Birbeck" />
or, alternatively, using the content of the element (
meta
or other) as an [XMLliteral]:
property="dc:creator">Mark Birbeck
If the element that carries the
property
attribute also
carries a
content
attribute and is non-empty, the value
of the
content
attribute takes precedence and is taken to
be the object of the triple.
More details on determining the type of a literal
object are provided in Section 5.1.
4.4.2 URI object resolution using the
href
attribute
The
href
attribute on the [RDF/A statement]'s element
is used to indicate the object as a [URI reference]. Its type, just
like that of the
about
attribute, is CURIE/URI:
rel="foaf:knows" href="mailto:libby.miller@bristol.ac.uk" />
There is no other way to specify a triple's URI object in RDF/A.
4.5 Summary
This section will contain a summary of the syntax.
5 RDF Concepts
Having established the different parts of the syntax of RDF/A, we will now look at
the various aspects of the RDF Abstract Syntax, and see how they can be represented
in RDF/A.
5.1 Literals as Objects
When a
property
predicate is used in RDF/A, the
object is expected to be a literal. This literal can be
optionally typed by a
datatype
attribute within
the same RDF/A element. The absence or presence of this
attribute has a significant impact on the interpretation
of the literal.
5.1.1 Without
datatype
Without a
datatype
attribute, the object
literal will either be a plain literal or an XML
literal, depending on whether the
content
attribute is used. For example, consider the following
XHTML with RDF/A which designates the author of a web
page:
...
In this case, with the use of the
content
attribute indicates that the object is a plain
literal:
<> dc:creator "Mark Birbeck" .
On the other hand, the following RDF/A will yield a
slightly different triple:
Mark Birbeck
...
which yields an XML literal object:
<> dc:creator "Mark Birbeck"^^rdf:XMLLiteral .
5.1.1.1 XML Literals
The default
rdf:XMLLiteral
type plays a
significant role. XML documents cannot contain XML
mark-up in their attributes, which means it is not
possible to represent XML within the
content
attribute. The following would cause an XML parser to generate an error:
Author: Albert Einstein
content="E = mc2: The Most Urgent Problem of Our Time" />
It does not help to escape the content, since the
output would simply be a string of text containing
numerous ampersands:
<> dc:title
"E = mc<sup>2</sup>: The Most Urgent Problem of Our Time" .
RDF does, however, provide a datatype for indicating
[XML literal]s. RDF/A therefore adds this datatype
to any [literal] that is indicated using child text
nodes on the [RDF/A statement]. For example:
Author: Albert Einstein
E = mc2: The Most Urgent Problem of Our Time
would generate the expected triple:
<> dc:title
"E = mc2: The Most Urgent Problem of Our Time"^^rdf:XMLLiteral .
Note that the value of this [XML Literal] is the
exclusive canonicalization of the RDF/A element's
value.
5.1.1.2 Language Tags
RDF allows [plain literal]s to have a language tag,
as illustrated by the following example from
[RDFTESTS-RDFMS-XMLLANG-TEST006]
In RDF/A the XML language
attribute --
xml:lang
-- is used to add
this information, whether the plain literal is
designated by the
content
attribute, or by
datatype
value of
plaintext
property="ex:property" xml:lang="fr" content="chat" />
Note that the value can be inherited as defined in
[XML-LANG]
, so the following syntax
will give the same triple as above:
property="ex:property" content="chat" />
...
5.1.2 With
datatype
RDF allows [literal]s to be given a data type, as illustrated by the following example from
[RDFTESTS-DATATYPES-TEST001]
"10"^^
This can be represented in RDF/A as follows:
property="ex:bar" content="10" datatype="xsd:integer">ten
5.1.2.1 Literal from string value of
meta
If the
datatype
is specified, but
no
content
attribute exists, then the
typed literal's value is determined as the
concatenation of all textual child elements. For example, the following RDF/A:
property="dc:creator" datatype="xsd:string">
Mark Birbeck
.
will yield the following triple:
5.2 Blank nodes
A [blank node] is generated explicitly when an [RDF/A statement]
uses a bnode CURIE as its subject. A [blank node] can be generated
more implicitly when an XML element without an
about
attribute has
meta
or
link
children
elements, also without
about
attributes of their own.
In the latter case, the [unique anonymous ID] generated to identify
the [blank node] is associated with the [context statement] of
the
meta
and
link
elements. This allows a
number of statements to be made about the same [blank node].
For example, to establish relationships between a [blank node] and
literals or URIs, one can use the implicit [blank node] construction
of our earlier exapmle, repeated here:
Rodion Romanovitch! My dear friend! If you go on in this way
you will go mad, I am positive! Drink, pray, if only a few drops!
This would generate the following [triple]s:
_:a dc:source
_:a dc:creator "Fyodor Dostoevsky" .
One could also use the more explicit declaration:
Rodion Romanovitch! My dear friend! If you go on in this way
you will go mad, I am positive! Drink, pray, if only a few drops!
rel="dc:source" href="urn:isbn:0140449132" />
property="dc:creator" content="Fyodor Dostoevsky" />
To establish relationships between [blank node]s, the [unique
anonymous ID] must be set explicity using a CURIE bnode as subject
or object. For example, if our desired output is the following
[triple]s:
_:a foaf:mbox mailto:daniel.brickley@bristol.ac.uk .
_:b foaf:mbox mailto:libby.miller@bristol.ac.uk .
_:a foaf:knows _:b .
we could use the following XHTML:
href="mailto:daniel.brickley@bristol.ac.uk" />
href="mailto:libby.miller@bristol.ac.uk" />
href="[_:b]" />
or, alternatively, if we wish to partly render the information in XHTML:
5.3 Reification
RDF/A partially supports reification.
During subject resolution (which could be triggered by object
resolution for a
rev
attribute), the processor may
traverse up the DOM tree in search of an
about
attribute. If a
link
or
meta
element is
encountered before an
about
attribute is found, and if
this
link
or
meta
element itself does not
have an
about
attribute, then the subject (or, again in
the case of
rev
, object) is resolved as the [RDF/A
statement] represented by this
link
or
meta
element.
For example, the following XHTML:
href="http://creativecommons.org/licenses/by-nc-nd/2.5/">
will yield the following triples:
<> cc:license
<> dc:creator "Mark Birbeck."
_:a rdf:type rdf:Statement .
_:a rdf:subject <> .
_:a rdf:predicate cc:license .
_:a rdf:object
_:a dc:creator "Ben Adida" .
which means that "Mark Birbeck" is the creator of the current
document, that this document is licensed under a Creative Commons
license, and that "Ben Adida" is the creator of that licensing
statement,
not
of the document itself.
6 Examples
6.1 Creative Commons
One of the advantages of using the same syntax to make general statements as well as statements about a document is
that in many cases a document can carry its own metadata. For example, if an XHTML document contains a navigable link
to the Creative Commons license, this link can also be used to express metadata:
This document is licensed under a
href="http://creativecommons.org/licenses/by-sa/2.0/">
Creative Commons License
which, among other things, requires that you provide
attribution to the author,
Ben Adida.
This chunk of XHTML will generate the same triples, no matter what other XHTML contains it:
<> cc:license
<> dc:creator
6.2 FOAF
FOAF requires the definition of at least two RDF entities: the FOAF
person, and the FOAF homepage, which cannot be the same. Thus, the
following XHTML can be used to represent a FOAF record:
Dan is located at latitude
51.47026
and longitude
-2.59466
Dan Brickley
which yields the correct FOAF triples:
<> dc:title "Dan's home page" .
_:geolocation geo:lat "51.47026" .
_:geolocation geo:long "-2.59466" .
<#person> rdf:type foaf:Person .
<#person> foaf:homepage <> .
<#person> foaf:based_near _:geolocation .
<#person> foaf:name "Dan Brickley" .
If one wants to make the
foaf:Person
a blank node, then
the only change required is taking out the
id="person"
from the
span
element, which then yields the following
triples:
<> dc:title "Dan's home page" .
_:geolocation geo:lat "51.47026" .
_:geolocation geo:long "-2.59466" .
_:span0 rdf:type foaf:Person .
_:span0 foaf:homepage <> .
_:span0 foaf:based_near _:geolocation .
_:span0 foaf:name "Dan Brickley" .
7 Rules
(not updated yet.)
8 Bibliography
DC
Dublin Core Metadata Initiative (DCMI) (See
.)
FOAF-PROJECT
The FOAF Project (See
.)
HTML
HTML 4.01 Specification (See
.)
N-TRIPLES
RDF Test Cases, N-Triples (See
.)
N3-PRIMER
N3 Primer (See
.)
RDF-CONCEPTS
Resource Description Framework (RDF): Concepts and Abstract Syntax (See
.)
RDF-SYNTAX
RDF/XML Syntax
and Grammar (See
.)
RDFTESTS-DATATYPES-TEST001
datatypes/test001.nt (See
.)
RDFTESTS-RDFMS-XMLLANG-TEST006
rdfms-xmllang/test006.nt (See
.)
RELAXNG
RELAX NG Home Page (See
.)
XHTML
XHTML 1.0 (See
.)
XHTML-2.0-LINKTYPES
XHTML
2.0 Link Types (See
.)
XML-BASE
XML Base (See
.)
XML-LANG
Extensible Markup Language (XML) 1.0 (Third Edition), Language Identification (See
.)
XPOINTER-FRAMEWORK
XPointer Framework (See
.)
RDFHTML
RDF-in-HTML Task Force (See
.)
SWBPD-WG
Semantic Web Best Practices and Deployment Working Group (See
.)
HTML-WG
HTML Working Group (See
.)
CURIE
CURIEs (See
.)
9 Change History
2006-01-16: made the use of CURIE type
for
rel
rev
property
consistent across document (particularly section 2.4 was
erroneous). [BenAdida]