Re: Announcement: The "info" URI Scheme

I can appreciate the political/social issues you describe.

At the very least, I would hope to see a URIQA server (or comparable)
hosted at whatever Web server might be set up to serve information
about info URI registrants and their terms. I.e., if one cannot
have

   MGET http://ddc.some.root.domain/... HTTP/1.1

at least it would be a great service to the SW to have

   GET http://some.root.domain/URIQA?uri=info:ddc/... HTTP/1.1

So that precise descriptions of these important resources can
be easily obtained by SW agents.

Cheers,

Patrick


On 2003-10-01 19:05, "ext Eric Hellman" <eric@openly.com> wrote:

> Let me try to articulate one of the unspoken reasons in favor of the
> "info:" scheme with respect to the "http://some.root.domain/"
> approach.
> 
> 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.
> 
> Eric
> 
> 
> 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 that
>>>  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 depending
>>>  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.
>> 
>> Cheers,
>> 
>> Patrick
>> 
>> 
>>> 
>>>  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 fits
>>>>  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.
>>> 
>>> 
>>> 
>

Received on Thursday, 2 October 2003 02:59:35 UTC