XHTML and RDF

1 Motivation

We have two standards running parallel with each other; HTML is the de facto standard for document markup, accounting for millions of items on the web. RDF is a standard for expressing metadata, which in turn provides a foundation for making use of that metadata, such as reasoning about it. Yet the former is very rarely the subject of the latter; meta information placed in the HTML family of documents is often encoded in such a way as to make it difficult to extract by RDF-related parsers. And if it cannot be extracted, then it cannot be used.

Our intention here is to make more of the information that is contained within HTML-family documents available to RDF tools, but without putting an unnecessary burden on authors familiar with HTML, but not with the subtleties of triples and statements. However, for our discussions on how best to do this, we do need to be familiar with at least the principles of RDF.

RDF is about statements and triples. There are a number of syntaxes which can be used to express these triples, such as N3 and RDF/XML. This document proposes ensuring that the metadata elements already proposed in XHTML 2.0 can be used to glean useful RDF-based information.

2 Types of Metadata in XHTML Documents

There are a number of sets of useful meta information that may be contained in, or relate to, an XHTML document:

There may be information about the document itself; who wrote it and when, the document's subject matter, and so on.
There may be further information about some of this document metadata; not only might we indicate the name of the author, but we might also mark-up metadata to indicate their contact information.
There may be information about words used in the text; an abbreviation may be marked-up with the full text version, or the word "yesterday" may be tagged as being a date with a value of "2004-01-01".
And finally, there may be information about items completely unrelated to the document; there may be meta information about a company or country.

To introduce the issues we'll go through some examples of each of these, using the RDF notion of triples.

3 Document Metadata

3.1 Top-level Metadata with `meta` and QNames

Our first scenario involves statements made about the document. This is to some extent already catered for with the current use of meta and link. Statements can be made about the document, such as its publication date, author, revision number, subjects, and so on.

An example of using meta is provided in the latest XHTML 2.0 draft:

<html ... profile="http://www.acme.com/profiles/core">
        <head>
                <title>How to complete Memorandum cover sheets</title>
                <meta name="author">John Doe</meta>
                <meta name="copyright">&copy; 1997 Acme Corp.</meta>
                <meta name="keywords">corporate,guidelines,cataloging</meta>
                <meta name="date">1994-11-06T08:49:37+00:00</meta>
        </head>
        ...

Whilst this provides useful metadata about the document, the lack of qualification of the value in the name attribute means that in terms of RDF statements, it is weak. The technique usually used in previous versions of HTML is to provide a prefix on the property name, or to use the scheme attribute. Adopting this same technique in XHTML 2.0, our markup would now look like this:

<meta name="DC.identifier">http://www.rfc-editor.org/rfc/rfc3236.txt</meta>

From an RDF standpoint this doesn't help. The statement that the author intends - expressed as RDF triples - would be:

<> <http://purl.org/dc/elements/1.1/identifier> <http://www.rfc-editor.org/rfc/rfc3236.txt> .

Editorial note
All RDF statements are represented in this document using N3, since it is more compact than RDF/XML. Most of the notation I will use is covered in [N3-PRIMER].

An easy way to resolve this would be to allow the author to use QNames inside name:

<html xmlns:dc="http://purl.org/dc/elements/1.1/">
        <head>
                <title>How to complete Memorandum cover sheets</title>
                <meta name="dc:creator">John Doe</meta>
                <meta name="dc:rights">&copy; 1997 Acme Corp.</meta>
                <meta name="dc:subject">corporate,guidelines,cataloging</meta>
                <meta name="dc:date">1994-11-06T08:49:37+00:00</meta>
        </head>
        ...

However, for reasons that will become clearer later, I would suggest that we drop the use of name and call it property:

