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]

All right, I get it. Thanks.
--
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:     "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Date:   05/22/2013 07:26 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]




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