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

On 30 May 2013, at 10:23, Roger Menday <> wrote:

> Given that a LDPC is defined as a collection of same-subject, same-predicate triples, my reaction to this issue to is to simply refuse a PATCH with a triple which fails outside of this SS-SP definition.

So one could not just PATCH something with 

{ <> ldp:membershipPredicate ex:attachment }

That is not specified anywhere, and it seems important enough 
and automatic enough to record it.

Notice that you need to be consistent across representations 
too. In the case of an LDPC that said

  <> ldp:membershipSubject <../bugs/12> .

you also need to make sure that one cannot PATCH the bug
<../bugs/12> resource with that relation either. 

Formal RDF Semantics

Let's now look at this more formally.

In the "RDF Semantics" spec there is a section entitled 
"Monotonicity of semantic extensions"

     Subgraph Lemma. A graph entails all its subgraphs.

example1: ldp:membershipPredicate

  { <> a ldp:Container;
        ldp:membershipPredicate ex:attachment . }
  { <> a ldp:Container }

so what does entailment mean?

Entailment is the key idea which connects model-theoretic semantics to real-world applications. As noted earlier, making an assertion amounts to claiming that the world is an interpretation which assigns the value true to the assertion. If A entails B, then any interpretation that makes A true also makes B true, so that an assertion of A already contains the same "meaning" as an assertion of B; one could say that the meaning of B is somehow contained in, or subsumed by, that of A. If A and B entail each other, then they both "mean" the same thing, in the sense that asserting either of them makes the same claim about the world. The interest of this observation arises most vividly when A and B are different expressions, since then the relation of entailment is exactly the appropriate semantic license to justify an application inferring or generating one of them from the other. Through the notions of satisfaction, entailment and validity, formal semantics gives a rigorous definition to a notion of "meaning" that can be related directly to computable methods of determining whether or not meaning is preserved by some transformation on a representation of knowledge.

but according to the current spec the world where 

   { <> a ldp:Container .}

is true is the world where 

   { <> ldp:membershipPredicate rdf:member . }

And that world is I am told incompatible with the world where 

   { <> ldp:membershipPredicate ex:attachment }


   { ex:attachment rdfs:subPropertyOf rdfs:member . }

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

 { <> a ldp:Container;
        ldp:membershipPredicate rdfs:member .
        ldp:membershipSubject <> } .

But according to our spec you can't have two distinc ldp:membershipSubjects.

 { <> owl:sameAs <../bugs/13> }

Which I don't think is the intended consequence.

> Roger
>> ldp-ISSUE-75 (monotonicity): rdf:membershipProperty makes LDP PATCHing non-monotonic [Linked Data Platform core]
>> Raised by: Henry Story
>> On product: Linked Data Platform core
>> The current spec says that:
>> [[
>> 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.
>> ]]
>> ie. rdfs:member is a default property.
>> So from 
>> <> ldp:Container .
>> one can deduce that 
>> <> ldp:Container ;
>>  ldp:membershipPredicate rdf:member .
>> but if one then PATCHes the above LDPC by adding say
>>  { <> ldp:membershipPredicate foaf:depiction } 
>> then one can no longer deduce that {<> ldp:membershipPredicate rdf:member } which
>> means that appending { <> ldp:membershipPredicate xxx } is a non-monotonic 
>> process. 
>> Would one not then also by doing this suddenly make a LDPC that had members not 
>> have any at all? It seems that the spec needs to say something about this.
>> This seems to be one more argument in favor of ISSUE-71 .

Social Web Architect

Received on Thursday, 30 May 2013 10:20:25 UTC