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 18:07, Nandana Mihindukulasooriya <nmihindu@fi.upm.es> wrote:

> Hi Henry,
> 
> On Wed, May 22, 2013 at 5:25 PM, Henry Story <henry.story@bblfish.net> wrote:
> 
> 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.
> 
> So according to your line of argument, a container should be like the following ?
> 
> <> a ldp:Container;
>       ldp:membershipSubject <#i>;
>       ldp:membershipPredicate pets:has_pet .
> 
> <> rdfs:member <zaza> .
> <#i> pets:has_pet <zaza#it> .
> 
> and 
> 
> <zaza> foaf:primaryTopic <#it> .
> <#it> a animal:Cat;
>      foaf:name "Zaza". 
> 
> where 
>   1.) rdfs:member defines the relationship between the information resources managed by LDP which can always be rdfs:member
>   2.) ldp:membershipPredicate which defines the relationships between the two real things using the vocabulary used by the domain 

Well that is starting to make things clearer already. :-)

The most important thing is 1) because that means that one can write a client that can reliably work with LDPCs,
follow rdf:member relations to find resources owned by the server, that it can GET, DELETE, PATCH.... It also 
makes it possible as  Erik Wilde pointed out to trace all the contents that exist on a server ( for those who have access ).
This helps deal with  link rot.

Now 2) is in my view an optional thing that is clearly orthogonal to Content management. If membershipObject 
were to be defined satisfactorily then at least this would mean that peopel would not be forced into 
making bad modelling  decisions. So splitting these two concerns is already a big improvement in 
terms of clarity all around. The relations should probably be renamed in that case away from membershipXXX to
something else. Not sure what.




> 
> Best Regards,
> Nandana
>  

Social Web Architect
http://bblfish.net/