Re: What a URI means, was Re: erratum Re: resources and URIs

>> A principle of Roy Fielding's REST architecture is that you never  
>> directly
>> operate on the resource.
>>
>> http://www.ics.uci.edu/~fielding/pubs/dissertation/ 
>> rest_arch_style.htm .
>> see: 5.2.
>>
>> "resource: the intended conceptual target of a hypertext reference"
>>
>> Now I realize that discussing whether a remote galaxy might be part  
>> of an
>> information network gets pretty quickly obtuse, by the REST  
>> definition of
>> resource, a resource might indeed be a remote galaxy _identified_ by  
>> a URI.

Please try to keep in mind that the REST architectural *style* is a
model for an information retrieval system.  It is not a model of the
network-of-linked-resources, but of the process for interacting with
WWW resources according to instructions found in hypertext.  That is
why there is a disjoint between the terms used by my dissertation and
those used by the mix of people adding text to the webarch document.
REST resources are always information resources, not because the
resources are information, but because the system is designed to
retrieve information associated with any resource identifier.

> Well, that document also says (5.2.1.2):
> "REST components perform actions on a resource .."
> so if the remote galaxy is a resource then Web components can preform  
> actions on it.

REST doesn't care what the resource *is* aside from providing a
sameness over time that might be desirable as a link target (the
conceptual target). While it is certainly true that we cannot
"access" a remote galaxy, it is possible to access a conceptual
mapping of information observed from those galaxies.  The resource
in REST is the conceptual mapping, not the concept.  The concept
can exist outside the REST-based system and be uniquely identified
by the same URI outside the system.  Claiming that the URI cannot
identify both the conceptual mapping and the real thing outside
the information system is equivalent to claiming that your
social security number cannot be used to identify anything other
than your social security account.  REST-based systems use URIs
as indirect identifiers, even if they happen to identify
the same thing directly.

Meanwhile, we can access physical hardware operating in the real
world using an http URI, such as the robot arms that manufacture
cars.  We can act on them via http in the same way, albeit with
less fidelity, as we can act on our fingers though signals generated
by our brains.  We can't say anything about the "realness" of a
resource by inspecting the naming scheme of its URI.

If I hold up my hand with my index finger extended, people
interpreting the visible reflection of light from my finger
(its representation as received by their eyes) will comprehend
it as representing the number 1.  It is still a finger, but when
presented consistently in the appropriate contexts it has a
different meaning.  [*]

Now, consider taking a picture of my finger.  That picture is
a representation -- it doesn't have to be full fidelity to
represent either my finger or the number 1, though it does require
some metadata to indicate when the picture was taken.  Now I assign
two URIs, one for the state of my finger and another for the number 1,
and bind both within a server to that representation.  The
semantic requirement that REST has is that if someone applies GET
to the first URI they will obtain some representation of my finger,
whereas if they apply GET to the second URI they will obtain some
representation of the number 1.  REST doesn't care how, nor why.

If Sesame Street wants to link to my resource representing the
number 1, they had better use the second URI.

What is important here is not whether the machines can
distinguish between those resources, or even if the semantic
software can somehow determine their meaning by inspection, but
rather that Sesame Street gets what it wants.  They can find out
what the URI means by asking the authority, or by inspecting the
links that other people (especially me) create when referring to
the resource using that URI, or by interpreting metadata that
is provided by anyone (preferably the authority).  Frequently,
all this requires is looking at other hypertext anchors and
their surrounding text.

I hope that helps explain the issues.

....Roy

[*] The model presented in REST is based on a theory of human
     communication, not just a software design.  That was not
     included in my dissertation because it isn't something I
     wanted to defend.

Received on Friday, 25 July 2003 04:55:51 UTC