<html xmlns:dc="http://purl.org/dc/elements/1.1/">
        <head>
                <title>How to complete Memorandum cover sheets</title>
                <meta property="dc:creator">John Doe</meta>
                <meta property="dc:rights">&copy; 1997 Acme Corp.</meta>
                <meta property="dc:subject">corporate,guidelines,cataloging</meta>
                <meta property="dc:date">1994-11-06T08:49:37+00:00</meta>
        </head>
        ...

This would create the following statements:

@prefix dc:  <http://purl.org/dc/elements/1.1/> .
<> dc:creator "John Doe" ;
   dc:rights "&copy; 1997 Acme Corp." ;
   dc:subject "corporate,guidelines,cataloging" ;
   dc:date "1994-11-06T08:49:37+00:00" .

Editorial note
This would mean that in the previous example, non-prefixed names would be regarded as being properties from the source document - for example `<> :author "John Doe" .` - which I would suggest is correct. The consequence is that no matter how consistently a name is applied across a web site, it never conveys anything other than a 'local' concept.

3.2 Statements About Top-level Metadata

Our second scenario concerns statements made about the metadata that we have just created to describe the document. We might want to add further information about the author or publisher, for example.

The simplest way to do this would be to place the additional statements in an external RDF/XML document, and make reference to them. For example, the external reference could, under the current spec, be expressed like this:

<link rel="meta" href="JohnDoe.rdf" />

and the metadata in the document being linked to, might look like this:

<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:con="http://www.w3.org/2000/10/swap/pim/contact#"
>
        <con:Person rdf:about="http://www.example.org/People/JohnDoe">
                <con:fullName>John Doe</con:fullName>
                <con:mailbox rdf:resource="mailto:JohnDoe@example.org"/>
        </con:Person>
</rdf:RDF>

Whilst this makes the metadata available to an RDF/XML parser, this does imply that if this information were to be usable within the XHTML 2.0 browser, then it would need to incorporate an RDF/XML parser. Whilst this is certainly a desirable goal in the long term, it is probably an impractical requirement in the short. Anyway, there are other ways of structuring the data that may give the XHTML 2.0 browser access to the meta information, without requiring it to incorporate an RDF/XML parser.

Unlike previous HTML mark-up, XHTML 2.0 allows meta to be nested. The effect of this in RDF terms, is to create an anonymous resource inside the containing meta element, and then for nested meta elements to be further statements about this anonymous resource. This technique would therefore allow the previous information about our document's author to be used by the browser, or indeed the author, without requiring a full-fledged RDF parser. The structure might look something like this (some statements from the external document are not reflected):

<html xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:con="http://www.w3.org/2000/10/swap/pim/contact#">
        <head>
                <title>How to complete Memorandum cover sheets</title>
                <meta property="dc:creator">
                        <meta property="con:fullName">John Doe</meta>
                </meta>
                <meta property="dc:rights">&copy; 1997 Acme Corp.</meta>
                <meta property="dc:subject">corporate,guidelines,cataloging</meta>
                <meta property="dc:date">1994-11-06T08:49:37+00:00</meta>
        </head>
        ...

This would be read in prose as "the document's author is called 'John Doe'", and in terms of statements that "this document has a dc:creator property, which is an anonymous object, which in turn has a con:fullName property, which is 'John Doe'". Note that the implication here is that any non-contained meta element is referring to "this document". In N3 notation it would be:

<> dc:creator [ con:fullName "John Doe" ] .

3.3 Statements About Other Resources

Sometimes we need to be able to make statements about resources outside of our document. For example, we may know that the resource identified by http://people.com/TonyBlair has a con:fullName of "Tony Blair". Currently the only choices we have are either to embed RDF/XML inside our XHTML document, or to link to an external RDF file, in the manner that we saw above.

Since neither of these approches is suitable, I would suggest that we add a new attribute aboutthat can appear on the meta element. Our new markup might look like this:

<html ...>
        <head>
                <title>How to complete Memorandum cover sheets</title>
                <meta property="dc:creator">
                        <meta property="con:fullName">John Doe</meta>
                </meta>
                <meta about="p:TonyBlair" property="con:fullName">Tony Blair</meta>
        </head>
        ...

