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]

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

Roger

> Thanks.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 
> 
> 
> 
> From:        "Linked Data Platform (LDP) Working Group Issue Tracker" <sysbot+tracker@w3.org> 
> To:        public-ldp-wg@w3.org, 
> Date:        05/22/2013 02:13 AM 
> Subject:        ldp-ISSUE-72 (membershipObject): The object of a membership triple isn't always the address of the created informational resource [Linked Data Platform core] 
> 
> 
> 
> ldp-ISSUE-72 (membershipObject): The object of a membership triple isn't always the address of the created informational resource [Linked Data Platform core]
> 
> http://www.w3.org/2012/ldp/track/issues/72
> 
> Raised by: Roger Menday
> On product: Linked Data Platform core
> 
> When creating a new resource, the membershipPredicate and membershipSubject properties are used to construct a new triple expressing the relationship between the LDPR and the newly created resource. As pointed out by Henry, e.g. in [1], there is a current limitation because this new triple only references the document that contains the description (rather than the resource itself).
> 
> One solution might be :: when creating the membership triple, if the POSTed content includes a primaryTopic reference, the server should use that address as the object in the membership triple (and not that of the information resource itself). 
> 
> [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0186.html
> 
> 
> 
>