--- a/ldp.html Sat Mar 01 13:50:02 2014 -0500
+++ b/ldp.html Sat Mar 01 14:51:42 2014 -0500
@@ -5,6 +5,7 @@
TODO: Add new "discovery of server capabilities" non-norm section
TODO: Consider folding LDP Clients section, feels a bit out of place
TODO: Consider creating LDPR sub sections R, RS, NR like LDPCs
+ TODO: Consider adding Venn diagram for differences of LDPCs
-->
<html>
<head>
@@ -543,36 +544,20 @@
</section>
+<section id="ldpr-resource">
+<h2>Resource</h2>
+
<section id="ldpr-general">
<h2>General</h2>
<section id="ldpr-gen-http"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].
</h2></section><!-- Was 4.2.1 / #ldpr-4_2_1 -->
- <section id="ldpr-gen-rdf"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide an RDF representation for <a title="Linked Data Platform RDF Source">LDP-RSs</a>.
- The HTTP <code>Request-URI</code> of the LDP-RS is typically the subject of most triples in the response.
- </h2></section><!-- Was 4.2.2 / #ldpr-4_2_2 -->
-
<section id="ldpr-gen-binary"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY host a mixture of LDPRs, <a title="Linked Data Platform RDF Source">LDP-RSs</a>
and <a title="Linked Data Platform Non-RDF Source">LDP-NRs</a>. For example, it
is common for <a title="LDP server">LDP servers</a> to need to host binary or text resources
that do not have useful RDF representations.</h2></section><!-- Was 4.2.3 / #ldpr-4_2_3 -->
- <section id="ldpr-gen-reusevocab"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> SHOULD reuse existing vocabularies instead of creating
- their own duplicate vocabulary terms. In addition to this general rule, some specific cases are
- covered by other conformance rules.
- </h2></section><!-- Was 4.2.4 / #ldpr-4_2_4 -->
-
- <section id="ldpr-gen-reusevocabsuchas"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> predicates SHOULD use standard vocabularies such as Dublin Core
- [[!DC-TERMS]], RDF [[!rdf11-concepts]] and RDF Schema [[!rdf-schema]], whenever
- possible.
- </h2></section><!-- Was 4.2.4.1 / #ldpr-4_2_4_1 -->
-
- <section id="ldpr-gen-atleast1rdftype"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> representations SHOULD have at least one <code>rdf:type</code>
- set explicitly. This makes the representations much more useful to
- client applications that don’t support inferencing.
- </h2></section><!-- Was 4.2.5 / #ldpr-4_2_5 -->
-
<section id="ldpr-gen-etags"><h2 class="normal"><a title="LDP server">LDP server</a> responses MUST use entity tags (either
weak or strong ones) as response <code>ETag</code> header values.
</h2></section><!-- Was 4.2.8 / #ldpr-4_2_8 -->
@@ -605,14 +590,7 @@
individually inspected, in the absence of outside information.
</p>
</blockquote>
-
- <section id="ldpr-gen-noinferencing"><h2 class="normal"><a title="LDP server">LDP servers</a>
- MUST NOT require LDP clients to implement inferencing in order to recognize the subset
- of content defined by LDP. Other specifications built on top of LDP may require clients
- to implement inferencing [[!rdf11-concepts]]. The practical implication is that all content defined by LDP
- must be explicitly represented, unless noted otherwise within this document.
- </h2></section><!-- Was 4.2.11 / #ldpr-4_2_11 -->
-
+
<section id="ldpr-gen-defbaseuri"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST assign the default
base-URI for [[!RFC3987]] relative-URI resolution to be the HTTP
<code>Request-URI</code> when the resource already exists, and to the URI of the created resource when the request results
@@ -643,10 +621,6 @@
<a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
</h2></section><!-- Was 4.3.2 / #ldpr-4_3_2 -->
- <section id="ldpr-get-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide a <code>text/turtle</code>
- representation of the requested <a title="Linked Data Platform RDF Source">LDP-RS</a> [[!turtle]].
- </h2></section><!-- Was 4.3.3 / #ldpr-4_3_3 -->
-
</section>
<section id="ldpr-HTTP_POST">
@@ -680,6 +654,7 @@
<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
</p>
+ <!-- TODO: Should we move these to LDP-RS section? They are generic enough. -->
<section id="ldpr-put-replaceall"><h2 class="normal">If a HTTP <code>PUT</code> is accepted on an existing resource,
<a title="LDP server">LDP servers</a> MUST
replace the entire persistent state of the identified resource with
@@ -691,24 +666,7 @@
with existing state stored on the server for a resource MUST use HTTP
<code>PATCH</code>, not HTTP <code>PUT</code>.
</h2></section><!-- Was 4.5.1 / #ldpr-4_5_1 -->
-
- <section id="ldpr-put-servermanagedprops"><h2 class="normal">
- If an otherwise valid HTTP <code>PUT</code> request is received
- that attempts to change triples the server does not allow clients to modify,
- <a title="LDP server">LDP servers</a> MUST
- respond with a 4xx range status code (typically
- 409 Conflict).
- <a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
- information about which triples could not be
- persisted.
- The format of the 4xx response body is not constrained by LDP.
- </h2></section><!-- Was 4.5.1.1 / #ldpr-4_5_1_1 -->
- <blockquote>
- Non-normative note: Clients might provide triples equivalent to those already in the resource's state,
- e.g. as part of a GET/update representation/PUT sequence, and those PUT requests are intended to work as long as the
- server-controlled triples are identical on the GET response and the subsequent PUT request.
- </blockquote>
-
+
<section id="ldpr-put-precond"><h2 class="normal"><a title="LDP client">LDP clients</a> SHOULD use the HTTP <code>If-Match</code>
header and HTTP <code>ETags</code> to ensure it isn’t
modifying a resource that has changed since the client last retrieved
@@ -719,18 +677,6 @@
(Precondition Required) when the absence of a precondition is the only reason for rejecting the request [[!RFC6585]].
</h2></section><!-- Was 4.5.2 / #ldpr-4_5_2 -->
- <section id="ldpr-put-failed"><h2 class="normal">
- If an otherwise valid HTTP <code>PUT</code> request is received that contains triples the server
- chooses not to persist, e.g. unknown content,
- <a title="LDP server">LDP servers</a> MUST respond with an appropriate 4xx range status code
- [[HTTP11]].
- <a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
- information about which triples could not be
- persisted.
- The format of the 4xx response body is not constrained by LDP. LDP servers
- expose these application-specific constraints as described in <a href="#ldpr-general" class="sectionRef"></a>.
- </h2></section><!-- Was 4.5.4 / #ldpr-4_5_4 -->
-
<section id="ldpr-put-create"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY choose to allow the creation of new resources using HTTP <code>PUT</code>.
</h2></section><!-- Was 4.5.6 / #ldpr-4_5_6 -->
@@ -804,7 +750,121 @@
</section> <!-- h2 -->
-</section> <!-- h1 -->
+</section> <!-- ldpr-resource -->
+
+<section id="ldprs">
+<h2>RDF Source</h2>
+
+<p>The following section contains normative clauses for <a title="">Linked Data Platform RDF Source</a>.</p>
+
+<section id="ldprs-general">
+<h2>General</h2>
+
+ <section id="ldprs-are-ldpr"><h2 class="normal">Each <a title="Linked Data Platform RDF Resource">LDP RDF Source</a> MUST also be
+ a conforming <a title="Linked Data Platform Resource">LDP Resource</a> in <a href="#ldpr-resource" class="sectionRef"></a> along the
+ following restrictions in this section. <a title="">LDP client</a>s MAY infer the following triple:
+ whose subject is <code>ldp:RDFSource</code>,
+ whose predicate is <code>rdfs:subClassOf</code>,
+ and whose object is <code>ldp:Resource</code>,
+ but there is no requirement to materialize this triple in the LDP-RS representation.
+ </h2></section>
+
+ <section id="ldprs-gen-atleast1rdftype"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> representations SHOULD have at least one <code>rdf:type</code>
+ set explicitly. This makes the representations much more useful to
+ client applications that don’t support inferencing.
+ </h2></section><!-- Was 4.2.5 / #ldpr-4_2_5 -->
+
+ <section id="ldpc-typecontainer"><h2 class="normal">The representation of an LDP-RS MAY have an <code>rdf:type</code>
+ of only one of <code>ldp:RDFSource</code> for <a title="">Linked Data Platform RDF Source</a>.
+ </h2></section><!-- Was 5.2.7 / #ldpc-5_2_7 -->
+
+ <section id="ldprs-gen-rdf"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide an RDF representation for <a title="Linked Data Platform RDF Source">LDP-RSs</a>.
+ The HTTP <code>Request-URI</code> of the LDP-RS is typically the subject of most triples in the response.
+ </h2></section><!-- Was 4.2.2 / #ldpr-4_2_2 -->
+
+ <section id="ldprs-gen-reusevocab"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> SHOULD reuse existing vocabularies instead of creating
+ their own duplicate vocabulary terms. In addition to this general rule, some specific cases are
+ covered by other conformance rules.
+ </h2></section><!-- Was 4.2.4 / #ldpr-4_2_4 -->
+
+ <section id="ldprs-gen-reusevocabsuchas"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> predicates SHOULD use standard vocabularies such as Dublin Core
+ [[!DC-TERMS]], RDF [[!rdf11-concepts]] and RDF Schema [[!rdf-schema]], whenever
+ possible.
+ </h2></section><!-- Was 4.2.4.1 / #ldpr-4_2_4_1 -->
+
+ <section id="ldprs-gen-noinferencing"><h2 class="normal"><a title="LDP server">LDP servers</a>
+ MUST NOT require LDP clients to implement inferencing in order to recognize the subset
+ of content defined by LDP. Other specifications built on top of LDP may require clients
+ to implement inferencing [[!rdf11-concepts]]. The practical implication is that all content defined by LDP
+ must be explicitly represented, unless noted otherwise within this document.
+ </h2></section><!-- Was 4.2.11 / #ldpr-4_2_11 -->
+
+</section> <!-- ldprs-general -->
+
+<section id="ldprs-HTTP_GET">
+<h2>HTTP GET</h2>
+ <section id="ldprs-get-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide a <code>text/turtle</code>
+ representation of the requested <a title="Linked Data Platform RDF Source">LDP-RS</a> [[!turtle]].
+ </h2></section><!-- Was 4.3.3 / #ldpr-4_3_3 -->
+
+</section> <!-- ldprs-HTTP_GET -->
+
+<section id="ldprs-HTTP_PUT">
+<h2>HTTP PUT</h2>
+
+<!-- TODO: Should we make them apply to non-RDF as well? -->
+ <section id="ldprs-put-servermanagedprops"><h2 class="normal">
+ If an otherwise valid HTTP <code>PUT</code> request is received
+ that attempts to change triples the server does not allow clients to modify,
+ <a title="LDP server">LDP servers</a> MUST
+ respond with a 4xx range status code (typically
+ 409 Conflict).
+ <a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
+ information about which triples could not be
+ persisted.
+ The format of the 4xx response body is not constrained by LDP.
+ </h2></section><!-- Was 4.5.1.1 / #ldpr-4_5_1_1 -->
+ <blockquote>
+ Non-normative note: Clients might provide triples equivalent to those already in the resource's state,
+ e.g. as part of a GET/update representation/PUT sequence, and those PUT requests are intended to work as long as the
+ server-controlled triples are identical on the GET response and the subsequent PUT request.
+ </blockquote>
+
+ <section id="ldprs-put-failed"><h2 class="normal">
+ If an otherwise valid HTTP <code>PUT</code> request is received that contains triples the server
+ chooses not to persist, e.g. unknown content,
+ <a title="LDP server">LDP servers</a> MUST respond with an appropriate 4xx range status code
+ [[HTTP11]].
+ <a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
+ information about which triples could not be
+ persisted.
+ The format of the 4xx response body is not constrained by LDP. LDP servers
+ expose these application-specific constraints as described in <a href="#ldpr-general" class="sectionRef"></a>.
+ </h2></section><!-- Was 4.5.4 / #ldpr-4_5_4 -->
+
+</section> <!-- ldprs-HTTP_PUT -->
+
+</section> <!-- ldprs RDF Source-->
+
+<section id="ldpnr">
+<h2>Non-RDF Source</h2>
+
+<p>The following section contains normative clauses for <a title="">Linked Data Platform Non-RDF Source</a>.</p>
+
+<section id="ldpnr-general">
+<h2>General</h2>
+
+ <section id="ldpnr-are-ldpr"><h2 class="normal">Each <a title="Linked Data Platform Non-RDF Source">LDP Non-RDF Source</a> MUST also be
+ a conforming <a title="Linked Data Platform Resource">LDP Resource</a> in <a href="#ldpr-resource" class="sectionRef"></a>.
+ <a title="Linked Data Platform Non-RDF Source">LDP Non-RDF Source</a> may not be able to fully express their
+ state using RDF. [[rdf11-concepts]]
+ </h2></section>
+
+</section> <!-- ldpnr Non-RDF Source-->
+
+</section>
+
+</section> <!-- ldpr h1 -->
<section id="ldpc">
<h1>Linked Data Platform Containers</h1>
@@ -2152,6 +2212,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-03-01 - Split out different kinds of LDPRs into their own subsection (SS)</li>
<li>2014-02-28 - Combined rules for container triples (SS) </li>
<li>2014-02-28 - Split out different kinds of LDPCs into their own subsection (SS)</li>
<li>2014-02-24 - Corrected rel=meta to be rel=describedby (SS) </li>