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

Re: Networth example with ldp:contains

From: Alexandre Bertails <bertails@w3.org>
Date: Wed, 15 Jan 2014 07:45:24 -0500
Message-ID: <52D682E4.4070500@w3.org>
To: Henry Story <henry.story@bblfish.net>, Arnaud LeHors <lehors@us.ibm.com>
CC: "public-ldp-wg@w3.org Working Group" <public-ldp-wg@w3.org>
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

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/
>
>
>
Received on Wednesday, 15 January 2014 12:44:50 UTC

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