Re: The URI of a RDDL "nature"

Norm et al.

I've been revisiting this and I want to run a couple of things by you.

> Hi Jonathan,
> If you saw the minutes of the last couple of TAG meetings, you may
> have noticed that there's been some expression of discomfort about the
> "nature" URIs in RDDL. Unlike the "purpose" URIs which are all
> identified by anchors in, the nature URIs
> are drawn from a variety of sources.
> As you already observed, the use of "" as the nature
> of an ISO standard is controversial for a few reasons. The most
> technic argument against it, I think, is that it conflates "a website"
> and "a nature" so that any descriptive statement made about a nature
> must (by virtue of the use of the same URI) also be a statement about
> the website.

This is entirely correct and it is wrong to use the URI of the  
website as the nature of the specification. It is unfortunate that  
such examples were used but I don't want to entirely throw out the  
baby with the bathwater until at least after some further discussion.

More specifically, I'd like to at least preserve the idea that a URI  
being used as a namespace name may be used as the URI which  
identifies the nature of a related resource.

> To a greater or lesser extent, the same argument
> applies to several other nature URIs as well.

As indicated above, I'd like to, at the very least, draw the line at  
the point where some of the other nature URIs are namespaces.

There are several principles that should be considered. Let's start  
with the definition of nature as given in Section  

	Related resources have a nature, a machine-readable label provided
	by the value of the xlink:role attribute. For example, the nature of  
an XML Schema
	designed for use with a namespace would be given as

Aside from places where the natures as given in 
natures/ may be bad examples, do you really mean to say that the  
nature of an XML Schema ought not be

1) The namespace of the root element of the document *may* be used to  
determine the nature of the document. The utility of this is that the  
root element ought point to a RDDL which is used to get a schema etc  
to process the document.

The following point should be at the least discussed:

2) Any specification/recommendation defines a class of things that  
conform to it. For example: on one had  
refers to a specification but at the same time defines a class of  
documents which 'conform' to the outlined specification.

A nature is specifically intended to be such a class.

In my mind the URI identifies a  
specification which defines a class of documents. I can see using  
this URI as a rddl:nature but if there is a need to distinguish  
between the specification that defines the class and the class itself  
then I agree that it would be best to use a different URI for the  

> On the whole, I've been persuaded by the arguements and I think it
> would have been less controversial if the nature URIs had all followed
> the same pattern as the purpose URIs (as several already do).
> In approaching namespaceDocument-8, the TAG has been very conscious of
> the problem associated with changing URIs that are already used in
> deployed software. But it occurred to me that very few of the "nature"
> URIs are likely to actually be used in deployed *software* *today*.
> I would hazard that only the following are actually used:

These are namespace names, moreover these are all types of schemata  
-- the archetypical rddl:natures:

I have seen a discussion of why things like websites are not  
rddl:natures (and agree) but a namespace and a website are different.  
What is the objection to using a namespace URI as a nature?

These aren't namespaces and I'm not terribly attached to these being  
> application/xml-dtd

I am happy to create new URIs for natures which aren't namespace names.


Received on Saturday, 14 January 2006 17:57:54 UTC