Re: Interaction model vs data model

On 29 Jan 2013, at 20:36, Roger Menday <Roger.Menday@uk.fujitsu.com> wrote:

>> 
>>>>>> <> 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 ?
>>> 
>>>> 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...
>>> 
>>> In my proposal for this kind of thing at http://lists.w3.org/Archives/Public/public-ldp-wg/2012Dec/0118.html I'm taking large amounts of inspiration from HTML. Therefore, to accomplish the above, we just need a select/option element for a robot ... i.e., we might have a "suggested" property which points to a LDP container - this means pick your type of Doll from the contents of this container. For similar (copying-html) reasons, I prefer POSTing sets of properties, rather than POSTing a graph. 
>> 
>> "I prefer POSTing sets of properties", which means that you are losing context. What is a property of? Some subject
>> presumably. The aim is to make everything as explicit as possible for reasons I gave earlier
>> 
> 
> Look to the Web. You are sent a form, you fill it out, and then return. You are responding to a request for a list of required parameters. And there is no context lost !! 

In the current web the interpreters are human. Humans are extreemly agile at working with context. 
Here in linked data you need to work with machiens, so things need to be made explicit. Furthermore
you are trying to create linked data, where things can be globally linked to, so you are still in a space 
such as the web, where people can come from anywhere.

Now if you want to think of forms then I have previously made the point that you could think of
SPARQL queries as forms that make the context explicit.

Anyway, I recommend you work with Olivier: after all a bug ontology is only going to be interesting
if it can work across sites. He essentially continued the work I started at Sun Microsystem in 2007

https://blogs.oracle.com/bblfish/entry/baetle_bug_and_enhancement_tracking

Henry



> 
> Roger
> 

Social Web Architect
http://bblfish.net/