>Ed, Pat
> Sorry to butt in here ...
>
> At one point the TAG was talking about a model
>involving transducers, that might help here:
>
>1. A URL is a name/symbol/identifier, that
>identifies a resource (something with a name)
>2. There are transducers (a.k.a. web servers)
>that can map an identifier to a representation
>3. Using the HTTP protocol to dereference the
>content of a URL amounts to interacting with
>that transducer to get a representation (bag of
>bits) of a particular resource (which it itself
>inherently unknowable except via pictures of it) (01)
Right. The thing returned in response to the
query is not the resource: it is a
*representation* of the (state of the) resource.
The resource stays where it is, being identified
by its URI, so that it can continue to respond in
the future. "REST" is an acronym for
REpresentational State Transfer (see
http://www.w3.org/TR/webarch/ and references
there for (lots) more on this) which sums up the
chief ideas of the model of Web architecture
being used here. (02)
Pat (03)
>
>This is where the time-varying function view of
>resources came from (I believe).
>
>Frank
>
>
>On Apr 17, 2007, at 9:59 AM, Ed Barkmeyer wrote:
>
>>Pat,
>>
>>Thanks again for the further clarification. I
>>will retract my pejorative comment.
>>
>>If I may summarize, there are two concepts at work here:
>> - the Internet transfer protocol endpoint
>> - the "sensible thing" at that endpoint
>>
>>The TAG is not able to define any clear
>>characteristics of the latter, but the
>>TAG does appreciate that it is somehow different from the former.
>>The TAG is
>>not comfortable using the term "resource" to refer to the latter, because it
>>is not clear that it actually exists, or that two different observers will
>>agree as to what the "sensible thing" at some endpoint is. So the TAG uses
>>the term "resource" to mean the/your/some
>>interpretation of the stream of bits
>>you get from the former when you GET it.
>>
>>The endpoint is (I think) what I meant by "location".
>>The "sensible thing" is (I think) what I meant by "resource",
>>and I agree with all the associated caveats.
>>
>>For my purposes, the interpretation of the stream of bits, as a collection of
>>information elements, is a distinct but related
>>concept. And that too needs a
>>term. I thought that was what the term "web page" referred to, but perhaps
>>the "web page" has a narrower meaning that is too closely coupled to the
>>implementation at the server end to be used for the contents "on the wire".
>>So if that is a "resource", then that problem is solved, but we still need a
>>term for the "sensible thing". Yes, the "sensible thing" will have a really
>>vacuous definition -- it is someone's conceptualization of the thing at the
>>endpoint.
>>
>>But there are common kinds of "sensible things" that are important, and we
>>need a general term that includes all of those, so long as it also contains a
>>bucket for "other". For example, we understand "static documents" and
>>"services" as principal subcategories. And we also understand that the
>>"resource" -- the bitstream returned -- for a "static document" may well
>>include a representation of the document, a document metadata set, a
>>collection of provider labels, a site menu, a collection of ads, and possibly
>>other things. And while the document is
>>static, some of the other stuff might
>>not be. But that is the difference between the conceptualized "sensible
>>thing" and the "resource on the wire".
>>
>>It is very important for the provider to think of the "content" of that web
>>page as all of that stuff, because some of the other elements relate to
>>presenting image, providing services beyond the document, and generating
>>revenue. And since I only care about some of that and ignore the rest, my
>>model of "content" for that page will be
>>different from the provider's. So we
>>may disagree substantially on what the "sensible thing" is.
>>
>>So, yes. There are lots of associated ideas here, and they are all a bit
>>messy. But it is to some extent "browser-based access" that muddies the
>>picture. I suspect that things will become a lot less messy when/where the
>>"service" model begins to dominate.
>>
>>-Ed
>>
>>--
>>Edward J. Barkmeyer Email: edbark@xxxxxxxx
>>National Institute of Standards & Technology
>>Manufacturing Systems Integration Division
>>100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
>>Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694
>>
>>"The opinions expressed above do not reflect consensus of NIST,
>> and have not been reviewed by any Government authority."
>>
>>
>>_________________________________________________________________
>>Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>>Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
>>Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
>>Shared Files: http://ontolog.cim3.net/file/
>>Community Wiki: http://ontolog.cim3.net/wiki/
>>To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (04)
--
---------------------------------------------------------------------
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 (05)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (06)
|