--- a/ldp.html Tue Jul 23 10:13:09 2013 -0400
+++ b/ldp.html Tue Jul 23 16:17:25 2013 -0400
@@ -12,6 +12,8 @@
defined in section 4.8 .
->
defined in section 4.8.
+ - The ReSpec SPARQL QUERY link is http://www.w3.org/TR/rdf-sparql-query/ , which has highlighted text
+ referring readers to SPARQL 1.1. Which normative reference do we want?
Various pre-LC comments:
- John A's comments http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0054.html
http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0056.html
@@ -177,7 +179,7 @@
data model.
</section>
-<section>
+<section class="informative">
<h1 id="intro">Introduction</h1>
<p>This document describes the use
of HTTP for accessing, updating, creating and deleting resources from
@@ -307,7 +309,7 @@
<p>The status of the sections of Linked Data Platform 1.0 (this document) is as follows:</p>
<ul>
<li>1. Introduction: <b>informative</b></li>
- <li>2. Terminology: <b>informative</b></li>
+ <li>2. Terminology: <b>normative</b></li>
<li>3. Conformance: <b>normative</b></li>
<li>4. Linked Data Platform Resources: <b>normative</b></li>
<li>5. Linked Data Platform Containers: <b>normative</b></li>
@@ -331,6 +333,9 @@
<section>
<h1 id="ldpr">Linked Data Platform Resources</h1>
+
+<section class="informative">
+<h2 id="ldpr-informative">Informative</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
@@ -365,52 +370,47 @@
guidelines for use of LDPRs. This document also explains how to include
information about each member in the resource’s own representation
and how to paginate the resource representation if it gets too big.</p>
-
+
+</section>
+
<section>
<h2 id="ldpr-general">General</h2>
- <div id="ldpr-4_1_1" class="rule">4.1.1 LDPR servers MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].</div>
- <div id="ldpr-4_1_2" class="rule">4.1.2 LDPR servers MUST provide an RDF representation for LDPRs.
+ <div id="ldpr-4_2_1" class="rule">4.2.1 LDPR servers MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].</div>
+ <div id="ldpr-4_2_2" class="rule">4.2.2 LDPR servers MUST provide an RDF representation for LDPRs.
The HTTP <code>Request-URI</code> of the LDPR is typically the subject of most triples in the response.
</div>
- <div id="ldpr-4_1_3" class="rule">4.1.3 LDPR servers MAY host a mixture of LDPRs and non-LDPRs. For example, it
+ <div id="ldpr-4_2_3" class="rule">4.2.3 LDPR servers MAY host a mixture of LDPRs and non-LDPRs. For example, it
is common for LDPR servers to need to host binary or text resources
that do not have useful RDF representations.
</div>
- <div id="ldpr-4_1_4" class="rule">4.1.4 LDPRs SHOULD reuse existing vocabularies instead of creating
+ <div id="ldpr-4_2_4" class="rule">4.2.4 LDPRs 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.
</div>
- <div id="ldpr-4_1_4_1" class="rule">4.1.4.1 LDPR predicates SHOULD use standard vocabularies such as Dublin Core
+ <div id="ldpr-4_2_4_1" class="rule">4.2.4.1 LDPR predicates SHOULD use standard vocabularies such as Dublin Core
[[!DC-TERMS]], RDF [[!RDF-CONCEPTS]] and RDF Schema [[!RDF-SCHEMA]], whenever
possible.
</div>
- <div id="ldpr-4_1_5" class="rule">4.1.5 LDPR representations SHOULD have at least one <code>rdf:type</code>
+ <div id="ldpr-4_2_5" class="rule">4.2.5 LDPR 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.
</div>
- <div id="ldpr-4_1_6" class="rule">4.1.6 LDPR servers MAY support standard representations beyond those
+ <div id="ldpr-4_2_6" class="rule">4.2.6 LDPR servers MAY support standard representations beyond those
necessary to conform to this specification. These
could be other RDF formats, like N3 or NTriples, but non-RDF formats
like HTML [[!HTML401]] and JSON [[!RFC4627]] would likely be common.
- </div>
-
- <div id="ldpr-4_1_7" class="rule">4.1.7 LDPRs MAY be created, updated and deleted using methods not defined in
+ </div>
+ <div id="ldpr-4_2_7" class="rule">4.2.7 LDPRs MAY be created, updated and deleted using methods not defined in
this document, for example through application-specific means, SPARQL
UPDATE, etc. [[!SPARQL-UPDATE]], as long as those methods do not conflict with this specification's
normative requirements.
</div>
- <div id="ldpr-4_1_8" class="rule">4.1.8 LDPR server responses MUST use entity tags (either weak or strong
+ <div id="ldpr-4_2_8" class="rule">4.2.8 LDPR server responses MUST use entity tags (either weak or strong
ones) as response <code>ETag</code> header values.
</div>
-
- <div class="ldp-issue-pending">
- <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/32">ISSUE-32</a></div>
- How can clients discover that a resource is an LDPR or LDPC, and what features are supported?
- </div>
-
- <div id="ldpr-4_1_9" class="rule">4.1.9 LDPR
+ <div id="ldpr-4_2_9" class="rule">4.2.9 LDPR
servers SHOULD enable simple creation and modification of LDPRs.
It is
common for LDPR servers to put restrictions on representations – for
@@ -421,13 +421,7 @@
that can modify resources. For some server applications, excessive
constraints on modification of resources may be required.
</div>
-
-<div class="ldp-issue-pending">
- <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/57">ISSUE-57</a></div>
- How can a client determine that it is in communication with an LDP server?
- </div>
-
- <div id="ldpr-4_1_10" class="rule">4.1.10 LDPR servers
+ <div id="ldpr-4_2_10" class="rule">4.2.10 LDPR servers
MUST advertise their LDP support by exposing a HTTP <code>Link</code> header
with a target URI of <code>http://www.w3.org/ns/ldp/Resource</code>, and
a link relation type of <code>type</code> (that is, <code>rel="type"</code>)
@@ -436,17 +430,12 @@
presence of a <var>(subject-URI, <code>rdf:type</code>, <code>ldp:Resource</code>)</var> triple in the resource.
The HTTP <code>Link</code> header is the method by which servers assert their support for the LDP specification in a way
that clients can introspect dynamically at run-time. Conservative clients should note that
- <a href="#ldpr-4_1_3">a server can host a mixture of LDPRs and other resources</a>, and therefore there is no implication
+ <a href="#ldpr-4_2_3">a server can host a mixture of LDPRs and other resources</a>, and therefore there is no implication
that LDP support advertised on one HTTP <code>Request-URI</code> means that other
resources on the same server are also LDPRs. Each HTTP <code>Request-URI</code> needs to be
individually introspected by a conservative client, in the absence of outside information.
</div>
-<div class="ldp-issue-pending">
- <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/78">ISSUE-78</a></div>
- inferencing levels
- </div>
-
- <div id="ldpr-4_1_11" class="rule">4.1.11 LDPR servers
+ <div id="ldpr-4_2_11" class="rule">4.2.11 LDPR servers
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 [[!RDF-CONCEPTS]]. The practical implication is that all content defined by LDP
@@ -457,20 +446,20 @@
<section>
<h2 id="ldpr-HTTP_GET">HTTP GET</h2>
- <div id="ldpr-4_2_1" class="rule">4.2.1 LDPR servers MUST support the HTTP <code>GET</code> Method for LDPRs.
+ <div id="ldpr-4_3_1" class="rule">4.3.1 LDPR servers MUST support the HTTP <code>GET</code> Method for LDPRs.
</div>
- <div id="ldpr-4_2_2" class="rule">4.2.2 LDPR servers SHOULD provide a <code>text/turtle</code>
+ <div id="ldpr-4_3_2" class="rule">4.3.2 LDPR servers SHOULD provide a <code>text/turtle</code>
representation of the requested LDPR [[!TURTLE]].
</div>
- <div id="ldpr-4_2_3" class="rule">4.2.3 LDPR servers MAY provide
+ <div id="ldpr-4_3_3" class="rule">4.3.3 LDPR servers MAY provide
representations of the requested LDPR beyond those
necessary to conform to this specification, using standard HTTP content negotiation.
If the client does not indicate a preference, <code>text/turtle</code> SHOULD be returned.
</div>
- <div id="ldpr-4_2_4" class="rule">4.2.4 In the absence of special knowledge of the application or domain, LDPR
+ <div id="ldpr-4_3_4" class="rule">4.3.4 In the absence of special knowledge of the application or domain, LDPR
clients MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
</div>
- <div id="ldpr-4_2_5" class="rule">4.2.5 In the absence of special knowledge of the application or domain, LDPR
+ <div id="ldpr-4_3_5" class="rule">4.3.5 In the absence of special knowledge of the application or domain, LDPR
clients MUST assume that the <code>rdf:type</code> values
of a given LDPR can change over time.
</div>
@@ -492,7 +481,7 @@
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>
- <div id="ldpr-4_4_1" class="rule">4.4.1 If HTTP <code>PUT</code> is performed on an existing resource, LDPR servers MUST
+ <div id="ldpr-4_5_1" class="rule">4.5.1 If HTTP <code>PUT</code> is performed on an existing resource, LDPR servers MUST
replace the entire persistent state of the identified resource with
the entity representation in the body of the request.
LDPR servers MAY ignore server managed properties such as <code>dcterms:modified</code>
@@ -503,7 +492,7 @@
<code>PATCH</code>, not HTTP <code>PUT</code>.
</div>
- <div id="ldpr-4_4_2" class="rule">4.4.2 LDPR clients SHOULD use the HTTP <code>If-Match</code>
+ <div id="ldpr-4_5_2" class="rule">4.5.2 LDPR clients 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
its representation. LDPR servers SHOULD require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
@@ -512,30 +501,30 @@
errors with the request [[!HTTP11]]. LDPR servers that require conditional requests MUST respond with status code 428
(Precondition Required) when the absence of a precondition is the only reason for rejecting the request [[!RFC6585]].
</div>
- <div id="ldpr-4_4_3" class="rule">4.4.3 LDPR clients SHOULD always assume that the set of predicates for a
+ <div id="ldpr-4_5_3" class="rule">4.5.3 LDPR clients SHOULD always assume that the set of predicates for a
resource 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
set.
</div>
- <div id="ldpr-4_4_4" class="rule">4.4.4 LDPR clients SHOULD assume that an LDPR server could discard triples
+ <div id="ldpr-4_5_4" class="rule">4.5.4 LDPR clients SHOULD assume that an LDPR server could discard triples
whose predicates the server does not recognize or otherwise chooses
not to persist. In other words, LDPR servers MAY restrict themselves
to a known set of predicates, but LDPR clients MUST NOT restrict themselves to a known set of predicates
when their intent is to perform a later HTTP <code>PUT</code> to update the resource.
</div>
- <div id="ldpr-4_4_5" class="rule">4.4.5 An LDPR client MUST preserve all triples retrieved using HTTP <code>GET</code> that
+ <div id="ldpr-4_5_5" class="rule">4.5.5 An LDPR client MUST preserve all triples retrieved 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
[[RFC5789]].
</div>
- <div id="ldpr-4_4_6" class="rule">4.4.6 LDPR servers MAY choose to allow the creation of new resources using HTTP <code>PUT</code>.
+ <div id="ldpr-4_5_6" class="rule">4.5.6 LDPR servers MAY choose to allow the creation of new resources using HTTP <code>PUT</code>.
</div>
- <div id="ldpr-4_4_7" class="rule">4.4.7 LDPR servers SHOULD allow clients to update resources without
+ <div id="ldpr-4_5_7" class="rule">4.5.7 LDPR servers SHOULD allow clients to update resources without
requiring detailed knowledge of server-specific constraints.
- This is a consequence of the requirement to <a href="#ldpr-4_1_9">enable simple creation and modification</a> of LPDRs.
+ This is a consequence of the requirement to <a href="#ldpr-4_2_9">enable simple creation and modification</a> of LPDRs.
</div>
</section>
@@ -545,15 +534,15 @@
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">section 5.6</a>.</p>
+ <a href="#ldpc-HTTP_DELETE" class="sectionRef"></a>.</p>
- <div id="ldpr-4_5_1" class="rule">4.5.1 LDPR servers MUST remove the resource identified by the <code>Request-URI</code>.
+ <div id="ldpr-4_6_1" class="rule">4.6.1 LDPR servers MUST remove the resource identified by the <code>Request-URI</code>.
After a successful HTTP <code>DELETE</code>, a subsequent HTTP <code>GET</code> on the same
<code>Request-URI</code> MUST result in a 404 (Not found) or 410 (Gone) status
code. Clients SHOULD note that servers MAY reuse a URI under some circumstances.
</div>
- <div id="ldpr-4_5_2" class="rule">4.5.2 LDPR servers MAY alter the state of other resources as a result of an
+ <div id="ldpr-4_6_2" class="rule">4.6.2 LDPR servers MAY alter the state of other resources as a result of an
HTTP <code>DELETE</code> request. For example, it is acceptable for the server to
remove triples from other resources whose subject or object is the
deleted resource. It is also acceptable and common for LDPR servers to
@@ -566,8 +555,8 @@
<p>Note that certain LDP mechanisms, such as paging, rely on HTTP headers, and HTTP generally requires that
<code>HEAD</code> responses include the same headers as <code>GET</code> responses.
Thus, implementers should also carefully read <a href="#ldpr-HTTP_GET" class="sectionRef"></a>.</p>
- <div id="ldpr-4_6_1" class="rule">4.6.1 LDPR servers MUST support the HTTP <code>HEAD</code> method.</div>
- <div id="ldpr-4_6_2" class="rule">4.6.2 LDPR servers MUST support the HTTP response headers defined in <a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
+ <div id="ldpr-4_7_1" class="rule">4.7.1 LDPR servers MUST support the HTTP <code>HEAD</code> method.</div>
+ <div id="ldpr-4_7_2" class="rule">4.7.2 LDPR servers MUST support the HTTP response headers defined in <a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
</div>
</section>
@@ -575,28 +564,19 @@
<h2 id="ldpr-HTTP_PATCH">HTTP PATCH</h2>
<p>This specification imposes the following new requirements on HTTP <code>PATCH</code> for LDPRs
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>
-
- <div id="ldpr-4_7_1" class="rule">4.7.1 LDPR servers MAY implement HTTP <code>PATCH</code> to allow modifications,
+ new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
+ <div id="ldpr-4_8_1" class="rule">4.8.1 LDPR servers MAY implement HTTP <code>PATCH</code> to allow modifications,
especially partial replacement, of their resources [[!RFC5789]]. No
minimal set of patch document formats is mandated by this document.
</div>
-
- <div id="ldpr-4_7_2" class="rule">4.7.2 LDPR servers SHOULD allow clients to update resources without
+ <div id="ldpr-4_8_2" class="rule">4.8.2 LDPR servers SHOULD allow clients to update resources without
requiring detailed knowledge of server-specific constraints.
- This is a consequence of the requirement to <a href="#ldpr-4_1_9">enable simple creation and modification</a> of LPDRs.
+ This is a consequence of the requirement to <a href="#ldpr-4_2_9">enable simple creation and modification</a> of LPDRs.
</div>
-
- <div id="ldpr-4_7_3" class="rule">4.7.3 LDPR servers SHOULD NOT allow clients to create new resources using <code>PATCH</code>.
+ <div id="ldpr-4_8_3" class="rule">4.8.3 LDPR servers SHOULD NOT allow clients to create new resources using <code>PATCH</code>.
<a href="#ldpc-HTTP_POST"><code>POST</code> (to an LDPC)</a> and/or <a href="#ldpc-HTTP_PUT"><code>PUT</code></a> should be used as the standard way to create new LDPRs.
</div>
-
- <div class="ldp-issue-pending">
- <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/32">ISSUE-32</a></div>
- How can clients discover that a resource is an LDPR or LDPC, and what features are supported?
- </div>
-
- <div id="ldpr-4_7_4" class="rule">4.7.4 LDPR servers that support <code>PATCH</code> MUST
+ <div id="ldpr-4_8_4" class="rule">4.8.4 LDPR servers that support <code>PATCH</code> MUST
include an <code>Accept-Patch</code> HTTP response header [[!RFC5789]] on HTTP <code>OPTIONS</code>
requests, listing patch document media type(s) supported by the server.
</div>
@@ -613,14 +593,8 @@
add other requirements on <code>OPTIONS</code> responses.
</p>
- <div class="ldp-issue-pending">
- <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/32">ISSUE-32</a></div>
- How can clients discover that a resource is an LDPR or LDPC, and what features are supported?
- </div>
-
- <div id="ldpr-4_8_1" class="rule">4.8.1 LDPR servers MUST support the HTTP <code>OPTIONS</code> method.</div>
-
- <div id="ldpr-4_8_2" class="rule">4.8.2 LDPR servers MUST indicate their support for HTTP Methods by
+ <div id="ldpr-4_9_1" class="rule">4.9.1 LDPR servers MUST support the HTTP <code>OPTIONS</code> method.</div>
+ <div id="ldpr-4_9_2" class="rule">4.9.2 LDPR servers MUST indicate their support for HTTP Methods by
responding to a HTTP <code>OPTIONS</code> request on the LDPR’s URL with the HTTP
Method tokens in the HTTP response header <code>Allow</code>.
</div>
@@ -740,7 +714,7 @@
<h3 id="ldpr-PagingGET">HTTP GET</h3>
<p>In addition to the requirements set forth in <a href="#ldpr-HTTP_GET" class="sectionRef"></a> on HTTP <code>GET</code>, LDPR servers that support paging must also follow the requirements in this section</p>
- <div id="ldpr-pagingGET-1" class="rule">4.9.2.1 LDPR servers SHOULD allow clients to retrieve large LDPRs in
+ <div id="ldpr-pagingGET-1" class="rule">4.10.2.1 LDPR servers SHOULD allow clients to retrieve large LDPRs in
pages. In responses to <code>GET</code> requests with an LDPR as the <code>Request-URI</code>,
LDPR servers that support paging SHOULD provide an HTTP <code>Link</code>
header whose target URI is the first page resource, and whose link relation type is <code>first</code> [[!RFC5988]].
@@ -752,29 +726,29 @@
The representation for any page, including the first, will include
the URL for the next page. See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.
</div>
- <div id="ldpr-pagingGET-2" class="rule">4.9.2.2 LDPR servers MAY split the response representation of any LDPR.
+ <div id="ldpr-pagingGET-2" class="rule">4.10.2.2 LDPR servers MAY split the response representation of any LDPR.
This is known as
server-initiated paging. See <a href="#ldpr-Paging" class="sectionRef"></a> for
additional details.
</div>
- <div id="ldpr-pagingGET-3" class="rule">4.9.2.3 LDPR servers that initiate paging SHOULD respond to requests for a LDPR
+ <div id="ldpr-pagingGET-3" class="rule">4.10.2.3 LDPR servers that initiate paging SHOULD respond to requests for a LDPR
by redirecting the client to the first page resource using a <code>303 See
Other</code> response with an HTTP <code>Location</code> header providing the first page resource URL.
</div>
- <div id="ldpr-pagingGET-4" class="rule">4.9.2.4 LDPR servers that support paging MUST include in the page
+ <div id="ldpr-pagingGET-4" class="rule">4.10.2.4 LDPR servers that support paging MUST include in the page
representation a representation for the LDPR.
</div>
- <div id="ldpr-pagingGET-5" class="rule">4.9.2.5 The page resource representation SHOULD have one triple to indicate its
+ <div id="ldpr-pagingGET-5" class="rule">4.10.2.5 The page resource representation SHOULD have one triple to indicate its
type, whose subject is the URL of the page, whose predicate is <code>rdf:type</code> and object is <code>ldp:Page</code>.
It also SHOULD have 1 triple to indicate the resource it is paging,
whose subject is the URL of the page, predicate is <code>ldp:pageOf</code>,
and object is the URL of the LDPR.
</div>
- <div id="ldpr-pagingGET-6" class="rule">4.9.2.6 The page resource representation MUST have one triple with the subject
+ <div id="ldpr-pagingGET-6" class="rule">4.10.2.6 The page resource representation MUST have one triple with the subject
of the page, predicate of <code>ldp:nextPage</code> and
object being the URL for the subsequent page.
</div>
- <div id="ldpr-pagingGET-7" class="rule">4.9.2.7 The last page resource representation MUST have one triple with the subject of the
+ <div id="ldpr-pagingGET-7" class="rule">4.10.2.7 The last page resource representation MUST have one triple with the subject of the
last page, predicate of <code>ldp:nextPage</code> and object being <code>rdf:nil</code>.
</div>
</section>
@@ -782,12 +756,7 @@
<section>
<h3 id="ldpr-paging-HTTP_OPTIONS">HTTP OPTIONS</h3>
- <div class="ldp-issue-pending">
- <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/32">ISSUE-32</a></div>
- How can clients discover that a resource is an LDPR or LDPC, and what features are supported?
- </div>
-
-<div id="ldpr-4_9_3_1" class="rule">4.9.3.1 LDPR servers MUST indicate their support for client-initiated paging by
+<div id="ldpr-4_10_3_1" class="rule">4.10.3.1 LDPR servers MUST indicate their support for client-initiated paging by
responding to a HTTP <code>OPTIONS</code> request on the LDPR’s URL with the HTTP
response header for link relations using the header name of <code>Link</code> and link relation type <code>first</code> [[!RFC5988]].
</div>
@@ -836,11 +805,6 @@
<section class="informative">
<h3 id="ldpr-InliningWarnings">Use with Care</h3>
- <div class="ldp-issue-pending">
- <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/58">ISSUE-58</a></div>
- Action 87: Add an informative section on the possible dangers of inlining resources
- </div>
-
<p>The building blocks LDP provides can only be safely used if certain assumptions hold.
Said another way, resource inlining solves a subset of scenarios, not all scenarios in the general case —
so if you care about any of the following in a given application, your server should avoid returning
@@ -871,13 +835,7 @@
LDPR servers that support <a>resource inlining</a>
must also follow the requirements in this section.</p>
- <div class="ldp-issue-pending">
- <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/58">ISSUE-58</a></div>
- Action 89: Add a predicate ldp:inlinedResource the object of which is a URI of a linked resource that is fully inlined,
- marked as AT RISK.
- </div>
-
- <div id="ldpr-4_10_3_1" class="rule">4.10.3.1 LDPR servers that support <a>resource inlining</a> MUST
+ <div id="ldpr-4_11_3_1" class="rule">4.11.3.1 LDPR servers that support <a>resource inlining</a> MUST
include a <code>ldp:Page</code> resource in the representation describing the set of inlined resources,
whether or not the representation contains subsequent pages. The <code>ldp:Page</code> resource conceptually contains
metadata about the representation; it is usually not part of the HTTP resource's state, and its presence does not indicate that
@@ -890,24 +848,24 @@
requests for them.
</div>
- <div id="ldpr-4_10_3_2" class="rule">4.10.3.2 LDPR servers that support <a>resource inlining</a> MUST
- include the <code>ldp:Page</code> resource described in <a href="#ldpr-4_10_3_1">section 4.10.3.1</a>
+ <div id="ldpr-4_11_3_2" class="rule">4.11.3.2 LDPR servers that support <a>resource inlining</a> MUST
+ include the <code>ldp:Page</code> resource described in <a href="#ldpr-4_11_3_1">section 4.11.3.1</a>
one triple for each inlined resource,
whose subject is the <code>ldp:Page</code> resource URI,
whose predicate is <code>ldp:inlinedResource</code>, and
whose object is the HTTP <code>Request-URI</code> of an inlined resource [[!HTTP11]].
</div>
- <div id="ldpc-4_10_3_3" class="rule">4.10.3.3 LDPR clients SHOULD avoid making HTTP <code>GET</code> requests
+ <div id="ldpc-4_11_3_3" class="rule">4.11.3.3 LDPR clients SHOULD avoid making HTTP <code>GET</code> requests
against any resource whose HTTP <code>Request-URI</code> is the object of a triple of the form
- described in <a href="#ldpc-4_10_3_2">section 4.10.3.2</a>, unless there are application-specific
+ described in <a href="#ldpc-4_11_3_2">section 4.11.3.2</a>, unless there are application-specific
reasons for doing so. Clients should note that by the time the representation is received, the actual state
of any inlined resource(s) may have changed due to subsequent requests.
</div>
- <div id="ldpc-4_10_3_4" class="rule">4.10.3.4 LDPR clients MUST NOT assume that LDPR representations
+ <div id="ldpc-4_11_3_4" class="rule">4.11.3.4 LDPR clients MUST NOT assume that LDPR representations
lacking a <code>ldp:Page</code> resource or lacking the triple
- described in <a href="#ldpc-4_10_3_2">section 4.10.3.2</a> contain all the triples for any resource(s)
+ described in <a href="#ldpc-4_11_3_2">section 4.11.3.2</a> contain all the triples for any resource(s)
listed in the representation whose HTTP <code>Request-URI</code> differs from
the HTTP <code>Request-URI</code> used by the client.
The representation might in fact contain all such triples, or some
@@ -1278,25 +1236,17 @@
SHOULD use the <code>rdfs:member</code> predicate. Member resources can be
any kind of resource identified by its URI, LDPR or otherwise.
</div>
-
<div id="ldpc-5_2_4" class="rule">5.2.4 An LDPC representation MUST contain one triple
whose subject is the LDPC URI,
whose predicate is the <code>ldp:membershipSubject</code>,
and whose object is the LDPC's membership subject URI.
</div>
-
<div id="ldpc-5_2_5" class="rule">5.2.5 An LDPC representation MUST contain one triple
whose subject is the LDPC URI,
and whose predicate is either <code>ldp:membershipPredicate</code> or <code>ldp:membershipPredicateInverse</code>.
The object of the triple is constrained by other sections, such as
<a href="ldpc-5_2_5_1">5.2.5.1</a> or <a href="ldpc-5_2_5_2">5.2.5.2</a>.
</div>
-
- <div class="ldp-issue-pending">
- <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/75">ISSUE-75</a></div>
- non-monotonic ldp:membershipXXX relations. Drafted per 2013-06-18 F2F resolution.
- </div>
-
<div id="ldpc-5_2_5_1" class="rule">5.2.5.1 For a given triple <var>T</var> with a subject <var>C</var>
of the LDPC and predicate of
<code>ldp:membershipPredicate</code>, the object MUST be the URI of the membership predicate <var>P</var> used to
@@ -1306,7 +1256,6 @@
(<var>R</var>, <var>P</var>, <var>MR</var>), where <var>MR</var> represents URI of
a member resource.
</div>
-
<div id="ldpc-5_2_5_2" class="rule">5.2.5.2 For a given triple <var>T</var> with a subject <var>C</var>
of the LDPC and predicate of
<code>ldp:membershipPredicateInverse</code>, the object MUST be the URI of the membership predicate <var>P</var> used to
@@ -1316,7 +1265,6 @@
(<var>MR</var>, <var>P</var>, <var>R</var>), where <var>MR</var> represents URI of
a member resource.
</div>
-
<div id="ldpc-5_2_6" class="rule">5.2.6 The representation of a LDPC MAY include an arbitrary number of
additional triples whose subjects are the members of the container,
or that are from the representations of the members (if they have RDF
@@ -1326,7 +1274,6 @@
Member Information</a>, <a href="#ldpr-inlining" class="sectionRef"></a>, and
<a href="#ldpc-inlining" class="sectionRef"></a> for additional details.
</div>
-
<div id="ldpc-5_2_7" class="rule">5.2.7 The representation of a LDPC MUST have <code>rdf:type</code>
of <code>ldp:Container</code>, but it MAY have additional
<code>rdf:type</code>s.
@@ -1334,7 +1281,6 @@
<div id="ldpc-5_2_8" class="rule">5.2.8 LDPC representations SHOULD NOT use RDF container types <code>rdf:Bag</code>,
<code>rdf:Seq</code> or <code>rdf:List</code>.
</div>
-
<div id="ldpc-5_2_9" class="rule">5.2.9 LDPC servers SHOULD NOT re-use URIs,
regardless of the mechanism by which members are created (<code>POST</code>, <code>PUT</code>, etc.).
Certain specific cases exist where a LDPC server MAY delete a resource and then later re-use the
@@ -1342,8 +1288,6 @@
While it is difficult to provide absolute implementation guarantees of non-reuse in all failure
scenarios, re-using URIs creates ambiguities for clients that are best avoided.
</div>
-
-
<div id="ldpc-5_2_10" class="rule">5.2.10 Some LDPC's have membership object's that are not directly
URIs minted upon LDPC member creation, for example URIs with non-empty fragment identifier [[RFC3986]].
To determine which object URI to use for the membership triple, LDPC's MUST contain one triple whose
@@ -1356,11 +1300,6 @@
(the default or typical case), the object MUST be set to predefined URI <code>ldp:MemberSubject</code> such that it forms the triple:
<var>(LDPC URI, <code>ldp:membershipObject</code>, <code>ldp:MemberSubject</code>)</var>.
</div>
- <div class="ldp-issue-pending">
- <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/72">ISSUE-72</a></div>
- edited in ldp:membershipObject in new previous section
- </div>
-
<!-- NOTE: Saving this sample to help with future editing/understanding or possible insertion directly.
@@ -1399,7 +1338,6 @@
or MAY be another resource (as in the <a href="#ldpc-ex-membership-subj">example</a>). See also
<a href="#ldpc-5_2_3">5.2.3</a>.
</div>
-
<div id="ldpc-5_3_2" class="rule">5.3.2 LDPC servers MAY represent the members of a paged LDPC in a sequential
order. If the server does so, it MUST be specify the order using a triple
whose subject is the page URI,
@@ -1417,7 +1355,6 @@
See section <a href="#ldpc-ordering">5.1.4 Ordering</a> for
an example.
</div>
-
<div id="ldpc-5_3_3" class="rule">5.3.3 LDPC page representations
ordered using <code>ldp:containerSortCriteria</code> MUST contain,
in every <code>ldp:containerSortCriterion</code> list entry,
@@ -1431,7 +1368,6 @@
can be used, but LDP
assigns no meaning to them and interoperability will be limited.
</div>
-
<div id="ldpc-5_3_4" class="rule">5.3.4 LDPC page representations
ordered using <code>ldp:containerSortCriteria</code> MUST contain,
in every <code>ldp:containerSortCriterion</code> list entry,
@@ -1443,14 +1379,6 @@
as the object of this triple. Other values can be used, but LDP
assigns no meaning to them and interoperability will be limited.
</div>
-
- <div class="ldp-issue-pending">
- <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/14">ISSUE-14</a></div>
- Include clarifications about ordering in LDPC representations.
- The ReSpec SPARQL QUERY link is http://www.w3.org/TR/rdf-sparql-query/ , which has highlighted text
- referring readers to SPARQL 1.1. Which normative reference do we want?
- </div>
-
<div id="ldpc-5_3_5" class="rule">5.3.5 LDPC page representations
ordered using <code>ldp:containerSortCriteria</code> MAY contain,
in any <code>ldp:containerSortCriterion</code> list entry,
@@ -1475,11 +1403,6 @@
The <code>ldp:containerSortCollation</code> triple SHOULD be omitted for comparisons
involving <a title="page-ordering values">page-ordering values</a> for which [[!SPARQL-QUERY]] does not use collations.
</div>
-
- <div class="ldp-issue-pending">
- <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/63">ISSUE-63</a></div>
- Need to be able to specify collation with container ordering. Drafted per 2013-06-18 F2F resolution.
- </div>
</section>
<section>
@@ -1535,7 +1458,7 @@
<div id="ldpc-5_4_9" class="rule">5.4.9 LDPC servers SHOULD allow clients to create new resources without
requiring detailed knowledge of application-specific constraints.
This is a consequence of the requirement to
- <a href="#ldpr-4_1_9">enable simple creation and modification</a> of LPDRs.
+ <a href="#ldpr-4_2_9">enable simple creation and modification</a> of LPDRs.
</div>
<div id="ldpc-5_4_10" class="rule">5.4.10 LDPC servers MAY allow clients to suggest the URI for a resource
created through <code>POST</code>, using the HTTP <code>Slug</code> header as defined in [[!RFC5023]]. LDP adds
@@ -1552,19 +1475,8 @@
201-Created and URI indicated by <code>Location</code> response header), LDPC servers MAY create an associated LDPR
to contain data about the created resource. If an LDPC server creates this associated LDPR it MUST indicate
its location on the HTTP response using the HTTP response header <code>Link</code> and relationship type <code>meta</code>
- and <code>href</code> to be the URI of the meta-resource [[!RFC5988]].</div>
-
- <div class="ldp-issue-pending">
- <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/80">ISSUE-80</a></div>
- How does a client know which <code>POST</code> requests create new resources.
- <p>
- Note from editor: the MUST here keeps this aligned with what we decided for OPTIONS on PATCH; in both
- cases the header registration says SHOULD, and the LDP spec says MUST. What makes that look a bit odd is
- that in the Accept-Post case, the registration and LDP are the same document. Thus I added informative
- text here explicitly talking to the apparent discrepancy.
- </p>
+ and <code>href</code> to be the URI of the meta-resource [[!RFC5988]].
</div>
-
<div id="ldpr-5_4_13" class="rule">5.4.13 LDPR servers that support <code>POST</code> MUST
include an <a href="#header-accept-post"><code>Accept-Post</code> response header</a> on HTTP <code>OPTIONS</code>
responses, listing post document media type(s) supported by the server.
@@ -1580,11 +1492,6 @@
<code>POST</code> to be aware of its existence and require it, but it is a reasonable requirement for new
specifications such as LDP.
</div>
-
- <div class="ldp-issue-pending">
- <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/79">ISSUE-79</a></div>
- ldp:contains => created
- </div>
<div id="ldpr-5_4_14" class="rule">5.4.14 LDPCs that create new member resources MAY add triples to the container
as part of member creation to reflect its factory role.
@@ -1612,9 +1519,8 @@
HTTP <code>PUT</code> on a corresponding <a>non-member resource</a>, which
MAY exclude server-managed properties such as <code>ldp:membershipSubject</code>, <code>ldp:membershipPredicate</code>
and <code>ldp:membershipPredicateInverse</code>.
- Section <a href="#ldpc-5_7_1">5.7.1 HTTP HEAD</a> describes the process by which clients
- discover whether the server offers such a resource, and if so its URL.
-
+ The <a href="#ldpc-HTTP_OPTIONS" class="sectionRef"></a> describes the process by which clients
+ use HTTP <code>OPTIONS</code> to discover whether the server offers such a resource, and if so its URL.
</div>
<div id="ldpc-5_5_3" class="rule">5.5.3 LDPC servers SHOULD NOT allow HTTP <code>PUT</code> requests
@@ -1646,13 +1552,7 @@
of member resources.
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.
- </div>
-
- <div class="ldp-issue-pending">
- <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/79">ISSUE-79</a></div>
- ldp:contains => created
</div>
-
<div id="ldpc-5_6_3" class="rule">5.6.3 When the conditions in <a href="#ldpc-5_6_1">5.6.1</a> hold, and the LDPC tracks member
resources that it created using the <code>ldp:created</code> predicate, the LDPC server MUST also remove
the deleted member's <code>ldp:created</code> triple.
@@ -1669,7 +1569,7 @@
<h2 id="ldpc-HTTP_HEAD">HTTP HEAD</h2>
<p>Note that certain LDP mechanisms, such as paging, rely on HTTP headers, and HTTP generally requires that
<code>HEAD</code> responses include the same headers as <code>GET</code> responses. Also LDPR servers must also include HTTP headers
- on response to <code>OPTIONS</code>, see <a href="#ldpr-4_6_2">4.6.2</a>.
+ on response to <code>OPTIONS</code>, see <a href="#ldpr-4_7_2">4.7.2</a>.
Thus, implementers supporting <code>HEAD</code> should also carefully read the
<a href="#ldpc-HTTP_GET" class="sectionRef"></a> and <a href="#ldpc-HTTP_OPTIONS" class="sectionRef"></a>.</p>
</section>
@@ -1751,11 +1651,6 @@
with any way to influence which (if any) resources are inlined in any given response.
</p>
- <div class="ldp-issue-pending">
- <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/58">ISSUE-58</a></div>
- Action 87: Add an informative section on the possible dangers of inlining resources
- </div>
-
<p>The inlining building blocks LDP provides can only be safely used if certain assumptions hold.
This is no less true for containers than for LDPRs in general.
See the general <a href="#ldpr-InliningWarnings">cautions on resource inlining</a>.
@@ -1770,17 +1665,9 @@
must also follow the requirements in this section.
</p>
- <div class="ldp-issue-pending">
- <div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/58">ISSUE-58</a></div>
- Action 88: Add a property ldp:membersInlined true/false. The default (if not specified) is false.
- If true, it means that a complete description of all members [on the current page] are inlined with the container document [or page],
- and therefore clients SHOULD NOT do <code>GET</code> on the member URIs to retrieve additional triples.
- marked as AT RISK.
- </div>
-
<div id="ldpc-5_10_2_1" class="rule">5.10.2.1 LDPC representations that are <a title="member inlining">member inlined</a> MUST
include a <code>ldp:Page</code> resource in the representation, whether or not the representation contains
- multiple pages, as described in <a href="#ldpr-4_10_3_1">section 4.10.3.1</a>. In addition to satisfying
+ multiple pages, as described in <a href="#ldpr-4_11_3_1">section 4.11.3.1</a>. In addition to satisfying
those requirements, the representation MUST contain a triple
whose subject is the <code>ldp:Page</code> resource URI,
whose predicate is <code>ldp:membersInlined</code>, and
@@ -1899,6 +1786,7 @@
<blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130701/">Third Public Working Draft</a></em></blockquote>
-->
<ul>
+ <li>2013-07-23 - Added informative <a href="#ldpr-informative" class="sectionRef"></a>, therefore shifting all sections by one 4.1->4.2, etc (SS)</li>
<li>2013-07-23 - Changed <a href="#header-accept-post" class="sectionRef"></a> to at risk as possibly moving to IETF (SS)</li>
<li>2013-07-23 - ISSUE-53 4.2.3 changed MUST to SHOULD (SS)</li>
<li>2013-07-22 - ISSUE-53 4.2.2 changed MUST to SHOULD (SS)</li>