Re: URI: Name or Network Location?

On Jan 20, 2004, at 09:28, ext Jeremy Carroll wrote:
>
>
> Also worth noticing the difference between a URI (identifier) and a 
> URL (location).

Sorry to jump on this, Jeremy, but the 'L' in URL stands for 'Locator' 
not 'Location',
and (IMMHO) the only notable distinction between a URI and a URL is 
that a URI is
simply a name, with no other expectations as to what might be done with 
it, other
than to simply denote some resource (concrete, abstract, digital, 
imaginary, whatever)
whereas a URL is a URI (name) which can (potentially) be dereferenced 
to a representation
of the denoted resource using some protocol.

It may very well be that a URL can be used to denote a 'location' 
(since a URI
can denote anything) and that dereferencing it provides a 
representation of that
location (which may very well be the thing located at that location), 
but a URL
does not inherently (and I think rarely does in actual practice) denote 
an actual
web "location", per se. I'd argue that from a REST perspective, there 
is no such
thing as a "web location". To posit such a thing is to violate the 
essential
principle of URI opacity.

The distinction between a URI and a URL is a phantom, and often 
contextual. It's
a matter of usage. The fact that URI and URL have been used 
interchangably
for years is strongly indicative of this.

E.g. there may not exist any standardized, globally deployed protocol 
to resolve a
'blargh:' scheme URI to a representation, but some local system may 
implement such
a protocol, making such URIs behave as URLs within that system, even 
though for
most folks, they have no function beyond just being names (URIs).

Also, IMO, just because some particular URI scheme is tightly 
associated with
a globally deployed protocol which provides all the necessary machinery 
for
resolving URIs that are instances of that scheme to some 
representation, that
doesn't mean that one *must* provide a representation for every resource
denoted by URIs of that scheme.

Thus, it's perfectly acceptable to use 'http:' URIs to denote abstract 
resources
having no representations provided (at the moment) and to use those 
URIs in
e.g. RDF statements to denote those abstract resources. HTTP GET 
requests
will return a 404 status, but so what. That doesn't mean they are not 
valid
http: URIs; simply that no representations are (presently) available. 
The owner
of such a URI may later decide to provide a representation (or cease to 
provide
one) without any impact to the denotation of the URI or its use as a 
name for
the resource denoted.

What that boils down to is that there is no need whatsoever to use 
URIrefs
with fragment identifiers. Ever. And the SW will be a happier place for 
it.
(but I digress...  ;-)


> Of course when given something like an ISBN number there is no 
> protocol (urn scheme) and it clearly is not a network location but a 
> name.
>

The distinction between URNs and other forms of URIs is orthogonal to 
the
distinction between URI vs. URL. And in fact, officially, there is but
one URN scheme and "urn:" is its prefix...

The original motivation for URNs (as I recall) was to decouple names
(URIs) from distinct web authorities based on DNS (supposedly because 
DNS
based URIs were too fragile for long term use) -- putting in its place
a scheme-dedicated infrastructure for partitioning and managing the URI
scheme's (or subscheme's) namespace.

Whether a URN acts as a URI or URL is another matter entirely.

A URN can (and usually does) act as a URL. Its just that HTTP is not 
used
to resolve that URI to a representation, but some other protocol 
(typically
proprietary and often system-specific, despite the emergence of DDDS). 
But
in contexts where URNs resolve to resources, they are URIs acting as 
URLs.

Folks should, IMO, talk strictly in terms of URIs, and particular URI
schemes, and simply refrain from using the terms URL or URN, as they 
don't
have any consistent functional significance in a REST based 
architecture.

There are simply URIs, which are names, which can denote anything that
one might wish to give a name to, so one can refer to and talk about
that thing, and a URI *might* (but does not have to) resolve to some
representation of that thing, and if so, one can consider the URI as 
acting
as a "locator" of that thing, such that one can locate a set of 
representations
of that thing via which one can access that thing and interact with 
that thing
via its representations.

But URL and URN should simply fade from folks vocabularies.


> Tom's summary was nice, I thought.

I agree. Though I'm not sure that RDF *needs* to make a distinction 
between the
three use cases Tom describes, since in all three cases, the URI simply 
is a
name denoting some resource, and whether one can dereference that URI 
to get
a representation of that resource, and whether that representation 
happens to
be a bit-equal copy of the resource (*is* that resource, in the case of 
a
distinct digital resource), and/or whether that representation contains
information of some sort that helps a machine or human understand the 
actual
denotation of the URI in question -- the URI simply names the resource, 
and
that's all RDF cares about.

Cheers,

Patrick


>
> Jeremy
>
>
>
> Thomas B. Passin wrote:
>
>> Stephen K. Rhoads wrote:
>>>
>>> I am working on an ontology to describe streaming media and find 
>>> myself
>>> unable to get my head around whether a dereferenced URI of a "typed"
>>> resource should result in a bit of RDF metadata or the data of the 
>>> resource
>>> itself.  In other words, is the URI specified as the value of the 
>>> rdf:about
>>> attribute "just a name", or is it to be interpreted as the "network
>>> location" for the data/resource/object itself?
>> There have been many threads on this, and a search for them will be 
>> useful.  The brief answer is "just a name".... BUT ....
>> There are several possibilities -
>> 1) The URI is "just a name" BUT conveniently happens to point to some 
>> useful information about the URI.  This can be a useful convention.
>> 2) The intention is to make a statement about the resource at the 
>> dereferencable URI itself.  For example, a statement about the 
>> designer of a web page.
>> 3) The resource referenced by the URI exists, and contains relevant 
>> information that identifies or specifies the thing denoted by the 
>> URI.
>> The problem is, there is no way in RDF to distinguish between these 
>> three cases.  Strictly speaking, the URI is just a name.  The best 
>> bet, IMHO, is to use special properties whose objects are 
>> dereferenceable URIs, when you want to capture the intent of 2) or 
>> 3).  1) is a convention you may want to follow.
>> Topic Maps in effect behave like this recommendation.
>> So yes, they are "just names".
>> Cheers,
>> Tom P
>
>
>

--

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

Received on Tuesday, 20 January 2004 03:42:04 UTC