In part I of this series, we looked at how semantic features normally confined to the head of an HTML document can be used to add semantic richness to the elements of the body. Along the way, we defined six rules of RDFa:
aelements imply that there is a relationship between the current document and some other document; the
@relattribute allows us to provide a value that will better describe that relationship.
@hrefattributes are no longer confined to the
linkelements, but can also be used on
imgto indicate a relationship between the image and some other item.
- In ordinary HTML, properties are set in the head of the document, using
meta. In HTML documents with RDFa,
@contentcan be used to set properties on any element.
- Although HTML uses the
@nameproperty to set the name of a property on
meta, it can’t be used on other elements, so RDFa provides a new attribute called
- If no
@contentattribute is present, then the value of a property will be set using the element’s inline text.
- If the
@contentattribute is present, it overrides the value in the element’s inline text to set the value of the property.
In part II, we’ll learn how to add properties to an image, and how to add metadata to any item—and we’ll add a few more rules to that list.
Adding properties to an image#section2
In part I, we discussed the fact that in ordinary HTML,
@rel is used to specify a relationship between the current document and some other document. We also noted that RDFa generalizes this function so that
@rel can be used on an
img element; the relationship expressed is between the image (in the
@src attribute) and the other document. The same principle applies when properties are placed on the
img tag: they too will apply to the image, rather than the current document.
For example, to indicate when an image was created, we might do this:
(Line wraps marked » —Ed.)
<img src="image1.png" property="dc:created" content="2009-03-22" /> <img src="image2.png" property="dc:created" content="2009-05-01" />
Ordinary HTML can only set properties that relate to the page itself, but RDFa allows properties to be set for image URLs, too.
RDFa also allows both a property and a relationship to be expressed for the same image:
<img src="image1.png" rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/" property="dc:created" content="2009-05-01" />
Adding metadata about any item#section4
Broadly speaking, we’ve made three important steps so far, as we’ve followed the evolution from basic HTML to RDFa:
- We’ve noted that any of the metadata features that can be used in the
headof the document can now be used in the
body—although we had to change the
@propertyto do so.
- We’ve seen how RDFa allows the property and relationship names to come from clearly defined vocabularies, using prefix mappings.
- We’ve learned that RDFa allows properties and relationships to be expressed about images, as well as about the current document.
If you’re not sure about any of these steps, you might want to go back and take another look before you carry on.
The ability to add properties and relationships to images is something we’ll surely want to generalize to other things. If I can indicate the license for the current document, and the license for images, why can’t I indicate the license for anything I make a reference to in my web page?
For example, let’s say I have some links to a couple of RDFa-related SlideShare presentations:
<a href="http://www.slideshare.net/fabien_ » gandon/rdfa-in-a-nutshell-v1">RDFa in a » nutshell</a> <a href="http://www.slideshare.net/mark.birbeck » /the-5-minute-guide-to-rdfain-only-6-minutes-40- » seconds">The 5-minute guide to RDFa...in only 6 minutes and 40 seconds</a>
If you look at either of these pages on SlideShare, you’ll see that the licensing information is clearly displayed. But what if we wanted to add the licensing information to the current document, so that a smart browser could do something with it? (The page might be a set of search results, for example, so we might want to show the license to the searcher, as a way to help them when choosing documents.)
We might think that we just use
@rel="license" on these anchors, as normal. But recall that this will imply that the current document has a license that is identified by the item in the
@href attribute; in this case the “other document” is a SlideShare page, not a license.
So, to make it possible to add more information about any resource we like, RDFa adds a new attribute, called
@about. It follows exactly the same pattern as the
@src attribute on
img—it can have
@property information attached to it—but it can be used on any HTML element. Here’s how we’ll use
@about to help us add licensing information about our slides. Our first link:
<a href="http://www.slideshare.net/fabien_gandon » /rdfa-in-a-nutshell-v1">RDFa in a nutshell</a>
…is licensed this way by adding the following mark-up:
<a about="http://www.slideshare.net/fabien_gandon » /rdfa-in-a-nutshell-v1" rel="license" href="http://creativecommons.org/licenses/by/2.5/"> CC BY</a>.
Note that as far as an RDFa processor is concerned, this extra markup can appear anywhere in the document—it doesn’t need to appear next to the presentation link. Of course, from the standpoint of human readability, it would usually go next to the link.
The second presentation:
<a href="http://www.slideshare.net/mark.birbeck » /the-5-minute-guide-to-rdfain-only-6-minutes-40- » seconds">The 5-minute guide to RDFa...in only 6 » minutes and 40 seconds</a>
…is licensed by adding this markup to the document:
<a about="http://www.slideshare.net/mark.birbeck » /the-5-minute-guide-to-rdfain-only-6-minutes-40- » seconds" rel="license" href="http://creativecommons.org/licenses/by-sa/2.5/"> CC BY SA</a>.
Once again, this markup could appear anywhere.
Note that the reference to each license is still a clickable link, so from a user’s perspective, nothing changes when we add
@about to an anchor. However, from a metadata perspective, each license is now being applied to an external document that contains a presentation, rather than being applied to the current document.
Of course, in a real example the clickable links would probably contain the Creative Commons icons, like this:
<a about="http://www.slideshare.net/mark.birbeck » /the-5-minute-guide-to-rdfain-only-6-minutes-40- » seconds" rel="license" href="http://creativecommons.org/licenses/by-sa/2.5/"> <img src="http://i.creativecommons.org/l/by-sa/2.5/80x15.png" /> </a>
And as you have probably realized, just as we use
@content to add properties for the document and images, we can also add them to the resources referenced by
@about. For example, if we wanted to add creator information to a presentation, we could do this:
<a about="http://www.slideshare.net/ » fabien_gandon/rdfa-in-a-nutshell-v1" rel="license" href="http://creativecommons.org/licenses/by/2.5/" property="dc:creator" content="Fabien Gandon"> <img src="http://i.creativecommons.org/l/by/2.5/80x15.png" /> </a>
So, to recap, our rule would be:
Properties and relationships can be specified for any resource, not just the current document and images, using RDFa’s
@about to set the context for many properties and relationships#section6
Setting a number of properties and relationships for the current document is easy. In ordinary HTML, we just place a number of
link elements in the
head of the document, and perhaps a few
a tags with
@rel in the
body. Now that we can add
@content in the
body, they too can be sprinkled throughout.
But what’s the equivalent technique for setting many properties when using
@about? The examples we’ve seen so far have only used one property and one relationship for each item, because that’s the limit imposed by the structure of HTML itself: each attribute on an element must have a unique name, so it’s not possible to specify multiple property values and multiple relationship values on a single element.
The answer is however, quite straightforward. In RDFa, the
@about attribute on an element actually sets the context for any RDFa that appears on any child elements. Before we illustrate this, let’s recap our last example:
<a about="http://www.slideshare.net/fabien_gandon » /rdfa-in-a-nutshell-v1" rel="license" href="http://creativecommons.org/licenses/by/2.5/" property="dc:creator" content="Fabien Gandon"> <img src="http://i.creativecommons.org/l/by/2.5/80x15.png" /> </a>
You recall that this markup is effectively saying two things. First, “The SlideShare presentation at the specified URL has the license CC BY” and second, “The SlideShare presentation at the specified URL was created by Fabien Gandon.”
To make the problem we’re trying to solve a little more tangible, imagine that we now also want to add the date that the presentation was published to our markup—with the limiting factor that we’re not allowed to add another
@property attribute to the anchor.
Now to the solution.
The easiest way to accomplish this is to begin by creating an element that contains the context in which we want all of our RDFa to operate, which in this case is the address of the presentation:
<div about="http://www.slideshare.net/fabien_gandon » /rdfa-in-a-nutshell-v1"> ... </div>
Once we have this, we can place all the properties we want to add inside it:
<div about="http://www.slideshare.net/fabien_gandon » /rdfa-in-a-nutshell-v1"> <h1>RDFa in a Nutshell</h1> <ul> <li>Author: <em property="dc:creator">Fabien Gandon</em></li> <li>Created: <em property="dc:created" content="2007-01-01"> Jan 1st, 2007</em></li> <li>License: <a rel="license" href="http://creativecommons.org » /licenses/by/2.5/"><img src="http://i.creativecommons.org » /l/by/2.5/80x15.png" /></a></li> </ul> </div>
If this layout looks familiar to you that’s good, because it’s exactly the layout we saw near the beginning, when we were adding properties about the ‘current document’:
<html xmlns:dc="http://purl.org/dc/terms/"> <head> <title>RDFa: Now everyone can have an API</title> </head> <body> <h1>RDFa: Now everyone can have an API</h1> <ul> <li>Author: <em property="dc:creator">Mark Birbeck</em></li> <li>Created: <em property="dc:created" content="2009- » 05-09">May 9th, 2009</em></li> <li>License: <a rel="license" href="http:// » creativecommons.org/licenses/by-sa/3.0/"> CCAttribution-ShareAlike</a></li> <li>Previous version: <a rel="dc:replaces" href="rdfa.0.8.html"> version 0.8</a></li> </ul> </body> </html>
The only difference between this and our new example—the RDFa for Fabien’s presentation—is that the context for all of the properties and relationships that we’ve added is defined with
@about, while in the first example, the context was simply the document itself. This gives us another rule:
@about property sets the context for all contained properties and relationships. If there is no
@about value set, then all properties and relationships will be in reference to the current document.
If any aspect of this last step is not clear to you, then I urge you to give it another read; this technique is probably the most important difference between RDFa and other methods of embedding structured data in HTML, such as Microformats and eRDF.
In the first two parts of this series, we’ve looked at the basics of RDFa, which are essentially:
- generalizing HTML’s existing metadata features so they can be used in any part of the document (
body) and on any element;
- adding a prefix-mapping mechanism which allows us to be very precise about the origin of any terms we are using; and
- adding the
@aboutattribute so that properties and relationships can be specified for any resource, not just the current document or the images it contains.
If you’d like to go beyond the basics and look at some of the more advanced aspects of RDFa, then take a look at the RDFa Handbook over at Backplane.
10 Reader Comments
It seems that RDFa is an HTML upgrade from a simple object to a language. Up until now an HTML tag would just state :”This is a link” or “This is an image”. Now, with RDFa, every object tell a whole story: “This is a link about.. that was created on..”
This will probably change search engines results dramatically. No more out dated articles or images, and much better mapping of the web.
It seems like RDFa is missing some consistency:
@href: a link betwen two documents
img@href: the license of the linked element
[@rel=license][@about]: the license of the linked element
Seems confusing. What’s wrong with img@about?
– this document was created on 1 April 2009
– this image was created on 1 April 2009
It’s hard enough getting users (e.g. content editors) to use semantic markup. Confusing and contradictory semantic markup? Forget about it. Is there a saving grace that I’m missing?
Comment preview does not accurately preview comments. My apologies for the above formatting.
First of all, great set of intro articles! Though I am confused on one example (I even tried it).
bq. Note that the reference to each license is still a clickable link, so from a user’s perspective, nothing changes when we add @about to an anchor…
Unless I am completely missing something here, it completely changes — there is no longer a link to the slide! Now the slide title links to the license… users will definitely notice that — again I might be missing something here.
That confused me, too, at first. I think the author intends the second element (the one with the link to the license) to _follow_ the first (the one with the link to the slides), not _replace_ it. Confusing, since in the other examples the RDFa-ed version replaces the original.
Still, overall a very informative and clearly written article.
@inoni and @somerain
Sorry for the delay in getting back to you, but @somerain is exactly right — the problem with the mark-up is that we have extra code that is to be inserted, but in all of my previous snippets I’m showing how the mark-up evolves.
I’ll see if that part can be rephrased a bit to make it clearer, and apologies for the confusion.
Oh, and many thanks for taking the trouble to point this out!
I understand that you can’t have multiple properties in attributes because attributes must be unique. It seems logical, therefore, to break it out into a big ol’ structure of tags, as illustrated. This makes sense in my mind as we are representing the data both to humans in the standard HTML and to machines in the RDFa additional markup.
So I guess what seems weird to me is the ability to provide extra information only to machines by using the property/content combination. Shouldn’t that information also be being represented visually? And if it’s perfectly OK to hide potentially useful information from the visual consumers of this data, why is there no neat way to do it for more than one property? (I’m presuming the only way to provide multiple properties only to machines is to include empty spans or similar tags with the information in the attributes.)
Having got my blustering confusion out of the way, thanks for these articles – I’m finding them very interesting and useful.
Firstly thanks for a pair of great articles. RDFa is entirely new to me but having read both articles carefully I think I now have a grasp of the potential power of this level of markup. It’s seems common sense to be able to apply attributes to specific elements of a page rather than to the document as a whole. The final @about example in the article brings it all together nicely showing the power and neatness of RDFa used in this way. It is clear that this will allow both for better browser use of data – I like the example of search results / lists pages where the organizing of data in this way makes perfect sense – and also potential benefit for Search Engines to enhance their results. With Google only just beginning to make use of RDFa it will be interesting to see how it’s use propagates. It will also be interesting to see how Google (and the others Search Engines) handle the inevitable attempts to abuse the power of RDFa if it becomes an important part of the ranking algorithms.
I’m all for semantic markup, but I agree with what a couple of others have posted in this discussion; how are we going to get content editors to apply semantic markup to what they write? Currently there are some great WYSIWYG editors out there that transform standard text to HTML – now we need some smart cookie to develop the next generation of editor that transforms standard text to apply RFDa markup to what people write. Otherwise I see a big chasm in the adoption of this markup.
Also, who is going to decide on which standard to use? “RFDa vs Microformats”:http://www.kelpdesign.com/tech-talk/rdfa-vs-microformats/ there are many developers already using Microformats, but I’m hoping that RFDa will become the preferred choice using XML namespaces to create a scalable form of markup. Will the development community or standards community win out?
Really clever, but come on, like most people say, how are we going to get an ordinary user to use this? How horrible is this syntax to learn? How many levels of inconsistencies and wierdness can we build on just to bow down to the XML/HTML altar?
Name or Property – Ugh!
href meaning different things depending on it’s element? – BIFF!, OW!
More horrible xmlns syntax to learn? – Arrgh!!!
Massive maintenance of the symantic ns register – No!!!
Is this where XML finally jumps the shark? How long before we have to admit that every problem cannot be fixed with the XML hammer?
Is it time to evolve?
(Throws bomb – runs!) 😉
Got something to say?
We have turned off comments, but you can see what folks had to say before we did so.
More from ALA
Personalization Pyramid: A Framework for Designing with User Data
Mobile-First CSS: Is It Time for a Rethink?
Designers, (Re)define Success First
Breaking Out of the Box
How to Sell UX Research with Two Simple Questions