Re: Interaction model vs data model

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

I make parameters explicit to my robot, because the parameter is a URI (an predicate). In addition in my description of my parameter I can also make suggestions (as above). and this is all and this is highly contextualised and very *explicit* to the specific the specific cart, and the orders it prepared to create. I don't think you can argue that my approach makes things less explicit. Infact it adds a lot more explicit information. 

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

I don't understand this second point. 

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

As I said at the time, I liked the ingenuity of your approach, but, it's a no-go for me because of the SPARQL requirement in the client.

> 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

BugTracking isn't really my thing - it's just a scenario that the UC&R has chosen that we all understand. 

But, thanks for the ref all the same. 

Roger