Re: [namespaceDocument-8] 14 Theses
On 2002-02-18 8:00, "ext Tim Bray" <tbray@t...> wrote: > We have general agreement that the issue of "namespace > documents" is one that deserves further study. I spent > some time over the weekend trying to get my thoughts and > arguments in order and have published them at > > http://www.textuality.com/tag/Issue8.html > > Note that this also takes care of my action item to say > something about URNs as namespace names. -Tim Thanks, Tim, for taking the effort to put your thoughts into words in such a well thought out and organized fashion. A few comments and questions: -- Item 1, I fully agree. Well said. -- In item 2, you talk about "a namespace that makes some assertions about the syntax and semantics of its content" but no such namespace exists. You are referring to a document model which uses a single vocabulary grounded in a single namespace, and the 1:1:1 correlation between namespace, vocabulary, and model is coincidental -- or even if intentional, does not mean that the same applies to any other namespace. A namespace is punctuation. If someone chooses to use a namespace as an alias or synonym of a vocabulary or document model, then that is poor practice and is a good example of why there is so much confusion about what a namespace correlates to. -- In item 4, you say "[because] namespace names may be "http:"-class URIs, it is a grievous waste of potential if it is not possible to use the namespace name in retrieving the definitive material." While I do agree that it is good for the purpose, significance, or simply historical use of a given namespace to be clearly documented and for such information (as for all useful information) to be web-retrievable, that does not necessarily mean that an http: URL should necessarily be used as the namespace URI and that the documentation about that namespace be HTTP GETable via that namespace http: URL. There are other ways to associate information with a URI (any URI, not just an http: URL) and other (both real and conceivable) ways to retrieve such information in a Web context. Just because we have a hammer (HTTP) does not mean that everything should remain a nail (http:). Rather, we should work on ways of making knowledge associated with any arbitrary URI efficiently accessible in a global manner. Can HTTP with http: namespaces be made to work today? Sure. Will that meet all of our needs onwards into the future? Probably not. There are many and varied reasons to use URI schemes other than http: for namespace URIs (and for other applications as well) and we should not adopt short term solutions as official web archtecture which will discriminate against non-http: URI schemes in the future. Also in item 4, you say "when you use something whose most common application is retrieval, and you use it to identify something which has supporting definitive material, it is wilfully perverse not to connect the retrieval function with the supporting material." which I both agree with, and also consider to be a good argument for not using 'http:' URIs for *anything* which is not intended to be HTTP GETable, including abstract or non-digital resources, vocabulary terms, etc. etc. This is a very nice argument for URPs ;-) -- Item 5: I agree fully that namespace URIs should not be relative. I would go further and suggest that namespace URIs should not be URI references either -- but that's not core to this particular discussion, really. (BTW, your reference link gives a 404 error...) -- You say in item 6: "URNs are not effectively usable in the general population for retrieval of resources, URNs are not appropriate for use as namespace names." yet one very good reason for not using an http: URL as the namespace URI is due to the well known fragility of location-specific URLs. [and please, folks, no pointers to the all too well known "Cool URLs don't change" document, eh? ;-) While that certainly expresses some folks' views, and has some good points, it's certainly not a silver bullet to the URL fragility criticisms] Thus, while it is true that transparent, automated retrieval of URN denoted resources still has not become commonplace, that seems a rather weak and short sighted reason for excluding URNs as valid namespace URIs. Furthermore, you seem to presume that a "namespace document" is the only, or even preferred way to associate knowledge with a given namespace. As pointed out below, knowledge about a given namespace may be expressed (and likely will be expressed) outside the scope of control of a single particular "namespace document" and thus a mechanism which handles open, multiparty expression of knowledge (e.g. RDF) is a more optimal candidate for recording and accessing namespace associated knowledge. -- In item 7 you say "basic definitive material usually consists of syntax constraints on *THE* markup vocabulary identified by a namespace" (emphasis added). Well, while one could consider all terms ground in the same namespace a single vocabulary of sorts, it is not necessarily a functionally distinct markup vocabulary designed for a particular application. While most namespaces host only one functionally distinct vocabulary, there could be, in fact, numerous separate, possibly intersecting, functionally distinct vocabularies grounded in the same namespace, thus there is no absolute 1:1 correlation between namespace and markup vocabulary. Furthermore, each of those functionally distinct vocabularies would have their own discriptive information, not specific to the namespace itself, but to each vocabulary, therefore at most, the namespace would simply be associated with each such vocabulary and not with any documents describing the vocabularies themselves. Furthermore, each of those vocabularies may be used by one or more document models, and each document model would have its own documentation not specific to the vocabulary itself, but to the document model. Thus, what we really need are URIs for functionally distinct vocabularies (namespace URIs are not suitable) and URIs for specific document models (namespace URIs are not suitable) and a generic solution for associating descriptive resources (schemas, prose, software components, etc.) with specific vocabularies, document models, etc. independent of HTTP (though with the presumption that eventually, most if not all of the actual digital resources in question will be mapped to some http: URL for actual retrieval and use). We need a solution that takes into account the following facts: Namespace URI != Vocabulary URI Namespace URI != Document Model URI Namespace URI != Software Component URI Namespace N:N Vocabulary Vocabulary N:N Document Model Document Model N:N Schema Document Model N:N Software Component URI != 'http:' URL A note on the N:N relations: A functional vocabulary may have terms grounded in different namespaces, and a given namespace may host multiple functional vocabularies. A document model may utilize multiple vocabularies, each grounded in a different namespace, and a given functional vocabulary may be used by multiple document models. A document model may be defined by mulitple schemas, and one schema (excluding DTDs) may define multiple document models. A document model (or vocabulary) may be supported by multiple software components and/or implementations and a single software component and/or implementation may support multiple document models (or vocabularies). While short-term approaches such as RDDL may help us limp along for awhile until the more generalized solution is achieved, it should not be considered a suitable candidate for inclusion as part of the web architecture proper and its use should not deflect efforts and focus on finding/achieving a proper solution for these issues. -- In item 9, I agree that knowledge associated with a namespace (if any) is a collection not a single resource and thus whatever mechanism is used to associate that knowlege with the namespace should function similarly to a "directory". However... Namespace "documents" can only provide contextual information about the functional vocabularies grounded in that namespace, no more. Subsequently, each vocabulary may have "documents" which may relate which document models utilize that vocabulary, and subsequently each document model may have "documents" which relate which schemas, sofware components, test suites, etc. may be provided for that document model, etc. etc. recursively. The 1:1:1 correspondence between namespace, vocabulary, and document model is both artificial, not reflected in real world usage, and far to constrained to be widely useful or scalable over the long term. Finally, the relations from namespace to vocabulary, from vocabulary to document model, from document model to schema, etc. are likely to be inferential, not explicit. Just as a reused component in a modular archtecture does not track its parents (which would be a management nightmare) the minter of a given namespace may not be aware of all of the vocabularies grounded in that namespace (all issues of rights and authority aside), or the author of a given vocabulary may not be aware of all document models based on that vocabulary, nor may the author of a document model be aware of all schemas which define that document model, etc. etc. What is needed is a solution such as RDF which allows schemas to state which document models they define. Document models to define which vocabularies they use. Vocabularies which reflect which namespaces they are grounded in (automatically of course by namespace prefix). And -- are you ready -- document instances to state which document models they conform to! Finally, in addition to all of that relational knowledge, we then, of course, need to know where we can retrieve the various digital resources equating to or describing all of those architectural components. But the role of namespace URIs in all of this is very, very minimal and even insignificant IMO. The atomic functional components in the above scenario are functional vocabularies, not namespaces. Any 1:1 correspondence between some vocabulary and a namespace URI is just a coincidence, not a feature of the architecture. RDDL just doesn't capture the reality of these relationships, particlarly their hierarchical/recursive structure, and 'http:' URLs only come into the picture when you need to get a specific resource -- not as a fundamental key to identifying resources or for defining and utilizing their inter-relational knowledge. -- Item 11: I certainly can agree that accessibility of knowledge is very very important to empowering web users in many ways -- but as outlined immediately above, I don't see namespace URIs as the proper focal point for organizing such knowledge. It's is just one small piece of the solution (and a nearly irrelevant, non-functional piece at that) not the foundation of the solution. The foundation of the solution should be the globally valid and consistent denotation of resources by URI and the ability to describe those resources by associating knowledge with their URI and retrieve knowledge about those resources by their URIs. We need to account for the big picture, not just one single use case (e.g. RDDL + 'http:' namespaces). -- Item 12: Human-readable technical documentation is most definitely an important component of the development and use of web applications in general, but it is not just about what a namespace denotes (since, of course, a namespace denotes nothing ;-) but that documentation does not actually describe the namespace, but describes vocabularies, document models, schemas, software components, style sheets, etc.; none of which are equivalent to any specific namespace. Thus, I certainly agree with your sentiments here, but only because they apply to much broader scope than just this namespace issue. I don't see them, however, as compelling reasons for either the existence of namespace documents themselves nor for http: URLs as namespace URIs. -- Item 14: Agreed. Though this follows from the fact that namespaces do not equate to either a specific vocabulary nor to a specific document model -- and of course, even if they did, one could define the same document model in various schema languages, so it wouldn't make sense anyway for a namespace URL to resolve to a single schema instance. -- In summary, I find sum of your arguments to be very sound and valid reasons why we need an efficient, scalable, open (not author controlled), and global directory/registry solution by which we can define the identities of resources and their functional relationships in a formal manner so that both machines and humans can discover and utilize that knowledge effectively. But http: URLs and RDDL are not that final solution (even if they will offer some needed, albeit limited, utility in the interim). Regards, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@n...
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format