W3C home > Mailing lists > Public > xml-uri@w3.org > September 2000

Re: URIs-Resource relationships

From: John Cowan <jcowan@reutershealth.com>
Date: Thu, 07 Sep 2000 15:40:44 -0400
Message-ID: <39B7EF3C.32A6369E@reutershealth.com>
To: liberte@crystaliz.com, "xml-uri@w3.org" <xml-uri@w3.org>
liberte@crystaliz.com wrote:

> There is a sense in which URIs can be considered equivalent regardless
> of the resources to which they might refer.  This is looking at the
> characters of the URIs themselves and the low-level semantics of
> the rules that constrain the namespace.  E.g. treating a/b/../c as
> equivalent to a/c.

That works for URI references (in this case, relative URLs), but not
for URIs proper.  http://www.example.net/foo/../bar is not the same
URI as http://www.example.net/bar, even if a server might typically
return the same entity body.

> Nevertheless, we need to talk about resources that may have no
> URIs (we would do so indirectly, still by reference, but not by URIs).

This goes beyond what predicate logic demands: there is no standard
methodology I'm aware of for reasoning about specific but unnameable
objects.   Unnameable objects, yes (real numbers, e.g.), specific objects,
yes, but not both at the same time.
  
> Saying that two URIs refer to equivalent resources also says that
> any other URIs that we previously knew to be equivalent to either
> of those URIs (really the resources to which they refer) are now
> all equivalent to each other.  So it is saying something about the
> URIs, it seems, and not just the resources.

This is "specificational identity" vs. "objectual identity".  In the
former, "a = b" is an assertion about the *names* "a" and "b": they
refer to the same object.  In the latter, "a = b" is an assertion about
the *objects* named by those names: they are the same.  The latter IMHO
(and I am in good company here) suffices, and leads to clearer thinking.

> Some people might believe in that isomorphism, and one could probably
> build a self-consistent system around it, but I don't think it is
> useful to do so because it denies the reality that we (people and
> applications) use multiple identifiers to refer to the same thing.

I agree.

> I've got a page of elaborations if anyone is interested.

I am!
 
> Yes, this happens, but how does an application know about it?
> Is it specific to "urn:isbn:*" URIs only or can the same constraint
> be applied to other sets of URIs?  If so, how?

I don't know if you were here when I was talking about the "brick:" URL scheme
for identifying bricks by location, such as the foundation stone
of my house:  "brick:us:ny:nyc:manhattan:13_East_3rd_St:course1:stone1".
This is a perfectly good URI, and although it does not make sense
to apply the method GET to brick: URLs (since bricks lack a digital
representation) there are other methods that do make sense, given the right
transducers.

> Content negotiation is a process (part of a protocol), but it is
> not a declaration of relationships independent of a particular process
> for discovering those relationships.

Agreed.  However, your term "associated with" is rather vague.  Is an
HTML document "associated with" the pages it links to?
  
> One might define relationships between URIs such that
> you can tell just by looking at the URI (and a declaration about
> the relationships that should hold for the URI) that it's resource
> is contained in the collection of another resource identified by a
> URI computed from the first.    We already do this to a limited extent,
> by the way, with hierarchical http URIs.  And it's not a bad thing,
> in my opinion, it's a good thing.

I agree.  But encoding this relation into the syntax so that it cannot
be changed sounds like a Bad Thing.  RDF already has about-each-prefix,
which is practically useful though theoretically ugly.

> Actually, the point of my posting was that
> we need to talk about not only relationships between URIs
> and resources, but also relationships and properties of URIs
> and relationships and properties of resources.

I would still like specific cases where it is useful to talk about
properties of URIs.  However, we already have a machinery for talking
about them, if we want to.  Because a URI is a string literal,
it can be referred to by a meta-URI of the "data:" scheme, thus:

1)	The URI "http://foo.net" refers to FooNet's web site.
2)	The URI "data:,http://foo.net" refers to the URI "http://foo.net"

And so on.  We could also, if we wanted to, introduce the media type "text/uri"
and then substitute "data:text/uri,http://foo.net" into Example 2 above.

-- 
There is / one art                   || John Cowan <jcowan@reutershealth.com>
no more / no less                    || http://www.reutershealth.com
to do / all things                   || http://www.ccil.org/~cowan
with art- / lessness                 \\ -- Piet Hein
Received on Thursday, 7 September 2000 15:40:45 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Tuesday, 12 April 2005 12:17:25 GMT