- From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
- Date: Tue, 15 Oct 2013 14:46:51 +0200
- To: Henry Story <henry.story@bblfish.net>
- Cc: Arnaud Le Hors <lehors@us.ibm.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <CA+OuRR9eKshsO0Tx_0Wg+bS2bFdrh0G116L1NH1VJBtUmoHbrQ@mail.gmail.com>
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> . 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> . but from that I will be authorized to *infer* <networth> v:assets <the-new-resource> . 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... 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/ > >
Received on Tuesday, 15 October 2013 12:47:23 UTC