W3C

Associating Resources with Namespaces

Draft TAG Finding 19 September 2007

This version:
http://www.w3.org/2001/tag/doc/nsDocuments-2007-09-19/
Latest version:
http://www.w3.org/2001/tag/doc/nsDocuments/
Previous version:
http://www.w3.org/2001/tag/doc/nsDocuments-2005-12-13/
Editor:
Norman Walsh, Sun Microsystems, Inc. <Norman.Walsh@Sun.COM>

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


Abstract

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 editor's draft without any normative standing.

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 Identifying Individual Terms
5 Natures
6 Purposes

Appendices

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.

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.

[WebArch Vol 1] says that it is a 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 identifying the nature and purpose of related resources.

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.

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 a purpose.

The nature of the resource is a machine-readable label (i.e., a URI) that identifies “what kind of thing” it is. For example, the key to its nature might be “HTML documentation” or “XML Schema” or “CSS Stylesheet”.

The purpose of an ancillary resource is a machine-readable label that 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”.

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 nature “is a” web site, is it coherent to say that it is also a namespace or an HTML document?

We can address this problem by observing that we don't really need to model what the nature is, we simply need to model the fact that we use the nature label 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.

We deal with both of these issues in our model by introducing a new, anonymous resource. The namespace is related to this anonymous resource by its purpose; the anonymous resource has a nature key and a target resource. The nature key is the label which allows us to distinguish between the different targets that could be used for the purpose. We can show this graphically as follows:

Diagram

For example, here's a diagram of the model for some DocBook-related resources:

RDDL Model for DocBook

This model indicates that for the purpose of validation there are two resources, one that identifies docbook.xsd with the nature key “XML Schema” and one that identifies docbook.rng with the nature key “RELAX NG”. This model also includes two examples of HTML documentation, defguide.html which has the purpose “reference” and docbook.html which has the purpose “normative reference”.

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 “specification” to locate the specification in a convenient format.

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

# RDDL Model for DocBook

@prefix purpose: <http://www.rddl.org/purposes#> .
@prefix nature: <http://www.rddl.org/natures#> .

