Re: Interaction model vs data model

>> 
>>> 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 ?

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