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

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