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

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


hi Henry, 

Well, I suppose to address that (i.e. 'like' to link to </me/likes/zaza#this> and not to the created resource </me/likes/zaza>) alternatively you could configure your server to observe 'primaryTopic' when constructing the new triple. 

I don't think you need to change everything else to achieve that ... 


From a modelling perspective, I have a small issue with the "likes" relation being managed in this way. I see this more as a case of where a new link where be added between two *existing* resources to express this. 

You sent a long email. I've got some other comments too ...

regards, 
Roger