Issue-87

ISSUE-87: What happens when the membership triples are modified?

The specification is currently silent on what happens if any one of the membership properties is changed. Should it stay that way or say anything? If the latter, what should it say?

( note the arguments in this page are put in terms of ldp:member. They could be made equally well in terms of ldp:manages. Using ldp:created will also work with adjustments. )

1 Origin of the problem

This problem arises if of one thinks of the relation between ldp:member and the "membership triples" as descibed in the "membership triple" <=> ldp:member rules of the membership page, but not for the Causal/Contractual rule.

If any of the membership relations changes then the spec does not describe what should happen to the membership triples. They need to all change or else the client won't be able to find the ldp:member. The spec does not explain what the consequences of changing this rule is.

1.1 ldp:member => membership triples

For example start with the following LDPC and applying the rule from ldp:member to

$ GET http://example.com/shopping/cart/

[[
</shopping/cart/> a ldp:Container;
    ldp:containerResource <#i>;
    ldp:containsRelation foaf:knows;
    ldp:insertedContentRelation foaf:primaryTopic;
    ldp:member <member> .
]]

This would give us _the inferred membership triple_

 <#i> foaf:knows <member#me> .

If one then changes the ldp:containsRelation to rel:loves then the implied triple would be

 <#i> rel:loves <member#me> .

1.2 membership triples => ldp:member

Or starting with the membership triples and applying the to ldp:member

$ GET http://example.com/shopping/cart/

[[
</shopping/cart/> a ldp:Container;
    ldp:containerResource <#i>;
    ldp:containsRelation foaf:knows;
    ldp:insertedContentRelation foaf:primaryTopic .

<#i> foaf:knows <member#me> .
]]

This would give us _the inferred membership triple_

 <#i> ldp:member <member> .

If one then changes the ldp:containsRelation to rel:loves then a client may no longer infer any ldp:member relation.

If this is the intended understanding of the relation then the spec MUST make this clear to the server.

2 Way out of the problem

By making it clear that "membership triples" are made by the action of POSTing, which could be described by a rule such as

ON POSTING TO ?ldpc 
CREATING ?member
CONSTRUCT {
   ?subject ?relation ?object .
} WHERE { 
   GRAPH ?ldpc {
      ?ldpc ldp:containerResource ?subject;
            ldp:containsRelation ?relation;
            ldp:insertedContentRelation ?memberRelation .
   }  
   GRAPH ?member {
     ?member ?memberRelation ?object 
   }
}

In this case changing the rules MUST NOT change the "membership triples" since those may be relations that clients wanted to commit themselves to. But it also follows that ISSUE-88: Lost link to the resource created via POST cannot be solved by making a special case as proposed, since this rule does not allow one to deduce ldp:member relations from membership triples. After all rules can change over time, but they don't bind people after the fact. If you do something which later becomes illegal your past actions are not bound by the new law.