Re: ISSUE-81: Confusing membership* predicate names and other possible improvements

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/