RDFa is a method of embedding rich metadata in any XML document, by making use of a small number of attributes. This section is an introduction to why we need RDFa.
RDFa is a new technique for embedding metadata into any XML document by using a small number of attributes. Its primary use is in XHTML documents, and allows metadata to be added in such a way that an ordinary home page can provide metadata such that it can serve as a FoaF file, an RSS feed, even a list of items for sale.
This paper aims to provide an introduction to RDFA, and will show how it can make the publication of metadata as easy as publishing any other type of information.
Although most people have heard of RDF, it is often associated with its rather obtuse language--RDF/XML. RDF is nothing more than a very general way of describing data, but as with many things that are very general, this gives it both power and the potential to confuse.
The basic idea of RDF is to reduce all collections of data to 'nuggets' of information called triples. A triple is nothing more than 'some item' having a property of 'some value'. It might be:
Mark has an address of London, UK
or:
XTech 2006 has a venue of Amsterdam
By breaking things down to such fundamental building blocks, RDF can be useful for anything from knowledge management to database definitions, to marking up metadata about web pages.
RDF has evolved over the years, and a number of incredibly powerful layers have been built upon it. For example, reasoning software can make use of RDF statements to work out other statements. To illustrate, it may be the case that some system knows the following facts:
XTech 2006 has a venue of Amsterdam XTech 2006 has a start date of May 16th XTech 2006 has an end date of May 19th
If the system also discovers that:
XTech has a speaker of Mark
then it could deduce that on May 18th:
Mark has a location of Amsterdam
The major problem that people have been trying to tackle is that although RDF itself is fairly simple, the language that is usually used to express it is not. RDF is usually 'carried' via RDF/XML which is renowned for its difficulty.
The reason this is such an important issue is that a great deal of the web's metadata resides in HTML pages sitting on web-sites. Company addresses, the weather in Tokyo, the price of a second-hand car...every day millions of pieces of metadata are placed onto the internet which are not usable in software since they are not formatted in any standardised way. Without some kind of mechanism for extracting this information the dream of the Semantic Web will remain just that--a dream.
What's needed is not to throw away RDF, but to find an easier way of encoding it that allows the output of HTML authors to be placed at the centre of the Semantic Web.
The growth of interest in so-called microformats shows the there is a real need for, and interest in, such a solution. The technique used is to agree that certain patterns of HTML usage can be 'codified' to represent some agreed upon metadata. For example, the following HTML mark-up:
<div class="vcard">
<a class="url fn" href="http://tantek.com/">
Tantek Çelik
</a>
<div class="org">Technorati</div>
</div>
leverages the use of CSS classes to reuse pieces of the mark-up as metadata, and so represent a vCard. This approach is the same as that used by GRDDL, which uses XSLT to take an XHTML document and extract from it pieces of metadata.
But the problem with both solutions is that they don't scale, and so don't allow the mark-up data to become part of the Semantic Web. In both cases they require already existing metadata formats (vCard, iCalendar, and so on) to have a 'partner' or 'mirror' definition created--usually called the same name but with an 'h' in front--which guides document production.
Despite these problems, the goal of initiatives like microformats is important, since it sets out the possibility of carrying metadata in an ordinary HTML document. But ultimately, without addressing the problem of scale, we are not much closer to our goal of building a Semantic Web that parallels the visible web we've used for years.
The approach taken by RDFa is that ultimately any RDF structure should be representable. This means that instead of having to 'codify' each format to describe how it must be marked up, we simply provide a set of rules that explain how anyRDF can be marked up, and than anyRDF 'language' can be used.
This means that a library, for example, can still make use of the complex taxonomies and schemas that it relies on, whilst a web author can mark-up their home page using something like Friend-of-a-Friend (FoaF).
Jane 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.
Jane'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>Jane Doe's Home Page</title>
</head>
<body>
<p>
Hello. This is Jane Doe's home page.
<h2>Work</h2>
If you want to contact me at work, you can
either <a href="mailto:jane.doe@example.org">email
me</a>, or call +1 777 888 9999.
</p>
</body>
</html>
Jane can now pass on the address of her home-page to her friends, which is http://jo-lambda.example.org/.
One of Jane's friends, John, tells Jane that the address book software he uses can be automatically kept up-to-date with Jane's details. All Jane 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 she is going to use is called 'Friend-of-a-friend', or FoaF.
The first thing that Jane needs to do is to add an identifier to the top of her home-page that will make the FoaF vocabulary available:
<html xmlns:foaf="http://xmlns.com/foaf/0.1/">
Jane 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 special names within FoaF. She therefore adds those names to her document, using the following approach:
href attribute of an a element, then the rel attribute can be added to the element, and its value is set to contain the name of the property she wants to add;property.Let's look at each of those rules.
Jane has provided a link in her home-page to her email address, which is jane.doe@example.org:
.
.
.
If you want to contact me at work, you can
either <a href="mailto:jane.doe@example.org">email
.
.
.
However, to ensure that John's address book software understands this, Jane can use the FoaF mailbox property:
.
.
.
If you want to contact me at work, you can
either <a rel="foaf:mbox" href="mailto:jane.doe@example.org">email
.
.
.
Note that using QNames to describe the property means it is clear and unambiguous--no matter where this appears, in whatever document, it will mean the FoaF mbox property.
In addition to her email address, Jane 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>Jane Doe</span>'s home page.
<h2>Work</h2>
If you want to contact me at work, you can either
<a
rel="foaf:mbox"
href="mailto:jane.doe@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 RDFa
attribute property:
<p>
Hello. This is
<span property="foaf:name">Jane Doe</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>
The completed document looks like this:
<html>
<head>
<title>Jane Doe's Home Page</title>
</head>
<body>
<p>
Hello. This is
<span property="foaf:name">Jane Doe</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 John needs to do is to provide the internet address for Jane's home-page to his contact software, and it will be able to extract the following information about Jane:
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 Jane added to her XHTML defines a set of RDF triples. Each triple effectively represents one property of her data.
The final mark-up shows how Jane's document can double as both an ordinary home-page and a collection of FoaF data. This has a twofold advantage:
We'll begin by looking at the current state of play as far as metadata in XHTML documents is concerned. A typical example of what people already do is this (we'll pretend that everyone uses XHTML):
<head>
<meta name="author" content="Mark Birbeck" />
</head>
Nothing wrong with that you'll say, and if this snippet of mark-up is in a web page at my blog's address (http://internet-apps.blogspot.com), then we have in effect 'created' the following triples:
<http://internet-apps.blogspot.com> _:author "Mark Birbeck" .
(If you're not familiar with this N3 syntax don't worry, we won't use a lot in this discussion--it just means that some resource has a property called 'author', and the value of that property is "Mark Birbeck". You can think of it as the same as a name/value pair, like those you use to send data to a server, i.e., author="Mark Birbeck".)
So far so good; we've made a statement about my blog, and we could easily have added other information, such as when it was written, when it was last updated, and so on.
The problem comes next though; what if we now want to add that I am currently on holiday in the south of France (if only...)? There are many systems that are making use of 'geo tagging' and there are a number of recommended ways to do this, but they all boil down to doing something like this in the head of your document:
<head>
<meta name="author" content="Mark Birbeck" />
<meta name="geo.position" content="43.95;4.833333" />
</head>
It might appear obvious, but we should ask what exactly this means, since we may be surprised by the answer.
The convention is that it means that 'Mark Birbeck' is currently located in Avignon, France. The technique is not actually limited to people though, and it could also give us the location for a company, a conference, a meeting, and so on.
But there's a problem--in 'proper' RDF terms putting this metadata in the head of a document means that the document itself is in the South of France!
Of course you could just say that this once again confirms what you already knew--that RDF is irrelevant and of no use to man or beast, but bear with me for a moment.
The fact that you and I 'know' that this mark-up means that 'Mark Birbeck' is located at a certain geographic location is a kind of 'implicit knowledge' that we have overlaid onto the scant information we've been given. But what if the web page we were dealing with didn't concern a person, but a company? Could we assume that it now means that the company is at the specified location? Perhaps. So what if the page also contained product information? How do we know whether the location information is to apply to the company or the product that is on the page?
In other words, having some kind of accepted behaviour for metadata, or relying on some kind of implicit (or 'domain') knowledge, only gets us so far...which is not very far at all.
Don't get me wrong, this information is still pretty useful when presented to humans, since they can usually 'fill in the gaps'. For example, if we had a web browser extension that showed a map with a little red cross on it whenever the page we were viewing contained location information, that would still be pretty handy; when we were looking at someone's home page we'd assume that the map showed us where the person lived (although it might be where they are now), and if we were looking at a museum web site we'd assume that the cross showed where the museum was located (although if it's a museum of items from another country it could be the location of the country).
And if we were looking at the 'ambiguous' example I gave above (of a company page that also contained a product description), we might still be able to make use of the location information given to us by our browser extension, and deduce from reading the web-page text that the map was showing us the company's location, or the product's, or neither.
In short, we can go a long way with this kind of 'flat' information structure, adding pretty much any 'tags' we like and relying on our 'implicit' knowledge to match up the meanings correctly. But we'd just have to be aware that outside of the world of this document, the metadata we have is pretty useless unless a system also knows these implicit meanings.
As it happens, relying on implicit knowledge is exactly what goes on in many situations; processors and systems get round the skewed nature of this embedded metadata by having some implicit knowledge about what they are processing.
For example, if I submitted my home page to a web-site that allows people to search for bloggers in different locations, then the web-site could pretty much assume that it was dealing with a person's location. It could therefore impute the following from my metadata:
@prefix dc: <http://purl.org/dc/elements/1.1/> .
<http://internet-apps.blogspot.com> dc:creator
[
foaf:name "Mark Birbeck";
geo:lat "43.95";
geo:long "4.833333"
] .
I've used N3 again to represent the meaning--and properties from existing vocabularies, as available--but in plain language what we have is this:
But just to be very clear, there is nothing in our original mark-up that says that the set of statements I just derived is a legitimate interpretation:
<head>
<meta name="author" content="Mark Birbeck" />
<meta name="geo.position" content="43.95;4.833333" />
</head>
It is only because the web-site instructed me to mark-up my documents in exactly this way so as to convey my current location that it works; I could have created a web-page for a house, and put in location data in exactly the same format before submitting it to a completely different web-site concerning real estate, and that site would have decided to use my information to represent a house for sale, rather than my current location.
In short, if we received this mark-up out of context then all we could say with any certainty is that something has a location of 43.95, 4.833333--our browser extension can show you where in the world that is, but what else you make of this information is entirely up to you!
(Some people will argue that you always have metadata in a context, so this is not a problem. This is in some ways true, but the problem with solutions like microformats is that you need to create all possible contexts in advance of them occurring...which just does not scale for a decentralised, organic, semantic web.)
What we need therefore is a generic solution to putting metadata into our documents, so that a processor can decipher it without having to know in advance that author and geo.position, for example, apply to different things.
For a number of years the general approach has been that metadata and documents just don't mix--you use RDF/XML for complicated metadata, and you put the actual content in your XHTML documents. But as we've seen with examples like location information, people want to put information about themselves, their companies, and their conferences, right into their documents, avoiding the need to publish separate documents. If we're to allow this, but at the same time avoid relying on the implicit knowledge that we discussed, then a key requirement will be to prise apart when we're talking about 'the document' and when we're talking about some other 'thing'.
The first part of what is needed is to bring some order to URI-space and ensure that if a URI is used to represent a document then it isn't used to represent some other 'thing' like a conference or a car, and likewise, if a URI is used to represent a conference or a car, it is never used to represent a document. The second half of the equation is to use a syntax that is richer than the simple meta element embedding provided by HTML (that we have seen in our previous examples).
The solution to the first problem is the notion of information resources, and to the second is RDFa. Let's look at these two points in turn.
A key concept to understand in this discussion is the notion of an information resource...but first let's get to grips with resources.
A resource is pretty much anything that we want to talk about; you, me, XTech 2006, John Lennon, the 322 bus route, the city of Paris, meeting room 2 (and its projector), a Zanussi washing-machine, and so on. These things are anything that we may usefully make statements about, and in turn share those statements with each other.
An information resource is a very specific subset of this enormous list of things, and it is those things that you interact with on the web. Why do we need to pull these resources out and make them special, as opposed to, say, car resources or planet resources? The answer actually goes to the heart of the discussion we have just had in the earlier sections.
Let's assume that we all want to share data about the XTech 2006 conference; we might want to say "get this flight to XTech 2006", or "tickets for XTech 2006 cost this much", or "Steven Pemberton is giving a tutorial on XForms and XHTML 2 at XTech 2006". RDF and the idea of URIs gives us a mechanism for identifying the resource 'XTech 2006' (go on, get with the programme...call it a resource...you won't regret it!) in such a way that we can all know that we're talking about the same thing; that mechanism is for us all to agree on a URI that represents this conference and nothing else.
Once we have agreed on this URI, then the information you have carefully put together about hotels that are close to the conference venue, could be mixed with my data about flights from London, and someone else's data about the topics that will be discussed, to build a package of useful data.
So how do we choose this all-important URI? It's probably best to let the conference organisers decide and then leverage the DNS architecture--they could choose a URI in a domain that they own and control. If they do this, then they would most likely decide to use the conference home page:
<http://xtech06.usefulinc.com/>
That's all well and good, but let's work through what happens when the conference organisers add metadata to this web-page.
Let's say they add something simple like a modification date; the problem now is that we're right back squarely into our 'implied knowledge' problem from the first section, since we now need to know whether the modification date applies to the conference agenda or just to the document page that has been modified.
A similar problem arises if we want to have a unique URI to identify the conference sessions so that we can make statements about them--perhaps we want to suggest sessions to avoid, or we want to give them stars afterwards to indicate how good they were. My session on RDFa is identified by this URI:
<http://xtech06.usefulinc.com/schedule/detail/58>
but if you opened the document from that URL and found that there was a dc:creator tag, what exactly would it indicate? Would it tell you the name of the page author, or me, the session author? Tricky...
TAG
The W3C's tag group got round this problem by saying that the URI that identifies my session in RDF-space must not be the URI I just quoted, since that is a web-page. Trying to use it to represent both resources (the session and the web-page) causes lots of problems because you only have one URI, and with one URI you can only unambiguously talk about one thing. To put it another way, the session and the web page describing the session, are distinct--there are two resources, not one.
It's important to be clear on the implications of this. No-one is saying that the URI for the session can't be within the address-space of the web-site, so it's fine for my session to be identified as something like this:
<http://xtech06.usefulinc.com/data/session/58>
The crucial thing about making this separation is that if we now talk about this resource (by using this URI) and make statements like who created it, where it is located, when it was last modifed, how long it is, what its subject matter is, and so on, we know without any doubt that we are talking about the session, and not the page about the session (that is still located at http://xtech06.usefulinc.com/schedule/detail/58.)
We're inching towards a solution, but now we have two further problems; how do we get distinct URIs for our two resources, and how do we put metadata in our document so that it's clear when we're talking about the session and when we're talking about the web-page.
We're now ready to look at how RDFa solves this problem. First we'll look at a simple way that RDFa can be used to unambiguously mark-up our metadata, before looking at using nested statements to make the mark-up more compact, and inline metadata to allow the document's content to be reused.
Let's return to our simple example from an earlier section:
<head>
<meta name="author" content="Mark Birbeck" />
<meta name="geo.position" content="43.95;4.833333" />
</head>
Recall that we said that with 'implicit knowledge' we could interpret this as the following set of triples:
<http://internet-apps.blogspot.com> dc:creator
[
foaf:name "Mark Birbeck";
geo:lat "43.95";
geo:long "4.833333"
] .
(Remember that I mapped the properties to existing vocabularies that seemed appropriate.)
Our next step is to look at how we can mark this up unambiguously; i.e., in such a way that we can dispense with the 'implicit' knowledge.
The RDFa mark-up for this actually mirrors the N3 quite closely (assuming that this is in a document stored at http://internet-apps.blogspot.com):
<head>
<link rel="dc:creator" href="#about" />
<meta about="#author" property="foaf:name" content="Mark Birbeck" />
<meta about="#author" property="geo:lat" content="43.95" />
<meta about="#author" property="geo:long" content="4.833333" />
</head>
This is a generic solution because statements in the head section that follow the layout of the first statement, i.e.:
<meta property="p" content="o" />
are always statements about the document itself, whilst statements with an about attribute, i.e., this pattern:
<meta about="s" property="p" content="o" />
always relate to the item designated by the URI in the about attribute.
Our mark-up has two sets of statements; the first concerns the document itself and is a reference to the 'thing' that created it:
<link rel="dc:creator" href="#about" />
The second lot of statements describe this 'thing' that created the document, and tell us its name and where it is:
<meta about="#author" property="foaf:name" content="Mark Birbeck" /> <meta about="#author" property="geo:lat" content="43.95" /> <meta about="#author" property="geo:long" content="4.833333" />
This separation of the two lots of statements means that even when we don't know anything about what the data 'means' we can still tell which of our resource pairs its about; we can tell if it's about the web-page or the web-page's author, the web-page or the conference, the web-page or the conference session, the web-page or the car, the web-page or the planet, the web-page or the Zanussi washing-machine, and so on.
In RDFa meta elements can be nested. The normal purpose of this is to make statements about the statement that contains them, such as indicating that the category 'fishing' was added by Jane or that the 4 star rating was given by John:
<head>
<meta property="category" content="fishing">
<meta property="dc:creator" content="Jane Doe" />
</meta>
<meta property="rating" content="4">
<meta property="dc:creator" content="John Doe" />
</meta>
</head>
But another use of nested statements is to make a lot of statements about the same resource, and this is achieved by adding an about attribute to the top-level statement. Our mark-up could now look like this:
<head>
<link rel="dc:creator" href="#about" />
<meta about="#author">
<meta property="foaf:name" content="Mark Birbeck" />
<meta property="geo:lat" content="43.95" />
<meta property="geo:long" content="4.833333" />
</meta>
</head>
In this small example there's not a lot to choose between this and the first syntax where the about attribute was repeated on each statement. But in a larger example the nested approach is probably easier to manage, as we can see here, where information about the author has been extended to include much of what might be in a person's FoaF file:
<html
xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
>
<head>
<link rel="dc:creator" href="#about" />
<meta about="#author">
<link rel="rdf:type" href="[foaf:Person]" />
<meta property="foaf:name" content="Mark Birbeck" />
<meta property="foaf:givenname" content="Mark" />
<meta property="foaf:family_name" content="Birbeck" />
<meta property="foaf:mbox_sha1sum"
content="b8b2922a0d39cd7c7db0b4f65124b4dd2a79fa24" />
<link rel="foaf:homepage" href="" />
<link rel="foaf:workplaceHomepage" href="http://www.formsPlayer.com/" />
<meta property="geo:long" content="4.833333" />
<meta property="geo:lat" content="43.95" />
</meta>
</head>
.
.
.
</html>
Software development is built on 're-use', but writing web-pages is one place that we've generally not had the benefit of re-use mechanisms. However, RDFa allows all of the metadata that we just saw in the FoaF example to be obtained from features that would normally be found in a web-page anyway.
For example, if my blog already has a link to my work web-site:
<body>
I am currently working on an XForms processor called
<a href="http://www.formsPlayer.com/">formsPlayer</a>.
</body>
I could re-use this information and so replace the mark-up for foaf:workplaceHomepage in the head of the document with this:
<body about="#author">
I am currently working on an XForms processor called
<a rel="foaf:workplaceHomepage"
href="http://www.formsPlayer.com/">formsPlayer</a>.
</body>
A full example that uses all of these techniques might look like this:
<html
xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
>
<head>
<link rel="dc:creator" href="#about" />
<meta about="#author">
<link rel="rdf:type" href="[foaf:Person]" />
<meta property="foaf:givenname" content="Mark" />
<meta property="foaf:family_name" content="Birbeck" />
<meta property="foaf:mbox_sha1sum"
content="b8b2922a0d39cd7c7db0b4f65124b4dd2a79fa24" />
<link rel="foaf:homepage" href="" />
<meta property="geo:long" content="4.833333" />
<meta property="geo:lat" content="43.95" />
</meta>
</head>
<body about="#author">
Hi, my name is Mark Birbeck,
and I am currently working on an XForms processor called
<a rel="foaf:workplaceHomepage"
href="http://www.formsPlayer.com/">formsPlayer</a>.
Don't bother emailing me though, because I'm on holiday
in Avignon. (I wish...)
</body>
</html>
RDFa provides an efficient, compact mechanism by which to add metadata to an XHTML document. This metadata can be as simple as a few statements, but ranges up to the full power of RDF. In addition to providing this expressive power, RDFa provides a simple way to refer to 'resources' from within a web-page--i.e., an 'information resource'.