ldp.html
changeset 435 e9efbc3a3ba8
parent 434 83b656184387
child 436 130a8b8a4583
equal deleted inserted replaced
434:83b656184387 435:e9efbc3a3ba8
    29     <!-- 
    29     <!-- 
    30       === NOTA BENE ===
    30       === NOTA BENE ===
    31       For the three scripts below, if your spec resides on dev.w3 you can check them
    31       For the three scripts below, if your spec resides on dev.w3 you can check them
    32       out in the same tree and use relative links so that they'll work offline,
    32       out in the same tree and use relative links so that they'll work offline,
    33      -->
    33      -->
    34     <script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script> 
    34   <script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script> 
       
    35  <!--    <script src='file:///Users/sspeiche/git/respec/js/profile-w3c-common.js' class='remove' async></script>  -->  
    35     <script class='remove'>
    36     <script class='remove'>
    36       var respecConfig = {
    37       var respecConfig = {
    37           // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
    38           // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
    38           specStatus:           "ED",
    39           specStatus:           "ED",
    39           
    40           
    60           // if there a publicly available Editor's Draft, this is the link
    61           // if there a publicly available Editor's Draft, this is the link
    61           edDraftURI:           "http://www.w3.org/2012/ldp/hg/ldp.html",
    62           edDraftURI:           "http://www.w3.org/2012/ldp/hg/ldp.html",
    62 
    63 
    63           // if this is a LCWD, uncomment and set the end of its review period
    64           // if this is a LCWD, uncomment and set the end of its review period
    64           lcEnd: "2013-09-02",
    65           lcEnd: "2013-09-02",
       
    66           
       
    67           // Only include h1 and h2 level
       
    68           maxTocLevel: 0, // HACK: We want 2 but auto-numbering doesn't happen
    65 
    69 
    66           // if you want to have extra CSS, append them to this list
    70           // if you want to have extra CSS, append them to this list
    67           // it is recommended that the respec.css stylesheet be kept
    71           // it is recommended that the respec.css stylesheet be kept
    68           //extraCSS:             ["https://dvcs.w3.org/hg/ldpwg/css/respec.css"],
    72           //extraCSS:             ["https://dvcs.w3.org/hg/ldpwg/css/respec.css"],
    69 
    73 
   187 			font-weight:    bold;
   191 			font-weight:    bold;
   188 			border: 1px solid #f00;
   192 			border: 1px solid #f00;
   189 			background: #fff;
   193 			background: #fff;
   190 			padding:    3px 1em;
   194 			padding:    3px 1em;
   191 		}
   195 		}
   192 
   196 		.normal { font-weight: normal; }
       
   197 		
   193     </style>
   198     </style>
   194     <style type="text/css" media="all">
   199     <style type="text/css" media="all">
   195     	code {
   200     	code {
   196     	    font-weight:bold;
   201     	    font-weight:bold;
   197 			font-size:larger;
   202 			font-size:larger;
   442 
   447 
   443 </div>
   448 </div>
   444 
   449 
   445 </section>
   450 </section>
   446 
   451 
       
   452 <section id="ldpclient">
       
   453 <h1>Linked Data Platform Clients</h1>
       
   454 <div class="ldp-issue-open">
       
   455 
       
   456 <p>All of the following rules are just copied here, without change; still need to be removed from original section.
       
   457 Should consider making this section come before the server sections; doing so would cause mass-renumbering however.
       
   458 </p>
       
   459 </div>
       
   460 <section><h2>General</h2>
       
   461 	<section id="ldp-cli-multitype"><h2 class="normal">In the absence of special knowledge of the application or domain, 
       
   462 		<a title="LDP client">LDP clients</a> MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
       
   463 	</h2></section> <!-- Was 4.3.5 / #ldpr-4_3_5 -->
       
   464 	
       
   465 	<section id="ldpr-cli-typeschange"><h2 class="normal">In the absence of special knowledge of the application or domain, 
       
   466 		<a title="LDP client">LDP clients</a> MUST assume that the <code>rdf:type</code> values
       
   467 		of a given LDPR can change over time.
       
   468 	</h2></section> <!-- Was 4.3.6 / #ldpr-4_3_6 -->
       
   469 	
       
   470 	<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
       
   471 		resource of a particular type at an arbitrary server is open, in the
       
   472 		sense that different resources of the same type may not all have the
       
   473 		same set of predicates in their triples, and the set of predicates that
       
   474 		are used in the state of any one resource is not limited to any pre-defined
       
   475 		set.
       
   476 	</h2></section> <!-- Was 4.5.3 / #ldpr-ldpr-4_5_3 -->
       
   477 	
       
   478 	<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
       
   479 		it doesn’t change whether it understands the predicates or not, when
       
   480 		its intent is to perform an update using HTTP <code>PUT</code>.  The use of HTTP
       
   481 		<code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
       
   482 		[[RFC5789]].
       
   483 	</h2></section> <!-- Was 4.5.5 / #ldpr-ldpr-4_5_5 -->
       
   484 </section>
       
   485 </section> <!-- Client constraints -->
   447 
   486 
   448 <section id="ldpr">
   487 <section id="ldpr">
   449 <h1>Linked Data Platform Resources</h1>
   488 <h1>Linked Data Platform Resources</h1>
   450 
   489 
   451 <section class="informative" id="ldpr-informative">
   490 <section class="informative" id="ldpr-informative">
   488 </section>
   527 </section>
   489 
   528 
   490 <section id="ldpr-general">
   529 <section id="ldpr-general">
   491 <h2>General</h2>
   530 <h2>General</h2>
   492 		
   531 		
   493 	<div id="ldpr-4_2_1" class="rule">4.2.1 <a title="LDP server">LDP servers</a> MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].</div>
   532 	<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]].
   494 	<div id="ldpr-4_2_2" class="rule">4.2.2 <a title="LDP server">LDP servers</a> MUST provide an RDF representation for LDPRs. 
   533 	</h2></section><!-- Was 4.2.1 / #ldpr-4_2_1 -->
       
   534 	
       
   535 	<section id="ldpr-gen-rdf"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide an RDF representation for LDPRs. 
   495 	The HTTP <code>Request-URI</code> of the LDPR is typically the subject of most triples in the response.
   536 	The HTTP <code>Request-URI</code> of the LDPR is typically the subject of most triples in the response.
   496 	</div>
   537 	</h2></section><!-- Was 4.2.2 / #ldpr-4_2_2 -->
   497 	<div id="ldpr-4_2_3" class="rule">4.2.3 <a title="LDP server">LDP servers</a> MAY host a mixture of LDPRs and non-LDPRs. For example, it
   538 	
       
   539 	<section id="ldpr-gen-binary"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY host a mixture of LDPRs and non-LDPRs. For example, it
   498 		is common for <a title="LDP server">LDP servers</a> to need to host binary or text resources
   540 		is common for <a title="LDP server">LDP servers</a> to need to host binary or text resources
   499 		that do not have useful RDF representations.
   541 		that do not have useful RDF representations.</h2></section><!-- Was 4.2.3 / #ldpr-4_2_3 -->
   500 	</div>
   542 
   501 
   543 	<section id="ldpr-gen-reusevocab"><h2 class="normal">LDPRs SHOULD reuse existing vocabularies instead of creating
   502 	<div id="ldpr-4_2_4" class="rule">4.2.4 LDPRs SHOULD reuse existing vocabularies instead of creating
       
   503 		their own duplicate vocabulary terms.  In addition to this general rule, some specific cases are
   544 		their own duplicate vocabulary terms.  In addition to this general rule, some specific cases are
   504 		covered by other conformance rules.
   545 		covered by other conformance rules.
   505 	</div>
   546 	</h2></section><!-- Was 4.2.4 / #ldpr-4_2_4 -->
   506 	<div id="ldpr-4_2_4_1" class="rule">4.2.4.1 LDPR predicates SHOULD use standard vocabularies such as Dublin Core
   547 	
       
   548 	<section id="ldpr-gen-reusevocabsuchas"><h2 class="normal">LDPR predicates SHOULD use standard vocabularies such as Dublin Core
   507 		[[!DC-TERMS]], RDF [[!RDF-CONCEPTS]] and RDF Schema [[!RDF-SCHEMA]], whenever
   549 		[[!DC-TERMS]], RDF [[!RDF-CONCEPTS]] and RDF Schema [[!RDF-SCHEMA]], whenever
   508 		possible.
   550 		possible.
   509 	</div>
   551 	</h2></section><!-- Was 4.2.4.1 / #ldpr-4_2_4_1 -->
   510 	<div id="ldpr-4_2_5" class="rule">4.2.5 LDPR representations SHOULD have at least one <code>rdf:type</code>
   552 	
       
   553 	<section id="ldpr-gen-atleast1rdftype"><h2 class="normal">LDPR representations SHOULD have at least one <code>rdf:type</code>
   511 		set explicitly.  This makes the representations much more useful to
   554 		set explicitly.  This makes the representations much more useful to
   512 		client applications that don’t support inferencing.
   555 		client applications that don’t support inferencing.
   513 	</div>
   556 	</h2></section><!-- Was 4.2.5 / #ldpr-4_2_5 -->
   514 	<!-- Action-108 removed this 2013-10-22
   557 	
   515 	<div id="ldpr-4_2_6" class="rule">4.2.6 <a title="LDP server">LDP servers</a> MAY support standard representations beyond those
   558 	<section id="ldpr-gen-etags"><h2 class="normal"><a title="LDP server">LDP server</a> responses MUST use entity tags (either 
   516 		necessary to conform to this specification. These
   559 		weak or strong ones) as response <code>ETag</code> header values.
   517 		could be other RDF formats, like N3 or NTriples, but non-RDF formats
   560 	</h2></section><!-- Was 4.2.8 / #ldpr-4_2_8 -->
   518 		like HTML [[!HTML401]] and JSON [[!RFC4627]] would likely be common.
   561 	
   519 	</div>		
   562 	<section id="ldpr-gen-linktypehdr"><h2 class="normal"><a title="LDP server">LDP servers</a>
   520 	-->
       
   521 	<!-- Action-108 removed this 2013-10-22
       
   522 	<div id="ldpr-4_2_7" class="rule">4.2.7 LDPRs MAY be created, updated and deleted using methods not defined in
       
   523 		this document, for example through application-specific means, SPARQL
       
   524 		UPDATE, etc. [[!SPARQL-UPDATE]], as long as those methods do not conflict with this specification's 
       
   525 		normative requirements.
       
   526 	</div>
       
   527 	-->
       
   528 	<div id="ldpr-4_2_8" class="rule">4.2.8 <a title="LDP server">LDP server</a> responses MUST use entity tags (either weak or strong 
       
   529 ones) as response <code>ETag</code> header values.
       
   530 	</div>
       
   531 	<!-- Action-110 removed this 2013-10-25
       
   532 	<div id="ldpr-4_2_9" class="rule">4.2.9 LDPR
       
   533 		servers SHOULD enable simple creation and modification of LDPRs.
       
   534 		It is
       
   535 		common for <a title="LDP server">LDP servers</a> to put restrictions on representations – for
       
   536 		example, the range of <code>rdf:type</code> predicates, datatypes of
       
   537 		the objects of predicates, and the number of occurrences of predicates in an LDPR, but
       
   538 		servers SHOULD minimize those restrictions.  Enforcement of
       
   539 		more complex constraints will greatly restrict the set of clients
       
   540 		that can modify resources. For some server applications, excessive
       
   541 		constraints on modification of resources may be required.
       
   542 	</div>
       
   543 	-->
       
   544 	<div id="ldpr-4_2_10" class="rule">4.2.10 <a title="LDP server">LDP servers</a>
       
   545 		exposing LDPRs 
   563 		exposing LDPRs 
   546 		MUST advertise their LDP support by exposing a HTTP <code>Link</code> header
   564 		MUST advertise their LDP support by exposing a HTTP <code>Link</code> header
   547 		with a target URI of <code>http://www.w3.org/ns/ldp/Resource</code>, and
   565 		with a target URI of <code>http://www.w3.org/ns/ldp/Resource</code>, and
   548 		a link relation type of <code>type</code> (that is, <code>rel='type'</code>)
   566 		a link relation type of <code>type</code> (that is, <code>rel='type'</code>)
   549 		in all responses to requests made 
   567 		in all responses to requests made 
   550 		to the LDPR's HTTP <code>Request-URI</code>. 
   568 		to the LDPR's HTTP <code>Request-URI</code>. 
   551 	</div>
   569 	</h2></section><!-- Was 4.2.10 / #ldpr-4_2_10 -->
   552 	<blockquote>
   570 	<blockquote>
   553 		<p>
   571 		<p>
   554 		Note: 
   572 		Note: 
   555 		The HTTP <code>Link</code> header is the method by which servers assert their support for the LDP specification 
   573 		The HTTP <code>Link</code> header is the method by which servers assert their support for the LDP specification 
   556 		on a specific resource in a way that clients can inspect dynamically at run-time.   
   574 		on a specific resource in a way that clients can inspect dynamically at run-time.   
   557 		This is <strong>not</strong> equivalent to the
   575 		This is <strong>not</strong> equivalent to the
   558 		presence of a <var>(subject-URI, <code>rdf:type</code>, <code>ldp:Resource</code>)</var> triple in an RDF resource.
   576 		presence of a <var>(subject-URI, <code>rdf:type</code>, <code>ldp:Resource</code>)</var> triple in an RDF resource.
   559 		The presence of this header asserts that the server complies with the LDP specification's constraints on 
   577 		The presence of this header asserts that the server complies with the LDP specification's constraints on 
   560 		HTTP interactions with LDPRs, that is
   578 		HTTP interactions with LDPRs, that is
   561 		it asserts that the resource <a href="#ldpr-4_2_8">has Etags</a>, <a href="#ldpr-4_2_2">has an RDF representation</a>, and so on,
   579 		it asserts that the resource <a href="#ldpr-gen-tags">has Etags</a>, <a href="#ldpr-gen-rdf">has an RDF representation</a>, and so on,
   562 		which is not true of all Web resources served as RDF media types.
   580 		which is not true of all Web resources served as RDF media types.
   563 		</p>
   581 		</p>
   564 		<p>
   582 		<p>
   565 		Note: 
   583 		Note: 
   566 		<a href="#ldpr-4_2_3">A LDP server can host a mixture of LDPRs and other resources</a>, and therefore there is no implication
   584 		<a href="#ldpr-gen-binary">A LDP server can host a mixture of LDPRs and other resources</a>, and therefore there is no implication
   567 		that LDP support advertised on one HTTP <code>Request-URI</code> means that other 
   585 		that LDP support advertised on one HTTP <code>Request-URI</code> means that other 
   568 		resources on the same server are also LDPRs.  Each HTTP <code>Request-URI</code> needs to be 
   586 		resources on the same server are also LDPRs.  Each HTTP <code>Request-URI</code> needs to be 
   569 		individually inspected, in the absence of outside information.
   587 		individually inspected, in the absence of outside information.
   570 		</p>
   588 		</p>
   571 	</blockquote>
   589 	</blockquote>
   572 	<div id="ldpr-4_2_11" class="rule">4.2.11 <a title="LDP server">LDP servers</a>
   590 	
       
   591 	<section id="ldpr-gen-noinferencing"><h2 class="normal"><a title="LDP server">LDP servers</a>
   573 		MUST NOT require LDP clients to implement inferencing in order to recognize the subset
   592 		MUST NOT require LDP clients to implement inferencing in order to recognize the subset
   574 		of content defined by LDP.  Other specifications built on top of LDP may require clients
   593 		of content defined by LDP.  Other specifications built on top of LDP may require clients
   575 		to implement inferencing [[!RDF-CONCEPTS]].  The practical implication is that all content defined by LDP
   594 		to implement inferencing [[!RDF-CONCEPTS]].  The practical implication is that all content defined by LDP
   576 		must be explicitly represented. 
   595 		must be explicitly represented. 
   577 	</div>
   596 	</h2></section><!-- Was 4.2.11 / #ldpr-4_2_11 -->
   578 	<div id="ldpr-4_2_12" class="rule">4.2.12 <a title="LDP server">LDP servers</a> MUST assign the default base-URI for [[!RFC3987]] relative-URI resolution to be the HTTP 
   597 	
       
   598 	<section id="ldpr-gen-defbaseuri"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST assign the default 
       
   599 		base-URI for [[!RFC3987]] relative-URI resolution to be the HTTP 
   579 		<code>Request-URI</code> when the resource already exists, and to the URI of the created resource when the request results 
   600 		<code>Request-URI</code> when the resource already exists, and to the URI of the created resource when the request results 
   580 		in the creation of a new resource.
   601 		in the creation of a new resource.
   581 	</div>
   602 	</h2></section><!-- Was 4.2.12 / #ldpr-4_2_12 -->
   582 	<div id="ldpr-4_2_13" class="rule">4.2.13 <a title="LDP server">LDP servers</a> MUST 
   603 	
       
   604 	<section id="ldpr-gen-pubclireqs"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST 
   583 		publish any constraints on <a title="LDP client">LDP clients’</a> ability to 
   605 		publish any constraints on <a title="LDP client">LDP clients’</a> ability to 
   584 		create or update LDPRs, by adding a Link header with <code>rel='describedby'</code> 
   606 		create or update LDPRs, by adding a Link header with <code>rel='describedby'</code> 
   585 		[[!POWDER-DR]] to all responses to requests which fail due to violation of 
   607 		[[!POWDER-DR]] to all responses to requests which fail due to violation of 
   586 		those constraints.  For example, a server that refuses resource creation 
   608 		those constraints.  For example, a server that refuses resource creation 
   587 		requests via HTTP PUT, POST, or PATCH would return this <code>Link</code> header on its 
   609 		requests via HTTP PUT, POST, or PATCH would return this <code>Link</code> header on its 
   589 		The same <code>Link</code> header MAY be provided on other responses.  LDP neither 
   611 		The same <code>Link</code> header MAY be provided on other responses.  LDP neither 
   590 		defines nor constrains the representation of the link's target resource; 
   612 		defines nor constrains the representation of the link's target resource; 
   591 		as stated in [[POWDER-DR]], the target might (or might not) be a POWDER 
   613 		as stated in [[POWDER-DR]], the target might (or might not) be a POWDER 
   592 		document.  Natural language constraint documents are therefore permitted, 
   614 		document.  Natural language constraint documents are therefore permitted, 
   593 		although machine-readable ones facilitate better client interactions.
   615 		although machine-readable ones facilitate better client interactions.
   594 	</div>
   616 	</h2></section><!-- Was 4.2.13 / #ldpr-4_2_13 -->
   595 	<div id="ldpr-page-large" class="rule">4.2.14 <a title="LDP server">LDP servers</a> SHOULD allow clients to retrieve large LDPRs in
   617 	
       
   618 	<section id="ldpr-page-large"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to retrieve large LDPRs in
   596 		pages.
   619 		pages.
   597 		See <a href="#ldpr-Paging" class="sectionRef"></a> for additional requirements associated with <a title="Paged resource">paged resources</a>.
   620 		See <a href="#ldpr-Paging" class="sectionRef"></a> for additional requirements associated with <a title="Paged resource">paged resources</a>.
   598 	</div>
   621 	</h2></section><!-- Was 4.2.14 / #ldpr-4_2_14 -->
   599 	<div id="ldpr-split-any" class="rule">4.2.15 <a title="LDP server">LDP servers</a> MAY 
   622 	
       
   623 	<section id="ldpr-split-any"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY 
   600 		treat any resource (LDPR or not) as a <a title="Paged resource">paged resource</a>. 
   624 		treat any resource (LDPR or not) as a <a title="Paged resource">paged resource</a>. 
   601 		See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.
   625 		See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.
   602 	</div>
   626 	</h2></section><!-- Was 4.2.15 / #ldpr-4_2_15 -->
   603 
   627 
   604 </section>
   628 </section>
   605 
   629 
   606 <section id="ldpr-HTTP_GET">
   630 <section id="ldpr-HTTP_GET">
   607 <h2>HTTP GET</h2>
   631 <h2>HTTP GET</h2>
   608 	<div id="ldpr-4_3_1" class="rule">4.3.1 <a title="LDP server">LDP servers</a> MUST support the HTTP <code>GET</code> Method for LDPRs.
   632 	<section id="ldpr-get-must"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST support the HTTP <code>GET</code> Method for LDPRs.
   609 	</div>
   633 	</h2></section><!-- Was 4.3.1 / #ldpr-4_3_1 -->
   610 	<div id="ldpr-4_3_2" class="rule">4.3.2 <a title="LDP server">LDP servers</a> MUST support the HTTP response headers defined in 
   634 	
       
   635 	<section id="ldpr-get-options"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST support the HTTP response headers defined in 
   611 		<a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
   636 		<a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
   612 	</div>
   637 	</h2></section><!-- Was 4.3.2 / #ldpr-4_3_2 -->
   613 	<div id="ldpr-4_3_3" class="rule">4.3.3 <a title="LDP server">LDP servers</a> MUST provide a <code>text/turtle</code>
   638 	
       
   639 	<section id="ldpr-get-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide a <code>text/turtle</code>
   614 		representation of the requested LDPR [[!TURTLE]].
   640 		representation of the requested LDPR [[!TURTLE]].
   615 	</div>
   641 	</h2></section><!-- Was 4.3.3 / #ldpr-4_3_3 -->
   616 	<!-- Action-108 removed this 2013-10-22
   642 	
   617 	<div id="ldpr-4_3_4" class="rule">4.3.4 <a title="LDP server">LDP servers</a> MAY provide 
   643 	<section id="ldpr-get-multitypes"><h2 class="normal">In the absence of special knowledge of the application or domain, 
   618 		representations of the requested LDPR beyond those
       
   619 		necessary to conform to this specification, using standard HTTP content negotiation ([[!HTTP11]] Section 12 - Content Negotiation). 
       
   620 		If the client does not indicate a preference, <code>text/turtle</code> SHOULD be returned.
       
   621 	</div>
       
   622 	-->
       
   623 	<div id="ldpr-4_3_5" class="rule">4.3.5 In the absence of special knowledge of the application or domain, 
       
   624 		<a title="LDP client">LDP clients</a> MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
   644 		<a title="LDP client">LDP clients</a> MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
   625 	</div>
   645 	</h2></section><!-- Was 4.3.5 / #ldpr-4_3_5 -->
   626 	<div id="ldpr-4_3_6" class="rule">4.3.6 In the absence of special knowledge of the application or domain, 
   646 
       
   647 	<section id="ldpr-get-typeschange"><h2 class="normal">In the absence of special knowledge of the application or domain, 
   627 		<a title="LDP client">LDP clients</a> MUST assume that the <code>rdf:type</code> values
   648 		<a title="LDP client">LDP clients</a> MUST assume that the <code>rdf:type</code> values
   628 		of a given LDPR can change over time.
   649 		of a given LDPR can change over time.
   629 	</div>
   650 	</h2></section><!-- Was 4.3.6 / #ldpr-4_3_6 -->
   630 </section>
   651 </section>
   631 
   652 
   632 <section id="ldpr-HTTP_POST">
   653 <section id="ldpr-HTTP_POST">
   633 <h2>HTTP POST</h2>
   654 <h2>HTTP POST</h2>
   634 	<p>This specification adds no new requirements on HTTP <code>POST</code> for LDPRs 
   655 	<p>This specification adds no new requirements on HTTP <code>POST</code> for LDPRs 
   636 		new requirement to support that method, and [[!HTTP11]] makes it optional.
   657 		new requirement to support that method, and [[!HTTP11]] makes it optional.
   637 	</p>
   658 	</p>
   638 	<p>Clients can create LDPRs via <code>POST</code> (<a href="#ldpc-HTTP_POST" class="sectionRef"></a>) or
   659 	<p>Clients can create LDPRs via <code>POST</code> (<a href="#ldpc-HTTP_POST" class="sectionRef"></a>) or
   639 		<code>PUT</code> (<a href="#ldpc-HTTP_PUT" class="sectionRef"></a>) to a LDPC, see those 
   660 		<code>PUT</code> (<a href="#ldpc-HTTP_PUT" class="sectionRef"></a>) to a LDPC, see those 
   640 		sections for more details.  Any server-imposed constraints on LDPR creation or update  
   661 		sections for more details.  Any server-imposed constraints on LDPR creation or update  
   641 		<a href="#ldpr-4_2_13">must be advertised</a> to clients.
   662 		<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
   642 	<!-- TODO: movethis content into an intro/overview section and add PATCH. -->
   663 	<!-- TODO: movethis content into an intro/overview section and add PATCH. -->
   643 	</p>
   664 	</p>
   644 </section>
   665 </section>
   645 
   666 
   646 <section id="ldpr-HTTP_PUT">
   667 <section id="ldpr-HTTP_PUT">
   647 <h2>HTTP PUT</h2>
   668 <h2>HTTP PUT</h2>
   648 	<p>This specification imposes the following new requirements on HTTP <code>PUT</code> for LDPRs 
   669 	<p>This specification imposes the following new requirements on HTTP <code>PUT</code> for LDPRs 
   649 		only when the LDPR supports that method.  This specification does not impose any
   670 		only when the LDPR supports that method.  This specification does not impose any
   650 		new requirement to support that method, and [[!HTTP11]] makes it optional.
   671 		new requirement to support that method, and [[!HTTP11]] makes it optional.
   651 		Any server-imposed constraints on LDPR creation or update  
   672 		Any server-imposed constraints on LDPR creation or update  
   652 		<a href="#ldpr-4_2_13">must be advertised</a> to clients.
   673 		<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
   653 	</p>
   674 	</p>
   654 		
   675 		
   655 	<div id="ldpr-4_5_1" class="rule">4.5.1 If a HTTP <code>PUT</code> is accepted on an existing resource, 
   676 	<section id="ldpr-put-replaceall"><h2 class="normal">If a HTTP <code>PUT</code> is accepted on an existing resource, 
   656 		<a title="LDP server">LDP servers</a> MUST
   677 		<a title="LDP server">LDP servers</a> MUST
   657 		replace the entire persistent state of the identified resource with
   678 		replace the entire persistent state of the identified resource with
   658 		the entity representation in the body of the request. 
   679 		the entity representation in the body of the request. 
   659 		<a title="LDP server">LDP servers</a> MAY ignore server managed properties such as <code>dcterms:modified</code> 
   680 		<a title="LDP server">LDP servers</a> MAY ignore server managed properties such as <code>dcterms:modified</code> 
   660 		and <code>dcterms:creator</code> if they are not under
   681 		and <code>dcterms:creator</code> if they are not under
   661 		client control. Any <a title="LDP server">LDP servers</a> that wish
   682 		client control. Any <a title="LDP server">LDP servers</a> that wish
   662 		to support a more sophisticated merge of data provided by the client
   683 		to support a more sophisticated merge of data provided by the client
   663 		with existing state stored on the server for a resource MUST use HTTP
   684 		with existing state stored on the server for a resource MUST use HTTP
   664 		<code>PATCH</code>, not HTTP <code>PUT</code>.
   685 		<code>PATCH</code>, not HTTP <code>PUT</code>.
   665 	</div>
   686 	</h2></section><!-- Was 4.5.1 / #ldpr-4_5_1 -->
   666 		
   687 		
   667 	<div id="ldpr-4_5_1_1" class="rule">4.5.1.1 
   688 	<section id="ldpr-put-servermanagedprops"><h2 class="normal">
   668 		If an otherwise valid HTTP <code>PUT</code> request is received 
   689 		If an otherwise valid HTTP <code>PUT</code> request is received 
   669 		that attempts to change triples the server does not allow clients to modify, 
   690 		that attempts to change triples the server does not allow clients to modify, 
   670 		<a title="LDP server">LDP servers</a> MUST 
   691 		<a title="LDP server">LDP servers</a> MUST 
   671 		respond with a 4xx range status code (typically
   692 		respond with a 4xx range status code (typically
   672 		409 Conflict). 
   693 		409 Conflict). 
   673 		<a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
   694 		<a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
   674 		information about which triples could not be
   695 		information about which triples could not be
   675 		persisted.
   696 		persisted.
   676 		The format of the 4xx response body is not constrained by LDP.
   697 		The format of the 4xx response body is not constrained by LDP.
   677 	</div>
   698 	</h2></section><!-- Was 4.5.1.1 / #ldpr-4_5_1_1 -->
   678 	<blockquote>
   699 	<blockquote>
   679 		Informative note: Clients might provide triples equivalent to those already in the resource's state,
   700 		Informative note: Clients might provide triples equivalent to those already in the resource's state,
   680 		e.g. as part of a GET/update representation/PUT sequence, and those PUT requests are intended to work as long as the 
   701 		e.g. as part of a GET/update representation/PUT sequence, and those PUT requests are intended to work as long as the 
   681 		server-controlled triples are identical on the GET response and the subsequent PUT request.
   702 		server-controlled triples are identical on the GET response and the subsequent PUT request.
   682 	</blockquote>
   703 	</blockquote>
   683 		
   704 		
   684 	<div id="ldpr-4_5_2" class="rule">4.5.2 <a title="LDP client">LDP clients</a> SHOULD use the HTTP <code>If-Match</code>
   705 	<section id="ldpr-put-precond"><h2 class="normal"><a title="LDP client">LDP clients</a> SHOULD use the HTTP <code>If-Match</code>
   685 		header and HTTP <code>ETags</code> to ensure it isn’t
   706 		header and HTTP <code>ETags</code> to ensure it isn’t
   686 		modifying a resource that has changed since the client last retrieved
   707 		modifying a resource that has changed since the client last retrieved
   687 		its representation. <a title="LDP server">LDP servers</a> SHOULD require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
   708 		its representation. <a title="LDP server">LDP servers</a> SHOULD require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
   688 		to detect collisions. <a title="LDP server">LDP servers</a> MUST respond with status code 412
   709 		to detect collisions. <a title="LDP server">LDP servers</a> MUST respond with status code 412
   689 		(Condition Failed) if <code>ETag</code>s fail to match when there are no other
   710 		(Condition Failed) if <code>ETag</code>s fail to match when there are no other
   690 		errors with the request [[!HTTP11]].  <a title="LDP server">LDP servers</a> that require conditional requests MUST respond with status code 428
   711 		errors with the request [[!HTTP11]].  <a title="LDP server">LDP servers</a> that require conditional requests MUST respond with status code 428
   691 		(Precondition Required) when the absence of a precondition is the only reason for rejecting the request [[!RFC6585]].
   712 		(Precondition Required) when the absence of a precondition is the only reason for rejecting the request [[!RFC6585]].
   692 	</div>
   713 	</h2></section><!-- Was 4.5.2 / #ldpr-4_5_2 -->
   693 	<div id="ldpr-4_5_3" class="rule">4.5.3 <a title="LDP client">LDP clients</a> SHOULD always assume that the set of predicates for a
   714 	
       
   715 	<section id="ldpr-put-openpreds"><h2 class="normal"><a title="LDP client">LDP clients</a> SHOULD always assume that the set of predicates for a
   694 		resource of a particular type at an arbitrary server is open, in the
   716 		resource of a particular type at an arbitrary server is open, in the
   695 		sense that different resources of the same type may not all have the
   717 		sense that different resources of the same type may not all have the
   696 		same set of predicates in their triples, and the set of predicates that
   718 		same set of predicates in their triples, and the set of predicates that
   697 		are used in the state of any one resource is not limited to any pre-defined
   719 		are used in the state of any one resource is not limited to any pre-defined
   698 		set.
   720 		set.
   699 		<!-- TODO: This seems to fly in the face of systems that are closed, which we have many, which have a way to discover via some 
   721 		<!-- TODO: This seems to fly in the face of systems that are closed, which we have many, which have a way to discover via some 
   700 		out of bands means. -->
   722 		out of bands means. -->
   701 	</div>
   723 	</h2></section><!-- Was 4.5.3 / #ldpr-4_5_3 -->
   702 	<div id="ldpr-4_5_4" class="rule">4.5.4 
   724 	
       
   725 	<section id="ldpr-put-failed"><h2 class="normal">
   703 		If an otherwise valid HTTP <code>PUT</code> request is received that contains triples the server 
   726 		If an otherwise valid HTTP <code>PUT</code> request is received that contains triples the server 
   704 		chooses not to persist, e.g. unknown content,
   727 		chooses not to persist, e.g. unknown content,
   705 		<a title="LDP server">LDP servers</a> MUST respond with an appropriate 4xx range status code
   728 		<a title="LDP server">LDP servers</a> MUST respond with an appropriate 4xx range status code
   706 		[[HTTP11]].  
   729 		[[HTTP11]].  
   707 		<a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
   730 		<a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
   708 		information about which triples could not be
   731 		information about which triples could not be
   709 		persisted.
   732 		persisted.
   710 		The format of the 4xx response body is not constrained by LDP.
   733 		The format of the 4xx response body is not constrained by LDP.
   711 		<!-- TODO: MUST respond with Link rel='describedBy' as in 4.2.13 -->
   734 		<!-- TODO: MUST respond with Link rel='describedBy' as in 4.2.13 -->
   712 	</div>
   735 	</h2></section><!-- Was 4.5.4 / #ldpr-4_5_4 -->
   713 	<div id="ldpr-4_5_5" class="rule">4.5.5 An <a title="LDP client">LDP client</a> MUST preserve all triples retrieved using HTTP <code>GET</code> that
   736 	
       
   737 	<section id="ldpr-put-perserveall"><h2 class="normal">An <a title="LDP client">LDP client</a> MUST preserve all triples retrieved using HTTP <code>GET</code> that
   714 		it doesn’t change whether it understands the predicates or not, when
   738 		it doesn’t change whether it understands the predicates or not, when
   715 		its intent is to perform an update using HTTP <code>PUT</code>.  The use of HTTP
   739 		its intent is to perform an update using HTTP <code>PUT</code>.  The use of HTTP
   716 		<code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
   740 		<code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
   717 		[[RFC5789]].
   741 		[[RFC5789]].
   718 	</div>
   742 	</h2></section><!-- Was 4.5.5 / #ldpr-4_5_5 -->
   719 	<div id="ldpr-4_5_6" class="rule">4.5.6 <a title="LDP server">LDP servers</a> MAY choose to allow the creation of new resources using HTTP <code>PUT</code>.
   743 	
   720 	</div>
   744 	<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>.
   721 	<div id="ldpr-4_5_7" class="rule">4.5.7 <a title="LDP server">LDP servers</a> SHOULD allow clients to update resources without
   745 	</h2></section><!-- Was 4.5.6 / #ldpr-4_5_6 -->
       
   746 	
       
   747 	<section id="ldpr-put-simpleupdate"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to update resources without
   722 		requiring detailed knowledge of server-specific constraints.  
   748 		requiring detailed knowledge of server-specific constraints.  
   723 		This is a consequence of the requirement to enable simple creation and modification of LPDRs.
   749 		This is a consequence of the requirement to enable simple creation and modification of LPDRs.
   724 	</div>		
   750 	</h2></section><!-- Was 4.5.7 / #ldpr-4_5_7 -->	
   725 </section>
   751 </section>
   726 		
   752 		
   727 <section id="ldpr-HTTP_DELETE">
   753 <section id="ldpr-HTTP_DELETE">
   728 <h2>HTTP DELETE</h2>
   754 <h2>HTTP DELETE</h2>
   729 	<p>This specification imposes the following new requirements on HTTP <code>DELETE</code> for LDPRs 
   755 	<p>This specification imposes the following new requirements on HTTP <code>DELETE</code> for LDPRs 
   730 		only when the LDPR supports that method.  This specification does not impose any
   756 		only when the LDPR supports that method.  This specification does not impose any
   731 		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
   757 		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
   732 	<p>Additional requirements on HTTP <code>DELETE</code> of LDPRs within containers can be found in
   758 	<p>Additional requirements on HTTP <code>DELETE</code> of LDPRs within containers can be found in
   733 	<a href="#ldpc-HTTP_DELETE" class="sectionRef"></a>.</p>
       
   734 		
       
   735 	<!-- Action-108 removed this 2013-10-22
       
   736 	<div id="ldpr-4_6_1" class="rule">4.6.1 <a title="LDP server">LDP servers</a> MUST remove the resource identified by the <code>Request-URI</code>.
       
   737 		After a successful HTTP <code>DELETE</code>, a subsequent HTTP <code>GET</code> on the same
       
   738 		<code>Request-URI</code> MUST result in a 404 (Not found) or 410 (Gone) status
       
   739 		code. Clients SHOULD note that servers MAY reuse a URI under some circumstances.
       
   740 	</div>
       
   741 	-->
       
   742 	
       
   743 	<!-- Action-108 removed this 2013-10-22
       
   744 	<div id="ldpr-4_6_2" class="rule">4.6.2 <a title="LDP server">LDP servers</a> MAY alter the state of other resources as a result of an
       
   745 		HTTP <code>DELETE</code> request. For example, it is acceptable for the server to
       
   746 		remove triples from other resources whose subject or object is the
       
   747 		deleted resource. It is also acceptable and common for <a title="LDP server">LDP servers</a> to
       
   748 		not do this – behavior is server application specific.
       
   749 	</div>
       
   750 	-->
       
   751 </section>
   759 </section>
   752 
   760 
   753 <section id="ldpr-HTTP_HEAD">
   761 <section id="ldpr-HTTP_HEAD">
   754 <h2>HTTP HEAD</h2>
   762 <h2>HTTP HEAD</h2>
   755 	<p>Note that certain LDP mechanisms, such as <a href="#ldpr-Paging">paging</a>, rely on HTTP headers, and HTTP generally requires that
   763 	<p>Note that certain LDP mechanisms, such as <a href="#ldpr-Paging">paging</a>, rely on HTTP headers, and HTTP generally requires that
   756 		<code>HEAD</code> responses include the same headers as <code>GET</code> responses.  
   764 		<code>HEAD</code> responses include the same headers as <code>GET</code> responses.  
   757 		Thus, implementers should also carefully read sections <a href="#ldpr-HTTP_GET"></a> 
   765 		Thus, implementers should also carefully read sections <a href="#ldpr-HTTP_GET"></a> 
   758 		and <a href="#ldpr-HTTP_OPTIONS"></a>.</p>
   766 		and <a href="#ldpr-HTTP_OPTIONS"></a>.</p>
   759 	<div id="ldpr-4_7_1" class="rule">4.7.1 <a title="LDP server">LDP servers</a> MUST support the HTTP <code>HEAD</code> method.</div>
   767 	<section id="ldpr-head-must"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST support the HTTP <code>HEAD</code> method.
       
   768 	</h2></section><!-- Was 4.7.1 / #ldpr-4_7_1 -->
   760 </section>
   769 </section>
   761 
   770 
   762 <section id="ldpr-HTTP_PATCH">
   771 <section id="ldpr-HTTP_PATCH">
   763 <h2>HTTP PATCH</h2>
   772 <h2>HTTP PATCH</h2>
   764 	<p>This specification imposes the following new requirements on HTTP <code>PATCH</code> for LDPRs 
   773 	<p>This specification imposes the following new requirements on HTTP <code>PATCH</code> for LDPRs 
   765 		only when the LDPR supports that method.  This specification does not impose any
   774 		only when the LDPR supports that method.  This specification does not impose any
   766 		new requirement to support that method, and [[!HTTP11]] makes it optional.
   775 		new requirement to support that method, and [[!HTTP11]] makes it optional.
   767 		Any server-imposed constraints on LDPR creation or update  
   776 		Any server-imposed constraints on LDPR creation or update  
   768 		<a href="#ldpr-4_2_13">must be advertised</a> to clients.
   777 		<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
   769 	</p>	
   778 	</p>	
   770 	<!-- Action-108 removed this 2013-10-22
   779 
   771 	<div id="ldpr-4_8_1" class="rule">4.8.1 <a title="LDP server">LDP servers</a> MAY implement HTTP <code>PATCH</code> to allow modifications,
   780 	<section id="ldpr-patch-create"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD NOT allow clients to create new resources using <code>PATCH</code>.
   772 		especially partial replacement, of their resources [[!RFC5789]]. No
       
   773 		minimal set of patch document formats is mandated by this document.
       
   774 	</div>
       
   775 	-->
       
   776 	<div id="ldpr-4_8_3" class="rule">4.8.3 <a title="LDP server">LDP servers</a> SHOULD NOT allow clients to create new resources using <code>PATCH</code>.
       
   777 		<a href="#ldpc-HTTP_POST"><code>POST</code> (to an LDPC)</a> and/or <a href="#ldpr-HTTP_PUT"><code>PUT</code></a> should be used as the standard way to create new LDPRs.
   781 		<a href="#ldpc-HTTP_POST"><code>POST</code> (to an LDPC)</a> and/or <a href="#ldpr-HTTP_PUT"><code>PUT</code></a> should be used as the standard way to create new LDPRs.
   778 	</div>
   782 	</h2></section><!-- Was 4.8.3 / #ldpr-4_8_3 -->
   779 	<div id="ldpr-4_8_4" class="rule">4.8.4 <a title="LDP server">LDP servers</a> that support <code>PATCH</code> MUST
   783 	
       
   784 	<section id="ldpr-patch-acceptpatch"><h2 class="normal"><a title="LDP server">LDP servers</a> that support <code>PATCH</code> MUST
   780 		include an <code>Accept-Patch</code> HTTP response header [[!RFC5789]] on HTTP <code>OPTIONS</code>
   785 		include an <code>Accept-Patch</code> HTTP response header [[!RFC5789]] on HTTP <code>OPTIONS</code>
   781 		requests, listing patch document media type(s) supported by the server.
   786 		requests, listing patch document media type(s) supported by the server.
   782 	</div>
   787 	</h2></section><!-- Was 4.8.4 / #ldpr-4_8_4 -->
   783 
   788 
   784 </section>
   789 </section>
   785 
   790 
   786 <section id="ldpr-HTTP_OPTIONS">
   791 <section id="ldpr-HTTP_OPTIONS">
   787 <h2>HTTP OPTIONS</h2>
   792 <h2>HTTP OPTIONS</h2>
   791 		<a href="#header-accept-post">Accept-Post</a>
   796 		<a href="#header-accept-post">Accept-Post</a>
   792 		and <a href="#ldpr-paging-HTTP_OPTIONS">Paging</a>,
   797 		and <a href="#ldpr-paging-HTTP_OPTIONS">Paging</a>,
   793 		add other requirements on <code>OPTIONS</code> responses.
   798 		add other requirements on <code>OPTIONS</code> responses.
   794 		</p>
   799 		</p>
   795 
   800 
   796 	<div id="ldpr-4_9_1" class="rule">4.9.1 <a title="LDP server">LDP servers</a> MUST support the HTTP <code>OPTIONS</code> method.</div>		
   801 	<section id="ldpr-options-must"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST support the HTTP <code>OPTIONS</code> method.
   797 	<div id="ldpr-4_9_2" class="rule">4.9.2 <a title="LDP server">LDP servers</a> MUST indicate their support for HTTP Methods by
   802 	</h2></section><!-- Was 4.9.1 / #ldpr-4_9_1 -->
       
   803 		
       
   804 	<section id="ldpr-options-allow"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST indicate their support for HTTP Methods by
   798 		responding to a HTTP <code>OPTIONS</code> request on the LDPR’s URL with the HTTP
   805 		responding to a HTTP <code>OPTIONS</code> request on the LDPR’s URL with the HTTP
   799 		Method tokens in the HTTP response header <code>Allow</code>.
   806 		Method tokens in the HTTP response header <code>Allow</code>.
   800 	</div>
   807 	</h2></section><!-- Was 4.9.2 / #ldpr-4_9_2 -->
   801 		
   808 		
   802 </section>
   809 </section>
   803 
   810 
   804 <section id="ldpr-Paging">
   811 <section id="ldpr-Paging">
   805 <h2>Paging</h2>
   812 <h2>Paging</h2>
   901    o:status o:ActiveCustomer, o:BronzeCustomer;
   908    o:status o:ActiveCustomer, o:BronzeCustomer;
   902    foaf:name "Alfred E. Smith".
   909    foaf:name "Alfred E. Smith".
   903  </pre>
   910  </pre>
   904 	<p>
   911 	<p>
   905 		In this example, there are only two customers provided in the
   912 		In this example, there are only two customers provided in the
   906 		final page.  To indicate this is the last page, the server omits the <code>Link rel='next'</code> 
   913 		final page.  To indicate this is the last page, the server omits the <code>Link: rel='next'</code> 
   907 		header in its response.
   914 		header in its response.
   908 	</p>
   915 	</p>
   909 	<p>
   916 	<p>
   910 		As mentioned above, retrieving all the pages offered by a server gives no guarantee to a client
   917 		As mentioned above, retrieving all the pages offered by a server gives no guarantee to a client
   911 		that it knows the entire state of the server.  For example, after the server constructs the
   918 		that it knows the entire state of the server.  For example, after the server constructs the
   920 		<a title="LDP server">LDP servers</a> that support paging must 
   927 		<a title="LDP server">LDP servers</a> that support paging must 
   921 		also follow the requirements in this section for all <a title="Paged resource">paged resources</a>
   928 		also follow the requirements in this section for all <a title="Paged resource">paged resources</a>
   922 		and their associated <a title="Single-page resource">single-page resources</a>.
   929 		and their associated <a title="Single-page resource">single-page resources</a>.
   923 	</p>
   930 	</p>
   924 
   931 
   925 	<div id="ldpr-pagingGET-sequences-change" class="rule">4.10.2.1 <a title="LDP server">LDP servers</a> MAY
   932 	<section id="ldpr-pagingGET-sequences-change"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
   926 		add <a title="Single-page resource">single-page resources</a> to a 
   933 		add <a title="Single-page resource">single-page resources</a> to a 
   927 		<a title="Paged resource">paged resource's</a> sequence over time,
   934 		<a title="Paged resource">paged resource's</a> sequence over time,
   928 		but SHOULD only add pages to the end of a sequence.
   935 		but SHOULD only add pages to the end of a sequence.
   929 		</div><div class="rule">
   936 		</h2><!-- Was 4.10.2.1 / #ldpr-pagingGET-sequences-change -->
   930 		<blockquote>Informative note: 
   937 		<blockquote>Informative note: 
   931 		As a result, clients retrieving any <a title="Single-page resource">single-page resource</a> several times can observe its place in the sequence
   938 		As a result, clients retrieving any <a title="Single-page resource">single-page resource</a> several times can observe its place in the sequence
   932 		change as the state of the <a title="Paged resource">paged resource</a> changes.
   939 		change as the state of the <a title="Paged resource">paged resource</a> changes.
   933 		For example, a nominally last page's server might provide a
   940 		For example, a nominally last page's server might provide a
   934 		<a>next page link</a> when the page is retrieved.  Similar situations arise when the page sequence crosses server boundaries; 
   941 		<a>next page link</a> when the page is retrieved.  Similar situations arise when the page sequence crosses server boundaries; 
   935 		server A might host the initial portion of a sequence that links to the last page server A is aware of,  
   942 		server A might host the initial portion of a sequence that links to the last page server A is aware of,  
   936 		hosted on server B, and server B might extend the sequence of pages.
   943 		hosted on server B, and server B might extend the sequence of pages.
   937 		</blockquote>
   944 		</blockquote>
   938 	</div>
   945 
   939 	<!-- Removed - action-113
   946 		<section id="ldpr-pagingGET-first-allowed-onpages"><h2 class="normal">
   940 	<div id="ldpr-pagingGET-first-reqd-onbase" class="rule">4.10.2.1 <a title="LDP server">LDP servers</a> MAY
   947 			<a title="LDP server">LDP servers</a> MAY provide 
   941 		provide an HTTP <code>Link</code>
   948 			a <a>first page link</a> when responding to 
   942 		header whose target URI is the <em>first</em> <a title="Single-page resource">single-page resource</a>, and whose link relation type is <code>first</code> [[!RFC5988]]
   949 			requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
   943 		in responses to <code>GET</code> requests with a <a title="Paged resource">paged resource</a> as the <code>Request-URI</code>.
   950 		</h2></section><!-- Was 4.10.2.1.1 / #ldpr-pagingGET-sequences-change -->
   944 		This is the mechanism by which clients can discover the URL of the first page.  
   951 	
   945 		For example, if there is a LDPR with URL <code>&lt;resourceURL&gt;</code> that supports paging and whose
   952 		<section id="ldpr-pagingGET-last-allowed-onpages"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
   946 		first page URL is <code>&lt;resourceURL&gt;?theFirstPage</code>, then the corresponding link header
   953 			provide a <a>last page link</a>
   947 		would be <code>Link: &lt;?theFirstPage&gt;;rel='first'</code>.
   954 			in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
   948 		If no such <code>Link</code> header is present, 
   955 		</h2></section><!-- Was 4.10.2.1.3 / #ldpr-pagingGET-last-allowed-onpages -->
   949 		then clients have no LDP-defined way to discover that the resource supports paging or the
   956 	</section>
   950 		URI of the first page.
   957 	
   951 	</div>
   958 	<section id="ldpr-pagingGET-next-reqd"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST
   952 	-->
       
   953 	<div id="ldpr-pagingGET-first-allowed-onpages" class="rule">4.10.2.1.1 
       
   954 		<a title="LDP server">LDP servers</a> MAY provide 
       
   955 		a <a>first page link</a> when responding to 
       
   956 		requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
       
   957 	</div>
       
   958 	<div id="ldpr-pagingGET-last-allowed-onbase" class="rule">4.10.2.1.2 removed
       
   959 	</div>
       
   960 	<!-- Removed - action-113
       
   961 	<div id="ldpr-pagingGET-last-allowed-onbase" class="rule">4.10.2.1.2 <a title="LDP server">LDP servers</a> MAY
       
   962 		provide an HTTP <code>Link</code>
       
   963 		header whose target URI is the final <a title="Single-page resource">single-page resource</a>, 
       
   964 		and whose link relation type is <code>last</code> [[!RFC5988]]
       
   965 		in responses to <code>GET</code> requests with a <a title="Paged resource">paged resource</a> as the <code>Request-URI</code> and/or
       
   966 		requests with a <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
       
   967 		This is the mechanism by which clients can discover the URL of the final page without 
       
   968 		following a potentially long sequence of next links.  
       
   969 		If no such <code>Link</code> header is present, 
       
   970 		then clients can only find the final page using LDP-defined means 
       
   971 		by following the <code>next</code> links to the end.
       
   972 	</div>
       
   973 	-->
       
   974 	<div id="ldpr-pagingGET-last-allowed-onpages" class="rule">4.10.2.1.3 <a title="LDP server">LDP servers</a> MAY
       
   975 		provide a <a>last page link</a>
       
   976 		in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
       
   977 	</div>
       
   978 	<div id="ldpr-pagingGET-next-reqd" class="rule">4.10.2.2 <a title="LDP server">LDP servers</a> MUST
       
   979 		provide a <a>next page link</a>
   959 		provide a <a>next page link</a>
   980 		in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> 
   960 		in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> 
   981 		<em>other than the final page</em>
   961 		<em>other than the final page</em>
   982 		as the <code>Request-URI</code>.
   962 		as the <code>Request-URI</code>.
   983 		This is the mechanism by which clients can discover the URL of the next page. 
   963 		This is the mechanism by which clients can discover the URL of the next page. 
   984 	</div>
   964 	</h2><!-- Was 4.10.2.2 / #ldpr-pagingGET-next-reqd-change -->
   985 	<div id="ldpr-pagingGET-lastnext-prohibited" class="rule">4.10.2.2.1 <a title="LDP server">LDP servers</a> MUST NOT
   965 	
   986 		provide a <a>next page link</a>
   966 		<section id="ldpr-pagingGET-lastnext-prohibited"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST NOT
   987 		in responses to <code>GET</code> requests with the final <a title="Single-page resource">single-page resource</a> 
   967 			provide a <a>next page link</a>
   988 		as the <code>Request-URI</code>.
   968 			in responses to <code>GET</code> requests with the final <a title="Single-page resource">single-page resource</a> 
   989 		This is the mechanism by which clients can discover the end of the page sequence
   969 			as the <code>Request-URI</code>.
   990 		as currently known by the server.  
   970 			This is the mechanism by which clients can discover the end of the page sequence
   991 	</div>
   971 			as currently known by the server.  
   992 	<div id="ldpr-pagingGET-prev-allowed" class="rule">4.10.2.2.2 <a title="LDP server">LDP servers</a> MAY
   972 		</h2></section><!-- Was 4.10.2.2.1 / #ldpr-pagingGET-lastnext-prohibited -->
   993 		provide a <a>previous page link</a>
   973 		
   994 		in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a>
   974 		<section id="ldpr-pagingGET-prev-allowed"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
   995 		<em>other than the first page</em>
   975 			provide a <a>previous page link</a>
   996 		as the <code>Request-URI</code>.
   976 			in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a>
   997 		This is one mechanism by which clients can discover the URL of the previous page.  
   977 			<em>other than the first page</em>
   998 	</div>
   978 			as the <code>Request-URI</code>.
   999 	<div id="ldpr-pagingGET-firstprev-prohibited" class="rule">4.10.2.2.3 <a title="LDP server">LDP servers</a> MUST NOT
   979 			This is one mechanism by which clients can discover the URL of the previous page.  
  1000 		provide a <a>previous page link</a>
   980 		</h2></section><!-- Was 4.10.2.2.2 / #ldpr-pagingGET-prev-allowed -->
  1001 		in responses to <code>GET</code> requests with the <em>first</em> <a title="Single-page resource">single-page resource</a> 
   981 		
  1002 		as the <code>Request-URI</code>.
   982 		<section id="ldpr-pagingGET-firstprev-prohibited"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST NOT
  1003 		This is one mechanism by which clients can discover the beginning of the page sequence
   983 			provide a <a>previous page link</a>
  1004 		as currently known by the server.  
   984 			in responses to <code>GET</code> requests with the <em>first</em> <a title="Single-page resource">single-page resource</a> 
  1005 	</div>
   985 			as the <code>Request-URI</code>.
  1006 	<div id="ldpr-pagingGET-collection-reqd" class="rule">4.10.2.2.4 removed
   986 			This is one mechanism by which clients can discover the beginning of the page sequence
  1007 	</div>
   987 			as currently known by the server.  
  1008 	<!-- Removed - action-113
   988 		</h2></section><!-- Was 4.10.2.2.3 / #ldpr-pagingGET-firstprev-prohibited -->
  1009 	<div id="ldpr-pagingGET-collection-reqd" class="rule">4.10.2.2.4 <a title="LDP server">LDP servers</a> MUST
   989 	</section>
  1010 		provide an HTTP <code>Link</code>
   990 
  1011 		header whose target URI is the <a title="Paged resource">paged resource</a>, and whose link relation type is <code>collection</code> [[!RFC5988]]
   991 	<section id="ldpr-pagingGET-page-type-reqd"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST
  1012 		in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> 
       
  1013 		as the <code>Request-URI</code>.
       
  1014 		This is the mechanism by which clients can discover the URL of the resource whose representation 
       
  1015 		has been broken into pages, in cases where some other actor gives the client 
       
  1016 		a <a title="Single-page resource">single-page resource</a> URL. 
       
  1017 	</div>
       
  1018 	-->
       
  1019 	<div id="ldpr-pagingGET-redirect" class="rule">4.10.2.3 removed
       
  1020 	</div>
       
  1021 	<!-- Removed - action-113
       
  1022 	<div id="ldpr-pagingGET-redirect" class="rule">4.10.2.3 <a title="LDP server">LDP servers</a> 
       
  1023 		that initiate paging for a LDPR MUST respond 
       
  1024 		by returning the first page resource using a <code>209 Related Content</code> response 
       
  1025 		with an HTTP <code>Location</code> header providing the first <a title="Single-page resource">single-page resource</a> URL.
       
  1026 	</div>
       
  1027 	-->
       
  1028 	<div id="ldpr-pagingGET-page-type-reqd" class="rule">4.10.2.4 <a title="LDP server">LDP servers</a> MUST
       
  1029 		provide an HTTP <code>Link</code>
   992 		provide an HTTP <code>Link</code>
  1030 		header whose target URI is <code>http://www.w3.org/ns/ldp#Page</code>, and whose link relation type is <code>type</code> [[!RFC5988]]
   993 		header whose target URI is <code>http://www.w3.org/ns/ldp#Page</code>, and whose link relation type is <code>type</code> [[!RFC5988]]
  1031 		in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> 
   994 		in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> 
  1032 		as the <code>Request-URI</code>.
   995 		as the <code>Request-URI</code>.
  1033 		This is one mechanism by which clients know that the resource is one of a sequence of pages.  
   996 		This is one mechanism by which clients know that the resource is one of a sequence of pages.  
  1034 	</div>
   997 	</h2></section><!-- Was 4.10.2.4 / #ldpr-pagingGET-page-type-reqd -->
  1035 </section>
   998 </section>
  1036 
   999 
  1037 <section id="ldpr-paging-HTTP_OPTIONS">
  1000 <section id="ldpr-paging-HTTP_OPTIONS">
  1038 <h3>HTTP OPTIONS</h3>
  1001 <h3>HTTP OPTIONS</h3>
  1039 
  1002 
  1044 		Note that LDP only requires enough from <code>OPTIONS</code> 
  1007 		Note that LDP only requires enough from <code>OPTIONS</code> 
  1045 		for discovery of paging support on a resource, which is considerably
  1008 		for discovery of paging support on a resource, which is considerably
  1046 		less than is required for HTTP <code>GET</code>.  
  1009 		less than is required for HTTP <code>GET</code>.  
  1047 		This lowers server implementation effort.
  1010 		This lowers server implementation effort.
  1048 	</p>
  1011 	</p>
  1049 
       
  1050 	<div id="ldpr-4_10_3_1" class="rule">4.10.3.1 removed
       
  1051 	</div>
       
  1052 	<!-- Removed - action-113
       
  1053 	<div id="ldpr-4_10_3_1" class="rule">4.10.3.1 <a title="LDP server">LDP servers</a> MUST indicate their support for paging by
       
  1054 		providing a <a href="#ldpr-pagingGET-first-reqd-onbase">first page link</a> when responding to HTTP <code>OPTIONS</code> 
       
  1055 		requests with a <a title="Paged resource">paged resource</a> as the <code>Request-URI</code>.
       
  1056 	</div>
       
  1057 	-->
       
  1058 
  1012 
  1059 </section> <!-- h3 -->
  1013 </section> <!-- h3 -->
  1060 
  1014 
  1061 </section> <!-- h2 -->
  1015 </section> <!-- h2 -->
  1062 
  1016 
  1233 	<p>In this example, clients cannot correctly guess
  1187 	<p>In this example, clients cannot correctly guess
  1234 			at the membership triples, so the example includes this information in
  1188 			at the membership triples, so the example includes this information in
  1235 			triples whose subject is the LDPC resource itself.
  1189 			triples whose subject is the LDPC resource itself.
  1236 	</p>
  1190 	</p>
  1237 	
  1191 	
  1238 
  1192 	<section id="ldpc-get_non-member_props"><h2 class="normal">Retrieving Only Non-member Properties
  1239 	<div id="ldpc-get_non-member_props" class="rule">5.1.1 Retrieving Only Non-member Properties
  1193 	</h2><!-- Was 5.1.1 / #ldpc-get_non-member_props -->
  1240 	</div>
       
  1241 	<p>The representation of a container
  1194 	<p>The representation of a container
  1242 		that has many members will be large. There are several important
  1195 		that has many members will be large. There are several important
  1243 		cases where clients need to access only the non-member properties of
  1196 		cases where clients need to access only the non-member properties of
  1244 		the container. Since retrieving the whole container representation to
  1197 		the container. Since retrieving the whole container representation to
  1245 		get this information may be onerous for clients and cause unnecessary
  1198 		get this information may be onerous for clients and cause unnecessary
  1282    ldp:insertedContentRelation ldp:MemberSubject;
  1235    ldp:insertedContentRelation ldp:MemberSubject;
  1283    dcterms:publisher &lt;http://acme.com/&gt;.</pre>
  1236    dcterms:publisher &lt;http://acme.com/&gt;.</pre>
  1284    
  1237    
  1285 	<p>While the same non-member resource could be used to update the non-member properties via PUT,
  1238 	<p>While the same non-member resource could be used to update the non-member properties via PUT,
  1286 		LDP recommends using PATCH for this purpose.</p>
  1239 		LDP recommends using PATCH for this purpose.</p>
  1287 
  1240 		
  1288 	<div id="ldpc-ordering" class="rule">5.1.2 Ordering</div>
  1241 	</section><!-- ldpc-get_non-member_props -->
       
  1242 
       
  1243 	<section id="ldpc-ordering"><h2 class="normal">Ordering</h2>
  1289 	<p>
  1244 	<p>
  1290 		There are many cases where an ordering of the members of the
  1245 		There are many cases where an ordering of the members of the
  1291 		container is important. LDPC does not provide any particular support
  1246 		container is important. LDPC does not provide any particular support
  1292 		for server ordering of members in containers, because any client can
  1247 		for server ordering of members in containers, because any client can
  1293 		order the members in any way it chooses based on the value of any
  1248 		order the members in any way it chooses based on the value of any
  1370 			example to sort the data prior to presentation on a user interface. Also
  1325 			example to sort the data prior to presentation on a user interface. Also
  1371 			as it is possible for a container to have as its members other containers,
  1326 			as it is possible for a container to have as its members other containers,
  1372 			the ordering approach doesn't change as containers themselves are LDPRs and the
  1327 			the ordering approach doesn't change as containers themselves are LDPRs and the
  1373 			properties from the domain model can be leveraged for the sort criteria.
  1328 			properties from the domain model can be leveraged for the sort criteria.
  1374 		</p>
  1329 		</p>
       
  1330 	</section><!-- Was 5.1.2 / #ldpc-ordering -->
  1375 </section>
  1331 </section>
  1376 
  1332 
  1377 <section id="ldpc-general">
  1333 <section id="ldpc-general">
  1378 <h2>General</h2>
  1334 <h2>General</h2>
  1379 	<p>The Linked Data Platform does not define how clients
  1335 	<p>The Linked Data Platform does not define how clients
  1380 		discover <dfn><abbr title="Linked Data Platform Containers">LDPCs</abbr></dfn>.</p>
  1336 		discover <dfn><abbr title="Linked Data Platform Containers">LDPCs</abbr></dfn>.</p>
  1381 
  1337 
  1382 	<div id="ldpc-5_2_1" class="rule">5.2.1 
  1338 	<section id="ldpc-isldpr"><h2 class="normal">Each Linked Data Platform Container MUST also be 
  1383 		Each Linked Data Platform Container MUST also be a conforming Linked Data Platform Resource.
  1339 		a conforming Linked Data Platform Resource.
  1384 	</div>
  1340 	</h2></section><!-- Was 5.2.1 / #ldpc-5_2_1 -->
  1385 	<!-- Action-108 removed this 2013-10-22
  1341 	
  1386 	<div id="ldpc-5_2_2" class="rule">5.2.2 LDPC membership is not exclusive; this means that the same resource
  1342 	<section id="ldpc-mbrpred"><h2 class="normal"><a title="LDP server">LDP servers</a>
  1387 	(LDPR or not) MAY be a member of more than one LDPC.
       
  1388 	</div>
       
  1389 	-->
       
  1390 	<div id="ldpc-5_2_3" class="rule">5.2.3 <a title="LDP server">LDP servers</a>
       
  1391 		SHOULD use the <code>rdfs:member</code> predicate as an LDPC's <a title="Membership predicate">membership predicate</a>
  1343 		SHOULD use the <code>rdfs:member</code> predicate as an LDPC's <a title="Membership predicate">membership predicate</a>
  1392 		if there is no obvious predicate from an application vocabulary to use.
  1344 		if there is no obvious predicate from an application vocabulary to use.
  1393 		The state of an LDPC includes information about which
  1345 		The state of an LDPC includes information about which
  1394 		resources are its members, in the form of <a title="Membership triples">membership triples</a> that
  1346 		resources are its members, in the form of <a title="Membership triples">membership triples</a> that
  1395 		follow a consistent pattern.  The LDPC's state contains enough information for clients to discern
  1347 		follow a consistent pattern.  The LDPC's state contains enough information for clients to discern
  1397 		value used in the container's membership triples (<var>membership-constant-URI</var>), 
  1349 		value used in the container's membership triples (<var>membership-constant-URI</var>), 
  1398 		and the position (subject or object) where those URIs
  1350 		and the position (subject or object) where those URIs
  1399 		occurs in the <a title="Membership triples">membership triples</a>.
  1351 		occurs in the <a title="Membership triples">membership triples</a>.
  1400 		Member resources can be
  1352 		Member resources can be
  1401 		any kind of resource identified by a URI, LDPR or otherwise.
  1353 		any kind of resource identified by a URI, LDPR or otherwise.
  1402 	</div>
  1354 	</h2></section><!-- Was 5.2.3 / #ldpc-5_2_3 -->
  1403 	<div id="ldpc-5_2_4" class="rule">5.2.4 An LDPC representation MUST contain exactly one triple 
  1355 	
       
  1356 	<section id="ldpc-containres"><h2 class="normal">An LDPC representation MUST contain exactly one triple 
  1404 		whose subject is the LDPC URI, 
  1357 		whose subject is the LDPC URI, 
  1405 		whose predicate is the <code>ldp:containerResource</code>, 
  1358 		whose predicate is the <code>ldp:containerResource</code>, 
  1406 		and whose object is the LDPC's membership-constant-URI.
  1359 		and whose object is the LDPC's membership-constant-URI.
  1407 		Commonly the LDPC's URI is the membership-constant-URI, but LDP does not require this.
  1360 		Commonly the LDPC's URI is the membership-constant-URI, but LDP does not require this.
  1408 	</div>
  1361 	</h2></section><!-- Was 5.2.4 / #ldpc-5_2_4 -->
  1409 	<div id="ldpc-5_2_5" class="rule">5.2.5 An LDPC representation MUST contain exactly one triple 
  1362 	
       
  1363 	<section id="ldpc-containtriples"><h2 class="normal">An LDPC representation MUST contain exactly one triple 
  1410 		whose subject is the LDPC URI, 
  1364 		whose subject is the LDPC URI, 
  1411 		and whose predicate is either <code>ldp:containsRelation</code> or <code>ldp:containedByRelation</code>. 
  1365 		and whose predicate is either <code>ldp:containsRelation</code> or <code>ldp:containedByRelation</code>. 
  1412 		The object of the triple is constrained by other sections, such as
  1366 		The object of the triple is constrained by other sections, such as
  1413 		<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>, based on the 
  1367 		<a href="#ldpc-containtriple-relation" class="sectionRef">ldp:containsRelation</a> or 
       
  1368 		<a href="#ldpc-containtriple-byrelation" class="sectionRef">ldp:containedByRelation</a>, based on the 
  1414 		<a title="Membership triples">membership triple</a> 
  1369 		<a title="Membership triples">membership triple</a> 
  1415 		pattern used by the container.
  1370 		pattern used by the container.
  1416 	</div>
  1371 	</h2><!-- Was 5.2.5 / #ldpc-5_2_5 -->
  1417 	<div id="ldpc-5_2_5_1" class="rule">5.2.5.1 LDPCs whose <a title="Membership triples">membership triple</a> 
  1372 	
       
  1373 	<section id="ldpc-containtriple-relation"><h2 class="normal">LDPCs whose <a title="Membership triples">membership triple</a> 
  1418 		pattern is <var>( membership-constant-URI , membership-predicate , member-derived-URI )</var> MUST
  1374 		pattern is <var>( membership-constant-URI , membership-predicate , member-derived-URI )</var> MUST
  1419 		contain exactly one triple
  1375 		contain exactly one triple
  1420 		whose subject is the LDPC URI, 
  1376 		whose subject is the LDPC URI, 
  1421 		whose predicate is either <code>ldp:containsRelation</code>, 
  1377 		whose predicate is either <code>ldp:containsRelation</code>, 
  1422 		and whose object is the URI of <var>membership-predicate</var>.
  1378 		and whose object is the URI of <var>membership-predicate</var>.
  1423 	</div>
  1379 	</h2></section><!-- Was 5.2.5.1 / #ldpc-5_2_5_1 -->
  1424 	<!-- Action-112 rewrote this 2013-11-12, original in this comment
  1380 	
  1425 	<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>
  1381 	<section id="ldpc-containtriple-byrelation"><h2 class="normal">LDPCs whose <a title="Membership triples">membership triple</a> 
  1426 	of the LDPC and predicate of 
       
  1427 	<code>ldp:containsRelation</code>, the object MUST be the URI of the membership predicate <var>P</var> used to
       
  1428 	indicate membership to the linked to LDPC, or simply: <var>T = ( C</var>, <code>ldp:containsRelation</code>, <var>P)</var>. 
       
  1429 	For the membership predicate URI object used in the triple <var>T</var>, it would be found in a resource's
       
  1430 	same subject <var>R</var> and same predicate <var>P</var> membership triples of the form: 
       
  1431 	(<var>R</var>, <var>P</var>, <var>MR</var>), where <var>MR</var> represents URI of
       
  1432 	a member resource.
       
  1433 	</div>
       
  1434 	-->
       
  1435 	<div id="ldpc-5_2_5_2" class="rule">5.2.5.2 LDPCs whose <a title="Membership triples">membership triple</a> 
       
  1436 		pattern is <var>( member-derived-URI , membership-predicate , membership-constant-URI )</var> MUST
  1382 		pattern is <var>( member-derived-URI , membership-predicate , membership-constant-URI )</var> MUST
  1437 		contain exactly one triple
  1383 		contain exactly one triple
  1438 		whose subject is the LDPC URI, 
  1384 		whose subject is the LDPC URI, 
  1439 		whose predicate is either <code>ldp:containedByRelation</code>, 
  1385 		whose predicate is either <code>ldp:containedByRelation</code>, 
  1440 		and whose object is the URI of <var>membership-predicate</var>.
  1386 		and whose object is the URI of <var>membership-predicate</var>.
  1441 	</div>
  1387 	</h2></section><!-- Was 5.2.5.2 / #ldpc-5_2_5_2 -->
  1442 	<!-- Action-112 rewrote this 2013-11-12, original in this comment
  1388 	</section>
  1443 	<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>
  1389 	
  1444 	of the LDPC and predicate of 
  1390 	<section id="ldpc-typecontainer"><h2 class="normal">The representation of a LDPC MUST have an <code>rdf:type</code>
  1445 	<code>ldp:containedByRelation</code>, the object MUST be the URI of the membership predicate <var>P</var> used to
       
  1446 	indicate membership to the linked to LDPC, or simply: <var>T = ( C</var>, <code>ldp:containedByRelation</code>, <var>P)</var>. 
       
  1447 	For the membership predicate URI object used in the triple <var>T</var>, it would be found in a resource's
       
  1448 	object subject <var>R</var> and same predicate <var>P</var> membership triples of the form: 
       
  1449 	(<var>MR</var>, <var>P</var>, <var>R</var>), where <var>MR</var> represents URI of
       
  1450 	a member resource.
       
  1451 	</div>
       
  1452 	-->
       
  1453 	<!-- Action-108 removed this 2013-10-22
       
  1454 	<div id="ldpc-5_2_6" class="rule">5.2.6 The representation of a LDPC MAY include an arbitrary number of
       
  1455 		additional triples whose subjects are the members of the container,
       
  1456 		or that are from the representations of the members (if they have RDF
       
  1457 		representations). This allows a LDPC server to provide clients with
       
  1458 		information about the members without the client having to do a <code>GET</code>
       
  1459 		on each member individually.  See <a href="#ldpc-member_data">section 5.1.1 Container
       
  1460 		Member Information</a> for additional details.
       
  1461     </div>
       
  1462 	-->
       
  1463 	<div id="ldpc-5_2_7" class="rule">5.2.7 The representation of a LDPC MUST have an <code>rdf:type</code>
       
  1464 		of <code>ldp:Container</code>.  Informative note: <a href="#ldp-rdfconcepts-extra-triples-types">LDPCs
  1391 		of <code>ldp:Container</code>.  Informative note: <a href="#ldp-rdfconcepts-extra-triples-types">LDPCs
  1465 		might have additional types</a>, like any RDF resource.
  1392 		might have additional types</a>, like any RDF resource.
  1466 	</div>
  1393 	</h2></section><!-- Was 5.2.7 / #ldpc-5_2_7 -->
  1467 	<div id="ldpc-5_2_8" class="rule">5.2.8 LDPC representations SHOULD NOT use RDF container types <code>rdf:Bag</code>,
  1394 	
       
  1395 	<section id="ldpc-nordfcontainertypes"><h2 class="normal">LDPC representations SHOULD NOT use RDF container types <code>rdf:Bag</code>,
  1468 		<code>rdf:Seq</code> or <code>rdf:List</code>.
  1396 		<code>rdf:Seq</code> or <code>rdf:List</code>.
  1469 	</div>
  1397 	</h2></section><!-- Was 5.2.8 / #ldpc-5_2_8 -->
  1470 	<!-- Action-108 removed this 2013-10-22
  1398 
  1471 	<div id="ldpc-5_2_9" class="rule">5.2.9 <a title="LDP server">LDP servers</a> SHOULD NOT re-use URIs, 
  1399 	<section id="ldpc-indirectmbr"><h2 class="normal">LDPCs MUST contain one triple whose
  1472 		regardless of the mechanism by which members are created (<code>POST</code>, <code>PUT</code>, etc.).
       
  1473 		Certain specific cases exist where a LDPC server MAY delete a resource and then later re-use the
       
  1474 		URI when it identifies the same resource, but only when consistent with Web architecture [[WEBARCH]].
       
  1475 		While it is difficult to provide absolute implementation guarantees of non-reuse in all failure
       
  1476 		scenarios, re-using URIs creates ambiguities for clients that are best avoided.
       
  1477 	</div>
       
  1478 	-->
       
  1479 	<div id="ldpc-5_2_10" class="rule">5.2.10 LDPCs MUST contain one triple whose
       
  1480 	    subject is the LDPC URI, 
  1400 	    subject is the LDPC URI, 
  1481 		whose predicate is <code>ldp:insertedContentRelation</code>, and 
  1401 		whose predicate is <code>ldp:insertedContentRelation</code>, and 
  1482 		whose object <var>ICR</var> describes how the <var>member-derived-URI</var> in 
  1402 		whose object <var>ICR</var> describes how the <var>member-derived-URI</var> in 
  1483 		the container's <a title="Membership triples">membership triples</a> is chosen.
  1403 		the container's <a title="Membership triples">membership triples</a> is chosen.</h2>
  1484 		<ul>
  1404 		<ul>
  1485 		<li>
  1405 		<li>
  1486 		LDP defines the URI <code>ldp:MemberSubject</code> for the common case where
  1406 		LDP defines the URI <code>ldp:MemberSubject</code> for the common case where
  1487 		<var>member-derived-URI</var> is simply the URI assigned by the server to a 
  1407 		<var>member-derived-URI</var> is simply the URI assigned by the server to a 
  1488 		document it creates; for example, if the client POSTs RDF content to a container
  1408 		document it creates; for example, if the client POSTs RDF content to a container
  1491 		LDPCs MUST use the URI <code>ldp:MemberSubject</code> when the <var>member-derived-URI</var>
  1411 		LDPCs MUST use the URI <code>ldp:MemberSubject</code> when the <var>member-derived-URI</var>
  1492 		is chosen in this way.
  1412 		is chosen in this way.
  1493 		</li>
  1413 		</li>
  1494 		<li>
  1414 		<li>
  1495 		In other cases, the <var>member-derived-URI</var> is taken from some triple 
  1415 		In other cases, the <var>member-derived-URI</var> is taken from some triple 
  1496 		<var>( S, P, O)</var> in the document supplied by the client as input to the create request;
  1416 		<var>( S, P, O )</var> in the document supplied by the client as input to the create request;
  1497 		if <var>ICR</var>'s value is <var>P</var>, then the <var>member-derived-URI</var> is
  1417 		if <var>ICR</var>'s value is <var>P</var>, then the <var>member-derived-URI</var> is
  1498 		<var>O</var>.  LDP does not define the behavior when more than one triple containing 
  1418 		<var>O</var>.  LDP does not define the behavior when more than one triple containing 
  1499 		the predicate <var>P</var> is present in the client's input.
  1419 		the predicate <var>P</var> is present in the client's input.
  1500 		For example, if the client POSTs RDF content to a container
  1420 		For example, if the client POSTs RDF content to a container
  1501 		that causes the container to create a new LDPR, and that content contains the triple 
  1421 		that causes the container to create a new LDPR, and that content contains the triple 
  1502 		<var>( &lt;&gt; , foaf:primaryTopic , mypet#Zaza )</var>
  1422 		<var>( &lt;&gt; , foaf:primaryTopic , mypet#Zaza )</var>
  1503 		<code>foaf:primaryTopic</code> says
  1423 		<code>foaf:primaryTopic</code> says
  1504 		that the <var>member-derived-URI</var> is <var>mypet#Zaza</var>.  
  1424 		that the <var>member-derived-URI</var> is <var>mypet#Zaza</var>.  
  1505 		</li>
  1425 		</li>
  1506 		</ul>
  1426 		</ul>
  1507 	</div>
  1427 	</section><!-- Was 5.2.10 / #ldpc-5_2_10 -->
  1508 	<!-- Action-112 rewrote this 2013-11-12, original in this comment
       
  1509 	<div id="ldpc-5_2_10" class="rule">5.2.10 Some LDPCs have members whose URIs are not directly
       
  1510 	    URIs minted upon LDPC member creation, for example URIs with a non-empty fragment identifier [[RFC3986]]. 
       
  1511 	    To determine which member URI to use as the <var>member-derived-URI</var>
       
  1512 		in the  membership triple, LDPCs MUST contain one triple whose
       
  1513 	    subject is the LDPC URI, whose predicate is <code>ldp:insertedContentRelation</code>, and whose object is <var>MO</var>. 
       
  1514 	    <var>MO</var> and the HTTP URI <var>R</var> from <code>POST</code> create 
       
  1515 		(as found in HTTP response <code>Location</code> header) are 
       
  1516 	    used to locate a triple in <var>R</var> of the form <var>(R, MO, N)</var>.
       
  1517 		When the LDPC uses <code>ldp:containsRelation</code>, 
       
  1518 	    <var>N</var> is then used to construct the membership triple of the form: 
       
  1519 		<var>(membership consistent value, membership predicate, N)</var>.
       
  1520 	    When the LDPC uses <code>ldp:containedByRelation</code>,
       
  1521 		the membership triple is
       
  1522 	    of the form: <var>(N, membership predicate, membership consistent value)</var>. 
       
  1523 		To indicate that the member resource URI is the membership object
       
  1524 	    (the default or typical case), the object MUST be set to predefined URI <code>ldp:MemberSubject</code> 
       
  1525 		such that it forms the triple: 
       
  1526 	    <var>(LDPC URI, <code>ldp:insertedContentRelation</code>, <code>ldp:MemberSubject</code>)</var>.
       
  1527 	</div>
       
  1528 	-->
       
  1529 	
  1428 	
  1530 	<!-- NOTE: Saving this sample to help with future editing/understanding or possible insertion directly.
  1429 	<!-- NOTE: Saving this sample to help with future editing/understanding or possible insertion directly.
  1531 	
  1430 	
  1532 	Let's say this LDPC has a containerResource of </people/roger> and containsRelation of pets:has_pet. If I POST the following to the LDPC: 
  1431 	Let's say this LDPC has a containerResource of </people/roger> and containsRelation of pets:has_pet. If I POST the following to the LDPC: 
  1533 
  1432 
  1550 	   a ldp:Container;
  1449 	   a ldp:Container;
  1551 	   ldp:containsRelation pets:has_pet;
  1450 	   ldp:containsRelation pets:has_pet;
  1552 	   ldp:containerResource </people/roger>;
  1451 	   ldp:containerResource </people/roger>;
  1553 	   ldp:insertedContentRelation foaf:primaryTopic .
  1452 	   ldp:insertedContentRelation foaf:primaryTopic .
  1554 	 -->
  1453 	 -->
  1555 	<div id="ldpc-5_2_11" class="rule">5.2.11 <a title="LDP server">LDP servers</a>
  1454 	<section id="ldpc-linktypehdr"><h2 class="normal"><a title="LDP server">LDP servers</a>
  1556 		exposing LDPCs
  1455 		exposing LDPCs
  1557 		MUST advertise their LDP support by exposing a HTTP <code>Link</code> header
  1456 		MUST advertise their LDP support by exposing a HTTP <code>Link</code> header
  1558 		with a target URI of <code>http://www.w3.org/ns/ldp/Container</code>, and
  1457 		with a target URI of <code>http://www.w3.org/ns/ldp/Container</code>, and
  1559 		a link relation type of <code>type</code> (that is, <code>rel='type'</code>)
  1458 		a link relation type of <code>type</code> (that is, <code>rel='type'</code>)
  1560 		in all responses to requests made 
  1459 		in all responses to requests made 
  1561 		to the LDPC's HTTP <code>Request-URI</code>. 
  1460 		to the LDPC's HTTP <code>Request-URI</code>. 
  1562 		The <a href="#4_2_10">notes on the corresponding LDPR constraint</a> apply
  1461 		The <a href="#ldpr-gen_linktypehdr">notes on the corresponding LDPR constraint</a> apply
  1563 		equally to LDPCs.
  1462 		equally to LDPCs.
  1564 	</div>
  1463 	</h2></section><!-- Was 5.2.11 / #ldpc-5_2_11 -->
  1565 	
  1464 	
  1566 </section>
  1465 </section>
  1567 
  1466 
  1568 <section id="ldpc-HTTP_GET">	
  1467 <section id="ldpc-HTTP_GET">	
  1569 <h2>HTTP GET</h2>
  1468 <h2>HTTP GET</h2>
  1570 
  1469 
  1571 	<div id="ldpc-5_3_1" class="rule">5.3.1 The representation of a LDPC MUST contain a set of 
  1470 	<section id="ldpc-get-mbrtriples"><h2 class="normal">The representation of a LDPC MUST contain a set of 
  1572 		<a title="Membership triples">membership triples</a> following one of the consistent 
  1471 		<a title="Membership triples">membership triples</a> following one of the consistent 
  1573 		patterns from that definition.
  1472 		patterns from that definition.
  1574 		The membership-constant-URI of the triples MAY be the container itself
  1473 		The membership-constant-URI of the triples MAY be the container itself
  1575 		or MAY be another resource (as in the <a href="#ldpc-ex-membership-subj">example</a>).  See also
  1474 		or MAY be another resource (as in the <a href="#ldpc-ex-membership-subj">example</a>).  See also
  1576 		<a href="#ldpc-5_2_3">5.2.3</a>.
  1475 		section on <a href="#ldpc-mbrpred">LDPC membership predicates</a>.
  1577 	</div>
  1476 	</h2></section><!-- Was 5.3.1 / #ldpc-5_3_1 -->
  1578 	<div id="ldpc-5_3_2" class="rule">5.3.2 <a title="LDP server">LDP servers</a> MAY 
  1477 	
       
  1478 	<section id="ldpc-sortcriteriaobj"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY 
  1579 		represent the members of a paged LDPC in a sequential
  1479 		represent the members of a paged LDPC in a sequential
  1580 		order.  If the server does so, it MUST specify the order using a triple 
  1480 		order.  If the server does so, it MUST specify the order using a triple 
  1581 		whose subject is the page URI, 
  1481 		whose subject is the page URI, 
  1582 		whose predicate is <code>ldp:containerSortCriteria</code>, 
  1482 		whose predicate is <code>ldp:containerSortCriteria</code>, 
  1583 		and whose object is a <code>rdf:List</code> of
  1483 		and whose object is a <code>rdf:List</code> of
  1589 		across pages would be undefined. 
  1489 		across pages would be undefined. 
  1590 		The first list entry provides the primary
  1490 		The first list entry provides the primary
  1591 		sorting criterion, any second entry provides a secondary criterion used to order members considered
  1491 		sorting criterion, any second entry provides a secondary criterion used to order members considered
  1592 		equal according to the primary criterion, and so on.
  1492 		equal according to the primary criterion, and so on.
  1593 		<!-- Convert cases like this to a sectionRef -->
  1493 		<!-- Convert cases like this to a sectionRef -->
  1594 		See section <a href="#ldpc-ordering">5.1.2 Ordering</a> for
  1494 		See section <a href="#ldpc-ordering" class="sectionRef"></a> for
  1595 		an example.
  1495 		an example.
  1596 	</div>
  1496 	</h2></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
  1597 	<div id="ldpc-5_3_3" class="rule">5.3.3 LDPC page representations 
  1497 	
       
  1498 	<section id="ldpc-sortliteraltype"><h2 class="normal">LDPC page representations 
  1598 		ordered using <code>ldp:containerSortCriteria</code> MUST contain, 
  1499 		ordered using <code>ldp:containerSortCriteria</code> MUST contain, 
  1599 		in every <code>ldp:containerSortCriterion</code> list entry, 
  1500 		in every <code>ldp:containerSortCriterion</code> list entry, 
  1600 		a triple
  1501 		a triple
  1601 		whose subject is the sort criterion identifier, 
  1502 		whose subject is the sort criterion identifier, 
  1602 		whose predicate is <code>ldp:containerSortPredicate</code> 
  1503 		whose predicate is <code>ldp:containerSortPredicate</code> 
  1604 		the predicate whose value is used to order members between pages (the <dfn>page-ordering values</dfn>).
  1505 		the predicate whose value is used to order members between pages (the <dfn>page-ordering values</dfn>).
  1605 		The only literal data types whose behavior LDP constrains are those defined
  1506 		The only literal data types whose behavior LDP constrains are those defined
  1606 		by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause [[!SPARQL-QUERY]].  Other data types
  1507 		by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause [[!SPARQL-QUERY]].  Other data types
  1607 		can be used, but LDP
  1508 		can be used, but LDP
  1608 		assigns no meaning to them and interoperability will be limited.
  1509 		assigns no meaning to them and interoperability will be limited.
  1609 	</div>
  1510 	</h2></section><!-- Was 5.3.3 / #ldpc-5_3_3 -->
  1610 	<div id="ldpc-5_3_4" class="rule">5.3.4 LDPC page representations 
  1511 	
       
  1512 	<section id="ldpc-sortorder"><h2 class="normal">LDPC page representations 
  1611 		ordered using <code>ldp:containerSortCriteria</code> MUST contain, 
  1513 		ordered using <code>ldp:containerSortCriteria</code> MUST contain, 
  1612 		in every <code>ldp:containerSortCriterion</code> list entry, 
  1514 		in every <code>ldp:containerSortCriterion</code> list entry, 
  1613 		a triple
  1515 		a triple
  1614 		whose subject is the sort criterion identifier, 
  1516 		whose subject is the sort criterion identifier, 
  1615 		whose predicate is <code>ldp:containerSortOrder</code> 
  1517 		whose predicate is <code>ldp:containerSortOrder</code> 
  1616 		and whose object describes the order used.  LDP defines two values,
  1518 		and whose object describes the order used.
       
  1519 		LDP defines two values,
  1617 		<code>ldp:Ascending</code> and <code>ldp:Descending</code>, for use
  1520 		<code>ldp:Ascending</code> and <code>ldp:Descending</code>, for use
  1618 		as the object of this triple.  Other values can be used, but LDP
  1521 		as the object of this triple.  Other values can be used, but LDP
  1619 		assigns no meaning to them and interoperability will be limited.
  1522 		assigns no meaning to them and interoperability will be limited.
  1620 	</div>
  1523 	 </h2></section><!-- Was 5.3.4 / #ldpc-5_3_4 -->
  1621 	<div id="ldpc-5_3_5" class="rule">5.3.5 LDPC page representations 
  1524 	
       
  1525 	<section id="ldpc-sortcollation"><h2 class="normal">LDPC page representations 
  1622 		ordered using <code>ldp:containerSortCriteria</code> MAY contain, 
  1526 		ordered using <code>ldp:containerSortCriteria</code> MAY contain, 
  1623 		in any <code>ldp:containerSortCriterion</code> list entry,
  1527 		in any <code>ldp:containerSortCriterion</code> list entry,
  1624 		a triple
  1528 		a triple
  1625 		whose subject is the sort criterion identifier, 
  1529 		whose subject is the sort criterion identifier, 
  1626 		whose predicate is <code>ldp:containerSortCollation</code> 
  1530 		whose predicate is <code>ldp:containerSortCollation</code> 
  1627 		and whose object identifies the collation used.  LDP defines no values for use
  1531 		and whose object identifies the collation used.
       
  1532 		LDP defines no values for use
  1628 		as the object of this triple.  While it is better for interoperability to use
  1533 		as the object of this triple.  While it is better for interoperability to use
  1629 		open standardized values, any value can be used.
  1534 		open standardized values, any value can be used.
  1630 		When the <code>ldp:containerSortCollation</code> triple is absent and the 
  1535 		When the <code>ldp:containerSortCollation</code> triple is absent and the 
  1631 		<a title="page-ordering values">page-ordering values</a> are strings or simple literals [[!SPARQL-QUERY]], the
  1536 		<a title="page-ordering values">page-ordering values</a> are strings or simple literals [[!SPARQL-QUERY]], the
  1632 		resulting order is as defined by SPARQL SELECT’s ORDER BY clause 
  1537 		resulting order is as defined by SPARQL SELECT’s ORDER BY clause 
  1639 		resulting order is as defined by SPARQL SELECT’s ORDER BY clause 
  1544 		resulting order is as defined by SPARQL SELECT’s ORDER BY clause 
  1640 		[[!SPARQL-QUERY]] using three-argument <code>fn:compare</code>, that is, the 
  1545 		[[!SPARQL-QUERY]] using three-argument <code>fn:compare</code>, that is, the 
  1641 		specified collation.
  1546 		specified collation.
  1642 		The <code>ldp:containerSortCollation</code> triple MUST be omitted for comparisons
  1547 		The <code>ldp:containerSortCollation</code> triple MUST be omitted for comparisons
  1643 		involving <a title="page-ordering values">page-ordering values</a> for which [[!SPARQL-QUERY]] does not use collations.
  1548 		involving <a title="page-ordering values">page-ordering values</a> for which [[!SPARQL-QUERY]] does not use collations.
  1644 	</div>
  1549 	</h2></section><!-- Was 5.3.5 / #ldpc-5_3_5 -->
  1645 </section>
  1550 </section>
  1646 
  1551 
  1647 <section id="ldpc-HTTP_POST">
  1552 <section id="ldpc-HTTP_POST">
  1648 <h2>HTTP POST</h2>
  1553 <h2>HTTP POST</h2>
  1649 	<p>This specification imposes the following new requirements on HTTP <code>POST</code> for LDPCs 
  1554 	<p>This specification imposes the following new requirements on HTTP <code>POST</code> for LDPCs 
  1650 		only when an LDPC supports that method.  This specification does not impose any
  1555 		only when an LDPC supports that method.  This specification does not impose any
  1651 		new requirement to support that method, and [[!HTTP11]] makes it optional.
  1556 		new requirement to support that method, and [[!HTTP11]] makes it optional.
  1652 		Any server-imposed constraints on creation or update  
  1557 		Any server-imposed constraints on creation or update  
  1653 		<a href="#ldpr-4_2_13">must be advertised</a> to clients.
  1558 		<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
  1654 	</p>
  1559 	</p>
  1655 		
  1560 		
  1656 	<div id="ldpc-5_4_1" class="rule">5.4.1 LDPC clients SHOULD create member resources by submitting a representation as
  1561 	<section id="ldpc-post-created201"><h2 class="normal">LDPC clients SHOULD create member resources by submitting a representation as
  1657 		the entity body of the HTTP <code>POST</code> to a known LDPC. If the resource was created successfully, <a title="LDP server">LDP servers</a> MUST
  1562 		the entity body of the HTTP <code>POST</code> to a known LDPC. If the resource was created successfully, <a title="LDP server">LDP servers</a> MUST
  1658 		respond with status code 201 (Created) and the <code>Location</code>
  1563 		respond with status code 201 (Created) and the <code>Location</code>
  1659 		header set to the new resource’s URL. Clients shall not expect any representation in the response
  1564 		header set to the new resource’s URL. Clients shall not expect any representation in the response
  1660 		entity body on a 201 (Created) response.
  1565 		entity body on a 201 (Created) response.
  1661 	</div>
  1566 	</h2></section><!-- Was 5.4.1 / #ldpc-5_4_1 -->
  1662 
  1567 
  1663 	<div id="ldpc-5_4_2" class="rule">5.4.2 After a successful HTTP <code>POST</code> request to a LDPC, the new resource MUST
  1568 	<section id="ldpc-post-createdmbr"><h2 class="normal">After a successful HTTP <code>POST</code> request to a LDPC, the new resource MUST
  1664 		appear as a member of the LDPC until the new resource is deleted or
  1569 		appear as a member of the LDPC until the new resource is deleted or
  1665 		removed by other methods. An LDPC MAY also contain resources that were
  1570 		removed by other methods. An LDPC MAY also contain resources that were
  1666 		added through other means - for example through the user interface of
  1571 		added through other means - for example through the user interface of
  1667 		the site that implements the LDPC.
  1572 		the site that implements the LDPC.
  1668 	</div>
  1573 	</h2></section><!-- Was 5.4.2 / #ldpc-5_4_2 -->
  1669 	
  1574 	
  1670 	<div id="ldpc-5_4_3" class="rule">5.4.3 <a title="LDP server">LDP servers</a> MAY accept an HTTP <code>POST</code> of non-RDF representations for
  1575 	<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 for
  1671 		creation of any kind of resource, for example binary resources.  See <a href="#ldpc-5_4_13">5.4.13</a> for 
  1576 		creation of any kind of resource, for example binary resources.  See <a href="#ldpc-post-acceptposthdr">AcceptPost section</a> for 
  1672 		details on how clients can discover whether a LDPC supports this behavior.
  1577 		details on how clients can discover whether a LDPC supports this behavior.
  1673 	</div>
  1578 	</h2></section><!-- Was 5.4.3 / #ldpc-5_4_3 -->
  1674 	<div id="ldpc-5_4_4" class="rule">5.4.4 <a title="LDP server">LDP servers</a> that successfully create a new resource from a
  1579 	
       
  1580 	<section id="ldpc-post-createrdf"><h2 class="normal"><a title="LDP server">LDP servers</a> that successfully create a new resource from a
  1675 		RDF representation in the request entity body MUST honor the client's requested interaction model(s).  
  1581 		RDF representation in the request entity body MUST honor the client's requested interaction model(s).  
  1676 		If any model cannot be honored, the server MUST fail the request.
  1582 		If any model cannot be honored, the server MUST fail the request.
  1677 	</div>
  1583 	</h2><!-- Was 5.4.4 / #ldpc-5_4_4 -->
  1678 	<ul>
  1584 	<ul>
  1679 	<li>If the request header <a href="#ldpr-4_2_10">specifies an LDPR interaction model</a>, then the server MUST create an LDPR.</li>
  1585 	<li>If the request header <a href="#ldpr-gen-linktypehdr">specifies an LDPR interaction model</a>, then the server MUST create an LDPR.</li>
  1680 	<li>If the request header <a href="#ldpc-5_2_11">specifies an LDPC interaction model</a>, then the server MUST create an LDPC.
  1586 	<li>If the request header <a href="#ldpc-linktypehdr">specifies an LDPC interaction model</a>, then the server MUST create an LDPC.
  1681 	</li>
  1587 	</li>
  1682 	<li>This specification does not constrain the server's behavior in other cases.</li>
  1588 	<li>This specification does not constrain the server's behavior in other cases.</li>
  1683 	<p>Note: A consequence of this is that LDPCs can be used to create LDPCs, if the server supports doing so.</p>
  1589 	<p>Note: A consequence of this is that LDPCs can be used to create LDPCs, if the server supports doing so.</p>
  1684 	</ul>
  1590 	</ul>
  1685 	
  1591 	</section>
  1686 	<div id="ldpc-5_4_5" class="rule">5.4.5 <a title="LDP server">LDP servers</a> MUST accept a request entity body with a request header
  1592 	
       
  1593 	<section id="ldpc-post-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST accept a request entity body with a request header
  1687 	    of <code>Content-Type</code> with value of <code>text/turtle</code> [[!TURTLE]].
  1594 	    of <code>Content-Type</code> with value of <code>text/turtle</code> [[!TURTLE]].
  1688 	</div>
  1595 	</h2></section><!-- Was 5.4.5 / #ldpc-5_4_5 -->
  1689 	<div id="ldpc-5_4_6" class="rule">5.4.6 <a title="LDP server">LDP servers</a> SHOULD use the <code>Content-Type</code> request header 
  1596 	
  1690 		to determine the representation format when the request has an entity body.  
  1597 	<section id="ldpc-post-contenttype"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD use the <code>Content-Type</code> request header 
  1691 	<!-- Action-108 removed this 2013-10-22
  1598 		to determine the representation format when the request has an entity body. 
  1692 		When the header is absent, 
  1599 	</h2></section><!-- Was 5.4.6 / #ldpc-5_4_6 -->
  1693 		<a title="LDP server">LDP servers</a> MAY infer the content type by inspecting the entity body contents [[!HTTP11]].
  1600 	
  1694 	-->
  1601 	<section id="ldpc-post-rdfnullrel"><h2 class="normal">In RDF representations, <a title="LDP server">LDP servers</a> MUST interpret the null relative
  1695 	</div>
       
  1696 	<div id="ldpc-5_4_7" class="rule">5.4.7 In RDF representations, <a title="LDP server">LDP servers</a> MUST interpret the null relative
       
  1697 		URI for the subject of triples in the LDPR representation in the
  1602 		URI for the subject of triples in the LDPR representation in the
  1698 		request entity body as referring to the entity in the request body.
  1603 		request entity body as referring to the entity in the request body.
  1699 		Commonly, that entity is the model for the “to be created” LDPR, so
  1604 		Commonly, that entity is the model for the “to be created” LDPR, so
  1700 		triples whose subject is the null relative URI will usually result in
  1605 		triples whose subject is the null relative URI will usually result in
  1701 		triples in the created resource whose subject is the created
  1606 		triples in the created resource whose subject is the created
  1702 		resource.  
  1607 		resource.  
  1703 	</div>	
  1608 	</h2></section><!-- Was 5.4.7 / #ldpc-5_4_7 -->	
  1704 	<div id="ldpc-5_4_8" class="rule">5.4.8 <a title="LDP server">LDP servers</a> SHOULD assign the URI for the resource to be
  1609 	
  1705 		created using server application specific rules in the absence of a <a href="#ldpc-5_4_10">client hint</a>.
  1610 	<section id="ldpc-post-serverassignuri"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD assign the URI for the resource to be
  1706 	</div>
  1611 		created using server application specific rules in the absence of a <a href="#ldpc-post-slug">client hint</a>.
  1707 	<div id="ldpc-5_4_9" class="rule">5.4.9 <a title="LDP server">LDP servers</a> SHOULD allow clients to create new resources without
  1612 	</h2></section><!-- Was 5.4.8 / #ldpc-5_4_8 -->
       
  1613 	
       
  1614 	<section id="ldpc-post-mincontraints"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to create new resources without
  1708 		requiring detailed knowledge of application-specific constraints.
  1615 		requiring detailed knowledge of application-specific constraints.
  1709 		This is a consequence of the requirement to enable simple creation and modification of LPDRs.
  1616 		This is a consequence of the requirement to enable simple creation and modification of LPDRs.
  1710 		<!-- TODO: Consider reference to 4.2.13 to include Link rel='desribedBy' header for such constraints.  
  1617 		<!-- TODO: Consider reference to 4.2.13 to include Link rel='desribedBy' header for such constraints.  
  1711 		           Also, should this call out LDPRs explicity?  Would think we could just have "resources" statement. -->
  1618 		           Also, should this call out LDPRs explicity?  Would think we could just have "resources" statement. -->
  1712 	</div>
  1619 	</h2></section><!-- Was 5.4.9 / #ldpc-5_4_9 -->
  1713 	<div id="ldpc-5_4_10" class="rule">5.4.10 <a title="LDP server">LDP servers</a> MAY allow clients to suggest the URI for a resource
  1620 	
       
  1621 	<section id="ldpc-post-slug"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY allow clients to suggest the URI for a resource
  1714 		created through <code>POST</code>, using the HTTP <code>Slug</code> header as defined in [[!RFC5023]].  LDP adds
  1622 		created through <code>POST</code>, using the HTTP <code>Slug</code> header as defined in [[!RFC5023]].  LDP adds
  1715 		no new requirements to this usage, so its presence functions as a client hint to the server 
  1623 		no new requirements to this usage, so its presence functions as a client hint to the server 
  1716 		providing a desired string to be incorporated into the server's final choice of resource URI.
  1624 		providing a desired string to be incorporated into the server's final choice of resource URI.
  1717 	</div>
  1625 	</h2></section><!-- Was 5.4.10 / #ldpc-5_4_10 -->
  1718 	
  1626 	
  1719 	<div id="ldpc-5_4_11" class="rule">5.4.11 <a title="LDP server">LDP servers</a> that allow member creation via <code>POST</code> 
  1627 	<section id="ldpc-post-dontreuseuris"><h2 class="normal"><a title="LDP server">LDP servers</a> that allow member creation via <code>POST</code> 
  1720 		SHOULD NOT re-use URIs.
  1628 		SHOULD NOT re-use URIs.
  1721 	</div>
  1629 	</h2></section><!-- Was 5.4.11 / #ldpc-5_4_11 -->
  1722 	
  1630 	
  1723 	<div id="ldpc-5_4_12" class="rule">5.4.12 Upon successful creation of a non-RDF and therefore non-LDPR member (HTTP status code of 
  1631 	<section id="ldpc-post-createbinlinkmetahdr"><h2 class="normal">Upon successful creation of a non-RDF and therefore non-LDPR member (HTTP status code of 
  1724 	201-Created and URI indicated by <code>Location</code> response header), <a title="LDP server">LDP servers</a> MAY create an associated LDPR
  1632 	201-Created and URI indicated by <code>Location</code> response header), <a title="LDP server">LDP servers</a> MAY create an associated LDPR
  1725 	to contain data about the created resource.  If an LDPC server creates this associated LDPR it MUST indicate
  1633 	to contain data about the created resource.  If an LDPC server creates this associated LDPR it MUST indicate
  1726 	its location on the HTTP response using the HTTP response header <code>Link</code> and relationship type <code>meta</code>
  1634 	its location on the HTTP response using the HTTP response header <code>Link</code> and relationship type <code>meta</code>
  1727 	and <code>href</code> to be the URI of the meta-resource [[!RFC5988]].
  1635 	and <code>href</code> to be the URI of the meta-resource [[!RFC5988]].
  1728 	</div>	
  1636 	</h2></section><!-- Was 5.4.12 / #ldpc-5_4_12 -->
  1729 	<div id="ldpc-5_4_13" class="rule">5.4.13 <a title="LDP server">LDP servers</a> that support <code>POST</code> MUST
  1637 	
       
  1638 	<section id="ldpc-post-acceptposthdr"><h2 class="normal"><a title="LDP server">LDP servers</a> that support <code>POST</code> MUST
  1730 		include an <a href="#header-accept-post"><code>Accept-Post</code> response header</a> on HTTP <code>OPTIONS</code>
  1639 		include an <a href="#header-accept-post"><code>Accept-Post</code> response header</a> on HTTP <code>OPTIONS</code>
  1731 		responses, listing post document media type(s) supported by the server.
  1640 		responses, listing post document media type(s) supported by the server.
  1732 		LDP only specifies the use of <code>POST</code> for the purpose of creating new resources, but a server
  1641 		LDP only specifies the use of <code>POST</code> for the purpose of creating new resources, but a server
  1733 		can accept <code>POST</code> requests with other semantics.  
  1642 		can accept <code>POST</code> requests with other semantics.  
  1734 		While "POST to create" is a common interaction pattern, LDP clients are not guaranteed, even when 
  1643 		While "POST to create" is a common interaction pattern, LDP clients are not guaranteed, even when 
  1738 		This requirement on LDP servers is intentionally stronger than the one levied in the
  1647 		This requirement on LDP servers is intentionally stronger than the one levied in the
  1739 		<a href="#header-accept-post">header registration</a>; it is unrealistic to expect all existing resources
  1648 		<a href="#header-accept-post">header registration</a>; it is unrealistic to expect all existing resources
  1740 		that support <code>POST</code> to suddenly return a new header or for all new specifications constraining
  1649 		that support <code>POST</code> to suddenly return a new header or for all new specifications constraining
  1741 		<code>POST</code> to be aware of its existence and require it, but it is a reasonable requirement for new
  1650 		<code>POST</code> to be aware of its existence and require it, but it is a reasonable requirement for new
  1742 		specifications such as LDP.
  1651 		specifications such as LDP.
  1743 	</div>
  1652 	</h2></section><!-- Was 5.4.13 / #ldpc-5_4_13 -->
  1744 		
  1653 		
  1745 	<div id="ldpc-5_4_14" class="rule">5.4.14 LDPCs that create new member resources MAY add triples to the container 
  1654 	<section id="ldpc-post-ldpcreated"><h2 class="normal">LDPCs that create new member resources MAY add triples to the container 
  1746 		as part of member creation to reflect its factory role.  
  1655 		as part of member creation to reflect its factory role.  
  1747 		LDP defines the <code>ldp:created</code> predicate for this purpose.  
  1656 		LDP defines the <code>ldp:created</code> predicate for this purpose.  
  1748 		An LDPC that tracks members created through the LDPC MUST add a triple to the container
  1657 		An LDPC that tracks members created through the LDPC MUST add a triple to the container
  1749 		whose subject is the container's URI, 
  1658 		whose subject is the container's URI, 
  1750 		whose predicate is <code>ldp:created</code>, and
  1659 		whose predicate is <code>ldp:created</code>, and
  1751 		whose object is the newly created member resource's URI; 
  1660 		whose object is the newly created member resource's URI; 
  1752 		it MAY add other triples as well.
  1661 		it MAY add other triples as well.
  1753 	</div>
  1662 	</h2></section><!-- Was 5.4.14 / #ldpc-5_4_14 -->
  1754 
  1663 
  1755 	<div id="ldpc-5_4_15" class="rule">5.4.15 LDPCs 
  1664 	<section id="ldpc-post-indirectmbrrel"><h2 class="normal">LDPCs 
  1756 		whose <code>ldp:insertedContentRelation</code> triple has an object
  1665 		whose <code>ldp:insertedContentRelation</code> triple has an object
  1757 		<strong>other than</strong> <code>ldp:MemberSubject</code> 
  1666 		<strong>other than</strong> <code>ldp:MemberSubject</code> 
  1758 		and that create new resources 
  1667 		and that create new resources 
  1759 		MUST add a triple to the container
  1668 		MUST add a triple to the container
  1760 		whose subject is the container's URI, 
  1669 		whose subject is the container's URI, 
  1761 		whose predicate is <code>ldp:created</code>, and
  1670 		whose predicate is <code>ldp:created</code>, and
  1762 		whose object is the newly created resource's URI (which will be different from
  1671 		whose object is the newly created resource's URI (which will be different from
  1763 		the <var><a href="#ldpc-5_2_10">member-derived URI</a></var> in this case).
  1672 		the <var><a href="#ldpc-indirectmbr">member-derived URI</a></var> in this case).
  1764 		This <code>ldp:created</code> triple can be the only link from the container to the newly created
  1673 		This <code>ldp:created</code> triple can be the only link from the container to the newly created
  1765 		resource in certain cases.
  1674 		resource in certain cases.
  1766 	</div>
  1675 	</h2></section><!-- Was 5.4.15 / #ldpc-5_4_15 -->
  1767 	
  1676 	
  1768 </section>
  1677 </section>
  1769 
  1678 
  1770 <section id="ldpc-HTTP_PUT">
  1679 <section id="ldpc-HTTP_PUT">
  1771 <h2>HTTP PUT</h2>
  1680 <h2>HTTP PUT</h2>
  1772 	<p>This specification imposes the following new requirements on HTTP <code>PUT</code> for LDPCs 
  1681 	<p>This specification imposes the following new requirements on HTTP <code>PUT</code> for LDPCs 
  1773 		only when an LDPC supports that method.  This specification does not impose any
  1682 		only when an LDPC supports that method.  This specification does not impose any
  1774 		new requirement to support that method, and [[!HTTP11]] makes it optional.
  1683 		new requirement to support that method, and [[!HTTP11]] makes it optional.
  1775 		Any server-imposed constraints on creation or update  
  1684 		Any server-imposed constraints on creation or update  
  1776 		<a href="#ldpr-4_2_13">must be advertised</a> to clients.
  1685 		<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
  1777 	</p>
  1686 	</p>
  1778 		
  1687 		
  1779 	<div id="ldpc-5_5_1" class="rule">5.5.1 <a title="LDP server">LDP servers</a> SHOULD NOT allow HTTP <code>PUT</code> to update a LDPC’s <a>membership triples</a>; 
  1688 	<section id="ldpc-put-mbrprops"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD NOT allow HTTP <code>PUT</code> to update a LDPC’s <a>membership triples</a>; 
  1780 		if the server receives such a request, it SHOULD respond with a 409
  1689 		if the server receives such a request, it SHOULD respond with a 409
  1781 		(Conflict) status code.
  1690 		(Conflict) status code.
  1782 	</div>
  1691 	</h2></section><!-- Was 5.5.1 / #ldpc-5_5_1 -->
  1783 	<div id="ldpc-5_5_2" class="rule">5.5.2 <a title="LDP server">LDP servers</a> MAY allow updating LDPC non-membership properties using
  1692 	
       
  1693 	<section id="ldpc-put-nonmbrprops"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY allow updating LDPC non-membership properties using
  1784 		HTTP <code>PUT</code> on a corresponding <a>non-member resource</a>, which
  1694 		HTTP <code>PUT</code> on a corresponding <a>non-member resource</a>, which
  1785 		MAY exclude server-managed properties such as <code>ldp:containerResource</code>, <code>ldp:containsRelation</code>
  1695 		MAY exclude server-managed properties such as <code>ldp:containerResource</code>, <code>ldp:containsRelation</code>
  1786 		and <code>ldp:containedByRelation</code>.
  1696 		and <code>ldp:containedByRelation</code>.
  1787 		The <a href="#ldpc-HTTP_OPTIONS" class="sectionRef"></a> describes the process by which clients
  1697 		The <a href="#ldpc-HTTP_OPTIONS" class="sectionRef"></a> describes the process by which clients
  1788 		use HTTP <code>OPTIONS</code> to discover whether the server offers such a resource, and if so its URL. 
  1698 		use HTTP <code>OPTIONS</code> to discover whether the server offers such a resource, and if so its URL. 
  1789 	</div>
  1699 	</h2></section><!-- Was 5.5.2 / #ldpc-5_5_2 -->
  1790 	    
  1700 	    
  1791     <div id="ldpc-5_5_3" class="rule">5.5.3 removed - inlining
  1701 	<section id="ldpc-put-create"><h2 class="normal"><a title="LDP server">LDP servers</a> that allow member creation via <code>PUT</code> 
  1792 	</div>
       
  1793 	
       
  1794 	<div id="ldpc-5_5_4" class="rule">5.5.4 <a title="LDP server">LDP servers</a> that allow member creation via <code>PUT</code> 
       
  1795 		SHOULD NOT re-use URIs.
  1702 		SHOULD NOT re-use URIs.
  1796 	</div>
  1703 	</h2></section><!-- Was 5.5.4 / #ldpc-5_5_4 -->
  1797 	
  1704 	
  1798 </section>
  1705 </section>
  1799 
  1706 
  1800 <section id="ldpc-HTTP_DELETE">
  1707 <section id="ldpc-HTTP_DELETE">
  1801 <h2>HTTP DELETE</h2>
  1708 <h2>HTTP DELETE</h2>
  1802 	<p>This specification imposes the following new requirements on HTTP <code>DELETE</code> for LDPRs and LDPCs
  1709 	<p>This specification imposes the following new requirements on HTTP <code>DELETE</code> for LDPRs and LDPCs
  1803 		only when a LDPC supports that method.  This specification does not impose any
  1710 		only when a LDPC supports that method.  This specification does not impose any
  1804 		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
  1711 		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
  1805 		
  1712 		
  1806 	<div id="ldpc-5_6_1" class="rule">5.6.1 When a LDPC member resource originally created by the LDPC (for example, one whose representation
  1713 	<section id="ldpc-del-contremovesmbrtriple"><h2 class="normal">When a LDPC member resource originally created by the LDPC (for example, one whose representation
  1807 	    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
  1714 	    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
  1808 		(for example, the member is managed by the same server), the LDPC server MUST also remove it from
  1715 		(for example, the member is managed by the same server), the LDPC server MUST also remove it from
  1809 		the LDPC by removing the corresponding membership triple.
  1716 		the LDPC by removing the corresponding membership triple.
  1810 	</div>	
  1717 	</h2></section><!-- Was 5.6.1 / #ldpc-5_6_1 -->
  1811 	<div id="ldpc-5_6_2" class="rule">5.6.2 When a <a>LDP server</a> successfully completes a <code>DELETE</code> request 
  1718 	
       
  1719 	<section id="ldpc-del-mbrremovesmbrtriple"><h2 class="normal">When a <a>LDP server</a> successfully completes a <code>DELETE</code> request 
  1812 		on a LDPC member resource, it MUST remove any
  1720 		on a LDPC member resource, it MUST remove any
  1813 		membership triples associated with the deleted member resource identified by the <code>Request-URI</code>.
  1721 		membership triples associated with the deleted member resource identified by the <code>Request-URI</code>.
  1814 	</div>	
  1722 	</h2>
  1815 	<blockquote>
  1723 	<blockquote>
  1816 		Informative note: The <a>LDP server</a> might perform additional removal 
  1724 		Informative note: The <a>LDP server</a> might perform additional removal 
  1817 		of member resources, as described in the <a href="#ldp-http-method-side-effects">normative references</a> like [[HTTP11]]. 
  1725 		of member resources, as described in the <a href="#ldp-http-method-side-effects">normative references</a> like [[HTTP11]]. 
  1818 		For example, the server could perform additional cleanup tasks for resources it knows are no longer referenced or have not
  1726 		For example, the server could perform additional cleanup tasks for resources it knows are no longer referenced or have not
  1819 		been accessed for some period of time.
  1727 		been accessed for some period of time.
  1820 	</blockquote>
  1728 	</blockquote>
  1821 	<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 
  1729 	</section><!-- Was 5.6.2 / #ldpc-5_6_2 -->
       
  1730 	
       
  1731 	<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 
  1822 		resources that it created using the <code>ldp:created</code> predicate, the LDPC server MUST also remove 
  1732 		resources that it created using the <code>ldp:created</code> predicate, the LDPC server MUST also remove 
  1823 		the deleted member's <code>ldp:created</code> triple.
  1733 		the deleted member's <code>ldp:created</code> triple.
  1824 	</div>	
  1734 	</h2></section><!-- Was 5.6.3 / #ldpc-5_6_3 -->
  1825 	
  1735 	
  1826 	<div id="ldpc-5_6_4" class="rule">5.6.4 When a LDPC member resource originally created by the LDPC (for example, one whose 
  1736 	<section id="ldpc-del-contremovesmbrres"><h2 class="normal">When a LDPC member resource originally created by the LDPC (for example, one whose 
  1827 	representation was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server 
  1737 	representation was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server 
  1828 	created an associated LDPR (see <a href="#ldpc-5_4_12">5.4.12</a>), the LDPC server MUST also remove the associated LDPR it created.
  1738 	created an associated LDPR (see <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>), the LDPC server MUST also remove the associated LDPR it created.
  1829 	</div>	
  1739 	</h2></section><!-- Was 5.6.4 / #ldpc-5_6_4 -->
  1830 	
  1740 	
  1831 </section>
  1741 </section>
  1832 
  1742 
  1833 <section id="ldpc-HTTP_HEAD">
  1743 <section id="ldpc-HTTP_HEAD">
  1834 <h2>HTTP HEAD</h2>
  1744 <h2>HTTP HEAD</h2>
  1844 <h2>HTTP PATCH</h2>
  1754 <h2>HTTP PATCH</h2>
  1845 	<p>This specification imposes the following new requirements on HTTP <code>PATCH</code> for LDPCs 
  1755 	<p>This specification imposes the following new requirements on HTTP <code>PATCH</code> for LDPCs 
  1846 		only when a LDPC supports that method.  This specification does not impose any
  1756 		only when a LDPC supports that method.  This specification does not impose any
  1847 		new requirement to support that method, and [[!HTTP11]] makes it optional.
  1757 		new requirement to support that method, and [[!HTTP11]] makes it optional.
  1848 		Any server-imposed constraints on LDPR creation or update  
  1758 		Any server-imposed constraints on LDPR creation or update  
  1849 		<a href="#ldpr-4_2_13">must be advertised</a> to clients.
  1759 		<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
  1850 	</p>
  1760 	</p>
  1851 		
  1761 		
  1852 	<div id="ldpc-5_8_1" class="rule">5.8.1 <a title="LDP server">LDP servers</a> are RECOMMENDED to support HTTP <code>PATCH</code> as the preferred
  1762 	<section id="ldpc-patch-req"><h2 class="normal"><a title="LDP server">LDP servers</a> are RECOMMENDED to support HTTP <code>PATCH</code> as the preferred
  1853 		method for updating LDPC non-membership properties.
  1763 		method for updating LDPC non-membership properties.
  1854 	</div>
  1764 	</h2></section><!-- Was 5.8.1 / #ldpc-5_8_1 -->
  1855 </section>
  1765 </section>
  1856 
  1766 
  1857 <section id="ldpc-HTTP_OPTIONS">
  1767 <section id="ldpc-HTTP_OPTIONS">
  1858 <h2>HTTP OPTIONS</h2>
  1768 <h2>HTTP OPTIONS</h2>
  1859 	<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for LDPCs.
  1769 	<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for LDPCs.
  1860 		</p>
  1770 		</p>
  1861 
  1771 
  1862 	<div id="ldpc-5_9_1" class="rule">5.9.1  
  1772 	<section id="ldpc-options-nonmbrprops"><h2 class="normal">
  1863 		<a title="LDP server">LDP servers</a> SHOULD define a corresponding
  1773 		<a title="LDP server">LDP servers</a> SHOULD define a corresponding
  1864 		<a>non-member resource</a>
  1774 		<a>non-member resource</a>
  1865 		to support requests for information about a LDPC
  1775 		to support requests for information about a LDPC
  1866 		without retrieving a full representation including all of its members; 
  1776 		without retrieving a full representation including all of its members; 
  1867 		<!-- sectionref this -->
  1777 		see section <a href="#ldpc-get_non-member_props" class="secitonRef"></a> for
  1868 		see section <a href="#ldpc-get_non-member_props">5.1.1 Retrieving Only Non-member Properties</a> for
  1778 		examples.</h2> 
  1869 		examples. 
       
  1870 		In responses to <code>OPTIONS</code> requests with an LDPC as the <code>Request-URI</code>, 
  1779 		In responses to <code>OPTIONS</code> requests with an LDPC as the <code>Request-URI</code>, 
  1871 		<a title="LDP server">LDP servers</a> that define a non-member resource SHOULD provide an HTTP <code>Link</code>
  1780 		<a title="LDP server">LDP servers</a> that define a non-member resource SHOULD provide an HTTP <code>Link</code>
  1872 		header whose target URI is the <a>non-member resource</a>, and whose link relation type is 
  1781 		header whose target URI is the <a>non-member resource</a>, and whose link relation type is 
  1873 		<code>http://www.w3.org/ns/ldp#nonMemberResource</code> [[!RFC5988]]. 
  1782 		<code>http://www.w3.org/ns/ldp#nonMemberResource</code> [[!RFC5988]]. 
  1874 		This is the mechanism by which clients discover the URL of the non-member resource.  
  1783 		This is the mechanism by which clients discover the URL of the non-member resource.  
  1877 		non-member resource.
  1786 		non-member resource.
  1878 		For example, if there is a LDPC with URL <code>&lt;containerURL&gt;</code> whose corresponding
  1787 		For example, if there is a LDPC with URL <code>&lt;containerURL&gt;</code> whose corresponding
  1879 		non-member resource 
  1788 		non-member resource 
  1880 		URL is <code>&lt;containerURL&gt;?nonMemberProperties</code>, then the corresponding link header
  1789 		URL is <code>&lt;containerURL&gt;?nonMemberProperties</code>, then the corresponding link header
  1881 		would be <code>Link: &lt;?nonMemberProperties&gt;;rel='http://www.w3.org/ns/ldp#nonMemberResource'</code>
  1790 		would be <code>Link: &lt;?nonMemberProperties&gt;;rel='http://www.w3.org/ns/ldp#nonMemberResource'</code>
  1882 	</div>
  1791 	</section><!-- Was 5.9.1 / #ldpc-5_9_1 -->
  1883 	
  1792 	
  1884 	<div id="ldpc-5_9_2" class="rule">5.9.2 When a LDPC creates a non-LDPR (e.g. binary) member (for example, one whose 
  1793 	<section id="ldpc-options-linkmetahdr"><h2 class="normal">When a LDPC creates a non-LDPR (e.g. binary) member (for example, one whose 
  1885 	representation was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) it might create an associated LDPR to contain data about the 
  1794 	representation was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) it might create an associated LDPR to contain data about the 
  1886 	non-LDPR (see <a href="#ldpc-5_4_12">5.4.12</a>).  For non-LDPRs that have this associated LDPR, an LDPC server MUST provide an HTTP <code>Link</code>
  1795 	non-LDPR (see <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>).  For non-LDPRs that have this associated LDPR, an LDPC server MUST provide an HTTP <code>Link</code>
  1887 	header whose target URI is the associated LDPR, and whose link relation type is 
  1796 	header whose target URI is the associated LDPR, and whose link relation type is 
  1888 	<code>meta</code> [[!RFC5988]].
  1797 	<code>meta</code> [[!RFC5988]].
  1889 	
  1798 	
  1890 	<!-- TODO: Consider some improvement to this:
  1799 	<!-- TODO: Consider some improvement to this:
  1891 	
  1800 	
  1892 	Does a LDPC create a non-LDPR? or does and LDPC server do this?
  1801 	Does a LDPC create a non-LDPR? or does and LDPC server do this?
  1893 	What is "it" in the first sentence?
  1802 	What is "it" in the first sentence?
  1894 	Adding a Request-URI clause to the last sentence may help clarify a couple things.
  1803 	Adding a Request-URI clause to the last sentence may help clarify a couple things.
  1895 	
       
  1896 	5.9.2 When an <a>LDP server</a> creates a non-LDPR (e.g. binary) member (for example, one whose 
       
  1897 	representation was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) <strike>it</strike> the LDPC might create an associated LDPR to contain data about the 
       
  1898 	non-LDPR (see <a href="#ldpc-5_4_12">5.4.12</a>).  For non-LDPRs (identified by their Request-URI) that have this associated LDPR, an LDPC server MUST provide an HTTP <code>Link</code>
       
  1899 	header whose target URI is the associated LDPR, and whose link relation type is 
       
  1900 	<code>meta</code> [[!RFC5988]].
       
  1901 	
       
  1902 	 -->
  1804 	 -->
  1903 	
  1805 	
  1904 	</div>
  1806 	</h2></section><!-- Was 5.9.2 / #ldpc-5_9_2 -->
  1905 </section> <!-- h2 -->
  1807 </section> <!-- h2 -->
  1906 
  1808 
  1907 </section> <!-- h1 -->
  1809 </section> <!-- h1 -->
  1908 
  1810 
  1909 <section>
  1811 <section>
  1926 	<p>This specification introduces a new HTTP response header <code>Accept-Post</code> used
  1828 	<p>This specification introduces a new HTTP response header <code>Accept-Post</code> used
  1927 		to specify the document formats accepted by the server on HTTP <code>POST</code> requests.
  1829 		to specify the document formats accepted by the server on HTTP <code>POST</code> requests.
  1928 		It is modelled after the <code>Accept-Patch</code> header defined in [[!RFC5789]].
  1830 		It is modelled after the <code>Accept-Patch</code> header defined in [[!RFC5789]].
  1929 	</p>
  1831 	</p>
  1930    
  1832    
  1931 	<div id="header-accept-post-1" class="rule">6.1.1 The syntax for <code>Accept-Post</code>, using
  1833 	<section id="header-accept-post-1"><h2 class="normal">The syntax for <code>Accept-Post</code>, using
  1932 		the ABNF syntax defined in Section 2.1 of [[!HTTP11]], is:
  1834 		the ABNF syntax defined in Section 2.1 of [[!HTTP11]], is:</h2>
  1933 		<blockquote><code>Accept-Post = "Accept-Post" ":" 1#media-type</code>
  1835 		<blockquote><code>Accept-Post = "Accept-Post" ":" 1#media-type</code>
  1934 		<p>
  1836 		<p>
  1935 		The <code>Accept-Post</code> header specifies a comma-separated list of media-
  1837 		The <code>Accept-Post</code> header specifies a comma-separated list of media-
  1936 		types (with optional parameters) as defined by [[!HTTP11]], Section 3.7.
  1838 		types (with optional parameters) as defined by [[!HTTP11]], Section 3.7.
  1937 		</p>
  1839 		</p>
  1938 		</blockquote>
  1840 		</blockquote>
  1939 	</div>
  1841 	</section><!-- Was 6.1.1 / #header-accept-post-1 -->
  1940 
  1842 
  1941 	<div id="header-accept-post-2" class="rule">6.1.2
  1843 	<section id="header-accept-post-2"><h2 class="normal">
  1942 		The <code>Accept-Post</code> HTTP header SHOULD appear in the <code>OPTIONS</code> response for any resource
  1844 		The <code>Accept-Post</code> HTTP header SHOULD appear in the <code>OPTIONS</code> response for any resource
  1943 		that supports the use of the <code>POST</code> method.  The presence of the
  1845 		that supports the use of the <code>POST</code> method.  The presence of the
  1944 		<code>Accept-Post</code> header in response to any method is an implicit
  1846 		<code>Accept-Post</code> header in response to any method is an implicit
  1945 		indication that <code>POST</code> is allowed on the resource identified by the
  1847 		indication that <code>POST</code> is allowed on the resource identified by the
  1946 		<code>Request-URI</code>.  The presence of a specific document format in
  1848 		<code>Request-URI</code>.  The presence of a specific document format in
  1947 		this header indicates that that specific format is allowed on <code>POST</code> requests to the
  1849 		this header indicates that that specific format is allowed on <code>POST</code> requests to the
  1948 		resource identified by the <code>Request-URI</code>.
  1850 		resource identified by the <code>Request-URI</code>.
  1949 	</div>
  1851 	</h2></section><!-- Was 6.1.2 / #header-accept-post-2 -->
  1950 	
  1852 	
  1951 	<div id="header-accept-post-iana" class="rule">6.1.3 IANA Registration Template</div>
  1853 	<section id="header-accept-post-iana" ><h2 class="normal">IANA Registration Template</h2>
  1952 	<div>
  1854 	<div>
  1953 	<blockquote>
  1855 	<blockquote>
  1954 	<p>
  1856 	<p>
  1955 	The Accept-Post response header must be added to the permanent registry (see [[!RFC3864]]).
  1857 	The Accept-Post response header must be added to the permanent registry (see [[!RFC3864]]).
  1956 	</p>
  1858 	</p>
  1966 	<p>
  1868 	<p>
  1967 	Specification document:  this specification
  1869 	Specification document:  this specification
  1968 	</p>
  1870 	</p>
  1969 	</blockquote>
  1871 	</blockquote>
  1970 	</div>
  1872 	</div>
       
  1873 	</section><!-- Was 6.1.3 / #header-accept-post-iana -->
  1971 
  1874 
  1972 </section>
  1875 </section>
  1973 </section> <!-- Header defns -->
  1876 </section> <!-- Header defns -->
  1974     
  1877     
  1975 <!-- Removed for action-113
  1878 <!-- Removed for action-113
  2044 	</div>
  1947 	</div>
  2045 
  1948 
  2046 </section>
  1949 </section>
  2047 </section> <!-- status code defns -->
  1950 </section> <!-- status code defns -->
  2048     
  1951     
  2049 <section id="ldpclient">
       
  2050 <h1>Linked Data Platform Clients</h1>
       
  2051 <div class="ldp-issue-open">
       
  2052 
       
  2053 
       
  2054 <p>All of the following rules are just copied here, without change; still need to be removed from original section.
       
  2055 Should consider making this section come before the server sections; doing so would cause mass-renumbering however.
       
  2056 </p>
       
  2057 	<div id="ldpr-4_3_5" class="rule">4.3.5 In the absence of special knowledge of the application or domain, 
       
  2058 		<a title="LDP client">LDP clients</a> MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
       
  2059 	</div>
       
  2060 	<div id="ldpr-4_3_6" class="rule">4.3.6 In the absence of special knowledge of the application or domain, 
       
  2061 		<a title="LDP client">LDP clients</a> MUST assume that the <code>rdf:type</code> values
       
  2062 		of a given LDPR can change over time.
       
  2063 	</div>
       
  2064 	<div id="ldpr-4_5_3" class="rule">4.5.3 <a title="LDP client">LDP clients</a> SHOULD always assume that the set of predicates for a
       
  2065 		resource of a particular type at an arbitrary server is open, in the
       
  2066 		sense that different resources of the same type may not all have the
       
  2067 		same set of predicates in their triples, and the set of predicates that
       
  2068 		are used in the state of any one resource is not limited to any pre-defined
       
  2069 		set.
       
  2070 	</div>
       
  2071 	<div id="ldpr-4_5_5" class="rule">4.5.5 A <a title="LDP client">LDP client</a> MUST preserve all triples retrieved using HTTP <code>GET</code> that
       
  2072 		it doesn’t change whether it understands the predicates or not, when
       
  2073 		its intent is to perform an update using HTTP <code>PUT</code>.  The use of HTTP
       
  2074 		<code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
       
  2075 		[[RFC5789]].
       
  2076 	</div>
       
  2077 
       
  2078 </div>
       
  2079 </section> <!-- Client constraints -->
       
  2080 
       
  2081 <section id="base-specs" class="informative">
  1952 <section id="base-specs" class="informative">
  2082 <h1>Notable information from normative references</h1>
  1953 <h1>Notable information from normative references</h1>
  2083 
  1954 
  2084 <div class="ldp-issue-open">
  1955 <div class="ldp-issue-open">
  2085 <p>
  1956 <p>
  2093 While readers, and especially implementers, of LDP are assumed to understand the information in its normative 
  1964 While readers, and especially implementers, of LDP are assumed to understand the information in its normative 
  2094 references, the working group has found that certain points are particularly important to understand.
  1965 references, the working group has found that certain points are particularly important to understand.
  2095 For those thoroughly familiar with the referenced specifications, these points might seem obvious, yet
  1966 For those thoroughly familiar with the referenced specifications, these points might seem obvious, yet
  2096 experience has shown that few non-experts find all of them obvious.  This section enumerates these topics; 
  1967 experience has shown that few non-experts find all of them obvious.  This section enumerates these topics; 
  2097 it is simply re-stating (informatively) information locatable via the normative references.
  1968 it is simply re-stating (informatively) information locatable via the normative references.
  2098 </p>
  1969 </p></div>
  2099 
  1970 
  2100 <section id="specs-webarch" class="informative">
  1971 <section id="specs-webarch" class="informative">
  2101 <h1>Architecture of the World Wide Web</h1>
  1972 <h1>Architecture of the World Wide Web</h1>
  2102 Reference: [[!WEBARCH]]
  1973 Reference: [[!WEBARCH]]
  2103 
  1974 
  2104 	<div id="ldp-webarch-nonexcl-membership" class="rule">9.1.1 LDPC membership is not exclusive; this means that the same resource
  1975 	<section id="ldp-webarch-nonexcl-membership" ><h2 class="normal">LDPC membership is not exclusive; this means that the same resource
  2105 	(LDPR or not) can be a member of more than one LDPC.
  1976 	(LDPR or not) can be a member of more than one LDPC.
  2106 	</div>
  1977 	</h2></section>
  2107 	<div id="ldp-webarch-uri-reuse" class="rule">9.1.2 <a title="LDP server">LDP servers</a> should not re-use URIs, 
  1978 	
       
  1979 	<section id="ldp-webarch-uri-reuse"><h2 class="normal"><a title="LDP server">LDP servers</a> should not re-use URIs, 
  2108 		regardless of the mechanism by which members are created (<code>POST</code>, <code>PUT</code>, etc.).
  1980 		regardless of the mechanism by which members are created (<code>POST</code>, <code>PUT</code>, etc.).
  2109 		Certain specific cases exist where a LDPC server might delete a resource and then later re-use the
  1981 		Certain specific cases exist where a LDPC server might delete a resource and then later re-use the
  2110 		URI when it identifies the same resource, but only when consistent with Web architecture.
  1982 		URI when it identifies the same resource, but only when consistent with Web architecture.
  2111 		While it is difficult to provide absolute implementation guarantees of non-reuse in all failure
  1983 		While it is difficult to provide absolute implementation guarantees of non-reuse in all failure
  2112 		scenarios, re-using URIs creates ambiguities for clients that are best avoided.
  1984 		scenarios, re-using URIs creates ambiguities for clients that are best avoided.
  2113 	</div>
  1985 	</h2></section>
  2114 
  1986 
  2115 </section> 
  1987 </section> 
  2116 
  1988 
  2117 <section id="specs-http" class="informative">
  1989 <section id="specs-http" class="informative">
  2118 <h1>HTTP 1.1</h1>
  1990 <h1>HTTP 1.1</h1>
  2119 Reference: [[!HTTP11]]
  1991 Reference: [[!HTTP11]]
  2120 
  1992 
  2121 	<div id="ldp-http-other-representations" class="rule">9.2.1 <a title="LDP server">LDP servers</a> can support representations beyond those
  1993 	<section id="ldp-http-other-representations"><h2 class="normal"><a title="LDP server">LDP servers</a> can support representations beyond those
  2122 		necessary to conform to this specification. These
  1994 		necessary to conform to this specification. These
  2123 		could be other RDF formats, like N3 or NTriples, but non-RDF formats
  1995 		could be other RDF formats, like N3 or NTriples, but non-RDF formats
  2124 		like HTML [[HTML401]] and JSON [[RFC4627]] would likely be common.  
  1996 		like HTML [[HTML401]] and JSON [[RFC4627]] would likely be common.  
  2125 		HTTP content negotiation ([[HTTP11]] Section 12 - Content Negotiation) is used to select the format.
  1997 		HTTP content negotiation ([[HTTP11]] Section 12 - Content Negotiation) is used to select the format.
  2126 	</div>		
  1998 	</h2></section>
  2127 	<div id="ldp-http-other-methods" class="rule">9.2.2 LDPRs can be created, updated and deleted using methods not defined in
  1999 	
       
  2000 	<section id="ldp-http-other-methods"><h2 class="normal">LDPRs can be created, updated and deleted using methods not defined in
  2128 		this document, for example through application-specific means, SPARQL
  2001 		this document, for example through application-specific means, SPARQL
  2129 		UPDATE, etc. [[SPARQL-UPDATE]], as long as those methods do not conflict with this specification's 
  2002 		UPDATE, etc. [[SPARQL-UPDATE]], as long as those methods do not conflict with this specification's 
  2130 		normative requirements.
  2003 		normative requirements.
  2131 	</div>
  2004 	</h2></section>	
  2132 	<div id="ldp-http-delete-uri-reuse" class="rule">9.2.3 <a title="LDP server">LDP servers</a> 
  2005 	
       
  2006 	<section id="ldp-http-delete-uri-reuse"><h2 class="normal"><a title="LDP server">LDP servers</a> 
  2133 		remove the resource identified by the <code>Request-URI</code> in response to a successful HTTP <code>DELETE</code> request.
  2007 		remove the resource identified by the <code>Request-URI</code> in response to a successful HTTP <code>DELETE</code> request.
  2134 		After such a request, a subsequent HTTP <code>GET</code> on the same
  2008 		After such a request, a subsequent HTTP <code>GET</code> on the same
  2135 		<code>Request-URI</code> usually results in a 404 (Not found) or 410 (Gone) status
  2009 		<code>Request-URI</code> usually results in a 404 (Not found) or 410 (Gone) status
  2136 		code, although HTTP allows others.
  2010 		code, although HTTP allows others.
  2137 	</div>
  2011 	</h2></section>	
  2138 	
  2012 	
  2139 	<div id="ldp-http-method-side-effects" class="rule">9.2.4 <a title="LDP server">LDP servers</a> can alter the state of other resources 
  2013 	<section id="ldp-http-method-side-effects"><h2 class="normal"><a title="LDP server">LDP servers</a> can alter the state of other resources 
  2140 		as a result of any HTTP request, especially when non-safe methods are used ([[HTTP11]] section 9.1). 
  2014 		as a result of any HTTP request, especially when non-safe methods are used ([[HTTP11]] section 9.1). 
  2141 		For example, it is acceptable for the server to
  2015 		For example, it is acceptable for the server to
  2142 		remove triples from other resources whose subject or object is the
  2016 		remove triples from other resources whose subject or object is the
  2143 		deleted resource as the result of a successful HTTP <code>DELETE</code> request. 
  2017 		deleted resource as the result of a successful HTTP <code>DELETE</code> request. 
  2144 		It is also acceptable and common for <a title="LDP server">LDP servers</a> to
  2018 		It is also acceptable and common for <a title="LDP server">LDP servers</a> to
  2145 		not do this – the server's behavior can vary, so LDP clients cannot depend on it.
  2019 		not do this – the server's behavior can vary, so LDP clients cannot depend on it.
  2146 	</div>
  2020 	</h2></section>
  2147 	<div id="ldp-http-patch-allowed" class="rule">9.2.5 <a title="LDP server">LDP servers</a> can implement HTTP <code>PATCH</code> 
  2021 	
       
  2022 	<section id="ldp-http-patch-allowed"><h2 class="normal"><a title="LDP server">LDP servers</a> can implement HTTP <code>PATCH</code> 
  2148 		to allow modifications,
  2023 		to allow modifications,
  2149 		especially partial replacement, of their resources. No
  2024 		especially partial replacement, of their resources. No
  2150 		minimal set of patch document formats is mandated by this document or by the definition of <code>PATCH</code> [[RFC5789]].
  2025 		minimal set of patch document formats is mandated by this document or by the definition of <code>PATCH</code> [[RFC5789]].
  2151 	</div>
  2026 	</h2></section>
  2152 	<div id="ldp-http-content-sniffing" class="rule">9.2.6 
  2027 	
       
  2028 	<section id="ldp-http-content-sniffing"><h2 class="normal"> 
  2153 		When the <code>Content-Type</code> request header is absent from a request, 
  2029 		When the <code>Content-Type</code> request header is absent from a request, 
  2154 		<a title="LDP server">LDP servers</a> might infer the content type by inspecting the entity body contents [[HTTP11]].
  2030 		<a title="LDP server">LDP servers</a> might infer the content type by inspecting the entity body contents [[HTTP11]].
  2155 	</div>
  2031 	</h2></section>
  2156 
  2032 
  2157 </section> 
  2033 </section> 
  2158 
  2034 
  2159 <section id="specs-rdf" class="informative">
  2035 <section id="specs-rdf" class="informative">
  2160 <h1>RDF</h1>
  2036 <h1>RDF</h1>
  2161 Reference: [[RDF-CONCEPTS]]
  2037 Reference: [[RDF-CONCEPTS]]
  2162 
  2038 
  2163 	<div id="ldp-rdfconcepts-extra-triples-any" class="rule">9.3.1 The state of an LDPR 
  2039 	<section id="ldp-rdfconcepts-extra-triples-any"><h2 class="normal"> The state of an LDPR 
  2164 		can have triples with any subject(s).  The URL used to retrieve the
  2040 		can have triples with any subject(s).  The URL used to retrieve the
  2165 		representation of an LDPR need not be the subject of any of its triples.
  2041 		representation of an LDPR need not be the subject of any of its triples.
  2166     </div>
  2042 	</h2></section>
  2167 	<div id="ldp-rdfconcepts-extra-triples-members" class="rule">9.3.2 The representation of an LDPC
  2043 	
       
  2044 	<section id="ldp-rdfconcepts-extra-triples-members"><h2 class="normal"> The representation of an LDPC
  2168 		can include an arbitrary number of
  2045 		can include an arbitrary number of
  2169 		additional triples whose subjects are the members of the container,
  2046 		additional triples whose subjects are the members of the container,
  2170 		or that are from the representations of the members (if they have RDF
  2047 		or that are from the representations of the members (if they have RDF
  2171 		representations). This allows a <a>LDP server</a> to provide clients with
  2048 		representations). This allows a <a>LDP server</a> to provide clients with
  2172 		information about the members without the client having to do a <code>GET</code>
  2049 		information about the members without the client having to do a <code>GET</code>
  2173 		on each member individually.  See <a href="#ldpc-member_data">Container
  2050 		on each member individually.  See <a href="#ldpc-member_data">Container
  2174 		Member Information</a> for additional details.
  2051 		Member Information</a> for additional details.
  2175     </div>
  2052 	</h2></section>
  2176 	<div id="ldp-rdfconcepts-extra-triples-types" class="rule">9.3.3 The state of an LDPR can have more than one
  2053 	
       
  2054 	<section id="ldp-rdfconcepts-extra-triples-types"><h2 class="normal"> The state of an LDPR can have more than one
  2177 		triple with a <code>rdf:type</code> predicate.
  2055 		triple with a <code>rdf:type</code> predicate.
  2178 	</div>
  2056 	</h2></section>
  2179 
  2057 
  2180 </section> 
  2058 </section> 
  2181 
  2059 
  2182 <section id="specs-paging" class="informative">
  2060 <section id="specs-paging" class="informative">
  2183 <h1>Feed paging and archiving</h1>
  2061 <h1>Feed paging and archiving</h1>
  2184 Reference: [[RFC5005]]
  2062 Reference: [[RFC5005]]
  2185 
  2063 
  2186 	<div id="ldp-paging-incomplete" class="rule">9.4.1 A <a title="LDP client">LDP client</a>  
  2064 	<section id="ldp-paging-incomplete"><h2 class="normal"> A <a title="LDP client">LDP client</a>  
  2187 		SHOULD NOT present <a title="paged resource">paged resources</a> as coherent or
  2065 		SHOULD NOT present <a title="paged resource">paged resources</a> as coherent or
  2188 		complete, or make assumptions to that effect.
  2066 		complete, or make assumptions to that effect.
  2189 		[[RFC5005]].
  2067 		[[RFC5005]].
  2190 	</div>
  2068 	</h2></section>
  2191 
  2069 
  2192 </section> 
  2070 </section> 
  2193 
  2071 
  2194 </div>
       
  2195 </section> <!-- Base specs -->
  2072 </section> <!-- Base specs -->
  2196 
  2073 
  2197 <section class='informative' id='security'>
  2074 <section class='informative' id='security'>
  2198 <h1>Security Considerations</h1>
  2075 <h1>Security Considerations</h1>
  2199 As with any protocol that is implemented leveraging HTTP, implementations should take advantage of the many 
  2076 As with any protocol that is implemented leveraging HTTP, implementations should take advantage of the many 
  2230 </p>
  2107 </p>
  2231 
  2108 
  2232 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
  2109 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
  2233 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130730/">Last Call Draft</a></em></blockquote> -->
  2110 <!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130730/">Last Call Draft</a></em></blockquote> -->
  2234 <ul>
  2111 <ul>
       
  2112 	<li>2014-01-17 - First attempt at correcting section ordering and anchors (SS)</li>
  2235 	<li>2014-01-02 - ACTION-122 Updated 4.2.10, 5.4.4, example 8 + added 5.2.11 requiring rel=type for interaction model (JA)</li>
  2113 	<li>2014-01-02 - ACTION-122 Updated 4.2.10, 5.4.4, example 8 + added 5.2.11 requiring rel=type for interaction model (JA)</li>
  2236 	<li>2014-01-02 - ACTION-119 Added 5.4.15 requiring ldp:created for indirect containers (JA)</li>
  2114 	<li>2014-01-02 - ACTION-119 Added 5.4.15 requiring ldp:created for indirect containers (JA)</li>
  2237 	<li>2013-11-27 - ACTION-101 Added informative <a href="#security">security</a> section (SS)</li>
  2115 	<li>2013-11-27 - ACTION-101 Added informative <a href="#security">security</a> section (SS)</li>
  2238 	<li>2013-11-27 - ACTION-100 Added informative note to Ordering section that containers can be nested (SS)</li>
  2116 	<li>2013-11-27 - ACTION-100 Added informative note to Ordering section that containers can be nested (SS)</li>
  2239 	<li>2013-11-18 - Various editorial and validation fixes (SS)</li>
  2117 	<li>2013-11-18 - Various editorial and validation fixes (SS)</li>