Re: URI: Name or Network Location?

On Jan 23, 2004, at 12:44, ext Hammond, Tony (ELSLON) wrote:

> Hi Patrick:
>
>> There is no need to introduce yet another URI scheme just to handle
>> (more) persistent naming and redirection.
>
> I would just like to point out that INFO expressly excludes 
> dereference - so
> no redirection available. There are multiple reasons why we have 
> positioned
> INFO thus. I would invite you to consult the FAQ at
> <http://info-uri.info/registry/docs/misc/faq.html> which goes into the
> details of why we have made this design choice. Bottom line is that we 
> are
> looking for a lightweight scheme for conferring identity (alone) of 
> public
> namespaces onto the Web. We do not support the idea of overloading the 
> HTTP
> document retrieval functionality with an independent naming 
> functionality.
> (By retrieval I intend the full set of CRUD actions.) Also any 
> reliance on
> DNS is inherently fragile and unnecessary - and frankly confusing.

I've reviewed the above referenced FAQ and many other INFO related
materials previously. I honestly don't find any of the arguments
put forth there in favor of "non-dereferencable" URIs to be the
least bit convincing. There is *no* requirement that *any* URI
of *any* URI Scheme resolve to *anything*. Thus, there is no
imposition of all the extra overhead that is suggested if http:
rather than info: URIs were used. If owners of a given subspace
choose not to provide for any form of resolution, fine. Then they
don't. And those URIs simply act as names. But if later they
decide to provide either representations and/or descriptions of
the resources thus named, they can, with *NO* impact to current
usage.

I think it boils down to a fundamental disagreement about (a) the
utility of dereferencable names and (b) the reliability of DNS.

As for resolution of info: URIs. I can use DDDS or any proprietary
solution to resolve info: URIs to representations or descriptions
of the resources denoted, and that cannot be prevented. Furthermore,
I expect that such practices will be *typical*. What good is a name
if you can't say anything about the think it names? Surely there
will be labels, descriptions, and other information associated with
those info: URIs which describe the things named. Why deliberately
prevent systems from accessing such information *based* on the
name (URI) used? I just don't find that position to be reasonable
or useful.

As for DNS, I've yet to see a convincing argument that DNS is
inherently "unreliable" and results in URIs containing web authority
components having domain names as being "fragile". Saying it is so
does not make it so.

One can accomplish the same degree of long-term integrity offered
by URNs, DOIs, and INFOs with just a little bit of forthought and
common sense. C.f.

http://lists.w3.org/Archives/Public/uri/2003Jul/0005.html

>
>> I am personally saddened to see the info: URI scheme emerge
>> rather than a similar solution based on http: URIs,
>
> Without intending to be facetious, I also am personally saddened to 
> see all
> URIs collapsed to a single HTTP scheme.

I'm not asserting that. I never have. We need more than one URI scheme.

I am, though, asserting that the goals of the info: URI scheme can
be fully met by using http: URIs, and that the percieved/intended
constraint against resolvability of info: URIs is quite simply
an illusion.

> That would seem to me to be the
> undoing of URI as a generic identifier architecture. The possibilities 
> that
> URI presents as a federeated namespace for identifying resources is too
> great not to want to see it further elaborated so as to incorporate 
> legacy
> naming systems.

In principle, I agree, but not for the use cases set forth for info: 
URIs.

I know you and others have put alot of work into info: URIs, and believe
me, I'm *very* sympathetic to your goals and motivations. I just think
it is a big mistake to not use http: URIs to name all those very 
important
resources, so that if/as desired, those URIs can be used to access
important, authoritative information about those resources.

Regards,

Patrick