This time our triples contain one statement about our document (and a statement about that statement), followed by one about some external resource over which we have no control:

<> dc:creator [ con:fullName "John Doe" ] .
p:TonyBlair con:fullName "Tony Blair" .

Another consequence of adding about is that we can now make statments about other parts of our document. For example, if we know that one part of the document is actually attributable to someone else, we could use the following markup:

<html ...>
        <head>
                <title>Some quotes</title>
                <meta about="#q1">
                        <meta property="dc:source">http://www.example.com/tolkien/twotowers.html</meta>
                </meta>
        </head>
        <body>
                <blockquote id="q1">
                        <p>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.</p>
                </blockquote>
        </body>
</html>

Editorial note
This is a reworking of the example at 8.3. Note, however that we favour the Dublin Core's `source` element over the proposed XHTML 2.0 `cite` element, which was used in the original example.

The triple represented is as follows:

<#q1> dc:source "http://www.example.com/tolkien/twotowers.html" .

3.4 String Literals and URIs

Although allowing QNames in property and about on meta gets us a little closer to usable RDF statements, there is still another problem; RDF allows statements to be made about two types of objects - resources and string literals - but the syntax that we have built up so far, only allows the object of a statement to be a string literal. The consequence is that this:

<meta property="dc:identifier">http://www.rfc-editor.org/rfc/rfc3236.txt</meta>

produces the following triples:

<> dc:identifier "http://www.rfc-editor.org/rfc/rfc3236.txt" .

As you can see, the object of the statement is a string literal, even though we wanted it to be a resource. The statement we really wanted to make, was this:

<> dc:identifier <http://www.rfc-editor.org/rfc/rfc3236.txt> .

Since XHTML 2.0 brings link with it from HTML to express relationships between the source document and some other document, then I would suggest that we simply allow QNames in the rel attribute on link. Our Dublin Core identifier example would then be expressed as follows:

<link rel="dc:identifier" href="http://www.rfc-editor.org/rfc/rfc3236.txt" />

Editorial note
To make this consistent, the values in `rel`[XHTML-2.0-LINKTYPES] would all need to be namespace prefixed, for example `xhtml2:next` or `xhtml2:stylesheet`. This is no bad thing.

In addition we would allow link to appear anywhere that meta can, since we are saying that the only difference between them is that one identifies a property of the document and assigns it a string literal value, whilst the other identifies a property of the document and assigns it a resource as the value. Our previous example (in which we indicated the source of a quote), would then become this:

<meta about="#q1">
        <link rel="dc:source" href="http://www.example.com/tolkien/twotowers.html" />
</meta>

Note that wheras before the triples produced were these:

<#q1> dc:source "http://www.example.com/tolkien/twotowers.html" .

now we correctly have these:

<#q1> dc:source <http://www.example.com/tolkien/twotowers.html> .

There is no reason why a number of the attributes for meta and link cannot appear on the same element. Our example could therefore be abbreviated to:

<link about="#q1" rel="dc:source" href="http://www.example.com/tolkien/twotowers.html" />

4 Markup Metadata

The next category of metadata concerns the qualification of text that appears in a document. This whole area is often discussed on the HTML mailing lists, and is the source of much confusiion. Almost every other day someone proposes new markup to capture the notion of weight, time, addresses, and so on. It's therefore worth looking at what the various proposals are trying to capture.

If we were simply concerned with how a document appeared then we would not need new markup. For example, if we have a corporate website, and on the 'contact us' page the address of the company headquarters is displayed, then the following would be sufficient:

<p class="address">
   <span class="street">4 Pear Treet Court</span>
   <span class="city">London</span>
   <span class="country">United Kingdom</span>
</p>

We could then add a stylesheet, and have the city shown in bold, red, loud, or whatever.

