Re: ldp-ISSUE-72 (membershipObject): The object of a membership triple isn't always the address of the created informational resource [Linked Data Platform core]

On 22 May 2013, at 17:16, Roger Menday <Roger.Menday@uk.fujitsu.com> wrote:

>>> 
>>>> Hi Roger, 
>>>> could you please post an example that illustrates what the problem is? I have to admit not to understand. 
>>> 
>>> There is lots of coverage around this in many of Henry's recent emails ... :) 
>>> 
>>> Anyway, I'll have a go at providing an example showing the problem. Picking up on the cat use-case that Henry introduced a few weeks ago:
>>> 
>>> There is an LDPR </people/roger>, this has a LDPC which is used to manage my pets. 
>>> 
>>> Let's say this LDPC has a membershipSubject of </people/roger> and membershipPredicate of pets:has_pet. If I POST the following to the LDPC: 
>>> 
>>> <> a animal:Cat; 
>>>     foaf:name "Zaza".
>>> 
>>> ... a new resource is created. 
>>> And there is a new membership triple of 
>>> 
>>> </people/roger> pets:has_pet </people/roger/zaza>
>>> 
>>> If one wants to keep the two resources separated, I might POST the following
>>> 
>>> <> foaf:primaryTopic <#this> .
>>> <#this> a animal:Cat;
>>>      foaf:name "Zaza". 
>>> 
>>> However, the new membership triple in this case is not quite right. It still is : 
>>> 
>>> </people/roger> pets:has_pet </people/roger/zaza>
>>> 
>>> ... but it should really be :
>>> 
>>> </people/roger> pets:has_pet </people/roger/zaza#this> 
>>> 
>>> That's the problem. 
>> 
>> Ok so presumably the problem here is that </people/roger> is a document too
>> so that you want the relation not to be on </people/roger> but on </people/roger#i>
>> right.
> 
> Henry, 
> 
> I believe you are looking at the wrong end of the triple. 
> This issue is about the object end. 

I fully understand that this is about the object end. But your argument is 
correctly that the current situation means you have to have documents as
pets, which may be something for monks living cloistered lives, but not for
most of us. So I just pointed out that your example if it is to be consistent
also needs the subject not to be a document... 

Some questions:

- As far as the ldp:membershipObject goes what should the object of that relation 
be? you did not specify that. 
- If the primaryTopic of the created resource is not a <#xxx> url but rather an existing
URL, say a dbpedia URL, then the container would have to add

<#i> pets:has_pet <zaza#it>, myneighbor:zoro .

Now with my neigherbor's cat zoro you see that I loose all information about
which document the LDPC created in which that statement of 

  <> foaf:primary_topic myneighbor:zoro

is located.  So if I wanted to delete the created resource I would not even 
know where it is. This is why I am arguing that in addition to these new
relations you are adding to the LDPC you need to keep the plain rdf:member
relations from the LDPC to the created documents.

Henry

> 
> Roger
> 
>> And that is what the ldp:membershipSubject would be for....
>> 
>> So we would then have
>> 
>> <> a ldp:Container;
>>      ldp:membershipSubject <#i>;
>>      ldp:membershipOject ??? ;
>>      ldp:membershipPredicate pets:has_pet .
>> 
>> <#i> pets:has_pet <zaza#it>, <zara#it> .
>> 
>> so clearly here pets:has_pet has nothing to do with rdf:contains anymore.
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/