- From: Henry Story <henry.story@bblfish.net>
- Date: Tue, 15 Oct 2013 15:55:05 +0200
- To: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
- Cc: Arnaud Le Hors <lehors@us.ibm.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-Id: <7CEF1771-C874-4D71-8593-B7E16A4B1720@bblfish.net>
On 15 Oct 2013, at 15:37, Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr> wrote:
> 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
(a) for sure yes
(b) that is the position most people here would defend, since as far as I can see they only wish the T2 type info
to be published
(c) is the consequence of decisions arrived at in (a) and (b) above.
>
> ?
>
> 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?
You may have other requirements on what should be published. The inference rules is one thing,
the pragmatics of what you publish, how and where is another thing. Keeping those issues
separate is another good reason to make the rule explicit.
>
>
> 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).
Ah it would have made more sense to have lpd:MemberSubject be owl:sameAs .
Since any document has the owl:sameAs relation to itself that works out well.
>
>
> 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/
>
>
Social Web Architect
http://bblfish.net/
Received on Tuesday, 15 October 2013 13:55:38 UTC