- From: Jonathan Rees <jar@creativecommons.org>
- Date: Thu, 17 Apr 2008 08:46:27 -0400
- To: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>
- Cc: "public-awwsw@w3.org" <public-awwsw@w3.org>
On Apr 16, 2008, at 12:55 PM, Williams, Stuart (HP Labs, Bristol) wrote: > Hello Jonathan, > >> -----Original Message----- >> [mailto:public-awwsw-request@w3.org] On Behalf Of Jonathan Rees >> >> One thing I would like to add to my diagram: A box for "network >> endpoint" with the meaning of a real-world source of >> awww:representations (e.g. a "web page" operationally defined by the >> process of sending an HTTP request specifying a particular resource- >> name string to a particular server, using the Internet, and so on). > > Oooohhh, I'd really rather that you didn't - not unless you really > really have to. I didn't mean to say I wanted to analyze network or protocol phenomena in depth. I just want to put "the web" onto the diagram somewhere - right now the diagram is completely detached from reality, as there is no arc that connects abstract entities such as IRs and value clouds to real world phenomena such as the web. I think I accept the same "the web" abstraction as you, and that the things I'm looking for are simply the specialization of "the web" to a particular URI. Let me take a crack at saying what this "the web" idealization is: let U = a URI, p = additional request parameters (such as Accept:), t = a time, V = a ft:value Submit a request (what in HTTP would be GET) for a awww:representation to "the web", using U to identify the awww:resource, at time t, specifying parameters p, with a successful result V, on a web W: webget(W,U,p,t) = V This would be true if, for example, the protocol used is HTTP and the response is a 200. There may be other things you can do with W but this is the one we care about. I hope this idea matches the entity "the web" that you're talking about. As for 'network endpoint', all I'd like to see is the specialization of webget to a particular W and U. We can fix W for the purposes of the entire diagram (since there is only one that we care about). For each URI U I posit a thing E(W,U), the logical endpoint of U (or whatever we choose to call it so that it doesn't misevoke) on W, satisfying get(E(W,U),p,t) = webget(W,U,p,t) I hypothesize that this is the class that David Booth has talked about as "network source of representations". Now why such an artifice? Because it helps the diagram giving another thing for URI to map to (U has endpoint E(W,U), or class URI maps to class endpoint), and another thing that, like Value Cloud, has the potential to be faithful (in some way) to some IR. It's also helpful notationally in RDF and OWL since there are no n-ary predicates. (We have to do the same kind of "at time t" with these that we did with IRs and value clouds.) I imagine this 'webget'/'get' function hides 301/2/7 redirects behind the scenes. To go one level of analysis deeper, instead of GET of a request (URI with parameters p) yielding a ft:Value (200), we talk about the more fine grained relationship of a request to an http:Response, and then we get to talk about redirects. Then we say how 'get' relates to the request/response relationship, which is where we were before. Yes, I agree we needn't talk about proxies, caching, or 404 at this time.
Received on Thursday, 17 April 2008 12:47:27 UTC