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 Tue Nov 15 2005 - 22:27:44 EST