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

Best Regards,
Nandana