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

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 . }

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 ];
    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.

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