- From: Sean B. Palmer <sean@mysterylights.com>
- Date: Sat, 4 Aug 2001 03:19:36 +0100
- To: "Roy T. Fielding" <fielding@ebuilt.com>
- Cc: <uri@w3.org>, <www-rdf-interest@w3.org>
> In my experience, a typical bookmarked URL will outlast > a URN. The reason is because unimplemented persistent > naming mechanisms go in and out of fashion. I agree with the gist of your arguement here: that it doesn't matter how persistent you say something is, it's the social usage of the identifier that gives it persistence. However, this conversation came from the topic of identifiers for the Semantic Web. Often, in RDF, you don't often expect a network entity to be returned from a particular term, because the semantics of it are coded into the processing tools (e.g. the built-ins in CWM). Thus, the persistence is still only as good as the implementation, but there is no particular benefit to using a URL, i.e. something that will give you a data representation of the resource upon dereferencing. Indeed, my argument is that because the DNS system is not all that stable (with domain takeovers, and money-crises a-plenty), a set of names that aren't based upon this is useful. Names that aren't necessarily expected to resolve to something could be useful too. > Persistence is not, and never has been, a function of the > syntax used to create the name. Apart from where the authority component for that syntax can be delegated away to other entities by "mistake", "force majure", "lack of money", or whatever? Also, I think that persistence is reflected in the syntax once it has been put to use for a while. People know that if they dereference an HTTP URL, 90%+ of the time, they're going to get a 200 O.K. response. > If you want persistent names, ask a library to > create one Would the W3C and PURL count as libraries? I trust these two organizations to provide persistent names, but only because I know their backgrounds, and that if someone took away their domain names, there would be an uproar. But I don't know that about any other server. Perhaps I can work it out given time, but often I will not trust a server, because most people really don't care about persistence to the lengths that (for example) the W3C and PURL do. And there comes another problem: how do I get people to trust the names that I create? I can't really, only by their experience with dealing with me. > [...] the syntax only determines how often the name will be > used. Making it a URN only reduces the name's scope of use. Surely the syntax that one uses for a URI scheme is independent of the scope of its implementation? I mean that just because I use a URN for a new scheme, that doesn't preclude me from building a successful range of tools that use the new scheme, does it? If we were talking about addresses here, I'd agree with you, but all I really want is a way to create a name that I know won't be whipped out from underneath me in a year or two. Heck, URLs could do it if domain names were persistent. But I also don't want people to necessarily believe that they're going to get some data back upon dereferencing whatever name I'm providing. viz. I don't want them to rely upon that. In the context of the Semantic Web, that can actually be a useful thing, although in the context of the "normal" Web, it often isn't. Of course, we still need addresses for all that RDF data :-) Above all, it should be noted that I'm essentially a pragmatist. I agree with you that mostly, URNs have a limited use, because people don't often need to agree upon a set of unique "names" rather than protocol bound addresses. XML namespaces confused the crap out of people in this respect, because for many, it was the first example of them needing to use a URL for a name. I don't know of any particular reason why an XML namespace cannot be a URN, and the only reason for it not being a URL is that it is more difficult to find URLs with a good quality of service. -- Kindest Regards, Sean B. Palmer @prefix : <http://webns.net/roughterms/> . :Sean :hasHomepage <http://purl.org/net/sbp/> .
Received on Friday, 3 August 2001 22:19:26 UTC