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:

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:

An RDF/A-aware browser would thus extract the following RDF triples:

(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":

Then the RDF/A might look like this:

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:

A precise way to augment this HTML with RDF/A is:

which would yield the following triples (note how the default datatype is XMLLiteral, which explains the first example above.):

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:

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.

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:

Using the rel attribute, one can easily update this HTML to include an RDF/A statement:

This would then yield the expected triple:

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 clickable link has an intended semantic meaning: it is the document's license. Using RDF/A can cement that meaning within the XHTML itself:

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:

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.

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:

, Sunset in Nice

, W3C Meeting in Mandelieu

]]>

The above RDF/A yields the following triples:

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.

, Sunset in Nice taken by photographer Mark Birbeck , licensed under a Creative Commons Non-Commercial License .

W3C Meeting in Mandelieu taken by photographer Steven Pemberton , licensed under a Creative Commons Commercial License .

]]>

This yields the following triples:

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:

Sunset in Nice , taken by photographer Mark Birbeck , licensed under a Creative Commons Non-Commercial License .

W3C Meeting in Mandelieu , taken by photographer Steven Pemberton licensed under a Creative Commons Commercial License .

]]>

which yields the same triples as the previous example, though, in this case, one can easily see the parallel to the corresponding N3 shorthand:

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:

and the photo page will then include information about which camera was used to take each photo:

... using the Nikon D200, ...

... ]]>

The RDF/A syntax for formally specifying the relationship is exactly the same as before, as expected:

... using the Nikon D200, ...

... ]]>

which generates the triple:

Then, the XHTML snippet at http://shutr.net/user/markb/cameras is:

which then yields the following triples:

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.

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.

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.

Back to Shutr

Thus, getting back to Shutr's photo list:

, Sunset in Nice, taken by Mark Birbeck , licensed under a Creative Commons License .

, W3C Meeting in Mandelieu taken by Steven Pemberton , licensed under a Creative Commons Non-Commercial License .

]]>

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:

, Sunset in Nice , taken by Mark Birbeck , licensed under a Creative Commons License .

, W3C Meeting in Mandelieu taken by Steven Pemberton , licensed under a Creative Commons Non-Commercial License .

]]>

Of course, this assumes a browser that can parse CURIEs for clickable links. Initially, complete URIs may be preferable in the href attribute.