Re: My action item on Moby Dec, issue 14, etc

Tim Bray writes:

>> Some URIs can also be dereferenced to yield 
>> a representation.  The workings of none of 
>> these operations are affected in the slightest 
>> by what a resource "is", granted only that the 
>> implementor bears in mind that what they're 
>> getting is a representation, with the 
>> limitations that implies.

I find a lot to like in what you've written overall, certainly in its 
focus on the practicalities of what can and cannot be known. 

That said, the quote above does give me some pause:  in practice, HTTP and 
REST put quite a bit of focus on mechanisms that enable cacheing, 
aggressive prefetch, and so on.  By their nature, these operations make 
assumptions about the relationship between successive accesses to, you 
should excuse the term, "the resource named by a URI".

When a server first supplies a representation, and marks it cacheable, I 
think that is creating a contract that affects future accesses to 
something.  I think that something is, in practice as well as in theory, 
"the resource" identified by your URI.  So, in this sense, I think your 
"weather/cat" whimsical resource must have some existence as one unified 
thing.  Specifically, whenever you serve up the weather, you presumably 
want to set the "don't cache me, >I< might be a cat next time" bit.  The 
"I" in that phrase seems like it's what's behind the URI. 

There may be other examples.  I agree that we can't and shouldn't keep 
owners of URIs from causing them to range over a supprisingly wide range 
of data that might collectively represent a (whimsical) resource.  I'm 
less convinced that there isn't, at least in some sense, a single 
abstraction that is indeed an observable resource behind even such oddball 
URIs.  Thanks!

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Thursday, 19 September 2002 09:33:25 UTC