And a little addendum: given that there will not be a good single
resolution for a url, it will surely become common to annotate a
resource with one or more "more info" predicates pointing to a URL (or
perhaps just a machine) that can be resolved in order to learn more
about the resource.
David Karger wrote:
> I agree with stefano that it is somewhat silly and annoying that
> people keep trying to spin off new naming schemes that are, at the
> bottom, completely equivalent to URIs---namely, they are opaque names
> that refer to arbitrary resources. About the only rationale I can see
> for this approach is that the question of who owns, ie registers,
> names is contentions and everybody wants to be a registrant. I think
> we could take a good insight from DNS here, and be better off using
> hierarchical namespaces plus delegation to address that problem;
> however, I am equally happy with a naming scheme that produces names
> that are gibberish nobody will fight over (md5:kjsfaga3258yu2hiuwiuw
> probably won't generate a lot of contention).
> However, I disagree with Stefano on the issue of resolvability.
> There's an important issue that people have circled in this discussion
> but not made explicit. On the web, with its urls, there is one place
> to resolve that url, and conveniently there is also one "owner" of the
> url. We go there to resolve the url because that location is
> authoratative regarding the url. Come the semantic web, names no
> longer imply authority---they are simply references. It is
> inconceivable that only one entity is going to want to talk about a
> given resource, and even more inconveivable that everyone will be
> happy if someone takes "authoratative ownership" of all the
> information about a given resource. Rather, different people will
> want to be free to make their own assertions about an name, without
> being subject to the censorship of an "owner" of the name, and
> different people will trust different information sources to provide
> valid information about the name. Thus, I don't see the idea of
> "single resolution mechanism" as being valid or useful. Rather, we
> are going to have to rely on assortments of spiders (ie, another level
> of indirection) to help resolve queries of the form "who can tell me
> more about the following resource". The answer to such queries may be
> a list of URLs (as opposed to URIs), as that is the appropriate moment
> to be pointed at a particular source of information. But it doesn't
> make any sense for a particular information source to be hard coded,
> either implicitly or explicitly, into the object name.
>
>
> Matthew Cockerill wrote:
>
>> "Sure it's useful as identification but completely useless for
>> discovery as I wouldn't know how to ask for more info about that URI."
>>
>> Yep - it's a floor polish, but most definitely is not a dessert topping.
>> From the Info URI FAQ:
>> http://info-uri.info/registry/docs/misc/faq.html#value
>>
>> "
>> Q. Why are info URIs non-dereferenceable?
>> A. info is focused exclusively on supporting identity [...]
>> "
>>
>> Theoretically distasteful it may be, but in my experience an agreed
>> on namespace for "identifiers" (independent of any question of
>> resolution) comes in very handy in practice when trying to make
>> different systems interoperate and correspond with each other.
>>
>> To do this, the info guys have had to add an extra layer onto the
>> existing URI namespace (and chosen this in favour of a URN based
>> solution) for what seem to me to be very valid practical reasons
>> (laid out in the FAQ).
>>
>> Explicitly avoiding the promise/threat of resolution seems like a
>> pretty good thing to me, if you're aiming to simply define an
>> identifier.
>> The XML and RDF worlds seems to be littered with URI-used-as-
>> identifiers where the URI 'kindof might be resolvable, but it might
>> not be, so try your luck, and it's also not necessarily defined what
>> will be delivered if you do resolve it - and also don't all try at
>> once, or the server it runs on will go down, and your enterprise
>> application will fail'.
>>
>> Matt
>>
>> On 13 Nov 2005, at 23:49, Stefano Mazzocchi wrote:
>>
>>> MacKenzie Smith wrote:
>>>
>>>> FYI, Tony Hammond at NPG pointed out to me that the info URI proposal
>>>> has received the blessing of the IETF and is now an Official Standard
>>>> https://datatracker.ietf.org/public/pidtracker.cgi?
>>>> command=view_id&dTag=10863&rfc_flag=0 NISO will maintain the
>>>> namespace registry and let's hope they set it up soon!
>>>> This will be a great help to us once the registry gets going as a
>>>> way to reference
>>>> things like PubMed records and published journal articles in a
>>>> standardized URI
>>>> kind of a way... we can even urge organizations like the Getty to
>>>> register their
>>>> vocabs so that we don't have to invent any more URIs!
>>>
>>>
>>>
>>> Hmmm, one step forward and two step backwards.
>>>
>>> This URI scheme is really a URN scheme and it's not able to locate
>>> anything.
>>>
>>> Sure it's useful as identification but completely useless for
>>> discovery as I wouldn't know how to ask for more info about that URI.
>>>
>>> Has the same exact problems that Handles, DOIs, LSIDs and all the
>>> other domain-specific IDs have: you need yet-another DNS system to
>>> get to the information, with no particular benefit if not the one
>>> that yet-another organization is in control of that addressing
>>> resolution space.
>>>
>>> While it's perfectly human that trust is clusterized and never
>>> global, it is also extremely frustrating, as a developer, to see
>>> such moves and, more important, to be considered as valuable for
>>> the ecosystem while they just introduce more work for no value
>>> other than more abstraction from the real problems.
>>>
>>> http://hdl.handle.net/1721.1/29466
>>>
>>> is as unique as
>>>
>>> urn:handle:1721.1/29466
>>>
>>> or now
>>>
>>> info:handle/1721.1/29466
>>>
>>> but with the first I know what to do to get more info out of it
>>> (and using HTTP content negotiation, I can ask for an HTML page or
>>> an RDF page) with the other two, I need to ask yet another DNS
>>> (which is currently unspecified!!) to give me a URL to locate that
>>> URI.
>>>
>>> Why? What is the benefit? that I can use another protocol rather
>>> than HTTP to get out information? why would I ever want that? HTTP
>>> is perfect for these kind of things! the simplest thing that can
>>> possibly work.
>>>
>>> If you want to talk about stuff, any identifier is equivalent.
>>>
>>> But if you want to build a semantic web, you need to be able to
>>> locate stuff or it's going to be utterly useless as a global
>>> coordination effort.
>>>
>>> I will sound like TimBL here but I really don't believe these non-
>>> dereferenceable URI schemes are really helping out.
>>>
>>> They sure remove the pressure from the domain name that is tasked
>>> to do the rereferencing, but this pressure is not gone, is just
>>> displaced... and hidden under a carpet of unspecified registry lookup.
>>>
>>> So, if I have to take
>>>
>>> info:handle/1721.1/29466
>>>
>>> transform it into
>>>
>>> http://info-uri.info/handle/1721.1/29446
>>>
>>> which redirects to
>>>
>>> http://hdl.handle.net/1721.1/29466
>>>
>>> which redirects to
>>>
>>> https://dspace.mit.edu/handle/1721.1/29466
>>>
>>> why is this better than starting out with
>>>
>>> http://hdl.handle.net/1721.1/29466
>>>
>>> directly?
>>>
>>> The usual answer in computer science is: if you don't know how to
>>> solve a problem, just add another level of indirection.
>>>
>>> That's how this "info" URN scheme feels to me.
>>>
>>> --
>>> Stefano Mazzocchi
>>> Research Scientist Digital Libraries Research Group
>>> Massachusetts Institute of Technology location: E25-131C
>>> 77 Massachusetts Ave telephone: +1 (617) 253-1096
>>> Cambridge, MA 02139-4307 email: stefanom at mit . edu
>>> -------------------------------------------------------------------
>>>
>
Received on Wed Nov 16 2005 - 13:47:56 EST