However, an automated process that was analysing this 'address' would be unlikely to derive any 'meaning' from this markup. To 'make sense' of this information, an indexing engine, content management system, e-commerce server, or whatever, would need to know in advance what 'street' and 'city' meant.

Of course, we could achieve this if we all agreed to reserve those words in the class attribute to mean only 'parts of an address', but that would then break with people who want to use 'city' as a style class, with no relation to its semantic meaning. It would also break for people who want to use 'address' for an IP address. In other words, we would be imposing a meaning onto those that don't want it. Far better then to try to create 'unique' versions of these identifiers.

What is usually proposed is to create some elements that capture the notions of addresses. The author's presentational requirements are not compromised since they are still able to style the new markup, and of course the elements capture the semantics:

<style>
   city { background-color: teal; }
</style>
<address>
   <street>4 Pear Treet Court</street>
   <city>London</city>
   <country>United Kingdom</country>
</address>

Whilst the general approach is fine - the use of elements to clearly mark metadata - the fact that those elements exist in the XHTML namespace causes a number of problems. The main one is that it is not clear where we should draw the line when adding new elements to XHTML; as mentioned earlier, on the www-html list debates frequently run about whether date/time/quantity/happiness elements should be added to XHTML. All of them have worthy arguments for their inclusion, but the bigger issue is whether we should even bother (since where do we stop), and should we instead focus on providing mechanisms by which elements from other namespaces can be used?

The second problem with these elements appearing in the XHTML namespace concerns their actual 'meaning'. Since all of these elements exist in the XHTML 2.0 namespace, then to some metadata processor, what we actually have is an 'XHTML date' (or an 'XHTML address', or person, or whatever).

One solution to this might appear to be to use the techniques we described above - meta and link:

<html xmlns:con="http://www.w3.org/2000/10/swap/pim/contact#">
<head>
    <meta property="con:address">
        <meta property="con:street">4 Pear Treet Court</meta>
        <meta property="con:city">London</meta>
        <meta property="con:country">United Kingdom</meta>
    </meta>
</head>
...

The statements represented by this are

<> con:address
  [
      con:street "4 Pear Tree Court" ;
      con:city "London" ;
      con:country "United Kingdom"
  ] .

Note however, that this indicates that it is the current document that 'has an address'. This is something that is often overlooked in the discussions about new markup to represent meta information - what exactly is it representing? To return to the type of example most often given:

<style>
   city { background-color: teal; }
</style>
<address>
   <street>4 Pear Treet Court</street>
   <city>London</city>
   <country>United Kingdom</country>
</address>

what is it that is based in London? And more to the point, what exactly is London. Let's turn to these questions now.

4.1 What Are We Trying To Represent?

When we are using meta it is clear that this:

<meta property="dc:creator">John Doe</meta>

means:

"John Doe" is the creator of this document

or:

<> dc:creator "John Doe" .

As we know, meta has an implied subject of the document that contains it. But when we say:

<city>London</city>

What is it that 'has' a property of city? We are probably not saying that the document has a property of city, with a value of 'London'. In fact, the only thing that we can be saying is that the text string 'London' has a type of city.

And why might authors want to emphasise this? In the hope that when someone uses some search engine to find documents about 'the city called London', they will find this document, and when they search for documents about Jack London, they won't.

Currently there is no easy way to indicate in a document which of these two queries you would like your document to repsond to. We could indicate the subject of a document with meta, by setting property to "dc:subject":

<meta property="dc:subject">London</meta>

but there is nothing here to say whether we are writing about Jack London, or the city.

Solving this problem would also help internationalisation, since currently the only options to help French users to find this document would be to mark the document up like this:.

<meta property="dc:subject">London, Londres</meta>

or this:.

<meta xml:lang="en" property="dc:subject">London</meta>
<meta xml:lang="fr" property="dc:subject">Londres</meta>

neither of which are very practical.

So, we seem to be stuck; if we start at the top of the document, and say that