<http://docbook.org/ns/docbook>
  purpose:validation [
      nature:key <http://relaxng.org/ns/structure/1.0>;
      nature:target <http://docbook.org/xml/5.0b1/rng/docbook.rng> ];

  purpose:validation [
      nature:key <http://www.w3.org/2000/10/XMLSchema>;
      nature:target <http://docbook.org/xml/5.0b1/rng/docbook.xsd> ];

  purpose:reference [
      nature:key <http://www.w3.org/1999/xhtml>;
      nature:target <http://docbook.org/tdg5/en/html/> ];

  purpose:normative-reference [
      nature:key <http://www.w3.org/1999/xhtml>;
      nature:target <http://docbook.org/specs/wd-docbook-docbook-5.0b1.html> ] .

If we can construct this model from a namespace document, then we know we have all the information we need to locate related resources.

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"
	       xlink:arcrole="http://www.w3.org/2005/12/assoc#relaxng-validation"
	       xlink:role="http://relaxng.org/ns/structure/1.0"
	       xlink:href="http://docbook.org/xml/5.0b1/rng/docbook.rng">
A <a href="http://docbook.org/xml/5.0b1/rng/docbook.rng">schema</a>
for RELAX NG validation.
</rddl:resource>

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
<a rddl:nature="http://relaxng.org/ns/structure/1.0"
   rddl:purpose="http://www.w3.org/2005/12/assoc#relaxng-validation"
   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 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 the transformation http://www.w3.org/2000/07/hs78/html2rdfs.

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

<http://www.w3.org/2000/10/swap/pim/usps>
 purpose:normative-reference <http://pe.usps.gov/cpim/ftp/pubs/Pub28/pub28.pdf>,
                             <http://pe.usps.gov/cpim/ftp/pubs/Pub63/Pub63.pdf> .

In other words, this RDDL model:

RDDL Model for USPS

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 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].

5 Natures

The nature of a resource identifies 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 an identifier for the nature of a resource encoded in that vocabulary. For other resources, the URI of the normative specification is appropriate. Here are the natures identified by [RDDL 1.0]:

http://www.rddl.org/natures#term

The nature of a defined term.

http://www.isi.edu/in-notes/iana/assignments/media-types/text/css

The nature of CSS.

http://www.isi.edu/in-notes/iana/assignments/media-types/application/xml-dtd

The nature of an XML DTD.

http://www.rddl.org/natures#mailbox

The nature of a mailbox.

http://www.isi.edu/in-notes/iana/assignments/media-types/text/html

The nature of generic HTML.

http://www.w3.org/TR/html4/

The nature of HTML 4.

http://www.w3.org/TR/html4/strict

The nature of HTML 4 Strict.

http://www.w3.org/TR/html4/transitional

The nature of HTML 4 Transitional.

http://www.w3.org/TR/html4/frameset

The nature of HTML 4 Frameset.

http://www.w3.org/1999/xhtml

The nature of XHTML 1.0.

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict

The nature of XHTML 1.0 Strict

http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional

The nature of XHTML 1.0 Transitional.

http://www.w3.org/2000/01/rdf-schema#

The nature of an RDF Schema.

http://www.xml.gr.jp/xmlns/relaxCore

The nature of RELAX (not RELAX NG) Core.

http://www.xml.gr.jp/xmlns/relaxNamespace

The nature of RELAX (not RELAX NG) Namespace.

http://www.ascc.net/xml/schematron

The nature of Schematron.

http://www.rddl.org/natures#SOCAT

The nature of an OASIS Open Catalog.

http://www.w3.org/2000/10/XMLSchema

The nature of a W3C XML Schema.

http://www.w3.org/TR/REC-xml.html#dt-chardata

The nature of XML character data.

http://www.w3.org/TR/REC-xml.html#dt-escape

The nature of escaped XML.

http://www.w3.org/TR/REC-xml.html#dt-unparsed

The nature of an XML unparsed entity.

http://www.ietf.org/rfc/rfc2026.txt

The nature of an IETF RFC.

http://www.iso.ch/

The nature of an ISO Standard.

6 Purposes

Purpose is a relationship between a namespace name and another resource. Broadly, it describes the action one might take with the related resource. For example, with respect to an XML document, the purpose of an W3C XML Schema might be “validation”. For an XHTML 1.0 document, the purpose of the XHTML Recommendation might be “normative reference”.

Here are the purposes identified in [RDDL 1.0]:

http://www.rddl.org/purposes#validation

Serves the purpose of SGML or XML DTD validation.

http://www.rddl.org/purposes#schema-validation

Serves the purpose of W3C XML Schema validation.

http://www.rddl.org/purposes#module

Serves the purpose of a software module.

http://www.rddl.org/purposes#schema-module

Serves the purpose of a schema module.

http://www.rddl.org/purposes#entities

Serves the purpose of an entity or collection of entities.

http://www.rddl.org/purposes#notations

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

http://www.rddl.org/purposes#software-module

Serves the purpose of a software module.

http://www.rddl.org/purposes#software-package

Serves the purpose of a software package.

http://www.rddl.org/purposes#software-project

Serves the purpose of a software project.

http://www.rddl.org/purposes#JAR

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

http://www.rddl.org/purposes#reference

Serves the purpose of documentation.

http://www.rddl.org/purposes#normative-reference

Serves the purpose of normative documentation.

http://www.rddl.org/purposes#non-normative-reference

Serves the purpose of non-normative documentation.

http://www.rddl.org/purposes#prior-version

Serves the purpose of being a prior version.

http://www.rddl.org/purposes#definition

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

http://www.rddl.org/purposes#icon

Serves the purpose of an icon or other relevant image.

http://www.rddl.org/purposes#alternate

Serves the purpose of being an alternate.

http://www.rddl.org/purposes#canonicalization

Serves the purpose of being canonical.

http://www.rddl.org/purposes#directory

Serves the purpose of being a RDDL directory.

http://www.rddl.org/purposes#target

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

http://www.rddl.org/purposes#target

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

A References

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/.)
GRDDL
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/.)
N3
Tim Berners-Lee. Notation 3. 1998. (See http://www.w3.org/DesignIssues/Notation3.html.)

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 xs: <http://www.w3.org/2001/XMLSchema#> .
@prefix assoc: <http://www.w3.org/2005/12/assoc#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix p: <http://www.rddl.org/purposes#> .

# Purpose is a relationship between the resource identified with
# a namespace URI and another resource (that is presumably useful
# for the specified purpose).
#
# With respect to example.xml, the purpose of example.xsd is schema validation.

assoc:purpose a owl:ObjectProperty;
  rdfs:comment """The relationship between a namespace name and
another resource useful for the specified purpose.""" .

# Nature is the relationship between a resource and the resource
# which defines it's inherent character.
#
# The nature of example.xsd is that it is a W3C XML Schema document.

assoc:nature a owl:ObjectProperty;
  rdfs:comment """The relationship between a resource and
another resource which describes its nature.""" .

# ============================================================
# RDDL 1.0 Purposes
#

p:validation a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of SGML or XML DTD validation." .

p:schema-validation a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of W3C XML Schema validation." .

p:module a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of a software module." .

p:schema-module a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of a schema module." .

p:entities a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of an entity or collection of entities." .

p:notations a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of a notation or a collection of notations." .

p:software-module a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of a software module." .

p:software-package a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of a software package." .

p:software-project a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of a software project." .

p:JAR a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment """Serves the purpose of a Java archive,
a package of code and/or other resources.""" .

p:reference a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of documentation." .

p:normative-reference a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of normative documentation." .

p:non-normative-reference a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of non-normative documentation." .

p:prior-version a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of being a prior version." .

p:definition a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of a definition (as to a specific term)" .

p:icon a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of an icon or other relevant image." .

p:alternate a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of being an alternate." .

p:canonicalization a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of being canonical." .

p:directory a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of being a RDDL directory." .

p:target a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of being the target URI (as of a #directory)." .

# ============================================================
# Examples of new purposes
#

assoc:relaxng-validation a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of RELAX NG Schema validation." .

assoc:function a owl:ObjectProperty; rdfs:subPropertyOf assoc:purpose;
  rdfs:comment "Serves the purpose of a function in programming language." .