- From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
- Date: Tue, 15 Oct 2013 15:37:36 +0200
- To: Henry Story <henry.story@bblfish.net>
- Cc: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>, Arnaud Le Hors <lehors@us.ibm.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <CA+OuRR-eMnhi=OLT1O+-di4Z4Ks5OpnFNdqxK-Ei_0SwuMCdiA@mail.gmail.com>
Henry, What is not yet clear to me is the "direction" of the "membership rule". In my example below, let's give a name to the triples for the sake of clarity? T1: <> ldp:member <the-new-resource> . T2: <networth> v:assets <the-new-resource> . Does the membership rule allow: a) to infer only T2 from T1 b) to infer only T1 from T2 c) to infer T1 from T2 and conversely ? If the answer is c), then you would assume that some servers would only publish T1, others would only publish T2, and others would publish both? More (minor) comments below : On Tue, Oct 15, 2013 at 3:03 PM, Henry Story <henry.story@bblfish.net>wrote: > > On 15 Oct 2013, at 14:46, Pierre-Antoine Champin < > pierre-antoine.champin@liris.cnrs.fr> wrote: > > Hi Henry, > > so just to be sure that I got it right: > > CURRENTLY, if I have an LDPC described by > > <> > a ldp:Container; > ldp:membershipSubject <networth> ; > ldp:membershipPredicate v:assets ; > ldp:membershipObject ldp:MemberSubject . > > and I post a new resource, I will then have > > <> > a ldp:Container; > ldp:membershipSubject <networth> ; > ldp:membershipPredicate v:assets; > ldp:membershipObject ldp:MemberSubject . > > <networth> v:assets <the-new-resource> . > > that last statement is wrong. The current spec says that you'll have > instead > the result of > > CONSTRUCT { <the-new-resource> v:assets ?x } > FROM <the-new-resource> > WHERE { <the-new-resource> ldp:MemberSubject ?x . } > You must mean CONSTRUCT { <networth> v:assets ?x } right? If so, I would agree with you, except that, in my reading, ldp:MemberSubject has a special meaning, for the case where we want to use the URI of the created resource itself (last sentence of 5.2.10 in the WD). > though it is not clear in which document that constructed relation is > going > to appear I think. > > > IN YOUR PROPOSAL (and regardless of the actual predicates in use) > after I post a new resource, I will have > > <> > a ldp:Container; > ldp:membershipSubject <networth> ; > ldp:membershipPredicate v:assets; > ldp:membershipObject ldp:MemberSubject ; > ldp:member <the-new-resource> . > > Well my proposal was that you'd start off with a container > > <> a lpd:Container; > ldp:membershipRule [ ldp:subject <networth> ; > ldp:property v:assets; > ldp:rangeSelector > ldp:MemberSubject ]; > I deliberately kept the "old" predicate to separate the issues -- I'm more interested here in the workflow than in the precise syntax... ldp:member <the-new-resource> . > > yes. Though one could argue that one need not explicitly state the > ldp:member relation > since it could perhaps be inferred from the following triple if that one > is published > > but from that I will be authorized to *infer* > > <networth> v:assets <the-new-resource> . > > except that the object needs to be built using the CONSTRUCT > clause shown above. > same comment as above, re. ldp:MemberSubject . pa > > Is that right? > This is indeed an elegant solution, and solves the monotonicity problem. > > I am concern, though, that it somehow requires clients to have some > inference capability, which I think we resolved not to do... > > > If you don't wish the client to have to deal with inferencing then you > need to argue that > ldp:member relation MUST be published. > Otherwise the inferencing is exactly the inferencing that the current > proposal asks of the client. It is just that by being explicity about this > inferencing it becomes a lot easier for people to understand what is going > on. > > Henry > > > pa > > > > On Tue, Oct 15, 2013 at 9:31 AM, Henry Story <henry.story@bblfish.net>wrote: > >> >> On 15 Oct 2013, at 03:27, Arnaud Le Hors <lehors@us.ibm.com> wrote: >> >> Hi Henry, >> >> Because this isn't merely about creation I would suggest you use >> something like ldp:membershipRule rather than ldp:creationRule. >> >> >> ok, I rewrote it in terms of an ldp:member relation that is similar to >> ldp:created but that is false if the object of the relation is deleted. >> the object of an ldp:member relation is the created LDPR. >> >> There certainly are advantages at grouping all the pieces together, the >> question is whether the group is willing to rely on a blank node. Past >> discussions have indicated that it wasn't. I don't know whether this has >> changed. We'll see. >> >> >> wether the blank node would be necessary or not is an interesting >> question. >> >> The main advantage I would argue of this way of putting things is that >> there is no necessity to have the ldp:membershipRule in the LDPC at all. >> When we reason in terms of rules we don't have the monotonicity problem >> we used to have. We can simply say that whenever something >> is created in an LDPC the { ?c ldp:member ?r } is true. Specifying a rule >> then allows one to come to further conclusions - which is very different >> from defeasible reasoning which I was arguing against previously. >> >> >> Thanks. >> -- >> Arnaud Le Hors - Software Standards Architect - IBM Software Group >> >> >> Henry Story <henry.story@bblfish.net> wrote on 10/14/2013 09:02:53 AM: >> >> > From: Henry Story <henry.story@bblfish.net> >> > To: public-ldp-wg@w3.org, >> > Date: 10/14/2013 09:03 AM >> > Subject: ISSUE-81: Confusing membership* predicate names and other >> > possible improvements >> > >> > I have added the following to the wiki: http://www.w3.org/2012/ldp/ >> > wiki/ISSUE-81 >> > >> > This proposal is a suggestion for an improvement to build on top of >> > whatever comes out of Part I. This is a structural improvement that >> > would reduce the redundancy found in 1. The proposal is to not have >> > 3 relations from the LDPC, but rather have 1 relation from the LDPC >> > to a blank node which itself then has 3 relations. >> > <> a ldp:Container; >> > ldp:creationRule [ ldp:subject <../card#me>; >> > ldp:predicate foaf:knows; >> > ldp:rangeSelector foaf:primaryTopic ] . >> >> > The names for ldp:subject, ldp:predicate, ldp:rangeSelector, can be >> > taken to be those people prefer in Part 1 above. >> > By default creation in an LDPC ?c of an LDPR ?r makes the following >> > statement true: >> > ?c ldp:created ?r . >> >> > The creationRule is just the statement of a pragmatic consequence of >> > creating a resource in that particular LDPC. There could be one or >> > more such rules, and so also the ldp:creationRule could be missing ( >> > a vanilla server? ) This makes it easier to understand what the >> > membershipXXX rules are about: they don't specify new membership >> > predicates, but they specify a rule that makes it possible to deduce >> > some things from the existence of an ldp:created relation - and it >> > seems this groups wants the relation to be an if and only if >> > relation: that is that if the ldp:created relation is not to be >> > found but the other relations exist one can deduce the existence of >> > the ldp:created relation. >> > This does not I think have the problems of monotonicty that were >> > found to be existing in the original ldp:membershipXXX relations. >> > >> > Social Web Architect >> > http://bblfish.net/ >> >> >> Social Web Architect >> http://bblfish.net/ >> >> > > Social Web Architect > http://bblfish.net/ > >
Received on Tuesday, 15 October 2013 13:38:10 UTC