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.

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 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:

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, and , 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.

There may exist any number of ancillary resources that are related to a namespace. Borrowing on the terminology defined by , we say that each of these other resources has a nature and 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 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 the 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.

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. We can show this graphically as follows:

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.

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 .

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 normative specification is appropriate. Here are the nature keys corresponding to the natures listed in :

Purpose is a relationship between a namespace name and another resource. Broadly, it describes the action one might take with the related resource or the reason one might look at it. 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 :