Re: LDP-Server - Issue-57

On 13 Jun 2013, at 17:00, Arnaud Le Hors <lehors@us.ibm.com> wrote:

> Hey Henry, 
> Didn't you mean Issue-57 (How can a client determine that it is in communication with an LDP server) rather than issue-58 (membersInlined) here? 

yes. Thanks for pointing that out.

> 
> I must admit to be surprised by your question but I'm glad you asked because this is fundamental enough that if we don't all agree on this it's no wonder we have such a hard time talking through some of the issues. 
> 
> From my point of view, we're not just defining a vocabulary or ontology people can use with an existing triple store. We're also defining an interaction model in a the form of requirements that requires one to write code for in a server to be compliant. 
> 
> LDP isn't only about RDF. It is also about REST, which clearly involves servers and clients. We're not only defining specific states but also how to transition from one state to another. How do you do that without talking about servers? 

Ok, well I cannot disagree with that, there are clients and servers. 
When we describe a protocol we are describing a communication system.
We are therefore close to what is know in philosophy as speech acts,
a similarity that the Technical Architecture Group picked up in 2009

  http://www.w3.org/2001/tag/dj9/story.html

This part of the web does not seem to be finally formalised yet.
Speech acts distinguished the force of a statement from its declarative
content. The declarative content of a statement such as 

   "The meeting is closed"

would be analysed declaratively as requiring the world to be in a 
certain relation to the sentence for it to be true. But Austin,
and later Searle ( who is still alive and teaching in Berkeley )
argued that there is more to this. When a chair of a meeting says
"The meeting is closed" then it is closed by virtue of the chair
saying it. The saying makes it so, rather than the world making it 
so. 

So we have something similar going on when we interact with a
web agent by using messages that we send using the verbs such
as POST, PUT, etc... We send content with an action verb, that
makes the server do something - namely change the state of the
resource we are interacting with. 

Now in order for that to happen we need the web agent to be able
to change the state of a resource correctly on our POSTing, PUTing.... 
content.

So the question is how do we know that the server has the capacity
to follow up on our request. It seems natural. And yet, my point below
was that something is odd in this question: nobody asks this question
about wether a server has the capacity to deal with HTML forms in general.
What we do is follow representations from resources (eg html) which tell 
us that we can POST data to some resource. The HTML form describes a 
resource as having the ability to receive a certain interaction.
If we cannot interact with the resource that way, then we know the description
in the HTML was faulty, and we can fill in a bug report.

That is we can describe resources as being of certain types, and that
they allow certain types of interactions. We can declaratively describe
a resource as allowing certain actions. By doing that of course we
describe the web agent that the server we are interacting with is.
But we did not need to describe the web agent in full to do this, just
the resources we are interested in.

I hope that helps a bit.

> 
> Regards.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 
> 
> Henry Story <henry.story@bblfish.net> wrote on 06/12/2013 07:50:31 AM:
> 
> > From: Henry Story <henry.story@bblfish.net> 
> > To: public-ldp-wg@w3.org, 
> > Date: 06/12/2013 07:57 AM 
> > Subject: LDP-Server - Issue-58 
> > 
> > The spec says in Section-3
> > 
> > [[
> > A conforming LDP Server is an application program that processes 
> > HTTP requests and generates HTTP responses that conform to the rules
> > defined in sections onLDPRs and LDPCs
> > ]]
> > 
> > Does this notion really make sense? It seems to lead straight to 
> > question of ISSUE-58
> > 
> >  "How can a client determine that it is in communication with an LDP server?"
> > 
> > Do we speak of an Form Server, because a Web Server can deal with HTML forms?
> > Or do we speak of a jpg server because a web server can deal with jpg images?
> > Or do we speak of a shopping cart server because a server contains a
> > shopping cart functionality?
> > 
> > One can see how speaking in those ways would soon raise similar questions:
> > 
> >   - How can a client determine that it is in communication with a form server?
> >   - How can a client determine that it is in communication with a jpg server?
> >   - How can a client determine that it is in communication with a 
> > shopping cart server?
> >  
> > Clearly all those questions are silly. There is no such thing as a 
> > shopping cart server.
> > There are just resources that can receive shopping cart type 
> > requests: such as adding
> > items, etc... ( not so unlike an LDPC ). A request with a jpg mime 
> > type on a particular
> > image will return that image. etc...
> > 
> > The same is true then with an LDP Server.  It is not clear that one needs
> > anything more than the notion of an LDPC and LDPR resource. These would be
> > such that they behave the way the spec defines them to behave. They are of
> > course HTTP resources.
> > 
> > An LDP Server is then just a loose hand way of saying
> > 
> > [[
> > A conforming LDP Server is an HTTP Server that contains one or more 
> > LDPC resources that conform
> > to the rules defined in this spec.
> > ]]
> > 
> > Social Web Architect
> > http://bblfish.net/
> > 
> > 

Social Web Architect
http://bblfish.net/

Received on Thursday, 13 June 2013 15:44:44 UTC