Re: Issue-34 Back_to_Basics proposal

+1 to this being the proposal resolution to issue 34.

It is not surprising but I like this proposal for the following reasons:

1. I don't need different data models for different interaction semantics.
I just insert a triple '<coll> ldp:Container <mem>' for one to know it
has this semantics.  Doesn't request adding additional levels of
indirection, or casting my existing membership predicates for another
one, or needing to make some statements about my predicates what would
have broader impact (subPropertyOf).

2. Delete is for many applications, an edge case.
I like that the interaction model is consistent and what happens for
delete, which seemed to be the motivating factor for two models, is
separated.  GET is the same, for both the collection, member and
non-member properties.  Create/add (POST) is the same.  From a client,
it only needs to know differences for delete (if it cares about
cascading deletes).  Servers it is fairly similar, a server can decide
to not allow certain kids of collections or operations (create,
delete), so nothing is different from typical Linked Data interaction
today.

It would be good to get resolution on this specific issue, then start
to tackle some of the outstanding related issues which don't need to
be addressed until after we close on this.


On Thu, Jan 31, 2013 at 4:01 PM, John Arwe <johnarwe@us.ibm.com> wrote:
> Not having seen any replies to [1], wondering if it got lost in the shuffle.
> This is the same proposal [2] mentioned on this week's call for how to
> resolve the issue and define an interaction model covering both aggregation
> and composition.
>
> [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0330.html
>
> [2] http://www.w3.org/2012/ldp/wiki/Issue-34:_Back_to_Basics
>
> Best Regards, John
>
> Voice US 845-435-9470  BluePages
> Tivoli OSLC Lead - Show me the Scenario



-- 
- Steve

Received on Friday, 1 February 2013 17:47:03 UTC