W3C home > Mailing lists > Public > uri@w3.org > October 2003

RE: Announcement: The "info" URI Scheme

From: Hammond, Tony (ELSLON) <T.Hammond@elsevier.com>
Date: Wed, 1 Oct 2003 17:29:56 +0100
Message-ID: <54A600C436EA694581B93E4BD4D4788A06B73C27@elslonexc004.eslo.co.uk>
To: 'Eric Hellman' <eric@openly.com>, Patrick Stickler <patrick.stickler@nokia.com>
Cc: uri@w3.org

To endorse this last post by Eric Hellman, I'm forwarding a separate post
made to www-rdf-interest:


> And we are in the midst of uri crisis again !

This whole thread reminds me of Scott McNealy's position vis-a viz privacy
on the Net: "You have zero privacy anyway. Get over it!"

The same thing with URI dereferenceability: URIs do not have to be
dereferenceable: Get over it!

The "info" scheme merely seeks to identify information assets from public
namespaces so that applications can refer to these assets in a highly
standard (read "uniform") manner using URIs. Sure could be neat to add in
the hooks for some extra dereference functionality. But that's well beyond
the scope of the "info" URI scheme. All we are concerned with is
representing these information assets within the URI naming architecture -
nothing more.

So, the suggestions to basically a) misuse HTTP (which despite everything
still holds out the retrieval promise of GET, etc - it is after all a
HyperText /Transfer/ Protocol), and b)to deploy a DNS domain name for use by
third-party namespace authorities (a DNS domain over which they have no
admin control) are both untenable positions - as far as the "info" URI
scheme is concerned.

I see no crisis.



-----Original Message-----
From: Eric Hellman [mailto:eric@openly.com]
Sent: 01 October 2003 17:08
To: Patrick Stickler
Cc: uri@w3.org
Subject: Re: Announcement: The "info" URI Scheme

Let me try to articulate one of the unspoken reasons in favor of the 
"info:" scheme with respect to the "http://some.root.domain/" 

I think there is no argument that  the http-some-domain approach has 
the great technical advantage over info that it has a built-in 
mechanism for retrieving resources and descriptions. What this list 
may not immediately recognize is that this technical advantage can, 
in many situations, be a great political disadvantage.

In general, technological barriers are easily surmounted by 
technologist, but political barriers can be genuinely hard. By that I 
mean that getting people to agree on things (peacefully) is not 
easily arrived at by technological means.

The technical ability to dereference an http URI results in a grant 
of power to the owner of some-domain by anyone who uses some-domain 
URI's. The practical effect is that real people, real organizations, 
and real communities are less willing to go along with the use of 
some-domain uri's to reference resources. Regardless of how much the 
owner of some-domain is trusted,  there is a natural reluctance to 
delegate the power to de-reference. Potential users might try to 
impose specific dereferencing policies  on the some-domain owner (for 
example by legal means) that might be objectionable to other users of 
the some-domain authority.

The info scheme explicitly has no dereferencing capability. The lack 
of this ability makes it easier to get people and organizations to 
agree to use these uri's, and is in fact its signal advantage.

At the same time, there is absolutely nothing to stop the 
proliferation of "info" dereferencing services. Given that hundreds 
of libraries have already installed OpenURL "dereferencing services" 
(such as our product, 1Cate (http://www.openly.com/1cate/) and others 
such as SFX, LinkFinderPlus, O-link, LinkSource, Sirsi Resolver, 
etc., etc.) which will rapidly add support for  info uri's packaged 
in http urls, it seems likely that means for obtaining semantic web 
descriptions for info uri over http will be quickly supplied by 
market forces.

To sum up, with regard to the info scheme, less is more.


At 3:06 PM +0300 10/1/03, Patrick Stickler wrote:
>On 2003-10-01 14:45, "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com> wrote:
>>  While having some sympathy with Patrick here, I note that a new scheme
>>  is URIs not URLs neatly sidesteps the car/document problems.
>Which is simply a problem that must be solved, if the Web
>and SW are to progress...
>The tradeoff, having no easy means to obtain representations/descriptions
>of resources denoted by info URIs is IMO far greater a loss.
>Particularly when the resources denoted are fundamental terms
>used broadly in the classification of resources -- where the ability
>to easily obtain schema based descriptions of those terms for
>inference and other operations is a big win for applications.
>>  An info URI identifies a concept not a document about that concept.
>>  A similar http URL would be taken as identifying either or both
>>  on who you talk to.
>True. But one of them would be wrong ;-)
>And that's why I've been working hard on URIQA, so that such
>disagreements can be easily resolves by asking the web authority
>for an authoritative description of the denoted resource, which
>(hopefully) will include some rdf:type assertions.
>Rather than publish an insulated info: URI, an http: URI could
>be used and precise descriptions of the denoted resources published
>on the appropriate servers. E.g.
>    MGET http://lccn.some.root.domain/2002022641 HTTP/1.1
>where the server lccn.some.root.domain is managed by whomever
>is responsible for managing the LCCN namespace, and a request
>such as above would return RDF which explicitly defines the
>resource denoted by that URI.
>Thus, the owners of the namespace themselves can *still* avoid the
>document/car problem by employing a URIQA enlightened server
>which provides precise descriptions of the resources denoted,
>thus making it clear precisely what kind of resource it is.
>A new URI scheme that is not dereferencable is, IMO, a step
>backwards (or at best sideways), not forwards.
>It's the proverbial "hiding your light under a bushel basket".
>HTTP + URIQA offer a great table. Why not use it.
>>  Jeremy
>>  Hammond, Tony (ELSLON) wrote:
>>>>  Why define and manage the URI space outside the scope of the core Web
>>>>  and SW machinery?
>>>  Hi Patrick:
>>>  I have to query the question you put above. IMO the "info" URI scheme
>>>  full square within the core Web and SW machinery as articulated in the
>>>  latest Web Architecture Draft:
>>>  Architecture of the World Wide Web
>>>  W3C Working Draft 27 June 2003
>>>  http://www.w3.org/TR/webarch/
>>>  The domain of URI is more extensive than HTTP alone. I would 
>>>assert that the
>>>  actual domain of URI is the Web.


Eric Hellman, President                            Openly Informatics, Inc.
eric@openly.com                                    2 Broad St., 2nd Floor
tel 1-973-509-7800 fax 1-734-468-6216              Bloomfield, NJ 07003
http://www.openly.com/1cate/      1 Click Access To Everything
Received on Wednesday, 1 October 2003 12:30:35 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:43 UTC