- From: Williams, Stuart <skw@hplb.hpl.hp.com>
- Date: Fri, 1 Mar 2002 17:43:06 -0000
- To: TAG <www-tag@w3.org>
Of the theses that Tim has offered us [1,2] the ones giving us most trouble are: 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 again). 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 [1] http://lists.w3.org/Archives/Public/www-tag/2002Feb/0104.html [2] http://www.textuality.com/tag/Issue8.html [3] http://lists.w3.org/Archives/Public/www-tag/2002Feb/0106.html [4] http://lists.w3.org/Archives/Public/www-tag/2002Feb/0112.html [5] http://lists.w3.org/Archives/Public/www-tag/2002Feb/0200.html [6] http://lists.w3.org/Archives/Public/www-tag/2002Feb/0022 [7] http://lists.w3.org/Archives/Public/www-tag/2002Feb/0114.html
Received on Friday, 1 March 2002 12:43:34 UTC