Re: Interaction model vs data model

On 29 Jan 2013, at 18:43, Roger Menday <roger.menday@uk.fujitsu.com> 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> .
> 
> I think this kind of example can join the BugTracker for input about doing "services" with LDP. 
> 
> I do think that one of the good things about REST is that it eliminates pre-knowledge for the client. For example, there is magic in your example, i.e., the client has to know it is a Toyshop. It could be a selling Pizza .... and then what ?

yes, the example was incomplete. The point of this was not to 
give a complete example, but to show how one could POST a graph,
it be clear to the agent that the posting there would be an
act of Ordering, and that the resulting order would look very
much like what was Posted, but would then *BE* the order: and
have its own URL. 

Essentially the agent POSTing knows that the posting will create
a :order relation from the collection to the thing posted, and that
this means for the server that it will start a process. Ie:
everything is declarative through and through.

Now your question is good one: how do you delimit the type of things ordered.
There are many possible answers. One would be to restrict the order relation
using an owl restriction on the elements of an rdf collection named by 
reference. Clearly more work is to be done there...

I am just building the basic blocks over on my side. When those
are done, looking at these more advanced problems is going to be
something I can look at practically.


> 
> Roger
> 
>> 
>> 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/
>> 
> 

Social Web Architect
http://bblfish.net/