1 Purpose of RDF/A and Preliminaries
RDF/A is a set of attributes used to embed RDF in XHTML. An
important goal of RDF/A is to achieve this RDF embedding
without repeating existing XHTML content when that
content is the metadata. Though RDF/A was initially
designed for XHTML2, one should be able to use RDF/A with
other XML dialects, e.g. XHTML1, SVG, given proper schema
additions.
We note that RDF/A makes use of XML namespaces. In this
document, we assume, for simplicity's sake, that the
following namespaces are defined: dc for Dublin
Core, foaf for FOAF, cc for
Creative Commons, and xsd for XML Schema Definitions.
2 A Simple Scenario
IMPORTANT NOTE: The examples in this section
(Section 2) are incorrect according to TAG instructions
on which URIs constitute information resources and which
URIs can refer to non-information resource
entities. Specifically, the examples in this section use
the same URI to refer to both a Person (or a group of
people) and a document. The debate on how to solve this
is on
the mailing
list.
Jo has lots of friends, family and work colleagues with which she would like to stay
in touch during her busy schedule. She would like to set up a home-page for herself,
where people who know her can find useful contact information, such as her phone
number or work email.
2.1 Setting Up the Web Page
Jo's first stop is to create a page that contains information about her that can
be read by anyone using a web browser. She begins with some details for people
who might be trying to contact her at work:
<html>
<head>
<title>Jo Lambda's Home Page</title>
</head>
<body>
<p>
Hello. This is Jo Lambda's home page.
<h2>Work</h2>
If you want to contact me at work, you can
either <a href="mailto:jo.lambda@example.org">email
me</a>, or call +1 777 888 9999.
</p>
</body>
</html>
Jo can now pass on the address of her home-page to her friends, which is
http://jo-lambda.example.org/.
2.2 Adding Name and Contact Metadata
One of Jo's friends, Terri, tells Jo that the address book software she uses can be
automatically kept up-to-date with Jo's details. All Jo needs to do is to add some
tags to her home page to help the system understand her data. The tags that Terri's
address book understands come from a special list-often called a vocabulary-specifically
for describing relationships between people. The particular vocabulary is called
'Friend-of-a-friend', or FoaF [FOAF].
The first thing that Jo needs to do is add an identifier to the top of her document
that will make the FoaF vocabulary available to the rest of her home-page:
<html
xmlns:foaf="http://xmlns.com/foaf/0.1/"
>
Jo then looks through the FoaF vocabulary, and sees that the pieces of information
that she has in her page—name, phone number and email address—all have
names within FoaF. She therefore adds those names to her document, using the following
approach:
if the value we want to use for a property is in the href attribute
of an <a> element, then the rel attribute
can be added to the element, set to contain the name of the property;
if the value to be used for a property that we want to add doesn't have
an element to contain it, then one must be added;
the name of the property used to describe the contents of an element
is placed in an attribute called property.
Let's look at each of those rules.
2.2.1 Using URLs as Property Values
Jo has provided a link in her home-page to her email address, which is
jo.lambda@example.org:
.
.
.
If you want to contact me at work, you can
either <a href="mailto:jo.lambda@example.org">email
.
.
.
However, to ensure that Terri's address book software understands this, Jo
can use the FoaF mailbox property:
.
.
.
If you want to contact me at work, you can
either <a rel="foaf:mbox" href="mailto:jo.lambda@example.org">email
.
.
.
2.2.2 Using Text As Property Values
In addition to her email address, Jo also wants to add her name and phone number.
Currently the values that she would like to use for these properties are not
separated from the other text items so, as per rule 2, Jo adds some simple wrapper
elements:
<p>
Hello. This is <span>Jo Lambda</span>'s home page.
<h2>Work</h2>
If you want to contact me at work, you can
either <a rel="foaf:mbox" href="mailto:jo.lambda@example.org">email
me</a>, or call <span>+1 777 888 9999</span>.
</p>
Now that the text is inside span elements it is easy to add the FoaF
properties for name and phone number, using the RDF/A attribute property:
<p>
Hello. This is <span property="foaf:name">Jo Lambda</span>'s home page.
<h2>Work</h2>
If you want to contact me at work, you can
either <a rel="foaf:mbox" href="mailto:jo.lambda@example.org">email
me</a>, or call <span property="foaf:phone">+1 777 888 9999</span>.
</p>
2.2.3 Complete Mark-up
The completed document looks like this:
<html>
<head>
<title>Jo Lambda's Home Page</title>
</head>
<body>
<p>
Hello. This is <span property="foaf:name">Jo Lambda</span>'s
home page.
<h2>Work</h2>
If you want to contact me at work, you can
either <a rel="foaf:mbox" href="mailto:jo.lambda@example.org">email
me</a>, or call <span property="foaf:phone">+1 777 888 9999</span>.
</p>
</body>
</html>
Now all Terri needs to do is to provide the internet address for Jo's home page to her contact
software, and it will be able to extract the following information about Jo:
foaf:name = "Jo Lambda"
foaf:mbox = "mailto:jo.lambda@example.org"
foaf:phone = "+1 777 888 9999"
foaf:homepage = "http://jo-lambda.example.org/"
More formally, the markup Terri added to her XHTML
defines a set of RDF triples. Each triple
effectively represents one property of her
data. Specifically, Terri's markup yields the
following
RDF triples, expressed in
N-Triples syntax:
<> foaf:name "Jo Lambda"^^rdf:XMLLiteral ;
foaf:mbox <mailto:jo.lambda@example.org> ;
foaf:phone "+1 777 888 9999"^^rdf:XMLLiteral .
Terri's software gets the final piece of data 'for
free', since that was how Terri made the software
aware of Jo's data in the first place. And from
now on, synchronisation of Jo's data to Terri's
address book will be automatic.
Emboldened by how easy it was to keep her friend Terri up-to-date with her information, Jo decides to
encourage the same approach amongst her work colleagues. Jo is part of the widget development department
at her company, and is currently working on a project to make the widgets shinier. She decides she wants
this information to also be in a form that can be automatically kept up-to-date.
2.3 Adding A Departmental List
Jo's company intranet runs a Wiki, so it is quite straightforward to create a page for the department
in which she works. On this page she wants, amongst other things, to have a list of the deparment's
members. The page is http://intranet.example.com/WidgetDevelopmentDepartment.
The first step is to indicate in the header of the document that we are dealing with a FoaF group:
<html
xmlns:foaf="http://xmlns.com/foaf/0.1/"
>
<head>
<title>Widget Development Department</title>
<link rel="rdf:type" href="[foaf:Group]" />
</head>
The title of the group is also set:
<body>
<p>
Hello. Welcome to the
<span property="foaf:name">Widget Development Department.</span>
</p>
We have now established a foaf:group with the foaf:name of "Widget Development
Department". The next step is to list each member of the group. The best way to do this is to add
a link to a member's details, since then anyone synchronising their address
book with the departmental list will also remain synchronised with the contact details of each
member, just as Terri is synchronised with Jo's information:
<p>
<h2>Departmental Members</h2>
<ul>
<li>
<a rel="foaf:member" href="http://jo-lambda.example.org/">Jo Lambda</a>
</li>
The above XHTML will yield RDF triples, as expected:
<> rdf:type foaf:Group ;
foaf:name "Widget Development Department."^^rdf:XMLLiteral ;
foaf:member <http://jo-lambda.example.org/> .
Of course, not everyone will be as up-to-the-minute as Jo, with her home-page doubling up as
an automatic source of FoaF information; so for people without available contact information,
details can still be added inline:
<li id="andrew" about="#andrew">
<link rev="foaf:member" href="" />
<span property="foaf:firstname">Andrew</span>
<span property="foaf:surname">Smith</span> can be contacted on
<span property="foaf:phone">+1 777 888 9999</span>
</li>
</ul>
</p>
</body>
</html>
Note that if the list item (li) does not have an about attribute, then the
foaf:surname, foaf:firstname and foaf:phone properties would apply to the
foaf:group and not to the individual
member of the group. Note how membership is
defined using the rev attribute to denote a reverse relationship.
Again, this yields RDF triples, this time with a
subject other than the current URI:
<> foaf:member <#andrew> .
<#andrew> foaf:firstname "Andrew"^^rdf:XMLLiteral ;
foaf:surname "Smith"^^rdf:XMLLiteral ;
foaf:phone "+1 777 888 9999" .
3 A Second Scenario
IMPORTANT NOTE: The examples in this section
(Section 3) that relate to dc:creator are
incorrect according to TAG instructions and DC best
practices. Specifically, the examples in this section
use the same URI to refer to both a Person (or a group
of people) and a document. The debate on how to solve
this is on
the mailing
list.
3.1 The Shutr Photo Management System
Consider a (fictional) photo management web site
called Shutr, whose web site
is http://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.
The primary interface to Shutr is its web site and the XHTML
it delivers. Since photos are contributed by users with
significant amount of built-in metadata (camera type,
exposure, etc...) and additional, explicitly provided
metadata (photo caption, license, photographer's name),
Shutr may benefit from using RDF to express this rich metadata.
We explore how Shutr might use RDF/A to express this RDF
metadata right in the XHTML it already publishes. We assume
an additional XML namespace, shutr, which
corresponds to URI http://shutr.net/rdf/shutr#.
The simplest structured metadata Shutr might want to expose
is basic information about a photo album: the creator of the
album, the date of creation, and its license. We consider
literal properties first, and URI properties second. (We
ignore photo-specific metadata for now, as that involves RDF
statements about an image, which is not an XHTML
document. We will, of course, get back to this soon.)
3.2 Literal Properties
A literal property is a string of text, e.g. "Ben
Adida", a number, e.g. "28", or any other typed,
self-contained datum that one might want to express as a
metadata property.
Consider Mark Birbeck, a user of the Shutr system with
username markb, and his latest photo album
"Vacation in the South of France." This photo album
resides
at http://shutr.net/user/markb/album/12345. The
XHTML document presented upon request of that URI includes
the following XHTML snippet:
<h1>Photo Album #12345: Vacation in the South of France</h1>
<h2>created by Mark Birbeck</h2>
Notice how the rendered XHTML contains elements of the
photo album's structured metadata. Using RDF/A, Shutr can
mark up this XHTML to indicate these structured metadata
properties without repeating the raw data:
<h1>Photo Album #12345: <span property="dc:title">Vacation in the South of France</span></h1>
<h2>created by <span property="dc:creator">Mark Birbeck</span></h2>
An RDF/A-aware browser would thus extract the following
RDF triples:
<> dc:title "Vacation in the South of France"^^XMLLiteral .
<> dc:creator "Mark Birbeck"^^XMLLiteral .
(The ^^XMLLiteral notation, which denotes a datatype, will be explained shortly.)
One might wonder, given the above example, if
the span element is required to attach RDF
properties to rendered content. In fact, it is not:
the property attribute can be used on any
XHTML element. For example, if the original HTML did not
include the explicit words "Photo Album #12345":
<h1>Vacation in the South of France</h1>
<h2>created by Mark Birbeck</h2>
Then the RDF/A might look like this:
<h1 property="dc:title">Vacation in the South of France</h1>
<h2>created by <span property="dc:creator">Mark Birbeck</span></h2>
and would yield the same RDF triples, of course.
A reader who knows about XML datatypes might, at this
point in the presentation, wonder what datatype these
values will have. Given the above RDF/A, "Vacation in the
South of France" is an XML Literal. In some cases, this
may not be appropriate. Consider an expanded HTML snippet
which includes the photo album's creation date:
<h1>Vacation in the South of France</h1>
<h2>created by Mark Birbeck on 2006-01-02</h2>
A precise way to augment this HTML with RDF/A is:
<h1 property="dc:title">Vacation in the South of France</h1>
<h2>created by <span property="dc:creator">Mark Birbeck</span>
on <span property="dc:date" type="xsd:date">2006-01-02</span></h2>
which would yield the following triples (note how the
default datatype is XMLLiteral, which
explains the first example above.):
<> dc:title "Vacation in the South of France"^^XMLLiteral .
<> dc:creator "Mark Birbeck"^^XMLLiteral .
<> dc:date "2006-01-02"^^xsd:date .
Going further, Shutr realizes
that 2006-01-02, while a correct xsd:date
representation, is not exactly user-friendly. In this
case, having the rendered data be the same as the
structured data might not be the right answer. Shutr may
instead opt for the following RDF/A:
<h1 property="dc:title">Vacation in the South of France</h1>
<h2>created
by <span property="dc:creator">Mark Birbeck</span>
on <span property="dc:date" type="xsd:date"
content="2006-01-02">
January 2nd, 2006
</span>
</h2>
The above XHTML will render the date as "January 2nd,
2006" but will yield the exact same triples as above. The
use of the content attribute should be limited
to cases where the rendered text is not well-enough
structured to represent the metadata.
3.3 URI Properties
A URI property is one that is merely a reference
to a web-accessible resource, e.g. an image, a PDF
document, or another XHTML document, all reachable via the
web.
As Mark Birbeck uploads many photo albums to Shutr, the
site decides to build a user-profile page for him, a page
that summarizes all of his albums and user profile
information for others to see. This profile lives
at http://shutr.net/user/markb. Thus,
the dc:creator property should probably
reference this URI. At the same time, Mark's name on the
Shutr site should consistently link to this same URI in a
clickable fashion.
The raw XHTML snippet might look like:
<h2>created by <a href="/https/www.w3.org/user/markb">Mark Birbeck</a></h2>
Using the rel attribute, one can easily update
this HTML to include an RDF/A statement:
<h2>created by <a rel="dc:creator" href="/https/www.w3.org/user/markb">Mark Birbeck</a></h2>
This would then yield the expected triple:
<> dc:creator </user/markb> .
Similarly, Shutr may want to give its users the ability to
license their photos to the world under certain specific
conditions. For this purpose, there are numerous existing
licenses, including those published by Creative
Commons. Thus, if Mark Birbeck chooses to license his
vacation album for others to reuse, Shutr might use the
following XHTML snippet (currently -- January 2006 --
recommended by Creative Commons):
This document is licensed under a
<a href="http://creativecommons.org/licenses/by-nc/2.5/">
Creative Commons Non-Commercial License
</a>.
This clickable link has an intended semantic meaning: it
is the document's license. Using RDF/A can cement that
meaning within the XHTML itself:
This document is licensed under a
<a rel="cc:license"
href="http://creativecommons.org/licenses/by-nc/2.5/">
Creative Commons Non-Commercial License
</a>.
Note the use of the rel attribute to indicate a
URI property rather than a textual one. The use of this
attribute goes hand in hand with an href
attribute within the same element. This href
attribute indicates the URI object of the RDF
triple. Thus, the above RDF/A yields the following triple:
<> cc:license <http://creativecommons.org/licenses/by-nc/2.5/> .
Compared with other existing RDF mechanisms to indicate
Creative Commons licensing
-- e.g. a parallel RDF/XML file or inline RDF/XML within
XHTML comments --, the RDF/A approach provides Creative
Commons and Shutr with a significant integrity advantage:
the clickable link is is the semantic link, and
any change to the target will change both the human and
machine views. Also, a simple copy-and-paste of the XHTML
will carry through both the rendered and semantic data.
In both cases, the target URI may provide an XHTML
document which includes further RDF/A statements. The
Creative Commons license page, for example, may include
RDF/A statements about its legal details.
4 Beyond the Current Document
The above examples casually swept under the rug the issue of
the RDF subject: all the triples expressed were about the
current document representing a photo album. However, not
all RDF triples in a given XHTML2 document will be about
that document itself. In RDF/A, the default subject is the
current document, but it can easily be overriden using
the about attribute.
4.1 Qualifying Other Documents
Shutr may choose to present many photos in a given XHTML
page. In particular, at the
URI http://shutr.net/user/markb/album/12345,
all of the album's photos will appear inline. Metadata
about each photo can be included simply by specifying
an about attribute:
<ul>
<li> <img src="/https/www.w3.org/user/markb/photo/23456" />,
<span about="/user/markb/photo/23456" property="dc:title">
Sunset in Nice
</span>
</li>
<li> <img src="/https/www.w3.org/user/markb/photo/34567" />,
<span about="/user/markb/photo/34567" property="dc:title">
W3C Meeting in Mandelieu
</span>
</li>
</ul>
The above RDF/A yields the following triples:
</user/markb/photo/23456> dc:title "Sunset in Nice"^^XMLLiteral .
</user/markb/photo/34567> dc:title "W3C Meeting in Mandelieu"^^XMLLiteral .
This same approach applies to statements with URI
objects. For example, each photo in the album has a
creator and may have its own usage license.
<ul>
<li> <img src="/https/www.w3.org/user/markb/photo/23456" />,
<span about="/user/markb/photo/23456" property="dc:title">
Sunset in Nice
</span>
taken by photographer
<a about="/user/markb/photo/23456"
rel="dc:creator"
href="/https/www.w3.org/user/markb">
Mark Birbeck
</a>,
licensed under a
<a about="/user/markb/photo/23456" rel="cc:license"
href="http://creativecommons.org/licenses/by-nc/2.5/">
Creative Commons Non-Commercial License
</a>.
</li>
<li> <img src="/https/www.w3.org/user/markb/photo/34567" />
<span about="/user/markb/photo/34567" property="dc:title">
W3C Meeting in Mandelieu
</span>
taken by photographer
<a about="/user/markb/photo/34567"
rel="dc:creator"
href="/https/www.w3.org/user/stevenp">
Steven Pemberton
</a>,
licensed under a
<a about="/user/markb/photo/34567" rel="cc:license"
href="http://creativecommons.org/licenses/by/2.5/">
Creative Commons Commercial License
</a>.
</li>
</ul>
This yields the following triples:
</user/markb/photo/23456>
dc:title "Sunset in Nice"^^XMLLiteral .
</user/markb/photo/23456>
dc:creator </user/markb> .
</user/markb/photo/23456>
cc:license <http://creativecommons.org/licenses/by-nc/2.5/> .
</user/markb/photo/34567>
dc:title "W3C Meeting in Mandelieu"^^XMLLiteral .
</user/markb/photo/34567>
dc:creator </user/stevenp> .
</user/markb/photo/34567>
cc:license <http://creativecommons.org/licenses/by/2.5/> .
4.2 Inheriting about
At this point, Shutr might begin to worry about the
fast-growing size of its HTML document, given that the
photo's URI must be repeated in the about
attribute for every RDF property expressed. To address
this issue, RDF/A allows the value of this attribute to be
inherited from a parent element. In other words, if an
element carries a rel or property
attribute, but no about attribute, an RDF/A
browser will determine the subject of the RDF statement by
navigating up the parent hierarchy of that element until
it finds an about, or until it gets to the root
element, at which point the default
is about="".
Thus, the markup for the above example can be
simplified to:
<ul>
<li about="/user/markb/photo/23456">
<img src="/https/www.w3.org/user/markb/photo/23456" />
<span property="dc:title">
Sunset in Nice
</span>,
taken by photographer
<a rel="dc:creator" href="/https/www.w3.org/user/markb/">
Mark Birbeck
</a>,
licensed under a
<a rel="cc:license"
href="http://creativecommons.org/licenses/by-nc/2.5/">
Creative Commons Non-Commercial License
</a>.
</li>
<li about="/user/markb/photo/34567">
<img src="/https/www.w3.org/user/markb/photo/34567" />
<span property="dc:title">
W3C Meeting in Mandelieu
</span>,
taken by photographer
<a rel="dc:creator" href="/https/www.w3.org/user/stevenp">
Steven Pemberton
</a>
licensed under a
<a rel="cc:license"
href="http://creativecommons.org/licenses/by/2.5/">
Creative Commons Commercial License
</a>.
</li>
</ul>
which yields the same triples as the previous example,
though, in this case, one can easily see the parallel to
the corresponding N3 shorthand:
</user/markb/photo/23456> dc:title "Sunset in Nice"^^XMLLiteral ;
dc:creator </user/markb> ;
cc:license <http://creativecommons.org/licenses/by-nc/2.5/> .
</user/markb/photo/34567> dc:title "W3C Meeting in Mandelieu"^^XMLLiteral ;
dc:creator </user/stevenp> ;
cc:license <http://creativecommons.org/licenses/by/2.5/> .
4.3 Qualifying Chunks of Documents
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
belong to a single user is the more likely scenario. For
this purpose, RDF/A provides ways to make metadata
statements about chunks of documents using natural XHTML
constructs.
Consider the
page http://shutr.net/user/markb/cameras,
which, as its URI implies, lists Mark Birbeck's
cameras. Its HTML includes:
<ul>
<li id="nikon_d200"> Nikon D200, purchased on 2004-06-01.
</li>
<li id="canon_sd550"> Canon Powershot SD550, purchased on 2005-08-01.
</li>
</ul>
and the photo page will then include information about
which camera was used to take each photo:
<ul>
<li> <img src="/https/www.w3.org/user/markb/photo/23456" />
...
using the <a href="/https/www.w3.org/user/markb/cameras#nikon_d200">Nikon D200</a>,
...
</li>
...
</ul>
The RDF/A syntax for formally specifying the relationship
is exactly the same as before, as expected:
<ul>
<li about="/user/markb/photo/23456"> <img src="/https/www.w3.org/user/markb/photo/23456" />
...
using the <a rel="shutr:takenWith"
href="/https/www.w3.org/user/markb/cameras#nikon_d200">Nikon D200</a>,
...
</li>
...
</ul>
which generates the triple:
</user/markb/photo/23456> shutr:takenWith </user/markb/cameras#nikon_d200>
Then, the XHTML snippet at http://shutr.net/user/markb/cameras is:
<ul>
<li id="nikon_d200" about="#nikon_d200">
<span property="dc:title" type="xsd:string">
Nikon D200
</span>
purchased on
<span property="dc:date" type="xsd:date">
2004-06-01
</span>
</li>
<li id="canon_sd550" about="#canon_sd550">
<span property="dc:title" type="xsd:string">
Canon Powershot SD550
</span>
purchased on
<span property="dc:date" type="xsd:date">
2005-08-01
</span>
</li>
</ul>
which then yields the following triples:
<#nikon_d200> dc:title "Nikon D200"^^xsd:string ;
dc:date "2004-06-01"^^xsd:date .
<#canon_sd550> dc:title "Canon SD550"^^xsd:string ;
dc:date "2005-08-01"^^xsd:date .
One immediately wonders whether the redundancy between
the about and id attributes can be
simplified. Partly for this purpose, RDF/A includes
elements link and meta, which behave in
a special way : they only apply to their immediate parent
element, even if an ancestor element bears an
alternate about attribute.
<ul>
<li id="nikon_d200">
<meta property="dc:title" type="xsd:string">
Nikon D200
</meta>
purchased on
<meta property="dc:date" type="xsd:date">
2004-06-01
</meta>
</li>
<li id="canon_sd550">
<meta property="dc:title" type="xsd:string">
Canon Powershot SD550
</meta>
purchased on
<meta property="dc:date" type="xsd:date">
2005-08-01
</meta>
</li>
</ul>
One might now wonder how meta and link
behave when their parent element doesn't have
an id or about attribute. The result
of such syntax is an RDF bnode, an advanced topic which we
skip in this Primer.
4.4 Compact URIs (CURIEs)
For Shutr, as for many other web publishers, the
introduction of RDF/A attributes tends to increase the size
of the XHTML noticeably, sometimes unnecessarily so: there
is significant data duplication with full expression of
URIs. We have already shown how judicious use of
the about attribute can reduce the number of
times an RDF subject is expressed. We have also shown how
the use of link and meta elements can
further reduce the use of the about attribute
when attaching metadata to particular XHTML chunks.
We now address URI duplication, RDF/A's most significant
data duplication issue, with Compact URIs, known as
CURIEs. A CURIE, e.g. dc:title is
composed of a prefix, e.g. dc, followed by a
colon, followed by a suffix, e.g. title. The
compact URI is resolved by
- resolving the prefix according to normal XML
namespace resolution,
- resolving the suffix as a relative URI
against the base URI defined by the resolved prefix.
Note that QNames used for RDF properties are valid CURIEs,
and resolve in exactly the same
way. Thus dc:title and cc:license
resolve as expected when dc and cc
are correctly defined namespaces.
The differences to note between CURIEs and QNames are:
-
CURIEs allow any sequence of legal URI characters in
the suffix, including, for example, digits only, dashes,
slashes, etc...
-
CURIEs allow the empty string as a prefix,
e.g.
:next, in which case the base URI
defaults to the default XML namespace, which is usually
xhtml2 in our case.
-
CURIEs allow the underscore character
_ as
a prefix when referencing bnodes. More on this in the Advanced section.
4.4.1 Mixing CURIEs and URIs
One of the most important applications of CURIEs in RDF/A
is the use of a CURIE/URI attribute, where either a normal
URI or a CURIE can be used interchangeably. In order to
differentiate between the two types, square
brackets [] are used around a CURIE, whereas
a URI is written normally.
For example, if Shutr wants to reference the Creative
Commons
license http://creativecommons.org/licenses/by/2.5/
in an attribute that accepts both CURIEs and URIs, it can
use either:
... attr="http://creativecommons.org/licenses/by/2.5/" ...
or, assuming the namespace cclicenses has been properly defined:
... attr="[cclicenses:by/2.5/]" ...
4.4.2 Which Attributes are Which?
In RDF/A, the property
attributes property,rel,
and rev are all CURIE-only, which ensures
backwards compatibility with past uses of rel,
e.g. rel="next". The about
and href attributes, on the other hand, accept
mixed CURIE/URI datatypes. This ensures compatibility with
browsers that expect clickability for the href,
and consistency between subject and object.
4.4.3 Back to Shutr
Thus, getting back to Shutr's photo list:
<ul>
<li> <img src="/https/www.w3.org/user/markb/photo/23456" />,
Sunset in Nice,
taken by
<a href="/https/www.w3.org/user/markb">
Mark Birbeck
</a>,
licensed under a
<a href="http://creativecommons.org/licenses/by/2.5/">
Creative Commons License
</a>.
</li>
<li> <img src="/https/www.w3.org/user/markb/photo/34567" />,
W3C Meeting in Mandelieu
taken by
<a href="/https/www.w3.org/user/stevenp">
Steven Pemberton
</a>,
licensed under a
<a href="http://creativecommons.org/licenses/by-nc/2.5/">
Creative Commons Non-Commercial License
</a>.
</li>
</ul>
adding metadata to these photos with CURIEs can save
significant space (over the non-CURIE use) as soon as
there are a number of photos in the list:
<ul xmlns:cclic="http://creativecommons.org/licenses/" xmlns:photos="/user/markb/photo/">
<li about="[photos:23456]"> <img src="/https/www.w3.org/user/markb/photo/23456" />,
<span property="dc:title">
Sunset in Nice
</span>,
taken by
<a rel="dc:creator" href="/https/www.w3.org/user/markb">
Mark Birbeck
</a>,
licensed under a
<a rel="cc:license"
href="[cclic:by/2.5/]">
Creative Commons License
</a>.
</li>
<li about="[photos:34567]"> <img src="/https/www.w3.org/user/markb/photo/34567" />,
<span property="dc:title">
W3C Meeting in Mandelieu
</span>
taken by
<a rel="dc:creator" href="/https/www.w3.org/user/stevenp">
Steven Pemberton
</a>,
licensed under a
<a rel="cc:license"
href="[cclic:by-nc/2.5/]">
Creative Commons Non-Commercial License
</a>.
</li>
</ul>
Of course, this assumes a browser that can parse CURIEs
for clickable links. Initially, complete URIs may be
preferable in the href attribute.