Re: network endpoints

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