RE: [namespaceDocument-8] 14 Theses, take 2

Of the theses that Tim has offered us [1,2] the ones giving us most trouble

  12. Namespace documents should be human-readable.
  13. Namespace documents should not favor the needs of any one application
or application class.
  14. Namespace documents should not be "schemas".

I also have a minor concern with:

  6. Namespace names should not be URNs.

Which I'd prefer to see stated in a way that more directly exposes the
concern eg:

  6. Namespace names should use URI schemes that are dereferencable.

wrt 12,13 and 14 on my first read-through 13 really seemed to be there as a
bowling-pin to roll 14 at :-). The discussion between Dan and Tim, [3,4] on
13 seems to have converged at a point where 13 serves mostly as a
restatement of 12.

From [4]
>>> Finally, Dan Connolly had an issue with Thesis 13 "Namespace
>>> documents should not favor the needs of any one application or
>>> application class" which I never got time to understand. Dan?
>> Whatever you put there is going to favor the needs of some
>> applications over others. For example,
>>  12. Namespace documents should be human-readable.
>> favors the human-browsing application over, say, validation stuff.
> Yup, I'll accept that.  I'm explicitly arguing that explaining 
> namespaces to humans is of special importance among all the other
> things you might want to do with them - because that's how you
> empower people to do things with them.  I agree that there's a
> contradiction in my theses unless I better highlight this
> prejudice.

My gut feel is that namespace documents should be both machine and human
readable, and I agree with Mark Nottingham [5]:

> I think the overriding principle, from a URI perspective, is to give
> each thing that needs identity a URI. One can do conneg when there
> are a number of roughly equivalent (in information contained). These
> are somewhat orthoganal; one can do conneg and have only one URI,
> one can do conneg as well as have many URIs for the different
> representations, and one can just have a bunch of URIs

[I'm consicous that Patrick Stickler explored similar ground to what follows
in [6] although I wanted to persue a line of though without first re-reading
Parick's message.]

A namespace seems to me to be a means for partitioning a space of language
tokens (symbols) into clusters (namespaces) where the tokens within a
cluster are usually (but not aways) intended to be used together to form the
'vocabulary of a language' - all possible tokens could be said to exist and
we only say how use and interpret some of them, and even then there is
usually some context to that interpretation.

A schema defines the grammar rules for a language. That language uses a
vocabulary of tokens drawn from (potentially) multiple namespaces.

It's probably bad manners to define/redefine the grammar constraints
associated with tokens belonging to namespaces whose name lies outside your
authority. However, I expect I'd find that it's possible at least with XML
Schema. Likewise, RDFS schema information on domain/range constraints of a
given RDF property can be drawn from multiple source, and different
collections of RDFS statements would yield different constraints on a given
RDF property 

Anyway, the point wrt to Mark's comment is that I think that there are many
things (resources) that might be deserving of Web names and representations.
The above inarticulate ramble calls out a four possibles: namespaces;
grammars; vocabularies; and interpretations (of language utterances).

I think of a schema as defining the grammar of a language. This also implies
some constraints on the vocabulary of the language (which could be open or
closed). However, I don't think that the vocabulary of a lanuage defined in
schema (XMLS,RDFS, etc.) is necessarily constrained to draw its tokens from
a single namespace.

So... on the substantive issues under consideration:

  12. Namespace documents should be human-readable.

I would not argue against this, but I think I would add  "15. Namespace
documents should be machine readable" with equal weight to 12 (avoiding
replacing the unlucky 13).

  14. Namespace documents should not be "schemas".

Tend to agree, because I think that the things described by schemas are
grammar constraints on languages which will usually, but not always, have
just one intended interpretation. However, a given token may be admissable
(with same or different meaning/content model) in multiple grammars.
Basically, I don't think that a single schema covers all potential uses of a
token drawn from a given namespace or that it generally covers all tokens
clustered in that one namespace.

One further problem with 14 is that it only tells us one sort of thing that
a namespace document should not be... it would be interesting to dwell on
the desirable properties of a namespace document (I'll go an read RDDL

I was optimistic mid-way through reading the thread, and I wondering whether
things have drifted very far away from what seemed to be an the beginnings
of concensus emerging [7]. I don't we are very far from concensus - I think
we're tuning shoulds and mays, rather than musts and must nots.

Best regards

Stuart Williams

Received on Friday, 1 March 2002 12:43:34 UTC