>
> Tony
>
>
>
>> -----Original Message-----
>> From: www-rdf-interest-request@w3.org
>> [mailto:www-rdf-interest-request@w3.org]On Behalf Of Patrick Stickler
>> Sent: 23 January 2004 07:38
>> To: ext Hammond, Tony (ELSLON)
>> Cc: ext Sandro Hawke; Thomas B. Passin; 'Phil Dawes'; ext Jeremy
>> Carroll; www-rdf-interest@w3.org
>> Subject: Re: URI: Name or Network Location?
>>
>>
>>
>>
>> On Jan 22, 2004, at 17:38, ext Hammond, Tony (ELSLON) wrote:
>>
>>>> It seems to me
>>>> that the most obvious way of addressing this is to use a
>> URI to denote
>>>> the thing (i.e. a name) and a seperate way of talking about the
>>>> numerous ways of locating information about it.
>>>
>>> Hence INFO, see <http://info-uri.info/> ...
>>
>>
>> There is no need to introduce yet another URI scheme just to handle
>> (more) persistent naming and redirection.
>>
>> http: based PURLs work just fine. As I've pointed out before, you
>> can accomplish all that you aim to accomplish with the info: URI
>> scheme by simply using http: URIs grounded in your top level
>> domain, delegating control of subtrees of that namespace to the
>> various managing entities per each subscheme (the same is true
>> of urn: URIs). Then each http: URI can be associated with an
>> alias to which it redirects, as well as allow for access to
>> metadata descriptions via solutions such as URIQA[1]. E.g.
>> rather than
>>
>>     info:lccn/n78890351
>>
>> you'd have
>>
>>     http://info-uri.info/lccn/n78890351
>>
>> thus providing just as robust and long lived an identifier (since
>> one would think that if info-uri.info dissappeared, so too would
>> all integrity for any info: URI) yet still allow existing web
>> protocols such as HTTP to be employed to provide access to
>> descriptions and representations; either directly or via
>> redirections of various sorts.
>>
>> Even if some particular info subscheme had no intention of
>> providing any representations or descriptions *now*, if ever
>> the decision were changed, it would be possible with *no*
>> impact to any usage of those URIs as names.
>>
>> I am personally saddened to see the info: URI scheme emerge
>> rather than a similar solution based on http: URIs, dispite
>> my appreciation that the definition of standardized URIs
>> for so many important vocabularies has been sorely needed
>> for far too long.
>>
>> Patrick
>>
>>
>> [1] http://sw.nokia.com/uriqa/URIQA.html
>>
>>
>>>
>>> Tony
>>>
>>>
>>>> -----Original Message-----
>>>> From: www-rdf-interest-request@w3.org
>>>> [mailto:www-rdf-interest-request@w3.org]On Behalf Of Phil Dawes
>>>> Sent: 22 January 2004 15:23
>>>> To: Patrick Stickler
>>>> Cc: ext Sandro Hawke; www-rdf-interest@w3.org; Thomas B.
>> Passin; ext
>>>> Jeremy Carroll
>>>> Subject: Re: URI: Name or Network Location?
>>>>
>>>>
>>>>
>>>> Hi Patrick,
>>>>
>>>> Patrick Stickler writes:
>>>>>
>>>>> Per your view, most URIs do not denote web pages, images,
>>>>> video streams, services, etc. but all denote "locations" and
>>>>> if we ever want to describe all those web-accessible resources,
>>>>> we need an entirely different set of URIs for them if we wish
>>>>> to talk about them.
>>>>>
>>>>
>>>> But surely the only reason this argument has weight is
>> because there
>>>> is usually only 1 way of retrieving that web resource* - i.e. HTTP.
>>>> Thus it becomes an attractive choice for naming it.
>>>>
>>>> If the web hadn't turned out the way it has, and there were lots of
>>>> protocols vying on equal footing for supremacy, then the
>> 'it's a name'
>>>> argument wouldn't seem so obvious. We would, as you say,
>> probably have
>>>> a way of talking about the web resource itself, and a
>> seperate way of
>>>> talking about the numerous ways of locating it.
>>>>
>>>> The problem now is that we are attempting to use HTTP URIs
>> to describe
>>>> abstract concepts and physical objects, and so the 'it's a name'
>>>> argument for HTTP URIs is suddenly non-obvious again. It
>> seems to me
>>>> that the most obvious way of addressing this is to use a
>> URI to denote
>>>> the thing (i.e. a name) and a seperate way of talking about the
>>>> numerous ways of locating information about it.
>>>>
>>>> Cheers,
>>>>
>>>> Phil
>>>>
>>>> * or the representation of that resource
>>>>
>>>
>>>
>>
>> --
>>
>> Patrick Stickler
>> Nokia, Finland
>> patrick.stickler@nokia.com
>>
>
>

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Friday, 23 January 2004 06:44:05 UTC