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

On 23 Apr 2013, at 17:23, Roger Menday <> wrote:

> 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 isn't made a container itself and POST the new asset directly there. That would be a fine design if 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 and container resources allows both assets and liabilities to be created.

( btw. there is a bug in the spec I think as <.> refers to <> and <> refers 
  to <> )

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


> regards, 
> Roger
>> ldp-ISSUE-61 (membershipSubject): remove membershipSubject [Linked Data Platform core]
>> 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

Received on Tuesday, 23 April 2013 16:51:45 UTC