Re: Example for consideration: Resource versus Representation

At 12:11 AM -0500 1/24/08, Alan Ruttenberg wrote:
>On Jan 23, 2008, at 12:51 PM, Pat Hayes wrote:
>
>>At 11:34 PM -0500 1/22/08, Alan Ruttenberg wrote:
>>
>>>Are representations resources?
>>>
>>
>>They can be (anything CAN be a resource....), but its not usually 
>>very useful to want to treat them as resources, I'd say.
>>
>>>I have heard the argument that they are not. In this morning's 
>>>call I agreed to send an example I've been thinking about.
>>>
>>>Consider some Information Resource that responds to a request with 
>>>a Representation of type application/pdf.
>>>
>>
>>Wrong way to put it. You are making 'representation' into a 
>>category, but it should be a relationship. That thing you get back 
>>is required by the REST architecture to be a representation OF the 
>>IR. That is, whatever we call this thing you get back, it bears a 
>>webarch:represents relationship to the IR. Saying that doesn't say 
>>what kind of thingthe representation is, only that it represents. 
>>So we can (using this confusing language we all speak) nominalize 
>>this and say that it 'is a representation', but that shouldn't be 
>>taken to mean that this means (or at any rate, that it 
>>means usefully) that it is a category of Things called 
>>Representations.
>>
>
>I'm content with saying something isn't useful. What I find to be a 
>problem is the "can't be" which is what I hear.
>
>>>I save the response on my hard disk. Is the thing I have 
>>>(henceforth known as the file)  on my hard disk an Information 
>>>Resource?
>>>
>>
>>Yes.
>>
>>>If it is, when and how did it become one, having been only a 
>>>Representation until recently?
>>>
>>
>>When you stored it (in fact when you *created* that file, based on 
>>the byte stream you got back from the first resource; that byte 
>>steam being the actual representation of the first IR, if one wants 
>>to be pedantic.)
>>
>
>(and wants to use that crazy nominalization thing we do ;-)
>
>>Being a file, stored stably in a computer, it can possibly (see 
>>below) be given a URI. However, I see no way to give a URI to a 
>>byte stream.
>>
>
>True, but is this different that giving a URI naming "love".  What's 
>the problem naming a byte stream with a URI, if we can name a 
>person, process, property with a URI?

Well, no problem in semiotic principle, but I see no way to pin down 
such an intended meaning either by description or (still less) by Web 
architecture. I'd have some problems with a URi intended to refer to 
love, by the way. Is love a resource? Now there's a question.

>
>>
>>>If not, what happens when I move the file to a directory 
>>>(actually, I don't move the file, I make changes to directory 
>>>structures) that my Apache server can serve from. Can my server 
>>>respond to requests for Representations?
>>>
>>
>>No, because it doesn't know that this file represents anything, so 
>>such a request is meaningless. But it can still serve the file.
>>
>
>Not that I'm sure which sense of "represents" you are using here, 
>but even without knowing what it means, let me say two things: My 
>apache server doesn't "know" anything.

True, sorry I was using a common solecism. The server has ways of 
responding to a request for a file, for example, but it has no 
protocols or standard methods which allow it to do anything 
particular with a request for a thing called a Representation.

>And I know it represents, since I know that it once represents, and 
>I don't know how something that once represented comes to no longer 
>represent. Moreover I can write that down in a comment about the 
>resource and someone who read it could understand what I meant.

That doesn't help the server, though, does it?

Pat
-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Thursday, 24 January 2008 07:19:43 UTC