Issue-88

ISSUE-88: Lost link to the resource created via POST was described in great detail in Missing Function from Object to LDPR member section of the MembershipInferencing page.

( 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 Overview

It is important to understand the cause of the problem. It is due to the implicit existence of a rule from "membership triples" => ldp:member rule such as:

CONSTRUCT {
  ?ldpc ldp:member ?resource . // <- the consequence
} WHERE { 
    ?ldpc ldp:containerResource ?subject;
          ldp:containsRelation ?relation;
          ldp:insertedContentRelation ?memberRelation .

   ?subject ?relation ?object . // <- the membership triples 
 
   GRAPH ?resource {
      ?resource ?memberRelation ?object . 
   }
}

This problem could not exist if such a rule were not implied.

2 Potential Answers

2.1 make ldp:member mandatory when ldp:insertedContentRelation is different from ldp:MemberSubject

This is a hack around the problems caused by the rule from "membership triples" => ldp:member . It means that servers have one more way they can make a mistake in their implementation of LDP. It also means that clients have to

1. do the inferencing from membership triples anyway before looking for ldp:member relations
2. then look for ldp:member relations, anyway.

2.2 make ldp:member mandatory

• This then reduces the need for clients to do complex inferencing from "membership triples" to ldp:member relations.
• Ties in very well with a LDPC as SPARQL endpoint story

How does one recover the membership triples? This depends on how one thinks of the membership triples.

2.2.1 1. ldp:member => membership triples rule

A simple rule such as

CONSTRUCT {
   ?subject ?relation ?object .  //<- the consequence
} WHERE { 
    ?ldpc ldp:containerResource ?subject;
          ldp:containsRelation ?relation;
          ldp:insertedContentRelation ?memberRelation;
          ldp:member ?resource . // <- a membership relation
 
   GRAPH ?resource {
      ?resource ?memberRelation ?object . 
   }
}

recovers the triples. The server then does not even need to publish the membership triples, since a client can recover them with such a rule.

2.2.2 2. contractual/causal consequence

If one thinks of LDPC creations more in terms of causal/contractual consequence such as would be expressed by a rule such as this:

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 
   }
}

then both the ldp:member and the "membership triples" MUST be published. This is because the rule is triggered by an action at a time, and one cannot deduce from later rules what previous rules were.

This is the correct interpretation if one decides to do nothing with Issue-87: What happens when the membership triples are modified?.