- From: Pat Hayes <phayes@ihmc.us>
- Date: Thu, 24 Jan 2008 01:19:17 -0600
- To: Alan Ruttenberg <alanruttenberg@gmail.com>
- Cc: public-awwsw@w3.org
- Message-Id: <p06230902c3bdeb4d2858@[192.168.1.2]>
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