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

Re: URIs-Resource relationships

From: <liberte@crystaliz.com>
Date: Thu, 7 Sep 2000 15:01:23 -0400
To: John Cowan <jcowan@reutershealth.com>
Cc: "xml-uri@w3.org" <xml-uri@w3.org>, uri@w3.org
Message-ID: <20000907150123.B22962@crystaliz.com>
On Thu, Sep 07, 2000 at 01:12:01PM -0400, John Cowan wrote:
> liberte@crystaliz.com wrote:
> >
> > What we need is a way of specifying things such as the following:
> (dum dum dum) Hello Frege / hello Russell / Here we are at / Camp Befuddle ...

There are a bunch of interesting philosphical issues that tend to come up,
but just as philosophers try to make mathematically clear statements out of
otherwise fuzzy concepts, I believe we can do a similar job here.
Avoiding the issues up until now was fine partly because there has been
a lot of basic infrastructure to get out there before anything more
complex mattered.  It is starting to matter more and more.

> > * A specific set of URIs that all map to the same resource by some
> >   measure of equality.
> > 
> > * A general set of URIs, or URI patterns, that may be assumed to
> >   map to the same resources.  e.g. "case doesn't matter for us"
> These can be achieved by defining "=" for resources.  Just as 2+2 = 4
> means that the referent of the expressions "2+2" and "4" are the
> same object (is the same object?), so the same can apply to
> ftp://ftp.unicode.org/Public and http://www.unicode.org/Public,
> both of which are directory resources.  Note that "=" is just the
> smallest equivalence relationship between resources as between
> numbers; you don't need to talk about relationships between URIs
> as such at all.

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.  

We can talk about the equivalence of resources independent of the
URIs that refer to them, but the tricky bit is that you can't even
talk *about* the resources without referring to them in some way.  
Nevertheless, we need to talk about resources that may have no
URIs (we would do so indirectly, still by reference, but not by URIs).

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.

> However, it still seems to be official that the relation between
> URIs and resources is an isomorphism.

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've got a page of elaborations if anyone is interested.

> > * URIs that are mapped to no internet representation but still
> >   somehow identify an abstract resource.
> No special situation:  urn:isbn:1565921496 refers to the 2nd edition
> of the Camel Book, which has no Internet representation.

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?

> > * Resources that are associated with multiple entities, which may
> >   or may not have their own URIs.
> That is content negotiation.

Content negotiation lets a client say what kind of entities it wants,
or lets a server say what kind of entities it has,
but does content negotiation necessarily have anything to do with 
identifying the individual entities?  

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.

> > * Resources that are collections of other resources.
> > 
> > * Resources that "contain" other resources.
> > 
> > * Resources that will always have only one bit representation.
> These are ordinary resource properties, not properties of URIs.

So you say, but let me see if I can mix it up a bit.  

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.

Knowing that a resource doesn't change means you don't have to resolve
its URI again.  But I can't make any more of that argument :-)

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.  We don't have a 
good language for talking about any of that yet, and it is basic
for building anything more complex in a way that does not resort
to application-specific hackery.  Various XML specs are starting to
hack away at the larger problem, so to speak, and RDF has some promise
of being able to address it, but we are only at the pre-beginning,
recognizing the problem.

Daniel LaLiberte
Received on Thursday, 7 September 2000 14:59:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:44 UTC