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

On 24 Apr 2013, at 12:18, Roger Menday <roger.menday@uk.fujitsu.com> wrote:

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

I worked through example 3 in detail in my previous mail (as one can see below). But let me go further here.

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

I explained my reasons in detail below. In summary this makes the container a lot more complex.

 - A GET on the </con/tainer> now does not tell you which members were created by that container. You have to look elsewhere.
 - If you arrive on the other resource (o:NetWorth), you don't know that those relations are in fact owned by </con/tainer> . 
   They look like normal RDF triples. 

Some additional questions in this section of example3
 
   <> a o:NetWorth ;
      o:asset <assetContainer/a1> .

is o:asset a subrelation of rdf:member ?  If so is <> an instance of rdf:Container ? 
If so this is a heavy restriction, and it seems to me that it won't deal with many 
use cases people are probably hoping it would be useful for. 

For example why could I not do the following

  </me/imgs/> a ldp:Container;
        ldp:membershipSubject </me#hjs> ;
        ldp:membershipPredicate foaf:likes .

On posting a description of my cat onto </me/likes/> I would end up with the following 
additional triple in </me>

  </me#hjs> foaf:likes </me/likes/zaza>
 
But that is not really what I want. I want to like not the document zaza, but the
thing </me/likes/zaza#this>, ie my cat. It seems that there are going to be many cases 
where we would like posting triples to have  effects of adding relations elsewhere. 
Is the current proposed way of doing things in LDP ®eally the best way to do things? 
It seems like a half baked solution to a subset of the problems that people would like to solve.

So the thing is can we not solve the problem some other way, with a simpler container? 
I don't have a feeling that this question has been at all explored carefully on this list.
And given that the semantic web is very new here to many, there may very well be very
simple ways of doing this that are more general and that keep the LDPC much simpler.

One possibility for example would be for the client to send the following to </me/likes/>

{
 <> foaf:primaryTopic <#this> .

 <#this> a animal:Cat, foaf:Agent;
      foaf:name "Zaza". 

 </me#hjs> foaf:likes <#this> .
}

And for the container to have rules for keeping data in the store consistent 
eg: to add { </me#hjs> foaf:likes </me/likes/zaza#this> } to /me 

then </me/likes> would still be able to show 

{ <> rdf:member <zaza> }

And everyting is clear and simple.

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

Social Web Architect
http://bblfish.net/