"London" is a subject of this document

we don't know if we mean Jack London, or London Town. But if we start at the bottom of the document and say that:

"London" is a type of city

we're none the wiser as to how this piece of information relates to anything else. Using RDF statements again, we can say that the top-down approach is represented by:

<> dc:subject "London" .

and the bottom-up, by:

[ :city "London" ] .

Our task then is to see if we can make the two meet in the middle, and our first step is to solve the problem of searching for 'London' versus 'Londres'.

4.2 Identifying Resources

To re-cap, the issue is that the type of markup that is often proposed, such as:

<city>London</city>

is not much use to us, since we do not know what the information relates to. In this case, which city is it that has a string literal value of "London"? The key to this is of course to use a unique value based on URIs. If we had one defined for the city of London, in the UK, such as http://www.examples.org/city#london, and we were able to attach this in some way to our text, then we could unambiguously identify what we're talking about.

I propose therefore, that we add an attribute called resource, which would allow us to do the following:

<city resource="city:london">London</city>

We have now uniquely identified that the document we're dealing with has a reference to the city of London, in the UK, regardless of the actual text used in the document:

I stayed in the <city resource="city:london">capital</city> for a week.
Je voudrais visiter a <city resource="city:london">Londres</city>.

Now a search engine could search for all documents that contain a reference to http://www.examples.org/city#london, which would unambiguously identify documents relating to the city of London, in the UK. And provided that the search server had a mapping between "Londres" and http://www.examples.org/city#london, French speakers could also find this article. (And the indexing server may have deduced the mapping when crawling documents.)

As we can see with the use of this technique to make documents available to searches in other languages, it is particularly powerful when the term being searched for is not present in the document. For example, with this document:

Tomorrow the Prime Minister is expected to fly to ...

Searching for "Tony Blair" would not find this article. However, if a search server knows how to establish from a user that they are actually searching for http://people.com/TonyBlair, then we could mark up our document as follows:

Tomorrow the <span resource="p:TonyBlair">Prime Minister</span>
is expected to fly to ...

A search for articles relating to Tony Blair would now yield this one, even though his name is not mentioned. This becomes particularly useful when individuals and places are identified in a number of ways, and the lexical description bears no relation to the actual meaning:

Today <span resource="p:DianaSpencer">Lady Diana</span> died in a car crash ...
The <span resource="p:DianaSpencer">Princess of Wales</span> was killed today ...

One final example concerns distinguishing between two items of text that are the same, but represent something different. For example:

Yesterday in Parliament the <span resource="p:WinstonChurchill">Prime Minister</span>
said that we will fight on the beaches ...
Tomorrow the <span resource="p:TonyBlair">Prime Minister</span>
is expected to fly to ...

In these two examples the string of characters "Prime Minister" is exactly the same, but they refer to two different individuals. It is now possible to search for "Winston Churchill" and still find the first of these two articles, but not the second. Indeed, where we to search for "Prime Minister", our search server could easily ask us whether we want to search for the words "Prime Minister", or for articles about the current or a previous prime minister.

Editorial note
Of course, it is also now possible to search for "all articles about British prime ministers who served during the second world war", provided that the search engine is able to deduce such things. As long as the answer includes `p:WinstonChurchill` then this document can be located.

One last thing on resources, we still haven't addressed where this information is attached to. The easiest approach is to say that where any of our new attributes appear on an element that is not meta, then there is an implied relationship to the containing resource (or the document) of "xhtml2:reference". Our previous example therefore results in the following triples:

<> xh2:reference p:TonyBlair .

This means simply that this document contains a reference to Tony Blair. Note that this is not just a fudge - we are saying that a search for articles and documents written by, reviewed by, criticised by, or summarised by Tony Blair, is very different to seeking out articles and documents that make reference to Tony Blair. This additional property allows us to make that distinction.

4.3 Representing Type

Our second issue was to be able to express the type of our element. I would propose that property is allowed on any element, not just meta. For example:

