Re: ldp-ISSUE-61 (membershipSubject): remove membershipSubject [Linked Data Platform core]

hi Henry, 

I see observe strong container-oriented thinking in your email. But, I think LDP should be entity-oriented (the containers are just the means to manage the entities) .....

You say that it is intuitive that after creating (with POST) there would be a new triple, [URI of LDPC]-[membershipPredicate]-[URI of new resource]. I don't see it that way. Instead, I think that the [membershipSubject] should be in the subject position in that triple.

You asked for an example .. so, please look at example 3 in the spec. After POSTing a new Asset to an assetContainer, the triple which should emerge is networth-hasasset->thenewasset. What good would it be to have the assetContainer in the subject position? Moreover without the presence of the membershipSubject triples on the assetContainer and liabilbilityContainer, I don't see how a client can assume that the containers are connected with the networth resource. How do you make that connection ? 

regards, 
Roger


>> 
>> Henry, 
>> 
>> In issue 51, I expressed a requirement to have a forward link between an LDPR and its LDPC's. Then at the F2F I was reassured (kind of) that at least there is a link from the LDPC back to it's LDPR using membershipSubject. So I cannot agree with removing the last remaining link.
> 
> I don't think that is the way membershipSubject is meant to work, but I am not sure I understand what your point is.
> 
> Can you give me an example LDPR and an example LDPC as two different documents (ie getting their representations 
> would require 2 different GETs) with the minimum  required triples in each case to illustrate your problem?
> 
> See below for how it is meant to work:
> ---
> 
> Looking at the spec and especially the examples, my thought is that membershipSubject 
> is meant to work with membershipPredicate so that if we have a collection such 
> as </con/tainer/>
> 
> </con/tainer/> a ldp:Container;
> ldp:membershipPredicate o:asset ;
> ldp:memberShipSubject <../thing> .
> 
> Then POSTing 
> 
> <> a BigAsset;
>   o:worth 10000 .
> 
> onto </con/tainer/> would end up with  these relations appearing in  </con/thing> .
> 
> </con/thing> a o:NetWorth;
>  o:asset </con/tainer/newAsset> .
> 
> Where </con/tainer/newAsset> would now contain
> 
> <> a BigAsset;
>   o:worth 10000 .
> 
> And I just found the explanation in the spec which confirms this reading (guessing) (after Example 3)
> 
> [[
> The essential structure of the container is the same, but in this example, the membership subject is not the container itself – it is a separate net worth resource. The membership predicates are o:asset and o:liability – predicates from the domain model. A POST of an asset representation to the asset container will create a new asset and add it to the list of	members by adding a new membership triple to the container. You might wonder why http://example.org/netWorth/nw1 isn't made a container itself and POST the new asset directly there. That would be a fine design if http://example.org/netWorth/nw1 had only assets, but if it has separate predicates for assets and liabilities, that design will not work because it is unspecified to which predicate the POST should add a membership triple. Having separate http://example.org/netWorth/nw1/assetContainer/ and http://example.org/netWorth/nw1/liabilityContainer/ container resources allows both assets and liabilities to be created.
> ]]
> 
> ( btw. there is a bug in the spec I think as <.> refers to <http://example.org/netWorth/> and <> refers 
> to <http://example.org/netWorth/nw1> )
> 
> Still this leave the question open:
> 
> • is a GET on </con/tainer> now meant to return the following?
> 
>     <> rdf:member <newAsset> .
> 
> ( from the spec it would seem that not )
> So that would mean that one would really have to go to </con/thing> to find what 
> intuitively would be thought of as being the members of </con/tainer/> .
> In the examples in the spec, the resource shows the contents.
> 
> • But </con/thing> is not an ldpc so doing a PATCH on that should work to remove
> 
> <> o:asset </con/tainer/newAsset>
> 
> But someone doing that would not be aware that by doing this he is doing something that
> should be somewhat equivalent to removing the only link to </con/tainer/newAsset> .
> 
> 
> I understand the reasoning behind this as explained in the text from the spec above. 
> But I wonder if one cannot do this in a much cleaner way where LDPC's just have
> simple rdf:member relations to their content, in a way that gives us the same effect,
> but without mixing containership semantics and application semantics quite so strongly.
> 
> I'll see if I can come up with something...
> 
> Henry
> 
>> 
>> regards, 
>> Roger
>> 
>> 
>>> ldp-ISSUE-61 (membershipSubject): remove membershipSubject [Linked Data Platform core]
>>> 
>>> http://www.w3.org/2012/ldp/track/issues/61
>>> 
>>> Raised by: Henry Story
>>> On product: Linked Data Platform core
>>> 
>>> the ldp:membershipSubject functionality was never really discussed in the Working group, but it was just taken on from the original IBM proposal. It complicates things and makes the LDPC model a lot harder to understand:
>>> 
>>> - if the subject is another LDPC why not just POST to that other LDPC? In which case this feature is redundant.
>>> - if the subject is not an LDPC why not just PATCH the other LDPR with the new information? In which case this feature is redundant.
>>> 
>>> What is the use case for this? Given that the aim of this first spec is to be very simple, why is this needed at  all, when so many other features have been having trouble being developed?
>>> 
>>> 
>>> 
>> 
> 
> Social Web Architect
> http://bblfish.net/
>