--- a/ldp.html Thu Feb 06 15:36:17 2014 -0500
+++ b/ldp.html Thu Feb 06 17:12:36 2014 -0500
@@ -309,18 +309,18 @@
<p></p></dd>
<dt><dfn>Linked Data Platform Basic Container</dfn> (<abbr title="Linked Data Platform Basic Container">LDP-BC</abbr>)</dt>
- <dd>An <a title="Linked Data Platform Container">LDPC</a> that uses a single pre-defined predicate to link to both
+ <dd>A <a title="Linked Data Platform Container">LDPC</a> that uses a single pre-defined predicate to link to both
its <a title="Containment">contained</a> and <a title="Membership">member</a> documents (information resources) [[!WEBARCH]].
<p></p></dd>
<dt><dfn>Linked Data Platform Direct Container</dfn> (<abbr title="Linked Data Platform Direct Container">LDP-DC</abbr>)</dt>
- <dd>An <a title="Linked Data Platform Container">LDPC</a> that has the flexibility of choosing what form its
+ <dd>A <a title="Linked Data Platform Container">LDPC</a> that has the flexibility of choosing what form its
<a title="Membership triples">membership triples</a> take, and allows <a title="Membership">members</a> to be
any resources [[!WEBARCH]], not only documents.
<p></p></dd>
<dt><dfn>Linked Data Platform Indirect Container</dfn> (<abbr title="Linked Data Platform Indirect Container">LDP-IC</abbr>)</dt>
- <dd>An <a title="Linked Data Platform Container">LDPC</a> that is similar to a <a title="Linked Data Platform Direct Container">LDP-DC</a>
+ <dd>A <a title="Linked Data Platform Container">LDPC</a> that is similar to a <a title="Linked Data Platform Direct Container">LDP-DC</a>
and is capable of accepting creation requests that result in <a title="Membership">members</a> being added based
on the content of its <a title="Containment">contained</a> documents rather than the URIs assigned to those documents.
<p></p></dd>
@@ -491,23 +491,24 @@
</p>
<section><h2>General</h2>
<section id="ldp-cli-multitype"><h2 class="normal">In the absence of special knowledge of the application or domain,
- <a title="LDP client">LDP clients</a> MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
+ <a title="LDP client">LDP clients</a> MUST assume that any LDP-RR can have multiple values for <code>rdf:type</code>.
</h2></section> <!-- Was 4.3.5 / #ldpr-4_3_5 -->
<section id="ldpr-cli-typeschange"><h2 class="normal">In the absence of special knowledge of the application or domain,
<a title="LDP client">LDP clients</a> MUST assume that the <code>rdf:type</code> values
- of a given LDPR can change over time.
+ of a given LDP-RR can change over time.
</h2></section> <!-- Was 4.3.6 / #ldpr-4_3_6 -->
<section id="ldpr-cli-openpreds"><h2 class="normal"><a title="LDP client">LDP clients</a> SHOULD always assume that the set of predicates for a
- resource of a particular type at an arbitrary server is open, in the
+ LDP-RR of a particular type at an arbitrary server is open, in the
sense that different resources of the same type may not all have the
same set of predicates in their triples, and the set of predicates that
- are used in the state of any one resource is not limited to any pre-defined
+ are used in the state of any one LDP-RR is not limited to any pre-defined
set.
</h2></section> <!-- Was 4.5.3 / #ldpr-ldpr-4_5_3 -->
- <section id="ldpr-cli-preservetriples"><h2 class="normal">A <a title="LDP client">LDP client</a> MUST preserve all triples retrieved using HTTP <code>GET</code> that
+ <section id="ldpr-cli-preservetriples"><h2 class="normal">
+ A <a title="LDP client">LDP client</a> MUST preserve all triples retrieved from an LDP-RR using HTTP <code>GET</code> that
it doesn’t change whether it understands the predicates or not, when
its intent is to perform an update using HTTP <code>PUT</code>. The use of HTTP
<code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
@@ -520,7 +521,7 @@
<h1>Linked Data Platform Resources</h1>
<section class="informative" id="ldpr-informative">
-<h2>Non-normative</h2>
+<h2>Introduction</h2>
<p>Linked Data Platform Resources (<dfn><abbr title="Linked Data Platform Resources">LDPRs</abbr></dfn>) are HTTP resources
that conform to the simple patterns and conventions in this section.
HTTP requests to access, modify, create or delete LDPRs are accepted
@@ -784,6 +785,8 @@
only when the LDPR supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
<p>Additional requirements on HTTP <code>DELETE</code> of LDPRs within containers can be found in
+ <a href="#ldpc-HTTP_DELETE" class="sectionRef"></a>.
+ </p>
</section>
<section id="ldpr-HTTP_HEAD">
@@ -1091,7 +1094,7 @@
<h1>Linked Data Platform Containers</h1>
<section class="informative" id="ldpc-informative">
-<h2>Non-normative</h2>
+<h2>Introduction</h2>
<p>Many HTTP applications and sites have organizing
concepts that partition the overall space of resources into smaller
containers. Blog posts are grouped into blogs, wiki pages are grouped
@@ -1601,24 +1604,14 @@
</h2></section><!-- Was 5.2.5.2 / #ldpc-5_2_5_2 -->
</section>
- <section id="ldpc-indirectmbr"><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) MUST contain one triple whose
+ <section id="ldpc-indirectmbr"><h2 class="normal">
+ LDP <a title="Linked Data Platform Indirect Container">Indirect</a> Containers
+ MUST contain exactly one triple whose
subject is the LDPC URI,
whose predicate is <code>ldp:insertedContentRelation</code>, and
whose object <var>ICR</var> describes how the <var>member-derived-URI</var> in
- 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>,
- <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.
- </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
+ the container's <a title="Membership triples">membership triples</a> is chosen.
+ The <var>member-derived-URI</var> is taken from some triple
<var>( S, P, O )</var> in the document supplied by the client as input to the create request;
if <var>ICR</var>'s value is <var>P</var>, then the <var>member-derived-URI</var> is
<var>O</var>. LDP does not define the behavior when more than one triple containing
@@ -1628,13 +1621,20 @@
<var>( <> , foaf:primaryTopic , bob#me )</var>
<code>foaf:primaryTopic</code> says
that the <var>member-derived-URI</var> is <var>bob#me</var>.
- </li>
- </ul>
+ </h2>
<section id="ldpc-indirectmbr-basic"><h2 class="normal">
- <a title="Linked Data Platform Basic Container">Basic</a> Containers MUST behave as if they
+ LDP
+ <a title="Linked Data Platform Basic Container">Basic</a> and
+ <a title="Linked Data Platform Direct Container">Direct</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.
+ The value <code>ldp:MemberSubject</code> means 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.
</h2></section>
</section><!-- Was 5.2.10 / #ldpc-5_2_10 -->
@@ -1917,35 +1917,37 @@
only when a LDPC supports that method. This specification does not impose any
new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
- <section id="ldpc-del-contremovesmbrtriple"><h2 class="normal">When a LDPC member resource originally created by the LDPC (for example, one whose representation
- was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server is aware of the member's deletion
- (for example, the member is managed by the same server), the LDPC server MUST also remove it from
- the LDPC by removing the corresponding membership triple.
- </h2></section><!-- Was 5.6.1 / #ldpc-5_6_1 -->
-
- <section id="ldpc-del-mbrremovesmbrtriple"><h2 class="normal">When a <a>LDP server</a> successfully completes a <code>DELETE</code> request
- on a LDPC member resource, it MUST remove any
- membership triples associated with the deleted member resource identified by the <code>Request-URI</code>.
+ <section id="ldpc-del-contremovesmbrtriple"><h2 class="normal">
+ When a LDPC contained resource is deleted, the LDPC server MUST also remove it from
+ the LDPC by removing the corresponding containment and membership triples.
</h2>
<blockquote>
- Non-normative note: The <a>LDP server</a> might perform additional removal
- of member resources, as described in the <a href="#ldp-http-method-side-effects">normative references</a> like [[HTTP11]].
+ Non-normative note: The <a>LDP server</a> might perform additional actions,
+ as described in the <a href="#ldp-http-method-side-effects">normative references</a> like [[HTTP11]].
For example, the server could perform additional cleanup tasks for resources it knows are no longer referenced or have not
been accessed for some period of time.
</blockquote>
- </section><!-- Was 5.6.2 / #ldpc-5_6_2 -->
+ </section><!-- Was 5.6.1 / #ldpc-5_6_1 -->
- <!-- TODO: No net diff between previous 2 clauses (old-5.6.1 and old-5.6.2), so combine -->
+ <!-- combined with clause above
+ <section id="ldpc-del-mbrremovesmbrtriple"><h2 class="normal">
+ When a <a>LDP server</a> successfully completes a <code>DELETE</code> request
+ on a LDPC member resource, it MUST remove any
+ membership triples associated with the deleted member resource identified by the <code>Request-URI</code>.
+ </h2> </section><!-- Was 5.6.2 / #ldpc-5_6_2 -->
+
<!-- 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
+ <!-- containment now required, handled in clause above
+ <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.
</h2></section><!-- Was 5.6.3 / #ldpc-5_6_3 -->
- <section id="ldpc-del-contremovesmbrres"><h2 class="normal">When a LDPC member resource originally created by the LDPC (for example, one whose
- representation was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server
- created an associated LDPR (see the <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>), the LDPC server MUST also remove the associated LDPR it created.
+ <section id="ldpc-del-contremovesmbrres"><h2 class="normal">
+ When a LDPC contained resource is deleted, and the LDPC server
+ created an associated LDP-RR (see the <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>), the LDPC server MUST also remove the associated LDP-RR it created.
</h2></section><!-- Was 5.6.4 / #ldpc-5_6_4 -->
</section>
@@ -2312,6 +2314,7 @@
<!-- <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 - partial first pass at arnaud's email comments (JA)</li>
<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>