RE: URI: Name or Network Location?

It would be helpful if you guys could frame some of your responses in terms
of the real-world example I have provided.


-----Original Message-----
From: Patrick Stickler
To: ext Sandro Hawke
Cc: www-rdf-interest@w3.org; Thomas B. Passin; ext Jeremy Carroll
Sent: 1/21/04 9:45 AM
Subject: Re: URI: Name or Network Location? 



On Jan 21, 2004, at 15:07, ext Sandro Hawke wrote:

>
>
>> 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.
>
> In my experience, the association between URIs and web content is more
> mutable than seems appropriate for the "naming" relationship, and more
> like the "location" relationship.  So, you can talk about an image "no
> longer being named URI1" and "now being named URI2", or you can talk
> about it "being moved from URI1 ro URI2".  Either works.  Do you use
> "mv" to rename files, or "rename" to move files?  *shrug*
>

I expect that there will always be an aspect to URIs that reflect
accessibility as it is difficult for folks to keep the syntactic
characteristics of the URI which are relevant to resolution separate
from the more fundamental naming characteristic of a URI.

If you have some URI which is e.g. a PURL, and the alias to which
that PURL redirects changes, noone says that the resource has
moved, if all they ever use is the PURL to talk about it. Yet
the actual physical location of the representation in question
has changed.

Likewise, one could modify a URI syntactically, yet treat it
as an alias of the original, resolving to the same representation in
precisely the same manner (i.e. mapping to the same "location")
and yet without any semantics or storage location changing, folks
will say the resource "moved" from the former URI to the latter.

Perception is a tricky thing. That's why we need tight, consistent
models that help us distill all of the myriad perspectics down to
an essential core of functional requirements which allow our solutions
to be resilient to change when those changes are not relevant
to the central model (even if they affect various perspectives).

Thus it is quite true that user perspective may in many cases
reflect a location-based metaphor, irrespective of what is actually
happening, either semantically or with regards to structure or
organization.

It is therefore even more important that those architecting the
web and SW and building the systems have a clearer, consistent,
and common perspective of what is minimally essential for these
systems to effectively interoperate, even if
for various usability reasons, it may be useful to pretend
that things are different because it makes understanding and
interacting with some particular service easier.

So while users in various contexts (or even developers in
various contexts) may find it useful to think in terms of
locations and addresses -- web agents, SW agents, and other
core bits of the infrastructure can be designed and deployed
to more effectively interact in terms of a more generic,
flexible, and resilient perspective based on names of
resources and protocols to resolve those names
to representations of those resources.

While the metaphor of locations or addresses is useful
in many ways, I do not consider such a view
to be optimal, or even sufficient, for describing the
fundamental web and SW architecture, and the more generic
view of names which resolve to representations (irregardless
of the location or other nature of existence of the thing
named) will be a cornerstone of the future.

Cheers,

Patrick

--

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


Note:  The information contained in this message may be privileged and
confidential and protected from disclosure.  If the reader of this message
is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified
that any dissemination, distribution or copying of this communication is
strictly prohibited.  If you have received this communication in error,
please notify us immediately by replying to the message and deleting it from
your computer. Thank you.  ThruPoint, Inc.