RDF in HTML: Approaches (original) (raw)

Since there is no one standardized approach for associating RDF compatible metadata with HTML, and since this is one of the most frequently asked questions on the RDF mailing lists, this document is provided as an outline of some RDF-in-HTML approaches that the author is aware of.

Table Of Contents

• Introduction
• The Approaches(approaches TOC)
• Issues With Embedding
• Conclusion: Which Approach Is Best?
• Further Reading

Please direct feedback to the author, preferably CCing the publically archived www-archive.

Introduction

Ever since RDF's inception, people have been wanting to embed it in their HTML documents. In fact, ever since HTML was invented, people have been wanting to embed some sort of metadata for extraction and processing by user agents and crawlers. So, theoretically, HTML and RDF is a match made in heaven (aka. the halls of the W3C's offices at MIT).

However, after many raging discussions within the W3C's RDF Interest Group and elsewhere, there is still no one standard method for associating RDF with HTML. This is an important thing for the Semantic Web community to resolve: even the author has quite recently found himself wanting to associate RDF with HTML for certain applications, but has had to put-aside the application due to the lack of a standard approach.

The original RDF FAQ contained a piece of advicetelling people to simply embed the XML RDF into the XHTML (cf. Embed XML RDF Part I), but this was criticized since the approach means that the resultant XHTML/RDF soup does not validate. This issue has been noted by the RDF Core Working Group (as faq- html-compliance), and is currently "for discussion". My hope is that this document will be valuable input into the issue.

All of the approaches given in this note will suited towards particular applications. What applications are there? In general, anything that combines human and machine readable data is game; for example: RDF Schemata/namespace documents, page accessiblity evaluations, complex relationships between the document and related resources (for example, one could generate an SVG diagram showing how this document fits into the rest of the world), links to digital signatures, and possibly even advanced versioning data (cf. CVS). Only the first of the list is extant, to the best of the author's knowledge.

The Approaches

• Embed XML RDF Part I: Eschew Validation
• Embed XML RDF Part II: Embrace Validation
• Utilize the Object or Script Elements
• to the Metadata
• HyperRDF
• Augmented Metadata for XHTML
• Use the Profile Attribute
• Making use of XML Notations

In no particular order...

>>Embed XML RDF Part I: Eschew Validation

In the "validator.w3.org be damned" approach, one would generally use the abbreviated XML RDF syntax so as to hide the contents from older browsers (which usually render the contents of any element, but not attribute values).

This approach is convenient for authors that know how to author XML RDF (or have had some generated for them). It's quite easy for agents to extract, too. However, it also has many disadvantages: it does not validate, may still choke some older browsers, and the fragment identifers may conflict. As the TAG have put it:-

[...] despite widely adopted specifications for XHTML and RDF, there is no specification for the interpretation of the mixture. The TAG felt that this lack, falling between the scopes of two working groups, was within its scope to fill or ask to be filled. [...] A futher problem is that the question of how to define the meaning of a URIref with fragement id wihtin such a document.

Sidenote: Murray Altheim wrote an excellent summary of why validation is important. Also: Nick Kew's essay on the subject.

>>Embed XML RDF Part II: Embrace Validation

This "create a new XHTML family" approach basically involves hacking up a small DTD (document type definition) using XHTML Modularization for a variant of XHTML, putting it on the Web, and then referencing it from your document. The main drawback is that the DTDs are large and relatively complex; this is not a viable approach for typical HTML authors.

XHTML Modularization is essentially oriented towards companies and skilled Web users that want to provide regular extensions to XHTML. It is not so good when it comes to unique extensions that need to be created on a whim.

This method has the same "what is the meaning of the fragment identifiers within such a document?" issue as embed-and-don't-validate.

>>Utilize the Object or Script Elements

HTML has two elements for including non-HTML media; <object>, and <script>. <object> is a generic element for including any external object, whereas <script> is available for embedding executable scripts.

The HTML 4.01 specification says that inline data may be supplied from a base64 encoded "data:" URI. For example:-

congrats, you've found a syntax less workable thatn RDF/XML.

- Edd Dumbill, 24 seconds after this method was proposed on #rdfig.

Of course, one can also link to the RDF in an external file, although we shall be discussing using the element for this a little later. Note that object allows one to cascade the referenced media, thereby offering a provision for alternate serializations: perhaps offering XML RDF, Notation3, and NTriples versions of your RDF metadata.

All that the HTML 4.01 specification says about the contents of the script element is that:-

Scripts are evaluated by script engines that must be known to a user agent. [...] The syntax of script data depends on the scripting language.

This is suspiciously vague. Moreover, whilst I do not want to get engaged in an argument over the semantics of programming languages, I will note that people [such as Sandro Hawke? ask Sandro if he really said this] have estimated that the Notation3 superset of RDF has as much power as Prolog, a well-known highly-declarative programming language.

Since using the script element in this way is very similar to embedding the information (it's just embedding + giving the media type), one would presume that it has the same fragment-conflict problem looming over it.

>> <link> to the Metadata

Arguably the purest solution from an architectural point of view, making use of the <link> element has been the object of criticism since maintaining the metadata externally to the RDF is seen as an inconvenience. Proponents of the solution contend that CSS, JavaScript, and images are already maintained externally without fuss, and that retrieving external files does not take much more programming than extraction (in fact, possibly less so).

Here's an example:-

or, if you want to mention it in the document body...

blargh[...]

Note that according to the HTML 4.01 specification:-

Authors may wish to define additional link types not described in this specification. If they do so, they should use a profileto cite the conventions used to define the link types.

Since this recommendation is a "should" and "not" a must, and since the "meta" link relationship is not one where achieving a global consensus should be a difficulty, it is reasonable to use the link type without declaring a profile.

Another interesting point to note is that the link element does allow for a certain amount of cascading thanks to the "alternate" link relationship. For example:-

This means that the XML RDF version is preferred, but that user agents may use the Notation3 and/or NTriples files as alternatives.

>>HyperRDF

Dan Connolly of the W3C published a note that outlined an ingenious method for marking up HTML in such as way as to make relatively easy to transform via. XSLT into RDF. The method relies upon binding URIs to link relationship QName prefixes via. a special profile and the element, and closely resembles the XML Names binding mechanism.

Here's the basic example from DanC's proposal:-