Re: network endpoints

On May 1, 2008, at 2:52 PM, Pat Hayes wrote:

> At 9:27 AM +0000 5/1/08, Williams, Stuart (HP Labs, Bristol) wrote:
>> Hello Pat,
>>
>> I was wondering how you respond to the notion of attributing  
>> agency/action to the infrastructure of the web itself. Grant that  
>> in some sense the (http?) web infrastructure is able to inspect  
>> the 'state' of some things and report on it when asked.
>
> OK
>> By web infrastructure I mean some aggregregation of origin servers  
>> (backed by app servers, databases, filing systems etc) and proxies/ 
>> caches. Any given user agent (software) experience 'the web' via  
>> the requests it makes and responses it receives via some local  
>> API. I was suggesting to Jonathan not to attribute behaviour in a  
>> fine-grained way to the 'mechnical' artefacts that make up web  
>> infrastructure - but to a coarse-grained agreegation of all of  
>> those artefacts as perceived by a given UA. Not least that avoids  
>> having to account in detail for caching behaviours where a given  
>> request may never reach the relevant origin server.
>
> Well, OK, that all makes sense. Its the entire Web that is acting,  
> and we don't say what the parts of it are doing. It seems rather  
> uninformative and coarse as a basis for theorizing, but it does  
> make a kind of sense. Still, my point remains, seems to me.  
> Documents can't act. So apparently we have to say that there is the  
> aggregation of all the machinery, which acts, and then there are  
> documents, which get acted upon. Is that what you meant? (Im  
> guessing not. :-)

It's close to what *I* mean, since it recognizes that there are two  
things, ideal and actual. I wouldn't commit to documents being "acted  
upon" but wouldn't object to the expression.

If I may use David's fftr:IR for now (it can be replaced by another  
notion of abstract document / IR if you like): an fftr:IR is  
independent of the web (abstract), but one can establish a  
relationship "compatible with the web at U" between fftr:IRs and the  
web as follows: Let U be a URI and R be an arbitrary fftr:IR. Then R  
is compatible with the web at U if for every t, if a GET request A  
specifying URI U is made at time t and results in a response B, then R 
(t, A) = B.

Since requests are not being made all the time, there are many  
fftr:IRs for any given URI, that differ in unobserved ways. One could  
give a canonical inverse: Let U be a URI; define the "actual behavior  
of the web at U" to be the fftr:IR R which has R(t,A) = B for every t  
at which a request A is made, with B = the response. Define R(t,A) to  
be some fixed arbitrary value at all other times, either a bottom  
value adjoined to the class of responses or a dummy response (maybe a  
500). Now we have canonically mapped each URI to an fftr:IR that  
tracks web behavior at U. It is compatible with the web at U by  
construction. This is pretty much what I meant when I initially said  
"network endpoint" (a term I regret, have I been punished enough yet?).

The artificiality of this construction tells me that fftr:IR might  
not be the right abstraction, but that's OK, we're talking.

As I said you can do this same analysis for any information-resource  
candidate class.

This is the kind of picture I'm looking for. It has something  
abstract (the fftr:IR), something concrete (the web), and a  
relationship between them. It tells us when any particular thing  
(fftr:IR in this case) is "on" the web, and by examining the classes  
and properties in the diagram, we can tell what kinds of things can  
be on the web and what the web has to do in order for this to be the  
case.

Jonathan