Associating Resources with Namespaces

Draft TAG Finding 13 November 2007 16 May 2008

This version:
http://www.w3.org/2001/tag/doc/nsDocuments-2007-11-13/ http://www.w3.org/2001/tag/doc/nsDocuments-2008-05-16/
Latest version:
Previous versions:
http://www.w3.org/2001/tag/doc/nsDocuments-2007-11-13/ http://www.w3.org/2001/tag/doc/nsDocuments-2007-10-05/ http://www.w3.org/2001/tag/doc/nsDocuments-2007-09-19/ http://www.w3.org/2001/tag/doc/nsDocuments-2005-12-13/
Norman Walsh, Sun Microsystems, Inc. <Norman.Walsh@Sun.COM>
Henry S. Thompson, University of Edinburgh <ht@inf.ed.ac.uk>

This document is also available in these non-normative formats: XML .


This Finding addresses the question of how ancillary information (schemas, stylesheets, documentation, etc.) can be associated with a namespace.

Status of this Document

This document has been produced for review by the W3C Technical Architecture Group (TAG) . This finding addresses TAG issue namespaceDocument-8 .

This document is an editors' draft without any normative standing.

A diff-marked version showing changes since the previous version is available.

Additional TAG findings , both accepted and in draft state, may also be available.

The terms MUST , SHOULD , and SHOULD NOT are used in this document in accordance with [RFC 2119] .

Please send comments on this finding to the publicly archived TAG mailing list www-tag@w3.org ( archive ).

Table of Contents

1 Preface
2 The Model
3 Namespace Document Formats
    3.1 RDDL 1.0
    3.2 RDDL 2.0
    3.3 Using GRDDL
4 Namespace URIs and Namespace Documents
    4.1 Namespace URIs and Namespace Documents: The XML language case
    4.2 Namespace URIs and Namespace Documents: The Semantic Web case
    4.3 GRDDL and Namespace documents
5 Identifying Individual Terms
6 Nature Keys
7 Purposes


A References
B OWL Ontology for the RDDL Model (Non-Normative)

1 Preface

The names in a namespace form a collection:

There's no requirement that the names in a namespace only identify items of a single type; elements and attributes can both come from the same namespace as could functions and concepts or any other homogeneous or heterogeneous collection you can imagine. The names in a namespace can, in theory at least, be defined to identify any thing or any number of things.

Given the wide variety of things that can be identified, it follows that an equally wide variety of ancillary resources may be relevant to a namespace. A namespace may have documentation (specifications, reference material, tutorials, etc., perhaps in several formats and several languages), schemas (in any of several forms), stylesheets, software libraries, applications, or any other kind of related resource. The names in a namespace likewise may have a range of information associated with them.

A user encountering a namespace might want to find any or all of these related resources. In the absence of any other information, a logical place to look for these resources, or information about them, is at the location of the namespace URI itself. The details of exactly what this means may be subtlely different in different cases, but the general point is clear, as [WebArch Vol 1] says: It is Good Practice for the owner of a namespace to make available at the namespace URI “material intended for people to read and material optimized for software agents in order to meet the needs of those who will use the namespace”.

The question remains, how can we best provide both human and machine readable information at the namespace URI such that we can achieve the good practice identified by web architecture? One early attempt was [RDDL 1.0] . RDDL 1.0 is an XLink-based vocabulary for connecting a namespace document to related resources and identifying their nature and purpose.

Several attempts were made to simplify RDDL. The TAG's original plan for addressing namespaceDocument-8 was to help define a simpler, standard RDDL format. However, this space has matured somewhat since the TAG's original discussions and RDDL 1.0 is now widely deployed. In addition, some of the proposed alternative formats are also deployed, and it seems likely that over time new variations may arise based on other evolving web standards.

This finding therefore attempts to address the problem by considering it in a more general fashion. We:

  1. Define a conceptual model for identifying related resources that is simple enough to garner community consensus as a reasonable abstraction for the problem.

  2. Show how RDDL 1.0 is one possible concrete syntax for this model.

  3. Show how other concrete syntaxes could be defined and identified in a way that would preserve the model.

We'll define this model using RDF. RDF allows us to describing the model formally and allows us to integrate the semantics of terms in a namespace into the semantic web. It is important to note that the use of RDF for modelling the abstraction does not place any onus on implementors to use RDF technologies to locate ancillary resources nor does it require that authors writing namespace documents understand semantic web technologies or RDF.

