--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/drafts/ldp/Overview.html Wed Jul 24 16:10:19 2013 -0400
@@ -0,0 +1,2111 @@
+<!DOCTYPE html>
+<html lang="en" dir="ltr" typeof="bibo:Document w3p:LastCall" about="" property="dcterms:language" content="en">
+<head>
+ <title>Linked Data Platform 1.0</title>
+ <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
+ <!--
+ === NOTA BENE ===
+ For the three scripts below, if your spec resides on dev.w3 you can check them
+ out in the same tree and use relative links so that they'll work offline,
+ -->
+
+
+ <style type="text/css">
+ div.rule {padding-top: 1em;}
+ div.ldp-issue-open {
+ border-color: #E05252;
+ background: #FBE9E9;
+ padding: 0.5em;
+ margin: 1em 0;
+ position: relative;
+ clear: both;
+ border-left-width: .5em;
+ border-left-style: solid;
+ }
+ div.ldp-issue-pending {
+ border-color: #FAF602;
+ background: #F7F6BC;
+ padding: 0.5em;
+ margin: 1em 0;
+ position: relative;
+ clear: both;
+ border-left-width: .5em;
+ border-left-style: solid;
+ }
+ div.ldp-issue-closed {
+ border-color: #009900;
+ background: #BCF7CF;
+ padding: 0.5em;
+ margin: 1em 0;
+ position: relative;
+ clear: both;
+ border-left-width: .5em;
+ border-left-style: solid;
+ }
+ div.ldp-issue-title {
+ color: #E05252;
+ padding-right: 1em;
+ min-width: 7.5em;
+ }
+ .atrisk {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #f00;
+ background: #ffc;
+ }
+ .atrisktext {
+ /* content: "Feature At Risk"; */
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+ }
+
+ </style>
+ <style type="text/css" media="all">
+ code {
+ font-weight:bold;
+ font-size:larger;
+ }
+ /* ReSpec uses color ff4500 for code elements, which does not print well on some black & white printers
+ and is a little hard to read for some folks even on-line.
+ The default code font size was also somewhat too small/hard to read.
+ */
+ </style>
+ <style>/*****************************************************************
+ * ReSpec 3 CSS
+ * Robin Berjon - http://berjon.com/
+ *****************************************************************/
+
+/* --- INLINES --- */
+em.rfc2119 {
+ text-transform: lowercase;
+ font-variant: small-caps;
+ font-style: normal;
+ color: #900;
+}
+
+h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
+h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
+ border: none;
+}
+
+dfn {
+ font-weight: bold;
+}
+
+a.internalDFN {
+ color: inherit;
+ border-bottom: 1px solid #99c;
+ text-decoration: none;
+}
+
+a.externalDFN {
+ color: inherit;
+ border-bottom: 1px dotted #ccc;
+ text-decoration: none;
+}
+
+a.bibref {
+ text-decoration: none;
+}
+
+cite .bibref {
+ font-style: normal;
+}
+
+code {
+ color: #ff4500;
+}
+
+/* --- TOC --- */
+.toc a, .tof a {
+ text-decoration: none;
+}
+
+a .secno, a .figno {
+ color: #000;
+}
+
+ul.tof, ol.tof {
+ list-style: none outside none;
+}
+
+.caption {
+ margin-top: 0.5em;
+ font-style: italic;
+}
+
+/* --- TABLE --- */
+table.simple {
+ border-spacing: 0;
+ border-collapse: collapse;
+ border-bottom: 3px solid #005a9c;
+}
+
+.simple th {
+ background: #005a9c;
+ color: #fff;
+ padding: 3px 5px;
+ text-align: left;
+}
+
+.simple th[scope="row"] {
+ background: inherit;
+ color: inherit;
+ border-top: 1px solid #ddd;
+}
+
+.simple td {
+ padding: 3px 10px;
+ border-top: 1px solid #ddd;
+}
+
+.simple tr:nth-child(even) {
+ background: #f0f6ff;
+}
+
+/* --- DL --- */
+.section dd > p:first-child {
+ margin-top: 0;
+}
+
+.section dd > p:last-child {
+ margin-bottom: 0;
+}
+
+.section dd {
+ margin-bottom: 1em;
+}
+
+.section dl.attrs dd, .section dl.eldef dd {
+ margin-bottom: 0;
+}
+</style><style>/* --- EXAMPLES --- */
+div.example-title {
+ min-width: 7.5em;
+ color: #b9ab2d;
+}
+div.example-title span {
+ text-transform: uppercase;
+}
+aside.example, div.example, div.illegal-example {
+ padding: 0.5em;
+ margin: 1em 0;
+ position: relative;
+ clear: both;
+}
+div.illegal-example { color: red }
+div.illegal-example p { color: black }
+aside.example, div.example {
+ padding: .5em;
+ border-left-width: .5em;
+ border-left-style: solid;
+ border-color: #e0cb52;
+ background: #fcfaee;
+}
+
+aside.example div.example {
+ border-left-width: .1em;
+ border-color: #999;
+ background: #fff;
+}
+aside.example div.example div.example-title {
+ color: #999;
+}
+</style><link rel="stylesheet" href="https://www.w3.org/StyleSheets/TR/W3C-WD"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
+<body class="h-entry" style=""><div class="head">
+ <p>
+
+ <a href="http://www.w3.org/"><img width="72" height="48" src="https://www.w3.org/Icons/w3c_home" alt="W3C"></a>
+
+ </p>
+ <h1 class="title p-name" id="title" property="dcterms:title">Linked Data Platform 1.0</h1>
+
+ <h2 property="dcterms:issued" datatype="xsd:dateTime" content="2013-07-30T04:00:00.000Z" id="w3c-last-call-working-draft-30-july-2013"><abbr title="World Wide Web Consortium">W3C</abbr> Last Call Working Draft <time class="dt-published" datetime="2013-07-30">30 July 2013</time></h2>
+ <dl>
+
+ <dt>This version:</dt>
+ <dd><a class="u-url" href="http://www.w3.org/TR/2013/WD-ldp-20130730/">http://www.w3.org/TR/2013/WD-ldp-20130730/</a></dd>
+ <dt>Latest published version:</dt>
+ <dd><a href="http://www.w3.org/TR/ldp/">http://www.w3.org/TR/ldp/</a></dd>
+
+
+ <dt>Latest editor's draft:</dt>
+ <dd><a href="http://www.w3.org/2012/ldp/hg/ldp.html">http://www.w3.org/2012/ldp/hg/ldp.html</a></dd>
+
+
+
+
+
+ <dt>Previous version:</dt>
+ <dd><a rel="dcterms:replaces" href="http://www.w3.org/TR/2013/WD-ldp-20130307/">http://www.w3.org/TR/2013/WD-ldp-20130307/</a></dd>
+
+
+ <dt>Editors:</dt>
+ <dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Steve Speicher" href="http://stevespeicher.blogspot.com">Steve Speicher</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://ibm.com/">IBM Corporation</a></span>
+</dd>
+<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="John Arwe" href="https://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/allcommunities?userid=120000CAW7">John Arwe</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://ibm.com/">IBM Corporation</a></span>
+</dd>
+<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Ashok Malhotra" href="ashok.malhotra@oracle.com">Ashok Malhotra</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.oracle.com">Oracle Corporation</a></span>
+</dd>
+
+
+
+ </dl>
+
+
+
+
+
+ <p class="copyright">
+ <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
+ 2013
+
+ <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
+ (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
+ <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
+ <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>), All Rights Reserved.
+ <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
+ <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
+ <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.
+ </p>
+
+
+ <hr>
+</div>
+<section id="abstract" class="introductory" property="dcterms:abstract" datatype="" typeof="bibo:Chapter" resource="#abstract" rel="bibo:chapter"><h2>Abstract</h2><p>
+This document describes a set of best practices and simple approach for a read-write Linked Data architecture, based on
+HTTP access to web resources that describe their state using the <abbr title="Resource Description Framework">RDF</abbr>
+data model.
+</p></section><section id="sotd" class="introductory" typeof="bibo:Chapter" resource="#sotd" rel="bibo:chapter"><h2>Status of This Document</h2>
+
+
+
+ <p>
+ <em>This section describes the status of this document at the time of its publication. Other
+ documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the latest revision
+ of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports
+ index</a> at http://www.w3.org/TR/.</em>
+ </p>
+
+ <p>
+ This document was published by the <a href="http://www.w3.org/2012/ldp">Linked Data Platform Working Group</a> as a Last Call Working Draft.
+
+ This document is intended to become a <abbr title="World Wide Web Consortium">W3C</abbr> Recommendation.
+
+
+ If you wish to make comments regarding this document, please send them to
+ <a href="mailto:public-ldp-comments@w3.org">public-ldp-comments@w3.org</a>
+ (<a href="mailto:public-ldp-comments-request@w3.org?subject=subscribe">subscribe</a>,
+ <a href="http://lists.w3.org/Archives/Public/public-ldp-comments/">archives</a>).
+
+ The Last Call period ends 02 September 2013.
+
+
+ All comments are welcome.</p>
+
+
+ <p>
+ Publication as a Last Call Working Draft does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr> Membership.
+ This is a draft document and may be updated, replaced or obsoleted by other documents at
+ any time. It is inappropriate to cite this document as other than work in progress.
+ </p>
+
+
+ <p>
+ This is a Last Call Working Draft and thus the Working Group has determined that this document has satisfied the
+ relevant technical requirements and is sufficiently stable to advance through the Technical Recommendation process.
+ </p>
+
+ <p>
+
+ This document was produced by a group operating under the
+
+ <a id="sotd_patent" about="" rel="w3p:patentRules" href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
+
+
+
+
+
+ <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="http://www.w3.org/2004/01/pp-impl/55082/status" rel="disclosure">public list of any patent disclosures</a>
+
+ made in connection with the deliverables of the group; that page also includes instructions for
+ disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains
+ <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the
+ information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
+ 6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
+
+
+ </p>
+
+
+
+
+</section><section id="toc"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">1. </span>Introduction</a></li><li class="tocline"><a href="#terminology" class="tocxref"><span class="secno">2. </span>Terminology</a><ul class="toc"><li class="tocline"><a href="#conventions-used-in-this-document" class="tocxref"><span class="secno">2.1 </span>Conventions Used in This Document</a></li></ul></li><li class="tocline"><a href="#conformance" class="tocxref"><span class="secno">3. </span>Conformance</a></li><li class="tocline"><a href="#linked-data-platform-resources" class="tocxref"><span class="secno">4. </span>Linked Data Platform Resources</a><ul class="toc"><li class="tocline"><a href="#informative" class="tocxref"><span class="secno">4.1 </span>Informative</a></li><li class="tocline"><a href="#general" class="tocxref"><span class="secno">4.2 </span>General</a></li><li class="tocline"><a href="#http-get" class="tocxref"><span class="secno">4.3 </span>HTTP GET</a></li><li class="tocline"><a href="#http-post" class="tocxref"><span class="secno">4.4 </span>HTTP POST</a></li><li class="tocline"><a href="#http-put" class="tocxref"><span class="secno">4.5 </span>HTTP PUT</a></li><li class="tocline"><a href="#http-delete" class="tocxref"><span class="secno">4.6 </span>HTTP DELETE</a></li><li class="tocline"><a href="#http-head" class="tocxref"><span class="secno">4.7 </span>HTTP HEAD</a></li><li class="tocline"><a href="#http-patch" class="tocxref"><span class="secno">4.8 </span>HTTP PATCH</a></li><li class="tocline"><a href="#http-options" class="tocxref"><span class="secno">4.9 </span>HTTP OPTIONS</a></li><li class="tocline"><a href="#paging" class="tocxref"><span class="secno">4.10 </span>Paging</a><ul class="toc"><li class="tocline"><a href="#introduction-1" class="tocxref"><span class="secno">4.10.1 </span>Introduction</a></li><li class="tocline"><a href="#http-get-1" class="tocxref"><span class="secno">4.10.2 </span>HTTP GET</a></li><li class="tocline"><a href="#http-options-1" class="tocxref"><span class="secno">4.10.3 </span>HTTP OPTIONS</a></li></ul></li><li class="tocline"><a href="#resource-inlining-representing-multiple-resources-in-a-response" class="tocxref"><span class="secno">4.11 </span>Resource Inlining: Representing Multiple Resources in a Response</a><ul class="toc"><li class="tocline"><a href="#introduction-2" class="tocxref"><span class="secno">4.11.1 </span>Introduction</a></li><li class="tocline"><a href="#use-with-care" class="tocxref"><span class="secno">4.11.2 </span>Use with Care</a></li><li class="tocline"><a href="#http-get-2" class="tocxref"><span class="secno">4.11.3 </span>HTTP GET</a></li></ul></li></ul></li><li class="tocline"><a href="#linked-data-platform-containers" class="tocxref"><span class="secno">5. </span>Linked Data Platform Containers</a><ul class="toc"><li class="tocline"><a href="#informative-1" class="tocxref"><span class="secno">5.1 </span>Informative</a></li><li class="tocline"><a href="#general-1" class="tocxref"><span class="secno">5.2 </span>General</a></li><li class="tocline"><a href="#http-get-3" class="tocxref"><span class="secno">5.3 </span>HTTP GET</a></li><li class="tocline"><a href="#http-post-1" class="tocxref"><span class="secno">5.4 </span>HTTP POST</a></li><li class="tocline"><a href="#http-put-1" class="tocxref"><span class="secno">5.5 </span>HTTP PUT</a></li><li class="tocline"><a href="#http-delete-1" class="tocxref"><span class="secno">5.6 </span>HTTP DELETE</a></li><li class="tocline"><a href="#http-head-1" class="tocxref"><span class="secno">5.7 </span>HTTP HEAD</a></li><li class="tocline"><a href="#http-patch-1" class="tocxref"><span class="secno">5.8 </span>HTTP PATCH</a></li><li class="tocline"><a href="#http-options-2" class="tocxref"><span class="secno">5.9 </span>HTTP OPTIONS</a></li><li class="tocline"><a href="#member-inlining-returning-all-of-a-container-page-s-members-in-a-response" class="tocxref"><span class="secno">5.10 </span>Member Inlining: Returning All of a Container Page's Members in a Response</a><ul class="toc"><li class="tocline"><a href="#introduction-3" class="tocxref"><span class="secno">5.10.1 </span>Introduction</a></li><li class="tocline"><a href="#http-get-4" class="tocxref"><span class="secno">5.10.2 </span>HTTP GET</a></li></ul></li></ul></li><li class="tocline"><a href="#http-header-definitions" class="tocxref"><span class="secno">6. </span>HTTP Header Definitions</a><ul class="toc"><li class="tocline"><a href="#the-accept-post-response-header" class="tocxref"><span class="secno">6.1 </span>The Accept-Post Response Header</a></li></ul></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">B. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">B.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">B.2 </span>Informative references</a></li></ul></li></ul></section>
+
+<section class="informative" typeof="bibo:Chapter" resource="#intro" rel="bibo:chapter" id="introduction">
+<!--OddPage--><h2 id="intro"><span class="secno">1. </span>Introduction</h2><p><em>This section is non-normative.</em></p>
+ <p>This document describes the use
+ of HTTP for accessing, updating, creating and deleting resources from
+ servers that expose their resources as Linked Data. It provides clarifications
+ and extensions of the four rules of Linked Data [<cite><a class="bibref" href="#bib-LINKED-DATA">LINKED-DATA</a></cite>]:</p>
+ <p>1. Use URIs as names for things</p>
+ <p>2. Use HTTP URIs so that people can look up those
+ names</p>
+ <p>3. When someone looks up a URI, provide useful
+ information, using the standards (<abbr title="Resource Description Framework">RDF</abbr>*, <abbr title="SPARQL Protocol and RDF Query Language">SPARQL</abbr>)</p>
+ <p>4. Include links to other URIs, so that they can
+ discover more things</p>
+ <p>This specification discusses standard HTTP and <abbr title="Resource Description Framework">RDF</abbr> techniques and best practices that you
+ should use, and anti-patterns you should avoid, when constructing clients and servers that
+ read and write Linked Data resources.</p>
+ <p>A special type of <a title="Linked Data Platform Resource" href="#dfn-linked-data-platform-resource-1" class="internalDFN">Linked Data Platform Resource</a> is a
+ <a title="Linked Data Platform Container" href="#dfn-linked-data-platform-container-1" class="internalDFN">Container</a>. Containers are very useful
+ in building application models involving collections of homogeneous resources. For example, universities offer a collection of classes
+ and have a collection of faculty members, each faculty member teaches a collection of courses, etc.
+ This specification discusses how to work with containers. Resources can be added to containers in
+ several ways. As a special case, members can both be created and added to a container by overloading
+ the POST operation (see <a href="#ldpc-HTTP_POST" class="sectionRef">section 5.4 </a>).</p>
+ <p>Another contribution of this specification is how to deal with large amounts of data.
+ Depending on the server’s capabilities, a GET request on a Linked Data Platform Resource
+ returns a set of pages and uses a convention to access any subsequent page (see <a href="#ldpr-Paging" class="sectionRef">section 4.10 </a>). </p>
+ <p>The intention of this document is to enable additional rules and layered groupings of rules as
+ additional specifications. The scope is intentionally narrow to provide a set of key rules for
+ reading and writing Linked Data that most, if not all, other specifications will depend upon and
+ implementations will support.</p>
+</section>
+
+<section typeof="bibo:Chapter" resource="#terms" rel="bibo:chapter" id="terminology">
+<!--OddPage--><h2 id="terms"><span class="secno">2. </span>Terminology</h2>
+
+<p>Terminology is based on <abbr title="World Wide Web Consortium">W3C</abbr>'s Architecture of the World Wide Web [<cite><a class="bibref" href="#bib-WEBARCH">WEBARCH</a></cite>] and Hyper-text Transfer Protocol [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>].
+</p>
+ <dl class="glossary">
+ <dt>Link</dt>
+ <dd>A relationship between two resources when one resource (representation) refers to the other resource by means
+ of a URI [<cite><a class="bibref" href="#bib-WEBARCH">WEBARCH</a></cite>].
+ <p></p></dd>
+
+ <dt>Linked Data</dt>
+ <dd>As defined by Tim Berners-Lee [<cite><a class="bibref" href="#bib-LINKED-DATA">LINKED-DATA</a></cite>].<p></p></dd>
+
+ <dt><dfn id="dfn-linked-data-platform-resource">Linked Data Platform Resource</dfn> (<dfn id="dfn-linked-data-platform-resource-1"><abbr title="Linked Data Platform Resource">LDPR</abbr></dfn>)</dt>
+ <dd>HTTP resource whose state is represented in <abbr title="Resource Description Framework">RDF</abbr> that conforms to the simple lifecycle
+ patterns and conventions in <a href="#ldpr" class="sectionRef">section 4. </a>.<p></p></dd>
+
+ <dt><dfn id="dfn-linked-data-platform-container">Linked Data Platform Container</dfn> (<dfn id="dfn-linked-data-platform-container-1"><abbr title="Linked Data Platform Container">LDPC</abbr></dfn>)</dt>
+ <dd>An <abbr title="Linked Data Platform Resource">LDPR</abbr> representing a collection of same-subject, same-predicate triples which is uniquely identified by a URI
+ that responds to client requests for creation, modification, and enumeration of its members.
+ <p></p></dd>
+
+ <dt>Client</dt>
+ <dd>A program that establishes connections for the purpose of sending requests [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>].<p></p></dd>
+
+ <dt>Server</dt>
+ <dd>An application
+ program that accepts connections in order to service requests by
+ sending back responses.
+ <p>Any given program may be capable of being
+ both a client and a server; our use of these terms refers only to
+ the role being performed by the program for a particular
+ connection, rather than to the program's capabilities in general.
+ Likewise, any server may act as an origin server, proxy, gateway,
+ or tunnel, switching behavior based on the nature of each request
+ [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>]. </p></dd>
+
+ <dt><dfn id="dfn-membership-triples">Membership triples</dfn></dt>
+ <dd>A set of triples in an <abbr title="Linked Data Platform Container">LDPC</abbr>'s state that lists its members.
+ The membership triples of a container all have the same
+ subject and predicate, and the objects of the membership triples identify
+ the container's members.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-membership-subject">Membership subject</dfn></dt>
+ <dd>The subject of all a <abbr title="Linked Data Platform Container">LDPC</abbr>'s <a title="Membership triples" href="#dfn-membership-triples" class="internalDFN">membership triples</a>.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-membership-predicate">Membership predicate</dfn></dt>
+ <dd>The predicate of all a <abbr title="Linked Data Platform Container">LDPC</abbr>'s <a title="Membership triples" href="#dfn-membership-triples" class="internalDFN">membership triples</a>.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-page-resource">Page resource</dfn></dt>
+ <dd>A type of <abbr title="Linked Data Platform Resource">LDPR</abbr> that is associated to another <abbr title="Linked Data Platform Resource">LDPR</abbr> and whose representation
+ includes a subset of the triples in the associated <abbr title="Linked Data Platform Resource">LDPR</abbr>.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-non-member-resource">Non-member resource</dfn></dt>
+ <dd>A resource associated with a <abbr title="Linked Data Platform Container">LDPC</abbr> by a server for the purpose of enabling clients to
+ retrieve a subset of the <abbr title="Linked Data Platform Container">LDPC</abbr>'s state, namely the subset that omits the <abbr title="Linked Data Platform Container">LDPC</abbr>'s membership triples.
+ In other words, the union of the non-member resource's state and the <abbr title="Linked Data Platform Container">LDPC</abbr>'s membership triples
+ exactly equals the <abbr title="Linked Data Platform Container">LDPC</abbr>'s state.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-resource-inlining">Resource inlining</dfn></dt>
+ <dd>
+ The practice of responding to a HTTP GET request made to a request URI <var>R<sub>0</sub></var> with
+ a representation that includes the state of <var>R<sub>0</sub></var>, the <em>entire</em> state of resources accessed through
+ <em>other</em> request URI(s) <var>R<sub>1</sub></var>...<var>R<sub>n</sub></var>, <em>and assertions</em> from the server
+ identifying the additional resources whose
+ entire state has been provided.
+ <var>R<sub>1</sub></var>...<var>R<sub>n</sub></var> identify the inlined resource(s).
+ See <a href="#ldpr-inlining" class="sectionRef">section 4.11 </a> for details.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-member-inlining">Member inlining</dfn></dt>
+ <dd>A special case of <a title="Resource inlining" href="#dfn-resource-inlining" class="internalDFN">resource inlining</a>, where all members of a container on a given
+ page are inlined. The response page may or may not include all of the container's members.
+ See <a href="#ldpc-inlining" class="sectionRef">section 5.10 </a> for details.
+ <p></p></dd>
+
+ </dl>
+
+<section typeof="bibo:Chapter" resource="#conventions" rel="bibo:chapter" id="conventions-used-in-this-document">
+<h3 id="conventions"><span class="secno">2.1 </span>Conventions Used in This Document</h3>
+
+ <p>Sample resource representations are provided in <code>text/turtle</code>
+ format [<cite><a class="bibref" href="#bib-TURTLE">TURTLE</a></cite>].</p>
+ <p>Commonly used namespace prefixes:</p>
+ <pre style="word-wrap: break-word; white-space: pre-wrap;"> @prefix dcterms: <http://purl.org/dc/terms/>.
+ @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
+ @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+ @prefix ldp: <http://www.w3.org/ns/ldp#>.
+ @prefix xsd: <http://www.w3.org/2001/XMLSchema#>.</pre>
+</section>
+</section>
+
+<section id="conformance" typeof="bibo:Chapter" resource="#conformance" rel="bibo:chapter"><!--OddPage--><h2><span class="secno">3. </span>Conformance</h2>
+<p>
+ As well as sections marked as non-normative, all authoring guidelines, diagrams, examples,
+ and notes in this specification are non-normative. Everything else in this specification is
+ normative.
+</p>
+<p>
+ The key words <em class="rfc2119" title="MUST">MUST</em>, <em class="rfc2119" title="MUST NOT">MUST NOT</em>, <em class="rfc2119" title="REQUIRED">REQUIRED</em>, <em class="rfc2119" title="SHOULD">SHOULD</em>, <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em>, <em class="rfc2119" title="RECOMMENDED">RECOMMENDED</em>, <em class="rfc2119" title="MAY">MAY</em>,
+ and <em class="rfc2119" title="OPTIONAL">OPTIONAL</em> in this specification are to be interpreted as described in [<cite><a class="bibref" href="#bib-RFC2119">RFC2119</a></cite>].
+</p>
+
+
+<p>The status of the sections of Linked Data Platform 1.0 (this document) is as follows:</p>
+<ul>
+ <li>1. Introduction: <b>informative</b></li>
+ <li>2. Terminology: <b>normative</b></li>
+ <li>3. Conformance: <b>normative</b></li>
+ <li>4. Linked Data Platform Resources: <b>normative</b></li>
+ <li>5. Linked Data Platform Containers: <b>normative</b></li>
+ <li>6. HTTP Header Definitions: <b>normative</b></li>
+ <li>A. Acknowledgements: <b>informative</b></li>
+ <li>B.1 Normative references: <b>normative</b></li>
+ <li>B.2 Informative references: <b>informative</b></li>
+</ul>
+
+<p>A conforming <b>LDP server</b> is an application program that processes HTTP
+requests and generates HTTP responses that conform to the rules defined in <a href="#linked-data-platform-resources" class="sectionRef sec-ref">section 4. Linked Data Platform Resources</a>
+and <a href="#linked-data-platform-containers" class="sectionRef sec-ref">section 5. Linked Data Platform Containers</a>.</p>
+
+<p>A conforming <b>LDP client</b> is an application program that generates HTTP
+requests and processes HTTP responses that conform to the rules defined in <a href="#linked-data-platform-resources" class="sectionRef sec-ref">section 4. Linked Data Platform Resources</a>
+and <a href="#linked-data-platform-containers" class="sectionRef sec-ref">section 5. Linked Data Platform Containers</a>.</p>
+
+</section>
+
+
+<section typeof="bibo:Chapter" resource="#ldpr" rel="bibo:chapter" id="linked-data-platform-resources">
+<!--OddPage--><h2 id="ldpr"><span class="secno">4. </span>Linked Data Platform Resources</h2>
+
+<section class="informative" typeof="bibo:Chapter" resource="#ldpr-informative" rel="bibo:chapter" id="informative">
+<h3 id="ldpr-informative"><span class="secno">4.1 </span>Informative</h3><p><em>This section is non-normative.</em></p>
+ <p>Linked Data Platform Resources (<dfn id="dfn-linked-data-platform-resources"><abbr title="Linked Data Platform Resources">LDPRs</abbr></dfn>) are HTTP resources
+ that conform to the simple patterns and conventions in this section.
+ HTTP requests to access, modify, create or delete <abbr title="Linked Data Platform Resources">LDPRs</abbr> are accepted
+ and processed by <abbr title="Linked Data Platform Resource">LDPR</abbr> servers. Most <abbr title="Linked Data Platform Resources">LDPRs</abbr> are domain-specific resources
+ that contain data for an entity in some domain, which could be
+ commercial, governmental, scientific, religious, or other.</p>
+ <p>Some of the rules defined in this document provide
+ clarification and refinement of the base Linked Data rules [<cite><a class="bibref" href="#bib-LINKED-DATA">LINKED-DATA</a></cite>];
+ others address additional needs.</p>
+ <p>The rules for Linked Data Platform Resources address basic
+ questions such as:</p>
+ <ul>
+ <li>What resource representations should be used?</li>
+ <li>How is optimistic collision detection handled for updates?</li>
+ <li>What should client expectations be for changes to linked-to resources,
+ such as type changes?</li>
+ <li>What can servers do to ease the burden of constraints for resource
+ creation?</li>
+ <li>How do I GET the entries of a large resources broken up into pages?</li>
+ </ul>
+ <p>Additional informative guidance is available on the <a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide" class="external " title="Deployment Guide" rel="nofollow">working group's wiki</a> that addresses deployment
+ questions such as:</p>
+ <ul>
+ <li>What literal value types should be used?</li>
+ <li>Are there some typical vocabularies that should be reused?</li>
+ </ul>
+ <p>The following sections define the rules and
+ guidelines for use of <abbr title="Linked Data Platform Resources">LDPRs</abbr>. This document also explains how to include
+ information about each member in the resource’s own representation
+ and how to paginate the resource representation if it gets too big.</p>
+
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpr-general" rel="bibo:chapter" id="general">
+<h3 id="ldpr-general"><span class="secno">4.2 </span>General</h3>
+
+ <div id="ldpr-4_2_1" class="rule">4.2.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> at least be HTTP/1.1 conformant servers [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>].</div>
+ <div id="ldpr-4_2_2" class="rule">4.2.2 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> provide an <abbr title="Resource Description Framework">RDF</abbr> representation for <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
+ The HTTP <code>Request-URI</code> of the <abbr title="Linked Data Platform Resource">LDPR</abbr> is typically the subject of most triples in the response.
+ </div>
+ <div id="ldpr-4_2_3" class="rule">4.2.3 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MAY">MAY</em> host a mixture of <abbr title="Linked Data Platform Resources">LDPRs</abbr> and non-<abbr title="Linked Data Platform Resources">LDPRs</abbr>. For example, it
+ is common for <abbr title="Linked Data Platform Resource">LDPR</abbr> servers to need to host binary or text resources
+ that do not have useful <abbr title="Resource Description Framework">RDF</abbr> representations.
+ </div>
+
+ <div id="ldpr-4_2_4" class="rule">4.2.4 <abbr title="Linked Data Platform Resources">LDPRs</abbr> <em class="rfc2119" title="SHOULD">SHOULD</em> reuse existing vocabularies instead of creating
+ their own duplicate vocabulary terms. In addition to this general rule, some specific cases are
+ covered by other conformance rules.
+ </div>
+ <div id="ldpr-4_2_4_1" class="rule">4.2.4.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> predicates <em class="rfc2119" title="SHOULD">SHOULD</em> use standard vocabularies such as Dublin Core
+ [<cite><a class="bibref" href="#bib-DC-TERMS">DC-TERMS</a></cite>], <abbr title="Resource Description Framework">RDF</abbr> [<cite><a class="bibref" href="#bib-RDF-CONCEPTS">RDF-CONCEPTS</a></cite>] and <abbr title="Resource Description Framework">RDF</abbr> Schema [<cite><a class="bibref" href="#bib-RDF-SCHEMA">RDF-SCHEMA</a></cite>], whenever
+ possible.
+ </div>
+ <div id="ldpr-4_2_5" class="rule">4.2.5 <abbr title="Linked Data Platform Resource">LDPR</abbr> representations <em class="rfc2119" title="SHOULD">SHOULD</em> have at least one <code>rdf:type</code>
+ set explicitly. This makes the representations much more useful to
+ client applications that don’t support inferencing.
+ </div>
+ <div id="ldpr-4_2_6" class="rule">4.2.6 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MAY">MAY</em> support standard representations beyond those
+ necessary to conform to this specification. These
+ could be other <abbr title="Resource Description Framework">RDF</abbr> formats, like N3 or NTriples, but non-<abbr title="Resource Description Framework">RDF</abbr> formats
+ like HTML [<cite><a class="bibref" href="#bib-HTML401">HTML401</a></cite>] and JSON [<cite><a class="bibref" href="#bib-RFC4627">RFC4627</a></cite>] would likely be common.
+ </div>
+ <div id="ldpr-4_2_7" class="rule">4.2.7 <abbr title="Linked Data Platform Resources">LDPRs</abbr> <em class="rfc2119" title="MAY">MAY</em> be created, updated and deleted using methods not defined in
+ this document, for example through application-specific means, <abbr title="SPARQL Protocol and RDF Query Language">SPARQL</abbr>
+ UPDATE, etc. [<cite><a class="bibref" href="#bib-SPARQL-UPDATE">SPARQL-UPDATE</a></cite>], as long as those methods do not conflict with this specification's
+ normative requirements.
+ </div>
+ <div id="ldpr-4_2_8" class="rule">4.2.8 <abbr title="Linked Data Platform Resource">LDPR</abbr> server responses <em class="rfc2119" title="MUST">MUST</em> use entity tags (either weak or strong
+ones) as response <code>ETag</code> header values.
+ </div>
+ <div id="ldpr-4_2_9" class="rule">4.2.9 <abbr title="Linked Data Platform Resource">LDPR</abbr>
+ servers <em class="rfc2119" title="SHOULD">SHOULD</em> enable simple creation and modification of <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
+ It is
+ common for <abbr title="Linked Data Platform Resource">LDPR</abbr> servers to put restrictions on representations – for
+ example, the range of <code>rdf:type</code> predicates, datatypes of
+ the objects of predicates, and the number of occurrences of predicates in an <abbr title="Linked Data Platform Resource">LDPR</abbr>, but
+ servers <em class="rfc2119" title="SHOULD">SHOULD</em> minimize those restrictions. Enforcement of
+ more complex constraints will greatly restrict the set of clients
+ that can modify resources. For some server applications, excessive
+ constraints on modification of resources may be required.
+ </div>
+ <div id="ldpr-4_2_10" class="rule">4.2.10 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers
+ <em class="rfc2119" title="MUST">MUST</em> advertise their LDP support by exposing a HTTP <code>Link</code> header
+ with a target URI of <code>http://www.w3.org/ns/ldp/Resource</code>, and
+ a link relation type of <code>type</code> (that is, <code>rel="type"</code>)
+ in all responses to requests made
+ to the resource's HTTP <code>Request-URI</code>. This is notionally equivalent to the
+ presence of a <var>(subject-URI, <code>rdf:type</code>, <code>ldp:Resource</code>)</var> triple in the resource.
+ The HTTP <code>Link</code> header is the method by which servers assert their support for the LDP specification in a way
+ that clients can introspect dynamically at run-time. Conservative clients should note that
+ <a href="#ldpr-4_2_3">a server can host a mixture of <abbr title="Linked Data Platform Resources">LDPRs</abbr> and other resources</a>, and therefore there is no implication
+ that LDP support advertised on one HTTP <code>Request-URI</code> means that other
+ resources on the same server are also <abbr title="Linked Data Platform Resources">LDPRs</abbr>. Each HTTP <code>Request-URI</code> needs to be
+ individually introspected by a conservative client, in the absence of outside information.
+ </div>
+ <div id="ldpr-4_2_11" class="rule">4.2.11 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers
+ <em class="rfc2119" title="MUST NOT">MUST NOT</em> require LDP clients to implement inferencing in order to recognize the subset
+ of content defined by LDP. Other specifications built on top of LDP may require clients
+ to implement inferencing [<cite><a class="bibref" href="#bib-RDF-CONCEPTS">RDF-CONCEPTS</a></cite>]. The practical implication is that all content defined by LDP
+ must be explicitly represented.
+ </div>
+ <div id="ldpr-4_2_12" class="rule">4.2.12 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> assign the default base-URI for [<cite><a class="bibref" href="#bib-RFC3987">RFC3987</a></cite>] relative-URI resolution to be the HTTP
+ <code>Request-URI</code> when the resource already exists, and to the URI of the created resource when the request results
+ in the creation of a new resource.
+ </div>
+
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpr-HTTP_GET" rel="bibo:chapter" id="http-get">
+<h3 id="ldpr-HTTP_GET"><span class="secno">4.3 </span>HTTP GET</h3>
+ <div id="ldpr-4_3_1" class="rule">4.3.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> support the HTTP <code>GET</code> Method for <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
+ </div>
+ <div id="ldpr-4_3_2" class="rule">4.3.2 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> support the HTTP response headers defined in
+ <a href="#ldpr-HTTP_OPTIONS" class="sectionRef">section 4.9 </a>.
+ </div>
+ <div id="ldpr-4_3_3" class="rule">4.3.3 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="SHOULD">SHOULD</em> provide a <code>text/turtle</code>
+ representation of the requested <abbr title="Linked Data Platform Resource">LDPR</abbr> [<cite><a class="bibref" href="#bib-TURTLE">TURTLE</a></cite>].
+ </div>
+ <div id="ldpr-4_3_4" class="rule">4.3.4 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MAY">MAY</em> provide
+ representations of the requested <abbr title="Linked Data Platform Resource">LDPR</abbr> beyond those
+ necessary to conform to this specification, using standard HTTP content negotiation ([<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] Section 12 - Content Negotiation).
+ If the client does not indicate a preference, <code>text/turtle</code> <em class="rfc2119" title="SHOULD">SHOULD</em> be returned.
+ </div>
+ <div id="ldpr-4_3_5" class="rule">4.3.5 In the absence of special knowledge of the application or domain, <abbr title="Linked Data Platform Resource">LDPR</abbr>
+ clients <em class="rfc2119" title="MUST">MUST</em> assume that any <abbr title="Linked Data Platform Resource">LDPR</abbr> can have multiple values for <code>rdf:type</code>.
+ </div>
+ <div id="ldpr-4_3_6" class="rule">4.3.6 In the absence of special knowledge of the application or domain, <abbr title="Linked Data Platform Resource">LDPR</abbr>
+ clients <em class="rfc2119" title="MUST">MUST</em> assume that the <code>rdf:type</code> values
+ of a given <abbr title="Linked Data Platform Resource">LDPR</abbr> can change over time.
+ </div>
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpr-HTTP_POST" rel="bibo:chapter" id="http-post">
+<h3 id="ldpr-HTTP_POST"><span class="secno">4.4 </span>HTTP POST</h3>
+ <p>This specification adds no new requirements on HTTP <code>POST</code> for <abbr title="Linked Data Platform Resources">LDPRs</abbr>
+ even when the <abbr title="Linked Data Platform Resource">LDPR</abbr> supports that method. This specification does not impose any
+ new requirement to support that method, and [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] makes it optional.</p>
+ <p>Creation of <abbr title="Linked Data Platform Resources">LDPRs</abbr> can be done via <code>POST</code> (<a href="#ldpc-HTTP_POST" class="sectionRef">section 5.4 </a>) or
+ <code>PUT</code> (<a href="#ldpc-HTTP_PUT" class="sectionRef">section 5.5 </a>) to a <abbr title="Linked Data Platform Container">LDPC</abbr>, see those
+ sections for more details.</p>
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpr-HTTP_PUT" rel="bibo:chapter" id="http-put">
+<h3 id="ldpr-HTTP_PUT"><span class="secno">4.5 </span>HTTP PUT</h3>
+ <p>This specification imposes the following new requirements on HTTP <code>PUT</code> for <abbr title="Linked Data Platform Resources">LDPRs</abbr>
+ only when the <abbr title="Linked Data Platform Resource">LDPR</abbr> supports that method. This specification does not impose any
+ new requirement to support that method, and [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] makes it optional.</p>
+
+ <div id="ldpr-4_5_1" class="rule">4.5.1 If HTTP <code>PUT</code> is performed on an existing resource, <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em>
+ replace the entire persistent state of the identified resource with
+ the entity representation in the body of the request.
+ <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MAY">MAY</em> ignore server managed properties such as <code>dcterms:modified</code>
+ and <code>dcterms:creator</code> if they are not under
+ client control. Any <abbr title="Linked Data Platform Resource">LDPR</abbr> servers that wish
+ to support a more sophisticated merge of data provided by the client
+ with existing state stored on the server for a resource <em class="rfc2119" title="MUST">MUST</em> use HTTP
+ <code>PATCH</code>, not HTTP <code>PUT</code>.
+ </div>
+
+ <div id="ldpr-4_5_2" class="rule">4.5.2 <abbr title="Linked Data Platform Resource">LDPR</abbr> clients <em class="rfc2119" title="SHOULD">SHOULD</em> use the HTTP <code>If-Match</code>
+ header and HTTP <code>ETags</code> to ensure it isn’t
+ modifying a resource that has changed since the client last retrieved
+ its representation. <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="SHOULD">SHOULD</em> require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
+ to detect collisions. <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> respond with status code 412
+ (Condition Failed) if <code>ETag</code>s fail to match when there are no other
+ errors with the request [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>]. <abbr title="Linked Data Platform Resource">LDPR</abbr> servers that require conditional requests <em class="rfc2119" title="MUST">MUST</em> respond with status code 428
+ (Precondition Required) when the absence of a precondition is the only reason for rejecting the request [<cite><a class="bibref" href="#bib-RFC6585">RFC6585</a></cite>].
+ </div>
+ <div id="ldpr-4_5_3" class="rule">4.5.3 <abbr title="Linked Data Platform Resource">LDPR</abbr> clients <em class="rfc2119" title="SHOULD">SHOULD</em> always assume that the set of predicates for a
+ resource of a particular type at an arbitrary server is open, in the
+ sense that different resources of the same type may not all have the
+ same set of predicates in their triples, and the set of predicates that
+ are used in the state of any one resource is not limited to any pre-defined
+ set.
+ </div>
+ <div id="ldpr-4_5_4" class="rule">4.5.4 <abbr title="Linked Data Platform Resource">LDPR</abbr> clients <em class="rfc2119" title="SHOULD">SHOULD</em> assume that an <abbr title="Linked Data Platform Resource">LDPR</abbr> server could discard triples
+ whose predicates the server does not recognize or otherwise chooses
+ not to persist. In other words, <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MAY">MAY</em> restrict themselves
+ to a known set of predicates, but <abbr title="Linked Data Platform Resource">LDPR</abbr> clients <em class="rfc2119" title="MUST NOT">MUST NOT</em> restrict themselves to a known set of predicates
+ when their intent is to perform a later HTTP <code>PUT</code> to update the resource.
+ </div>
+ <div id="ldpr-4_5_5" class="rule">4.5.5 An <abbr title="Linked Data Platform Resource">LDPR</abbr> client <em class="rfc2119" title="MUST">MUST</em> preserve all triples retrieved using HTTP <code>GET</code> that
+ it doesn’t change whether it understands the predicates or not, when
+ its intent is to perform an update using HTTP <code>PUT</code>. The use of HTTP
+ <code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
+ [<cite><a class="bibref" href="#bib-RFC5789">RFC5789</a></cite>].
+ </div>
+ <div id="ldpr-4_5_6" class="rule">4.5.6 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MAY">MAY</em> choose to allow the creation of new resources using HTTP <code>PUT</code>.
+ </div>
+ <div id="ldpr-4_5_7" class="rule">4.5.7 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="SHOULD">SHOULD</em> allow clients to update resources without
+ requiring detailed knowledge of server-specific constraints.
+ This is a consequence of the requirement to <a href="#ldpr-4_2_9">enable simple creation and modification</a> of LPDRs.
+ </div>
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpr-HTTP_DELETE" rel="bibo:chapter" id="http-delete">
+<h3 id="ldpr-HTTP_DELETE"><span class="secno">4.6 </span>HTTP DELETE</h3>
+ <p>This specification imposes the following new requirements on HTTP <code>DELETE</code> for <abbr title="Linked Data Platform Resources">LDPRs</abbr>
+ only when the <abbr title="Linked Data Platform Resource">LDPR</abbr> supports that method. This specification does not impose any
+ new requirement to support that method, and [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] makes it optional.</p>
+ <p>Additional requirements on HTTP <code>DELETE</code> of <abbr title="Linked Data Platform Resources">LDPRs</abbr> within containers can be found in
+ <a href="#ldpc-HTTP_DELETE" class="sectionRef">section 5.6 </a>.</p>
+
+ <div id="ldpr-4_6_1" class="rule">4.6.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> remove the resource identified by the <code>Request-URI</code>.
+ After a successful HTTP <code>DELETE</code>, a subsequent HTTP <code>GET</code> on the same
+ <code>Request-URI</code> <em class="rfc2119" title="MUST">MUST</em> result in a 404 (Not found) or 410 (Gone) status
+ code. Clients <em class="rfc2119" title="SHOULD">SHOULD</em> note that servers <em class="rfc2119" title="MAY">MAY</em> reuse a URI under some circumstances.
+ </div>
+
+ <div id="ldpr-4_6_2" class="rule">4.6.2 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MAY">MAY</em> alter the state of other resources as a result of an
+ HTTP <code>DELETE</code> request. For example, it is acceptable for the server to
+ remove triples from other resources whose subject or object is the
+ deleted resource. It is also acceptable and common for <abbr title="Linked Data Platform Resource">LDPR</abbr> servers to
+ not do this – behavior is server application specific.
+ </div>
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpr-HTTP_HEAD" rel="bibo:chapter" id="http-head">
+<h3 id="ldpr-HTTP_HEAD"><span class="secno">4.7 </span>HTTP HEAD</h3>
+ <p>Note that certain LDP mechanisms, such as paging, rely on HTTP headers, and HTTP generally requires that
+ <code>HEAD</code> responses include the same headers as <code>GET</code> responses.
+ Thus, implementers should also carefully read <a href="#ldpr-HTTP_GET" class="sectionRef">section 4.3 </a>
+ and <a href="#ldpr-HTTP_OPTIONS" class="sectionRef">section 4.9 </a>.</p>
+ <div id="ldpr-4_7_1" class="rule">4.7.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> support the HTTP <code>HEAD</code> method.</div>
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpr-HTTP_PATCH" rel="bibo:chapter" id="http-patch">
+<h3 id="ldpr-HTTP_PATCH"><span class="secno">4.8 </span>HTTP PATCH</h3>
+ <p>This specification imposes the following new requirements on HTTP <code>PATCH</code> for <abbr title="Linked Data Platform Resources">LDPRs</abbr>
+ only when the <abbr title="Linked Data Platform Resource">LDPR</abbr> supports that method. This specification does not impose any
+ new requirement to support that method, and [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] makes it optional.</p>
+ <div id="ldpr-4_8_1" class="rule">4.8.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MAY">MAY</em> implement HTTP <code>PATCH</code> to allow modifications,
+ especially partial replacement, of their resources [<cite><a class="bibref" href="#bib-RFC5789">RFC5789</a></cite>]. No
+ minimal set of patch document formats is mandated by this document.
+ </div>
+ <div id="ldpr-4_8_2" class="rule">4.8.2 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="SHOULD">SHOULD</em> allow clients to update resources without
+ requiring detailed knowledge of server-specific constraints.
+ This is a consequence of the requirement to <a href="#ldpr-4_2_9">enable simple creation and modification</a> of LPDRs.
+ </div>
+ <div id="ldpr-4_8_3" class="rule">4.8.3 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> allow clients to create new resources using <code>PATCH</code>.
+ <a href="#ldpc-HTTP_POST"><code>POST</code> (to an <abbr title="Linked Data Platform Container">LDPC</abbr>)</a> and/or <a href="#ldpc-HTTP_PUT"><code>PUT</code></a> should be used as the standard way to create new <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
+ </div>
+ <div id="ldpr-4_8_4" class="rule">4.8.4 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers that support <code>PATCH</code> <em class="rfc2119" title="MUST">MUST</em>
+ include an <code>Accept-Patch</code> HTTP response header [<cite><a class="bibref" href="#bib-RFC5789">RFC5789</a></cite>] on HTTP <code>OPTIONS</code>
+ requests, listing patch document media type(s) supported by the server.
+ </div>
+
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpr-HTTP_OPTIONS" rel="bibo:chapter" id="http-options">
+<h3 id="ldpr-HTTP_OPTIONS"><span class="secno">4.9 </span>HTTP OPTIONS</h3>
+ <p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for <abbr title="Linked Data Platform Resources">LDPRs</abbr>
+ beyond those in [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>]. Other sections of this specification, for example
+ <a href="#ldpr-HTTP_PATCH">PATCH</a>,
+ <a href="#header-accept-post">Accept-Post</a>
+ and <a href="#ldpr-paging-HTTP_OPTIONS">Paging</a>,
+ add other requirements on <code>OPTIONS</code> responses.
+ </p>
+
+ <div id="ldpr-4_9_1" class="rule">4.9.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> support the HTTP <code>OPTIONS</code> method.</div>
+ <div id="ldpr-4_9_2" class="rule">4.9.2 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> indicate their support for HTTP Methods by
+ responding to a HTTP <code>OPTIONS</code> request on the <abbr title="Linked Data Platform Resource">LDPR</abbr>’s URL with the HTTP
+ Method tokens in the HTTP response header <code>Allow</code>.
+ </div>
+
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpr-Paging" rel="bibo:chapter" id="paging">
+<h3 id="ldpr-Paging"><span class="secno">4.10 </span>Paging</h3>
+
+<section class="informative" typeof="bibo:Chapter" resource="#ldpr-PagingIntro" rel="bibo:chapter" id="introduction-1">
+<h4 id="ldpr-PagingIntro"><span class="secno">4.10.1 </span>Introduction</h4><p><em>This section is non-normative.</em></p>
+ <p>It sometimes happens that a
+ resource is too large to reasonably transmit its representation in a
+ single HTTP response. This will be especially true if the resource
+ representation includes many triples both from its own representation and
+ from the representations of any <a title="Resource inlining" href="#dfn-resource-inlining" class="internalDFN">inlined resources</a>. A client could anticipate that a resource will be too large -
+ for example, a client tool that accesses defects may assume that an
+ individual defect will usually be of sufficiently constrained size
+ that it makes sense to request all of it at once, but that the
+ container of all the defects ever created will typically be too big.
+ Alternatively, a server could recognize that a resource that has been
+ requested is too big to return in a single message.</p>
+ <p>
+ To address this problem, <abbr title="Linked Data Platform Resources">LDPRs</abbr> should support a technique called Paging. Paging can be achieved with a
+ simple <abbr title="Resource Description Framework">RDF</abbr> pattern. For each resource, <code><resourceURL></code>, we define a new
+ 'first page' resource. In this example, its URL will be <code><resourceURL>?firstPage</code>,
+ but servers are free to construct the URL as they see fit.
+ The triples in the representation of the each page
+ are typically a subset of the triples in the resource
+ - same subject, predicate and object.
+ </p>
+ <p><abbr title="Linked Data Platform Resource">LDPR</abbr> servers may respond to requests for a
+ resource by redirecting the client to the first page resource –
+ using a 303 “See Other” redirect to the actual URL for the page
+ resource. Alternatively, clients may introspect the resource for a paged representation
+ and use it preferentially when available.</p>
+ <p>
+ Looking at an example resource representing Example Co.'s customer
+ relationship data, we’ll split the response across two pages.
+ To find the URL of the first page, the client makes a <code>OPTIONS</code> request
+ to the resource's URL, and in the response looks for a HTTP <code>Link</code>
+ header with <code>rel="first"</code>; the target URI in the header is the URL
+ of the first page resource.
+ The client then
+ requests the first page as <code>http://example.org/customer-relations?firstPage</code>:
+ </p>
+
+<div class="example"><div class="example-title"><span>Example 1</span></div><pre class="example"># The following is the representation of
+# http://example.org/customer-relations?firstPage
+@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix foaf: <http://xmlns.com/foaf/0.1/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix o: <http://example.org/ontology/>.
+
+<http://example.org/customer-relations>
+ a o:CustomerRelations;
+ dcterms:title "The customer information for Example Co.";
+ o:client <client#JohnZSmith>, <client#BettyASmith>, <client#JoanRSmith>.
+
+<http://example.org/customer-relations?firstPage>
+ a ldp:Page;
+ ldp:pageOf <http://example.org/customer-relations>;
+ ldp:nextPage <http://example.org/customer-relations?p=2>.
+
+<client#JohnZSmith>
+ a foaf:Person;
+ o:status o:ActiveCustomer;
+ foaf:name "John Z. Smith".
+<client#BettyASmith>
+ a foaf:Person;
+ o:status o:PreviousCustomer;
+ foaf:name "Betty A. Smith".
+ <client#BettyASmith>
+ a foaf:Person;
+ o:status o:PotentialCustomer;
+ foaf:name "Joan R. Smith".</pre></div>
+
+ <p>
+ The server determines the size of the pages using application specific methods not defined
+ within this specificiation. Note also, the actual name for the query parameter (such as ?p=2) is also
+ defined by the server and not this specification.
+ </p>
+ <p>
+ The following example is the result of retrieving the representation
+ for the next page:
+ </p>
+
+<div class="example"><div class="example-title"><span>Example 2</span></div><pre class="example"># The following is the representation of
+# http://example.org/customer-relations?p=2
+@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix foaf: <http://xmlns.com/foaf/0.1/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix o: <http://example.org/ontology/>.
+
+<http://example.org/customer-relations>
+ o:client <client#GlenWSmith>, <client#AlfredESmith>.
+
+<http://example.org/customer-relations?p=2>
+ a ldp:Page;
+ ldp:pageOf <http://example.org/customer-relations>;
+ ldp:nextPage rdf:nil.
+
+<client#GlenWSmith>
+ a foaf:Person;
+ o:status o:ActiveCustomer, o:GoldCustomer;
+ foaf:name "Glen W. Smith".
+
+<client#AlfredESmith>
+ a foaf:Person;
+ o:status o:ActiveCustomer, o:BronzeCustomer;
+ foaf:name "Alfred E. Smith".</pre></div>
+ <p>
+ In this example, there are only two customers provided in the
+ final page. To indicate this is the last page, a value of <code>rdf:nil</code> is used for the <code>ldp:nextPage</code>
+ predicate of the page resource.
+ </p>
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpr-PagingGET" rel="bibo:chapter" id="http-get-1">
+<h4 id="ldpr-PagingGET"><span class="secno">4.10.2 </span>HTTP GET</h4>
+<p>In addition to the requirements set forth in <a href="#ldpr-HTTP_GET" class="sectionRef">section 4.3 </a> on HTTP <code>GET</code>, <abbr title="Linked Data Platform Resource">LDPR</abbr> servers that support paging must also follow the requirements in this section</p>
+
+ <div id="ldpr-pagingGET-1" class="rule">4.10.2.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="SHOULD">SHOULD</em> allow clients to retrieve large <abbr title="Linked Data Platform Resources">LDPRs</abbr> in
+ pages. In responses to <code>GET</code> requests with an <abbr title="Linked Data Platform Resource">LDPR</abbr> as the <code>Request-URI</code>,
+ <abbr title="Linked Data Platform Resource">LDPR</abbr> servers that support paging <em class="rfc2119" title="SHOULD">SHOULD</em> provide an HTTP <code>Link</code>
+ header whose target URI is the first page resource, and whose link relation type is <code>first</code> [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>].
+ This is the mechanism by which clients discover the URL of the first page. If no such <code>Link</code>
+ header is present, then conservative clients will assume that the <abbr title="Linked Data Platform Resource">LDPR</abbr> does not support paging.
+ For example, if there is a <abbr title="Linked Data Platform Resource">LDPR</abbr> with URL <code><resourceURL></code> that supports paging and whose
+ first page URL is <code><resourceURL>?theFirstPage</code>, then the corresponding link header
+ would be <code>Link: <?theFirstPage>;rel="first"</code>.
+ The representation for any page, including the first, will include
+ the URL for the next page. See <a href="#ldpr-Paging" class="sectionRef">section 4.10 </a> for additional details.
+ </div>
+ <div id="ldpr-pagingGET-2" class="rule">4.10.2.2 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MAY">MAY</em> split the response representation of any <abbr title="Linked Data Platform Resource">LDPR</abbr>.
+ This is known as
+ server-initiated paging. See <a href="#ldpr-Paging" class="sectionRef">section 4.10 </a> for
+ additional details.
+ </div>
+ <div id="ldpr-pagingGET-3" class="rule">4.10.2.3 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers that initiate paging <em class="rfc2119" title="SHOULD">SHOULD</em> respond to requests for a <abbr title="Linked Data Platform Resource">LDPR</abbr>
+ by redirecting the client to the first page resource using a <code>303 See
+ Other</code> response with an HTTP <code>Location</code> header providing the first page resource URL.
+ </div>
+ <div id="ldpr-pagingGET-4" class="rule">4.10.2.4 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers that support paging <em class="rfc2119" title="MUST">MUST</em> include a representation for the page resource.
+ </div>
+ <div id="ldpr-pagingGET-4_1" class="rule">4.10.2.4.1 The page resource representation <em class="rfc2119" title="MUST">MUST</em> have one triple with the subject
+ of the page, predicate of <code>ldp:nextPage</code> and
+ object being the URL for the subsequent page.
+<div class="example"><div class="example-title"><span>Example 3</span></div><pre class="example"><http://example.org/customer-relations?firstPage>
+ ldp:nextPage <http://example.org/customer-relations?p=2> .</pre></div>
+ </div>
+ <div id="ldpr-pagingGET-4_2" class="rule">4.10.2.4.2 The last page resource representation <em class="rfc2119" title="MUST">MUST</em> have one triple with the subject of the
+ last page, predicate of <code>ldp:nextPage</code> and object being <code>rdf:nil</code>.
+<div class="example"><div class="example-title"><span>Example 4</span></div><pre class="example"><http://example.org/customer-relations?p=2>
+ ldp:nextPage rdf:nil .</pre></div>
+ </div>
+ <div id="ldpr-pagingGET-4_3" class="rule">4.10.2.4.3 The page resource representation <em class="rfc2119" title="SHOULD">SHOULD</em> have one triple to indicate its
+ type, whose subject is the URL of the page, whose predicate is <code>rdf:type</code> and object is <code>ldp:Page</code>.
+ It also <em class="rfc2119" title="SHOULD">SHOULD</em> have 1 triple to indicate the resource it is paging,
+ whose subject is the URL of the page, predicate is <code>ldp:pageOf</code>,
+ and object is the URL of the <abbr title="Linked Data Platform Resource">LDPR</abbr>.
+<div class="example"><div class="example-title"><span>Example 5</span></div><pre class="example"><http://example.org/customer-relations?firstPage>
+ rdf:type ldp:Page;
+ ldp:pageOf <http://example.org/customer-relations>.</pre></div>
+ </div>
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpr-paging-HTTP_OPTIONS" rel="bibo:chapter" id="http-options-1">
+<h4 id="ldpr-paging-HTTP_OPTIONS"><span class="secno">4.10.3 </span>HTTP OPTIONS</h4>
+
+<div id="ldpr-4_10_3_1" class="rule">4.10.3.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers <em class="rfc2119" title="MUST">MUST</em> indicate their support for client-initiated paging by
+ responding to a HTTP <code>OPTIONS</code> request on the <abbr title="Linked Data Platform Resource">LDPR</abbr>’s URL with the HTTP
+ response header for link relations using the header name of <code>Link</code> and link relation type <code>first</code> [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>].
+</div>
+</section>
+
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpr-inlining" rel="bibo:chapter" id="resource-inlining-representing-multiple-resources-in-a-response">
+<h3 id="ldpr-inlining"><span class="secno">4.11 </span>Resource Inlining: Representing Multiple Resources in a Response</h3>
+
+ <div class="atrisk"><p class="atrisktext">Feature At Risk</p>
+ <p>The LDP Working Group proposes incorporation of the features described in this section.</p>
+ <ul>
+ <li>The addition of <a href="#dfn-resource-inlining" class="internalDFN">resource inlining</a> to save application latency
+ and server/network load in controlled environments.</li>
+ </ul>
+ <p>Feedback, both positive and negative, is invited by sending email to the mailing list
+ in <a href="#sotd">Status of This Document</a>.</p>
+ </div>
+
+<section class="informative" typeof="bibo:Chapter" resource="#ldpr-InliningIntro" rel="bibo:chapter" id="introduction-2">
+<h4 id="ldpr-InliningIntro"><span class="secno">4.11.1 </span>Introduction</h4><p><em>This section is non-normative.</em></p>
+ <p>Servers whose resources are relatively granular may wish to optimistically provide more information
+ in a response than what the client actually requested, in order to reduce the average number of client
+ application HTTP flows. LDP provides some basic building blocks to enable
+ this, that implementations can re-use to build complete solutions, and they may serve as
+ complete solutions in applications with sufficient controls on resource content.
+ These building blocks are <a href="#dfn-resource-inlining" class="internalDFN">resource inlining</a> and <a href="#dfn-member-inlining" class="internalDFN">member inlining</a>.
+ </p>
+
+ <p>LDP does not provide clients with any way to detect whether or not the server is capable of
+ inlining (all its resources or any specific resource), nor does it provide clients
+ with any way to influence which (if any) resources are inlined in any given response.
+ </p>
+
+ <p>
+ Servers can return extra triples on any response, but fail to meet the definition of <a href="#dfn-resource-inlining" class="internalDFN">resource inlining</a>,
+ by either returning a subset of the other resource(s) triples or by failing to assert that
+ all triples were included (even through they were). Clients might still find the extra
+ information useful, but the only way for clients to be sure they had all available
+ information would be to make a HTTP <code>GET</code> request against all the other resource(s).
+ In some applications, knowing that these requests are unnecessary saves significant latency
+ and server/network load.
+ </p>
+</section> <!-- h3 -->
+
+<section class="informative" typeof="bibo:Chapter" resource="#ldpr-InliningWarnings" rel="bibo:chapter" id="use-with-care">
+<h4 id="ldpr-InliningWarnings"><span class="secno">4.11.2 </span>Use with Care</h4><p><em>This section is non-normative.</em></p>
+ <p>The building blocks LDP provides can only be safely used if certain assumptions hold.
+ Said another way, resource inlining solves a subset of scenarios, not all scenarios in the general case —
+ so if you care about any of the following in a given application, your server should avoid returning
+ <em>any</em> triples beyond those found at the HTTP <code>Request-URI</code>.
+ </p>
+ <ul>
+ <li><p>
+ Provenance is lost: because <abbr title="Resource Description Framework">RDF</abbr> graphs from multiple HTTP resources are merged in the
+ response without attributing each statement to its originating graph (i.e. without quotation),
+ it is impossible for a client to reliably know which
+ triples came from which HTTP resource(s). A general solution allowing quotation is
+ <abbr title="Resource Description Framework">RDF</abbr> Datasets; that is expected to be standardized independently, and can be used in these cases
+ once it is available.
+ </p></li>
+ <li><p>
+ The response may contain contradictions that are trivially obvious (or subtle), and those may or
+ may not be a problem at the application level. For a trivial example, two triples may have
+ identical subjects and predicates but different objects: "75F is too hot"; "75F is too cold".
+ Again, quotation via <abbr title="Resource Description Framework">RDF</abbr> Datasets (or any equivalent mechanism) is believed to provide a
+ long term solution once standardized.
+ </p></li>
+ </ul>
+</section> <!-- h3 -->
+
+<section typeof="bibo:Chapter" resource="#ldpr-InliningGET" rel="bibo:chapter" id="http-get-2">
+<h4 id="ldpr-InliningGET"><span class="secno">4.11.3 </span>HTTP GET</h4>
+ <p>In addition to the requirements set forth in other sections,
+ <abbr title="Linked Data Platform Resource">LDPR</abbr> servers that support <a href="#dfn-resource-inlining" class="internalDFN">resource inlining</a>
+ must also follow the requirements in this section.</p>
+
+ <div id="ldpr-4_11_3_1" class="rule">4.11.3.1 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers that support <a href="#dfn-resource-inlining" class="internalDFN">resource inlining</a> <em class="rfc2119" title="MUST">MUST</em>
+ include a <code>ldp:Page</code> resource in the representation describing the set of inlined resources,
+ whether or not the representation contains subsequent pages. The <code>ldp:Page</code> resource conceptually contains
+ metadata about the representation; it is usually not part of the HTTP resource's state, and its presence does not indicate that
+ the <abbr title="Linked Data Platform Resource">LDPR</abbr> server supports <a href="#ldpr-Paging">paging</a> in general.
+ <abbr title="Linked Data Platform Resource">LDPR</abbr> servers that include the <code>ldp:Page</code> resource for inlining and also support
+ paging <em class="rfc2119" title="MUST">MUST</em> use the same <code>ldp:Page</code> resource for the triples required by both,
+ in order to minimize client code complexity.
+ The <code>ldp:Page</code> resource's triples are the LDP-defined means by which the servers communicate to LDP clients
+ the set of HTTP resources whose state is included in a representation, allowing clients to avoid HTTP <code>GET</code>
+ requests for them.
+ </div>
+
+ <div id="ldpr-4_11_3_2" class="rule">4.11.3.2 <abbr title="Linked Data Platform Resource">LDPR</abbr> servers that support <a href="#dfn-resource-inlining" class="internalDFN">resource inlining</a> <em class="rfc2119" title="MUST">MUST</em>
+ include the <code>ldp:Page</code> resource described in <a href="#ldpr-4_11_3_1">section 4.11.3.1</a>
+ one triple for each inlined resource,
+ whose subject is the <code>ldp:Page</code> resource URI,
+ whose predicate is <code>ldp:inlinedResource</code>, and
+ whose object is the HTTP <code>Request-URI</code> of an inlined resource [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>].
+ </div>
+
+ <div id="ldpc-4_11_3_3" class="rule">4.11.3.3 <abbr title="Linked Data Platform Resource">LDPR</abbr> clients <em class="rfc2119" title="SHOULD">SHOULD</em> avoid making HTTP <code>GET</code> requests
+ against any resource whose HTTP <code>Request-URI</code> is the object of a triple of the form
+ described in <a href="#ldpc-4_11_3_2">section 4.11.3.2</a>, unless there are application-specific
+ reasons for doing so. Clients should note that by the time the representation is received, the actual state
+ of any inlined resource(s) may have changed due to subsequent requests.
+ </div>
+
+ <div id="ldpc-4_11_3_4" class="rule">4.11.3.4 <abbr title="Linked Data Platform Resource">LDPR</abbr> clients <em class="rfc2119" title="MUST NOT">MUST NOT</em> assume that <abbr title="Linked Data Platform Resource">LDPR</abbr> representations
+ lacking a <code>ldp:Page</code> resource or lacking the triple
+ described in <a href="#ldpc-4_11_3_2">section 4.11.3.2</a> contain all the triples for any resource(s)
+ listed in the representation whose HTTP <code>Request-URI</code> differs from
+ the HTTP <code>Request-URI</code> used by the client.
+ The representation might in fact contain all such triples, or some
+ subset of them, and that might or might not be completely adequate for the client's intended usage, but
+ an LDP client has no way to discern from such a representation which interpretation is accurate.
+ </div>
+
+</section>
+
+</section> <!-- h2 -->
+
+</section> <!-- h1 -->
+
+<section typeof="bibo:Chapter" resource="#ldpc" rel="bibo:chapter" id="linked-data-platform-containers">
+<!--OddPage--><h2 id="ldpc"><span class="secno">5. </span>Linked Data Platform Containers</h2>
+
+<section class="informative" typeof="bibo:Chapter" resource="#ldpc-informative" rel="bibo:chapter" id="informative-1">
+<h3 id="ldpc-informative"><span class="secno">5.1 </span>Informative</h3><p><em>This section is non-normative.</em></p>
+ <p>Many HTTP applications and sites have organizing
+ concepts that partition the overall space of resources into smaller
+ containers. Blog posts are grouped into blogs, wiki pages are grouped
+ into wikis, and products are grouped into catalogs. Each resource
+ created in the application or site is created within an instance of
+ one of these container-like entities, and users can list the existing
+ artifacts within one. Containers answer some basic questions, which
+ are:</p>
+ <ol>
+ <li>To which URLs can I POST to create new resources?</li>
+ <li>Where can I GET a list of existing resources?</li>
+ <li>How is the order of the container entries expressed?</li>
+ <li>How do I get information about the members along with the container?</li>
+ <li>How can I ensure the resource data is easy to query?</li>
+ </ol>
+ <p>
+ This document defines the representation and behavior of containers
+ that address these issues. The set of members of a container is
+ defined by a set of triples in its representation (and state) called
+ the membership triples. The membership triples of a container all
+ have the same subject and predicate – the objects of the membership
+ triples define the members of the container. The subject of the
+ membership triples is called the membership subject and the predicate
+ is called the membership predicate. In the simplest cases, the
+ membership subject will be the <abbr title="Linked Data Platform Container">LDPC</abbr> resource itself, but it does not
+ have to be. The membership predicate is also variable and will often
+ be a predicate from the server application vocabulary or the <code>rdfs:member</code> predicate.
+ </p>
+ <p>This document includes a set of guidelines for
+ using POST to create new resources and add them to the list of
+ members of a container. It goes on to explain how to learn about a set of related
+ resources, they may have been created using POST or through other means.
+ It also defines behavior when POST created resources are deleted, to clean up
+ container membership, and deleting containers removes membership information and
+ possibly perform some cleanup tasks on unreferenced member resources.</p>
+
+ <p>The following illustrates a very simple
+ container with only three members and some information about the
+ container (the fact that it is a container and a brief title):</p>
+
+<div class="example"><div class="example-title"><span>Example 6</span></div><pre class="example"># The following is the representation of
+# http://example.org/container1/
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<>
+ a ldp:Container;
+ ldp:membershipSubject <>
+ ldp:membershipPredicate rdfs:member;
+ ldp:membershipObject ldp:MemberSubject;
+ dcterms:title "A very simple container";
+ rdfs:member <member1>, <member2>, <member3>.</pre></div>
+
+ <p>This example is very straightforward - the
+ membership predicate is <code>rdfs:member</code> and the membership subject is the container
+ itself. A POST to this container will create a new resource
+ and add it to the list of members by adding a new membership triple
+ to the container.</p>
+
+ <p>Sometimes it is useful to use a subject
+ other than the container itself as the membership subject and to use
+ a predicate other than <code>rdfs:member</code> as the membership predicate. Let's
+ start with a domain resource for a person's net worth, as illustrated below:</p>
+
+<div class="example"><div class="example-title"><span>Example 7</span></div><pre class="example" id="ldpc-ex-membership-partial"># The following is a partial representation of
+# http://example.org/netWorth/nw1
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix o: <http://example.org/ontology/>.
+<>
+ a o:NetWorth;
+ o:netWorthOf <http://example.org/users/JohnZSmith>;
+ o:asset
+ <assetContainer/a1>,
+ <assetContainer/a2>;
+ o:liability
+ <liabilityContainer/l1>,
+ <liabilityContainer/l2>,
+ <liabilityContainer/l3>.</pre></div>
+ <p>From this example, there is a <code>rdf:type</code> of <code>o:NetWorth</code> indicating the
+ resource represents an instance of a person's net worth and <code>o:netWorthOf</code> predicate indicating
+ the associated person. There are two sets of same-subject, same-predicate pairings; one for assets and
+ one for liabilities. It would be helpful to be able to associate these multi-valued sets using a URL
+ for them to assist with managing these, this is done by associating containers with them as
+ illustrated below:
+ </p>
+
+<div class="example"><div class="example-title"><span>Example 8</span></div><pre class="example" id="ldpc-ex-membership-full"># The following is an elaborated representation of
+# http://example.org/netWorth/nw1/
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix o: <http://example.org/ontology/>.
+<>
+ a o:NetWorth;
+ o:netWorthOf <http://example.org/users/JohnZSmith>;
+ o:asset
+ <assetContainer/a1>,
+ <assetContainer/a2>;
+ o:liability
+ <liabilityContainer/l1>,
+ <liabilityContainer/l2>,
+ <liabilityContainer/l3>.
+
+<assetContainer/>
+ a ldp:Container;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:membershipSubject <>;
+ ldp:membershipPredicate o:asset;
+ ldp:membershipObject ldp:MemberSubject.
+
+<liabilityContainer/>
+ a ldp:Container;
+ dcterms:title "The liabilities of JohnZSmith";
+ ldp:membershipSubject <>;
+ ldp:membershipPredicate o:liability;
+ ldp:membershipObject ldp:MemberSubject.</pre></div>
+
+ <p>The essential structure of the container is
+ the same, but in this example, the membership subject is not the
+ container itself – it is a separate net worth resource. The
+ membership predicates are <code>o:asset</code> and <code>o:liability</code> – predicates
+ from the domain model. A POST of an asset representation to the asset container will create a new
+ asset and add it to the list of members by adding a new membership triple
+ to the container. You might wonder why
+ <code>http://example.org/netWorth/nw1</code> isn't made a container itself and POST
+ the new asset directly there. That would be a fine design if <code>http://example.org/netWorth/nw1</code>
+ had only assets, but if it has separate predicates for assets and liabilities,
+ that design will not work because it is unspecified to which predicate the POST
+ should add a membership triple. Having separate <code>http://example.org/netWorth/nw1/assetContainer/</code>
+ and <code>http://example.org/netWorth/nw1/liabilityContainer/</code> container
+ resources allows both assets and liabilities to be created.
+ </p>
+
+<div class="example"><div class="example-title"><span>Example 9</span></div><pre class="example" id="ldpc-ex-membership-subj"># The following is the representation of
+# http://example.org/netWorth/nw1/assetContainer/
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix o: <http://example.org/ontology/>.
+
+<>
+ a ldp:Container;
+ ldp:membershipSubject <http://example.org/netWorth/nw1>;
+ ldp:membershipPredicate o:asset;
+ ldp:membershipObject ldp:MemberSubject.
+
+<http://example.org/netWorth/nw1>
+ a o:NetWorth;
+ o:asset <a1>, <a2>.</pre></div>
+
+ <p>In this example, clients cannot simply guess
+ which resource is the membership subject and which predicate is the
+ membership predicate, so the example includes this information in
+ triples whose subject is the <abbr title="Linked Data Platform Container">LDPC</abbr> resource itself.
+ </p>
+
+ <div id="ldpc-member_data" class="rule informative">5.1.1 Container Member Information</div>
+ <p>In many – perhaps most – applications
+ involving containers, it is desirable for the client to be able to
+ get information about each container member without having to do a
+ GET on each one. <abbr title="Linked Data Platform Container">LDPC</abbr> allows servers to include this information
+ directly in the representation of the container. The server decides
+ the amount of data about each member that is provided. Some common
+ strategies include providing a fixed number of standard properties,
+ or providing the entire <abbr title="Resource Description Framework">RDF</abbr> representation of each member resource,
+ or providing nothing. The server application domain and its use-cases
+ will determine how much information is required.</p>
+
+ <p>Continuing on from the net worth
+ example, there will be additional triples for the member resources
+ (assets) in the representation:</p>
+
+<div class="example"><div class="example-title"><span>Example 10</span></div><pre class="example"># The following is the representation of
+# http://example.org/netWorth/nw1/assetContainer/
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix o: <http://example.org/ontology/>.
+
+<>
+ a ldp:Container;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:membershipSubject <http://example.org/netWorth/nw1>;
+ ldp:membershipPredicate o:asset;
+ ldp:membershipObject ldp:MemberSubject.
+
+<http://example.org/netWorth/nw1>
+ a o:NetWorth;
+ o:asset <a1>, <a3>, <a2>.
+
+<a1>
+ a o:Stock;
+ o:value 10000.
+<a2>
+ a o:Bond;
+ o:value 20000.
+<a3>
+ a o:RealEstateHolding;
+ o:value 300000.</pre></div>
+ <p>In a similar manner, when the representation for the resource of asset <var>.../<a1></var> is returned a
+ server may include the membership triple of the form <var>(.../nw1, o:asset, .../a1).</var></p>
+
+ <div id="ldpc-get_non-member_props" class="rule">5.1.2 Retrieving Only Non-member Properties
+ </div>
+ <p>The representation of a container
+ that has many members will be large. There are several important
+ cases where clients need to access only the non-member properties of
+ the container. Since retrieving the whole container representation to
+ get this information may be onerous for clients and cause unnecessary
+ overhead on servers, it is desired to define a way to retrieve only
+ the non-member property values. Defining for each <abbr title="Linked Data Platform Container">LDPC</abbr> a corresponding
+ resource, called the “<a href="#dfn-non-member-resource" class="internalDFN">non-member resource</a>”, whose state is a subset
+ of the state of the container, does this.</p>
+ <p>The example listed here only show
+ a simple case where only a few simple non-member properties are
+ retrieved. In real world situations more complex cases are likely, such as those that add other predicates to
+ containers, for example providing validation information and
+ associating <abbr title="SPARQL Protocol and RDF Query Language">SPARQL</abbr> endpoints. [<cite><a class="bibref" href="#bib-SPARQL-QUERY">SPARQL-QUERY</a></cite>]</p>
+ <p>
+ Here is an example requesting the non-member properties of a
+ container identified by the URL <code>http://example.org/container1/</code>.
+ In this case, the non-member resource is identified by the URL
+ <code>http://example.org/container1?non-member-properties</code>:
+ </p>
+<p>Request:</p>
+<div class="example"><div class="example-title"><span>Example 11</span></div><pre class="example">GET /container1?non-member-properties HTTP/1.1
+Host: example.org
+Accept: text/turtle; charset=UTF-8</pre></div>
+<p>Response:</p>
+<div class="example"><div class="example-title"><span>Example 12</span></div><pre class="example">HTTP/1.1 200 OK
+Content-Type: text/turtle; charset=UTF-8
+ETag: "_87e52ce291112"
+Content-Length: 325
+
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<http://example.org/container1/>
+ a ldp:Container;
+ dcterms:title "A Linked Data Platform Container of Acme Resources";
+ ldp:membershipSubject http://example.org/container1/;
+ ldp:membershipPredicate rdfs:member;
+ ldp:membershipObject ldp:MemberSubject;
+ dcterms:publisher <http://acme.com/>.</pre></div>
+
+ <p>While the same non-member resource could be used to update the non-member properties via PUT,
+ LDP recommends using PATCH for this purpose.</p>
+
+ <div id="ldpc-ordering" class="rule">5.1.3 Ordering</div>
+ <p>
+ There are many cases where an ordering of the members of the
+ container is important. <abbr title="Linked Data Platform Container">LDPC</abbr> does not provide any particular support
+ for server ordering of members in containers, because any client can
+ order the members in any way it chooses based on the value of any
+ available property of the members. In the example below, the value of
+ the <code>o:value</code> predicate is present for each
+ member, so the client can easily order the members according to the
+ value of that property. In this way, <abbr title="Linked Data Platform Container">LDPC</abbr> avoids the use of <abbr title="Resource Description Framework">RDF</abbr>
+ constructs like Seq and List for expressing order.
+ </p>
+ <p>
+ Order becomes more important for <abbr title="Linked Data Platform Container">LDPC</abbr> servers when containers are
+ paginated. If the server does not respect ordering when constructing
+ pages, the client would be forced to retrieve all pages before
+ sorting the members, which would defeat the purpose of pagination.
+ In cases where ordering is important, an <abbr title="Linked Data Platform Container">LDPC</abbr> server exposes all the
+ members on a page with the proper sort order with relation to all
+ members on the next and previous pages.
+ When the sort is ascending, all the members on a current page have a
+ higher sort order than all members on the previous page and
+ lower sort order than all the members on the next page.
+ When the sort is descending, the opposite order is used.
+ Since more than one value may be used to sort members,
+ the <abbr title="Linked Data Platform Container">LDPC</abbr> specification allows servers to assert the ordered list
+ of sort criteria used to sort the members, using the
+ <code>ldp:containerSortCriteria</code> relation.
+ Each member of the ordered list exposes one <code>ldp:containerSortCriterion</code>,
+ consisting of a <code>ldp:containerSortOrder</code>,
+ <code>ldp:containerSortPredicate</code>, and
+ optionally a <code>ldp:containerSortCollation</code>.
+ </p>
+ <p>Here is an example container described
+ previously, with representation for ordering of the assets:</p>
+<div class="example"><div class="example-title"><span>Example 13</span></div><pre class="example"># The following is the ordered representation of
+# http://example.org/netWorth/nw1/assetContainer/
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix o: <http://example.org/ontology/>.
+
+<>
+ a ldp:Container;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:membershipSubject <http://example.org/netWorth/nw1>;
+ ldp:membershipPredicate o:asset;
+ ldp:membershipObject ldp:MemberSubject.
+
+<?firstPage>
+ a ldp:Page;
+ ldp:pageOf <>;
+ ldp:containerSortCriteria (#SortValueAscending).
+
+<#SortValueAscending>
+ a ldp:ContainerSortCriterion;
+ ldp:containerSortOrder ldp:Ascending;
+ ldp:containerSortPredicate o:value.
+
+<http://example.org/netWorth/nw1>
+ a o:NetWorth;
+ o:asset <a1>, <a3>, <a2>.
+
+<a1>
+ a o:Stock;
+ o:value 100.00.
+<a2>
+ a o:Cash;
+ o:value 50.00.
+<a3>
+ a o:RealEstateHolding;
+ o:value 300000.</pre></div>
+ <p>
+ As you can see by the addition of the <code>ldp:ContainerSortCriteria</code>
+ predicate, the <code>o:value</code> predicate is used
+ to order the page members in ascending order. It is up to the domain model
+ and server to determine the appropriate predicate to indicate the
+ resource’s order within a page, and up to the client receiving this
+ representation to use that order in whatever way is appropriate, for
+ example to sort the data prior to presentation on a user interface.
+ </p>
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpc-general" rel="bibo:chapter" id="general-1">
+<h3 id="ldpc-general"><span class="secno">5.2 </span>General</h3>
+ <p>The Linked Data Platform does not define how clients
+ discover <dfn id="dfn-linked-data-platform-containers"><abbr title="Linked Data Platform Containers">LDPCs</abbr></dfn>.</p>
+
+ <div id="ldpc-5_2_1" class="rule">5.2.1 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MUST">MUST</em> also be conformant <abbr title="Linked Data Platform Resource">LDPR</abbr> servers. A Linked Data Platform
+ Container <em class="rfc2119" title="MUST">MUST</em> also be a conformant Linked Data Platform Resource.
+ </div>
+ <div id="ldpc-5_2_2" class="rule">5.2.2 <abbr title="Linked Data Platform Container">LDPC</abbr> membership is not exclusive; this means that the same resource
+ (<abbr title="Linked Data Platform Resource">LDPR</abbr> or not) which is identified by its canonical URI, <em class="rfc2119" title="MAY">MAY</em> be a member of
+ more than one <abbr title="Linked Data Platform Container">LDPC</abbr>.
+ </div>
+ <div id="ldpc-5_2_3" class="rule">5.2.3 The state of an <abbr title="Linked Data Platform Container">LDPC</abbr> includes information about which
+ resources are its members. In the simplest cases, the membership subject
+ will be the <abbr title="Linked Data Platform Container">LDPC</abbr> resource itself, but it does not have to be. The
+ membership predicate is also variable and will often be a predicate
+ from the server application vocabulary. If there is no obvious
+ predicate from the server application vocabulary to use, <abbr title="Linked Data Platform Container">LDPC</abbr> servers
+ <em class="rfc2119" title="SHOULD">SHOULD</em> use the <code>rdfs:member</code> predicate. Member resources can be
+ any kind of resource identified by its URI, <abbr title="Linked Data Platform Resource">LDPR</abbr> or otherwise.
+ </div>
+ <div id="ldpc-5_2_4" class="rule">5.2.4 An <abbr title="Linked Data Platform Container">LDPC</abbr> representation <em class="rfc2119" title="MUST">MUST</em> contain exactly one triple
+ whose subject is the <abbr title="Linked Data Platform Container">LDPC</abbr> URI,
+ whose predicate is the <code>ldp:membershipSubject</code>,
+ and whose object is the <abbr title="Linked Data Platform Container">LDPC</abbr>'s membership subject URI.
+ </div>
+ <div id="ldpc-5_2_5" class="rule">5.2.5 An <abbr title="Linked Data Platform Container">LDPC</abbr> representation <em class="rfc2119" title="MUST">MUST</em> contain exactly one triple
+ whose subject is the <abbr title="Linked Data Platform Container">LDPC</abbr> URI,
+ and whose predicate is either <code>ldp:membershipPredicate</code> or <code>ldp:membershipPredicateInverse</code>.
+ The object of the triple is constrained by other sections, such as
+ <a href="#ldpc-5_2_5_1">5.2.5.1</a> or <a href="#ldpc-5_2_5_2">5.2.5.2</a>.
+ </div>
+ <div id="ldpc-5_2_5_1" class="rule">5.2.5.1 For a given triple <var>T</var> with a subject <var>C</var>
+ of the <abbr title="Linked Data Platform Container">LDPC</abbr> and predicate of
+ <code>ldp:membershipPredicate</code>, the object <em class="rfc2119" title="MUST">MUST</em> be the URI of the membership predicate <var>P</var> used to
+ indicate membership to the linked to <abbr title="Linked Data Platform Container">LDPC</abbr>, or simply: <var>T = ( C</var>, <code>ldp:membershipPredicate</code>, <var>P)</var>.
+ For the membership predicate URI object used in the triple <var>T</var>, it would be found in a resource's
+ same subject <var>R</var> and same predicate <var>P</var> membership triples of the form:
+ (<var>R</var>, <var>P</var>, <var>MR</var>), where <var>MR</var> represents URI of
+ a member resource.
+ </div>
+ <div id="ldpc-5_2_5_2" class="rule">5.2.5.2 For a given triple <var>T</var> with a subject <var>C</var>
+ of the <abbr title="Linked Data Platform Container">LDPC</abbr> and predicate of
+ <code>ldp:membershipPredicateInverse</code>, the object <em class="rfc2119" title="MUST">MUST</em> be the URI of the membership predicate <var>P</var> used to
+ indicate membership to the linked to <abbr title="Linked Data Platform Container">LDPC</abbr>, or simply: <var>T = ( C</var>, <code>ldp:membershipPredicateInverse</code>, <var>P)</var>.
+ For the membership predicate URI object used in the triple <var>T</var>, it would be found in a resource's
+ object subject <var>R</var> and same predicate <var>P</var> membership triples of the form:
+ (<var>MR</var>, <var>P</var>, <var>R</var>), where <var>MR</var> represents URI of
+ a member resource.
+ </div>
+ <div id="ldpc-5_2_6" class="rule">5.2.6 The representation of a <abbr title="Linked Data Platform Container">LDPC</abbr> <em class="rfc2119" title="MAY">MAY</em> include an arbitrary number of
+ additional triples whose subjects are the members of the container,
+ or that are from the representations of the members (if they have <abbr title="Resource Description Framework">RDF</abbr>
+ representations). This allows a <abbr title="Linked Data Platform Container">LDPC</abbr> server to provide clients with
+ information about the members without the client having to do a <code>GET</code>
+ on each member individually. See sections <a href="#ldpc-member_data">5.1.1 Container
+ Member Information</a>, <a href="#ldpr-inlining" class="sectionRef">section 4.11 </a>, and
+ <a href="#ldpc-inlining" class="sectionRef">section 5.10 </a> for additional details.
+ </div>
+ <div id="ldpc-5_2_7" class="rule">5.2.7 The representation of a <abbr title="Linked Data Platform Container">LDPC</abbr> <em class="rfc2119" title="MUST">MUST</em> have <code>rdf:type</code>
+ of <code>ldp:Container</code>, but it <em class="rfc2119" title="MAY">MAY</em> have additional
+ <code>rdf:type</code>s.
+ </div>
+ <div id="ldpc-5_2_8" class="rule">5.2.8 <abbr title="Linked Data Platform Container">LDPC</abbr> representations <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> use <abbr title="Resource Description Framework">RDF</abbr> container types <code>rdf:Bag</code>,
+ <code>rdf:Seq</code> or <code>rdf:List</code>.
+ </div>
+ <div id="ldpc-5_2_9" class="rule">5.2.9 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> re-use URIs,
+ regardless of the mechanism by which members are created (<code>POST</code>, <code>PUT</code>, etc.).
+ Certain specific cases exist where a <abbr title="Linked Data Platform Container">LDPC</abbr> server <em class="rfc2119" title="MAY">MAY</em> delete a resource and then later re-use the
+ URI when it identifies the same resource, but only when consistent with Web architecture [<cite><a class="bibref" href="#bib-WEBARCH">WEBARCH</a></cite>].
+ While it is difficult to provide absolute implementation guarantees of non-reuse in all failure
+ scenarios, re-using URIs creates ambiguities for clients that are best avoided.
+ </div>
+ <div id="ldpc-5_2_10" class="rule">5.2.10 Some <abbr title="Linked Data Platform Container">LDPC</abbr>'s have membership object's that are not directly
+ URIs minted upon <abbr title="Linked Data Platform Container">LDPC</abbr> member creation, for example URIs with non-empty fragment identifier [<cite><a class="bibref" href="#bib-RFC3986">RFC3986</a></cite>].
+ To determine which object URI to use for the membership triple, <abbr title="Linked Data Platform Container">LDPC</abbr>'s <em class="rfc2119" title="MUST">MUST</em> contain one triple whose
+ subject is the <abbr title="Linked Data Platform Container">LDPC</abbr> URI, predicate is <code>ldp:membershipObject</code>, with an object <var>MO</var>.
+ Where <var>MO</var> and the HTTP URI <var>R</var> from <code>POST</code> create (as found in HTTP response <code>Location</code> header) can be
+ used to locate a triple of the form: <var>(R, MO, N)</var> and
+ where <var>N</var> can be used to construct the membership triple of the form: <var>(membership subject, membership predicate, N)</var>.
+ When <code>ldp:membershipPredicateInverse</code> is used instead of <code>ldp:membershipPredicate</code>, the membership triple <em class="rfc2119" title="MUST">MUST</em> be
+ of the form: <var>(N, membership predicate, membership subject)</var>. To indicate that the member resource URI is the membership object
+ (the default or typical case), the object <em class="rfc2119" title="MUST">MUST</em> be set to predefined URI <code>ldp:MemberSubject</code> such that it forms the triple:
+ <var>(<abbr title="Linked Data Platform Container">LDPC</abbr> URI, <code>ldp:membershipObject</code>, <code>ldp:MemberSubject</code>)</var>.
+ </div>
+
+ <!-- NOTE: Saving this sample to help with future editing/understanding or possible insertion directly.
+
+ Let's say this LDPC has a membershipSubject of </people/roger> and membershipPredicate of pets:has_pet. If I POST the following to the LDPC:
+
+ <> foaf:primaryTopic <#this> .
+ <#this>
+ a animal:Cat;
+ foaf:name "Zaza".
+
+ ... a new resource is created and there is a new membership triple of
+
+ </people/roger> pets:has_pet </people/roger/zaza>.
+
+ but the desired one is:
+
+ </people/roger> pets:has_pet </people/roger/zaza#this>.
+
+ To do this, you'd have to use ldp:membershipObject such as:
+
+ pets:has_pet
+ a ldp:Container;
+ ldp:membershipPredicate pets:has_pet;
+ ldp:membershipSubject </people/roger>;
+ ldp:membershipObject foaf:primaryTopic .
+ -->
+
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpc-HTTP_GET" rel="bibo:chapter" id="http-get-3">
+<h3 id="ldpc-HTTP_GET"><span class="secno">5.3 </span>HTTP GET</h3>
+
+ <div id="ldpc-5_3_1" class="rule">5.3.1 The representation of a <abbr title="Linked Data Platform Container">LDPC</abbr> <em class="rfc2119" title="MUST">MUST</em> contain a set of triples with a
+ consistent subject and predicate whose objects indicate members of
+ the container. The subject of the triples <em class="rfc2119" title="MAY">MAY</em> be the container itself
+ or <em class="rfc2119" title="MAY">MAY</em> be another resource (as in the <a href="#ldpc-ex-membership-subj">example</a>). See also
+ <a href="#ldpc-5_2_3">5.2.3</a>.
+ </div>
+ <div id="ldpc-5_3_2" class="rule">5.3.2 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MAY">MAY</em> represent the members of a paged <abbr title="Linked Data Platform Container">LDPC</abbr> in a sequential
+ order. If the server does so, it <em class="rfc2119" title="MUST">MUST</em> be specify the order using a triple
+ whose subject is the page URI,
+ whose predicate is <code>ldp:containerSortCriteria</code>,
+ and whose object is a <code>rdf:List</code> of
+ <code>ldp:containerSortCriterion</code> resources.
+ The resulting order <em class="rfc2119" title="MUST">MUST</em> be as defined by <abbr title="SPARQL Protocol and RDF Query Language">SPARQL</abbr> <code>SELECT</code>’s <code>ORDER BY</code> clause
+ [<cite><a class="bibref" href="#bib-SPARQL-QUERY">SPARQL-QUERY</a></cite>].
+ Sorting criteria <em class="rfc2119" title="MUST">MUST</em> be the same for all pages of a representation; if
+ the criteria were allowed to vary, the ordering among members of a container
+ across pages would be undefined.
+ The first list entry provides the primary
+ sorting criterion, any second entry provides a secondary criterion used to order members considered
+ equal according to the primary criterion, and so on.
+ See section <a href="#ldpc-ordering">5.1.4 Ordering</a> for
+ an example.
+ </div>
+ <div id="ldpc-5_3_3" class="rule">5.3.3 <abbr title="Linked Data Platform Container">LDPC</abbr> page representations
+ ordered using <code>ldp:containerSortCriteria</code> <em class="rfc2119" title="MUST">MUST</em> contain,
+ in every <code>ldp:containerSortCriterion</code> list entry,
+ a triple
+ whose subject is the sort criterion identifier,
+ whose predicate is <code>ldp:containerSortPredicate</code>
+ and whose object is
+ the predicate whose value is used to order members between pages (the <dfn id="dfn-page-ordering-values">page-ordering values</dfn>).
+ The only predicate data types whose behavior LDP constrains are those defined
+ by <abbr title="SPARQL Protocol and RDF Query Language">SPARQL</abbr> <code>SELECT</code>’s <code>ORDER BY</code> clause [<cite><a class="bibref" href="#bib-SPARQL-QUERY">SPARQL-QUERY</a></cite>]. Other data types
+ can be used, but LDP
+ assigns no meaning to them and interoperability will be limited.
+ </div>
+ <div id="ldpc-5_3_4" class="rule">5.3.4 <abbr title="Linked Data Platform Container">LDPC</abbr> page representations
+ ordered using <code>ldp:containerSortCriteria</code> <em class="rfc2119" title="MUST">MUST</em> contain,
+ in every <code>ldp:containerSortCriterion</code> list entry,
+ a triple
+ whose subject is the sort criterion identifier,
+ whose predicate is <code>ldp:containerSortOrder</code>
+ and whose object describes the order used. LDP defines two values,
+ <code>ldp:Ascending</code> and <code>ldp:Descending</code>, for use
+ as the object of this triple. Other values can be used, but LDP
+ assigns no meaning to them and interoperability will be limited.
+ </div>
+ <div id="ldpc-5_3_5" class="rule">5.3.5 <abbr title="Linked Data Platform Container">LDPC</abbr> page representations
+ ordered using <code>ldp:containerSortCriteria</code> <em class="rfc2119" title="MAY">MAY</em> contain,
+ in any <code>ldp:containerSortCriterion</code> list entry,
+ a triple
+ whose subject is the sort criterion identifier,
+ whose predicate is <code>ldp:containerSortCollation</code>
+ and whose object identifies the collation used. LDP defines no values for use
+ as the object of this triple. While it is better for interoperability to use
+ open standardized values, any value can be used.
+ When the <code>ldp:containerSortCollation</code> triple is absent and the
+ <a title="page-ordering values" href="#dfn-page-ordering-values" class="internalDFN">page-ordering values</a> are strings or simple literals [<cite><a class="bibref" href="#bib-SPARQL-QUERY">SPARQL-QUERY</a></cite>], the
+ resulting order is as defined by <abbr title="SPARQL Protocol and RDF Query Language">SPARQL</abbr> SELECT’s ORDER BY clause
+ [<cite><a class="bibref" href="#bib-SPARQL-QUERY">SPARQL-QUERY</a></cite>] using two-argument <code>fn:compare</code>, that is,
+ it behaves as if <code>http://www.w3.org/2005/xpath-functions/collation/codepoint</code>
+ was the specified collation.
+ When the <code>ldp:containerSortCollation</code> triple is present and the
+ <a title="page-ordering values" href="#dfn-page-ordering-values" class="internalDFN">page-ordering values</a> are strings or simple literals
+ [<cite><a class="bibref" href="#bib-SPARQL-QUERY">SPARQL-QUERY</a></cite>], the
+ resulting order is as defined by <abbr title="SPARQL Protocol and RDF Query Language">SPARQL</abbr> SELECT’s ORDER BY clause
+ [<cite><a class="bibref" href="#bib-SPARQL-QUERY">SPARQL-QUERY</a></cite>] using three-argument <code>fn:compare</code>, that is, the
+ specified collation.
+ The <code>ldp:containerSortCollation</code> triple <em class="rfc2119" title="SHOULD">SHOULD</em> be omitted for comparisons
+ involving <a title="page-ordering values" href="#dfn-page-ordering-values" class="internalDFN">page-ordering values</a> for which [<cite><a class="bibref" href="#bib-SPARQL-QUERY">SPARQL-QUERY</a></cite>] does not use collations.
+ </div>
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpc-HTTP_POST" rel="bibo:chapter" id="http-post-1">
+<h3 id="ldpc-HTTP_POST"><span class="secno">5.4 </span>HTTP POST</h3>
+ <p>This specification imposes the following new requirements on HTTP <code>POST</code> for <abbr title="Linked Data Platform Containers">LDPCs</abbr>
+ only when an <abbr title="Linked Data Platform Container">LDPC</abbr> supports that method. This specification does not impose any
+ new requirement to support that method, and [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] makes it optional.</p>
+
+ <div id="ldpc-5_4_1" class="rule">5.4.1 <abbr title="Linked Data Platform Container">LDPC</abbr> clients <em class="rfc2119" title="SHOULD">SHOULD</em> create member resources by submitting a representation as
+ the entity body of the HTTP <code>POST</code> to a known <abbr title="Linked Data Platform Container">LDPC</abbr>. If the resource was created successfully, <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MUST">MUST</em>
+ respond with status code 201 (Created) and the <code>Location</code>
+ header set to the new resource’s URL. Clients shall not expect any representation in the response
+ entity body on a 201 (Created) response.
+ </div>
+
+ <div id="ldpc-5_4_2" class="rule">5.4.2 After a successful HTTP <code>POST</code> request to a <abbr title="Linked Data Platform Container">LDPC</abbr>, the new resource <em class="rfc2119" title="MUST">MUST</em>
+ appear as a member of the <abbr title="Linked Data Platform Container">LDPC</abbr> until the new resource is deleted or
+ removed by other methods. An <abbr title="Linked Data Platform Container">LDPC</abbr> <em class="rfc2119" title="MAY">MAY</em> also contain resources that were
+ added through other means - for example through the user interface of
+ the site that implements the <abbr title="Linked Data Platform Container">LDPC</abbr>.
+ </div>
+
+ <div id="ldpc-5_4_3" class="rule">5.4.3 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MAY">MAY</em> accept an HTTP <code>POST</code> of non-<abbr title="Resource Description Framework">RDF</abbr> representations for
+ creation of any kind of resource, for example binary resources. See <a href="#ldpc-5_4_13">5.4.13</a> for introspection
+ details.
+ </div>
+ <div id="ldpc-5_4_4" class="rule">5.4.4 For servers that support create, <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MUST">MUST</em> create an <abbr title="Linked Data Platform Resource">LDPR</abbr> from a
+ <abbr title="Resource Description Framework">RDF</abbr> representation in the request entity body. The newly created <abbr title="Linked Data Platform Resource">LDPR</abbr> could also be a <abbr title="Linked Data Platform Container">LDPC</abbr>, therefore servers <em class="rfc2119" title="MAY">MAY</em>
+ allow the creation of <abbr title="Linked Data Platform Containers">LDPCs</abbr> within a <abbr title="Linked Data Platform Container">LDPC</abbr>.
+ </div>
+
+ <div id="ldpc-5_4_5" class="rule">5.4.5 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MUST">MUST</em> accept a request entity body with a request header
+ of <code>Content-Type</code> with value of <code>text/turtle</code> [<cite><a class="bibref" href="#bib-TURTLE">TURTLE</a></cite>].
+ </div>
+ <div id="ldpc-5_4_6" class="rule">5.4.6 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="SHOULD">SHOULD</em> use the <code>Content-Type</code> request header
+ to determine the representation format when the request has an entity body. When the header is absent,
+ <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MAY">MAY</em> infer the content type by inspecting the entity body contents [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>].
+ </div>
+ <div id="ldpc-5_4_7" class="rule">5.4.7 In <abbr title="Resource Description Framework">RDF</abbr> representations, <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MUST">MUST</em> interpret the null relative
+ URI for the subject of triples in the <abbr title="Linked Data Platform Resource">LDPR</abbr> representation in the
+ request entity body as referring to the entity in the request body.
+ Commonly, that entity is the model for the “to be created” <abbr title="Linked Data Platform Resource">LDPR</abbr>, so
+ triples whose subject is the null relative URI will usually result in
+ triples in the created resource whose subject is the created
+ resource.
+ </div>
+ <div id="ldpc-5_4_8" class="rule">5.4.8 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="SHOULD">SHOULD</em> assign the subject URI for the resource to be
+ created using server application specific rules in the absence of a <a href="#ldpc-5_4_10">client hint</a>.
+ </div>
+ <div id="ldpc-5_4_9" class="rule">5.4.9 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="SHOULD">SHOULD</em> allow clients to create new resources without
+ requiring detailed knowledge of application-specific constraints.
+ This is a consequence of the requirement to
+ <a href="#ldpr-4_2_9">enable simple creation and modification</a> of LPDRs.
+ </div>
+ <div id="ldpc-5_4_10" class="rule">5.4.10 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MAY">MAY</em> allow clients to suggest the URI for a resource
+ created through <code>POST</code>, using the HTTP <code>Slug</code> header as defined in [<cite><a class="bibref" href="#bib-RFC5023">RFC5023</a></cite>]. LDP adds
+ no new requirements to this usage, so its presence functions as a client hint to the server
+ providing a desired string to be incorporated into the server's final choice of resource URI.
+ </div>
+
+ <div id="ldpc-5_4_11" class="rule">5.4.11 <abbr title="Linked Data Platform Container">LDPC</abbr> servers that allow member creation via <code>POST</code>
+ <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> re-use URIs, per the<a href="#ldpc-5_2_9">
+ general requirements on <abbr title="Linked Data Platform Containers">LDPCs</abbr></a>.
+ </div>
+
+ <div id="ldpc-5_4_12" class="rule">5.4.12 Upon successful creation of a non-<abbr title="Resource Description Framework">RDF</abbr> and therefore non-<abbr title="Linked Data Platform Resource">LDPR</abbr> member (HTTP status code of
+ 201-Created and URI indicated by <code>Location</code> response header), <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MAY">MAY</em> create an associated <abbr title="Linked Data Platform Resource">LDPR</abbr>
+ to contain data about the created resource. If an <abbr title="Linked Data Platform Container">LDPC</abbr> server creates this associated <abbr title="Linked Data Platform Resource">LDPR</abbr> it <em class="rfc2119" title="MUST">MUST</em> indicate
+ its location on the HTTP response using the HTTP response header <code>Link</code> and relationship type <code>meta</code>
+ and <code>href</code> to be the URI of the meta-resource [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>].
+ </div>
+ <div id="ldpc-5_4_13" class="rule">5.4.13 <abbr title="Linked Data Platform Container">LDPC</abbr> servers that support <code>POST</code> <em class="rfc2119" title="MUST">MUST</em>
+ include an <a href="#header-accept-post"><code>Accept-Post</code> response header</a> on HTTP <code>OPTIONS</code>
+ responses, listing post document media type(s) supported by the server.
+ LDP only specifies the use of <code>POST</code> for the purpose of creating new resources, but a server
+ can accept <code>POST</code> requests with other semantics.
+ While "POST to create" is a common interaction pattern, LDP clients are not guaranteed, even when
+ making requests to an LDP server, that every successful <code>POST</code> request will result in the
+ creation of a new resource; they must rely on out of band information for knowledge of which <code>POST</code> requests,
+ if any, will have the "create new resource" semantics.
+ This requirement on LDP servers is intentionally stronger than the one levied in the
+ <a href="#header-accept-post">header registration</a>; it is unrealistic to expect all existing resources
+ that support <code>POST</code> to suddenly return a new header or for all new specifications constraining
+ <code>POST</code> to be aware of its existence and require it, but it is a reasonable requirement for new
+ specifications such as LDP.
+ </div>
+
+ <div id="ldpc-5_4_14" class="rule">5.4.14 <abbr title="Linked Data Platform Containers">LDPCs</abbr> that create new member resources <em class="rfc2119" title="MAY">MAY</em> add triples to the container
+ as part of member creation to reflect its factory role.
+ LDP defines the <code>ldp:created</code> predicate for this purpose.
+ An <abbr title="Linked Data Platform Container">LDPC</abbr> that tracks members created through the <abbr title="Linked Data Platform Container">LDPC</abbr> <em class="rfc2119" title="MUST">MUST</em> add a triple
+ whose subject is the container's URI,
+ whose predicate is <code>ldp:created</code>, and
+ whose object is the newly created member resource's URI;
+ it <em class="rfc2119" title="MAY">MAY</em> add other triples as well.
+ </div>
+
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpc-HTTP_PUT" rel="bibo:chapter" id="http-put-1">
+<h3 id="ldpc-HTTP_PUT"><span class="secno">5.5 </span>HTTP PUT</h3>
+ <p>This specification imposes the following new requirements on HTTP <code>PUT</code> for <abbr title="Linked Data Platform Containers">LDPCs</abbr>
+ only when an <abbr title="Linked Data Platform Container">LDPC</abbr> supports that method. This specification does not impose any
+ new requirement to support that method, and [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] makes it optional.</p>
+
+ <div id="ldpc-5_5_1" class="rule">5.5.1 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> allow HTTP <code>PUT</code> to update a <abbr title="Linked Data Platform Container">LDPC</abbr>’s <a href="#dfn-membership-triples" class="internalDFN">membership triples</a>;
+ if the server receives such a request, it <em class="rfc2119" title="SHOULD">SHOULD</em> respond with a 409
+ (Conflict) status code.
+ </div>
+ <div id="ldpc-5_5_2" class="rule">5.5.2 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="MAY">MAY</em> allow updating <abbr title="Linked Data Platform Container">LDPC</abbr> non-membership properties using
+ HTTP <code>PUT</code> on a corresponding <a href="#dfn-non-member-resource" class="internalDFN">non-member resource</a>, which
+ <em class="rfc2119" title="MAY">MAY</em> exclude server-managed properties such as <code>ldp:membershipSubject</code>, <code>ldp:membershipPredicate</code>
+ and <code>ldp:membershipPredicateInverse</code>.
+ The <a href="#ldpc-HTTP_OPTIONS" class="sectionRef">section 5.9 </a> describes the process by which clients
+ use HTTP <code>OPTIONS</code> to discover whether the server offers such a resource, and if so its URL.
+ </div>
+
+ <div id="ldpc-5_5_3" class="rule">5.5.3 <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> allow HTTP <code>PUT</code> requests
+ with <a title="Member inlining" href="#dfn-member-inlining" class="internalDFN">inlined member</a> information in the request representation.
+ See section <a href="#ldpc-member_data">5.1.1 Container
+ Member Information</a> for additional details.
+ </div>
+
+ <div id="ldpc-5_5_4" class="rule">5.5.4 <abbr title="Linked Data Platform Container">LDPC</abbr> servers that allow member creation via <code>PUT</code>
+ <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> re-use URIs, per the <a href="#ldpc-5_2_9">
+ general requirements on <abbr title="Linked Data Platform Containers">LDPCs</abbr></a>.
+ </div>
+
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpc-HTTP_DELETE" rel="bibo:chapter" id="http-delete-1">
+<h3 id="ldpc-HTTP_DELETE"><span class="secno">5.6 </span>HTTP DELETE</h3>
+ <p>This specification imposes the following new requirements on HTTP <code>DELETE</code> for <abbr title="Linked Data Platform Resources">LDPRs</abbr> and <abbr title="Linked Data Platform Containers">LDPCs</abbr>
+ only when a <abbr title="Linked Data Platform Container">LDPC</abbr> supports that method. This specification does not impose any
+ new requirement to support that method, and [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] makes it optional.</p>
+
+ <div id="ldpc-5_6_1" class="rule">5.6.1 When a <abbr title="Linked Data Platform Container">LDPC</abbr> member resource originally created by the <abbr title="Linked Data Platform Container">LDPC</abbr> (for example, one whose representation
+ was HTTP <code>POST</code>'d to the <abbr title="Linked Data Platform Container">LDPC</abbr> and then referenced by a membership triple) is deleted, and the <abbr title="Linked Data Platform Container">LDPC</abbr> server is aware of the member's deletion
+ (for example, the member is managed by the same server), the <abbr title="Linked Data Platform Container">LDPC</abbr> server <em class="rfc2119" title="MUST">MUST</em> also remove it from
+ the <abbr title="Linked Data Platform Container">LDPC</abbr> by removing the corresponding membership triple.
+ </div>
+ <div id="ldpc-5_6_2" class="rule">5.6.2 When the <abbr title="Linked Data Platform Container">LDPC</abbr> server successfully completes the <code>DELETE</code> request on a <abbr title="Linked Data Platform Container">LDPC</abbr>, it <em class="rfc2119" title="MUST">MUST</em> remove any
+ membership triples associated with the <abbr title="Linked Data Platform Container">LDPC</abbr> as indicated by the canonical <code>Request-URI</code>. The <abbr title="Linked Data Platform Container">LDPC</abbr> server <em class="rfc2119" title="MAY">MAY</em> perform additional removal
+ of member resources.
+ For example, the server could perform additional cleanup tasks for resources it knows are no longer referenced or have not
+ been accessed for some period of time.
+ </div>
+ <div 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 <abbr title="Linked Data Platform Container">LDPC</abbr> tracks member
+ resources that it created using the <code>ldp:created</code> predicate, the <abbr title="Linked Data Platform Container">LDPC</abbr> server <em class="rfc2119" title="MUST">MUST</em> also remove
+ the deleted member's <code>ldp:created</code> triple.
+ </div>
+
+ <div id="ldpc-5_6_4" class="rule">5.6.4 When a <abbr title="Linked Data Platform Container">LDPC</abbr> member resource originally created by the <abbr title="Linked Data Platform Container">LDPC</abbr> (for example, one whose
+ representation was HTTP <code>POST</code>'d to the <abbr title="Linked Data Platform Container">LDPC</abbr> and then referenced by a membership triple) is deleted, and the <abbr title="Linked Data Platform Container">LDPC</abbr> server
+ created an associated <abbr title="Linked Data Platform Resource">LDPR</abbr> (see <a href="#ldpc-5_4_12">5.4.12</a>), the <abbr title="Linked Data Platform Container">LDPC</abbr> server must also remove the associated <abbr title="Linked Data Platform Resource">LDPR</abbr> it created.
+ </div>
+
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpc-HTTP_HEAD" rel="bibo:chapter" id="http-head-1">
+<h3 id="ldpc-HTTP_HEAD"><span class="secno">5.7 </span>HTTP HEAD</h3>
+ <p>Note that certain LDP mechanisms, such as paging, rely on HTTP headers, and HTTP generally requires that
+ <code>HEAD</code> responses include the same headers as <code>GET</code> responses. Also <abbr title="Linked Data Platform Container">LDPC</abbr> servers must also include HTTP headers
+ on response to <code>OPTIONS</code>, see <a href="#ldpr-4_7_2">4.7.2</a>.
+ Thus, implementers supporting <code>HEAD</code> should also carefully read the
+ <a href="#ldpc-HTTP_GET" class="sectionRef">section 5.3 </a> and <a href="#ldpc-HTTP_OPTIONS" class="sectionRef">section 5.9 </a>.</p>
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpc-HTTP_PATCH" rel="bibo:chapter" id="http-patch-1">
+<h3 id="ldpc-HTTP_PATCH"><span class="secno">5.8 </span>HTTP PATCH</h3>
+ <p>This specification imposes the following new requirements on HTTP <code>PATCH</code> for <abbr title="Linked Data Platform Containers">LDPCs</abbr>
+ only when a <abbr title="Linked Data Platform Container">LDPC</abbr> supports that method. This specification does not impose any
+ new requirement to support that method, and [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] makes it optional.</p>
+
+ <div id="ldpc-5_8_1" class="rule">5.8.1 <abbr title="Linked Data Platform Container">LDPC</abbr> servers are <em class="rfc2119" title="RECOMMENDED">RECOMMENDED</em> to support HTTP <code>PATCH</code> as the preferred
+ method for updating <abbr title="Linked Data Platform Container">LDPC</abbr> non-membership properties.
+ </div>
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpc-HTTP_OPTIONS" rel="bibo:chapter" id="http-options-2">
+<h3 id="ldpc-HTTP_OPTIONS"><span class="secno">5.9 </span>HTTP OPTIONS</h3>
+ <p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for <abbr title="Linked Data Platform Containers">LDPCs</abbr>.
+ </p>
+
+ <div id="ldpc-5_9_1" class="rule">5.9.1
+ <abbr title="Linked Data Platform Container">LDPC</abbr> servers <em class="rfc2119" title="SHOULD">SHOULD</em> define a corresponding
+ <a href="#dfn-non-member-resource" class="internalDFN">non-member resource</a>
+ to support requests for information about a <abbr title="Linked Data Platform Container">LDPC</abbr>
+ without retrieving a full representation including all of its members;
+ see section <a href="#ldpc-get_non-member_props">5.1.2 Retrieving Only Non-member Properties</a> for
+ examples.
+ In responses to <code>OPTIONS</code> requests with an <abbr title="Linked Data Platform Container">LDPC</abbr> as the <code>Request-URI</code>,
+ <abbr title="Linked Data Platform Container">LDPC</abbr> servers that define a non-member resource <em class="rfc2119" title="SHOULD">SHOULD</em> provide an HTTP <code>Link</code>
+ header whose target URI is the <a href="#dfn-non-member-resource" class="internalDFN">non-member resource</a>, and whose link relation type is
+ <code>http://www.w3.org/ns/ldp#nonMemberResource</code> [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>].
+ This is the mechanism by which clients discover the URL of the non-member resource.
+ If no such <code>Link</code>
+ header is present, then conservative clients will assume that the <abbr title="Linked Data Platform Container">LDPC</abbr> does not have a corresponding
+ non-member resource.
+ For example, if there is a <abbr title="Linked Data Platform Container">LDPC</abbr> with URL <code><containerURL></code> whose corresponding
+ non-member resource
+ URL is <code><containerURL>?nonMemberProperties</code>, then the corresponding link header
+ would be <code>Link: <?nonMemberProperties>;rel="http://www.w3.org/ns/ldp#nonMemberResource"</code>
+ </div>
+
+ <div id="ldpc-5_9_2" class="rule">5.9.2 When a <abbr title="Linked Data Platform Container">LDPC</abbr> creates a non-<abbr title="Linked Data Platform Resource">LDPR</abbr> (e.g. binary) member (for example, one whose
+ representation was HTTP <code>POST</code>'d to the <abbr title="Linked Data Platform Container">LDPC</abbr> and then referenced by a membership triple) it might create an associated <abbr title="Linked Data Platform Resource">LDPR</abbr> to contain data about the
+ non-<abbr title="Linked Data Platform Resource">LDPR</abbr> (see <a href="#ldpc-5_4_12">5.4.12</a>). For non-<abbr title="Linked Data Platform Resources">LDPRs</abbr> that have this associated <abbr title="Linked Data Platform Resource">LDPR</abbr>, an <abbr title="Linked Data Platform Container">LDPC</abbr> server <em class="rfc2119" title="MUST">MUST</em> provide an HTTP <code>Link</code>
+ header whose target URI is the associated <abbr title="Linked Data Platform Resource">LDPR</abbr>, and whose link relation type is
+ <code>meta</code> [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>].</div>
+</section>
+
+<section typeof="bibo:Chapter" resource="#ldpc-inlining" rel="bibo:chapter" id="member-inlining-returning-all-of-a-container-page-s-members-in-a-response">
+<h3 id="ldpc-inlining"><span class="secno">5.10 </span>Member Inlining: Returning All of a Container Page's Members in a Response</h3>
+
+ <div class="atrisk"><p class="atrisktext">Feature At Risk</p>
+ <p>The LDP Working Group proposes incorporation of the features described in this section.</p>
+ <ul>
+ <li>The addition of <a href="#dfn-resource-inlining" class="internalDFN">resource inlining</a> to save application latency
+ and server/network load in controlled environments.</li>
+ </ul>
+ <p>Feedback, both positive and negative, is invited by sending email to the mailing list
+ in <a href="#sotd">Status of This Document</a>.</p>
+ </div>
+
+<section class="informative" typeof="bibo:Chapter" resource="#ldpc-InliningIntro" rel="bibo:chapter" id="introduction-3">
+<h4 id="ldpc-InliningIntro"><span class="secno">5.10.1 </span>Introduction</h4><p><em>This section is non-normative.</em></p>
+ <p>One of the most commonly cited scenarios for resource inlining is to save clients enumerating a container of
+ <i>m</i> members from having to perform <i>m+1</i> HTTP requests (or <i>m+p</i>, if the container
+ is paged into <i>p</i> pages). The desire is to allow the server to reduce the number of HTTP
+ round-trips by returning some (perhaps all) members' content as part of the container's representation.
+ In addition to the general <a href="#dfn-resource-inlining" class="internalDFN">resource inlining</a> mechanism useful
+ in cases where only a subset of the members' content is inlined, LDP also provides
+ a predicate for the special case where <i>all</i> of a container's or page's members are inlined.
+ Rather than forcing the server to add a triple for each inlined member, forcing clients to
+ compare the list of inlined members against the set of members in the representation,
+ and enlarging the representation needlessly,
+ a single triple can be used. This is called <a href="#dfn-member-inlining" class="internalDFN">member inlining</a>.
+ </p>
+
+ <p>LDP does not provide clients with any way to detect whether or not the server is capable of
+ resource inlining (all its resources or any specific resource), nor does it provide clients
+ with any way to influence which (if any) resources are inlined in any given response.
+ </p>
+
+ <p>The inlining building blocks LDP provides can only be safely used if certain assumptions hold.
+ This is no less true for containers than for <abbr title="Linked Data Platform Resources">LDPRs</abbr> in general.
+ See the general <a href="#ldpr-InliningWarnings">cautions on resource inlining</a>.
+ </p>
+</section> <!-- h3 -->
+
+<section typeof="bibo:Chapter" resource="#ldpc-InliningGET" rel="bibo:chapter" id="http-get-4">
+<h4 id="ldpc-InliningGET"><span class="secno">5.10.2 </span>HTTP GET</h4>
+ <p>In addition to the requirements set forth in other sections,
+ <abbr title="Linked Data Platform Container">LDPC</abbr> servers that support <a href="#dfn-member-inlining" class="internalDFN">member inlining</a>,
+ and LDP clients aware of the same facility,
+ must also follow the requirements in this section.
+ </p>
+
+ <div id="ldpc-5_10_2_1" class="rule">5.10.2.1 <abbr title="Linked Data Platform Container">LDPC</abbr> representations that are <a title="member inlining" href="#dfn-member-inlining" class="internalDFN">member inlined</a> <em class="rfc2119" title="MUST">MUST</em>
+ include a <code>ldp:Page</code> resource in the representation, whether or not the representation contains
+ multiple pages, as described in <a href="#ldpr-4_11_3_1">section 4.11.3.1</a>. In addition to satisfying
+ those requirements, the representation <em class="rfc2119" title="MUST">MUST</em> contain a triple
+ whose subject is the <code>ldp:Page</code> resource URI,
+ whose predicate is <code>ldp:membersInlined</code>, and
+ whose object is <code>"true"^^xsd:boolean</code>.
+ This is means by which the server communicates to LDP clients that they can avoid HTTP <code>GET</code>
+ requests for the members listed on the page.
+ </div>
+
+ <div id="ldpc-5_10_2_2" class="rule">5.10.2.2 <abbr title="Linked Data Platform Container">LDPC</abbr> clients <em class="rfc2119" title="SHOULD">SHOULD</em> avoid making HTTP <code>GET</code> requests
+ against any members in a <abbr title="Linked Data Platform Container">LDPC</abbr> representation containing a <code>ldp:Page</code> resource with the triple
+ described in <a href="#ldpc-5_10_2_1">section 5.10.2.1</a>, unless there are application-specific
+ reasons for doing so. Clients should note that by the time the representation is received, the actual state
+ of inlined members may have changed due to subsequent requests.
+ </div>
+
+ <div id="ldpc-5_10_2_3" class="rule">5.10.2.3 <abbr title="Linked Data Platform Container">LDPC</abbr> clients <em class="rfc2119" title="MUST NOT">MUST NOT</em> assume that <abbr title="Linked Data Platform Container">LDPC</abbr> representations
+ lacking a <code>ldp:Page</code> resource or lacking the triple
+ described in <a href="#ldpc-5_10_2_1">section 5.10.2.1</a> contain all the triples for all members
+ listed in the representation. The representation might in fact contain all those triples, or some
+ subset of them, that might or might not be completely adequate for the client's intended usage, but
+ an LDP client has no way to discern from such a representation which interpretation is accurate.
+ </div>
+
+ </section>
+
+</section> <!-- h2 -->
+</section>
+
+<section id="http-header-definitions">
+<!--OddPage--><h2><span class="secno">6. </span>HTTP Header Definitions</h2>
+
+<section typeof="bibo:Chapter" resource="#header-accept-post" rel="bibo:chapter" id="the-accept-post-response-header">
+<h3 id="header-accept-post"><span class="secno">6.1 </span>The Accept-Post Response Header</h3>
+
+ <div class="atrisk"><p class="atrisktext">Feature At Risk</p>
+ <p>The LDP Working Group proposes incorporation of the features described in this section.</p>
+ <ul>
+ <li>The addition of <a>Accept-Post</a> in this specification is pending
+ advancement of an IETF draft that would fully include it, see [<cite><a class="bibref" href="#bib-RFC5789">RFC5789</a></cite>]. Once LDP is in
+ Candidate Recommendation, the LDP WG will make an assessment based on the status at IETF
+ working with the <abbr title="World Wide Web Consortium">W3C</abbr> Director.</li>
+ </ul>
+ </div>
+
+ <p>This specification introduces a new HTTP response header <code>Accept-Post</code> used
+ to specify the document formats accepted by the server on HTTP <code>POST</code> requests.
+ It is modeled after the <code>Accept-Patch</code> header defined in [<cite><a class="bibref" href="#bib-RFC5789">RFC5789</a></cite>].
+ </p>
+
+ <div id="header-accept-post-1" class="rule">6.1.1 The syntax for <code>Accept-Post</code>, using
+ the ABNF syntax defined in Section 2.1 of [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>], is:
+ <blockquote><code>Accept-Post = "Accept-Post" ":" 1#media-type</code>
+ <p>
+ The <code>Accept-Post</code> header specifies a comma-separated list of media-
+ types (with optional parameters) as defined by [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>], Section 3.7.
+ </p>
+ </blockquote>
+ </div>
+
+ <div id="header-accept-post-2" class="rule">6.1.2
+ The <code>Accept-Post</code> HTTP header <em class="rfc2119" title="SHOULD">SHOULD</em> appear in the <code>OPTIONS</code> response for any resource
+ that supports the use of the <code>POST</code> method. The presence of the
+ <code>Accept-Post</code> header in response to any method is an implicit
+ indication that <code>POST</code> is allowed on the resource identified by the
+ <code>Request-URI</code>. The presence of a specific document format in
+ this header indicates that that specific format is allowed on <code>POST</code> requests to the
+ resource identified by the <code>Request-URI</code>.
+ </div>
+
+ <div id="header-accept-post-iana" class="rule">6.1.3 IANA Registration Template</div>
+ <div>
+ <blockquote>
+ <p>
+ The Accept-Post response header must be added to the permanent registry (see [<cite><a class="bibref" href="#bib-RFC3864">RFC3864</a></cite>]).
+ </p>
+ <p>
+ Header field name: Accept-Post
+ </p>
+ <p>
+ Applicable Protocol: HTTP
+ </p>
+ <p>
+ Author/Change controller: <abbr title="World Wide Web Consortium">W3C</abbr>
+ </p>
+ <p>
+ Specification document: this specification
+ </p>
+ </blockquote>
+ </div>
+
+</section>
+</section> <!-- Header defns -->
+
+<section class="appendix informative" id="acknowledgements">
+<!--OddPage--><h2><span class="secno">A. </span>Acknowledgements</h2><p><em>This section is non-normative.</em></p>
+
+ <p>The following people have been instrumental in providing thoughts, feedback,
+reviews, content, criticism and input in the creation of this specification:</p>
+
+ <p style="margin-left: 3em;">Tim Berners-Lee, Steve Battle,
+ Olivier Berger, Alexandre Bertails, Reza B'Far, Cody Burleson, Richard Cyganiak, Raúl García Castro,
+ Miguel Esteban Gutiérrez,
+ Sandro Hawke, Kingsley Idehen, Yves Lafon, Arnaud Le Hors, Antonis Loizou, Ashok Malhota, Roger Menday,
+ Nandana Mihindukulasooriya, Kevin Page, Eric Prud'hommeaux, Andy Seaborne, Steve Speicher,
+ Henry Story, Ted Thibodeau, Bart van Leeuwen, Miel Vander Sande, Ruben Verborgh, Serena Villata, Erik Wilde, David Wood, Martin P. Nally</p>
+
+</section>
+
+<!--
+<section class='appendix informative' id="history">
+<h1>Change History</h1>
+<p>The change history is up to the editors to insert a brief summary of
+changes, ordered by most recent changes first and with heading from which
+public draft it has been changed from.
+</p> -->
+<!--
+<blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130701/">Third Public Working Draft</a></em></blockquote>
+-->
+<!--
+<ul>
+ <li>2013-07-24 - Moved 4.7.2 (from HEAD) to 4.3.2 (GET), shifted rest of GET section by one (SS)</li>
+ <li>2013-07-24 - Moved 4.10.2.5->4.10.2.4.3,4.10.2.6->4.10.2.4.1,4.10.2.7->4.10.2.4.2 and added samples (SS)</li>
+ <li>2013-07-24 - Changed ldp:ascending->ldp:Ascending, ldp:descending->ldp:Descending, ldp:non-member-resource ->ldp:nonMemberResource (SS)</li>
+ <li>2013-07-24 - Added term <a title="Page resource"></a> (SS)</li>
+ <li>2013-07-24 - Removed 5.4.8.1 and added 4.2.12 to better handle base/rel URI (SS)</li>
+ <li>2013-07-23 - Added informative <a href="#ldpr-informative" class="sectionRef"></a>, therefore shifting all sections by one 4.1->4.2, etc (SS)</li>
+ <li>2013-07-23 - Changed <a href="#header-accept-post" class="sectionRef"></a> to at risk as possibly moving to IETF (SS)</li>
+ <li>2013-07-23 - ISSUE-53 4.2.3 changed MUST to SHOULD (SS)</li>
+ <li>2013-07-22 - ISSUE-53 4.2.2 changed MUST to SHOULD (SS)</li>
+ <li>2013-07-17 - Various updates from suggests from <a href="http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0067.html">Raúl</a> (SS)</li>
+ <li>2013-07-15 - Inserted ldp:membershipObject into examples (SS)</li>
+ <li>2013-07-15 - ISSUE-79 ldp:contains => ldp:created (JA)</li>
+ <li>2013-07-11 - Improving working in <a href="#ldpr-Paging" class="sectionRef"></a> to remove container references (SS)</li>
+ <li>2013-07-11 - Removed 4.1.5, section number fixup:4.1.8-13->6-11, 4.9.2.* fixup, 5.3.7-10->>2-5 (SS)</li>
+ <li>2013-07-11 - Removed all stubbed out sections 5.1.3, 5.3.2-6 (SS)</li>
+ <li>2013-07-11 - Various editorial clean up items from editor todo list (SS)</li>
+ <li>2013-07-11 - Removed closed issues that required no new spec changes: 50, 56, 16, 19, 17 (SS)</li>
+ <li>2013-07-11 - ISSUE-51 Added how a LDPR can show which LDPC is it in (SS)</li>
+ <li>2013-07-10 - Removed closed issues that required no new spec changes: 18, 35, 20 (SS)</li>
+ <li>2013-07-10 - ISSUE-44 move section 4.1.7 (relationships are simple RDF links) to guidance (SS)</li>
+ <li>2013-07-10 - ISSUE-72 take 2 - added ldp:MemberSubject to handle default case (SS)</li>
+ <li>2013-07-10 - ISSUE-72 adding 5.2.10 for ldp:membershipObject (SS)</li>
+ <li>2013-07-09 - ISSUE-58 inlining - actions 87-89 inclusive (JA)</li>
+ <li>2013-07-08 - Moved 5.7.* sections out of HEAD and into OPTIONS as 5.9.*, added 4.6.2 (SS)</li>
+ <li>2013-07-08 - ISSUE-15 Inserted 5.4.12, 5.6.4, 5.7.2 to describe link-relation meta usage (SS)</li>
+ <li>2013-07-08 - ISSUE-79 ldp:contains (JA)</li>
+ <li>2013-07-08 - ISSUE-80 Accept-Post (JA)</li>
+ <li>2013-07-08 - ISSUE-32 Must support options (JA)</li>
+ <li>2013-07-08 - ISSUE-78 No client inferencing (JA)</li>
+ <li>2013-07-08 - ISSUE-77 Move "must have rdf:type explicitly" to Best Practices (JA)</li>
+ <li>2013-07-08 - ISSUE-57 Knowing it's an LDP server (JA)</li>
+ <li>2013-07-01 - ISSUE-33 Moved 5.1.3 Paging (LDPC) to 4.8 (LDPR) (SS)</li>
+ <li>2013-06-18 - ISSUE-75 5.2.5 membershipxxx predicates required, per 2013-06-18 F2F resolution (JA)</li>
+ <li>2013-06-18 - ISSUE-63 End of 5.3 + example rewritten for 2013-06-18 F2F resolution (JA)</li>
+ <li>2013-06-15 - ISSUE-14 End of 5.3 + example rewritten for ascending/descending sorts with optional collation (JA)</li>
+ <li>2013-06-13 - ISSUE-54 New 5.4.8.1 to set base URI on create for relative URI resolution (SS)</li>
+ <li>2013-06-10 - ISSUE-74 4.4.2 require 428 Condition Required status code when appropriate; SS adding 6585 to biblio (JA)</li>
+ <li>2013-06-05 - ISSUE-64 Remove ?non-member-properties; 5.1.2, 5.3.2, 5.5.2 (JA)</li>
+ <li>2013-05-21 - ISSUE-35 Re-use of URIs on create; 5.2.9, 5.4.11, 5.5.4 (JA)</li>
+ <li>2013-05-21 - ISSUE-43 Slug in LDPC POSTs; 5.4.8, 5.4.10 (JA)</li>
+ <li>2013-05-21 - ISSUE-65 Remove firstPage in favor of Link rel=first, mostly hits 5.3.3/5.3.4 (JA)</li>
+ <li>2013-05-17 - ISSUE-13 Updated 5.2.3 to say any resource can be in a LDPC and inserted 5.5.3 on rejecting member data on PUT to LDPC (SS)</li>
+ <li>2013-05-17 - Tweaks to Terminology section for LDPR and LDPC (SS)</li>
+ <li>2013-05-17 - ISSUE-9 Moved section 4.1.7 out of spec to the <a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Servers_should_serve_up_canonical_URLs">deployment guide</a> (SS)</li>
+ <li>2013-05-15 - Updated wording for 5.2.2 from to be more clear (SS)</li>
+ <li>2013-05-13 - ISSUE-49 Moved section 4.1.4 out of spec to the <a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Predicate_URIs_SHOULD_be_HTTP_URLs">deployment guide</a>. (SS)</li>
+ <li>2013-05-08 - Removed closed issues 5, 7, 55 and 38 as the don't require edits. Added 64 and 65. (SS)</li>
+ <li>2013-05-08 - ISSUE-59 5.3.2 limited rdf:type of ldp:Container, removed 5.6.3, reworded 5.6.2, updated 1. (SS)</li>
+ <li>2013-04-15 - ISSUE-21 Added ldp:membershipPredicateInverse to 5.2.5 & 5.5.2, created 5.2.5.1 & 5.3.5.2 to indicate difference. (SS)</li>
+ <li>2013-04-15 - ISSUE-39 Moved informative text from 5.4.5 into 5.4.1, shifted subsections .6-.10 (SS)</li>
+ <li>2013-04-15 - Expanded on wording for 4.3 to be more consistent (SS)</li>
+ <li>2013-04-08 - Fixed two old references to BPR (SS)</li>
+ <li>2013-03-17 - Inserted examples 2&3, a more complete NetWorth resource (SS)</li>
+ <li>2013-03-15 - Update LDPC glossary term based on Cody's feedback (SS)</li>
+ <li>2013-03-15 - Additional fix in 5.2.2 for ISSUE-34 (SS)</li>
+ <li>2013-03-15 - Remove reference to closed issues that don't require edits: ISSUE-27 & ISSUE-45 (SS)</li>
+ <li>2013-03-14 - General prep for 3rd draft, cleanup and a little restructure (SS)</li>
+</ul>
+
+<blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130307/">Second Public Working Draft</a></em></blockquote>
+<ul>
+ <li>2013-03-14 - Fixed up broken fragments and typos before publication (SS)</li>
+ <li>2013-03-04 - Comments received from David Wood: 5.3.7 & 5.1.3 clarity, other minor edits (part 2) (SS)</li>
+ <li>2013-03-04 - Comments received from David Wood: abstract, paging informative (part 1) (SS)</li>
+ <li>2013-03-04 - ISSUE-36 - Added informative text regarding creationg of containers in 5.4.4 (SS)</li>
+ <li>2013-03-04 - ISSUE-12 - Added section 4.7.3 not to allow PATCH for create (SS)</li>
+ <li>2013-03-03 - Adjustments to language about different container behavior (SS)</li>
+ <li>2013-03-02 - Adding trailing '/' on Container URLs to help with readability based on WG suggestion (SS)</li>
+ <li>2013-02-26 - Updated Acknowledgements section (SS)</li>
+ <li>2013-02-25 - ISSUE-29 - Use relative URIs in examples (SS)</li>
+ <li>2013-02-25 - ISSUE-31 - Added a more complete conformance section, motived by SPARQL 1.1 (SS)</li>
+ <li>2013-02-25 - Updating some simple formatting, reorganizing open issues and todos. (SS) </li>
+ <li>2013-02-15 - ISSUE-34 - Aggregration: 5.6.1 and 5.6.2 updated for review. (JA) </li>
+ <li>2013-02-13 - ISSUE-42 - 4.8 Common Properties moved to
+ <a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Re-use_established_linked_data_vocabularies_instead_of_.28re-.29inventing_duplicates">Deploment Guide</a>
+ (JA) </li>
+ <li>2013-02-12 - Fixed up previous publication links (SS) </li>
+ <li>2013-02-12 - ISSUE-10 - 4.1.12 to be MUST use entity tags (either weak or strong ones) (SS) </li>
+ <li>2013-02-12 - ISSUE-11 - 4.4.1 Relaxed the MUST ignore dc:modified/creator to MAY (SS) </li>
+ <li>2013-01-16 - ISSUE-25 Updated introduction. 5.2.2 changed to MUST NOT be in multiple containers. Flipped 5.6.1/2 as
+ first rule leads to 2nd. 5.6.2(was .1) Delete LDPC MUST also delete members. (SS)</li>
+ <li>2013-01-16 - Added new issues ranging from 26-43. Removed closed/deferred issues: 2 & 3 (SS)</li>
+ <li>2012-12-28 - Fixed Typos. Separated some compound rules like 4.1.5. Rewording for clarity: 4.1.10,
+ Text being repeated in several places centralized and cross-linked. Made printed code output easier to read
+ on black & white printers. Exposed terms defined in-line under LDPC as Terminology (tentatively). Removed non-normative
+ qualifer from section 5.2. Added "several" editors' to-dos.(JA)</li>
+ <li>2012-11-05 - minor rewording from ISSUE-24</li>
+ <li>2012-11-03 - ISSUE-22, ISSUE-23: changed sections 4.2.3 and 5.4.7. Removed closed issues. (SS)</li>
+ <li>2012-11-03 - ISSUE-24 Delete the phrase in 4.5.1 that nays "until ...Request URI"
+ and adding a sentence, "Clients should note that servers may reuse a Request-URI under some circumstances."</li>
+ <li>2012-11-03 - ISSUE-6 Removed section 4.1.9. Shifted up sections .10 through .13.</li>
+ <li>2012-11-01 - Fixed minor typo and added some notes (SS)</li>
+</ul>
+
+<blockquote><em><a href="http://www.w3.org/TR/2012/WD-ldp-20121025/">First Public Working Draft</a></em></blockquote>
+<ul>
+ <li>2012-10-15 - ISSUE-8 Changed references from LDBP to LDP, removed definition for "profile" and new namespace (SS)</li>
+ <li>2012-10-15 - Included additional open ISSUES from Oct 15 WG meeting: 22, 23, 24 (SS)</li>
+ <li>2012-10-14 - Added open ISSUES and formating to prep for public working draft (SS)</li>
+ <li>2012-09-20 - Sent pull request re LINKED-DATA and added suggestion for <code>ldp</code> namespace (SS)</li>
+ <li>2012-09-19 - Repairing references and forward reference to biblio.js updates (SS)</li>
+ <li>2012-09-19 - Fixed rdfs:label range to be rdfs:Literal (SS)</li>
+ <li>2012-09-19 - ISSUE-1 Define Turtle as the required serialization format for LDP (SS)</li>
+ <li>2012-09-18 - Initial ReSpec'ing of <a href="http://www.w3.org/Submission/ldbp/">Member Submission - Linked Data Basic Profile 1.0</a> (SS)</li>
+ <li>2012-09-18 - Fixed up some links and worked on references, work left to do. (SS)</li>
+</ul>
+<blockquote><em><a href="http://www.w3.org/Submission/2012/SUBM-ldbp-20120326/">Submission</a></em></blockquote>
+</section>
+ -->
+
+
+
+<section id="references" class="appendix" typeof="bibo:Chapter" resource="#references" rel="bibo:chapter"><!--OddPage--><h2><span class="secno">B. </span>References</h2><section id="normative-references" typeof="bibo:Chapter" resource="#normative-references" rel="bibo:chapter"><h3><span class="secno">B.1 </span>Normative references</h3><dl class="bibliography" about=""><dt id="bib-DC-TERMS">[DC-TERMS]</dt><dd rel="dcterms:requires">Dublin Core Metadata Initiative. <a href="http://dublincore.org/documents/2010/10/11/dcmi-terms/"><cite>Dublin Core Metadata Initiative Terms, version 1.1.</cite></a> 11 October 2010. DCMI Recommendation. URL: <a href="http://dublincore.org/documents/2010/10/11/dcmi-terms/">http://dublincore.org/documents/2010/10/11/dcmi-terms/</a>.
+</dd><dt id="bib-HTML401">[HTML401]</dt><dd rel="dcterms:requires">Dave Raggett; Arnaud Le Hors; Ian Jacobs. <a href="http://www.w3.org/TR/html401"><cite>HTML 4.01 Specification</cite></a>. 24 December 1999. W3C Recommendation. URL: <a href="http://www.w3.org/TR/html401">http://www.w3.org/TR/html401</a>
+</dd><dt id="bib-HTTP11">[HTTP11]</dt><dd rel="dcterms:requires">R. Fielding et al. <a href="http://www.ietf.org/rfc/rfc2616.txt"><cite>Hypertext Transfer Protocol - HTTP/1.1</cite></a>. June 1999. RFC. URL: <a href="http://www.ietf.org/rfc/rfc2616.txt">http://www.ietf.org/rfc/rfc2616.txt</a>
+</dd><dt id="bib-RDF-CONCEPTS">[RDF-CONCEPTS]</dt><dd rel="dcterms:requires">Graham Klyne; Jeremy Carroll. <a href="http://www.w3.org/TR/rdf-concepts/"><cite>Resource Description Framework (RDF): Concepts and Abstract Syntax</cite></a>. 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/rdf-concepts/">http://www.w3.org/TR/rdf-concepts/</a>
+</dd><dt id="bib-RDF-SCHEMA">[RDF-SCHEMA]</dt><dd rel="dcterms:requires">Dan Brickley; Ramanathan Guha. <a href="http://www.w3.org/TR/rdf-schema"><cite>RDF Vocabulary Description Language 1.0: RDF Schema</cite></a>. 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/rdf-schema">http://www.w3.org/TR/rdf-schema</a>
+</dd><dt id="bib-RFC2119">[RFC2119]</dt><dd rel="dcterms:requires">S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for use in RFCs to Indicate Requirement Levels.</cite></a> March 1997. Internet RFC 2119. URL: <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>
+</dd><dt id="bib-RFC3864">[RFC3864]</dt><dd rel="dcterms:requires">G. Klyne; M. Nottingham; J. Mogul. <a href="http://www.ietf.org/rfc/rfc3864.txt"><cite>Registration Procedures for Message Header Fields</cite></a>. September 2004. RFC. URL: <a href="http://www.ietf.org/rfc/rfc3864.txt">http://www.ietf.org/rfc/rfc3864.txt</a>
+</dd><dt id="bib-RFC3987">[RFC3987]</dt><dd rel="dcterms:requires">M. Dürst; M. Suignard. <a href="http://www.ietf.org/rfc/rfc3987.txt"><cite>Internationalized Resource Identifiers (IRIs)</cite></a>. January 2005. RFC. URL: <a href="http://www.ietf.org/rfc/rfc3987.txt">http://www.ietf.org/rfc/rfc3987.txt</a>
+</dd><dt id="bib-RFC4627">[RFC4627]</dt><dd rel="dcterms:requires">D. Crockford. <a href="http://www.ietf.org/rfc/rfc4627.txt"><cite>The application/json Media Type for JavaScript Object Notation (JSON) (RFC 4627)</cite></a>. July 2006. RFC. URL: <a href="http://www.ietf.org/rfc/rfc4627.txt">http://www.ietf.org/rfc/rfc4627.txt</a>
+</dd><dt id="bib-RFC5023">[RFC5023]</dt><dd rel="dcterms:requires">J. Gregorio; B. de hOra. <a href="http://www.ietf.org/rfc/rfc5023.txt"><cite>The Atom Publishing Protocol</cite></a>. October 2007. RFC. URL: <a href="http://www.ietf.org/rfc/rfc5023.txt">http://www.ietf.org/rfc/rfc5023.txt</a>
+</dd><dt id="bib-RFC5789">[RFC5789]</dt><dd rel="dcterms:requires">L Dusseault; J. Snell. <a href="http://tools.ietf.org/html/rfc5789"><cite>PATCH Method for HTTP (RFC 5789)</cite></a>. March 2010. RFC. URL: <a href="http://tools.ietf.org/html/rfc5789">http://tools.ietf.org/html/rfc5789</a>
+</dd><dt id="bib-RFC5988">[RFC5988]</dt><dd rel="dcterms:requires">Mark Nottingham. <a href="http://www.ietf.org/rfc/rfc5988.txt"><cite>Web Linking (RFC 5988)</cite></a>. October 2010. RFC. URL: <a href="http://www.ietf.org/rfc/rfc5988.txt">http://www.ietf.org/rfc/rfc5988.txt</a>
+</dd><dt id="bib-RFC6585">[RFC6585]</dt><dd rel="dcterms:requires">M. Nottingham; R. Fielding. <a href="http://www.ietf.org/rfc/rfc6585.txt"><cite>Additional HTTP Status Codes</cite></a>. April 2012. RFC. URL: <a href="http://www.ietf.org/rfc/rfc6585.txt">http://www.ietf.org/rfc/rfc6585.txt</a>
+</dd><dt id="bib-SPARQL-QUERY">[SPARQL-QUERY]</dt><dd rel="dcterms:requires">Eric Prud'hommeaux; Andy Seaborne. <a href="http://www.w3.org/TR/rdf-sparql-query/"><cite>SPARQL Query Language for RDF</cite></a>. 15 January 2008. W3C Recommendation. URL: <a href="http://www.w3.org/TR/rdf-sparql-query/">http://www.w3.org/TR/rdf-sparql-query/</a>
+</dd><dt id="bib-SPARQL-UPDATE">[SPARQL-UPDATE]</dt><dd rel="dcterms:requires">Paul Gearon; Alexandre Passant; Axel Polleres. <a href="http://www.w3.org/TR/sparql11-update/"><cite>SPARQL 1.1 Update</cite></a>. 21 March 2013. W3C Recommendation. URL: <a href="http://www.w3.org/TR/sparql11-update/">http://www.w3.org/TR/sparql11-update/</a>
+</dd><dt id="bib-TURTLE">[TURTLE]</dt><dd rel="dcterms:requires">David Beckett; Tim Berners-Lee. <a href="http://www.w3.org/TeamSubmission/turtle/"><cite>Turtle: Terse RDF Triple Language</cite></a>. January 2008. W3C Team Submission. URL: <a href="http://www.w3.org/TeamSubmission/turtle/">http://www.w3.org/TeamSubmission/turtle/</a>
+</dd></dl></section><section id="informative-references" typeof="bibo:Chapter" resource="#informative-references" rel="bibo:chapter"><h3><span class="secno">B.2 </span>Informative references</h3><dl class="bibliography" about=""><dt id="bib-LINKED-DATA">[LINKED-DATA]</dt><dd rel="dcterms:references">Tim Berners-Lee. <a href="http://www.w3.org/DesignIssues/LinkedData.html"><cite>Linked Data Design Issues</cite></a>. 27 July 2006. W3C-Internal Document. URL: <a href="http://www.w3.org/DesignIssues/LinkedData.html">http://www.w3.org/DesignIssues/LinkedData.html</a>
+</dd><dt id="bib-RFC3986">[RFC3986]</dt><dd rel="dcterms:references">T. Berners-Lee; R. Fielding; L. Masinter. <a href="http://www.ietf.org/rfc/rfc3986.txt"><cite>Uniform Resource Identifier (URI): Generic Syntax (RFC 3986)</cite></a>. January 2005. RFC. URL: <a href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>
+</dd><dt id="bib-WEBARCH">[WEBARCH]</dt><dd rel="dcterms:references">Ian Jacobs; Norman Walsh. <a href="http://www.w3.org/TR/webarch/"><cite>Architecture of the World Wide Web, Volume One</cite></a>. 15 December 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/webarch/">http://www.w3.org/TR/webarch/</a>
+</dd></dl></section></section></body></html>
\ No newline at end of file