- From: Henry Story <henry.story@bblfish.net>
- Date: Wed, 15 Jan 2014 14:50:25 +0100
- To: Alexandre Bertails <bertails@w3.org>
- Cc: Arnaud LeHors <lehors@us.ibm.com>, "public-ldp-wg@w3.org Working Group" <public-ldp-wg@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