Directing humans or machines to related resources is by no means the only kind of information about a namespace that a namespace document might provide. For humans, ordinary language, and for machines, [GRDDL] and [RDFa] , may be used to provide additional relevant information, for example the type and intended use of the things identified by individual names in the namespace. The RDF model defined here does not constrain whether or how such additional information may be provided.

2 The Model

There may exist any number of ancillary resources that are related to a namespace. Borrowing on the terminology defined by [RDDL 1.0] , we say that each of these other resources has a nature and serves a purpose.

In RDDL 1.0, the nature of a resource is specified using a URI, which identifies “what kind of thing” the resource is. For example, the URI http://www.w3.org/TR/html4/ is used to specify that a related resource is an HTML4 document, while http://www.isi.edu/in-notes/iana/assignments/media-types/text/css specifies that it's a CSS stylesheet and http://www.w3.org/2001/XMLSchema specifies that it's a W3C XML Schema document. The URIs used in RDDL 1.0 to specify natures varied widely, as these examples show (being URIs for respectively a W3C specification, an unresolvable node in IANA's web space and a namespace document).

In RDDL 1.0 the purpose of served by an ancillary resource is also specified using a URI, which identifies “what the ancillary resource is for” with respect to the resource to which it is related. For example, its purpose might be “validation” or “normative reference” or “specification” or “transformation”. The URIs used for purposes in RDDL 1.0 are all of the form http://www.rddl.org/purposes# plus the name of the purpose.

In order to model this set of relationships in RDF, there are two aspects which we must consider with care. The first is the range of “nature” labels. The second is the fact that we're describing a relationship between four terms: namespace, purpose, nature, and ancillary resource.

The range of labels used to identify the nature of a resource is very broad, ranging from terms defined in an RDF ontology to media types to the URI of specification documents to XML namespaces to the URI of a web site. To say that the nature of a resource is any one of these things suggests that the notion of “nature” has an exceptionally broad range. If a URI identifies a nature, is it coherent to say that it also identifies a HTML document, a media type or a namespace?

We can address this problem by observing that we don't really need to model what a nature is, we simply need to model the fact that we use a nature-related URI as a key to distinguish between different resources that could satisfy the same purpose.

With respect to the number of terms in the relationship, recall that RDF deals naturally with triples; addressing relationships with four or more parts is less straightforward. It's also worth noting that RDDL 1.0 doesn't set up links directly from a namespace to its ancilliary resources, but rather from individual resource description anchors within a namespace document.

We deal with both of these issues in our model by introducing a new, anonymous resource. The namespace is related to this This anonymous resource by its purpose; serves a purpose with respect to the anonymous resource namespace; it has a nature key and a target resource. We can show this graphically as follows:

Generic RDDL model

The model treats the collection of anonymous resources as indexed by the purposes they serve. The label purpose in the above diagram will be replaced by specific purposes in any actual instance of the model. For example, here's a diagram of the model for some DocBook-related resources:

Specific RDDL model for DocBook

This model indicates that for the purpose of validation there is a resource whose nature key is the one for Relax NG, and for the purpose of normative documentation, there is a resource whose nature key is the one for XHTML documents.

If an application can obtain this model from the document that it gets from the namespace URI, then it can find the relevant related resources. (It may also, of course, find the relevant related resources more directly if it has a native understanding of the format of the document.)

For example, a Relax NG validator could find all the resources that serve the purpose “validation” and identify the one (or one of the ones) with the nature “Relax NG” and proceed with a validation task. Similarly, a human being could find the resource with the purpose “normative reference” to locate the specification in a convenient format. The value of the nature information is that it enables software (or people) to identify the resources they are looking for without having to dereference many URIs looking for the right media type/namespace/...

Here's an expanded example of the DocBook model above, expressed in RDF using [N3] , with two . :

