W3C home > Mailing lists > Public > public-ldp-wg@w3.org > January 2014

Re: Networth example with ldp:contains

From: Henry Story <henry.story@bblfish.net>
Date: Wed, 15 Jan 2014 14:50:25 +0100
Cc: Arnaud LeHors <lehors@us.ibm.com>, "public-ldp-wg@w3.org Working Group" <public-ldp-wg@w3.org>
Message-Id: <16FB5CEF-5F2B-4C7B-B7ED-3D5D0335F251@bblfish.net>
To: Alexandre Bertails <bertails@w3.org>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:54 UTC