Re: ldp-ISSUE-75 (monotonicity): rdf:membershipProperty makes LDP PATCHing non-monotonic [Linked Data Platform core]

On 31 May 2013, at 20:32, John Arwe <johnarwe@us.ibm.com> wrote:

> > but according to the current spec the world where 
> > 
> >    { <> a ldp:Container .}
> > 
> > is true is the world where 
> > 
> >    { <> ldp:membershipPredicate rdf:member . }
> > 
> 
> Where exactly do you find that? 
> I ask because when I convert that into 2119-language in my head, the second assertion comes out "LDPCs MUST use rdfS:member as their ldp:membershipPredicate".   
> And we know the current spec is not that simple. 
> So is my conversion wrong, or your logic (granted, finding such flaws ... if this is one... is exactly the purpose of rendering them so explicit, so my compliments to the chef)?   
> The rest of the arguments build on this foundation, so if the logic is flawed then implications based on them are also suspect. 

Thanks for getting me to think about this in more detail 
The passages in the spec talk in terms of the whole LDPC:

5.2.4 An LDPC must contain one triple containing the ldp:membershipSubject predicate when the membership subject is not the LDPC itself. This triple's object provides clients with the LDPC's membership subject URI.
5.2.5 An LDPC must contain one triple containing the ldp:membershipPredicate or ldp:membershipPredicateInverse predicate when the membership predicate is not rdfs:member.

This mean you may have to parse the whole graph to get to know how to deduce the ldp:includes relation I postit in ISSUE-79
This means also you are requiring inferencing. 

Is this closed world inferencing? the  ldp:membershipPredicate has to be in THAT graph. 
What happens now when you merge two graphs? Then you can no longer do that inferencing 
because you would no longer know in the merged graph where the 
{ <> ldp:membershipPredicate p } relation came from . 
Perhaps you can say the following: the criterion for the truth of 

 { ldpr ldp:membershipPredicate p } 

is that 

 ldpr log:Includes { ldpr ldp:membershipPredicate p } 
  OR 
 ldpr log:notIncludes { ldpr ldp:membershipPredicate ?p }  

where I am using cwms log:xxx relations
from http://www.w3.org/2000/10/swap/doc/CwmBuiltins

but cwm does not have a disjunction relation ( the OR above ). Is that because we start entering heavy waters?

> 
> Following your lead, I copied your example in below in the same style and rewrote/added new cases as necessary to reflect what I think the spec says today. 
> 
> What I expected, to see, if it accurately reflects the current spec, is something like this: 
> 
> but according to the current spec the world where 
> 
>   { <> a ldp:Container .}
> 
> is true is the world where EXACTLY ONE OF THE FOLLOWING is true
> 
>   { <> ldp:membershipPredicate rdfS:member . }
> 
> OR
> 
>   { <> ldp:membershipPredicate ?mp . }
> 
> Which is compatible with 
> 
>   { <> ldp:membershipPredicate ex:attachment }

ok. Note that if a resource other than the given <ldpc> says 

   <ldpc> a ldp:Container .

Then I cannot conclude that the ldp:membershipPredicate is rdf:member .

We have an asymmetry here between how the LDPC can speak about itself, 
and how other resources can speak about it.

At least that would need to be noted.


> 
> 
> 
> example 2: ldp:membershipSubject
> --------------------------------
> 
> Let's take the more complex example
> 
>  { <> a ldp:Container;
>        ldp:membershipPredicate ex:attachment .
>        ldp:membershipSubject <../bugs/13> }
> 
> entails according to the Subgraph Lemma
> 
>  { <> a ldp:Container . }
> 
> but the world in which that entailment is true
> is according to our spec the world where EXACTLY ONE OF THE FOLLOWING is true
> 
> { <> a ldp:Container;
>        ldp:membershipPredicate rdfs:member .
>        ldp:membershipSubject <> } .
> 
> OR
> 
> { <> a ldp:Container;
>        ldp:membershipPredicate rdfs:member .
>        ldp:membershipSubject ?ms } .
> 
> OR
> 
> { <> a ldp:Container;
>        ldp:membershipPredicate ?mp .
>        ldp:membershipSubject <> } .
> 
> OR
> 
> { <> a ldp:Container;
>        ldp:membershipPredicate ?mp .
>        ldp:membershipSubject ?ms } .
> 
> But according to our spec you can't have two distinct ldp:membershipSubjects.
> Therefore ANY INTERPRETATION OTHER THAN THE FINAL ONE (with ?mp and ?ms) implies
> 
> { <> owl:sameAs <../bugs/13> }
> 
> Which I don't think is the intended consequence.

I think that is ok. As long as the entailement of the original 3 statements
are part of the possible worlds of the entailed relation { <> a ldp:Container }
then it should be ok.

Still you have the same problem now. Any resource and than the <ldpc>
resource itself has to specify both the ldp:membershipPredicate and the 
ldp:membershipSubject . The ONLY place where you can have the default
reasoning is in the LDPC itself!

That seems agains like something very ad-hoc.

So thanks for helping make this conversation progress. :-) 

> 
> 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario 
> 
> 
> 

Social Web Architect
http://bblfish.net/