# RDDL Model for DocBook
@prefix purpose: <http://www.rddl.org/purposes#> .
@prefix nature: <http://www.rddl.org/natures#> .
  purpose:validation [a nature:Object;
      nature:key "http://relaxng.org/ns/structure/1.0";
      nature:target <http://docbook.org/xml/5.0b1/rng/docbook.rng> ];
  purpose:validation [a nature:Object;
      nature:key "http://www.w3.org/2000/10/XMLSchema";
      nature:target <http://docbook.org/xml/5.0b1/rng/docbook.xsd> ];
  purpose:reference [a nature:Object;
      nature:key "http://www.w3.org/1999/xhtml";
      nature:target <http://docbook.org/tdg5/en/html/> ];
  purpose:normative-reference [a nature:Object;
      nature:key "http://www.w3.org/1999/xhtml";
      nature:target <http://docbook.org/specs/wd-docbook-docbook-5.0b1.html> ] .

Although it is often the case the purpose and nature are closely coupled, it is not always possible to determine one given the other, as this expanded example shows. On the one hand we have two XHTML documents, one for the purpose of normative, and the non-normative, reference. On the other hand the purpose of schema validation is be satisfied by two resources, one a Relax NG document and the other a W3C XML Schema document.

3 Namespace Document Formats

This section describes two formats deployed explicitly to address the question of namespace documents and a third format which can be seen as simultaneously providing a unified view of these two formats and also providing a model to make other new formats available.

3.1 RDDL 1.0

A RDDL 1.0 document encodes the nature and purpose of the related resource in a rddl:resource element. That element uses XLink:

<rddl:resource xlink:title="Relax NG for validation"
A <a href="http://docbook.org/xml/5.0b1/rng/docbook.rng">schema</a>
for Relax NG validation.

Extacting the model is a simple matter of reading the xlink:href , xlink:role , and xlink:arcrole attributes of each rddl:resource .

3.2 RDDL 2.0

One of the RDDL 2.0 proposals encodes the nature and purpose of the related resource directly on the HTML a element:

<a rddl:nature="http://relaxng.org/ns/structure/1.0"

Extacting the model is a simple matter of reading the rddl:nature , rddl:purpose , and href attributes of each HTML a .

3.3 Using GRDDL

A third approach is to use [GRDDL] . GRDDL provides a mechanism for gleaning resource descriptions from XML. Employing GRDDL allows an author to associate a transformation with a document. The result of applying that transformation is an RDF model (the resource description).

Given that our RDDL model can be expressed in RDF, such a gleaned resource description can be seen as a RDDL model. Consider the following example:

The URI http://www.w3.org/2000/10/swap/pim/usps is the namespace name for an RDF vocabulary that describes United States postal addressing terms. Its namespace document is an XHTML document that uses GRDDL to identify an XSLT transformation into RDF.

If this transformation is applied, the resulting resource description includes the following model fragment:

 purpose:normative-reference [nature:target <http://pe.usps.gov/cpim/ftp/pubs/Pub28/pub28.pdf>],

In other words, this RDDL model:

RDDL model generated from HTML for usps

(The lack of nature keys in this example is not a bug, it simply reflects a lack of information in the HTML original.)

It's important to note that XSLT processing is not required to take advantage of GRDDL. For well-known transformation URIs, an application can be written to extract the data directly from the source markup without actually running an XSLT transformation. XSLT is only required when an application wants to support arbitrary GRDDL transformations.

In fact, a pair of well-known GRDDL transformation URIs for RDDL 1.0 and RDDL 2.0 will allow us to unify both RDDL variants and the GRDDL case.

4 Namespace URIs and Namespace Documents

In its finding on how responses to requests for resources which are not information resources should be constructed [HTTPRANGE] , the TAG recommended that documents descriptive of non-information resources should not be simply returned normally in response to requests for URIs which identify those resources. Since a namespace document is precisely such a descriptive document, and namespaces are not information resources, what should be done? How should namespace documents, as opposed to namespaces themselves, be identified and retrieved. retrieved?

Broadly speaking there are two distinct patterns of namespace naming, one virtually universal for namespaces identifying names in XML document vocabularies, and one at least dominant for namespaces identifying constituents of Semantic Web ontologies. Different solutions to the namespace document identification/retrieval problem are appropriate in these two cases.

4.1 Namespace URIs and Namespace Documents: The XML language case

Many XML languages use namespaces to distinguish the element and attributes names in that language from all others. For many of these languages, a namespace document can be retrieved from the namespace URI today, whether they are official W3C standards (for example W3C XML Schema (namespace URI http://www.w3.org/2001/XMLSchema ), SVG (namespace URI http://www.w3.org/2000/svg )) or created by government (State of Minnessota Criminal Justice Integration http://www.it.ojp.gov/jxdm/3.0.2 ), industry groups (Auto parts (PIES) www.aftermarket.org/eCommerce/Pies http://www.aftermarket.org/eCommerce/Pies ) or individuals (RelaxNG http://relaxng.org/ns/structure/1.0 ). We recommend that in all such cases server configurations should be changed, in line with [HTTPRANGE] , to respond with a 303 redirection from the namespace URI to a related URI for the namespace document. For all of the above examples, and for virtually all cases we are aware of, an appropriate URI for the namespace document (and indeed one from which it is often already available) can be formed by simply adding .html to the namespace URI.


The examples above, and in the next section, were as described at the time of publication, but may change over time.

4.2 Namespace URIs and Namespace Documents: The Semantic Web case

Many namespaces have been created in the context of Semantic Web projects to distinguish the names of classes, properties and individuals defined and/or described by that project from all others. One common approach is to use a namespace URI ending with a hash ( # ) to identify the namespace, in which case the URI without the hash is available to identify the information resource which describes the namespace, that is, the namespace document. Some Semantic Web vocabularies, however, use plain URIs without a # , in which case the same 303-based approach recommended above should be used. Some namespaces in this category already do this, for as illustrated by this example t. . Others do different kinds of redirection. For example, we find RDF and HTML descriptions of the FOAF namespace http://xmlns.com/foaf/0.1/ at http://xmlns.com/foaf/0.1/index.rdf and http://xmlns.com/foaf/0.1/index.html respectively, to which we are silently redirected via content negotiation, whereas for the one of the Dublin Core namespaces http://purl.org/dc/terms/ we find its RDF description at http://dublincore.org/2006/12/18/dcq.rdf , to which we get a 302 ('Found') redirection.

4.3 GRDDL and Namespace documents

When both human-readable and RDF-format descriptions of a namespace are available, with the latter being derived from the former via GRDDL, it is good practice to make the GRDDL-derived description available at its own URI. Whether this is done using a static copy or by applying the GRDDL-specified transformation on demand is an implementation detail.

5 Identifying Individual Terms

For many applications of namespaces, it's valuable not only to be able to point to the namespace as a whole, but also to be able to point to terms within that namespace. Fragment identifiers are the obvious mechanism for achieving this. For example, http://www.w3.org/2005/xpath-functions/#matches is the URI for the “matches” function, a term in the XQuery 1.0, XPath 2.0, and XSLT 2.0 Functions and Operators Namespace , http://www.w3.org/2005/xpath-functions/ .

If it would be valuable to directly address specific terms in a namespace, namespace owners SHOULD provide identifiers for them. It follows that if the namespace document is available in multiple forms (RDDL 1.0, RDF through GRDDL, etc.) that consistent fragment identifiers MUST be made available. See 3.2.2. Fragment identifiers and content negotiation in [WebArch Vol 1] .

6 Nature Keys

The nature key of a resource specifies the fundamental or essential characteristics of that resource. We often speak of the nature of documents in an informal manner: when we say “that's an XML Schema”, or “that's an HTML document”, or “that's an XML DTD”, we are identifying the nature of those documents.

The RDDL Model uses a URI to uniquely identify the nature of a resource. For XML vocabularies, the namespace URI is often suitable as a key for the nature of a resource encoded in that vocabulary. For other resources, the URI of the a media type or normative specification is appropriate. Here are the nature keys corresponding to the natures listed in [RDDL 1.0] :


The nature key for a defined term.


The nature key for CSS.


The nature key for an XML DTD.


The nature key for a mailbox.


The nature key for generic HTML.


The nature key for HTML 4.


The nature key for HTML 4 Strict.


The nature key for HTML 4 Transitional.


The nature key for HTML 4 Frameset.


The nature key for XHTML 1.0.


The nature key for XHTML 1.0 Strict


The nature key for XHTML 1.0 Transitional.


The nature key for an RDF Schema.


The nature key for Relax (not Relax NG) Core.


The nature key for Relax (not Relax NG) Namespace.


The nature key for Schematron.


The nature key for an OASIS Open Catalog.


The nature key for a W3C XML Schema.


The nature key for XML character data.


The nature key for escaped XML.


The nature key for an XML unparsed entity.


The nature key for an IETF RFC.


The nature key for an ISO Standard.

7 Purposes

Purpose is a relationship between a namespace, another resource and the nature of that resource. Broadly, it answers the question "For this purpose with respect to this namespace, what resource do I need, and what is the nature of that resource?". For example, with respect to a particular namespace, the purpose of an W3C XML Schema might be “validation” (of documents in that namespace). For the XHTML 1.0 namespace, the purpose of the XHTML Recommendation might be “normative reference”. Although when expressed as it is here as the name of an RDF property, the name 'purpose' seems to read backwards, as it were, it has been retained for compatibility with RDDL 1.0.

Here are the purposes identified in [RDDL 1.0] :


Serves the purpose of SGML or XML DTD validation.


Serves the purpose of W3C XML Schema validation.


Serves the purpose of a software module.


Serves the purpose of a schema module.


Serves the purpose of an entity or collection of entities.


Serves the purpose of a notation or a collection of notations.


Serves the purpose of a software module.


Serves the purpose of a software package.


Serves the purpose of a software project.


Serves the purpose of a Java archive, a package of code and/or other resources.


Serves the purpose of documentation.


Serves the purpose of normative documentation.


Serves the purpose of non-normative documentation.


Serves the purpose of being a prior version.


Serves the purpose of a definition (as to a specific term)


Serves the purpose of an icon or other relevant image.


Serves the purpose of being an alternate.


Serves the purpose of being canonical.


Serves the purpose of being a RDDL directory.


Serves the purpose of being the target URI (as of a #directory).


Serves the purpose of being the target URI (as of a #directory).

A References

Adida, B. and M. Birbeck eds. RDFa Primer 1.0 Embedding RDF in XHTML . W3C, March 2007. (See http://www.w3.org/TR/xhtml-rdfa-primer/.)
RFC 2119
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels . IETF. March, 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)
RDDL 1.0
Jonathan Borden and Tim Bray. Resource Directory Description Language (RDDL) . February, 2002. (See http://www.rddl.org/.)
WebArch Vol 1
Ian Jacobs and Norman Walsh, editors. Architecture of the World Wide Web, Volume 1 . World Wide Web Consortium, 2004. (See http://www.w3.org/TR/webarch/.)
Dominique Hazaël-Massieux and Dan Connolly, editors. Gleaning Resource Descriptions from Dialects of Languages (GRDDL) . World Wide Web Consortium, 2004. (See http://www.w3.org/TR/grddl/.)
Tim Berners-Lee. Notation 3 . 1998. (See http://www.w3.org/DesignIssues/Notation3.html.)
R. Fielding, ed. "[httpRange-14] Resolved", W3C Tag, 2003. (See http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.)

B OWL Ontology for the RDDL Model (Non-Normative)

An OWL Ontology for the RDDL Model described in this Finding.

# -*- N3 -*-
# OWL Ontology for RDDL Model
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix : <http://www.w3.org/2000/01/rdf-schema#> .
@prefix p: <http://www.rddl.org/purposes#> .
@prefix n: <http://www.rddl.org/natures#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix r2: <http://www.example.org/purposes#> .
n:Object     a owl:Class;
     :comment """An association of a resource and a nature key: the object of an
     :label "Object" .
n:target     a owl:ObjectProperty;
     :comment "The resource of an Object";
     :domain n:Object;
     :label "target" .
n:key     a owl:DatatypeProperty;
     :comment "The Nature Key of an Object";
     :domain n:Object;
     :label "nature key";
     :range xsd:anyURI .
p:Purpose     a owl:ObjectProperty;
     :comment "The super-type of all RDDL purposes";
     :range n:Object;
     :label "Purpose" .
# ============================================================
# RDDL 1.0 Purposes
p:validation a owl:ObjectProperty; :subPropertyOf p:Purpose;
  :comment "Serves the purpose of SGML or XML DTD validation." .
p:schema-validation a owl:ObjectProperty; :subPropertyOf p:Purpose;
  :comment "Serves the purpose of W3C XML Schema validation." .
p:module a owl:ObjectProperty; :subPropertyOf p:Purpose;
  :comment "Serves the purpose of a software module." .
p:schema-module a owl:ObjectProperty; :subPropertyOf