Re: LDPRs, LDPCs and the mysterious X

* Wilde, Erik <Erik.Wilde@emc.com> [2013-01-25 09:31-0500]
> hello henry.
> 
> On 2013-01-25 09:44 , "Henry Story" <henry.story@bblfish.net> wrote:
> >Now is it even useful to notice this? Does it have any
> >protocol implications? Well I think it does. For example
> >it explains why ISSUE-45 [1] can give those things a
> >different operational behavior to ldp:Container-s
> >with regard to POST. It can do that because there is
> >no overlap between ldp:Container-s and _:X .
> 
> i really like this exercise, but i just want to point out the difference
> between the data model and the interaction model again: for the data model
> part, looking at LDPR and LDPC makes a lot of sense. for the interaction
> model, we could/might choose other/additional resources/representations.

I'm confused by this. I'd have thought that LDPC and LDPR were the
*interaction* model, and that we want to steer clear of the data
model. (In fact, we hamper our goal of wide utility if we make demands
of the application's internal model.)


> for example, consider the simple product/order example i described
> yesterday (follow an "order" link of a product page to POST an order),
> where the data model would be products and orders (these would be the
> resources managed by the server). the protocol probably would use other
> resources, for example asking a client to submit just an address (which
> then translates to an order being created), or maybe even only a single
> number ("i want *42* of these things), and then the server creates an
> order out of that.
> 
> so while the data model in that case would clearly only need products and
> orders, the interactions could very well use different representations,
> because the state that is transferred in the protocol is different from
> the "server-side data model".
> 
> cheers,
> 
> dret.
> 
> 

-- 
-ericP

Received on Friday, 25 January 2013 15:31:00 UTC