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]

I think that a simple fix would be : 
if a primaryTopic is referenced in the POSTed content than use that in the object position of the membership triple, otherwise use the address of the created resource. 

?

Roger

> Ok. I understand. Thanks. 
> 
> How would you use something like membershipOject for this? 
> 
> Regards.
> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
> 
> 
> 
> 
> From:        Roger Menday <roger.menday@uk.fujitsu.com> 
> To:        Arnaud Le Hors/Cupertino/IBM@IBMUS, 
> Cc:        Linked Data Platform Working Group <public-ldp-wg@w3.org> 
> Date:        05/22/2013 06:43 AM 
> Subject:        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
> 
> 
> 
> 
>