Re: Interaction model vs data model

On 25 Jan 2013, at 16:51, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:

> hello henry.
> 
> On 2013-01-24 19:45 , "Henry Story" <henry.story@bblfish.net> wrote:
>> We have two elements here: the documents and the protocol (which most of
>> us regard HTTP as being a clear case of).  The area of philosophy where
>> these two is known as pragmatics. For example one distinguishes between
>> the content of a sentence, and what one does with it.  For example given
>> the sentence A
>> A: "The blue chair is outside"@en
>> Here are two ways to use it
>> B: Joe make it the case that "the blue chair is outside"@en .
>> C: Joe is it the case that "the blue chair is outside"@en ?
> 
> this is an excellent example. let's change it just a little, but i think
> we're getting close to some of the more confusing things about REST. REST
> is not about exchanging facts, it's about exchanging state. most
> importantly, it's about engaging in a conversation that may have built-in
> rules.

REST - Representational State Transfer does indeed transfer state. When 
speaking of the state of something one should ask of course state of what? 
And the answer is: the state of some Resource. We don't get very far here, 
as it is very general. But we have a start.

The Resources on the Web are identified with URIs ( Uniform Resource Identifiers ). 
These URIs can be exchanged over e-mail, telephone, busses and so on around the world, 
be embeeded in documents and linked to from anywhere. As a result there is 
social pressure and technical pressure for these URIs to be stable - which 
means that their content does not change beyond the  expectations of those 
linking to it. since the value of your reputation of your  resources and 
the ease with which that resource will be findable depends on its position  
in the global network of links. This is the reason why the Web has the declarative 
nature it has: as resources can be split up as much as possible into
maximally invariant ones, the cache life of the representations can be longer
lasting, and the strength of the links linking is improved. (this is a
short summary of Roy Fielding's thesis )

The importance of this is that there is no determinate context when one reaches
a resource on the web. Any resource on the web can link to any other resource.
One has to therfore when publishing data on the web make all context explicit.

This is where RDF comes in: Resource Description Framwork. RDF builds on a
mathematical logic that arose out of the work of the Boole and mostly
Frege in the 19th Century, and which had huge impact in the 20th century.
Frege thought of his notation as one to make the  implicit in language explicit, 
in order to help mathematicians and scientists think clearly about their domain. 
The Semantic Web took this work and by adding  URIs tied mathematical  logic 
into the Web. Why did it do this? Because as  argued in the previous paragraphs 
the web is a global publication platform where links can arrive from anywhere,
from any context, and so the information needs to be made as explicit 
as possible. 
  RDF therefore allows us to describe resource explicitly and globally in
in such a way as to make the merging of information a simple mechanical 
process that can be done  when needed. Furthermore it make reasoning
possible. After all logic is the science of reasoning, that is of
making valid deductions from information. That is of following rules of
logic.

  So what is the state of the Resource you were speaking of earlier?
Well what you receive is a description of that state in the form of
some bytes encoded in some syntax specified by a mime type.  
If the format has a semantic mapping either naturally such as Turtle, 
RDFXML or indirectly via GRDDL, you can retrieve that description 
in a manner that allows a machine to easily reason about that resource. 

The resource may be of many tupes. Each resource can describe itself
and other things. It is thus a representation of a set of 
possibilities, as all information is, and indeed as the RDF
Semantics spec clearly states. 

Given all this we can now describe the aim of LDP to be 
provide a platform to allow interactions between agents 
( be they in the role of client or server ) in a global 
hyperdata  information space, in order to build the
type of application such as the one you describe below.

But as you can see there is a lot of work to be done when moving
to this space to try to describe what is  the case. This requires
trying to think declaratively, for the same reason that functional
programming languages do: because allows exchange of information in 
a massively parallel world, with reduction to the minimum of knowledge
of context.

> let's take this example:
> 
> i have a product page and i am composing and POSTing an order for the
> product. i am providing all information and send a request that is a
> perfectly self-contained order for 42 pieces of that product. if the
> protocol says that the server has the freedom to down-adjust the amount of
> ordered pieces, and there are only 10 in stock, it would be perfectly fine
> if the server state that ends up being created for the order is an order
> for 10 pieces. for an HTTP observer it may look strange that i am asking
> for 42 and then get a confirmation for an order of 10, but if that's the
> rule of the service, then this is a correct conversation.

That's a good example, though I would say perhaps a bit too complicated for
a starting point. Try to simplify it down to something much simpler. Describe
what you have in Turtle using rdfs. 

For example you have a product. Then create an ontology for your products
and publish them using ldp.

You want there to be a resource that allows you to buy something? 
Describe the type of resource it is. Clearly something in which the
client has to engage in something, something where he can create 
resource that is to be his statement of an event of buying. That
sounds like a Container. 

So what should the client POST there?

just posting 42 does not seem good enough. The resource to which the
client is going to post needs to describe what type of resource is going
to be created.

So perhaps the Container says

<> a ShoppingCartContainer;
   ldp:membershipPredicate :order .

and the client  now knows that if he posts something like

<> a Order;
   content [ a BarbieDoll ];
   for <http://joe.example/#me >;
   address <http://joe.example/#address> .

That this will create in the container a new

<> :order <order2123> .

and that order if accepted would contain presumably the content
above, + perhaps links to the state of the order.
                      
So this requires writing this up in Turtle, trying
it out, verifying the ontologies, seeing if you have not
made weird presuppositions, getting your vocab adopted, 
etc, etc...

For example avoid making up your own ontology, and try
rather the well known one such as

http://www.heppnetz.de/ontologies/goodrelations/v1

Henry  

> 
> cheers,
> 
> dret.
> 

Social Web Architect
http://bblfish.net/