GRDDL mechanisms
Specifying a Transformation For a Family of Documents
Let us refer to a class of XML or XHTML documents that share a specific semantically-meaningful structure as a "family" of documents. The idea behind GRDDL is that a family of documents will advertise its family via a well-known URI and that dereferencing this URI should lead a GRDDL processor to an algorithm to map from the structure to the semantics. The XHTML1 namespace URI is an example of one such family identifier.
The existence of such a well-known URI for vocabularies deployed on the Web is consistent with the World Wide Web Architecture WEBARCH described by the W3C Technical Architecture Group:
To benefit from and increase the value of the World Wide Web, agents should provide URIs as identifiers for resources.
In the case of XML vocabularies, the most deployed form of URI as identifier for a family of documents is the namespace of the root element - although this is not enforced by any specification, see the relevant TAG issue mixedNamespaceMeaning-13 for more details.
For instance, all P3P Policy Reference files P3P start with a META element in the http://www.w3.org/2002/01/P3Pv1 namespace; interestingly in the case of P3P, the associated meaning of the XML vocabulary has been formally translated in RDF, as described in the RDF Schema for P3P P3P-RDF. Similarly, SVG files and XML Schema files can be recognized by the namespace of their root element, making it a good identifier for the type of structure and semantics associated with these families of document.
XHTML also has been used as a container for sub-vocabularies, e.g. the XHTML Friends Network proposal XFN). The proper way to anchor these additional semantics in the Web is to use the profile attribute on the head element, as warranted by the HTML 4.01 specification HTML4:
The
profileattribute of theHEADspecifies the location of a meta data profile. The value of theprofileattribute is a URI. User agents may use this URI in two ways:
- As a globally unique name. User agents may be able to recognize the name (without actually retrieving the profile) and perform some activity based on known conventions for that profile. For instance, search engines could provide an interface for searching through catalogs of HTML documents, where these documents all use the same profile for representing catalog entries.
- As a link. User agents may dereference the URI and perform some activity based on the actual definitions within the profile (e.g., authorize the usage of the profile within the current HTML document). [The HTML4] specification does not define formats for profiles.
Indeed, an XHTML document using the set of relationships defined in XFN XFN must reference the XFN profile in its head element.
Both for XML and XHTML, when such a family identifier URI exists and is dereferencable, GRDDL proposes that dereferencing the said URI should provide one or more algorithms that transform an instance of a document of this family and turn it into RDF/XML statements. When such a transformation exists, GRDDL specifies that these statements are indeed part of the intended meaning of the document. This is illustrated with the .
Practically speaking, this works as follows:
- A GRDDL processor encounters an XML document whose root element has a dereferencable namespace URI. If this document is an XHTML document, the
headis examined for a derefencable profile URI. - Upon dereferencing the said URI, the GRDDL processor finds that it references one or more URIs identifying a set of algorithms (this step is described in more detail below).
- If the identified algorithms are well-known to the GRDDL processor, it applies them to the initial XML (or XHTML) document; otherwise, it dereferences the URIs and finds, e.g., an XSL transformation as one of the representations.
- Applying the XSL transformations to the initial document, the GRDDL processor extracts a set of RDF/XML statements that are asserted as being part of the intended meaning of the document.
Given the XML nature of the targeted vocabularies, and the growing availability of XSLT processors, GRDDL suggests that algorithms should be expressed in this language, so that a processor configured to fetch new algorithms on the fly could use XSLT XSLT1 as a common transformation language. At the time of this writing, XSLT 2 is still a Working Draft XSLT2, and the question of whether GRDDL should require support for XSLT 2 has not been fully addressed, although its admittedly superior expressive power makes it an interesting candidate.
This does not prevent the use of URIs as simple identifiers relying on a library for well-known transformation algorithms, nor the use of other techniques than XSLT to process the said XML documents.
A point has been left open in the process above: how to detect the URI referencing the algorithms in the namespace (or XHTML profile) document, given that there is no standard format for it? (See W3C TAG issue namespaceDocument-8). And indeed, namespace owners have put a wide variety of documents as representations of their URIs, from a simple HTML document to content negotiated schemas, DTDs, or RDDL documents to dispatch between these various relevant data.
To solve that problem, GRDDL instructs a processor not to look for a particular format, but to look for a given RDF property stated by the namespace or profile document. And since it is not possible to assume that all namespaces and profiles documents are published in RDF, the GRDDL processing is applied here recursively: namely, if the given namespace/profile document is not in RDF/XML but in some XML format, the processor should simply try to extract RDF statements from it using GRDDL processing.
The examples attached to the XSLT-based GRDDL processor XSLT-DEMO shows how this recursive processing can be applied fairly easily to namespace and profile documents given in XML Schema, XHTML and RDDL formats, and can be easily extended to any XML format. The illustrates how this would work applied to a namespace represented by an XML Schema - thus implementing partially one of the goals put up in the Cambridge Communiqué CambComm.
A final question arises with this recursive method: how to stop the recursion without having to modify all the namespace and profile documents of formats that may be used only a few times as containers for GRDDL markup? Not only would this be unlikely to be achievable, it would also limit the number of ways one could use a given format as a container for GRDDL markup.
The following section details the second GRDDL mechanism that makes this possible.
Specifying a Transformation For an Individual Document
There are various situations where it is not possible, practical or desirable to have a URI identifying a given family of documents, or to have it referenced in the places mentioned above (i.e. as namespace of the root element or as profile in the head element), or to change the representation available at such a URI.
Thus, GRDDL provides a second mechanism that allows authors to associate an individual document with a given transformation algorithm. It does so through
-
an attribute (
dataview:transformation) on the root element for the generic XML caseGRDDL attribute in an XML Schema document<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:data-view="http://www.w3.org/2003/g/data-view#" data-view:transformation="http://www.w3.org/2003/g/embeddedRDF.xsl">
-
for XHTML, given the syntactic constraints imposed by the required DTD validity, adding an attribute in the
htmlroot element is not an option. Thus, GRDDL proposes to use a specificrelattribute value (transformation), anchored in URI space through a defined profile attribute value:GRDDL link in an XHTML document<html xmlns="http://www.w3.org/1999/xhtml"> <head profile="http://www.w3.org/2003/g/data-view"> <title>Some Document</title> <link rel="transformation" href="http://www.w3.org/2000/06/dc-extract/dc-extract.xsl" />
This mechanism means that a GRDDL processor should
- look for the said attribute (resp. the said
profilevalue and the targets of the links with the saidrelvalue) in the root element of processed XML documents (resp. XHTML documents) - if the URIs given in this attribute (resp. in the links) identifies well-known algorithms, it applies the said algorithm to the initial document to extract RDF Statements
- otherwise, it dereferences the URIs and applies the XSL style sheets representations available to the initial document to extract RDF/XML Statements
- the statements extracted are then considered part of the intended meaning of the document
This mechanism offers a simple and short way to close the recursive processing explained above: in the case of an XML Schema-based namespace document (), one would just need to add a single transformation reference to the XML Schema to allow the GRDDL processor to extract the transformations that apply to all the documents defined in this namespace.
How can these mechanisms be used in practice with vocabularies deployed today? How do they allow communities to take part to the Semantic Web goals of re-using information as much as possible?
Scenarios of applications
Most of the deployed vocabularies (either XML or XHTML based) are the results of some agreement inside a community on the meaning of the terms defined by the vocabulary.
Some of these communities may wish to integrate these vocabularies into the Semantic Web, either to benefit of the promises of the network effect allowed by sharing a common format to carry semantics, or to solve a particular integration of vocabularies (see ), or simply to re-use some of the tools available for Semantic Web technologies to make inferences, visualize relationships, or ease indexing by Semantic Web bots.
We explore here a few usage scenarios of various communities, and how they could effectively use GRDDL to meet their needs. This section is purely putative and does not necessarily reflect the thinking of these communities.
The HTML Working Group is working on XHTML 2.0 XHTML 2.0. One of the most promising aspects of this new version of XHTML is the possibility to express in XHTML markup a very wide range of RDF Statements. This would offer a whole new community the opportunity to take a direct part to the Semantic Web.
The current proposal make it possible to extract RDF/XML Statements from XHTML 2 documents using XSLT, making it compatible with the GRDDL mechanisms. As such, any Semantic Web agent implementing GRDDL would be able to parse XHTML 2 documents, as long as the XHTML Working Group publishes in the XHTML 2 namespace document a proper link to the relevant XSLT style sheet.
The SVG specification offers a metadata tag, and its associated XML Schema allows any type of markup inside this element, thus allowing to embed RDF/XML Statements inside any kind of SVG content.
To help make these metadata elements available to Semantic Web agents, the SVG Working Group could decide to update the SVG namespace document, published in XHTML, to make it point to an XSL style sheet that would simply extracts the content of such metadata elements expressed in RDF/XML, making instantaneously all these metadata part of the Semantic Web.
The XFN community has defined a set of well-defined relationships names XFN anchored in a URI space through an XHTML profile. Since these relationships have been made explicit for authors and authoring tools developers, it is reasonable to assume that people using these conventions agree that using them is indeed expressing the intended meaning.
If the XFN community wanted to bring their data into the Semantic Web, for instance to be able to re-use the existing visualization tools developed for Semantic Web languages, they would simply need:
- to create an RDF/XML description of these relationships - or to make the existing XHTML description equivalent to a set of RDF/XML ones using GRDDL
- to update the existing XHTML profile to make it reference an XSL transformations that would turn links with XFN-relationships into proper RDF Statements, à la
[ foaf:homepage <myhomepage.html>] xfn:met [ foaf:homepage <http://buddy.example.net/homepage/> ].(in RDF/N3 for ease of reading)
The blogging community has been defining and re-using a number of HTML conventions to markup relationships between blog authors (XFN), geographical indications (GeoURL), communications endpoints (trackback, pingback), links endorsement (nofollow, etc.)
This growing number of conventions allows the encoding of a fascinating number of data that a few ad-hoc applications have started to explore. But the diversity of the topics and the number of used conventions make any development of this application dependent on the creation of a new one.
Moreover, a number of these conventions have not been grounded in URI space, making them somewhat fragile on the process to interpret and make these conventions evolve; in the future, new conventions may end up using clashing names by lack of coordination or due to bad timing.
To lower these risks and benefit from a stronger foundation, the blogging community could create a profile (or a set of profiles) that would associate the existing conventions to a URI; if this profile was set up with a set of GRDDL transformations, any content referencing the said profile could automatically be processed by Semantic Web agents supporting GRDDL. Moreover, any addition of a new convention to the given profile (as a result of a consensus in the community) could be supported in processing tools by simply adding a link to a new XSL style sheet to the said profile.
The Creative Commons have defined a set of RDF properties describing the licenses they propose for authors to use on their content. They want search engines to be able to parse this data in a wide variety of formats, from XHTML to the Open Archive Initiative format.
But each of these formats has a set of syntactic constraints that need to be addressed separately, using a different embedding technique.
Instead of having to maintain a library of formats that Creative Commons search engines need to know how to process, the Creative Commons could create a set of XSL transformations that would work for each of these formats, and either propose them as directly included in individual documents, or work with the community owning these formats to have them include the links in the relevant namespace and profile documents.
These various examples make appear an interesting property of GRDDL: given its levels of indirections, it can be adapted to a wide samples of community processes, and be used as a technical tool to express existing consensus among these communities.