Re: Networth example with ldp:contains

On 15 Jan 2014, at 13:45, Alexandre Bertails <bertails@w3.org> wrote:

> Hi Henry,
> 
> sorry for top-posting but this is a general response to your email.
> 
> I think you mostly forgot "PROPOSAL 2: LDP Named Graphs" [1] that we
> approved a few weeks ago, not yet updated in the draft. In a nutshell:
> 
> * membership triples go into hashless-ContainerResource
> * containment triples go into LDPC

Ah ok, in that case my answer would simply that people who have problems
with duplications in that very very particular case can 

 • set the ldp:ContainerResource to something other than <>
 • use some domain specific inferencing such that the other relation can be deduced from  the first

It does not seem to me that it is worth making a special twist in the protocol for this particular case. 

> 
> Regards,
> Alexandre.
> 
> [1] http://www.w3.org/2012/ldp/wiki/Issue-90#PROPOSAL_2:_LDP_Named_Graphs
> 
> On 01/15/2014 03:18 AM, Henry Story wrote:
>> On 14 Jan 2014, at 19:36, Arnaud Le Hors <lehors@us.ibm.com> wrote:
>> 
>>> As Alexandre alluded to there is still one case where the duplication occurs: this is when the containerResource/memberSubject of a DirectContainer is the container itself. You end up with something like this:
>>> 
>>> <> a ldp:DirectContainer,
>>>         ldp:containerResource <>,
>>>         ldp:containsRelation ex:member,
>>>         ex:member <m1>,
>>>         ldp:contains <m1>,
>>>         ex:member <m2>,
>>>         ldp:contains<m2>.
>>> --
>>> Arnaud  Le Hors - Software Standards Architect - IBM Software Group
>> 
>> 
>> Thinking a bit more about Roger Menday's example, what seems to be missing
>> at present from our spec is something to says "this is where the membership
>> triples should  reside".
>> 
>> Consider, the Networth example 5 from the spec he cites below which
>> makes clear that the representation is a representation of an LDPR
>> 
>> (as can be deduced from this text
>> 
>> [[
>> # The following is an elaborated representation of
>> #   http://example.org/netWorth/nw1/
>> # @base <http://example.org/netWorth/nw1/>
>> ]]
>> 
>> and from the fact that </netWorth/nw1> is not specified as an LDPC. )
>> 
>> Now if we look at the container referenced by </netWorth/nw1>
>> and which is described in Example 6:
>> 
>> [[
>> # The following is the representation of
>> #   http://example.org/netWorth/nw1/assetContainer/
>> 
>> # @base <http://example.org/netWorth/nw1/assetContainer/>
>> @prefix ldp: <http://www.w3.org/ns/ldp#>.
>> @prefix o: <http://example.org/ontology/>.
>> 
>> <>
>>    a ldp:Container;
>>    ldp:containerResource <http://example.org/netWorth/nw1>;
>>    ldp:containsRelation o:asset;
>>    ldp:insertedContentRelation ldp:MemberSubject.
>> 
>> <http://example.org/netWorth/nw1>
>>    a o:NetWorth;
>>    o:asset <a1>, <a2>.
>> ]]
>> 
>> What we are missing is any information to the client as to where the
>> "membership triples" are to reside. The ldp:containerXXX relations tell
>> us what the membership triples are going to be, but they don't say where
>> they are going to be published. This is not so obvious from the above
>> example because the ldp:containerResource is pointing to an LDPR ( an
>> information HTTP GETable resource ). But what if that subject were something
>> else like <http://example.org/netWorth/nw1#it> ? Does the spec say something
>> about this? ( I could not find anything there in § 5.4 HTTP POST . )
>> 
>> Up until now it seems to have been assumed that they should be published
>> in two places: in the LDPC in such a way that one could deduce the ldp:contains
>> relations from them, and in the associated LDPR ( though as pointed out above
>> it was never made explicit how this LDPR should be found ).  Now this does mean
>> there is duplication in most cases since the same information ( the membership triples )
>> is published in two resources.
>> 
>> So the case you point out above is not a special case of duplication. It is
>> just a case where the duplication is more grating, because it is so visible.
>> ( in the other cases the duplication was hidden by its being spread across two
>> different information resources ).
>> 
>> But then if it is really grating to someone, then the answer is simply the same
>> Roger Menday gave: move the "membership triples" to another resource. Lets
>> call this relation pointing to the membership triples document the
>> ldp:membershipTriplesDocument relation.
>> 
>> So we can in fact think then of Alexandre Bertails proposal in issue-89 [1]
>> not as a filtering mechanism, but instead as a relation to expose where the
>> membership triples are going to reside, which is a relation which seems
>> to be needed for the reasons exposed above.
>> 
>> With this simple new tool we now have the NetWorth LDPC look something like this:
>> 
>> <>
>>    a ldp:DirectContainer;
>>    ldp:containerResource <http://example.org/netWorth/nw1>;
>>    ldp:containsRelation o:asset;
>>    ldp:membershipTriplesDocument <http://example.org/netWorth/nw1> .
>>    ldp:contains <a1>, <a2>.
>> 
>> and we have Example 5 from the spec and repoduced below by Roger remain exactly the same.
>> This is nice because now we have a unified LDPC behavior across SimpleContainer, DirectContainer and
>> IndirectContainer. Clients only need to understand the ldp:contains relation.
>> Futhermore there is no inferencing required, since the membership triples are materialised in
>> the membershipTriplesDocument , satisfying our section 4.2.11 to not require inferencing.
>> We also have fixed the problem of WHERE the triples should end up.
>> 
>> So if someone then were to complain, that they want:
>> 
>>   <> ldp:membershipTriplesDocument <>;
>>      a ldp:DirectContainer;
>>      ldp:containsRelation whatever .
>> 
>> without duplication, then we can just suggest they
>> move the ldp:membershipTriplesDocument to another resource
>> or that they require their clients to be able to do the minimal
>> inferencing from
>> 
>>     <> ldp:contains ?x
>> 
>> to
>> 
>>    <> whatever ?x
>> 
>> for any variable ?x bound in the LDPC.
>> 
>> 
>> Henry
>> [1] http://www.w3.org/2012/ldp/wiki/Issue-89
>> 
>>> 
>>> 
>>> 
>>> Henry Story <henry.story@bblfish.net> wrote on 01/14/2014 04:38:33 AM:
>>> 
>>>> From: Henry Story <henry.story@bblfish.net>
>>>> To: Roger Menday <roger.menday@uk.fujitsu.com>,
>>>> Cc: "public-ldp-wg@w3.org Working Group" <public-ldp-wg@w3.org>
>>>> Date: 01/14/2014 04:40 AM
>>>> Subject: Re: Networth example with ldp:contains
>>>> 
>>>> 
>>>> On 13 Jan 2014, at 18:39, Roger Menday <roger.menday@uk.fujitsu.com> wrote:
>>>> 
>>>>> 
>>>>> hello,
>>>>> 
>>>>> Following up on the long call this afternoon ...
>>>>> 
>>>>> In the following two examples, where/why is it necessary to use
>>>> client preference for materializing ldp:contains ?
>>>>> 
>>>>> 1. 'DirectContainer' case (such as a Networth in the spec):
>>>>> 
>>>>> <>
>>>>>   a o:NetWorth;
>>>>>   o:netWorthOf <http://example.org/users/JohnZSmith>;
>>>>>   o:asset
>>>>>      <assetContainer/a1>,
>>>>>      <assetContainer/a2>;
>>>>>   o:liability
>>>>>      <liabilityContainer/l1>,
>>>>>      <liabilityContainer/l2>,
>>>>>      <liabilityContainer/l3>.
>>>>> 
>>>>> <assetContainer/>
>>>>>   a ldp:DirectContainer;
>>>>>   dcterms:title "The assets of JohnZSmith";
>>>>>   ldp:containerResource <>;
>>>>>   ldp:containsRelation o:asset.
>>>>> 
>>>>> <liabilityContainer/>
>>>>>   a ldp:DirectContainer;
>>>>>   dcterms:title "The liabilities of JohnZSmith";
>>>>>   ldp:containerResource <>;
>>>>>   ldp:containsRelation o:liability.
>>>>> 
>>>>> POSTing to  the LDPCs (<assetContainer/>, <liabilityContainer/>)
>>>> creates new Assets and Liabilities.
>>>>> The response has the Location: of these newly created resources.
>>>>> If I GET the LDPR, I see domain-specific <asset> and <liabilities> triples.
>>>>> If I GET the LDPC, I see ldp:contains triples.
>>>> 
>>>> yes, I think that is the best way to do things: Have the LDPC list
>>>> its ldp:contains relations, and have other resources ( eg the Networth
>>>> one shown above) contain the "membership triples".
>>>> 
>>>> The advantage here is that there is no duplication and each resource
>>>> does what it is meant for. Your Networth resource above lists the
>>>> Networth facts, and the LDPCs <assetContainer/> and <liabilityContainer/>
>>>> list the ldp:contains relations. A client that did not deal with LDP would
>>>> probably not end up in <assetContainer/> or <liabilityContainer/>, but
>>>> just follow the domain specific o: ontology .
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> 2. 'SimpleContainer' case:
>>>>> 
>>>>> <>
>>>>>   a o:Box, ldp:SimpleContainer;
>>>>>   o:boxOwner <http://example.org/users/JohnZSmith>;
>>>>>   ldp:contains
>>>>>      <item/m1>,
>>>>>      <item/m2>;
>>>>> 
>>>>> In this case, the LDPR and LDPC are the same thing, and by the
>>>> ldp:contains triples are found when GETting.
>>>>> There isn't a duplication issue.
>>>> 
>>>> exactly.
>>>> 
>>>> :-)
>>>> 
>>>>> 
>>>>> Roger
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> Social Web Architect
>>>> http://bblfish.net/
>>>> 
>>>> 
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
>> 
>> 
> 

Social Web Architect
http://bblfish.net/

Received on Wednesday, 15 January 2014 13:51:31 UTC