<span property="con:address">
        <span property="con:street">4 Pear Tree Court</span>
        <span property="con:city">London</span>
        <span property="con:country">United Kingdom</span>
</span>

This now opens up an unlimited supply of descriptors for our text, and so rather than trying to add elements such as address, weight, time and so on we can make use of established taxonomies, or devise our own.

Note also that the presence of property creates opportunities for avoiding repetition. For example, we often find ourselves creating our metadata from information that also appears in the document itself:

<html xmlns:dc="http://purl.org/dc/elements/1.1/">
        <head>
                <title>Prime Minister to Fly Out Tomorrow</title>
                <meta property="dc:creator">John Doe</meta>
                </meta>
        </head>
        <body>
                <h1>Prime Minister to Fly Out Tomorrow</h1>
                <span>By John Doe</span>
                <p>
                        Tomorrow the <span resource="p:TonyBlair">Prime Minister</span> is expected to fly to ...
                </p>
        </body>
</html>

This often seems like unnecessary duplication, and may add an additional maintenance headache. However, specifying the property explicitly rather than using the default, we can abbreviate this document to:

<html xmlns:dc="http://purl.org/dc/elements/1.1/">
        <head>
                <title>Prime Minister to Fly Out Tomorrow</title>
        </head>
        <body>
                <h1>Prime Minister to Fly Out Tomorrow</h1>
                <span>By
                        <span property="dc:creator">John Doe</span>
                </span>
                <p>
                        Tomorrow the <span resource="p:TonyBlair">Prime Minister</span> is expected to fly to ...
                </p>
        </body>
</html>

Editorial note
Note that this means we have to refine the rule earlier, in which there was an implied "xhtml2:reference" value. We should now say that this is the default value for `properrty`.

4.4 Representing Value

Just as we sometimes need to refer to a resource, so sometimes we need to indicate clearly what the vallue of something is. In this example:

Yesterday in Parliament the <span resource="p:WinstonChurchill">Prime Minister</span>
said that we will fight on the beaches ...

we would like to indicate that the speech was made on June 4th, 1940, since this would allow sophisticated metadata searches to be made. To do this we use the attributes val and datatype:

<span datatype="xsd:date" val="1940-06-04">Yesterday</span> in Parliament the <span resource="p:WinstonChurchill">Prime Minister</span>
said that we will fight on the beaches ...

This would create the following triples:

<> xhtml2:reference "1940-06-04"^^xsd:date , p:WinstonChurchill .

5 Bibliography

XHTML-2.0-LINKTYPES: XHTML 2.0 Link Types (See http://www.w3.org/TR/2003/WD-xhtml2-20030506/abstraction.html#dt_LinkTypes.)
N3-PRIMER: N3 Primer (See http://www.w3.org/2000/10/swap/Primer.)

XHTML and RDF

Version 14 February 2004

Abstract

Status of this Document

Table of Contents

1 Motivation

2 Types of Metadata in XHTML Documents

3 Document Metadata

3.1 Top-level Metadata with `meta` and QNames

3.2 Statements About Top-level Metadata

3.3 Statements About Other Resources

3.4 String Literals and URIs

4 Markup Metadata

4.1 What Are We Trying To Represent?

4.2 Identifying Resources

4.3 Representing Type

4.4 Representing Value

5 Bibliography

XHTML and RDF

Version 14 February 2004

Abstract

Status of this Document

Table of Contents

1 Motivation

2 Types of Metadata in XHTML Documents

3 Document Metadata

3.1 Top-level Metadata with meta and QNames

3.2 Statements About Top-level Metadata

3.3 Statements About Other Resources

3.4 String Literals and URIs

4 Markup Metadata

4.1 What Are We Trying To Represent?

4.2 Identifying Resources

4.3 Representing Type

4.4 Representing Value

5 Bibliography

3.1 Top-level Metadata with `meta` and QNames