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

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/
>
>