- From: Al Gilman <asgilman@iamdigex.net>
- Date: Fri, 03 Oct 2003 14:13:27 -0400
- To: "Williams, Stuart" <skw@hp.com>, "'Tim Bray'" <tbray@textuality.com>, "Roy T. Fielding" <fielding@apache.org>
- Cc: "Hammond, Tony (ELSLON)" <T.Hammond@elsevier.com>, uri@w3.org
At 09:01 AM 2003-10-03, Williams, Stuart wrote: >Tim, > > > So, as I understand it, 'info:' is just like 'urn:' except for: > > > > - For 'info:xxx:', NISO hands out the 'xxx' > > - There is no requirement for permanence or reference stability. > > > > This latter is I suppose why you wouldn't want to do 'urn:info:xxx:' > > which otherwise would work just fine. > > > > Is that oversimplifying? > >After ploughing through scads of email on this thread, I found it refreshing >to find such a well framed question. Regrettably, it seems to have gone >unanswered :-( Let me try to answer that one, at least. Yes, it is oversimplifying. The info: scheme resolves, in the scheme name, the car/document ambiguity that Patrick Stickler mentioned earlier. The urn: scheme does not. So far as I understand it. If it includes ISBNs as well as Dewey Decimal category numbers, then I am wrong. But I got the impression this was all about category designators. http://lists.w3.org/Archives/Public/uri/2003Oct/0019.html The proposed domain of the info: scheme if I understood it is for categories, known to be abstract concepts, and not documents or otherwise concrete utterances. Can someone from the NISO proponents of the info: scheme confirm or deny this interpretation? Al Long version: As I understand it, the info: scheme is being offered as not an omnibus ur-scheme for delegated naming, but as a merged naming scheme for a collection of similar concept pools. The commonality among all the concepts so collected is far stronger than that which obtains for urn: subdomains. We have heard two arguments against the 'info' scheme. One is "One ur-scheme is more than enough" The other is "All schemes existing primarily for the purpose of federating naming authority should be subschemes of the 'urn' scheme." Neither of these is, to me, convincing. I can see the community succeeding with either an urn: subscheme or collection of such subschemes, or with a novel top-level scheme. Let's look at the pros and cons for each, however. Let's take the second argument one first. Remember, DNS federates naming, as the http:-does-it-all voices have reminded us often. But my root argument is that there are two performance metrics that URIs are valued by: ease of recovery, and authenticity of communication. Most URI users want to support both in the services that they deliver over the web. There is a lively debate over the relative importance of naming and retrieval, but despite the differences in emphasis between advocates of the two performance metrics, the question "which is more important" cannot be answered completely until recovery time when the value system of the recipient is known. So it can't be the rule used for naming decisions. All we know is that the publisher wishes to support authentic identification and facile recovery with some concrete provisions in the URI or in the network services that handle that URI. In the URN case, it is ease of recovery that is dependent on services on the network more than on data in the URI. In the http: URL case, authenticity of the recovery is supported by network services -- PKI linking a signature in the body of the communication to an authentication argument involving a chain of certificates. In the case of an httpsy: YURL, we have data explicitly targeted to improving performance on both axes of performance: facility of recovery, and authenticity of communication. Even if this scheme isn't the answer, this is the way that URIs have got to evolve to grow up with the Internet. The presence of intelligent, hostile agents on the net has by now been well established, and the next wave of development will be more defensive against the actions of such agents than the waves up through DNS and the Web were. Authentic communication is what we will need to build more fundamentally into URI usage. This can be done today with http: scheme URLs with the network support of OpenURL schemas. Or almost fundamentally. Maybe fundamentally enough. Just as SOAP can run happily over HTTP even 'though in a way the capabilities in SOAP, had we had them then, would have made some of the features in HTTP unnecessary. In the case of the 'info' scheme there is a body of usage, some well-wrought community concepts like the Dublin Core Element Set, that would be better integrated into Web usage if they had an agreed linearization in the URI namespace. Functionally, this could be urn:dds:blah and urn:etc.:blah. urn: could be the syntax at the front of an info: URI just as "www." is the literal syntax at the start of a site address on the web. You know, the Web collapsed DNS into a flat space with structure siteAddress ::= 'www.' agglutenattedBusinessName '.com' ..but this is sub-optimal. It would be better to let this class float to the top of the syntax and give it its own top-level scheme. The internal consistency of the meaning of info: scheme URIs is far greater than the commonality that they share with other candidate urn: scheme applications. It's a matter of judicious source coding. 'Naming' is too flimsy a concept to be the sole connotation of the root segment (that is to say the scheme part) in the URI's construction. The URI language is to be practiced by a vary large pool of mostly-autonomous actors. Thus the 'technical factors' that Roy sees as absent are not the only factors to be considered in deciding what schemes to authorize. It is also important that the URI language, in Cranmer's terms, be "understanded of the people." For the class of things that would be named under the proposed 'info' scheme, a root scheme would be much better 'understanded of the people,' the people coining and interpreting these URIs, than would a branch of the 'urn' scheme tree. The stretch to see a common concept across both Dewey Decimal sorting buckets and Library of Congress sorting buckets is a stretch we can begin to believe we can get many people to master and generally apply right. The stretch to the abstract notion of "a name, any name" is far less amenable to popular understanding. I can see this domain of application being served competently either by embedding these sub-schemes in the urn: tree or by coining a new top-level scheme for this application. But on balance as far as I can see now, this domain would most likely be better served by a dedicated top-level scheme. This is not a show-stopper, just a leaning. But those are some factors that I think we should be considering, and that's my leaning of the moment. Al >Regards > >Stuart >-- > > > -----Original Message----- > > From: Tim Bray [mailto:tbray@textuality.com] > > Sent: 2 October 2003 18:58 > > To: Roy T. Fielding > > Cc: Hammond, Tony (ELSLON); uri@w3.org > > Subject: Re: Announcement: The "info" URI scheme > > > > > > > > So, as I understand it, 'info:' is just like 'urn:' except for: > > > > - For 'info:xxx:', NISO hands out the 'xxx' > > - There is no requirement for permanence or reference stability. > > > > This latter is I suppose why you wouldn't want to do 'urn:info:xxx:' > > which otherwise would work just fine. > > > > Is that oversimplifying? > > > > Eric Hellman outlined, quite clearly, the notion that the > > absence of a > > built-in dereference mechanism is an advantage for political reasons. > > While his sentences parse and I have to acknowledge that empirically, > > it's possible for a human to believe this, the whole notion that an > > identifier is better because non-dereferenceable just comes from a > > different planet thatn the one I live on. > > > > Like Roy says, let the market decide. > > > > I think, though, that if the URN fans and the doi: and info: and tag: > > people all got together in a room and came out with a reduced > > number of > > URI schemes, they and the community would be winners. > > -- > > Cheers, Tim Bray (http://www.tbray.org/ongoing/) > > > > > >
Received on Friday, 3 October 2003 14:15:52 UTC