Re: Networth example with ldp:contains

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 08:19:14 UTC