- From: Graham Klyne <gk-lists@dial.pipex.com>
- Date: Thu, 07 Sep 2000 21:13:46 +0100
- To: liberte@crystaliz.com
- Cc: uri@w3.org
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