Difference between revisions of "Issue-87"

From Linked Data Platform
Jump to: navigation, search
(Created page with "[https://www.w3.org/2012/ldp/track/issues/87 ISSUE-87: What happens when the membership triples are modified?] The specification is currently silent on what happens if any one o…")
 
Line 2: Line 2:
  
 
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?
 
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 [http://www.w3.org/2012/ldp/wiki/Member ldp:member]. They could
 +
be made equally well in terms of ldp:manages. Using ldp:created will also work with adjustments. )
  
 
== Origin of the problem ==
 
== Origin of the problem ==

Revision as of 11:58, 16 November 2013

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.

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.