Resources and Identifiers

Daniel LaLiberte <liberte@ncsa.uiuc.edu> Fri, 21 February 1997 19:25 UTC

Received: from cnri by ietf.org id aa17584; 21 Feb 97 14:25 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa20544; 21 Feb 97 14:25 EST
Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id KAA29424 for uri-out; Fri, 21 Feb 1997 10:22:57 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id KAA29419 for <uri@services.bunyip.com>; Fri, 21 Feb 1997 10:22:54 -0500 (EST)
Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03155 (mail destined for uri@services.bunyip.com); Fri, 21 Feb 97 10:22:51 -0500
Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id JAA27629; Fri, 21 Feb 1997 09:22:42 -0600 (CST)
From: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id JAA09164; Fri, 21 Feb 1997 09:22:37 -0600 (CST)
Date: Fri, 21 Feb 1997 09:22:37 -0600
Message-Id: <199702211522.JAA09164@void.ncsa.uiuc.edu>
To: Dan Connolly <connolly@w3.org>
Cc: uri@bunyip.com
Subject: Resources and Identifiers
In-Reply-To: <330CE7B4.18C21C9E@w3.org>
References: <3.0.32.19970218151607.0080d4d0@hq.lcs.mit.edu> <199702201524.JAA11237@void.ncsa.uiuc.edu> <330C7650.6EF22561@w3.org> <330CB46B.FA8@parc.xerox.com> <199702202230.QAA22773@void.ncsa.uiuc.edu> <330CE7B4.18C21C9E@w3.org>
Sender: owner-uri@bunyip.com
Precedence: bulk

Dan Connolly writes:
 > Does it help if I quit using the term 'object' and say 'resource'
 > exclusively?

Not really.  By 'object', I mean bits or services, you don't know which.
'Resource' is more neutral regarding this distinction, so it is better.

 > Yes, all objects _do_ have addresses in smalltalk/lisp systems!

Constants (e.g. 42) are objects but they do not have addresses - they
have only value.  But let's leave the programming language analogy
aside for now.

 > > ... A single object could have multiple URLs, so
 > > different URLs do not necessarily mean different objects.
 > 
 > That's an interesting assertion. Is it the conclusion of some
 > argument, or just an assertion?

It is the conclusion of a fairly short argument.  Consider that a
document may have an http URL and an ftp URL for the very same
document.  The question is how do you, the client, *know* that it is
the same document?  You could do an md5 hash of what you get back if
it is static.  Some explicit metadata could specify that they are the
same.  Otherwise, you don't know.  When is an object really a replica
of an object?  In fact, each time you get bits in the result of a
request, you are getting a replica of some object (in my world view).

I suppose this problem with replicas is the reason you like to have
a reference to the object instead of the object itself.

 > But I don't think there's any universal concept of 'same
 > objects' other than 'objects referred to in exactly the
 > same way'.

Same bits means same object, but for a complex object, determining
that it has the same bits as another can be expensive (e.g. compare
two collections).  An explicitly declared equality relationship is
another way.  An operation for determining equality is another way.
Same identifier is yet another way.  But I think that we will have to
learn to live with multiple identifiers for the same object.

One relatively easy work around for dealing with multiple identifiers
is that the provider of a resource maintains a "preferred" identifier
that it tells clients about.  You could then compare what two
different identifiers refer to by comparing their preferred
identifiers.


 > > Another claim (sort of an opposite) can be made: if URL-of-A ==
 > > URL-of-B, then A is the same object as B.
 > 
 > Yes, URLs and resources are exactly 1-1, in both directions.

But, of course, the claim I made does not mean 1-1.

 > What I mean by directly observe is: know everything there is to
 > know about it. If I receive the sequence of bytes "abcde" then I
 > know everything there is to know about it.
 > It doesn't have any unobservable
 > state, or have any associated state that may change with time.

You may have all the state that determines its behavior (unless parts
of the state refer to other remote objects - this is a composite
object, not just a hypertext document), but you don't really "know"
what that state means, so it is useless for direct observation.  You
have to go through the operations on the object - the implementations
of those operations "know" what the state means.

dan