- From: Didier PH Martin <martind@netfolder.com>
- Date: Mon, 14 Feb 2005 15:56:27 -0500
- To: "'Roy T. Fielding'" <fielding@gbiv.com>
- Cc: 'Michael Mealling' <michael@neonym.net>, 'W3C TAG' <www-tag@w3.org>, colin.wallis@ssc.govt.nz, ferry.hendrikx@ssc.govt.nz
Hello Roy, > It could be, if the URN is tied to DNS and the people who mint the > URNs also have control over the associated DNS zone file. If that > system were deployed, it would make a URN a locator with DNS as > its resolution mechanism. I see no difference between that and > existing URI schemes aside from deployment. You are absolutely right, people extended the actual URL schema to do what they want. Other prefers to use a different specification which explains what a Uniform Resource Name is. A matter of choice. Exactly like before when we used OID or UUID to identify a resource on a net (ref: CORBA, DCOM, OSF PRC, ONC). Again, it's a matter of choices. The URN schema is more flexible than the URL schema. We can use other naming convention than the strict "/" delimitated path. There is obviously the procrustean resolution mechanism and fit everything into URL or to allow alternative naming schemas. URNs are simply more versatile than URLs. > I don't follow that reasoning at all. An http URI based on a DNS > hostname will indirect via common-place DNS address records and > depend on the addresses returned (any modern CDN can remove the > single points of failure for you). A URN resolved with DNS depends > on specially-crafted zone files and extended record caching, such > that it is dependent on each name server contacted. To remove the > single points of failure from that system requires every local > name server to be upgraded in addition to special-purpose DNS > load balancing (caching the entire DNS response instead of just > the addresses+TTL). Yes to resolve URNs with DNS you need to allow clients to dynamically change the record involved in the URN/URL translation. Then you may need a URL/IP translation. I agree with you, this involves two queries. Then some may be tempted to use URN/IP direct translation. Not a big advantage I concede. It remains the flexibility of the URN scheme in terms of naming convention left to the namespace administrator. Could be useful to port some actual naming convention on the web like for instance the facetted classification convention, the ISBN convention and so on and so forth. Otherwise they will have to retrofit their actual naming convention into the URL schema: a procrustean mechanism. > > > C) The information conveyed by the URN is as follow: the namespace is > > owned > > or is part of a name space identifier. Then all the names after that > > can > > follow different conventions as stated by the name space provider. It > > could > > be as well urn:nzl:registration(dogs)-1.0 > > Likewise for http URIs. Off course, since a both URLs and URNs are URIs. > > > D) Social factor: They increased their chances that people won't > > associate > > the URN to a document located on the web. > > That is true, and I consider it to be a negative difference. You are probably right for the web in general and probably wrong in some niche markets where porting their actual naming convention is an advantage. > > > Bottom line: a name has nothing to do with a > > location. It could be resolved to a location if the named thing is > > locatable > > on the net but this is not a necessity. It's a name. In contrast, a > > locator > > tells me _where_ (i.e. the location) is located something. It's all a > > matter > > of semantics. > > Sure, but if the thing being named is information that will be > used in an information system, isn't it natural to conclude that > it will be used as more than just a name? Isn't it easier to simply > use an existing information system with names that are every bit as > persistent as any system based on URNs-as-locators? Or we can look at it as they use their naming convention for off the web and still use the same for online access. Otherwise it requires to modify the naming convention for on-off line. For instance, take the following book naming convention ISBN: 0066214130. Any onfo about this book but this time on-line could be referred as urn:isbn:0066214130 or in a URL schema as: http://www.amazon.com/exec/obidos/tg/detail/-/0066214130/ref=pd_nfy_gw_nr/00 2-9269393-1065606?v=glance as actually used by Amazon. The former is more uniform for off-on line reference. Like I said, URNs are superior in certain niche market. Books are a good example of that. Now, can we say that from the social point of view one is easier to remember than the other? Maybe for some autistic persona but probably not for most of the people. So, we can say that in our last example, at least we have some consistency on "naming" things by keeping their name on both the on and off line world. Can URNs support all naming conventions. In its actual incarnation, no, and this is maybe the main criticism we can have about it. > I did not intend it to be scientific. There were many naming systems > that predated the Web and many that have been defined since the Web, > but none of them have succeeded beyond the scope of a limited group > of people who either were not given a choice or who whose grant > money was tied to their use. Metcalfe's Law is at best a principle > of economics, not a scientific argument, yet we have all seen it > in practice. I didn't say that the Web is perfect -- I said that > the Web is already deployed and already performs the only service > that they need. You are right, the web does a good but still partial job. It also needs to be improved. We just increased the reach and this not totally due to the technological merits. Do we should stick to the same web as today with all its goodness and limitations? Some are trying to go beyond its current limitations and make it evolve. > > > This is not a problem > >> that technology can solve, and so far the most persistent names > >> on the Internet are the ones that have the most usefulness. > >> Personally, I think my 12 years studying this particular problem > >> is more than sufficient to reach a conclusion, but you are free > >> to disagree with any of my conclusions. > > > > Roy, this time you use the authority argument. > > I merely responded to your ridiculous suggestion that I should > look at the problem again, completely ignoring the fact that I just > spent three years revising the URI specification and working on > Webarch (not to mention all of the other times I've written about > it going all the way back to MOMspider). I am just trying to save > them from the same costly mistake made by dozens of others. So, all your arguments are based on the deep investment you did on this schema. It's understandable then.... It's not the first time I see that in both the scientific and technological worlds. I also did the same error in the past sometimes. It's human, I can understand that. However, why the URNs would be a so bad enemy? It's a URI with its own advantages and limitations. It represents the advantage of allowing to port existing naming conventions. The other didn't necessarily made mistakes, it was simply that the social and economical situation was totally different than what made the web possible. Its even possible that these "mistakes" come back this time adapted to the new network realities just to resolve the actual "mistakes" that people are doing today. So let's call them simply "solutions" and let's not get our ego in the way Roy. I was too resistant to the URNs at first, but when I met with librarians and when they told me about the problem of adapting the facetted classification to the web I started to see that some niche need a naming convention adapted to their reality. The melting pot is not always the best solution Roy even if it is tempting at first sight to resolve the Babel tour syndrome. Look at the following URL and think if it makes it easier to locate or name something. Does it have any innate characteristics to make it easier to remember? http://www.amazon.com/exec/obidos/tg/detail/-/0066214130/ref=pd_nfy_gw_nr/00 2-9269393-1065606?v=glance And in which ways it is superior to urn:isbn:0066214130 ? Cheers Didier PH Martin
Received on Monday, 14 February 2005 21:07:00 UTC