Warning:
This wiki has been archived and is now read-only.
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. )
Contents
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
- do the inferencing from membership triples anyway before looking for ldp:member relations
- 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?.