Re: URIs-Resource relationships

This is an interesting commentary that I think deserves careful consideration.

I won't attempt to respond off-the-cuff...

#g


At 03:01 PM 9/7/00 -0400, liberte@crystaliz.com wrote:
>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
>liberte@crystaliz.com
>liberte@holonexus.org

------------------------------------------------------------
Graham Klyne                       Content Technologies Ltd.
Strategic Research              <http://www.mimesweeper.com>
<Graham.Klyne@mimesweeper.com>
------------------------------------------------------------

Received on Thursday, 7 September 2000 17:24:50 UTC