Difference between revisions of "Issue-88"

From Linked Data Platform
Jump to: navigation, search
(ISSUE-88: Lost link to the resource created via POST)
(make ldp:member mandatory when ldp:insertedContentRelation is different from ldp:MemberSubject)
Line 36: Line 36:
 
It means that servers have one more way they can make a mistake in their implementation of LDP.
 
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  
 
It also means that clients have to  
  1. do the inferencing from membership triples anyway before looking for ldp:member relations
+
# do the inferencing from membership triples anyway before looking for ldp:member relations
  2. then look for ldp:member relations, anyway.
+
# then look for ldp:member relations, anyway.
  
 
=== make ldp:member mandatory ===
 
=== make ldp:member mandatory ===

Revision as of 11:32, 16 November 2013

1 ISSUE-88: Lost link to the resource created via POST

( 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. )

ISSUE-88 was described in great detail in Missing Function from Object to LDPR member section of the MembershipInferencing page.

1.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.

1.2 Potential Answers

1.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.

1.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.

1.2.2.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.

1.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?.