- From: Alexandre Bertails <bertails@w3.org>
- Date: Wed, 15 Jan 2014 07:45:24 -0500
- 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