RE: Subgroup to handle semantics of HTTP etc?

> -----Original Message-----
> From: Xiaoshu Wang [] 
> Sent: 23 October 2007 11:46
> To: Williams, Stuart (HP Labs, Bristol)
> Subject: Re: Subgroup to handle semantics of HTTP etc?
> Williams, Stuart (HP Labs, Bristol) wrote:
> >> A representation is bound with its master URI, so we cannot talk 
> >> about it without its master URI.
> >>     
> >
> > Hmmm... I think you are still in a tangle trying to think of 
> > representations as resources.
> >   
> I am actually thinking otherwise. 
> > Once you have lumpped all possible representations into a single
> > I don't see what distinguishing feature they have that enables you
> > bind them to a b-node - it's just representation soup.
> >   
> Representation is a-provoked resource in the sense that if 
> there is no request, there is no representation.  If I define 
> a class to represent representation, there is a necessary 
> property relates it to a request.  
> But an ordinary resource does not need this property to be a 
> resource.  
> Its existence does not depend on if there is a request.

Well... I observe that you persist in wanting to speak of
representations as resources.

> > FWIW: the definition of the a resource that I suspect most of the
> > work with is the one that I'll attribute to Roy Fielding:
> >
> > 	"More precisely, a resource R is a temporally varying
> > 	membership function MR(t), which for time t maps to a set of
> > 	entities, or values, which are equivalent. The values in the set
> > 	may be resource representations and/or resource identifiers."
> >
> > My understaning of the latter clause ("...and/or resource 
> > identifiers.") is that it covers both redirection and 
> content-negotiation.
> >   
> Sure I can accept that. But the defined mapping function is one way: 
> from Resource to Representations.  It does not tell us that 
> given a representation, what a resource is, yes?

Well is suppose that you can conceive of an inverse... and depending on
whether you regard a representation as a particular message (in which
case it arises because of an access attempt using a URI) or as a type
for all messages that carry the specific sequence of bits/bytes... may
or may not be functional, respectively.

> httpRange-14 trying to force the issue.  

No... at the most, the TAG's httpRange-14 resolution:

a) seeks to avoid ambiguity of reference between a thing and a
description/depiction of a 
b) leave the range of what can be referenced by an http: URI sans
fragment, unconstrained.
c) provide a sufficient mechanism for those that care about the
difference to determine that an information resource has been

[btw: b) comes at the cost of c)]

None of this tells you what any given resource is - what a give
reference actually denotes.

> > Anyway... the point is that by that definition, the notion of a 
> > resource entails all its available representations past, present and

> > future. I think this is close to your conceptualisation, except that

> > in your formulation: 
> >
> > 	"I think it is more 
> > 	appropriate to define *information resource* as the set of all 
> > 	representations of all generic URIs."
> >
> > you seem to form a set from ALL representation of ALL (generic) 
> > resources, whereas Fieldings defn (flattening out time) 
> forms a set of 
> > resources each of which has a sets of ALL it's possible 
> > "representations and/or (redirection/connneg) resource 
> identifiers". 
> > It is then the resource which get assigned resource 
> identifiers, *not* 
> > their representations.
> >   
> Yes, I agree.  The reason that I made the above proposition 
> is to remove the current definition of *information resource" 
> in the AWWW document.  

Well, in that case, rather than going round the houses, I suggest you
propose an alternative defintion, bearing mind that in order for a
definition to stick you'll need to reach concensus with a community that
does care to distinguish information resource - or persuade them that
the distinction is not worth making.

> I think, if we want to use the words, it is more appropriate 
> to use it to refer to the concept of representation.
> >> I snip the rest.  I don't think we differ too much but only on 
> >> probably this one question.
> >>
> >> Is there any distinguishable difference between a "document 
> >> (awww:InformationResource)" and a person?
> >>     
> >
> > Distinguishable by whom/what?
> >   
> Right, this is my argument. :-)
> > I don't think that I can capture all my (current) 'essential'
> > characteristics in a message, though I think Pat had a pretty good
> > wrt to himself and what might be regarded as some eternal
characteristics [2].
> >
> > I was going to say that I could/can change the state of at least
> > documents by sending a message on the web (PUT/POST), whereas I
> > change your state in the same way (if you have state that is). OTOH 
> > sending a message clearly has some impact. In large part though,
> > would be equally true of a paper document - though what is printed
> > the paper would be regarded as an IR, the paper copy itself would
> >   
> Why cannot. Assuming your past few email is posted to my 
> website, wouldn't it possibly change the state of my mind? 

But... can you convey your "state of mind" before and after our exchange
in a message? :-)

> > Short answer is...  yes I think that there are... but pinning down 
> > what precisely they are is hard.
> >   
> I agree there are because otherwise there is no need for 
> ontology and semantic web any more.  My point is that the 
> difference does not make them behave differently in a 
> particular transportation protocol, like HTTP.

Well, try as a I might, I don't think that I can affect the state of the
moon by referring to it with an HTTP URI and doing a PUT or a POST.
Equally, I very much doubt that it is going to yield a representation of
itself however nicely I ask it.

> As I just 
> replied to Richard, dereferencing a URI with HTTP is the 
> behavior of a server, not the resource itself.

FWIW: of late I have been taking the view that requests and responses
are made of web infrastructure which attempts to obtain resource
representations (which may involve interaction with the resource) and
provide responses. 

> > "... I propose to use "information resource" for
> > Please don't do that... I think that would contribute more confusion

> > than light.
> >   
> Sure.  The point I want to make is to scratch off the current 
> definition of "information resource".
> "information resource" is the remnant from the traditional 
> view of URL. We seems not be able to give us the idea or 
> comfort of using a path-like structure to refer to a document 
> on our computer.  httpRange-14 is just one of those struggles.  
> In a lot of way, httpRange-14 intends to say when a URI 
> becomes a URL but in the disguise of "information resource".  
> I want us to say no to
> 303 and say no to "information resource".
> Xiaoshu

Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks
RG12 1HN
Registered No: 690597 England

Received on Tuesday, 23 October 2007 14:15:36 UTC