Re: Resources and Identifiers

Dan Connolly writes:
 > [I started by saying that I find it useful to regard
 > each resource as the referent of exactly one URL,
 > by definition. It's not really possible to make
 > and refute arguments when we don't agree on the definition of
 > terms. So this is a goofy dialog. But I don't mind...]

I'm glad you don't mind.  It is good that we at least know we are
looking at things differently and we can qualify terms to avoid
getting confused.  You might claim "resource" to necessarily have an
identifier, and I might go along with that (I'll try).  But "object"
is too generic to be tied down to that detail.

 > Daniel LaLiberte wrote:
 > > 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.
 > 
 > Whoa... you just assumed the conclusion!

OK, I wasn't clear.  There are two senses in which this is not
circular.

If by "document" we mean the object you get back rather than the
remote resource, then two objects can be identical that *resulted
from* two different resolutions.  Even the same URL resolved two
different times might result in different objects, even though the
remote resource is "the same" for both.

The other sense in which the document can be the same for two
different URLs is that the provider knows that they refer to the same
internal document.  The client may get slightly different results by
using each of the URLs, or perhaps the ftp server is unavailable.
But they still reference the same resource in some important sense.
The client would have to be told that they are the same, and it may
not believe it even so.

 > By the definition I find useful, the resource (object, document,
 > whatever) at ftp:... is distinct from the resource at
 > http:...

The resources may be different, yes.  But the bits you get back from
both resolutions may be identical.  Another time, the results might be
different, or you might not have access to one or the other resource.
So it is not correct to infer from identical bits that the remote
resources are identical.  I think we are in agreement on all of this.

 > >  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).
 > 
 > In the general case, objects have state. I would expect
 > replicas to share state (mostly -- they might be only weakly
 > consistent). When you get a result, you get a snapshot
 > of the state, not a replica.

Well, a "snapshot" is another name for an "entity" I think.  I want
that snapshot to be an object too, but (we agree) this object is not
necessarily the same object as the remote resource.  My above claim
that you get a replica of some object as the result of a request is
misleading.  The object it is a replica of is another identical
snapshot, and perhaps it is the only instance of its kind and so it is
not a replica of anything.

Also, I agree that replicas of resources might be only weakly
consistent with each other.

 > When are two resources replicas of each other? When you
 > get metadata (that you trust) that asserts "resource X
 > is a replica of resource Y." ala:

I agree that you have to get some declaration that two resources are
replicas.  (But it is possible to infer that relationship from other
declarations, such as declarations about each of the components of the
resources.)

 > > .. But I think that we will have to
 > > learn to live with multiple identifiers for the same object.
 > 
 > Er... we're writing the specs, no? We don't _have_ to live
 > with anything except what we agree to live with.

True, but we can't avoid the need to support providers who want to
declare that multiple identifiers map to the same resource.
Replicas are a case of this in which the replicas are at different
locations with different URLs.

dan

Received on Friday, 21 February 1997 18:03:08 UTC