Re: Interaction model vs data model

On 1/25/13 12:29 PM, Henry Story wrote:
> 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

Great explanation!

Some examples of offers, licenses, and whatever else from our data space 
on the Web:

1. http://virtuoso.openlinksw.com/data/turtle/ -- Virtuoso
2. http://virtuoso.openlinksw.com/data/turtle/ -- Universal Data Access 
(UDA) Drivers
3. http://virtuoso.openlinksw.com/data/turtle/VirtuosoBuyServices.ttl -- 
even describes a purchase service (note that it even incorporate the URI 
Templates [1])
3. http://ode.openlinkw.com -- a Linked Data extension for all the major 
browsers (on Firefox and Chrome to can even enable defualt handling of 
Content-types for RDF content e.g., Turtle ).

Link:

1. http://tools.ietf.org/html/rfc6570 -- URI Templates .


>
>> cheers,
>>
>> dret.
>>
> Social Web Architect
> http://bblfish.net/
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen