--- a/ldp.html Thu Feb 06 13:14:15 2014 -0500
+++ b/ldp.html Thu Feb 06 15:36:17 2014 -0500
@@ -329,13 +329,6 @@
<dd>The relationship linking an LDP-RR (LDPCs are also LDP-RRs) and its member LDPRs.
There often is a linked LDPC that assists with managing the member LDPRs.<p></p></dd>
- <dt><dfn>Containment</dfn></dt>
- <dd>The relationship binding an LDPC to its contained LDPRs. The
- lifecycle of the contained LDPR is limited by the lifecycle of the containing LDPC;
- that is, a contained LDPR cannot be created before its containing LDPC exists, nor
- does a contained LDPR continue to exist after its containing LDPC is deleted.
- <p></p></dd>
-
<dt><dfn>Membership triples</dfn></dt>
<dd>A set of triples in an LDPC's state that lists its members.
A container's membership triples all have one of the following patterns:
@@ -368,6 +361,18 @@
<dd>The predicate of all a LDPC's <a title="Membership triples">membership triples</a>.
<p></p></dd>
+ <dt><dfn>Containment</dfn></dt>
+ <dd>The relationship binding an LDPC to LDPRs whose lifecycle it controls and is aware of. The
+ lifecycle of the contained LDPR is limited by the lifecycle of the containing LDPC;
+ that is, a contained LDPR cannot be created (through LDP-defined means) before its containing LDPC exists.
+ <p></p></dd>
+
+ <dt><dfn>Containment triples</dfn></dt>
+ <dd>
+ A set of triples in an LDPC's state, maintained by the LDPC, that lists documents created by the LDPC but not yet deleted.
+ These triples <strong>always</strong> have the form: <var>( LDPC URI, ldp:contains , document-URI )</var>.
+ <p></p></dd>
+
<dt><dfn>Non-member resource</dfn></dt>
<dd>A HTTP resource associated with a LDPC by a server for the purpose of enabling clients to
retrieve a subset of the LDPC's state, namely the subset that omits the LDPC's membership triples.
@@ -1298,9 +1303,9 @@
<advisorContainer/>
a ldp:Container, ldp:IndirectContainer;
- dcterms:title "The assets of JohnZSmith";
+ dcterms:title "The asset advisors of JohnZSmith";
ldp:containerResource <>;
- ldp:containsRelation o:asset;
+ ldp:containsRelation o:advisor;
ldp:insertedContentRelation foaf:primaryTopic;
ldp:contains
<advisorContainer/bob>,
@@ -1540,20 +1545,23 @@
<!-- TODO: Leaving this as-is, refining others as-needed. Do we need an explicit clause for "ldp:contains"?
-->
- <section id="ldpc-containres"><h2 class="normal">An LDPC representation MUST contain exactly one triple
+ <section id="ldpc-containres"><h2 class="normal">Each <a title="Linked Data Platform Direct Container">LDP Direct Container</a>
+ and <a title="Linked Data Platform Indirect Container">LDP Indirect Container</a> representation MUST contain exactly one triple
whose subject is the LDPC URI,
whose predicate is the <code>ldp:containerResource</code>,
- and whose object is the LDPC's membership-constant-URI.
- Commonly the LDPC's URI is the membership-constant-URI, but LDP does not require this except for <a title="Linked Data Platform Basic Container">LDP-BCs</a>.
+ and whose object is the LDPC's <var>membership-constant-URI</var>.
+ Commonly the LDPC's URI is the <var>membership-constant-URI</var>, but LDP does not require this.
</h2>
- <section id="ldpc-containres-basic"><h2 class="normal">For <a title="Linked Data Platform Basic Container">LDP-BCs</a>, the triple MUST be
- where the subject is the LDPC URI,
- whose predicate is the <code>ldp:containerResource</code>,
- and whose object is the LDPC URI itself.
+ <section id="ldpc-containres-basic"><h2 class="normal"><a title="Linked Data Platform Basic Container">LDP-BCs</a> MUST
+ behave as if their state contains the triple
+ whose subject is the LDPC URI,
+ whose predicate is <code>ldp:containerResource</code>,
+ and whose object is the LDPC URI (subject and object are the same URI),
+ but there is no requirement to materialize this triple in LDP-BC representations.
</h2></section>
</section><!-- Was 5.2.4 / #ldpc-5_2_4 -->
- <section id="ldpc-containtriples"><h2 class="normal">An <a title="Linked Data Platform Direct Container">LDP Direct Container</a>
+ <section id="ldpc-containtriples"><h2 class="normal">Each <a title="Linked Data Platform Direct Container">LDP Direct Container</a>
and <a title="Linked Data Platform Indirect Container">LDP Indirect Container</a> representation MUST contain exactly one triple
whose subject is the LDPC URI,
and whose predicate is either <code>ldp:containsRelation</code> or <code>ldp:containedByRelation</code>.
@@ -1570,9 +1578,17 @@
pattern is <var>( membership-constant-URI , membership-predicate , member-derived-URI )</var> MUST
contain exactly one triple
whose subject is the LDPC URI,
- whose predicate is either <code>ldp:containsRelation</code>,
+ whose predicate is <code>ldp:containsRelation</code>,
and whose object is the URI of <var>membership-predicate</var>.
- </h2></section><!-- Was 5.2.5.1 / #ldpc-5_2_5_1 -->
+ </h2>
+ <section id="ldpc-containtriple-basic"><h2 class="normal"><a title="Linked Data Platform Basic Container">LDP-BCs</a> MUST
+ behave as if their state contains the triple
+ whose subject is the LDPC URI,
+ whose predicate is <code>ldp:containsRelation</code>,
+ and whose object is <code>ldp:member</code>,
+ but there is no requirement to materialize this triple in LDP-BC representations.
+ </h2></section>
+ </section><!-- Was 5.2.5.1 / #ldpc-5_2_5_1 -->
<section id="ldpc-containtriple-byrelation"><h2 class="normal">LDPCs (<a title="Linked Data Platform Direct Container">Direct</a>
and <a title="Linked Data Platform Indirect Container">Indirect</a> Containers only)
@@ -1593,13 +1609,13 @@
the container's <a title="Membership triples">membership triples</a> is chosen.</h2>
<ul>
<li>
- For <a title="Linked Data Platform Direct Container">LDP Direct Containers</a>, the URI <code>ldp:MemberSubject</code> the
- <var>member-derived-URI</var> is simply the URI assigned by the server to a
- document it creates; for example, if the client POSTs RDF content to a container
+ For <a title="Linked Data Platform Direct Container">LDP Direct Containers</a>,
+ <var>ICR</var> MUST have the value <code>ldp:MemberSubject</code>, meaning that
+ the
+ <var>member-derived-URI</var> is the URI assigned by the server to a
+ document it creates; for example, if the client POSTs content to a container
that causes the container to create a new LDPR, <code>ldp:MemberSubject</code> says
that the <var>member-derived-URI</var> is the URI assigned to the newly created LDPR.
- LDPCs MUST use the URI <code>ldp:MemberSubject</code> when the <var>member-derived-URI</var>
- is chosen in this way.
</li>
<li>
For <a title="Linked Data Platform Direct Container">LDP Indirect Containers</a>, the <var>member-derived-URI</var> is taken from some triple
@@ -1614,6 +1630,12 @@
that the <var>member-derived-URI</var> is <var>bob#me</var>.
</li>
</ul>
+
+ <section id="ldpc-indirectmbr-basic"><h2 class="normal">
+ <a title="Linked Data Platform Basic Container">Basic</a> Containers MUST behave as if they
+ have a <var>( LDPC URI, <code>ldp:insertedContentRelation</code> , <code>ldp:MemberSubject</code> )</var>
+ triple, but LDP imposes no requirement to materialize such a triple in representations.
+ </h2></section>
</section><!-- Was 5.2.10 / #ldpc-5_2_10 -->
<section id="ldpc-linktypehdr"><h2 class="normal"><a title="LDP server">LDP servers</a>
@@ -1732,12 +1754,20 @@
entity body on a 201 (Created) response.
</h2></section><!-- Was 5.4.1 / #ldpc-5_4_1 -->
- <section id="ldpc-post-createdmbr"><h2 class="normal">After a successful HTTP <code>POST</code> request to a LDPC,
+ <section id="ldpc-post-createdmbr-contains"><h2 class="normal">
+ When a successful HTTP <code>POST</code> request to a LDPC
+ results in the creation of an LDPR,
the newly created document MUST
appear as a contained resource of the LDPC until the newly created document is deleted or
- removed by other methods. An LDPC's membership MAY also include resources that were
- added through other means - for example through the user interface of
- the site that implements the LDPC.
+ removed by other methods.
+ </h2></section>
+
+ <section id="ldpc-post-createdmbr-member"><h2 class="normal">
+ When a successful HTTP <code>POST</code> request to a LDPC results in the creation of an LDPR,
+ the LDPC MUST update its membership triples to reflect that addition, and the resulting
+ membership triple MUST be consistent with any LDP-defined predicates it exposes.
+ A Direct or Indirect container's membership triples MAY also be modified via
+ through other means.
</h2></section><!-- Was 5.4.2 / #ldpc-5_4_2 -->
<!-- TODO: "contained resource" is not the right term here, an example of where ldp:containedResource would be better
@@ -1746,13 +1776,13 @@
<section id="ldpc-post-createbins"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY accept an HTTP <code>POST</code> of non-RDF representations
<a title="Linked Data Platform Binary Resource">(LDP-BRs)</a> for
- creation of any kind of resource, for example binary resources. See <a href="#ldpc-post-acceptposthdr">AcceptPost section</a> for
+ creation of any kind of resource, for example binary resources. See <a href="#ldpc-post-acceptposthdr">the Accept-Post section</a> for
details on how clients can discover whether a LDPC supports this behavior.
</h2></section><!-- Was 5.4.3 / #ldpc-5_4_3 -->
<section id="ldpc-post-createrdf"><h2 class="normal"><a title="LDP server">LDP servers</a> that successfully create a resource from a
RDF representation in the request entity body MUST honor the client's requested interaction model(s). The created resource
- MUST be an RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[rdf11-concepts]].
+ can be thought of as an RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[rdf11-concepts]].
If any model cannot be honored, the server MUST fail the request.
</h2><!-- Was 5.4.4 / #ldpc-5_4_4 -->
<ul>
@@ -1876,7 +1906,7 @@
<section id="ldpc-put-create"><h2 class="normal"><a title="LDP server">LDP servers</a> that allow member creation via <code>PUT</code>
SHOULD NOT re-use URIs. For RDF representations (LDP-RRs),the created resource
- MUST be an RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[rdf11-concepts]].
+ can be thought of as a RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[rdf11-concepts]].
</h2></section><!-- Was 5.5.4 / #ldpc-5_5_4 -->
</section>
@@ -1905,6 +1935,9 @@
</blockquote>
</section><!-- Was 5.6.2 / #ldpc-5_6_2 -->
+ <!-- TODO: No net diff between previous 2 clauses (old-5.6.1 and old-5.6.2), so combine -->
+ <!-- TODO: All these constraints apply only to LDPC contained resources being deleted, so clarify that up front of the section hey? -->
+
<section id="ldpc-del-ldpcreated"><h2 class="normal">When the conditions in <a href="#ldpc-del-contremovesmbrtriple">previous section</a> hold, and the LDPC tracks member
resources that it created using the <code>ldp:contains</code> predicate, the LDPC server MUST also remove
the deleted member's <code>ldp:contains</code> triple.
@@ -2279,6 +2312,10 @@
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130730/">Last Call Draft</a></em></blockquote> -->
<ul>
+ <li>2014-02-06 - fixing containment def, adding containment triples to terminology (JA)</li>
+ <li>2014-02-06 - fixing POST to create containment/membership triples, which was mangled (JA)</li>
+ <li>2014-02-06 - fully aligning SS changes with http://www.w3.org/2012/ldp/wiki/Containers for basic containers, allowing them to omit the standard predicates in representations despite requiring behavior consistent with the presence of those triples (JA)</li>
+ <li>2014-02-06 - editorial fixes (JA)</li>
<li>2014-02-06 - ACTION-127 (complete) use the TAG's new [23]xx code; if that code is not sufficiently through IETF process by CR, we will use a 303 (JA)</li>
<li>2014-02-05 - ACTION-133 Get rid of ldp:created which is subsumed by ldp:contains (SS)</li>
<li>2014-02-04 - ACTION-124 LDPR-RR as named graphs (SS)</li>