Re: uri, urn and info

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

> Our experience with  an http based dereferencing system for isbn,
> ticker, and journal articles (linkbaton) showed us that in the real
> world, web site producers are seldom willing to give up control over
> uri resolution, even if you pay them to do so.

It's hard to say much about that, since I have no idea
what the linkbaton system was like, or the business needs of
the content producers.

I don't really understand what you mean by "giving up control",
unless you mean that the primary URI the people use to denote
the resource in question is in a namespace they
do not control.

Yet if they think they are gaining greater control by the use
of a non-dereferencible URI, that is an illusion. As you show
below, one can define any number of redirection proxies or
dereference services which "take control" away from the content
owner if people use those indirect URIs more often than that
minted by the content owner. And in the future, one could use
DDDS or similar protocols to add after-the-fact direct resolution
to any URI. There is *no* added control or benefit to the
fact that a given URI is, at present, non-dereferencable.

No matter what kind of URI is used, if the most commonly used
URI is not minted by them, in one of their namespaces, they
have no control over its interpretation. Period. End of story.

So if the NYSE is willing to support an info: URI denoting
their ticker, they should just as willingly support an http:
URI, minted/controlled by the ticker subnamespace registrant,
and they lose no more control over their site in the case of
the http: URI than they do for the info: URI.

However, the http: URI greatly facilitates resolution by
redirection to an NYSE specific URI, without any special,
otherwise *unknown* resolution services or any new resolution
protocols, etc.

> However, they have been rather more willing to adopt a identifier
> resolution architecture that looks like:
> 
> http://customers.own.resolver/?id=x-info:ticker:nyse:TWX
> 
> with a default of no link or
> 
> http://producers.default.resolver/?id=x-info:ticker:nyse:TWX

There are two serious problems, IMO, with this approach (in
addition to the above mentioned fact that any greater control
it seems to offer the content owner is an illusion).

1. When one only has x-info:ticker:nyse:TWX one does not know
   from *which* server to ask for information about the resource
   denoted by that URI. Should we then construct and deploy a
   global registry for the purpose of resolution? Why? Since
   that's what HTTP already provides.

2. Even if one is able to locate servers which can provide
   a dereferencing service for that URI, one does not know
   which of those is the *authoritative* source of information.
   Again, some registry will have to say which source is
   authoritative. Yet HTTP URIs with web authority components
   already provide that clarification.

As for providing a means of 3rd party resolution, one could just as
well use http: URIs and provide those as input to a service:

http://producers.default.resolver/?id=http://ticker.info.niso.org/nyse/TWX

allowing for either direct or indirect (3rd party) dereferencing.
If you want direct resolution, do

GET http://ticker.info.niso.org/nyse/TWX HTTP/1.1

If you want indirect, 3rd party resolution, do

GET http://{SOME_SERVICE}?id=http://ticker.info.niso.org/nyse/TWX HTTP/1.1

The URIQA servlet interface provides similar support for accessing
3rd party descriptions rather than the authoritative description
acessible from the web authority of the URI itself. E.g. for an
authoritative description, do

MGET http://ticker.info.niso.org/nyse/TWX HTTP/1.1

And for a 3rd party description, do

MGET http://{SOME_SERVICE}?uri=http://ticker.info.niso.org/nyse/TWX HTTP/1.1

E.g.

http://sw.google.com/URIQA?uri=http://ticker.info.niso.org/nyse/TWX


> so based on the observed behavior of the uri "market", the absence of
> inherent dereference is a selling point to large market segments.

It's an illusion. If it's a selling point, then the market doesn't
know what it's buying.

> You 
> can be a pessimist and say that this will cripple everything, or you
> can be an optimist and say, gee, maybe we can actually get this whole
> semantic web thing flying even on one wing.

I like to think that I am quite optimistic about the semantic web,
and also realistic about what it will take.

Holding the view that the info: URI scheme is not the optimal way
to denote resources does not at all make me a pessimist about
the SW. I am, of course, a pessimist about the utility of the info:
URI scheme (of which I see none at all).

One can say they are optimistic about jumping their 1967 Chevy
Ipala over the Grand Canyon, but bystanders may use other
adjectives to describe the driver than "optimistic" ;-)

> Eric (an optimist)

Patrick (also an optimist)


> 
> At 8:54 AM +0000 10/9/03, Patrick Stickler wrote:
>> x-info:ticker:nyse:TWX
>> 
>> (the persistence issue aside, for the moment)
>> 
>> Here is a prime example of why an http: URI
>> would be a far more useful means of denotation
>> than an info: URI.
>> 
>> If the above were rather, e.g.
>> 
>> http://ticker.info.niso.org/nyse/TWX
>> 
>> Then web users could (potentially) obtain
>> a representation of the current state of the TWX
>> ticker simply by dereferencing it (with probable
>> redirection from ticker.info.niso.org to a NYSE
>> server) without any change to the present,
>> globally deployed web infrastructure.
>> 
>> That doesn't mean the URI *has* to resolve to
>> anything, but deciding whether it does, and if
>> so, to what, is not affected by the URI itself.
>> And if decided at first to provide no representations,
>> a change to that decision has no impact on either
>> its denotation or its non-resolvable usage to date.
>> 
>> Likewise, SW agents could (potentially) obtain
>> (by means of a standardised solution such as URIQA)
>> an authoritative, formal, RDF description of the
>> denoted resource, which could include the state
>> of the ticker expressed precisely, suitable for
>> inference engines to e.g. deduce whether one
>> should buy or sell ;-)
>> 
>> But "hiding" the denoted resource behind an info:
>> URI (even if it can eventually be "found" via ad hoc
>> resolution schemes)  is hindering, not helping, the
>> web and SW.
>> 
>> Regards,
>> 
>> Patrick
>

Received on Friday, 10 October 2003 06:42:18 UTC