Re: infoURI standard officially blessed

From: Stefano Mazzocchi <>
Date: Mon, 21 Nov 2005 10:36:08 -0500

Alf Eaton wrote:
> On 15 Nov 2005, at 08:51, Stefano Mazzocchi wrote:
>> Alf Eaton wrote:
>>> Stefano Mazzocchi wrote:
>>>> I'd much rather invest on automatically dereferenceable URIs now and
>>>> avoid paying the discoverability price (not only the technical one
>>>> but also the social one!) later on.
>>> Stefano,
>>> Just as example, which dereferenceable URI would you use for the book
>>> "The History of Love", ISBN 0393060349, so that everybody would be
>>> able to use that URI as an identifier for that book?
> I was thinking about this again today, while reading Tim Berners-Lee's
> essay "What do HTTP URI's identify?"
> <>. Now, I don't know if he
> still stands by this point of view, but his point as I understand it is
> that HTTP URIs are designed to identify documents, rather than abstract
> (or physical) concepts - one conclusion being "the idea that a URI
> identifies the thing the document is about doesn't work because we can
> only use a URI to identify one thing and we have and already do use it
> to identify documents on the web.". This is also what I like about info
> URIs, where, for example, uri:info:pmid/16286011 identifies the abstract
> concept of a particular scientific paper, rather than
> which produces a document with information *about* the paper.
> That particular example is complicated by DOIs, where
> can produce a representation of the
> paper which is in fact the same thing represented by
> uri:info:doi/example/1111111, but this only works for examples where the
> object being referenced is available in its entirety in a digital form.
> It doesn't work for cars, for example (as in Tim BL's example), or
> holiday resorts, or restaurants. In those cases, it seems more
> appropriate to use an identifier which *isn't* HTTP.
> In your example above, points to a
> document *about* the book, but it doesn't point to the book itself.

We are back to square one: nobody here is saying that identification and
localization are the same thing. They are not and there is no debate there.

The argument on the table is whether or not the use of an identifier
*as-is* as a locator is useful or not.

The advantage of using HTTP-URIs as URLs is that you use the existing
web infrastructure (DNS+HTTP) for the dereferencing.

The advantage of using INFO-URIs is that they are "just" identifiers and
they can be created and used without people worrying about a direct
mapping on the resources they locate.

Alf, you are right, my URI was defective in the way that it does not
differentiate between the page and the book, so here is a new one:

and when you fetch that HTTP-URI as a URL, the #book part is not sent by
the browser to the server, and you content-negotiate, say, RDF, you get
a bunch of statements and one will contain the above HTTP-URI, so you
know what to do next.

Being a director of a group that tries to help to keep the web what it
is, in terms of openness and compatibility, I *strongly* feel against
new hubs and concentration of power being created and I see this
"info-URI dereferencing registry" as a huge one and my gut's reaction is
to be afraid of it.

It's not about being greedy, Tony, or thinking that one protocol is
better than another, it's about fear of change: you fear a change in a
space you are familiar with and don't see the value, I fear the same.

At the end of the day, I hope Postel's principle will apply: be strict
in what you send and be tolerant in what you receive.

And *this* is why the libraries, the internet and the web were successful.

The rest is just coping with complexity and one's own fears during a
phase transition, like that one that we both feel happening.

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 Mon Nov 21 2005 - 15:30:04 EST

This archive was generated by hypermail 2.3.0 : Thu Aug 09 2012 - 16:39:18 EDT