Ed, Pat
 Sorry to butt in here ...  (01)
 At one point the TAG was talking about a model involving 
transducers, that might help here:  (02)
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)  (03)
This is where the time-varying function view of resources came from 
(I believe).  (04)
Frank  (05)
On Apr 17, 2007, at 9:59 AM, Ed Barkmeyer wrote:  (06)
> 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
>  (07) 
_________________________________________________________________
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  (08)