Difference between revisions of "Issue-88"

From Linked Data Platform
Jump to: navigation, search
(Created page with "= ISSUE-88: Lost link to the resource created via POST = [https://www.w3.org/2012/ldp/track/issues/88 ISSUE-88] was described in great detail in [http://www.w3.org/2012/ldp/wik…")
 
(ISSUE-88: Lost link to the resource created via POST)
Line 1: Line 1:
 
= ISSUE-88: Lost link to the resource created via POST =
 
= ISSUE-88: Lost link to the resource created via POST =
 +
 +
( 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. )
  
 
[https://www.w3.org/2012/ldp/track/issues/88 ISSUE-88]  was described in great detail in
 
[https://www.w3.org/2012/ldp/track/issues/88 ISSUE-88]  was described in great detail in
 
[http://www.w3.org/2012/ldp/wiki/MembershipInferencing#missing_function_from_object_to_LDPR_member Missing Function from Object to LDPR member] section of the MembershipInferencing page.
 
[http://www.w3.org/2012/ldp/wiki/MembershipInferencing#missing_function_from_object_to_LDPR_member Missing Function from Object to LDPR member] section of the MembershipInferencing page.
 +
 +
== Overview ==
  
 
It is important to understand the cause of the problem. It is due to the implicit existence of a rule from
 
It is important to understand the cause of the problem. It is due to the implicit existence of a rule from
Line 22: Line 27:
 
}
 
}
 
</pre>
 
</pre>
This problem could not exist if such a rule were not existing.
+
This problem could not exist if such a rule were not implied.  
  
== make ldp:member mandatory when ldp:insertedContentRelation is different from ldp:MemberSubject ==
+
== Potential Answers ==
 +
 
 +
=== 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 .
 
This is a hack around the problems caused by the rule from "membership triples" => ldp:member .
Line 30: Line 37:
 
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
 
   1. do the inferencing from membership triples anyway before looking for ldp:member relations
   2. look for ldp:member relations
+
   2. then look for ldp:member relations, anyway.
 +
 
 +
=== 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 [http://lists.w3.org/Archives/Public/public-ldp/2013Nov/0009.html LDPC as SPARQL endpoint story]
 +
 
 +
How does one recover the membership triples? This depends on how one thinks of the membership triples.
 +
 
 +
==== ldp:member => membership triples rule ====
 +
A simple rule such as
 +
 
 +
<pre>
 +
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 .
 +
  }
 +
}
 +
</pre>
 +
 
 +
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.
 +
 
 +
==== 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:
 +
 
 +
<pre>
 +
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
 +
  }
 +
}
 +
</pre>
  
== make ldp:member mandatory ==
+
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.
  
T
+
This is the correct interpretation if one decides to do nothing with [http://www.w3.org/2012/ldp/track/issues/87  Issue-87: What happens when the membership triples are modified?].

Revision as of 11:31, 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?.