Re: Architecture Document: Terminology: Dereferencable, Retrivable, R esolvable.

Tim Berners-Lee wrote:
> I have used "dereference" to mean to "get that identified by" as in
> dereferencing a pointer. 
> ....
> In a computer system, you can dereference something which
> identifies a file or a document.

I understand that there is one point of view which says that URIs
*either* denote things that are retrievable (that can be "got") *or*
things that are not (e.g. persons, cars). (view 1) 

Then there is another point of view that says that URIs *always* denote
things that are not retrievable. You can never get the thing they
describe, only a representation of the thing. Doing a GET on a URI is
not dereferencing in the normal sense but the meaning is usually close
enough to make the distinction not worth making. (view 2) 

Above, you seem to say that you believe that some URIs are
dereferencable and some are not (view 1). Do you have separate
terminology for GET-ting a concrete resource like a file or document and
for GET-ting a representation of an abstract resource like a namespace?
Or do you use the word dereference in both cases but with separate
meanings?

Proponents of view 1 seem to argue that namespaces should not use HTTP
URIs because namespaces are abstract and cannot be "got". Doing a GET on
such a URI cannot be interpreted as "dereferencing" because the thing
you get back is different than the identified object. 

Proponents of view 2 seem to say that namespaces are no more or less
dereferencable than home pages. Both are abstractions which are not
retrievable in the usual English-language sense. Therefore HTTP URIs
make just as much sense as in any other context.
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/

Received on Monday, 15 July 2002 18:31:47 UTC