--- a/.hgtags Wed Mar 05 16:33:45 2014 +0000
+++ b/.hgtags Wed Mar 05 16:34:18 2014 +0000
@@ -1,1 +1,2 @@
71b0517fff46cbbb327f29599a05871ba54f6027 lc1
+b86124412c7aca632ae24a01890cc899634d9493 lc2
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/TR/WD-ldp-20140311/Overview.html Wed Mar 05 16:34:18 2014 +0000
@@ -0,0 +1,2381 @@
+<!DOCTYPE html>
+<!-- saved from url=(0054) -->
+<html lang="en" dir="ltr" typeof="bibo:Document w3p:LastCall" about="" property="dcterms:language" content="en" prefix="bibo: http://purl.org/ontology/bibo/ w3p: http://www.w3.org/2001/02pd/rec54#"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+ <title>Linked Data Platform 1.0</title>
+
+ <!--
+ === 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;
+ }
+ .normal {
+ font-weight: normal;
+ font: normal 100% sans-serif;
+ }
+ .indented {
+ margin-left: +3em;
+ }
+ tr:nth-of-type(odd),.oddrow {
+ background:#F2F2F2; /* light grey, just enough to differentiate from white */
+ }
+ td {
+ padding:0 +1ex 0 +1ex; /* add a bit of space from rule/edge to text */
+ }
+
+ </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;
+}
+
+@media print {
+ .removeOnSave {
+ display: none;
+ }
+}
+</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="" role="document" id="respecDocument"><div class="head" role="contentinfo" id="respecHeader">
+ <p>
+
+ <a href="http://www.w3.org/"><img width="72" height="48" src="http://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="2014-03-11T04:00:00.000Z" id="w3c-last-call-working-draft-11-march-2014"><abbr title="World Wide Web Consortium">W3C</abbr> Last Call Working Draft <time class="dt-published" datetime="2014-03-11">11 March 2014</time></h2>
+ <dl>
+
+ <dt>This version:</dt>
+ <dd><a class="u-url" href="http://www.w3.org/TR/2014/WD-ldp-20140311/">http://www.w3.org/TR/2014/WD-ldp-20140311/</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-20130730/">http://www.w3.org/TR/2013/WD-ldp-20130730/</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="mailto: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>
+ © 2014 <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. W3C
+ <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>
+
+</div>
+<hr>
+<section id="abstract" class="introductory" property="dcterms:abstract" datatype="" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h2 aria-level="1" role="heading" id="h2_abstract">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="#ref" rel="bibo:Chapter"><h2 aria-level="1" role="heading" id="h2_sotd">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 is the 2nd Last Call for Comments where the Working Group has addressed all
+ raised issues and as a result some significant changes have been made, see <a href="#history" class="sectionRef sec-ref">section <span class="secno">B.</span> <span class="sec-title">Change History</span></a>. Most notably
+ the Working Group has decided to handle paging as an extension to LDP in a separate
+ REC-track specification. [<cite><a class="bibref" href="#bib-LDP-PAGING">LDP-PAGING</a></cite>]
+ </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 April 2014.
+
+
+ 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" aria-level="1" role="heading" id="h2_toc">Table of Contents</h2><ul class="toc" role="directory" id="respecContents"><li class="tocline"><a href="#intro" class="tocxref"><span class="secno">1. </span>Introduction</a></li><li class="tocline"><a href="#terms" class="tocxref"><span class="secno">2. </span>Terminology</a><ul class="toc"><li class="tocline"><a href="#conventions" 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="#ldpr" class="tocxref"><span class="secno">4. </span>Linked Data Platform Resources</a><ul class="toc"><li class="tocline"><a href="#ldpr-informative" class="tocxref"><span class="secno">4.1 </span>Introduction</a></li><li class="tocline"><a href="#ldpr-resource" class="tocxref"><span class="secno">4.2 </span>Resource</a><ul class="toc"></ul></li><li class="tocline"><a href="#ldprs" class="tocxref"><span class="secno">4.3 </span><abbr title="Resource Description Framework">RDF</abbr> Source</a><ul class="toc"></ul></li><li class="tocline"><a href="#ldpnr" class="tocxref"><span class="secno">4.4 </span>Non-<abbr title="Resource Description Framework">RDF</abbr> Source</a><ul class="toc"></ul></li></ul></li><li class="tocline"><a href="#ldpc" class="tocxref"><span class="secno">5. </span>Linked Data Platform Containers</a><ul class="toc"><li class="tocline"><a href="#ldpc-informative" class="tocxref"><span class="secno">5.1 </span>Introduction</a><ul class="toc"></ul></li><li class="tocline"><a href="#ldpc-container" class="tocxref"><span class="secno">5.2 </span>Container</a><ul class="toc"></ul></li><li class="tocline"><a href="#ldpbc" class="tocxref"><span class="secno">5.3 </span>Basic</a><ul class="toc"></ul></li><li class="tocline"><a href="#ldpdc" class="tocxref"><span class="secno">5.4 </span>Direct</a><ul class="toc"></ul></li><li class="tocline"><a href="#ldpic" class="tocxref"><span class="secno">5.5 </span>Indirect</a><ul class="toc"></ul></li></ul></li><li class="tocline"><a href="#base-specs" class="tocxref"><span class="secno">6. </span>Notable information from normative references</a><ul class="toc"><li class="tocline"><a href="#specs-webarch" class="tocxref"><span class="secno">6.1 </span>Architecture of the World Wide Web</a><ul class="toc"></ul></li><li class="tocline"><a href="#specs-http" class="tocxref"><span class="secno">6.2 </span>HTTP 1.1</a><ul class="toc"></ul></li><li class="tocline"><a href="#specs-rdf" class="tocxref"><span class="secno">6.3 </span><abbr title="Resource Description Framework">RDF</abbr></a><ul class="toc"></ul></li></ul></li><li class="tocline"><a href="#http-header-definitions" class="tocxref"><span class="secno">7. </span>HTTP Header Definitions</a><ul class="toc"><li class="tocline"><a href="#header-accept-post" class="tocxref"><span class="secno">7.1 </span>The Accept-Post Response Header</a><ul class="toc"></ul></li><li class="tocline"><a href="#prefer-parameters" class="tocxref"><span class="secno">7.2 </span>Preferences on the Prefer Request Header</a><ul class="toc"></ul></li></ul></li><li class="tocline"><a href="#security" class="tocxref"><span class="secno">8. </span>Security Considerations</a></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a href="#history" class="tocxref"><span class="secno">B. </span>Change History</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">C. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">C.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">C.2 </span>Informative references</a></li></ul></li></ul></section>
+
+
+
+<section class="informative" id="intro" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<!--OddPage--><h2 aria-level="1" role="heading" id="h2_intro"><span class="secno">1. </span>Introduction</h2><p><em>This section is non-normative.</em></p>
+ <p>This specification 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 rules of Linked Data [<cite><a class="bibref" href="#bib-LINKED-DATA">LINKED-DATA</a></cite>]:</p>
+ <ol>
+ <li>Use URIs as names for things</li>
+ <li>Use HTTP URIs so that people can look up those names</li>
+ <li>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>)
+ </li>
+ <li>Include links to other URIs, so that they can discover more things</li>
+ </ol>
+ <p>This specification discusses standard HTTP and <abbr title="Resource Description Framework">RDF</abbr> techniques
+ used when constructing clients and servers that
+ create, read, and write <a title="Linked Data Platform Resource" href="#dfn-linked-data-platform-resource" class="internalDFN">Linked Data Platform Resources</a>.
+ A companion document discusses best practices that you
+ should use, and anti-patterns you should avoid, when constructing these clients and servers.
+ </p>
+ <p>This specification defines a special type of <a href="#dfn-linked-data-platform-resource" class="internalDFN">Linked Data Platform Resource</a>: a
+ <a title="Linked Data Platform Container" href="#dfn-linked-data-platform-container" class="internalDFN">Container</a>. Containers are very useful
+ in building application models involving collections of resources, often homogeneous ones.
+ For example, universities offer a collection of classes
+ and have a collection of faculty members, each faculty member teaches a collection of courses, and so on.
+ This specification discusses how to work with containers. Resources can be added to containers
+ using standard HTTP operations like
+ POST (see <a href="#ldpc-HTTP_POST" class="sectionRef sec-ref">section <span class="secno">5.2.3</span> <span class="sec-title">HTTP POST</span></a>).</p>
+ <p>The intention of this specification 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>
+ <p>This specification provides some approaches to deal with large resources. An extension to this specification
+ provides the ability to break large resource representations into multiple paged responses [<cite><a class="bibref" href="#bib-LDP-PAGING">LDP-PAGING</a></cite>].</p>
+ <p>For context and background, it could be useful to read <a href="#bib-LDP-UCR">Linked Data Platform Use Case and Requirements</a> [<cite><a class="bibref" href="#bib-LDP-UCR">LDP-UCR</a></cite>]
+ and <a href="#base-specs" class="sectionRef sec-ref">section <span class="secno">6.</span> <span class="sec-title">Notable information from normative references</span></a>.</p>
+</section>
+
+<section id="terms" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<!--OddPage--><h2 aria-level="1" role="heading" id="h2_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>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-linked-data-platform-resource">Linked Data Platform Resource</dfn> (<abbr title="Linked Data Platform Resource">LDPR</abbr>)</dt>
+ <dd>A HTTP resource whose state is represented in any way that conforms to the simple lifecycle
+ patterns and conventions in <a href="#ldpr" class="sectionRef sec-ref">section <span class="secno">4.</span> <span class="sec-title">Linked Data Platform Resources</span></a>.<p></p></dd>
+
+ <dt><dfn id="dfn-linked-data-platform-rdf-source">Linked Data Platform <abbr title="Resource Description Framework">RDF</abbr> Source</dfn> (<abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>)</dt>
+ <dd>An <a title="Linked Data Platform Resource" href="#dfn-linked-data-platform-resource" class="internalDFN"><abbr title="Linked Data Platform Resource">LDPR</abbr></a> whose state is fully represented in <abbr title="Resource Description Framework">RDF</abbr>, corresponding to
+ an <abbr title="Resource Description Framework">RDF</abbr> <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a>. See also the term
+ <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-source"><abbr title="Resource Description Framework">RDF</abbr> Source</a> from [<cite><a class="bibref" href="#bib-rdf11-concepts">rdf11-concepts</a></cite>].
+ <p></p></dd>
+
+ <dt><dfn id="dfn-linked-data-platform-non-rdf-source">Linked Data Platform Non-<abbr title="Resource Description Framework">RDF</abbr> Source</dfn> (<abbr title="Linked Data Platform Non-RDF Source">LDP-NR</abbr>)</dt>
+ <dd>An <a title="Linked Data Platform Resource" href="#dfn-linked-data-platform-resource" class="internalDFN"><abbr title="Linked Data Platform Resource">LDPR</abbr></a> whose state is <em>not</em> represented in <abbr title="Resource Description Framework">RDF</abbr>.
+ These are binary or text documents that do not have useful <abbr title="Resource Description Framework">RDF</abbr> representations.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-linked-data-platform-container">Linked Data Platform Container</dfn> (<abbr title="Linked Data Platform Container">LDPC</abbr>)</dt>
+ <dd>An <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> representing a collection of linked
+ documents (<a href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-document"><abbr title="Resource Description Framework">RDF</abbr> Document</a> [<cite><a class="bibref" href="#bib-rdf11-concepts">rdf11-concepts</a></cite>] or information resources [<cite><a class="bibref" href="#bib-WEBARCH">WEBARCH</a></cite>])
+ that responds to client requests for creation, modification, and/or enumeration of its linked members and documents,
+ and that conforms to the simple lifecycle
+ patterns and conventions in <a href="#ldpc" class="sectionRef sec-ref">section <span class="secno">5.</span> <span class="sec-title">Linked Data Platform Containers</span></a>.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-linked-data-platform-basic-container">Linked Data Platform Basic Container</dfn> (<abbr title="Linked Data Platform Basic Container">LDP-BC</abbr>)</dt>
+ <dd>An <a title="Linked Data Platform Container" href="#dfn-linked-data-platform-container" class="internalDFN"><abbr title="Linked Data Platform Container">LDPC</abbr></a> that defines a simple link to
+ its <a title="Containment" href="#dfn-containment" class="internalDFN">contained</a> documents (information resources) [<cite><a class="bibref" href="#bib-WEBARCH">WEBARCH</a></cite>].
+ <p></p></dd>
+
+ <dt><dfn id="dfn-linked-data-platform-direct-container">Linked Data Platform Direct Container</dfn> (<abbr title="Linked Data Platform Direct Container">LDP-DC</abbr>)</dt>
+ <dd>An <a title="Linked Data Platform Container" href="#dfn-linked-data-platform-container" class="internalDFN"><abbr title="Linked Data Platform Container">LDPC</abbr></a> adds the concept <a title="Membership" href="#dfn-membership" class="internalDFN">membership</a>, allows the flexibility of choosing what form its
+ <a title="Membership triples" href="#dfn-membership-triples" class="internalDFN">membership triples</a> take, and allows <a title="Membership" href="#dfn-membership" class="internalDFN">members</a> to be
+ any resources [<cite><a class="bibref" href="#bib-WEBARCH">WEBARCH</a></cite>], not only documents.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-linked-data-platform-indirect-container">Linked Data Platform Indirect Container</dfn> (<abbr title="Linked Data Platform Indirect Container">LDP-IC</abbr>)</dt>
+ <dd>An <a title="Linked Data Platform Container" href="#dfn-linked-data-platform-container" class="internalDFN"><abbr title="Linked Data Platform Container">LDPC</abbr></a> that is similar to a <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN"><abbr title="Linked Data Platform Direct Container">LDP-DC</abbr></a>
+ and is capable of having <a title="Membership" href="#dfn-membership" class="internalDFN">members</a> whose URIs are based
+ on the content of its <a title="Containment" href="#dfn-containment" class="internalDFN">contained</a> documents rather than the URIs assigned to those documents.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-membership">Membership</dfn></dt>
+ <dd>The relationship linking an <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> (<abbr title="Linked Data Platform Containers">LDPCs</abbr> are also LDP-RSs) and its member <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
+ There often is a linked <abbr title="Linked Data Platform Container">LDPC</abbr> that assists with managing the member <abbr title="Linked Data Platform Resources">LDPRs</abbr>.<p></p></dd>
+
+ <dt><dfn id="dfn-membership-triples">Membership triples</dfn></dt>
+ <dd>A set of triples in an <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>'s state that lists its members.
+ An <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>'s membership triples all have one of the following patterns:
+ <table class="indented">
+ <tbody><tr>
+ <td style="background:#DDDDDD"> <var>membership-constant-URI</var> </td>
+ <td style="background:#FFFFFF"> <var>membership-predicate</var> </td>
+ <td style="background:#CCFFFF"> <var>member-derived-URI</var> </td>
+ </tr>
+ <tr>
+ <td style="background:#CCFFFF"> <var>member-derived-URI</var> </td>
+ <td style="background:#FFFFFF"> <var>membership-predicate</var> </td>
+ <td style="background:#DDDDDD"> <var>membership-constant-URI</var> </td>
+ </tr>
+ </tbody></table>
+ The difference between the two is simply which position member-derived-URI occupies, which is usually
+ driven by the choice of <var>membership-predicate</var>. Most predicates have a natural forward direction
+ inherent in their name, and existing vocabularies contain useful examples that read naturally in
+ each direction. <code>ldp:member</code> and <code>dcterms:isPartOf</code> are representative examples.
+ <p>
+ Each linked container exposes properties (see <a href="#ldpc-general" class="sectionRef sec-ref">section <span class="secno">5.2.1</span> <span class="sec-title">General</span></a>)
+ that allow clients to determine which pattern it
+ uses, what the actual <var>membership-predicate</var> and <var>membership-constant-URI</var> values are,
+ and (for containers that allow the creation of new members) what value is used
+ for the <var>member-derived-URI</var> based on the client's input to the
+ creation process.</p>
+ <p></p></dd>
+
+ <dt><dfn id="dfn-membership-predicate">Membership predicate</dfn></dt>
+ <dd>The predicate of all an <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>'s <a title="Membership triples" href="#dfn-membership-triples" class="internalDFN">membership triples</a>.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-containment">Containment</dfn></dt>
+ <dd>The relationship binding an <abbr title="Linked Data Platform Container">LDPC</abbr> to <abbr title="Linked Data Platform Resources">LDPRs</abbr> whose lifecycle it controls and is aware of. The
+ lifecycle of the contained <abbr title="Linked Data Platform Resource">LDPR</abbr> is limited by the lifecycle of the containing <abbr title="Linked Data Platform Container">LDPC</abbr>;
+ that is, a contained <abbr title="Linked Data Platform Resource">LDPR</abbr> cannot be created (through LDP-defined means) before its containing <abbr title="Linked Data Platform Container">LDPC</abbr> exists.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-containment-triples">Containment triples</dfn></dt>
+ <dd>
+ A set of triples in an <abbr title="Linked Data Platform Container">LDPC</abbr>'s state, maintained by the <abbr title="Linked Data Platform Container">LDPC</abbr>, that lists documents created by the <abbr title="Linked Data Platform Container">LDPC</abbr> but not yet deleted.
+ These triples <strong>always</strong> have the form: <var>( <abbr title="Linked Data Platform Container">LDPC</abbr> URI, ldp:contains , document-URI )</var>.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-empty-container-triples">Empty-container triples</dfn></dt>
+ <dd>
+ The portion of an <abbr title="Linked Data Platform Container">LDPC</abbr>'s state that would be present when the container is empty. Currently, this definition
+ is equivalent to all the <abbr title="Linked Data Platform Container">LDPC</abbr>'s triples minus its containment triples and minus its membership
+ triples, but if future versions of LDP define additional classes of triples then this definition
+ would expand to subtract out those classes as well.
+ <p></p></dd>
+ </dl>
+
+<section id="conventions" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_conventions"><span class="secno">2.1 </span>Conventions Used in This Document</h3>
+ <p>The namespace for LDP is <code>http://www.w3.org/ns/ldp#</code>.</p>
+ <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 foaf: <http://xmlns.com/foaf/0.1/>.
+ @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
+ @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="#ref" rel="bibo:Chapter"><!--OddPage--><h2 aria-level="1" role="heading" id="h2_conformance"><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>non-normative</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. Notable information from normative references: <b>non-normative</b></li>
+ <li>7. HTTP Header Definitions: <b>normative</b></li>
+ <li>8. Security Considerations: <b>non-normative</b></li>
+ <li>A. Acknowledgements: <b>non-normative</b></li>
+ <li>B. Change History: <b>non-normative</b></li>
+ <li>C.1 Normative references: <b>normative</b></li>
+ <li>C.2 Non-normative references: <b>non-normative</b></li>
+</ul>
+
+<p>A conforming <b><dfn id="dfn-ldp-client">LDP client</dfn></b> is a conforming HTTP client [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] that follows the rules defined by LDP in
+<a href="#ldpr" class="sectionRef sec-ref">section <span class="secno">4.</span> <span class="sec-title">Linked Data Platform Resources</span></a> and also
+<a href="#ldpc" class="sectionRef sec-ref">section <span class="secno">5.</span> <span class="sec-title">Linked Data Platform Containers</span></a>.
+</p>
+
+<p>A conforming <b><dfn id="dfn-ldp-server">LDP server</dfn></b> is a conforming HTTP server [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] that follows the rules defined by LDP in
+<a href="#ldpr" class="sectionRef sec-ref">section <span class="secno">4.</span> <span class="sec-title">Linked Data Platform Resources</span></a> when it is serving <abbr title="Linked Data Platform Resources">LDPRs</abbr>, and also
+<a href="#ldpc" class="sectionRef sec-ref">section <span class="secno">5.</span> <span class="sec-title">Linked Data Platform Containers</span></a> when it is serving <abbr title="Linked Data Platform Containers">LDPCs</abbr>.
+LDP does not constrain its behavior when serving other HTTP resources.
+</p>
+</section>
+
+<section id="ldpr" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<!--OddPage--><h2 aria-level="1" role="heading" id="h2_ldpr"><span class="secno">4. </span>Linked Data Platform Resources</h2>
+
+<section class="informative" id="ldpr-informative" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_ldpr-informative"><span class="secno">4.1 </span>Introduction</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 <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a>. 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 representation of a large resource broken up into pages?</li>
+ </ul>
+ <p>Additional non-normative guidance is available in the <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html" class="external" title="LDP Best Practices and Guidelines" rel="nofollow">LDP Best Practices and Guidelines editor's draft</a> that addresses
+ 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 conformance rules for LDP servers when serving <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
+ Companion non-normative documents describe additional guidelines for use when interacting with <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
+ </p>
+ <p><abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>'s representations may be too big, one strategy is to break up the response representation
+ into client consumable chunks called pages. A separate LDP specification outlines the conformance
+ rules around pagination [<cite><a class="bibref" href="#bib-LDP-PAGING">LDP-PAGING</a></cite>].
+ </p>
+ <p>An LDP server manages two kinds of <a title="Linked Data Platform Resources" href="#dfn-linked-data-platform-resources" class="internalDFN"><abbr title="Linked Data Platform Resources">LDPRs</abbr></a>, those resources who whose state
+ is represented using <abbr title="Resource Description Framework">RDF</abbr> (<abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>) and those using other formats (<abbr title="Linked Data Platform Non-RDF Source">LDP-NR</abbr>). LDP-RSs have the unique
+ quality that their representation is based on <abbr title="Resource Description Framework">RDF</abbr>, which addresses a number of use cases from web metadata, open data
+ models, machine processable information, and automated processing by software agents [<cite><a class="bibref" href="#bib-rdf11-concepts">rdf11-concepts</a></cite>]. LDP-NRs are almost anything
+ on the Web today: images, HTML pages, word processing documents, spreadsheets, etc. and LDP-RSs hold
+ metadata associated with LDP-NRs in some cases.
+ </p>
+ <figure id="fig-ldpr-types">
+ <img src="images/ldpr1.png" alt="Sample separation of Linked Data Platform Resource">
+ <figcaption>Fig. <span class="figno">1</span> <span class="fig-title">Samples of different types of <abbr title="Linked Data Platform Resources">LDPRs</abbr></span></figcaption>
+ </figure>
+ <p>The LDP-NRs and LDP-RSs are simply sub-types of <abbr title="Linked Data Platform Resources">LDPRs</abbr>, as illustrated in <a href="#fig-ldpr-class" class="fig-ref">Fig. <span class="figno">2</span> <span class="fig-title">Class relationship of types of Linked Data Platform Resources</span></a>.</p>
+ <figure id="fig-ldpr-class">
+ <img src="images/ldpr2.png" alt="Class Diagram of Linked Data Platform Resource">
+ <figcaption>Fig. <span class="figno">2</span> <span class="fig-title">Class relationship of types of Linked Data Platform Resources</span></figcaption>
+ </figure>
+
+</section>
+
+<section id="ldpr-resource" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_ldpr-resource"><span class="secno">4.2 </span>Resource</h3>
+
+<section id="ldpr-general" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpr-general"><span class="secno">4.2.1 </span>General</h4>
+
+ <section id="ldpr-gen-http" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-gen-http"><span class="secno">4.2.1.1 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <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>].
+ </h5></section><!-- Was 4.2.1 / #ldpr-4_2_1 -->
+
+ <section id="ldpr-gen-binary" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-gen-binary"><span class="secno">4.2.1.2 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="MAY">MAY</em> host a mixture of <abbr title="Linked Data Platform Resources">LDPRs</abbr>, <a title="Linked Data Platform RDF Source" href="#dfn-linked-data-platform-rdf-source" class="internalDFN">LDP-RSs</a>
+ and <a title="Linked Data Platform Non-RDF Source" href="#dfn-linked-data-platform-non-rdf-source" class="internalDFN">LDP-NRs</a>. For example, it
+ is common for <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> to need to host binary or text resources
+ that do not have useful <abbr title="Resource Description Framework">RDF</abbr> representations.</h5></section><!-- Was 4.2.3 / #ldpr-4_2_3 -->
+
+ <section id="ldpr-gen-etags" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-gen-etags"><span class="secno">4.2.1.3 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP server</a> responses <em class="rfc2119" title="MUST">MUST</em> use entity tags (either
+ weak or strong ones) as response <code>ETag</code> header values.
+ </h5></section><!-- Was 4.2.8 / #ldpr-4_2_8 -->
+
+ <section id="ldpr-gen-linktypehdr" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-gen-linktypehdr"><span class="secno">4.2.1.4 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a>
+ exposing <abbr title="Linked Data Platform Resources">LDPRs</abbr>
+ <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 <abbr title="Linked Data Platform Resource">LDPR</abbr>'s HTTP <code>Request-URI</code>.
+ </h5></section><!-- Was 4.2.10 / #ldpr-4_2_10 -->
+ <blockquote>
+ <p>
+ Note:
+ The HTTP <code>Link</code> header is the method by which servers assert their support for the LDP specification
+ on a specific resource in a way that clients can inspect dynamically at run-time.
+ This is <strong>not</strong> equivalent to the
+ presence of a <var>(subject-URI, <code>rdf:type</code>, <code>ldp:Resource</code>)</var> triple in an <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>.
+ The presence of this header asserts that the server complies with the LDP specification's constraints on
+ HTTP interactions with <abbr title="Linked Data Platform Resources">LDPRs</abbr>, that is
+ it asserts that the resource <a href="#ldpr-gen-etags">has Etags</a>, <a href="#ldprs-gen-rdf">has an <abbr title="Resource Description Framework">RDF</abbr> representation</a>, and so on,
+ which is not true of all Web resources served as <abbr title="Resource Description Framework">RDF</abbr> media types.
+ </p>
+ <p>
+ Note:
+ <a href="#ldpr-gen-binary">An LDP 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 inspected, in the absence of outside information.
+ </p>
+ </blockquote>
+
+ <section id="ldpr-gen-defbaseuri" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-gen-defbaseuri"><span class="secno">4.2.1.5 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <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.
+ </h5></section><!-- Was 4.2.12 / #ldpr-4_2_12 -->
+
+ <section id="ldpr-gen-pubclireqs" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-gen-pubclireqs"><span class="secno">4.2.1.6 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="MUST">MUST</em>
+ publish any constraints on <a title="LDP client" href="#dfn-ldp-client" class="internalDFN">LDP clients’</a> ability to
+ create or update <abbr title="Linked Data Platform Resources">LDPRs</abbr>, by adding a Link header with <code>rel='describedby'</code>
+ [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>] to all responses to requests which fail due to violation of
+ those constraints. For example, a server that refuses resource creation
+ requests via HTTP PUT, POST, or PATCH would return this <code>Link</code> header on its
+ 4xx responses to such requests.
+ The same <code>Link</code> header <em class="rfc2119" title="MAY">MAY</em> be provided on other responses. LDP neither
+ defines nor constrains the representation of the link's target resource. Natural language
+ constraint documents are therefore permitted,
+ although machine-readable ones facilitate better client interactions.
+ </h5></section><!-- Was 4.2.13 / #ldpr-4_2_13 -->
+
+</section>
+
+<section id="ldpr-HTTP_GET" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpr-HTTP_GET"><span class="secno">4.2.2 </span>HTTP GET</h4>
+ <section id="ldpr-get-must" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-get-must"><span class="secno">4.2.2.1 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="MUST">MUST</em> support the HTTP <code>GET</code> Method for <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
+ </h5></section><!-- Was 4.3.1 / #ldpr-4_3_1 -->
+
+ <section id="ldpr-get-options" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-get-options"><span class="secno">4.2.2.2 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="MUST">MUST</em> support the HTTP response headers defined in
+ <a href="#ldpr-HTTP_OPTIONS" class="sectionRef sec-ref">section <span class="secno">4.2.8</span> <span class="sec-title">HTTP OPTIONS</span></a>.
+ </h5></section><!-- Was 4.3.2 / #ldpr-4_3_2 -->
+
+</section>
+
+<section id="ldpr-HTTP_POST" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpr-HTTP_POST"><span class="secno">4.2.3 </span>HTTP POST</h4>
+ <p>
+ Per [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>], this HTTP method is optional and
+ this specification does not require <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> to support it.
+ When an LDP server supports this method,
+ this specification imposes no new requirements for <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
+ </p>
+
+ <p>Clients can create <abbr title="Linked Data Platform Resources">LDPRs</abbr> via <code>POST</code> (<a href="#ldpc-HTTP_POST" class="sectionRef sec-ref">section <span class="secno">5.2.3</span> <span class="sec-title">HTTP POST</span></a>) to an <abbr title="Linked Data Platform Container">LDPC</abbr>,
+ via <code>PUT</code> (<a href="#ldpr-HTTP_PUT" class="sectionRef sec-ref">section <span class="secno">4.2.4</span> <span class="sec-title">HTTP PUT</span></a>), or any other methods allowed
+ for HTTP resources. Any server-imposed constraints on <abbr title="Linked Data Platform Resource">LDPR</abbr> creation or update
+ <a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
+
+ </p>
+</section>
+
+<section id="ldpr-HTTP_PUT" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpr-HTTP_PUT"><span class="secno">4.2.4 </span>HTTP PUT</h4>
+ <p>
+ Per [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>], this HTTP method is optional and
+ this specification does not require <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> to support it.
+ When an LDP server supports this method,
+ this specification imposes the following new requirements for <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
+ </p>
+
+ <p>
+ Any server-imposed constraints on <abbr title="Linked Data Platform Resource">LDPR</abbr> creation or update
+ <a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
+ </p>
+
+ <section id="ldpr-put-replaceall" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-put-replaceall"><span class="secno">4.2.4.1 </span>If a HTTP <code>PUT</code> is accepted on an existing resource,
+ <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <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.
+ <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <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 <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> 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>.
+ </h5></section><!-- Was 4.5.1 / #ldpr-4_5_1 -->
+
+ <section id="ldpr-put-simpleupdate" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-put-simpleupdate"><span class="secno">4.2.4.2 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <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 enable simple creation and modification of <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
+ </h5></section><!-- Was 4.5.7 / #ldpr-4_5_7 -->
+
+ <section id="ldprs-put-servermanagedprops" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldprs-put-servermanagedprops"><span class="secno">4.2.4.3 </span>
+ If an otherwise valid HTTP <code>PUT</code> request is received
+ that attempts to change properties the server does not allow clients to modify,
+ <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="MUST">MUST</em>
+ respond with a 4xx range status code (typically
+ 409 Conflict).
+ <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="SHOULD">SHOULD</em> provide a corresponding response body containing
+ information about which properties could not be
+ persisted.
+ The format of the 4xx response body is not constrained by LDP.
+ </h5></section><!-- Was 4.5.1.1 / #ldpr-4_5_1_1 -->
+ <blockquote>
+ Non-normative note: Clients might provide properties equivalent to those already in the resource's state,
+ e.g. as part of a GET/update representation/PUT sequence, and those PUT requests are intended to work as long as the
+ server-controlled properties are identical on the GET response and the subsequent PUT request.
+ </blockquote>
+
+ <section id="ldprs-put-failed" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldprs-put-failed"><span class="secno">4.2.4.4 </span>
+ If an otherwise valid HTTP <code>PUT</code> request is received that contains properties the server
+ chooses not to persist, e.g. unknown content,
+ <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="MUST">MUST</em> respond with an appropriate 4xx range status code
+ [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>].
+ <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="SHOULD">SHOULD</em> provide a corresponding response body containing
+ information about which properties could not be
+ persisted.
+ The format of the 4xx response body is not constrained by LDP. LDP servers
+ expose these application-specific constraints as described in <a href="#ldpr-general" class="sectionRef sec-ref">section <span class="secno">4.2.1</span> <span class="sec-title">General</span></a>.
+ </h5></section><!-- Was 4.5.4 / #ldpr-4_5_4 -->
+
+ <section id="ldpr-put-precond" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-put-precond"><span class="secno">4.2.4.5 </span><a title="LDP client" href="#dfn-ldp-client" class="internalDFN">LDP clients</a> <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. <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="SHOULD">SHOULD</em> require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
+ to detect collisions. <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <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>]. <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> 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>].
+ </h5></section><!-- Was 4.5.2 / #ldpr-4_5_2 -->
+
+ <section id="ldpr-put-create" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-put-create"><span class="secno">4.2.4.6 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="MAY">MAY</em> choose to allow the creation of new resources using HTTP <code>PUT</code>.
+ </h5></section><!-- Was 4.5.6 / #ldpr-4_5_6 -->
+
+</section>
+
+<section id="ldpr-HTTP_DELETE" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpr-HTTP_DELETE"><span class="secno">4.2.5 </span>HTTP DELETE</h4>
+ <p>
+ Per [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>], this HTTP method is optional and
+ this specification does not require <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> to support it.
+ When an LDP server supports this method,
+ this specification imposes the following new requirements for <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
+ </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 sec-ref">section <span class="secno">5.2.5</span> <span class="sec-title">HTTP DELETE</span></a>.
+ </p>
+</section>
+
+<section id="ldpr-HTTP_HEAD" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpr-HTTP_HEAD"><span class="secno">4.2.6 </span>HTTP HEAD</h4>
+ <p>Note that certain LDP mechanisms 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 sections <a href="#ldpr-HTTP_GET" class="sec-ref"><span class="secno">4.2.2</span> <span class="sec-title">HTTP GET</span></a>
+ and <a href="#ldpr-HTTP_OPTIONS" class="sec-ref"><span class="secno">4.2.8</span> <span class="sec-title">HTTP OPTIONS</span></a>.</p>
+ <section id="ldpr-head-must" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-head-must"><span class="secno">4.2.6.1 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="MUST">MUST</em> support the HTTP <code>HEAD</code> method.
+ </h5></section><!-- Was 4.7.1 / #ldpr-4_7_1 -->
+</section>
+
+<section id="ldpr-HTTP_PATCH" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpr-HTTP_PATCH"><span class="secno">4.2.7 </span>HTTP PATCH</h4>
+ <p>
+ Per [<cite><a class="bibref" href="#bib-RFC5789">RFC5789</a></cite>], this HTTP method is optional and
+ this specification does not require <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> to support it.
+ When an LDP server supports this method,
+ this specification imposes the following new requirements for <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
+ </p>
+
+ <p>
+ Any server-imposed constraints on <abbr title="Linked Data Platform Resource">LDPR</abbr> creation or update
+ <a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
+ </p>
+
+ <section id="ldpr-patch-acceptpatch" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-patch-acceptpatch"><span class="secno">4.2.7.1 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> 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.
+ </h5></section><!-- Was 4.8.4 / #ldpr-4_8_4 -->
+
+</section>
+
+<section id="ldpr-HTTP_OPTIONS" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpr-HTTP_OPTIONS"><span class="secno">4.2.8 </span>HTTP OPTIONS</h4>
+ <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>,
+ add other requirements on <code>OPTIONS</code> responses.
+ </p>
+
+ <section id="ldpr-options-must" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-options-must"><span class="secno">4.2.8.1 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="MUST">MUST</em> support the HTTP <code>OPTIONS</code> method.
+ </h5></section><!-- Was 4.9.1 / #ldpr-4_9_1 -->
+
+ <section id="ldpr-options-allow" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-options-allow"><span class="secno">4.2.8.2 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <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>.
+ </h5></section><!-- Was 4.9.2 / #ldpr-4_9_2 -->
+
+</section> <!-- h2 -->
+
+</section> <!-- ldpr-resource -->
+
+<section id="ldprs" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_ldprs"><span class="secno">4.3 </span><abbr title="Resource Description Framework">RDF</abbr> Source</h3>
+
+<p>The following section contains normative clauses for <a title="" href="#dfn-linked-data-platform-rdf-source" class="internalDFN">Linked Data Platform <abbr title="Resource Description Framework">RDF</abbr> Source</a>.</p>
+
+<section id="ldprs-general" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldprs-general"><span class="secno">4.3.1 </span>General</h4>
+
+ <section id="ldprs-are-ldpr" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldprs-are-ldpr"><span class="secno">4.3.1.1 </span>Each <a title="Linked Data Platform RDF Source" href="#dfn-linked-data-platform-rdf-source" class="internalDFN">LDP <abbr title="Resource Description Framework">RDF</abbr> Source</a> <em class="rfc2119" title="MUST">MUST</em> also be
+ a conforming <a title="Linked Data Platform Resource" href="#dfn-linked-data-platform-resource" class="internalDFN">LDP Resource</a> in <a href="#ldpr-resource" class="sectionRef sec-ref">section <span class="secno">4.2</span> <span class="sec-title">Resource</span></a> along the
+ following restrictions in this section. <a title="" href="#dfn-ldp-client" class="internalDFN">LDP client</a>s <em class="rfc2119" title="MAY">MAY</em> infer the following triple:
+ whose subject is <code>ldp:RDFSource</code>,
+ whose predicate is <code>rdfs:subClassOf</code>,
+ and whose object is <code>ldp:Resource</code>,
+ but there is no requirement to materialize this triple in the <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> representation.
+ </h5></section>
+
+ <section id="ldprs-gen-atleast1rdftype" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldprs-gen-atleast1rdftype"><span class="secno">4.3.1.2 </span><a title="Linked Data Platform RDF Source" href="#dfn-linked-data-platform-rdf-source" class="internalDFN">LDP-RSs</a> 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.
+ </h5></section><!-- Was 4.2.5 / #ldpr-4_2_5 -->
+
+ <section id="ldprs-rdftype" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldprs-rdftype"><span class="secno">4.3.1.3 </span>The representation of an <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> <em class="rfc2119" title="MAY">MAY</em> have an <code>rdf:type</code>
+ of only one of <code>ldp:RDFSource</code> for <a title="" href="#dfn-linked-data-platform-rdf-source" class="internalDFN">Linked Data Platform <abbr title="Resource Description Framework">RDF</abbr> Source</a>.
+ </h5></section><!-- Was 5.2.7 / #ldpc-5_2_7 -->
+
+ <section id="ldprs-gen-rdf" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldprs-gen-rdf"><span class="secno">4.3.1.4 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="MUST">MUST</em> provide an <abbr title="Resource Description Framework">RDF</abbr> representation for <a title="Linked Data Platform RDF Source" href="#dfn-linked-data-platform-rdf-source" class="internalDFN">LDP-RSs</a>.
+ The HTTP <code>Request-URI</code> of the <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> is typically the subject of most triples in the response.
+ </h5></section><!-- Was 4.2.2 / #ldpr-4_2_2 -->
+
+ <section id="ldprs-gen-reusevocab" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldprs-gen-reusevocab"><span class="secno">4.3.1.5 </span><a title="Linked Data Platform RDF Source" href="#dfn-linked-data-platform-rdf-source" class="internalDFN">LDP-RSs</a> <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.
+ </h5></section><!-- Was 4.2.4 / #ldpr-4_2_4 -->
+
+ <section id="ldprs-gen-reusevocabsuchas" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldprs-gen-reusevocabsuchas"><span class="secno">4.3.1.6 </span><a title="Linked Data Platform RDF Source" href="#dfn-linked-data-platform-rdf-source" class="internalDFN">LDP-RSs</a> 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-rdf11-concepts">rdf11-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.
+ </h5></section><!-- Was 4.2.4.1 / #ldpr-4_2_4_1 -->
+
+ <section id="ldp-cli-multitype" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldp-cli-multitype"><span class="secno">4.3.1.7 </span>In the absence of special knowledge of the application or domain,
+ <a title="LDP client" href="#dfn-ldp-client" class="internalDFN">LDP clients</a> <em class="rfc2119" title="MUST">MUST</em> assume that any <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> can have multiple values for <code>rdf:type</code>.
+ </h5></section> <!-- Was 4.3.5 / #ldpr-4_3_5 -->
+
+ <section id="ldpr-cli-typeschange" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-cli-typeschange"><span class="secno">4.3.1.8 </span>In the absence of special knowledge of the application or domain,
+ <a title="LDP client" href="#dfn-ldp-client" class="internalDFN">LDP clients</a> <em class="rfc2119" title="MUST">MUST</em> assume that the <code>rdf:type</code> values
+ of a given <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> can change over time.
+ </h5></section> <!-- Was 4.3.6 / #ldpr-4_3_6 -->
+
+ <section id="ldpr-cli-openpreds" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-cli-openpreds"><span class="secno">4.3.1.9 </span><a title="LDP client" href="#dfn-ldp-client" class="internalDFN">LDP clients</a> <em class="rfc2119" title="SHOULD">SHOULD</em> always assume that the set of predicates for a
+ <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> 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 <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> is not limited to any pre-defined
+ set.
+ </h5></section> <!-- Was 4.5.3 / #ldpr-ldpr-4_5_3 -->
+
+ <section id="ldprs-gen-noinferencing" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldprs-gen-noinferencing"><span class="secno">4.3.1.10 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a>
+ <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-rdf11-concepts">rdf11-concepts</a></cite>]. The practical implication is that all content defined by LDP
+ must be explicitly represented, unless noted otherwise within this document.
+ </h5></section><!-- Was 4.2.11 / #ldpr-4_2_11 -->
+
+ <section id="ldpr-cli-preservetriples" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-cli-preservetriples"><span class="secno">4.3.1.11 </span>
+ A <a title="LDP client" href="#dfn-ldp-client" class="internalDFN">LDP client</a> <em class="rfc2119" title="MUST">MUST</em> preserve all triples retrieved from an <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> 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>].
+ </h5></section> <!-- Was 4.5.5 / #ldpr-ldpr-4_5_5 -->
+
+ <section id="ldpr-cli-can-hint" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-cli-can-hint"><span class="secno">4.3.1.12 </span>
+ <a title="LDP client" href="#dfn-ldp-client" class="internalDFN">LDP clients</a> <em class="rfc2119" title="MAY">MAY</em>
+ provide LDP-defined hints that allow servers to optimize the content of responses.
+ <a href="#prefer-parameters" class="sectionRef sec-ref">section <span class="secno">7.2</span> <span class="sec-title">Preferences on the Prefer Request Header</span></a> defines hints that apply to
+ <a title="Linked Data Platform RDF Source" href="#dfn-linked-data-platform-rdf-source" class="internalDFN">LDP-RSs</a>.
+ </h5></section>
+
+ <section id="ldpr-cli-hints-ignorable" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-cli-hints-ignorable"><span class="secno">4.3.1.13 </span>
+ <a title="LDP client" href="#dfn-ldp-client" class="internalDFN">LDP clients</a> <em class="rfc2119" title="MUST">MUST</em>
+ be capable of processing responses formed by an LDP server that ignores hints,
+ including LDP-defined hints.
+ </h5></section>
+
+ <div class="atrisk" id="atrisk-paging"><p class="atrisktext">Feature At Risk</p>
+ <p>The LDP Working Group proposes incorporation of the following clause to make LDP clients paging aware:</p>
+ <section id="ldpr-cli-paging" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-cli-paging"><span class="secno">4.3.1.14 </span>
+ <a title="LDP client" href="#dfn-ldp-client" class="internalDFN">LDP clients</a> <em class="rfc2119" title="SHOULD">SHOULD</em>
+ be capable of processing successful HTTP <code>GET</code> responses formed by an LDP server
+ that independently initiated paging, returning a page of representation instead of full resource
+ representation [<cite><a class="bibref" href="#bib-LDP-PAGING">LDP-PAGING</a></cite>].
+ </h5>
+ </section>
+ </div>
+
+</section> <!-- ldprs-general -->
+
+<section id="ldprs-HTTP_GET" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldprs-HTTP_GET"><span class="secno">4.3.2 </span>HTTP GET</h4>
+ <section id="ldprs-get-turtle" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldprs-get-turtle"><span class="secno">4.3.2.1 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="MUST">MUST</em> provide a <code>text/turtle</code>
+ representation of the requested <a title="Linked Data Platform RDF Source" href="#dfn-linked-data-platform-rdf-source" class="internalDFN"><abbr title="Linked Data Platform RDF Source">LDP-RS</abbr></a> [<cite><a class="bibref" href="#bib-turtle">turtle</a></cite>].
+ </h5></section><!-- Was 4.3.3 / #ldpr-4_3_3 -->
+
+</section> <!-- ldprs-HTTP_GET -->
+
+</section> <!-- ldprs RDF Source-->
+
+<section id="ldpnr" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_ldpnr"><span class="secno">4.4 </span>Non-<abbr title="Resource Description Framework">RDF</abbr> Source</h3>
+
+<p>The following section contains normative clauses for <a title="" href="#dfn-linked-data-platform-non-rdf-source" class="internalDFN">Linked Data Platform Non-<abbr title="Resource Description Framework">RDF</abbr> Source</a>.</p>
+
+<section id="ldpnr-general" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpnr-general"><span class="secno">4.4.1 </span>General</h4>
+
+ <section id="ldpnr-are-ldpr" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpnr-are-ldpr"><span class="secno">4.4.1.1 </span>Each <a title="Linked Data Platform Non-RDF Source" href="#dfn-linked-data-platform-non-rdf-source" class="internalDFN">LDP Non-<abbr title="Resource Description Framework">RDF</abbr> Source</a> <em class="rfc2119" title="MUST">MUST</em> also be
+ a conforming <a title="Linked Data Platform Resource" href="#dfn-linked-data-platform-resource" class="internalDFN">LDP Resource</a> in <a href="#ldpr-resource" class="sectionRef sec-ref">section <span class="secno">4.2</span> <span class="sec-title">Resource</span></a>.
+ <a title="Linked Data Platform Non-RDF Source" href="#dfn-linked-data-platform-non-rdf-source" class="internalDFN">LDP Non-<abbr title="Resource Description Framework">RDF</abbr> Source</a> may not be able to fully express their
+ state using <abbr title="Resource Description Framework">RDF</abbr>. [<cite><a class="bibref" href="#bib-rdf11-concepts">rdf11-concepts</a></cite>]
+ </h5></section>
+
+</section> <!-- ldpnr Non-RDF Source-->
+
+</section>
+
+</section> <!-- ldpr h1 -->
+
+<section id="ldpc" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<!--OddPage--><h2 aria-level="1" role="heading" id="h2_ldpc"><span class="secno">5. </span>Linked Data Platform Containers</h2>
+
+<section class="informative" id="ldpc-informative" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_ldpc-informative"><span class="secno">5.1 </span>Introduction</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 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>
+ <li>How is the order of the container entries expressed? [<cite><a class="bibref" href="#bib-LDP-PAGING">LDP-PAGING</a></cite>]</li>
+ </ol>
+ <p>
+ This document defines the representation and behavior of containers
+ that address these issues. There are multiple types of containers defined
+ to support a variety of use cases, all that support a base set of capabilities.
+ The contents of a container is
+ defined by a set of triples in its representation (and state) called
+ the <a title="Containment triples" href="#dfn-containment-triples" class="internalDFN">containment triples</a> that follow a fixed pattern.
+ Additional types of containers allow for the set of members of a container to be
+ defined by a set of triples in its representation called
+ the <a title="Membership triples" href="#dfn-membership-triples" class="internalDFN">membership triples</a> that follow a consistent pattern
+ (see the linked-to definition for the possible patterns).
+ The membership triples of a container all
+ have the same predicate, called the membership predicate,
+ and either the subject or the object is also a consistent value
+ – the remaining position of the membership
+ triples (the one that varies) define the members of the container.
+ In the simplest cases, the
+ consistent value will be the <abbr title="Linked Data Platform Container">LDPC</abbr> resource's URI, 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>ldp:member</code> predicate.
+ </p>
+ <p>This document includes a set of guidelines for
+ creating new resources and adding them to the list of
+ resources linked to a container. It goes on to explain how to learn about a set of related
+ resources, regardless of how they were created or added to the container's membership.
+ It also defines behavior when resources created using a container are later deleted;
+ deleting containers removes membership information and
+ possibly performs 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 1</span></div><pre class="example" id="ldpc-ex-simple"># The following is the representation of
+# http://example.org/c1/
+<!-- @base is here only so it's easier to paste into validators for checking -->
+# @base <http://example.org/c1/>
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<>
+ a ldp:BasicContainer;
+ dcterms:title "A very simple container";
+ ldp:contains <r1>, <r2>, <r3>.</pre></div>
+
+ <!-- TODO: consider if basic container diagram helps, if so...add for other cases too
+ <figure id="fig-ldpc-basic">
+ <img src="images/ldpc-basic.png" alt="Sample Linked Data Platform Basic Container" />
+ <figcaption>Sample of Linked Data Platform Basic Container</figcaption>
+ </figure>
+ -->
+
+ <p>This example is very straightforward - there is the containment triple
+ with subject of the container, predicate of
+ <code>ldp:contains</code> and objects indicating the URIs of the contained resources.
+ A POST to this container will create a new resource
+ and add it to the list of contained resources by adding a new containment triple
+ to the container. This type of container is also referred to as
+ <a title="" href="#dfn-linked-data-platform-basic-container" class="internalDFN">Linked Data Platform Basic Container</a>.</p>
+
+ <p>Sometimes it is useful to use a subject
+ other than the container itself as the consistent membership value, and/or to use
+ a predicate from an application's domain model 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 2</span></div><pre class="example" id="ldpc-ex-membership-partial"># The following is a partial representation of
+# http://example.org/netWorth/nw1
+<!-- @base is here only so it's easier to paste into validators for checking -->
+# @base <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 in the set of related examples (one example per HTTP resource) below:
+ </p>
+
+<div class="example"><div class="example-title"><span>Example 3</span></div><pre class="example" id="ldpc-ex-membership-full"># The following is an elaborated representation of LDPR
+# http://example.org/netWorth/nw1
+<!-- @base is here only so it's easier to paste into validators for checking -->
+# @base <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>.</pre></div>
+
+<div class="example"><div class="example-title"><span>Example 4</span></div><pre class="example" id="ldpc-ex-membership-subj"># The following is an elaborated representation of LDPC
+# http://example.org/netWorth/nw1/assetContainer/
+<!-- @base is here only so it's easier to paste into validators for checking -->
+# @base <http://example.org/netWorth/nw1/assetContainer/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix o: <http://example.org/ontology/>.
+<>
+ a ldp:DirectContainer;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:membershipResource <http://example.org/netWorth/nw1/>;
+ ldp:hasMemberRelation o:asset;
+ ldp:contains <a1>, <a2>.</pre></div>
+
+<div class="example"><div class="example-title"><span>Example 5</span></div><pre class="example" id="ldpc-ex-membership-full-liabcont"># The following is an elaborated representation of LDPC
+# http://example.org/netWorth/nw1/liabilityContainer/
+<!-- @base is here only so it's easier to paste into validators for checking -->
+# @base <http://example.org/netWorth/nw1/liabilityContainer/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix o: <http://example.org/ontology/>.
+<>
+ a ldp:DirectContainer;
+ dcterms:title "The liabilities of JohnZSmith";
+ ldp:membershipResource <http://example.org/netWorth/nw1/>;
+ ldp:hasMemberRelation o:liability;
+ ldp:contains <l1>, <l2>, <l3>.</pre></div>
+
+ <p>The essential structure of the container is
+ the same, but in this example, the consistent membership value
+ (<a title="Membership triples" href="#dfn-membership-triples" class="internalDFN">membership-constant-URI</a>, still in the subject position) 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 resource and containment 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>
+ <p>This type of container is referred to as an <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Container</a>.
+ <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Container</a> adds the concept of <a title="Membership" href="#dfn-membership" class="internalDFN">membership</a>
+ and flexibilty on how to specify the <a title="Membership triples" href="#dfn-membership-triples" class="internalDFN">membership triples</a>.
+ </p>
+
+ <p>As seen in the <a href="#ldpc-ex-membership-subj"><code>assetContainer/</code> example</a>,
+ clients cannot correctly guess
+ at the membership triples, so the example includes this information in
+ triples whose subject is the <abbr title="Linked Data Platform Container">LDPC</abbr> resource itself.
+ </p>
+
+ <p>Alternatively, servers may provide the net worth resource and supporting containers in a single response
+ representations. When doing this, a preference would be for <abbr title="Resource Description Framework">RDF</abbr> formats that support multiple named graphs, one
+ named graph for the net worth resource and then two others for asset and liability containers. This allows for
+ the membership triples to be represented with the named graph for the net worth resource, while the containment triples
+ would be represented within the liability and asset containers [<cite><a class="bibref" href="#bib-rdf11-concepts">rdf11-concepts</a></cite>]. Generally, the membership triples belong
+ to the representation of an <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> and the containment triples belong to the representation of the <abbr title="Linked Data Platform Container">LDPC</abbr>.
+ </p>
+
+ <p>Additionally, we could extend our net worth example to include a container for
+ advisors (people) that have managed the assets and liabilities. We have decided
+ to identify these advisors with URLs that contain a fragment (hash) to represent
+ these real-world resources, not the documents that describe them.</p>
+
+<div class="example"><div class="example-title"><span>Example 6</span></div><pre class="example" id="ldpc-ex-membership-full-elab"># The following is an elaborated representation of
+# http://example.org/netWorth/nw1
+# Adding o:advisor but eaving off o:asset and o:liability for brevity.
+<!-- @base is here only so it's easier to paste into validators for checking -->
+# @base <http://example.org/netWorth/nw1/>
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix foaf: <http://xmlns.com/foaf/0.1/>.
+@prefix o: <http://example.org/ontology/>.
+<>
+ a o:NetWorth;
+ o:netWorthOf <http://example.org/users/JohnZSmith>;
+ o:advisor
+ <advisorContainer/bob#me>,
+ <advisorContainer/marsha#me>.
+
+<advisorContainer/>
+ a ldp:IndirectContainer;
+ dcterms:title "The asset advisors of JohnZSmith";
+ ldp:membershipResource <>;
+ ldp:hasMemberRelation o:advisor;
+ ldp:insertedContentRelation foaf:primaryTopic;
+ ldp:contains
+ <advisorContainer/bob>,
+ <advisorContainer/marsha>.</pre></div>
+
+ <p>To handle this type of indirection, the triple with predicate of <code>ldp:insertedContentRelation</code> and object of
+ <code>foaf:primaryTopic</code> informs clients that when POSTing to this container, they need to include a triple of the
+ form <code>(<>, foaf:primaryTopic, topic-URI)</code> to inform the server which URI to use
+ (<code>topic-URI</code>) in the new membership triple.</p>
+
+ <p>This type of container is also referred to as a <a title="Linked Data Platform Indirect Container" href="#dfn-linked-data-platform-indirect-container" class="internalDFN">LDP Indirect Container</a>.
+ It is similar to an <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Container</a>
+ but it provides an indirection to add (via a create request) as member any resource,
+ such as a URI representing a real-world object,
+ that is different from the document that is created.</p>
+
+ <p><a href="#fig-ldpc-types" class="fig-ref">Fig. <span class="figno">3</span> <span class="fig-title">Class relationship of types of Linked Data Platform Containers</span></a> illustrates the 3 types: Container, Basic Container and Direct Container, along
+ with their class relationship to types of <abbr title="Linked Data Platform Resources">LDPRs</abbr>.</p>
+
+ <figure id="fig-ldpc-types">
+ <img src="images/ldpc-hierarchy.png" alt="Types of Linked Data Platform Containers">
+ <figcaption>Fig. <span class="figno">3</span> <span class="fig-title">Class relationship of types of Linked Data Platform Containers</span></figcaption>
+ </figure>
+
+ <p>The following table illustrates some differences between <a title="membership" href="#dfn-membership" class="internalDFN">membership</a> and
+ <a title="containment" href="#dfn-containment" class="internalDFN">containment</a> triples. For details on the normative behavior, see appropriate sections
+ below.
+ </p>
+ <table style="border: 1px solid gray" id="ldpc-mbrcntdiff">
+ <thead><tr><th rowspan="2">Completed Request</th><th colspan="2">Effects</th></tr>
+ <tr class="oddrow"><th>Membership</th><th>Containment</th></tr></thead>
+ <tbody><tr><td><abbr title="Linked Data Platform Resource">LDPR</abbr> created in <abbr title="Linked Data Platform Basic Container">LDP-BC</abbr></td><td>New triple: (<abbr title="Linked Data Platform Container">LDPC</abbr>, ldp:contains, <abbr title="Linked Data Platform Resource">LDPR</abbr>)</td><td>Same</td></tr>
+ <tr><td><abbr title="Linked Data Platform Resource">LDPR</abbr> created in <abbr title="Linked Data Platform Direct Container">LDP-DC</abbr></td><td>New triple links <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> to created <abbr title="Linked Data Platform Resource">LDPR</abbr>. <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> URI may be same as <abbr title="Linked Data Platform Direct Container">LDP-DC</abbr></td>
+ <td>New triple: (<abbr title="Linked Data Platform Container">LDPC</abbr>, ldp:contains, <abbr title="Linked Data Platform Resource">LDPR</abbr>)</td></tr>
+ <tr><td><abbr title="Linked Data Platform Resource">LDPR</abbr> created in <abbr title="Linked Data Platform Indirect Container">LDP-IC</abbr></td><td>New triple links <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> to content indicated URI</td>
+ <td>New triple: (<abbr title="Linked Data Platform Container">LDPC</abbr>, ldp:contains, <abbr title="Linked Data Platform Resource">LDPR</abbr>)</td></tr>
+ <tr><td><abbr title="Linked Data Platform Resource">LDPR</abbr> is deleted</td><td>Membership triple may be removed</td><td>(<abbr title="Linked Data Platform Container">LDPC</abbr>, ldp:contains, <abbr title="Linked Data Platform Resource">LDPR</abbr>) triple is removed
+ </td></tr>
+ <tr><td><abbr title="Linked Data Platform Container">LDPC</abbr> is deleted</td><td>Triples and member resources may be removed</td><td>Triples of form
+ (<abbr title="Linked Data Platform Container">LDPC</abbr>, ldp:contains, <abbr title="Linked Data Platform Resource">LDPR</abbr>) and contained <abbr title="Linked Data Platform Resources">LDPRs</abbr> may be removed</td></tr>
+ </tbody></table>
+
+<section id="ldpc-get_empty-container_props" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpc-get_empty-container_props"><span class="secno">5.1.1 </span>Retrieving Only Empty-Container Triples
+ </h4><!-- Was 5.1.1 / #ldpc-get_empty-container_props -->
+ <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 subset of the container's properties
+ that are unrelated to member resources and unrelated to contained documents, for
+ example to determine the membership triple pattern and membership predicate of an
+ <abbr title="Linked Data Platform Direct Container">LDP-DC</abbr>. LDP calls these <a title="Empty-container triples" href="#dfn-empty-container-triples" class="internalDFN">empty-container triples</a>,
+ because they are what remains when the container has zero members and zero contained resources.
+ Since retrieving the whole container representation to
+ get this information may be onerous for clients and cause unnecessary
+ overhead on servers, we define a way to retrieve only
+ these property values (and more generally, a way to retrieve only the
+ subset of properties used to address other major clusters of use cases).
+ LDP adds parameters to the HTTP <code>Prefer</code> header's
+ <code>return=representation</code> preference for this
+ (see <a href="#prefer-parameters" class="sectionRef sec-ref">section <span class="secno">7.2</span> <span class="sec-title">Preferences on the Prefer Request Header</span></a> for details).
+ </p>
+ <p>The example listed here only shows
+ a simple case where few empty-container triples 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-sparql11-query">sparql11-query</a></cite>]</p>
+ <p>
+ Here is an example requesting the empty-container triples of a
+ container identified by the URL <code>http://example.org/container1/</code>.
+ </p>
+<p id="ldpc-ex-empty-container">Request:</p>
+<div class="example"><div class="example-title"><span>Example 7</span></div><pre class="example">GET /container1 HTTP/1.1
+Host: example.org
+Accept: text/turtle; charset=UTF-8
+Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferEmptyContainer"</pre></div>
+<p>Response:</p>
+<div class="example"><div class="example-title"><span>Example 8</span></div><pre class="example">HTTP/1.1 200 OK
+Content-Type: text/turtle; charset=UTF-8
+ETag: "_87e52ce291112"
+Content-Length: 325
+Link: <http://www.w3.org/ns/ldp#Container>; rel="type"
+Preference-Applied: return=representation
+
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<http://example.org/container1/>
+ a ldp:DirectContainer;
+ dcterms:title "A Linked Data Platform Container of Acme Resources";
+ ldp:membershipResource <http://example.org/container1/>;
+ ldp:hasMemberRelation ldp:member;
+ ldp:insertedContentRelation ldp:MemberSubject;
+ dcterms:publisher <http://acme.com/>.</pre></div>
+
+ <p>
+ LDP recommends using PATCH to update these properties, if necessary. It provides no facility
+ for updating them via PUT without replacing the entire container's state.
+ </p>
+ </section><!-- ldpc-get_empty-container_props -->
+
+</section>
+
+<section id="ldpc-container" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_ldpc-container"><span class="secno">5.2 </span>Container</h3>
+<p>The following section contains normative clauses for <a title="" href="#dfn-linked-data-platform-container" class="internalDFN">Linked Data Platform Container</a>.</p>
+
+<section id="ldpc-general" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpc-general"><span class="secno">5.2.1 </span>General</h4>
+ <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>
+
+ <section id="ldpc-isldpr" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-isldpr"><span class="secno">5.2.1.1 </span>Each <a title="" href="#dfn-linked-data-platform-container" class="internalDFN">Linked Data Platform Container</a> <em class="rfc2119" title="MUST">MUST</em> also be
+ a conforming <a title="" href="#dfn-linked-data-platform-rdf-source" class="internalDFN">Linked Data Platform <abbr title="Resource Description Framework">RDF</abbr> Source</a>. <a title="" href="#dfn-ldp-client" class="internalDFN">LDP client</a>s <em class="rfc2119" title="MAY">MAY</em> infer the following triple:
+ whose subject is <code>ldp:Container</code>,
+ whose predicate is <code>rdfs:subClassOf</code>,
+ and whose object is <code>ldp:RDFSource</code>,
+ but there is no requirement to materialize this triple in the <abbr title="Linked Data Platform Container">LDPC</abbr> representation.
+ </h5></section><!-- Was 5.2.1 / #ldpc-5_2_1 -->
+
+ <section id="ldpc-typecontainer" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-typecontainer"><span class="secno">5.2.1.2 </span>The representation of an <abbr title="Linked Data Platform Container">LDPC</abbr> <em class="rfc2119" title="MAY">MAY</em> have an <code>rdf:type</code>
+ of only one of <code>ldp:Container</code> for <a title="" href="#dfn-linked-data-platform-container" class="internalDFN">Linked Data Platform Container</a>.
+ Non-normative note: <a href="#ldp-rdfconcepts-extra-triples-types"><abbr title="Linked Data Platform Containers">LDPCs</abbr>
+ might have additional types</a>, like any <a title="Linked Data Platform RDF Source" href="#dfn-linked-data-platform-rdf-source" class="internalDFN"><abbr title="Linked Data Platform RDF Source">LDP-RS</abbr></a>.
+ </h5></section><!-- Was 5.2.7 / #ldpc-5_2_7 -->
+
+ <section id="ldpc-nordfcontainertypes" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-nordfcontainertypes"><span class="secno">5.2.1.3 </span><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>.
+ </h5></section><!-- Was 5.2.8 / #ldpc-5_2_8 -->
+
+ <section id="ldpc-linktypehdr" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-linktypehdr"><span class="secno">5.2.1.4 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a>
+ exposing <abbr title="Linked Data Platform Containers">LDPCs</abbr>
+ <em class="rfc2119" title="MUST">MUST</em> advertise their LDP support by exposing a HTTP <code>Link</code> header
+ with a target URI matching the type of container (see below) the
+ server supports, and
+ a link relation type of <code>type</code> (that is, <code>rel='type'</code>)
+ in all responses to requests made
+ to the <abbr title="Linked Data Platform Container">LDPC</abbr>'s HTTP <code>Request-URI</code>.
+ <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="MAY">MAY</em> provide additional HTTP <code>Link: rel='type'</code> headers.
+ The <a href="#ldpr-gen-linktypehdr">notes on the corresponding <abbr title="Linked Data Platform Resource">LDPR</abbr> constraint</a> apply
+ equally to <abbr title="Linked Data Platform Containers">LDPCs</abbr>.
+ </h5>
+ <p>Valid container type URIs for <code>rel='type'</code> defined by this document are:
+ </p><ul>
+ <li><code>http://www.w3.org/ns/ldp#BasicContainer</code> - for <a href="#ldpbc">LDP Basic Containers</a></li>
+ <li><code>http://www.w3.org/ns/ldp#DirectContainer</code> - for <a href="#ldpdc">LDP Direct Containers</a></li>
+ <li><code>http://www.w3.org/ns/ldp#IndirectContainer</code> - for <a href="#ldpic">LDP Indirect Containers</a></li>
+ </ul>
+ <p></p>
+ </section><!-- Was 5.2.11 / #ldpc-5_2_11 -->
+
+ <section id="ldpc-prefer" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-prefer"><span class="secno">5.2.1.5 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a>
+ <em class="rfc2119" title="SHOULD">SHOULD</em> respect all of a client's LDP-defined hints, for example
+ <a href="#prefer-parameters">which subsets of LDP-defined state</a>
+ the client is interested in processing,
+ to influence the set of triples returned in representations of an <abbr title="Linked Data Platform Container">LDPC</abbr>,
+ particularly for large <abbr title="Linked Data Platform Containers">LDPCs</abbr>. See also [<cite><a class="bibref" href="#bib-LDP-PAGING">LDP-PAGING</a></cite>].
+ </h5></section>
+
+</section>
+
+<section id="ldpc-HTTP_GET" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpc-HTTP_GET"><span class="secno">5.2.2 </span>HTTP GET</h4>
+ <p>
+ Per <a href="#ldpr-HTTP_GET" class="sectionRef sec-ref">section <span class="secno">4.2.2</span> <span class="sec-title">HTTP GET</span></a> the HTTP GET method is required and
+ additional requirements can be found in <a href="#ldpc-general" class="sectionRef sec-ref">section <span class="secno">5.2.1</span> <span class="sec-title">General</span></a>.
+ </p>
+
+</section>
+
+<section id="ldpc-HTTP_POST" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpc-HTTP_POST"><span class="secno">5.2.3 </span>HTTP POST</h4>
+ <p>
+ Per [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>], this HTTP method is optional and
+ this specification does not require <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> to support it.
+ When an LDP server supports this method,
+ this specification imposes the following new requirements for <abbr title="Linked Data Platform Containers">LDPCs</abbr>.
+ </p>
+
+ <p>
+ Any server-imposed constraints on creation or update
+ <a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
+ </p>
+
+ <section id="ldpc-post-created201" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-post-created201"><span class="secno">5.2.3.1 </span><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, <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <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.
+ </h5></section><!-- Was 5.4.1 / #ldpc-5_4_1 -->
+
+ <section id="ldpc-post-createdmbr-contains" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-post-createdmbr-contains"><span class="secno">5.2.3.2 </span>
+ When a successful HTTP <code>POST</code> request to an <abbr title="Linked Data Platform Container">LDPC</abbr> results in the creation of an <abbr title="Linked Data Platform Resource">LDPR</abbr>, a
+ <a title="Containment triples" href="#dfn-containment-triples" class="internalDFN">containment triple</a> <em class="rfc2119" title="MUST">MUST</em> be added to the state of <abbr title="Linked Data Platform Container">LDPC</abbr>. The
+ <a title="Containment triples" href="#dfn-containment-triples" class="internalDFN">containment triple</a> whose subject is the <abbr title="Linked Data Platform Container">LDPC</abbr> URI,
+ whose predicate is <code>ldp:contains</code> and whose object is the URI for the newly created document (<abbr title="Linked Data Platform Resource">LDPR</abbr>).
+ The newly created <abbr title="Linked Data Platform Resource">LDPR</abbr> appears as a contained resource of the <abbr title="Linked Data Platform Container">LDPC</abbr> until the
+ newly created document is deleted or removed by other methods. Other triples may be added as well.
+ </h5></section>
+
+ <section id="ldpc-post-createbins" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-post-createbins"><span class="secno">5.2.3.3 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="MAY">MAY</em> accept an HTTP <code>POST</code> of non-<abbr title="Resource Description Framework">RDF</abbr> representations
+ <a title="Linked Data Platform Non-RDF Source" href="#dfn-linked-data-platform-non-rdf-source" class="internalDFN">(LDP-NRs)</a> for
+ creation of any kind of resource, for example binary resources. See <a href="#ldpc-post-acceptposthdr">the Accept-Post section</a> for
+ details on how clients can discover whether an <abbr title="Linked Data Platform Container">LDPC</abbr> supports this behavior.
+ </h5></section><!-- Was 5.4.3 / #ldpc-5_4_3 -->
+
+ <section id="ldpc-post-createrdf" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-post-createrdf"><span class="secno">5.2.3.4 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> that successfully create a resource from a
+ <abbr title="Resource Description Framework">RDF</abbr> representation in the request entity body <em class="rfc2119" title="MUST">MUST</em> honor the client's requested interaction model(s). The created resource
+ can be thought of as an <abbr title="Resource Description Framework">RDF</abbr> <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [<cite><a class="bibref" href="#bib-rdf11-concepts">rdf11-concepts</a></cite>].
+ If any model cannot be honored, the server <em class="rfc2119" title="MUST">MUST</em> fail the request.
+ </h5><!-- Was 5.4.4 / #ldpc-5_4_4 -->
+ <ul>
+ <li>If the request header <a href="#ldpr-gen-linktypehdr">specifies an <abbr title="Linked Data Platform Resource">LDPR</abbr> interaction model</a>, then the server <em class="rfc2119" title="MUST">MUST</em> handle subsequent
+ requests to the newly created resource's URI as if it is an <abbr title="Linked Data Platform Resource">LDPR</abbr>.
+ (even if the content contains an <code>rdf:type</code> triple indicating a type of <abbr title="Linked Data Platform Container">LDPC</abbr>).</li>
+ <li>If the request header <a href="#ldpc-linktypehdr">specifies an <abbr title="Linked Data Platform Container">LDPC</abbr> interaction model</a>, then the server <em class="rfc2119" title="MUST">MUST</em> handle subsequent
+ requests to the newly created resource's URI as if it is an <abbr title="Linked Data Platform Container">LDPC</abbr>.
+ </li>
+ <li>This specification does not constrain the server's behavior in other cases.</li>
+ </ul>
+ <p>Note: A consequence of this is that <abbr title="Linked Data Platform Containers">LDPCs</abbr> can be used to create <abbr title="Linked Data Platform Containers">LDPCs</abbr>, if the server supports doing so.</p>
+ </section>
+
+ <section id="ldpc-post-turtle" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-post-turtle"><span class="secno">5.2.3.5 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <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>].
+ </h5></section><!-- Was 5.4.5 / #ldpc-5_4_5 -->
+
+ <section id="ldpc-post-contenttype" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-post-contenttype"><span class="secno">5.2.3.6 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <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.
+ </h5></section><!-- Was 5.4.6 / #ldpc-5_4_6 -->
+
+ <section id="ldpc-post-rdfnullrel" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-post-rdfnullrel"><span class="secno">5.2.3.7 </span>In <abbr title="Resource Description Framework">RDF</abbr> representations, <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <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.
+ </h5></section><!-- Was 5.4.7 / #ldpc-5_4_7 -->
+
+ <section id="ldpc-post-serverassignuri" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-post-serverassignuri"><span class="secno">5.2.3.8 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="SHOULD">SHOULD</em> assign the URI for the resource to be
+ created using server application specific rules in the absence of a <a href="#ldpc-post-slug">client hint</a>.
+ </h5></section><!-- Was 5.4.8 / #ldpc-5_4_8 -->
+
+ <section id="ldpc-post-mincontraints" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-post-mincontraints"><span class="secno">5.2.3.9 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <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 enable simple creation and modification of <abbr title="Linked Data Platform Resources">LDPRs</abbr>. LDP servers
+ expose these application-specific constraints as described in <a href="#ldpr-general" class="sectionRef sec-ref">section <span class="secno">4.2.1</span> <span class="sec-title">General</span></a>.
+ </h5></section><!-- Was 5.4.9 / #ldpc-5_4_9 -->
+
+ <section id="ldpc-post-slug" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-post-slug"><span class="secno">5.2.3.10 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <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.
+ </h5></section><!-- Was 5.4.10 / #ldpc-5_4_10 -->
+
+ <section id="ldpc-post-dontreuseuris" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-post-dontreuseuris"><span class="secno">5.2.3.11 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> that allow member creation via <code>POST</code>
+ <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> re-use URIs.
+ </h5></section><!-- Was 5.4.11 / #ldpc-5_4_11 -->
+
+ <section id="ldpc-post-createbinlinkmetahdr" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-post-createbinlinkmetahdr"><span class="secno">5.2.3.12 </span>Upon successful creation of an
+ <a title="Linked Data Platform Non-RDF Source" href="#dfn-linked-data-platform-non-rdf-source" class="internalDFN"><abbr title="Linked Data Platform Non-RDF Source">LDP-NR</abbr></a> (HTTP status code of
+ 201-Created and URI indicated by <code>Location</code> response header), <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="MAY">MAY</em> create an associated
+ <a title="Linked Data Platform RDF Source" href="#dfn-linked-data-platform-rdf-source" class="internalDFN"><abbr title="Linked Data Platform RDF Source">LDP-RS</abbr></a>
+ to contain data about the newly created <abbr title="Linked Data Platform Non-RDF Source">LDP-NR</abbr>. If an <abbr title="Linked Data Platform Container">LDPC</abbr> server creates this associated <a title="Linked Data Platform RDF Source" href="#dfn-linked-data-platform-rdf-source" class="internalDFN"><abbr title="Linked Data Platform RDF Source">LDP-RS</abbr></a> it <em class="rfc2119" title="MUST">MUST</em> indicate
+ its location on the HTTP response using the HTTP <code>Link</code> response header with link relation <code>describedby</code>
+ and <code>href</code> to be the URI of the associated <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> resource [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>].
+ </h5></section><!-- Was 5.4.12 / #ldpc-5_4_12 -->
+
+ <section id="ldpc-post-acceptposthdr" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-post-acceptposthdr"><span class="secno">5.2.3.13 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> 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.
+ </h5></section><!-- Was 5.4.13 / #ldpc-5_4_13 -->
+
+</section>
+
+<section id="ldpc-HTTP_PUT" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpc-HTTP_PUT"><span class="secno">5.2.4 </span>HTTP PUT</h4>
+ <p>
+ Per [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>], this HTTP method is optional and
+ this specification does not require <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> to support it.
+ When an LDP server supports this method,
+ this specification imposes the following new requirements for <abbr title="Linked Data Platform Containers">LDPCs</abbr>.
+ </p>
+
+ <p>
+ Any server-imposed constraints on creation or update
+ <a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
+ </p>
+
+ <section id="ldpc-put-mbrprops" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-put-mbrprops"><span class="secno">5.2.4.1 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> allow HTTP <code>PUT</code> to update an <abbr title="Linked Data Platform Container">LDPC</abbr>’s <a href="#dfn-containment-triples" class="internalDFN">containment triples</a>;
+ if the server receives such a request, it <em class="rfc2119" title="SHOULD">SHOULD</em> respond with a 409
+ (Conflict) status code.
+ </h5></section><!-- Was 5.5.1 / #ldpc-5_5_1 -->
+
+ <section id="ldpc-put-create" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-put-create"><span class="secno">5.2.4.2 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> that allow <abbr title="Linked Data Platform Resource">LDPR</abbr> creation via <code>PUT</code>
+ <em class="rfc2119" title="SHOULD NOT">SHOULD NOT</em> re-use URIs. For <abbr title="Resource Description Framework">RDF</abbr> representations (LDP-RSs),the created resource
+ can be thought of as an <abbr title="Resource Description Framework">RDF</abbr> <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [<cite><a class="bibref" href="#bib-rdf11-concepts">rdf11-concepts</a></cite>].
+ </h5></section><!-- Was 5.5.4 / #ldpc-5_5_4 -->
+
+</section>
+
+<section id="ldpc-HTTP_DELETE" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpc-HTTP_DELETE"><span class="secno">5.2.5 </span>HTTP DELETE</h4>
+ <p>
+ Per [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>], this HTTP method is optional and
+ this specification does not require <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> to support it.
+ When an LDP server supports this method,
+ this specification imposes the following new requirements for <abbr title="Linked Data Platform Containers">LDPCs</abbr>.
+ </p>
+
+ <section id="ldpc-del-contremovesconttriple" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-del-contremovesconttriple"><span class="secno">5.2.5.1 </span>
+ When an <abbr title="Linked Data Platform Resource">LDPR</abbr> identified by the object of a <a title="containment triples" href="#dfn-containment-triples" class="internalDFN">containment triple</a> is deleted, the <abbr title="Linked Data Platform Container">LDPC</abbr> server <em class="rfc2119" title="MUST">MUST</em> also remove
+ the <abbr title="Linked Data Platform Resource">LDPR</abbr> from the containing <abbr title="Linked Data Platform Container">LDPC</abbr> by removing the corresponding containment triple.
+ </h5>
+ <blockquote>
+ Non-normative note: The <a href="#dfn-ldp-server" class="internalDFN">LDP server</a> might perform additional actions,
+ as described in the <a href="#ldp-http-method-side-effects">normative references</a> like [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>].
+ For example, the server could perform additional cleanup tasks for resources it knows are no longer referenced or have not
+ been accessed for some period of time.
+ </blockquote>
+ </section><!-- Was 5.6.1 / #ldpc-5_6_1 -->
+
+ <section id="ldpc-del-contremovescontres" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-del-contremovescontres"><span class="secno">5.2.5.2 </span>
+ When an <abbr title="Linked Data Platform Resource">LDPR</abbr> identified by the object of a <a title="containment triples" href="#dfn-containment-triples" class="internalDFN">containment triple</a> is deleted, and the <abbr title="Linked Data Platform Container">LDPC</abbr> server
+ created an associated <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> (see the <a href="#ldpc-post-createbinlinkmetahdr"><abbr title="Linked Data Platform Container">LDPC</abbr> POST section</a>), the <abbr title="Linked Data Platform Container">LDPC</abbr> server <em class="rfc2119" title="MUST">MUST</em> also remove the associated <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> it created.
+ </h5></section><!-- Was 5.6.4 / #ldpc-5_6_4 -->
+
+</section>
+
+<section id="ldpc-HTTP_HEAD" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpc-HTTP_HEAD"><span class="secno">5.2.6 </span>HTTP HEAD</h4>
+ <p>Note that certain LDP mechanisms
+ rely on HTTP headers, and HTTP generally requires that
+ <code>HEAD</code> responses include the same headers as <code>GET</code> responses. Also <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> must also include HTTP headers
+ on response to <code>OPTIONS</code>, see <a href="#ldpr-HTTP_OPTIONS" class="sectionRef sec-ref">section <span class="secno">4.2.8</span> <span class="sec-title">HTTP OPTIONS</span></a>.
+ Thus, implementers supporting <code>HEAD</code> should also carefully read the
+ <a href="#ldpc-HTTP_GET" class="sectionRef sec-ref">section <span class="secno">5.2.2</span> <span class="sec-title">HTTP GET</span></a> and <a href="#ldpc-HTTP_OPTIONS" class="sectionRef sec-ref">section <span class="secno">5.2.8</span> <span class="sec-title">HTTP OPTIONS</span></a>.</p>
+</section>
+
+<section id="ldpc-HTTP_PATCH" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpc-HTTP_PATCH"><span class="secno">5.2.7 </span>HTTP PATCH</h4>
+ <p>
+ Per [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>], this HTTP method is optional and
+ this specification does not require <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> to support it.
+ When an LDP server supports this method,
+ this specification imposes the following new requirements for <abbr title="Linked Data Platform Containers">LDPCs</abbr>.
+ </p>
+
+ <p>
+ Any server-imposed constraints on <abbr title="Linked Data Platform Resource">LDPR</abbr> creation or update
+ <a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
+ </p>
+
+ <section id="ldpc-patch-req" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-patch-req"><span class="secno">5.2.7.1 </span>
+ <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> are <em class="rfc2119" title="RECOMMENDED">RECOMMENDED</em>
+ to support HTTP <code>PATCH</code> as the preferred method for
+ updating an <abbr title="Linked Data Platform Container">LDPC</abbr>'s <a title="Empty-container triples" href="#dfn-empty-container-triples" class="internalDFN">empty-container triples</a>.
+ </h5></section><!-- Was 5.8.1 / #ldpc-5_8_1 -->
+</section>
+
+<section id="ldpc-HTTP_OPTIONS" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpc-HTTP_OPTIONS"><span class="secno">5.2.8 </span>HTTP OPTIONS</h4>
+ <p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for <abbr title="Linked Data Platform Containers">LDPCs</abbr>.
+ </p>
+
+ <section id="ldpc-options-linkmetahdr" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-options-linkmetahdr"><span class="secno">5.2.8.1 </span>When an <abbr title="Linked Data Platform Container">LDPC</abbr> server creates an
+ <a title="Linked Data Platform Non-RDF Source" href="#dfn-linked-data-platform-non-rdf-source" class="internalDFN"><abbr title="Linked Data Platform Non-RDF Source">LDP-NR</abbr></a> (for example, one whose
+ representation was HTTP <code>POST</code>ed to the <abbr title="Linked Data Platform Container">LDPC</abbr>)
+ the LDP server might create an associated <a title="Linked Data Platform RDF Source" href="#dfn-linked-data-platform-rdf-source" class="internalDFN"><abbr title="Linked Data Platform RDF Source">LDP-RS</abbr></a>
+ to contain data about the non-<abbr title="Linked Data Platform Resource">LDPR</abbr> (see <a href="#ldpc-post-createbinlinkmetahdr"><abbr title="Linked Data Platform Container">LDPC</abbr> POST section</a>).
+ For LDP-NRs that have this associated <abbr title="Linked Data Platform RDF Source">LDP-RS</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 RDF Source">LDP-RS</abbr>, and whose link relation type is
+ <code>describedby</code> [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>].
+ </h5></section><!-- Was 5.9.2 / #ldpc-5_9_2 -->
+</section> <!-- h2 -->
+</section> <!-- ldpc-container -->
+
+<section id="ldpbc" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_ldpbc"><span class="secno">5.3 </span>Basic</h3>
+
+<p>The following section contains normative clauses for <a title="" href="#dfn-linked-data-platform-basic-container" class="internalDFN">Linked Data Platform Basic Container</a>.</p>
+
+
+<section id="ldpbc-general" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpbc-general"><span class="secno">5.3.1 </span>General</h4>
+
+<section id="ldpbc-are-ldpcs" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpbc-are-ldpcs"><span class="secno">5.3.1.1 </span>Each <a title="Linked Data Platform Basic Container" href="#dfn-linked-data-platform-basic-container" class="internalDFN">LDP Basic Container</a> <em class="rfc2119" title="MUST">MUST</em> also be
+ a conforming <a title="Linked Data Platform Container" href="#dfn-linked-data-platform-container" class="internalDFN">LDP Container</a> in <a href="#ldpc-container" class="sectionRef sec-ref">section <span class="secno">5.2</span> <span class="sec-title">Container</span></a> along the
+ following restrictions in this section. <a title="" href="#dfn-ldp-client" class="internalDFN">LDP client</a>s <em class="rfc2119" title="MAY">MAY</em> infer the following triple:
+ whose subject is <code>ldp:BasicContainer</code>,
+ whose predicate is <code>rdfs:subClassOf</code>,
+ and whose object is <code>ldp:Container</code>,
+ but there is no requirement to materialize this triple in the <abbr title="Linked Data Platform Basic Container">LDP-BC</abbr> representation.
+</h5></section>
+
+</section> <!-- ldpbc General -->
+
+</section> <!-- ldpbc Basic -->
+
+
+<section id="ldpdc" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_ldpdc"><span class="secno">5.4 </span>Direct</h3>
+
+<p>The following section contains normative clauses for <a title="" href="#dfn-linked-data-platform-direct-container" class="internalDFN">Linked Data Platform Direct Container</a>.</p>
+
+<section id="ldpdc-general" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpdc-general"><span class="secno">5.4.1 </span>General</h4>
+
+<section id="ldpdc-are-ldpcs" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpdc-are-ldpcs"><span class="secno">5.4.1.1 </span>Each <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Container</a> <em class="rfc2119" title="MUST">MUST</em> also be
+ a conforming <a title="Linked Data Platform Container" href="#dfn-linked-data-platform-container" class="internalDFN">LDP Container</a> in <a href="#ldpc-container" class="sectionRef sec-ref">section <span class="secno">5.2</span> <span class="sec-title">Container</span></a> along the following
+ restrictions. <a title="" href="#dfn-ldp-client" class="internalDFN">LDP client</a>s <em class="rfc2119" title="MAY">MAY</em> infer the following triple:
+ whose subject is <code>ldp:BasicContainer</code>,
+ whose predicate is <code>rdfs:subClassOf</code>,
+ and whose object is <code>ldp:Container</code>,
+ but there is no requirement to materialize this triple in the <abbr title="Linked Data Platform Direct Container">LDP-DC</abbr> representation.
+</h5></section>
+
+<section id="ldpdc-mbrpred" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpdc-mbrpred"><span class="secno">5.4.1.2 </span>
+ <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Containers</a>
+ <em class="rfc2119" title="SHOULD">SHOULD</em> use the <code>ldp:member</code> predicate as an <abbr title="Linked Data Platform Container">LDPC</abbr>'s <a title="Membership predicate" href="#dfn-membership-predicate" class="internalDFN">membership predicate</a>
+ if there is no obvious predicate from an application vocabulary to use..
+ The state of an <abbr title="Linked Data Platform Container">LDPC</abbr> includes information about which
+ resources are its members, in the form of <a title="Membership triples" href="#dfn-membership-triples" class="internalDFN">membership triples</a> that
+ follow a consistent pattern. The <abbr title="Linked Data Platform Container">LDPC</abbr>'s state contains enough information for clients to discern
+ the <a title="Membership predicate" href="#dfn-membership-predicate" class="internalDFN">membership predicate</a>, the other consistent membership
+ value used in the container's membership triples (<var>membership-constant-URI</var>),
+ and the position (subject or object) where those URIs
+ occurs in the <a title="Membership triples" href="#dfn-membership-triples" class="internalDFN">membership triples</a>.
+ Member resources can be
+ any kind of resource identified by a URI, <abbr title="Linked Data Platform Resource">LDPR</abbr> or otherwise.
+</h5></section><!-- Was 5.2.3 / #ldpc-5_2_3 -->
+
+<section id="ldpdc-containres" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpdc-containres"><span class="secno">5.4.1.3 </span>Each <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Container</a>
+ 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:membershipResource</code>,
+ and whose object is the <abbr title="Linked Data Platform Container">LDPC</abbr>'s <var>membership-constant-URI</var>.
+ Commonly the <abbr title="Linked Data Platform Container">LDPC</abbr>'s URI is the <var>membership-constant-URI</var>, but LDP does not require this.
+</h5>
+</section><!-- Was 5.2.4 / #ldpc-5_2_4 -->
+
+<section id="ldpdc-containtriples" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpdc-containtriples"><span class="secno">5.4.1.4 </span>Each <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Container</a>
+ 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:hasMemberRelation</code> or <code>ldp:isMemberOfRelation</code>.
+ The object of the triple is constrained by other sections, such as
+ <a href="#ldpdc-containtriple-relation" class="sectionRef">ldp:hasMemberRelation</a> or
+ <a href="#ldpdc-containtriple-byrelation" class="sectionRef">ldp:isMemberOfRelation</a>, based on the
+ <a title="Membership triples" href="#dfn-membership-triples" class="internalDFN">membership triple</a>
+ pattern used by the container.
+</h5><!-- Was 5.2.5 / #ldpc-5_2_5 -->
+
+<section id="ldpdc-containtriple-relation" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h6 class="normal" aria-level="5" role="heading" id="h6_ldpdc-containtriple-relation"><span class="secno">5.4.1.4.1 </span><a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Containers</a>
+ whose <a title="Membership triples" href="#dfn-membership-triples" class="internalDFN">membership triple</a>
+ pattern is <var>( membership-constant-URI , membership-predicate , member-derived-URI )</var> <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 <code>ldp:hasMemberRelation</code>,
+ and whose object is the URI of <var>membership-predicate</var>.
+</h6>
+</section><!-- Was 5.2.5.1 / #ldpc-5_2_5_1 -->
+
+<section id="ldpdc-containtriple-byrelation" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h6 class="normal" aria-level="5" role="heading" id="h6_ldpdc-containtriple-byrelation"><span class="secno">5.4.1.4.2 </span><a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Containers</a>
+ whose <a title="Membership triples" href="#dfn-membership-triples" class="internalDFN">membership triple</a>
+ pattern is <var>( member-derived-URI , membership-predicate , membership-constant-URI )</var> <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 either <code>ldp:isMemberOfRelation</code>,
+ and whose object is the URI of <var>membership-predicate</var>.
+</h6></section><!-- Was 5.2.5.2 / #ldpc-5_2_5_2 -->
+</section>
+
+<section id="ldpdc-indirectmbr-basic" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpdc-indirectmbr-basic"><span class="secno">5.4.1.5 </span>
+ <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Containers</a>
+ <em class="rfc2119" title="MUST">MUST</em> behave as if they
+ have a <var>( <abbr title="Linked Data Platform Container">LDPC</abbr> URI, <code>ldp:insertedContentRelation</code> , <code>ldp:MemberSubject</code> )</var>
+ triple, but LDP imposes no requirement to materialize such a triple in the <abbr title="Linked Data Platform Direct Container">LDP-DC</abbr> representation.
+ The value <code>ldp:MemberSubject</code> means that the
+ <var>member-derived-URI</var> is the URI assigned by the server to a
+ document it creates; for example, if the client POSTs content to a container
+ that causes the container to create a new <abbr title="Linked Data Platform Resource">LDPR</abbr>, <code>ldp:MemberSubject</code> says
+ that the <var>member-derived-URI</var> is the URI assigned to the newly created <abbr title="Linked Data Platform Resource">LDPR</abbr>.
+</h5></section>
+
+</section> <!-- ldpdc-general -->
+
+<section id="ldpdc-HTTP_POST" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpdc-HTTP_POST"><span class="secno">5.4.2 </span>HTTP POST</h4>
+ <section id="ldpdc-post-createdmbr-member" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpdc-post-createdmbr-member"><span class="secno">5.4.2.1 </span>
+ When a successful HTTP <code>POST</code> request to an <abbr title="Linked Data Platform Container">LDPC</abbr> results in the creation of an <abbr title="Linked Data Platform Resource">LDPR</abbr>,
+ the <abbr title="Linked Data Platform Container">LDPC</abbr> <em class="rfc2119" title="MUST">MUST</em> update its membership triples to reflect that addition, and the resulting
+ membership triple <em class="rfc2119" title="MUST">MUST</em> be consistent with any LDP-defined predicates it exposes.
+ A <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Container</a>'s membership triples <em class="rfc2119" title="MAY">MAY</em> also be modified via
+ through other means.
+ </h5></section><!-- Was 5.4.2 / #ldpc-5_4_2 -->
+</section> <!-- ldpdc-HTTP_POST -->
+
+<section id="ldpdc-HTTP_DELETE" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpdc-HTTP_DELETE"><span class="secno">5.4.3 </span>HTTP DELETE</h4>
+
+ <section id="ldpdc-del-contremovesmbrtriple" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpdc-del-contremovesmbrtriple"><span class="secno">5.4.3.1 </span>
+ When an <abbr title="Linked Data Platform Resource">LDPR</abbr> identified by the object of a <a title="membership triples" href="#dfn-membership-triples" class="internalDFN">membership triple</a> which was
+ originally created by the <abbr title="Linked Data Platform Direct Container">LDP-DC</abbr> is deleted, the <abbr title="Linked Data Platform Container">LDPC</abbr> server <em class="rfc2119" title="MUST">MUST</em> also remove
+ the corresponding membership triple..
+ </h5>
+ </section><!-- Was 5.6.1 / #ldpc-5_6_1 -->
+
+</section> <!-- ldpdc-HTTP_DELETE -->
+
+</section> <!-- ldpdc Direct -->
+
+<section id="ldpic" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_ldpic"><span class="secno">5.5 </span>Indirect</h3>
+
+<p>The following section contains normative clauses for <a title="" href="#dfn-linked-data-platform-indirect-container" class="internalDFN">Linked Data Platform Indirect Container</a>.</p>
+
+<section id="ldpic-general" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpic-general"><span class="secno">5.5.1 </span>General</h4>
+
+<section id="ldpic-are-ldpcs" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpic-are-ldpcs"><span class="secno">5.5.1.1 </span>Each <a title="Linked Data Platform Indirect Container" href="#dfn-linked-data-platform-indirect-container" class="internalDFN">LDP Indirect Container</a> <em class="rfc2119" title="MUST">MUST</em> also be
+ a conforming <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Container</a> in <a href="#ldpdc" class="sectionRef sec-ref">section <span class="secno">5.4</span> <span class="sec-title">Direct</span></a> along the following
+ restrictions. <a title="" href="#dfn-ldp-client" class="internalDFN">LDP client</a>s <em class="rfc2119" title="MAY">MAY</em> infer the following triple:
+ whose subject is <code>ldp:IndirectContainer</code>,
+ whose predicate is <code>rdfs:subClassOf</code>,
+ and whose object is <code>ldp:Container</code>,
+ but there is no requirement to materialize this triple in the <abbr title="Linked Data Platform Indirect Container">LDP-IC</abbr> representation.
+</h5></section>
+
+<section id="ldpic-indirectmbr" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpic-indirectmbr"><span class="secno">5.5.1.2 </span>
+ <a title="Linked Data Platform Indirect Container" href="#dfn-linked-data-platform-indirect-container" class="internalDFN">LDP Indirect Containers</a>
+ <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 <code>ldp:insertedContentRelation</code>, and
+ whose object <var>ICR</var> describes how the <var>member-derived-URI</var> in
+ the container's <a title="Membership triples" href="#dfn-membership-triples" class="internalDFN">membership triples</a> is chosen.
+ The <var>member-derived-URI</var> is taken from some triple
+ <var>( S, P, O )</var> in the document supplied by the client as input to the create request;
+ if <var>ICR</var>'s value is <var>P</var>, then the <var>member-derived-URI</var> is
+ <var>O</var>. LDP does not define the behavior when more than one triple containing
+ the predicate <var>P</var> is present in the client's input.
+ For example, if the client POSTs <abbr title="Resource Description Framework">RDF</abbr> content to a container
+ that causes the container to create a new <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>, and that content contains the triple
+ <var>( <> , foaf:primaryTopic , bob#me )</var>
+ <code>foaf:primaryTopic</code> says
+ that the <var>member-derived-URI</var> is <var>bob#me</var>.
+ </h5>
+</section><!-- Was 5.2.10 / #ldpc-5_2_10 -->
+</section> <!-- ldpic General -->
+
+<section id="ldpic-HTTP_POST" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_ldpic-HTTP_POST"><span class="secno">5.5.2 </span>HTTP POST</h4>
+ <section id="ldpic-post-indirectmbrrel" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpic-post-indirectmbrrel"><span class="secno">5.5.2.1 </span><abbr title="Linked Data Platform Containers">LDPCs</abbr>
+ whose <code>ldp:insertedContentRelation</code> triple has an object
+ <strong>other than</strong> <code>ldp:MemberSubject</code>
+ and that create new resources
+ <em class="rfc2119" title="MUST">MUST</em> add a triple to the container
+ whose subject is the container's URI,
+ whose predicate is <code>ldp:contains</code>, and
+ whose object is the newly created resource's URI (which will be different from
+ the <var><a href="#ldpic-indirectmbr">member-derived URI</a></var> in this case).
+ This <code>ldp:contains</code> triple can be the only link from the container to the newly created
+ resource in certain cases.
+ </h5></section><!-- Was 5.4.15 / #ldpc-5_4_15 -->
+</section> <!-- ldpic HTTP_POST -->
+
+</section> <!-- ldpic Indirect -->
+
+</section> <!-- h1 LDPC -->
+
+
+<section id="base-specs" class="informative" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<!--OddPage--><h2 aria-level="1" role="heading" id="h2_base-specs"><span class="secno">6. </span>Notable information from normative references</h2><p><em>This section is non-normative.</em></p>
+<p>
+While readers, and especially implementers, of LDP are assumed to understand the information in its normative
+references, the working group has found that certain points are particularly important to understand.
+For those thoroughly familiar with the referenced specifications, these points might seem obvious, yet
+experience has shown that few non-experts find all of them obvious. This section enumerates these topics;
+it is simply re-stating (non-normatively) information locatable via the normative references.
+</p>
+
+<section id="specs-webarch" class="informative" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_specs-webarch"><span class="secno">6.1 </span>Architecture of the World Wide Web</h3><p><em>This section is non-normative.</em></p>
+Reference: [<cite><a class="bibref" href="#bib-WEBARCH">WEBARCH</a></cite>]
+
+ <section id="ldp-webarch-nonexcl-membership" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldp-webarch-nonexcl-membership"><span class="secno">6.1.1 </span><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) can be a member of more than one <abbr title="Linked Data Platform Container">LDPC</abbr>.
+ </h4></section>
+
+ <section id="ldp-webarch-uri-reuse" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldp-webarch-uri-reuse"><span class="secno">6.1.2 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> should not re-use URIs,
+ regardless of the mechanism by which members are created (<code>POST</code>, <code>PUT</code>, etc.).
+ Certain specific cases exist where an <abbr title="Linked Data Platform Container">LDPC</abbr> server might delete a resource and then later re-use the
+ URI when it identifies the same resource, but only when consistent with Web architecture.
+ 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.
+ </h4></section>
+
+</section>
+
+<section id="specs-http" class="informative" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_specs-http"><span class="secno">6.2 </span>HTTP 1.1</h3><p><em>This section is non-normative.</em></p>
+Reference: [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>]
+
+ <section id="ldp-http-other-representations" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldp-http-other-representations"><span class="secno">6.2.1 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> can support 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.
+ HTTP content negotiation ([<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] Section 12 - Content Negotiation) is used to select the format.
+ </h4></section>
+
+ <section id="ldp-http-other-methods" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldp-http-other-methods"><span class="secno">6.2.2 </span><abbr title="Linked Data Platform Resources">LDPRs</abbr> can 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.
+ </h4></section>
+
+ <section id="ldp-http-delete-uri-reuse" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldp-http-delete-uri-reuse"><span class="secno">6.2.3 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a>
+ remove the resource identified by the <code>Request-URI</code> in response to a successful HTTP <code>DELETE</code> request.
+ After such a request, a subsequent HTTP <code>GET</code> on the same
+ <code>Request-URI</code> usually results in a 404 (Not found) or 410 (Gone) status
+ code, although HTTP allows others.
+ </h4></section>
+
+ <section id="ldp-http-method-side-effects" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldp-http-method-side-effects"><span class="secno">6.2.4 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> can alter the state of other resources
+ as a result of any HTTP request, especially when non-safe methods are used ([<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>] section 9.1).
+ For example, it is acceptable for the server to
+ remove triples from other resources whose subject or object is the
+ deleted resource as the result of a successful HTTP <code>DELETE</code> request.
+ It is also acceptable and common for <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> to
+ not do this – the server's behavior can vary, so LDP clients cannot depend on it.
+ </h4></section>
+
+ <section id="ldp-http-patch-allowed" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldp-http-patch-allowed"><span class="secno">6.2.5 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> can implement HTTP <code>PATCH</code>
+ to allow modifications,
+ especially partial replacement, of their resources. No
+ minimal set of patch document formats is mandated by this document or by the definition of <code>PATCH</code> [<cite><a class="bibref" href="#bib-RFC5789">RFC5789</a></cite>].
+ </h4></section>
+
+ <section id="ldp-http-content-sniffing" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldp-http-content-sniffing"><span class="secno">6.2.6 </span>
+ When the <code>Content-Type</code> request header is absent from a request,
+ <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> might infer the content type by inspecting the entity body contents [<cite><a class="bibref" href="#bib-HTTP11">HTTP11</a></cite>].
+ </h4></section>
+
+</section>
+
+<section id="specs-rdf" class="informative" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_specs-rdf"><span class="secno">6.3 </span><abbr title="Resource Description Framework">RDF</abbr></h3><p><em>This section is non-normative.</em></p>
+Reference: [<cite><a class="bibref" href="#bib-rdf11-concepts">rdf11-concepts</a></cite>]
+
+ <section id="ldp-rdfconcepts-extra-triples-any" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldp-rdfconcepts-extra-triples-any"><span class="secno">6.3.1 </span>The state of an <abbr title="Linked Data Platform Resource">LDPR</abbr>
+ can have triples with any subject(s). The URL used to retrieve the
+ representation of an <abbr title="Linked Data Platform Resource">LDPR</abbr> need not be the subject of any of its triples.
+ </h4></section>
+
+ <section id="ldp-rdfconcepts-extra-triples-members" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldp-rdfconcepts-extra-triples-members"><span class="secno">6.3.2 </span>The representation of an <abbr title="Linked Data Platform Container">LDPC</abbr>
+ can 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 an <a href="#dfn-ldp-server" class="internalDFN">LDP server</a> to provide clients with
+ information about the members without the client having to do a <code>GET</code>
+ on each member individually.
+ </h4></section>
+
+ <section id="ldp-rdfconcepts-extra-triples-types" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldp-rdfconcepts-extra-triples-types"><span class="secno">6.3.3 </span>The state of an <abbr title="Linked Data Platform Resource">LDPR</abbr> can have more than one
+ triple with an <code>rdf:type</code> predicate.
+ </h4></section>
+
+</section>
+
+</section> <!-- Base specs -->
+
+<section id="http-header-definitions">
+<!--OddPage--><h2 aria-level="1" role="heading" id="h2_http-header-definitions"><span class="secno">7. </span>HTTP Header Definitions</h2>
+
+<section id="header-accept-post" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_header-accept-post"><span class="secno">7.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 <code>Accept-Post</code> in this specification is pending
+ advancement of an <a href="https://datatracker.ietf.org/doc/draft-wilde-accept-post/">IETF draft</a>
+ that would fully include it, based on the Accept-Patch header's design from [<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 modelled after the <code>Accept-Patch</code> header defined in [<cite><a class="bibref" href="#bib-RFC5789">RFC5789</a></cite>].
+ </p>
+
+ <section id="header-accept-post-1" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_header-accept-post-1"><span class="secno">7.1.1 </span>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:</h4>
+ <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>
+ </section><!-- Was 6.1.1 / #header-accept-post-1 -->
+
+ <section id="header-accept-post-2" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_header-accept-post-2"><span class="secno">7.1.2 </span>
+ 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>.
+ </h4></section><!-- Was 6.1.2 / #header-accept-post-2 -->
+
+ <section id="header-accept-post-iana" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_header-accept-post-iana"><span class="secno">7.1.3 </span>IANA Registration Template</h4>
+ <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><!-- Was 6.1.3 / #header-accept-post-iana -->
+
+</section>
+
+<section id="prefer-parameters" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_prefer-parameters"><span class="secno">7.2 </span>Preferences on the Prefer Request Header</h3>
+
+<section id="prefer-summary" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_prefer-summary"><span class="secno">7.2.1 </span>Summary</h4>
+
+ <div class="ldp-issue-pending">
+ <div class="ldp-issue-title">Need to update normative reference once RFC number is assigned.</div>
+ The <a href="http://tools.ietf.org/html/draft-snell-http-prefer-18">HTTP Prefer header</a> is queued for an RFC number behind HTTPbis, whose BNF Prefer normatively refers to.
+ </div>
+
+ <p>This specification introduces new parameters on the HTTP <code>Prefer</code> request header's
+ <code>return=representation</code> preference [<cite><a class="bibref" href="#bib-Prefer">Prefer</a></cite>], used optionally by clients to
+ supply a hint to help the server form a response that is most appropriate to
+ the client's needs. The LDP-defined parameters suggest the portion(s) of a resource's state that the
+ client application is interested in and, if received, is likely to be
+ processed. LDP Containers with large numbers of associated documents
+ and/or members will have large representations, and many client
+ applications may be interested in processing only a subset of the <abbr title="Linked Data Platform Container">LDPC</abbr>'s
+ information (for example, only membership triples or only containment triples),
+ resulting in a potentially large savings in server, client,
+ and network processing.
+ </p>
+
+ <p>
+ Non-normative note: LDP server implementers should carefully consider the effects of these
+ preferences on caching, as described in section 2 of [<cite><a class="bibref" href="#bib-Prefer">Prefer</a></cite>].
+ </p>
+
+ <p>
+ Non-normative note: [<cite><a class="bibref" href="#bib-Prefer">Prefer</a></cite>] recommends that server implementers include a
+ <code>Preference-Applied</code> response header when the client cannot otherwise determine the server's
+ behavior with respect to honoring hints from the response content.
+ <a href="#prefer-examples">Examples</a> illustrates some cases where the header is unnecessary.
+ </p>
+
+</section> <!-- Prefer summary -->
+
+<section id="prefer-rules" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_prefer-rules"><span class="secno">7.2.2 </span>Specification</h4>
+
+ <section id="prefer-include" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_prefer-include"><span class="secno">7.2.2.1 </span>
+ The <code>include</code> hint defines a subset of an <abbr title="Linked Data Platform Resource">LDPR</abbr>'s content that a client
+ would like included in a representation.
+ The syntax for the <code>include</code> parameter of the
+ HTTP <code>Prefer</code> request header's
+ <code>return=representation</code> preference [<cite><a class="bibref" href="#bib-Prefer">Prefer</a></cite>] is:</h5>
+ <blockquote>
+ <code>include-parameter = "include" *WSP "=" *WSP ldp-uri-list</code>
+ <p>
+ Where <code>WSP</code> is whitespace [<cite><a class="bibref" href="#bib-RFC5234">RFC5234</a></cite>], and
+ <code>ldp-uri-list</code> is a double-quoted blank-delimited unordered set of URIs whose ABNF is given below.
+ The generic preference BNF [<cite><a class="bibref" href="#bib-Prefer">Prefer</a></cite>] allows either a quoted string or a token as the value of a
+ preference parameter; LDP assigns a meaning to the value only when it is a quoted string of
+ the form:
+ </p>
+ <code>ldp-uri-list = DQUOTE *WSP URI *[ 1*WSP URI ] *WSP DQUOTE</code>
+ <p>
+ where <code>DQUOTE</code> is a double quote [<cite><a class="bibref" href="#bib-RFC5234">RFC5234</a></cite>], and <code>URI</code> is an absolute URI with an optional
+ fragment component [<cite><a class="bibref" href="#bib-RFC3986">RFC3986</a></cite>].
+ </p>
+ </blockquote>
+ </section>
+
+ <section id="prefer-omit" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_prefer-omit"><span class="secno">7.2.2.2 </span>
+ The <code>omit</code> hint defines a subset of an <abbr title="Linked Data Platform Resource">LDPR</abbr>'s content that a client
+ would like omitted from a representation.
+ The syntax for the <code>omit</code> parameter of the
+ HTTP <code>Prefer</code> request header's
+ <code>return=representation</code> preference [<cite><a class="bibref" href="#bib-Prefer">Prefer</a></cite>] is:</h5>
+ <blockquote>
+ <code>omit-parameter = "omit" *WSP "=" *WSP ldp-uri-list</code>
+ <p>
+ Where <code>WSP</code> and <code>ldp-uri-list</code> are defined as above for <a href="#prefer-include">include</a>.
+ </p>
+ </blockquote>
+ </section>
+
+ <section id="prefer-conflicts" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_prefer-conflicts"><span class="secno">7.2.2.3 </span>
+ When LDP servers receive a request with conflicting hints, this specification imposes
+ no requirements on their behavior. They are free to reject the request, process it
+ applying some subset of the hints, or anything else appropriate to the server.
+ [<cite><a class="bibref" href="#bib-Prefer">Prefer</a></cite>] suggests treating similar requests as though none of the conflicting
+ preferences were specified.
+ </h5>
+ </section>
+
+ <section id="prefer-uris" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_prefer-uris"><span class="secno">7.2.2.4 </span>
+ This specification defines the following URIs for clients to use with <code>include</code>
+ and <code>omit</code> parameters. It assigns no meaning to other URIs, although
+ other specifications <em class="rfc2119" title="MAY">MAY</em> do so.</h5>
+ <table class="indented">
+ <tbody><tr>
+ <td> <a title="Containment triples" href="#dfn-containment-triples" class="internalDFN">Containment triples </a></td>
+ <td> <code>http://www.w3.org/ns/ldp#PreferContainment</code> </td>
+ </tr>
+ <tr>
+ <td> <a title="Membership triples" href="#dfn-membership-triples" class="internalDFN">Membership triples </a></td>
+ <td> <code>http://www.w3.org/ns/ldp#PreferMembership</code> </td>
+ </tr>
+ <tr>
+ <td> <a title="Empty-container triples" href="#dfn-empty-container-triples" class="internalDFN">Empty-container triples</a>
+ </td>
+ <td> <code>http://www.w3.org/ns/ldp#PreferEmptyContainer</code> </td>
+ </tr>
+ </tbody></table>
+ <blockquote>
+ <p>
+ Non-normative note: all currently defined URIs are only coherent for LDP-RSs,
+ and in fact only for <abbr title="Linked Data Platform Containers">LDPCs</abbr>, however in
+ the future it is possible that additional URIs with other scopes of applicability
+ could be defined.
+ </p>
+ </blockquote>
+ </section>
+
+</section> <!-- Prefer specification -->
+<section id="prefer-examples" class="informative" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_prefer-examples"><span class="secno">7.2.3 </span>Examples</h4><p><em>This section is non-normative.</em></p>
+ <p>
+ If we assume a container like
+ the one below:
+ </p>
+ <div class="example"><div class="example-title"><span>Example 9</span></div><pre class="example" id="prefer-examples-direct"># The following is the representation of
+# http://example.org/netWorth/nw1/assetContainer/
+<!-- @base is here only so it's easier to paste into validators for checking -->
+# @base <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:DirectContainer;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:membershipResource <http://example.org/netWorth/nw1>;
+ ldp:hasMemberRelation o:asset;
+ ldp:insertedContentRelation ldp:MemberSubject.
+
+<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 id="prefer-examples-direct-empty-container-only1">
+ Clients interested only in information about the container
+ (for example, which membership predicate it uses) might use this hint on a <code>GET</code> request:
+ <code>Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferEmptyContainer"</code>
+ </p>
+ <p>
+ A server that honors this hint would return a following response containing the HTTP header
+ <code>Preference-Applied: return=representation</code>
+ and this representation:
+ </p>
+
+ <div class="example"><div class="example-title"><span>Example 10</span></div><pre class="example"># The following is the ordered representation of
+# http://example.org/netWorth/nw1/assetContainer/
+<!-- @base is here only so it's easier to paste into validators for checking -->
+# @base <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:DirectContainer;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:membershipResource <http://example.org/netWorth/nw1>;
+ ldp:hasMemberRelation o:asset;
+ ldp:insertedContentRelation ldp:MemberSubject.</pre></div>
+
+ <p id="prefer-examples-direct-empty-container-only2">
+ Clients interested only in information about the container
+ (same as before) might use this hint instead:
+ <code>Prefer: return=representation; omit="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferContainment"</code>. Note: <strong>Treating the two as equivalent is not recommended.</strong> While today this
+ <code>omit</code> parameter value is equivalent to the preceding <code>include</code> parameter value,
+ they may not be equivalent in the future
+ due to the definition of <a title="Empty-container triples" href="#dfn-empty-container-triples" class="internalDFN">empty-container triples</a>.
+ Clients should preferentially use the <code>include</code> parameter, as it more precisely communicates their needs.
+ </p>
+ <p>
+ A <strong>LDP 1.0</strong> server that honors this hint would return the following response. Servers
+ implementing later versions of LDP might return substantively different responses.
+ </p>
+
+ <div class="example"><div class="example-title"><span>Example 11</span></div><pre class="example"># The following is the ordered representation of
+# http://example.org/netWorth/nw1/assetContainer/
+<!-- @base is here only so it's easier to paste into validators for checking -->
+# @base <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:DirectContainer;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:membershipResource <http://example.org/netWorth/nw1>;
+ ldp:hasMemberRelation o:asset;
+ ldp:insertedContentRelation ldp:MemberSubject.</pre></div>
+
+ <p id="prefer-examples-direct-membershiponly">
+ Clients interested only in information about the container
+ (for example, which membership predicate it uses) and its membership might use this hint on a <code>GET</code> request:
+ <code>Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferEmptyContainer"</code>
+ </p>
+ <p>
+ A server that honors this hint would return
+ (at least) the following response, and perhaps only this (it might
+ well omit containment triples if they are not specifically requested).
+ In cases like this example, where a client can detect from the content that its hints were honored
+ (the presence of the predicates <code>dcterms:title</code> and <code>o:asset</code> demonstrate this in the representation below),
+ there is no need for the server to include a <code>Preference-Applied</code> response header
+ in many common cases like a <code>200 (OK)</code> response. In other cases, like status code <code>303</code>,
+ the header would still be required for the client to know that the <code>303</code> response entity
+ is a representation of the resource identified by the <code>Location</code> URI
+ instead of a short hypertext note (one with a hyperlink to
+ the same URI reference provided in the <code>Location</code> header field [<cite><a class="bibref" href="#bib-HTTPBIS-SEMANTICS">HTTPBIS-SEMANTICS</a></cite>]).
+ </p>
+
+ <div class="example"><div class="example-title"><span>Example 12</span></div><pre class="example"># The following is the representation of
+# http://example.org/netWorth/nw1/assetContainer/
+<!-- @base is here only so it's easier to paste into validators for checking -->
+# @base <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:DirectContainer;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:membershipResource <http://example.org/netWorth/nw1>;
+ ldp:hasMemberRelation o:asset;
+ ldp:insertedContentRelation ldp:MemberSubject.
+
+<http://example.org/netWorth/nw1>
+ a o:NetWorth;
+ o:asset <a1>, <a3>, <a2>.</pre></div>
+
+ </section> <!-- Prefer examples -->
+
+</section> <!-- Prefer defns -->
+</section> <!-- Header defns -->
+
+<!-- Removed for action-113
+<section>
+<h1>HTTP Status Code Definitions</h1>
+
+<section id="status-code-related-content">
+<h2>209 Related Content</h2>
+
+ <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>209 Related Content</a> in this specification is pending
+ advancement of an <a href="https://datatracker.ietf.org/doc/draft-wilde-related-content/">IETF draft</a>
+ that would fully include it, patterned after the codes defined by [[RFC6585]]. Once LDP is in
+ Candidate Recommendation status, the LDP WG will make an assessment based on the status at IETF
+ working with the W3C Director.</li>
+ </ul>
+ </div>
+
+ <p>The <code>209 Related Content</code> status code indicates that the origin server
+ is supplying the representation of a different resource than the target resource,
+ and the origin server believes that the supplied representation
+ is likely to satisfy the user agent's original request.
+ The resource whose representation is supplied is descriptive of the target resource, in
+ the same way that the <code>Location</code> header in a <code>303 See Other</code>
+ response is descriptive of the target resource.
+ </p>
+ <p><code>209 Related Content</code> is intended to be used in situations where
+ <code>303 See Other</code> could have been used and would most likely result in a
+ user agent retrieving the other resource, but saves the user agent from
+ the latency penalty of having to perform a separate retrieval request.
+ </p>
+
+ <p> LDP uses <code>209 Related Content</code> to provide clients with the
+ <a href="#ldpr-Paging">first page of a large resource</a>, but it can also be used in
+ other common situations. Linked Data clients could benefit by avoiding the latency
+ of additional requests when the target resource is a concept resource (one without any
+ representation capable of transmission over HTTP), and general HTTP clients would
+ benefit in many of the more general cases where <code>303 See Other</code> responses
+ are currently used.
+ </p>
+
+ <div id="status-code-related-content-1" class="rule">7.1.1 A <code>209</code> response to a
+ <code>GET</code> request MUST contain a <code>Location</code> header with the same
+ <code>Location</code> field value as a <code>303 See Other</code> response would use [[!HTTP11]].
+ </div>
+
+ <div id="status-code-related-content-2" class="rule">7.1.2 A <code>209</code> response to a
+ <code>GET</code> request MUST contain a representation of the resource identified
+ by the response's <code>Location</code> header.
+ </div>
+
+ <div id="status-code-related-content-iana" class="rule">7.1.3 IANA Considerations</div>
+ <div>
+ <blockquote>
+ <p>
+ The <code>209 Related Content</code> must be added to the permanent status code registry
+ maintained at <a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>
+ (see [[HTTPBIS-SEMANTICS]], [[!RFC2817]]).
+ </p>
+ <p>
+ Value: 209
+ </p>
+ <p>
+ Description: Related Content
+ </p>
+ <p>
+ Reference: this specification
+ </p>
+ </blockquote>
+ </div>
+
+</section>
+</section> -->
+
+<section class="informative" id="security" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<!--OddPage--><h2 aria-level="1" role="heading" id="h2_security"><span class="secno">8. </span>Security Considerations</h2><p><em>This section is non-normative.</em></p>
+<p>As with any protocol that is implemented leveraging HTTP, implementations should take advantage of the many
+security-related facilities associated with it and are not required to carry out LDP operations
+that may be in contradistinction to a particular security policy in place. For example, when faced with an
+unauthenticated request to replace system critical <abbr title="Resource Description Framework">RDF</abbr> statements in a graph through the PUT method, applications may
+consider responding with the 401 status code (Unauthorized), indicating that the appropriate authorization
+is required. In cases where authentication is provided fails to meet the requirements of a particular access control
+policy, the 403 status code (Forbidden) can be sent back to the client to indicate this failure to meet the
+access control policy.</p>
+</section>
+
+<section class="appendix informative" id="acknowledgements">
+<!--OddPage--><h2 aria-level="1" role="heading" id="h2_acknowledgements"><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;">
+ Alexandre Bertails, Andrei Sambra, Andy Seaborne, Antonis Loizou, Arnaud Le Hors, Ashok Malhota, Bart van Leeuwen, Cody Burleson, David Wood, Eric Prud'hommeaux, Erik Wilde, Henry Story, John Arwe, Kevin Page, Kingsley Idehen, Mark Baker, Martin P. Nally, Miel Vander Sande, Miguel Esteban Gutiérrez, Nandana Mihindukulasooriya, Olivier Berger, Pierre-Antoine Champin, Raúl García Castro, Reza B'Far, Richard Cyganiak, Roger Menday, Ruben Verborgh, Sandro Hawke, Serena Villata, Sergio Fernandez, Steve Battle, Steve Speicher, Ted Thibodeau, Tim Berners-Lee, Yves Lafon
+ </p>
+
+</section>
+
+<section class="appendix informative" id="history" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
+<!--OddPage--><h2 aria-level="1" role="heading" id="h2_history"><span class="secno">B. </span>Change History</h2><p><em>This section is non-normative.</em></p>
+<p>Summary of notable changes from previous public working draft.</p>
+
+<ul>
+ <li>Changed a number of the should/may clauses to must</li>
+ <li>Introduced separate concepts for memerbship and containment</li>
+ <li>Defined sub-types of ldp:Container : Basic, Direct and Indirect</li>
+ <li>Defined sub-types of ldp:Resource : <abbr title="Resource Description Framework">RDF</abbr> Source and non-<abbr title="Resource Description Framework">RDF</abbr> Source</li>
+ <li>Improved membership predicate names, changed vocabulary terms</li>
+ <li>Reorganized conformance clauses based on type of resource</li>
+ <li>Moved paging and sorting capability into a separate document [<cite><a class="bibref" href="#bib-LDP-PAGING">LDP-PAGING</a></cite>]</li>
+ <li>Removed non-member property mechanism and replaced with usage of Prefer header</li>
+ <li>Added support for client requested interaction models on containers</li>
+ <li>Move restatements of HTTP et al. out of normative sections</li>
+</ul>
+
+</section>
+
+
+
+<section id="references" class="appendix" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><!--OddPage--><h2 aria-level="1" role="heading" id="h2_references"><span class="secno">C. </span>References</h2><section id="normative-references" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h3 aria-level="2" role="heading" id="h3_normative-references"><span class="secno">C.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-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-LDP-PAGING">[LDP-PAGING]</dt><dd rel="dcterms:requires">S. Speicher; J. Arwe; A. Malhotra. <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-paging.html"><cite>Linked Data Platform Paging</cite></a>. Editor's Working Draft. URL: <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-paging.html">https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-paging.html</a>
+</dd><dt id="bib-Prefer">[Prefer]</dt><dd rel="dcterms:requires">J. Snell. <a href="http://tools.ietf.org/html/draft-snell-http-prefer-18"><cite>Prefer</cite></a>. Internet Draft. URL: <a href="http://tools.ietf.org/html/draft-snell-http-prefer-18">http://tools.ietf.org/html/draft-snell-http-prefer-18</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-RFC3986">[RFC3986]</dt><dd rel="dcterms:requires">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-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-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-RFC5234">[RFC5234]</dt><dd rel="dcterms:requires">D. Crocker; P. Overell. <a href="http://www.ietf.org/rfc/rfc5234.txt"><cite>Augmented BNF for Syntax Specifications: ABNF</cite></a>. January 2008. STD. URL: <a href="http://www.ietf.org/rfc/rfc5234.txt">http://www.ietf.org/rfc/rfc5234.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-WEBARCH">[WEBARCH]</dt><dd rel="dcterms:requires">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><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 Schema 1.1</cite></a>. 9 January 2014. W3C Proposed Edited Recommendation. URL: <a href="http://www.w3.org/TR/rdf-schema/">http://www.w3.org/TR/rdf-schema/</a>
+</dd><dt id="bib-rdf11-concepts">[rdf11-concepts]</dt><dd rel="dcterms:requires">Richard Cyganiak; David Wood; Markus Lanthaler. <a href="http://www.w3.org/TR/rdf11-concepts/"><cite>RDF 1.1 Concepts and Abstract Syntax</cite></a>. 9 January 2014. W3C Proposed Recommendation. URL: <a href="http://www.w3.org/TR/rdf11-concepts/">http://www.w3.org/TR/rdf11-concepts/</a>
+</dd><dt id="bib-turtle">[turtle]</dt><dd rel="dcterms:requires">Eric Prud'hommeaux; Gavin Carothers. <a href="http://www.w3.org/TR/turtle/"><cite>RDF 1.1 Turtle</cite></a>. 9 January 2014. W3C Proposed Recommendation. URL: <a href="http://www.w3.org/TR/turtle/">http://www.w3.org/TR/turtle/</a>
+</dd></dl></section><section id="informative-references" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h3 aria-level="2" role="heading" id="h3_informative-references"><span class="secno">C.2 </span>Informative references</h3><dl class="bibliography" about=""><dt id="bib-HTML401">[HTML401]</dt><dd rel="dcterms:references">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-HTTPBIS-SEMANTICS">[HTTPBIS-SEMANTICS]</dt><dd rel="dcterms:references">R. Fielding; J. Reschke. <a href="http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics/"><cite>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</cite></a>. In Last Call. URL: <a href="http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics/">http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics/</a>
+</dd><dt id="bib-LDP-UCR">[LDP-UCR]</dt><dd rel="dcterms:references">Steve Battle; Steve Speicher. <a href="http://www.w3.org/TR/ldp-ucr/"><cite>Linked Data Platform Use Cases and Requirements</cite></a>. 31 October 2013. W3C Working Draft. URL: <a href="http://www.w3.org/TR/ldp-ucr/">http://www.w3.org/TR/ldp-ucr/</a>
+</dd><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-RFC4627">[RFC4627]</dt><dd rel="dcterms:references">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-SPARQL-UPDATE">[SPARQL-UPDATE]</dt><dd rel="dcterms:references">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-sparql11-query">[sparql11-query]</dt><dd rel="dcterms:references">Steven Harris; Andy Seaborne. <a href="http://www.w3.org/TR/sparql11-query/"><cite>SPARQL 1.1 Query Language</cite></a>. 21 March 2013. W3C Recommendation. URL: <a href="http://www.w3.org/TR/sparql11-query/">http://www.w3.org/TR/sparql11-query/</a>
+</dd></dl></section></section></body></html>
\ No newline at end of file
Binary file TR/WD-ldp-20140311/images/ldpc-hierarchy.png has changed
Binary file TR/WD-ldp-20140311/images/ldpr1.png has changed
Binary file TR/WD-ldp-20140311/images/ldpr2.png has changed
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/TR/WD-ldp-20140311/ldp.ttl Wed Mar 05 16:34:18 2014 +0000
@@ -0,0 +1,165 @@
+# See details within this document for linkage to specification and purpose.
+# This ontology file is a non-normative supporting document.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix owl: <http://www.w3.org/2002/07/owl#>.
+@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#> .
+@prefix : <http://www.w3.org/ns/ldp#>.
+
+:
+ a owl:Ontology;
+ dcterms:description "All vocabulary URIs defined in the Linked Data Platform (LDP) namespace.";
+ dcterms:title "The W3C Linked Data Platform (LDP) Vocabulary";
+ rdfs:label "W3C Linked Data Platform (LDP)";
+ rdfs:comment "This ontology provides an informal representation of the concepts and terms
+ as defined in the LDP specification. Consult the LDP specification for normative reference.";
+ rdfs:seeAlso <http://www.w3.org/2012/ldp>,
+ <http://www.w3.org/TR/ldp-ucr/>,
+ <http://www.w3.org/TR/ldp/>,
+ <http://www.w3.org/2011/09/LinkedData/>.
+
+:Resource
+ a rdfs:Class;
+ rdfs:comment "A HTTP-addressable resource whose lifecycle is managed by a LDP server.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "Resource".
+
+:RDFSource
+ a rdfs:Class;
+ rdfs:subClassOf :Resource;
+ rdfs:comment "A Linked Data Platform Resource (LDPR) whose state is represented as
+ RDF.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "RDFSource".
+
+:NonRDFSource
+ a rdfs:Class;
+ rdfs:subClassOf :Resource;
+ rdfs:comment "A Linked Data Platform Resource (LDPR) whose state is NOT represented as
+ RDF.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "NonRDFSource".
+
+:Container
+ a rdfs:Class;
+ rdfs:subClassOf :RDFSource;
+ rdfs:comment "A Linked Data Platform RDF Source (LDP-RS) that also conforms to
+ additional patterns and conventions for managing membership.
+ Readers should refer to the specification defining this ontology for the list of
+ behaviors associated with it.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "Container".
+
+:BasicContainer
+ a rdfs:Class;
+ rdfs:subClassOf :Container;
+ rdfs:comment "An LDPC that uses a predefined predicate to simply link to its contained resources.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "BasicContainer".
+
+:DirectContainer
+ a rdfs:Class;
+ rdfs:subClassOf :Container;
+ rdfs:comment "An LDPC that is similar to a LDP-DC but it allows an indirection with the ability to
+ list as member a resource, such as a URI representing a real-world object, that is different
+ from the resource that is created";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "DirectContainer".
+
+:IndirectContainer
+ a rdfs:Class;
+ rdfs:subClassOf :Container;
+ rdfs:comment "An LDPC that has the flexibility of choosing what form the membership triples take.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "IndirectContainer".
+
+:hasMemberRelation
+ a rdf:Property;
+ rdfs:comment "Indicates which predicate is used in membership triples, and that the membership triple pattern is < membership-constant-URI , object-of-hasMemberRelation, member-URI >.";
+ vs:term_status "unstable";
+ rdfs:domain :Container;
+ rdfs:isDefinedBy :;
+ rdfs:label "hasMemberRelation";
+ rdfs:range rdf:Property.
+
+:isMemberOfRelation
+ a rdf:Property;
+ rdfs:comment "Indicates which predicate is used in membership triples, and that the membership triple pattern is < member-URI , object-of-isMemberOfRelation, membership-constant-URI >.";
+ vs:term_status "unstable";
+ rdfs:domain :Container;
+ rdfs:isDefinedBy :;
+ rdfs:label "isMemmberOfRelation";
+ rdfs:range rdf:Property.
+
+:membershipResource
+ a rdf:Property;
+ rdfs:comment "Indicates the membership-constant-URI in a membership triple. Depending upon the membership triple pattern a container uses, as indicated by the presence of ldp:hasMemberRelation or ldp:isMemberOfRelation, the membership-constant-URI might occupy either the subject or object position in membership triples.";
+ vs:term_status "unstable";
+ rdfs:domain :Container;
+ rdfs:isDefinedBy :;
+ rdfs:label "membershipResource";
+ rdfs:range rdf:Property.
+
+:insertedContentRelation
+ a rdf:Property;
+ rdfs:comment "Indicates which triple in a creation request should be used as the member-URI value in the membership triple added when the creation request is successful.";
+ vs:term_status "unstable";
+ rdfs:domain :Container;
+ rdfs:isDefinedBy :;
+ rdfs:label "insertedContentRelation";
+ rdfs:range rdf:Property.
+
+:member
+ a rdf:Property;
+ rdfs:comment "LDP servers should use this predicate as the membership predicate if there is no obvious predicate from an application vocabulary to use.";
+ vs:term_status "unstable";
+ rdfs:domain :Resource;
+ rdfs:isDefinedBy :;
+ rdfs:label "member";
+ rdfs:range rdfs:Resource.
+
+:contains
+ a rdf:Property;
+ rdfs:comment "Links a container with resources created through the container.";
+ vs:term_status "unstable";
+ rdfs:domain :Container;
+ rdfs:isDefinedBy :;
+ rdfs:label "contains";
+ rdfs:range rdfs:Resource.
+
+:MemberSubject
+ a rdf:Description; # individual
+ rdfs:comment "Used to indicate default and typical behavior for ldp:insertedContentRelation, where the member-URI value in the membership triple added when a creation request is successful is the URI assigned to the newly created resource.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "MemberSubject".
+
+:PreferContainment
+ a rdf:Description; # individual
+ rdfs:comment "URI identifying a LDPC's containment triples, for example to allow clients to express interest in receiving them.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "PreferContainment".
+
+:PreferMembership
+ a rdf:Description; # individual
+ rdfs:comment "URI identifying a LDPC's membership triples, for example to allow clients to express interest in receiving them.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "PreferMembership".
+
+:PreferEmptyContainer
+ a rdf:Description; # individual
+ rdfs:comment "URI identifying the subset of a LDPC's triples present in an empty LDPC, for example to allow clients to express interest in receiving them. Currently this excludes containment and membership triples, but in the future other exclusions might be added. This definition is written to automatically exclude those new classes of triples.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "PreferEmptyContainer".
+
\ No newline at end of file
--- a/Test Cases/LDP Test Cases.html Wed Mar 05 16:33:45 2014 +0000
+++ b/Test Cases/LDP Test Cases.html Wed Mar 05 16:34:18 2014 +0000
@@ -4,4 +4,354 @@
</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a>:</em></p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.8 LDPR server responses MUST use entity tags (either weak or strong ones) as response ETag header values.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to the resource's HTTP Request-URI. [...]</span><span
property="rdfs:seeAlso"
href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.3.1 LDPR servers MUST support the HTTP GET Method for LDPRs.</span><span
property="rdfs:seeAlso"
href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCR1-I1-LDPR-URI" typeof="tn:TestInput"><em property="dc:title"><LDPR URI></em>. <span property="dc:description">The URI of an LDPR.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPR at <LDPR URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCR1-RQ1-GET-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description"> GET <LDPR URI></div>
<span property="tn:usesInput" resource="#TCR1-I1-LDPR-URI"> </span></li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCR1-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"> <em property="dc:title"><Response
1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span> <span property="tn:fromStep" resource="#TCR1-RQ1-GET-LDPR-URI"></span></li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCR1-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted"
resource="TCR1-O1-Response-1-GET">Assert
<Response 1 GET> (<span property="dc:title">GET correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
</ul>
</section>
<!-- RGC: Test removed since 4.3.4 is no longer an absolute requirement
<section resource="#TCR2" typeof="td:TestCase">
<h3><a id="TC-R2"><span property="rdfs:label">TC-R2</span>. <span property="dc:title">GET on an LDPR without content type</span></a></h3>
<p property="dc:description">Tests making a GET request on an existing LDPR without indicating a content type.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl
- García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.3.4 [...] If the client does not indicate a preference, text/turtle SHOULD be returned.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCR2-I1-LDPR-URI" typeof="tn:TestInput"><em property="dc:title"><LDPR URI></em>. <span property="dc:description">The URI of an LDPR.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPR at <LDPR URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCR2-RQ1-GET-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPR URI></div>
<span property="tn:usesInput" resource="#TCR2-I1-LDPR-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCR2-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span> <span property="tn:fromStep"
resource="#TCR2-RQ1-GET-LDPR-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCR2-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR2-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[entity-header].Content-Type = text/turtle</li>
</ul>
</div>
</div></li>
</ul>
</section>
-->
<section resource="#TCR3" typeof="td:TestCase">
<h3><a id="TC-R3"><span property="rdfs:label">TC-R3</span>. <span property="dc:title">GET on a non-existing LDPR</span></a></h3>
<p property="dc:description">Tests making a GET request on a non-existing LDPR.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.6.1 LDPR servers MUST remove the resource identified by the Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET on the same Request-URI MUST result in a 404 (Not found) or 410 (Gone) status code.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCR3-I1-LDPR-URI" typeof="tn:TestInput"><em property="dc:title"><LDPR URI></em>. <span property="dc:description">The URI of a non-existing LDPR.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server does not contain an LDPR at <LDPR URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCR3-RQ1-GET-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPR URI></div>
<span property="tn:usesInput" resource="#TCR3-I1-LDPR-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCR3-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
<span property="tn:fromStep" resource="#TCR3-RQ1-GET-LDPR-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCR3-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR3-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET incorrect</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 404 or 410</li>
</ul>
</div>
</div></li>
</ul>
</section>
<!-- RGC: Test removed since 4.5.2 is not an absolute requirement
<section resource="#TCR4" typeof="td:TestCase">
<h3><a id="TC-R4"><span property="rdfs:label">TC-R4</span>. <span property="dc:title">PUT on an LDPR</span></a></h3>
<p property="dc:description">Tests making a PUT request on an LDPR.</p> <p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a>:</em></p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to the resource's HTTP Request-URI. [...]</span><span
property="rdfs:seeAlso"
href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<p><em><a target="_blank" href="http://tools.ietf.org/html/rfc2616" property="rdfs:seeAlso">Hypertext Transfer Protocol - HTTP/1.1</a>:</em></p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">3.11 [...] An entity tag MUST be unique across all versions of all entities associated with a particular resource.</span><span property="rdfs:seeAlso" href="http://tools.ietf.org/html/rfc2616"></span></div>
</li>
</ul>
<h4>Input </h4>
<ul>
<li property="td:input" resource="#TCR4-I1-LDPR-URI" typeof="tn:TestInput"><em property="dc:title"><LDPR URI></em>. <span property="dc:description">The URI of an LDPR.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPR at <LDPR URI></li>
<li property="td:precondition">The LDPR at <LDPR URI> allows PUT</li>
<li property="td:precondition">The LDP server allows updating in the LDPR the current representation at <LDPR URI></li>
<li property="td:precondition">The LDP server does not desire that the request be applied to a different URI</li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCR4-RQ1-GET-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPR URI></div>
<span property="tn:usesInput" resource="#TCR4-I1-LDPR-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCR4-RQ2-PUT-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">PUT <LDPR URI>
<ul>
<li>[request-header].If-Match = <Response GET 1>.[response-header].ETag</li>
<li>[message-body] = <Response GET 1>.[message-body]</li>
</ul>
</div>
<span property="tn:usesInput" resource="#TCR4-I1-LDPR-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCR4-RQ3-GET-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPR URI></div>
<span property="tn:usesInput" resource="#TCR4-I1-LDPR-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCR4-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
<span property="tn:fromStep" resource="#TCR4-RQ1-GET-LDPR-URI">
</span>
</li>
<li property="td:output" resource="#TCR4-O2-Response-2-PUT" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 2 PUT></em>. <span property="dc:description">The response of the PUT request in step 2.</span>
<span property="tn:fromStep" resource="#TCR4-RQ2-PUT-LDPR-URI">
</span>
</li>
<li property="td:output" resource="#TCR4-O3-Response-3-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 3 GET></em>. <span property="dc:description">The response of the GET request in step 3.</span>
<span property="tn:fromStep" resource="#TCR4-RQ3-GET-LDPR-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCR4-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR4-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCR4-A2-Response-2-PUT" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR4-O2-Response-2-PUT">Assert <Response 2 PUT> (<span property="dc:title">PUT correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCR4-A3-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR4-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">GET correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCR4-A4-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR4-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">LDPR updated</span>):
<div property="dc:description">
<ul>
<li>[response-header].ETag != <Response 1 GET>.[response-header].ETag</li>
</ul>
</div>
</div></li>
</ul>
</section>
-->
<!-- RGC: Test removed since 4.5.2 is not an absolute requirement
<section resource="#TCR5" typeof="td:TestCase">
<h3><a id="TC-R5"><span property="rdfs:label">TC-R5</span>. <span property="dc:title">PUT on an LDPR without matching ETags</span></a></h3>
<p property="dc:description">Tests making a PUT request on an LDPR without matching ETags.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.5.2 [...] LDPR servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request. [...]</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input </h4>
<ul>
<li property="td:input" resource="#TCR5-I1-LDPR-URI" typeof="tn:TestInput"><em property="dc:title"><LDPR URI></em>. <span property="dc:description">The URI of an LDPR.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPR at <LDPR URI></li>
<li property="td:precondition">The LDPR at <LDPR URI> allows PUT</li>
<li property="td:precondition">The LDP server allows updating in the LDPR the current representation at <LDPR URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCR5-RQ1-GET-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPR URI></div>
<span property="tn:usesInput" resource="#TCR5-I1-LDPR-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCR5-RQ2-PUT-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">PUT <LDPR URI>
<ul>
<li>[request-header].If-Match = <Response GET 1>.[response-header].ETag + 'M'</li>
<li>[message-body] = <Response GET 1>.[message-body]</li>
</ul>
</div>
<span property="tn:usesInput" resource="#TCR5-I1-LDPR-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCR5-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
<span property="tn:fromStep" resource="#TCR5-RQ1-GET-LDPR-URI">
</span>
</li>
<li property="td:output" resource="#TCR5-O2-Response-2-PUT" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 2 PUT></em>. <span property="dc:description">The response of the PUT request in step 2.</span>
<span property="tn:fromStep" resource="#TCR5-RQ2-PUT-LDPR-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCR5-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR5-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCR5-A2-Response-2-PUT" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR5-O2-Response-2-PUT">Assert <Response 2 PUT> (<span property="dc:title">PUT incorrect</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 412</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
</ul>
</section>
-->
<section resource="#TCR6" typeof="td:TestCase">
<h3><a id="TC-R6"><span property="rdfs:label">TC-R6</span>. <span property="dc:title">DELETE on an LDPR</span></a></h3>
<p property="dc:description">Tests making a DELETE request on an LDPR.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to the resource's HTTP Request-URI. [...]</span><span
property="rdfs:seeAlso"
href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.6.1 LDPR servers MUST remove the resource identified by the Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET on the same Request-URI MUST result in a 404 (Not found) or 410 (Gone) status code.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCR6-I1-LDPR-URI" typeof="tn:TestInput"><em property="dc:title"><LDPR URI></em>. <span property="dc:description">The URI of an LDPR.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPR at <LDPR URI></li>
<li property="td:precondition">The LDPR at <LDPR URI> allows DELETE</li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCR6-RQ1-DELETE-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">DELETE <LDPR URI>
</div>
<span property="tn:usesInput" resource="#TCR6-I1-LDPR-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCR6-RQ2-GET-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPR URI></div>
<span property="tn:usesInput" resource="#TCR6-I1-LDPR-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCR6-O1-Response-1-DELETE" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 DELETE></em>. <span property="dc:description">The response of the DELETE request in step 1.</span>
<span property="tn:fromStep" resource="#TCR6-RQ1-DELETE-LDPR-URI">
</span>
</li>
<li property="td:output" resource="#TCR6-O2-Response-2-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 2 GET></em>. <span property="dc:description">The response of the GET request in step 2.</span>
<span property="tn:fromStep" resource="#TCR6-RQ2-GET-LDPR-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCR6-A1-Response-1-DELETE" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR6-O1-Response-1-DELETE">Assert <Response 1 DELETE> (<span property="dc:title">DELETE correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCR6-A2-Response-1-DELETE" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR6-O1-Response-1-DELETE">Assert <Response 1 DELETE> <Response 2 GET> (<span property="dc:title">DELETE resource correct</span>):
<div property="dc:description">
<ul>
<li><Response 1 DELETE>.[Status-Line].Status-Code = 200 or 204 and <Response 2 GET>.[Status-Line].Status-Code = 404 or 410</li>
<li>or </li>
<li><Response 1 DELETE>.[Status-Line].Status-Code = 2xx (except 200 and 204) </li>
</ul>
</div>
</div></li>
</ul>
</section>
<section resource="#TCR7" typeof="td:TestCase">
<h3><a id="TC-R7"><span property="rdfs:label">TC-R7</span>. <span property="dc:title">HEAD on an LDPR</span></a></h3>
<p property="dc:description">Tests making a HEAD request on an LDPR.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to the resource's HTTP Request-URI. [...]</span><span
property="rdfs:seeAlso"
href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.7.1 LDPR servers MUST support the HTTP HEAD method.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<p><em><a target="_blank" href="http://tools.ietf.org/html/rfc2616" property="rdfs:seeAlso">Hypertext Transfer Protocol - HTTP/1.1</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">9.4 The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response.</span><span property="rdfs:seeAlso" href="http://tools.ietf.org/html/rfc2616"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCR7-I1-LDPR-URI" typeof="tn:TestInput"><em property="dc:title"><LDPR URI></em>. <span property="dc:description">The URI of an LDPR.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPR at <LDPR URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCR7-RQ1-HEAD-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">HEAD <LDPR URI>
</div>
<span property="tn:usesInput" resource="#TCR7-I1-LDPR-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCR7-O1-Response-1-HEAD" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 HEAD></em>. <span property="dc:description">The response of the HEAD request in step 1.</span>
<span property="tn:fromStep" resource="#TCR7-RQ1-HEAD-LDPR-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCR7-A1-Response-1-HEAD" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR7-O1-Response-1-HEAD">Assert <Response 1 HEAD> (<span property="dc:title">HEAD correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
<li>[message-body] not exists</li>
</ul>
</div>
</div></li>
</ul>
</section>
<section resource="#TCR8" typeof="td:TestCase">
<h3><a id="TC-R8"><span property="rdfs:label">TC-R8</span>. <span property="dc:title">OPTIONS on an LDPR</span></a></h3>
<p property="dc:description">Tests making an OPTIONS request on an LDPR.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.9.1 LDPR servers MUST support the HTTP OPTIONS method.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.9.2 LDPR servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCR8-I1-LDPR-URI" typeof="tn:TestInput"><em property="dc:title"><LDPR URI></em>. <span property="dc:description">The URI of an LDPR.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPR at <LDPR URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCR8-RQ1-OPTIONS-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">OPTIONS <LDPR URI>
</div>
<span property="tn:usesInput" resource="#TCR8-I1-LDPR-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCR8-RP1-Response-1-OPTIONS" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 OPTIONS></em>. <span property="dc:description">The response of the OPTIONS request in step 1.</span>
<span property="tn:fromStep" resource="#TCR8-RQ1-OPTIONS-LDPR-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCR8-A1-Response-1-OPTIONS" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR8-O1-Response-1-OPTIONS">Assert <Response 1 OPTIONS> (<span property="dc:title">OPTIONS correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx<strong> </strong></li>
<li>[entity-header].Allow exists</li>
</ul>
</div>
</div></li>
</ul>
</section>
</section>
<section>
<h2><a id="Tests-LDPCs"></a>Tests for LDPCs</h2>
<p>These tests involve LDPCs and LDPRs.</p>
<section resource="#TCC1" typeof="td:TestCase">
<h3><a id="TC-C1"><span property="rdfs:label">TC-C1</span>. <span property="dc:title">GET on an LDPC</span></a></h3>
<p property="dc:description">Tests making a GET request on an LDPC.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.8 LDPR server responses MUST use entity tags (either weak or strong ones) as response ETag header values.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to the resource's HTTP Request-URI. [...]</span><span
property="rdfs:seeAlso"
href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.3.1 LDPR servers MUST support the HTTP GET Method for LDPRs.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.2.7 The representation of a LDPC MUST have rdf:type of ldp:Container, [...].</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.2.4 An LDPC representation MUST contain exactly one triple whose subject is the LDPC URI, whose predicate is the ldp:membershipSubject, and whose object is the LDPC's membership subject URI.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.2.5 An LDPC representation MUST contain exactly one triple whose subject is the LDPC URI, and whose predicate is either ldp:membershipPredicate or ldp:membershipPredicateInverse. [...]</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.2.5.1 For a given triple T with a subject C of the LDPC and predicate of ldp:membershipPredicate, the object MUST be the URI of the membership predicate P used to indicate membership to the linked to LDPC, [...]</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.2.5.2 For a given triple T with a subject C of the LDPC and predicate of ldp:membershipPredicateInverse, the object MUST be the URI of the membership predicate P used to indicate membership to the linked to LDPC, [...]</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCC1-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
<li property="td:input" resource="#TCC1-I2-S-URI" typeof="tn:TestInput"><em property="dc:title"><S URI></em>. <span property="dc:description">The URI of an RDF resource.</span></li>
<li property="td:input" resource="#TCC1-I3-P-URI" typeof="tn:TestInput"><em property="dc:title"><P URI></em>. <span property="dc:description">The URI of an RDF property.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
<li property="td:precondition">The membership subject used by the LDPC is identified by <S URI></li>
<li property="td:precondition">The membership predicate used by the LDPC is identified by <P URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC1-RQ1-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI></div>
<span property="tn:usesInput" resource="#TCC1-I1-LDPC-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC1-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
<span property="tn:fromStep" resource="#TCC1-RQ1-GET-LDPC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC1-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC1-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET resource correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC1-A2-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC1-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET container correct</span>):
<div property="dc:description">
<ul>
<li>[message-body] contains <LDPC URI> rdf:type ldp:Container .</li>
<li>[message-body] contains <LDPC URI> ldp:membershipSubject <S URI> .</li>
<li>[message-body] contains <LDPC URI> ldp:membershipPredicate <P URI> . or <LDPC URI> ldp:membershipPredicateInverse <P URI> .</li>
</ul>
</div>
</div></li>
</ul>
</section>
<!-- RGC: Test removed since 4.3.4 is no longer an absolute requirement
<section resource="#TCC2" typeof="td:TestCase">
<h3><a id="TC-C2"><span property="rdfs:label">TC-C2</span>. <span property="dc:title">GET on an LDPC without content type</span></a></h3>
<p property="dc:description">Tests making a GET request on an LDPC without content type.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.3.4 [...] If the client does not indicate a preference, text/turtle SHOULD be returned.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCC2-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC2-RQ1-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI>
</div>
<span property="tn:usesInput" resource="#TCC2-I1-LDPC-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC2-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
<span property="tn:fromStep" resource="#TCC2-RQ1-GET-LDPC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC2-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC2-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET resource correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[entity-header].Content-Type = text/turtle</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC2-A2-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC2-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET container correct</span>):
<div property="dc:description">
<ul>
<li>[message-body] contains rdf:type ldp:Container</li>
</ul>
</div>
</div></li>
</ul>
</section>
-->
<section resource="#TCC3" typeof="td:TestCase">
<h3><a id="TC-C3"><span property="rdfs:label">TC-C3</span>. <span property="dc:title">GET on a non-existing LDPC</span></a></h3>
<p property="dc:description">Tests making a GET request on an non-existing LDPC.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.6.1 LDPR servers MUST remove the resource identified by the Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET on the same Request-URI MUST result in a 404 (Not found) or 410 (Gone) status code.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCC3-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of a non-existing LDPC.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server does not contain an LDPC at <LDPC URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC3-RQ1-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI></div>
<span property="tn:usesInput" resource="#TCC3-I1-LDPC-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC3-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
<span property="tn:fromStep" resource="#TCC3-RQ1-GET-LDPC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC3-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC3-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET incorrect</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 404 or 410</li>
</ul>
</div>
</div></li>
</ul>
</section>
<!-- RGC: Test removed since 4.5.2 is not an absolute requirement
<section resource="#TCC4" typeof="td:TestCase">
<h3><a id="TC-C4"><span property="rdfs:label">TC-C4</span>. <span property="dc:title">PUT on an LDPC</span></a></h3>
<p property="dc:description">Tests making a PUT request on an LDPC.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a>:</em></p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to the resource's HTTP Request-URI. [...]</span><span
property="rdfs:seeAlso"
href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<p><em><a target="_blank" href="http://tools.ietf.org/html/rfc2616" property="rdfs:seeAlso">Hypertext Transfer Protocol - HTTP/1.1</a>:</em></p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">3.11 [...] An entity tag MUST be unique across all versions of all entities associated with a particular resource.</span><span property="rdfs:seeAlso" href="http://tools.ietf.org/html/rfc2616"></span></div>
</li>
</ul>
<h4>Input </h4>
<ul>
<li property="td:input" resource="#TCC4-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
<li property="td:precondition">The LDPC at <LDPC URI> allows PUT</li>
<li property="td:precondition">The LDP server allows updating in the LDPC the current representation at <LDPC URI></li>
<li property="td:precondition">The LDP server does not desire that the request be applied to a different URI</li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC4-RQ1-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI></div>
<span property="tn:usesInput" resource="#TCC4-I1-LDPC-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCC4-RQ2-PUT-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">PUT <LDPC URI>
<ul>
<li>[request-header].If-Match = <Response GET 1>.[response-header].ETag</li>
<li>[message-body] = <Response GET 1>.[message-body]</li>
</ul>
</div>
<span property="tn:usesInput" resource="#TCC4-I1-LDPC-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCC4-RQ3-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI></div>
<span property="tn:usesInput" resource="#TCC4-I1-LDPC-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC4-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
<span property="tn:fromStep" resource="#TCC4-RQ1-GET-LDPC-URI">
</span>
</li>
<li property="td:output" resource="#TCC4-O2-Response-2-PUT" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 2 PUT></em>. <span property="dc:description">The response of the PUT request in step 2.</span>
<span property="tn:fromStep" resource="#TCC4-RQ2-PUT-LDPC-URI">
</span>
</li>
<li property="td:output" resource="#TCC4-O3-Response-3-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 3 GET></em>. <span property="dc:description">The response of the GET request in step 3.</span>
<span property="tn:fromStep" resource="#TCC4-RQ3-GET-LDPC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC4-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC4-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET resource correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC4-A2-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC4-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET container correct</span>):
<div property="dc:description">
<ul>
<li>[message-body] contains rdf:type ldp:Container</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC4-A3-Response-2-PUT" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC4-O2-Response-2-PUT">Assert <Response 2 PUT> (<span property="dc:title">PUT correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC4-A4-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC4-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">GET resource correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC4-A5-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC4-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">GET container correct</span>):
<div property="dc:description">
<ul>
<li>[message-body] contains rdf:type ldp:Container</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC4-A6-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC4-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">LDPC updated</span>):
<div property="dc:description">
<ul>
<li>[response-header].ETag != <Response 1 GET>.[response-header].ETag</li>
</ul>
</div>
</div></li>
</ul>
</section>
-->
<!-- RGC: Test removed since 4.5.2 is not an absolute requirement
<section resource="#TCC5" typeof="td:TestCase">
<h3><a id="TC-C5"><span property="rdfs:label">TC-C5</span>. <span property="dc:title">PUT on an LDPC without matching ETags</span></a></h3>
<p property="dc:description">Tests making a PUT request on an LDPC without matching ETags.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.5.2 [...] LDPR servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request. [...]</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCC5-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
<li property="td:precondition">The LDPC at <LDPC URI> allows PUT</li>
<li property="td:precondition">The LDP server allows updating in the LDPC the current representation at <LDPC URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC5-RQ1-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI></div>
<span property="tn:usesInput" resource="#TCC5-I1-LDPC-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCC5-RQ2-PUT-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">PUT <LDPC URI>
<ul>
<li>[request-header].If-Match = <Response GET 1>.[response-header].ETag + 'M'</li>
<li>[message-body] = <Response GET 1>.[message-body]</li>
</ul>
</div>
<span property="tn:usesInput" resource="#TCC5-I1-LDPC-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC5-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
<span property="tn:fromStep" resource="#TCC5-RQ1-GET-LDPC-URI">
</span>
</li>
<li property="td:output" resource="#TCC5-O2-Response-2-PUT" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 2 PUT></em>. <span property="dc:description">The response of the PUT request in step 2.</span>
<span property="tn:fromStep" resource="#TCC5-RQ2-PUT-LDPC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC5-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC5-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET resource correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC5-A2-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC5-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET container correct</span>):
<div property="dc:description">
<ul>
<li>[message-body] contains rdf:type ldp:Container</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC5-A3-Response-2-PUT" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC5-O2-Response-2-PUT">Assert <Response 2 PUT> (<span property="dc:title">PUT correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 412</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
</ul>
</section>
-->
<section resource="#TCC6" typeof="td:TestCase">
<h3><a id="TC-C6"><span property="rdfs:label">TC-C6</span>. <span property="dc:title">DELETE on an LDPC</span></a></h3>
<p property="dc:description">Tests making a DELETE request on an LDPC.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to the resource's HTTP Request-URI. [...]</span><span
property="rdfs:seeAlso"
href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.6.1 LDPR servers MUST remove the resource identified by the Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET on the same Request-URI MUST result in a 404 (Not found) or 410 (Gone) status code.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCC6-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
<li property="td:precondition">The LDPC at <LDPC URI> allows DELETE</li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC6-RQ1-DELETE-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">DELETE <LDPC URI>
</div>
<span property="tn:usesInput" resource="#TCC6-I1-LDPC-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCC6-RQ2-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI></div>
<span property="tn:usesInput" resource="#TCC6-I1-LDPC-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC6-O1-Response-1-DELETE" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 DELETE></em>. <span property="dc:description">The response of the DELETE request in step 1.</span>
<span property="tn:fromStep" resource="#TCC6-RQ1-DELETE-LDPC-URI">
</span>
</li>
<li property="td:output" resource="#TCC6-O2-Response-2-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 2 GET></em>. <span property="dc:description">The response of the GET request in step 2.</span>
<span property="tn:fromStep" resource="#TCC6-RQ2-GET-LDPC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC6-A1-Response-1-DELETE" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC6-O1-Response-1-DELETE">Assert <Response 1 DELETE> (<span property="dc:title">DELETE correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC6-A2-Response-1-DELETE" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC6-O1-Response-1-DELETE">Assert <Response 1 DELETE> <Response 2 GET> (<span property="dc:title">DELETE resource correct</span>):
<div property="dc:description">
<ul>
<li><Response 1 DELETE>.[Status-Line].Status-Code = 200 or 204 and <Response 2 GET>.[Status-Line].Status-Code = 404 or 410</li>
<li>or </li>
<li><Response 1 DELETE>.[Status-Line].Status-Code = 2xx (except 200 and 204)</li>
</ul>
</div>
</div></li>
</ul>
</section>
<section resource="#TCC7" typeof="td:TestCase">
<h3><a id="TC-C7"><span property="rdfs:label">TC-C7</span>. <span property="dc:title">DELETE on an LDPR in an LDPC</span></a></h3>
<p property="dc:description">Tests making a DELETE request on an LDPR in an LDPC.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.6.2 When the LDPC server successfully completes the DELETE request on a LDPC, it MUST remove any membership triples associated with the LDPC as indicated by the canonical Request-URI. [...]</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCC7-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
<li property="td:input" resource="#TCC7-I2-LDPR-URI" typeof="tn:TestInput"><em property="dc:title"><LDPR URI></em>. <span property="dc:description">The URI of an LDPR that is a member of the LDPC.</span></li>
<li property="td:input" resource="#TCC7-I3-S-URI" typeof="tn:TestInput"><em property="dc:title"><S URI></em>. <span property="dc:description">The URI of an RDF resource.</span></li>
<li property="td:input" resource="#TCC7-I4-P-URI" typeof="tn:TestInput"><em property="dc:title"><P URI></em>. <span property="dc:description">The URI of an RDF property.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
<li property="td:precondition">The LDP server contains an LDPR at <LDPR URI></li>
<li property="td:precondition">The LDPR is a member of the LDPC</li>
<li property="td:precondition">The LDPR at <LDPR URI> allows DELETE</li>
<li property="td:precondition">The LDPR was originally created by the LDPC</li>
<li property="td:precondition">The membership subject used by the LDPC is identified by <S URI></li>
<li property="td:precondition">The membership predicate used by the LDPC is identified by <P URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC7-RQ1-DELETE-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">DELETE <LDPR URI>
</div>
<span property="tn:usesInput" resource="#TCC7-I2-LDPR-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCC7-RQ2-GET-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPR URI></div>
<span property="tn:usesInput" resource="#TCC7-I2-LDPR-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCC7-RQ3-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI></div>
<span property="tn:usesInput" resource="#TCC7-I1-LDPC-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC7-O1-Response-1-DELETE" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 DELETE></em>. <span property="dc:description">The response of the DELETE request in step 1.</span>
<span property="tn:fromStep" resource="#TCC7-RQ1-DELETE-LDPR-URI">
</span>
</li>
<li property="td:output" resource="#TCC7-O2-Response-2-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 2 GET></em>. <span property="dc:description">The response of the GET request in step 2.</span>
<span property="tn:fromStep" resource="#TCC7-RQ2-GET-LDPR-URI">
</span>
</li>
<li property="td:output" resource="#TCC7-O3-Response-3-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 3 GET></em>. <span property="dc:description">The response of the GET request in step 3.</span>
<span property="tn:fromStep" resource="#TCC7-RQ3-GET-LDPC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC7-A1-Response-1-DELETE" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC7-O1-Response-1-DELETE">Assert <Response 1 DELETE> (<span property="dc:title">DELETE correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC7-A2-Response-1-DELETE" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC7-O1-Response-1-DELETE">Assert <Response 1 DELETE> <Response 2 GET> (<span property="dc:title">DELETE resource correct</span>):
<div property="dc:description">
<ul>
<li><Response 1 DELETE>.[Status-Line].Status-Code = 200 or 204 and <Response 2 GET>.[Status-Line].Status-Code = 404 or 410</li>
<li>or </li>
<li><Response 1 DELETE>.[Status-Line].Status-Code = 2xx (except 200 and 204)</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC7-A3-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC7-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">GET resource correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC7-A4-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC7-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">GET container correct</span>):
<div property="dc:description">
<ul>
<li>[message-body] contains <LDPC URI> rdf:type ldp:Container .</li>
<li>[message-body] contains <LDPC URI> ldp:membershipSubject <S URI> .</li>
<li>[message-body] contains <LDPC URI> ldp:membershipPredicate <P URI> . or <LDPC URI> ldp:membershipPredicateInverse <P URI> .</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC7-A5-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC7-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">member removed from container</span>)
<div property="dc:description">
<ul>
<li>[message-body] does not contain <S URI> <P URI> <LDPR URI> .</li>
</ul>
</div>
</div></li>
</ul>
</section>
<section resource="#TCC8" typeof="td:TestCase">
<h3><a id="TC-C8"><span property="rdfs:label">TC-C8</span>. <span property="dc:title">HEAD on an LDPC</span></a></h3>
<p property="dc:description">Tests making a HEAD request on an LDPC.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to the resource's HTTP Request-URI. [...]</span><span
property="rdfs:seeAlso"
href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.7.1 LDPR servers MUST support the HTTP HEAD method.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<p><a target="_blank" href="http://tools.ietf.org/html/rfc2616" property="rdfs:seeAlso"><em>Hypertext Transfer Protocol - HTTP/1.1</em></a>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">9.4 The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response.</span><span property="rdfs:seeAlso" href="http://tools.ietf.org/html/rfc2616"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCC8-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC8-RQ1-HEAD-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">HEAD <LDPC URI>
</div>
<span property="tn:usesInput" resource="#TCC8-I1-LDPC-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC8-O1-Response-1-HEAD" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 HEAD></em>. <span property="dc:description">The response of the HEAD request in step 1.</span>
<span property="tn:fromStep" resource="#TCC8-RQ1-HEAD-LDPC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC8-A1-Response-1-HEAD" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC8-O1-Response-1-HEAD">Assert <Response 1 HEAD> (<span property="dc:title">HEAD correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
<li>[message-body] not exists</li>
</ul>
</div>
</div></li>
</ul>
</section>
<section resource="#TCC9" typeof="td:TestCase">
<h3><a id="TC-C9"><span property="rdfs:label">TC-C9</span>. <span property="dc:title">POST an LDPR on an LDPC</a></h3>
<p property="dc:description">Tests making a POST request of an LDPR on an LDPC.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to the resource's HTTP Request-URI. [...]</span><span
property="rdfs:seeAlso"
href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.4.1 [...] If the resource was created successfully, LDPC servers MUST respond with status code 201 (Created) and the Location header set to the new resource’s URL. [...] </span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.4.2 After a successful HTTP POST request to a LDPC, the new resource MUST appear as a member of the LDPC until the new resource is deleted or removed by other methods. [...] </span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.4.4 For servers that support create, LDPC servers MUST create an LDPR from a RDF representation in the request entity body. [...]</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.4.5 LDPC servers MUST accept a request entity body with a request header of Content-Type with value of text/turtle. </span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCC9-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
<li property="td:input" resource="#TCC9-I2-LDPR-REP" typeof="tn:TestInput"><em property="dc:title"><LDPR representation></em>. <span property="dc:description">The representation of the LDPR to be created</span></li>
<li property="td:input" resource="#TCC9-I3-S-URI" typeof="tn:TestInput"><em property="dc:title"><S URI></em>. <span property="dc:description">The URI of an RDF resource.</span></li>
<li property="td:input" resource="#TCC9-I4-P-URI" typeof="tn:TestInput"><em property="dc:title"><P URI></em>. <span property="dc:description">The URI of an RDF property.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
<li property="td:precondition">The LDPC at <LDPC URI> allows POST</li>
<li property="td:precondition">The LDP server does not desire to direct the user agent to retrieve a cacheable resource</li>
<li property="td:precondition"><LDPR representation> is in text/turtle</li>
<li property="td:precondition"><LDPR representation> is a valid representation for a resource to be created in the LDPC</li>
<li property="td:precondition"><LDPR representation> uses null relative URI as the entity in the request body</li>
<li property="td:precondition">The membership subject used by the LDPC is identified by <S URI></li>
<li property="td:precondition">The membership predicate used by the LDPC is identified by <P URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC9-RQ1-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI></div>
<span property="tn:usesInput" resource="#TCC9-I1-LDPC-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCC9-RQ2-POST-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">POST <LDPC URI>
<ul>
<li>[entity-header].Content-type = text/turtle</li>
<li>[message-body] = <LDPR representation></li>
</ul>
</div>
<span property="tn:usesInput" resource="#TCC9-I1-LDPC-URI"> </span>
<span property="tn:usesInput" resource="#TCC9-I2-LDPR-REP"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCC9-RQ3-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI></div>
<span property="tn:usesInput" resource="#TCC9-I1-LDPC-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCC9-RQ4-GET-LOC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <Response 2 POST>.[response-header].Location</div>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC9-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
<span property="tn:fromStep" resource="#TCC9-RQ1-GET-LDPC-URI">
</span>
</li>
<li property="td:output" resource="#TCC9-O2-Response-2-POST" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 2 POST></em>. <span property="dc:description">The response of the POST request in step 2.</span>
<span property="tn:fromStep" resource="#TCC9-RQ2-POST-LDPC-URI">
</span>
</li>
<li property="td:output" resource="#TCC9-O3-Response-3-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 3 GET></em>. <span property="dc:description">The response of the GET request in step 3.</span>
<span property="tn:fromStep" resource="#TCC9-RQ3-GET-LDPC-URI">
</span>
</li>
<li property="td:output" resource="#TCC9-O4-Response-4-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 4 GET></em>. <span property="dc:description">The response of the GET request in step 4.</span>
<span property="tn:fromStep" resource="#TCC9-RQ4-GET-LOC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC9-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC9-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET resource correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC9-A2-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC9-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET container correct</span>):
<div property="dc:description">
<ul>
<li>[message-body] contains <LDPC URI> rdf:type ldp:Container .</li>
<li>[message-body] contains <LDPC URI> ldp:membershipSubject <S URI> .</li>
<li>[message-body] contains <LDPC URI> ldp:membershipPredicate <P URI> . or <LDPC URI> ldp:membershipPredicateInverse <P URI> .</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC9-A3-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC9-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">container does not have member</span>):
<div property="dc:description">
<ul>
<li>[message-body] does not contain <S URI> <P URI> <Response 2
POST>.[response-header].Location .</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC9-A4-Response-2-POST" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC9-O2-Response-2-POST">Assert <Response 2 POST> (<span property="dc:title">POST correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 201</li>
<li>[response-header].Location exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC9-A5-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC9-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">GET resource correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC9-A6-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC9-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">GET container correct</span>):
<div property="dc:description">
<ul>
<li>[message-body] contains <LDPC URI> rdf:type ldp:Container .</li>
<li>[message-body] contains <LDPC URI> ldp:membershipSubject <S URI> .</li>
<li>[message-body] contains <LDPC URI> ldp:membershipPredicate <P URI> . or <LDPC URI> ldp:membershipPredicateInverse <P URI> .</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC9-A7-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC9-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">container has member</span>):
<div property="dc:description">
<ul>
<li>[message-body] contains <S URI> <P URI> <Response 2 POST>.[response-header].Location .</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC9-A8-Response-4-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC9-O4-Response-4-GET">Assert <Response 4 GET> (<span property="dc:title">GET resource correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
</ul>
</section>
<section resource="#TCC10" typeof="td:TestCase">
<h3><a id="TC-C10"><span property="rdfs:label">TC-C10</span>. <span property="dc:title">OPTIONS on an LDPC</span></a></h3>
<p property="dc:description">Tests making an OPTIONS request on an LDPC.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.9.1 LDPR servers MUST support the HTTP OPTIONS method.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.9.2 LDPR servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCC10-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC10-RQ1-OPTIONS-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">OPTIONS <LDPC URI>
</div>
<span property="tn:usesInput" resource="#TCC10-I1-LDPC-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC10-RP1-Response-1-OPTIONS" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 OPTIONS></em>. <span property="dc:description">The response of the OPTIONS request in step 1.</span>
<span property="tn:fromStep" resource="#TCC10-RQ1-OPTIONS-LDPC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC10-A1-Response-1-OPTIONS" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC10-O1-Response-1-OPTIONS">Assert <Response 1 OPTIONS> (<span property="dc:title">OPTIONS correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx<strong> </strong></li>
<li>[entity-header].Allow exists</li>
</ul>
</div>
</div></li>
</ul>
</section>
</section>
<section class="appendix">
<h2><a id="ChangeHistory">Change history</a></h2>
<ul>
<li>2013-08-27 Updated according to Last Call Working Draft from 30 July 2013 (RGC)</li>
<li>2013-06-03 Updated to use ReSpec (RGC)</li>
<li>2013-06-03 Implemented <a href="http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0153.html">changes suggested by Eric Prud'hommeaux</a> (RGC)</li>
</ul>
</section>
<section class="appendix">
<h2><a id="EditorNotes">Editor TODOs and notes</a></h2>
<ul>
<li>Define the type of document: Working Draft, Note, etc.</li>
<li>Choose a URI for the test cases (this) document</li>
<li>Choose a namespace for the new vocabulary terms and for the test cases</li>
<li>Include the RDF description of the test suite</li>
</ul>
</section>
</body>
</html>
\ No newline at end of file
+ García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.3.4 [...] If the client does not indicate a preference, text/turtle SHOULD be returned.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCR2-I1-LDPR-URI" typeof="tn:TestInput"><em property="dc:title"><LDPR URI></em>. <span property="dc:description">The URI of an LDPR.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPR at <LDPR URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCR2-RQ1-GET-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPR URI></div>
<span property="tn:usesInput" resource="#TCR2-I1-LDPR-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCR2-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span> <span property="tn:fromStep"
resource="#TCR2-RQ1-GET-LDPR-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCR2-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR2-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[entity-header].Content-Type = text/turtle</li>
</ul>
</div>
</div></li>
</ul>
</section>
-->
<section resource="#TCR3" typeof="td:TestCase">
<h3><a id="TC-R3"><span property="rdfs:label">TC-R3</span>. <span property="dc:title">GET on a non-existing LDPR</span></a></h3>
<p property="dc:description">Tests making a GET request on a non-existing LDPR.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.6.1 LDPR servers MUST remove the resource identified by the Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET on the same Request-URI MUST result in a 404 (Not found) or 410 (Gone) status code.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCR3-I1-LDPR-URI" typeof="tn:TestInput"><em property="dc:title"><LDPR URI></em>. <span property="dc:description">The URI of a non-existing LDPR.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server does not contain an LDPR at <LDPR URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCR3-RQ1-GET-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPR URI></div>
<span property="tn:usesInput" resource="#TCR3-I1-LDPR-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCR3-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
<span property="tn:fromStep" resource="#TCR3-RQ1-GET-LDPR-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCR3-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR3-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET incorrect</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 404 or 410</li>
</ul>
</div>
</div></li>
</ul>
</section>
<!-- RGC: Test removed since 4.5.2 is not an absolute requirement
<section resource="#TCR4" typeof="td:TestCase">
<h3><a id="TC-R4"><span property="rdfs:label">TC-R4</span>. <span property="dc:title">PUT on an LDPR</span></a></h3>
<p property="dc:description">Tests making a PUT request on an LDPR.</p> <p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a>:</em></p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to the resource's HTTP Request-URI. [...]</span><span
property="rdfs:seeAlso"
href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<p><em><a target="_blank" href="http://tools.ietf.org/html/rfc2616" property="rdfs:seeAlso">Hypertext Transfer Protocol - HTTP/1.1</a>:</em></p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">3.11 [...] An entity tag MUST be unique across all versions of all entities associated with a particular resource.</span><span property="rdfs:seeAlso" href="http://tools.ietf.org/html/rfc2616"></span></div>
</li>
</ul>
<h4>Input </h4>
<ul>
<li property="td:input" resource="#TCR4-I1-LDPR-URI" typeof="tn:TestInput"><em property="dc:title"><LDPR URI></em>. <span property="dc:description">The URI of an LDPR.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPR at <LDPR URI></li>
<li property="td:precondition">The LDPR at <LDPR URI> allows PUT</li>
<li property="td:precondition">The LDP server allows updating in the LDPR the current representation at <LDPR URI></li>
<li property="td:precondition">The LDP server does not desire that the request be applied to a different URI</li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCR4-RQ1-GET-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPR URI></div>
<span property="tn:usesInput" resource="#TCR4-I1-LDPR-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCR4-RQ2-PUT-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">PUT <LDPR URI>
<ul>
<li>[request-header].If-Match = <Response GET 1>.[response-header].ETag</li>
<li>[message-body] = <Response GET 1>.[message-body]</li>
</ul>
</div>
<span property="tn:usesInput" resource="#TCR4-I1-LDPR-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCR4-RQ3-GET-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPR URI></div>
<span property="tn:usesInput" resource="#TCR4-I1-LDPR-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCR4-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
<span property="tn:fromStep" resource="#TCR4-RQ1-GET-LDPR-URI">
</span>
</li>
<li property="td:output" resource="#TCR4-O2-Response-2-PUT" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 2 PUT></em>. <span property="dc:description">The response of the PUT request in step 2.</span>
<span property="tn:fromStep" resource="#TCR4-RQ2-PUT-LDPR-URI">
</span>
</li>
<li property="td:output" resource="#TCR4-O3-Response-3-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 3 GET></em>. <span property="dc:description">The response of the GET request in step 3.</span>
<span property="tn:fromStep" resource="#TCR4-RQ3-GET-LDPR-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCR4-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR4-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCR4-A2-Response-2-PUT" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR4-O2-Response-2-PUT">Assert <Response 2 PUT> (<span property="dc:title">PUT correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCR4-A3-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR4-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">GET correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCR4-A4-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR4-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">LDPR updated</span>):
<div property="dc:description">
<ul>
<li>[response-header].ETag != <Response 1 GET>.[response-header].ETag</li>
</ul>
</div>
</div></li>
</ul>
</section>
-->
<!-- RGC: Test removed since 4.5.2 is not an absolute requirement
<section resource="#TCR5" typeof="td:TestCase">
<h3><a id="TC-R5"><span property="rdfs:label">TC-R5</span>. <span property="dc:title">PUT on an LDPR without matching ETags</span></a></h3>
<p property="dc:description">Tests making a PUT request on an LDPR without matching ETags.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.5.2 [...] LDPR servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request. [...]</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input </h4>
<ul>
<li property="td:input" resource="#TCR5-I1-LDPR-URI" typeof="tn:TestInput"><em property="dc:title"><LDPR URI></em>. <span property="dc:description">The URI of an LDPR.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPR at <LDPR URI></li>
<li property="td:precondition">The LDPR at <LDPR URI> allows PUT</li>
<li property="td:precondition">The LDP server allows updating in the LDPR the current representation at <LDPR URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCR5-RQ1-GET-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPR URI></div>
<span property="tn:usesInput" resource="#TCR5-I1-LDPR-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCR5-RQ2-PUT-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">PUT <LDPR URI>
<ul>
<li>[request-header].If-Match = <Response GET 1>.[response-header].ETag + 'M'</li>
<li>[message-body] = <Response GET 1>.[message-body]</li>
</ul>
</div>
<span property="tn:usesInput" resource="#TCR5-I1-LDPR-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCR5-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
<span property="tn:fromStep" resource="#TCR5-RQ1-GET-LDPR-URI">
</span>
</li>
<li property="td:output" resource="#TCR5-O2-Response-2-PUT" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 2 PUT></em>. <span property="dc:description">The response of the PUT request in step 2.</span>
<span property="tn:fromStep" resource="#TCR5-RQ2-PUT-LDPR-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCR5-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR5-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCR5-A2-Response-2-PUT" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR5-O2-Response-2-PUT">Assert <Response 2 PUT> (<span property="dc:title">PUT incorrect</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 412</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
</ul>
</section>
-->
<section resource="#TCR6" typeof="td:TestCase">
<h3><a id="TC-R6"><span property="rdfs:label">TC-R6</span>. <span property="dc:title">DELETE on an LDPR</span></a></h3>
<p property="dc:description">Tests making a DELETE request on an LDPR.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to the resource's HTTP Request-URI. [...]</span><span
property="rdfs:seeAlso"
href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.6.1 LDPR servers MUST remove the resource identified by the Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET on the same Request-URI MUST result in a 404 (Not found) or 410 (Gone) status code.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCR6-I1-LDPR-URI" typeof="tn:TestInput"><em property="dc:title"><LDPR URI></em>. <span property="dc:description">The URI of an LDPR.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPR at <LDPR URI></li>
<li property="td:precondition">The LDPR at <LDPR URI> allows DELETE</li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCR6-RQ1-DELETE-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">DELETE <LDPR URI>
</div>
<span property="tn:usesInput" resource="#TCR6-I1-LDPR-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCR6-RQ2-GET-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPR URI></div>
<span property="tn:usesInput" resource="#TCR6-I1-LDPR-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCR6-O1-Response-1-DELETE" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 DELETE></em>. <span property="dc:description">The response of the DELETE request in step 1.</span>
<span property="tn:fromStep" resource="#TCR6-RQ1-DELETE-LDPR-URI">
</span>
</li>
<li property="td:output" resource="#TCR6-O2-Response-2-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 2 GET></em>. <span property="dc:description">The response of the GET request in step 2.</span>
<span property="tn:fromStep" resource="#TCR6-RQ2-GET-LDPR-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCR6-A1-Response-1-DELETE" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR6-O1-Response-1-DELETE">Assert <Response 1 DELETE> (<span property="dc:title">DELETE correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCR6-A2-Response-1-DELETE" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR6-O1-Response-1-DELETE">Assert <Response 1 DELETE> <Response 2 GET> (<span property="dc:title">DELETE resource correct</span>):
<div property="dc:description">
<ul>
<li><Response 1 DELETE>.[Status-Line].Status-Code = 200 or 204 and <Response 2 GET>.[Status-Line].Status-Code = 404 or 410</li>
<li>or </li>
<li><Response 1 DELETE>.[Status-Line].Status-Code = 2xx (except 200 and 204) </li>
</ul>
</div>
</div></li>
</ul>
</section>
<section resource="#TCR7" typeof="td:TestCase">
<h3><a id="TC-R7"><span property="rdfs:label">TC-R7</span>. <span property="dc:title">HEAD on an LDPR</span></a></h3>
<p property="dc:description">Tests making a HEAD request on an LDPR.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to the resource's HTTP Request-URI. [...]</span><span
property="rdfs:seeAlso"
href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.7.1 LDPR servers MUST support the HTTP HEAD method.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<p><em><a target="_blank" href="http://tools.ietf.org/html/rfc2616" property="rdfs:seeAlso">Hypertext Transfer Protocol - HTTP/1.1</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">9.4 The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response.</span><span property="rdfs:seeAlso" href="http://tools.ietf.org/html/rfc2616"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCR7-I1-LDPR-URI" typeof="tn:TestInput"><em property="dc:title"><LDPR URI></em>. <span property="dc:description">The URI of an LDPR.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPR at <LDPR URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCR7-RQ1-HEAD-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">HEAD <LDPR URI>
</div>
<span property="tn:usesInput" resource="#TCR7-I1-LDPR-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCR7-O1-Response-1-HEAD" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 HEAD></em>. <span property="dc:description">The response of the HEAD request in step 1.</span>
<span property="tn:fromStep" resource="#TCR7-RQ1-HEAD-LDPR-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCR7-A1-Response-1-HEAD" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR7-O1-Response-1-HEAD">Assert <Response 1 HEAD> (<span property="dc:title">HEAD correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
<li>[message-body] not exists</li>
</ul>
</div>
</div></li>
</ul>
</section>
<section resource="#TCR8" typeof="td:TestCase">
<h3><a id="TC-R8"><span property="rdfs:label">TC-R8</span>. <span property="dc:title">OPTIONS on an LDPR</span></a></h3>
<p property="dc:description">Tests making an OPTIONS request on an LDPR.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.9.1 LDPR servers MUST support the HTTP OPTIONS method.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.9.2 LDPR servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCR8-I1-LDPR-URI" typeof="tn:TestInput"><em property="dc:title"><LDPR URI></em>. <span property="dc:description">The URI of an LDPR.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPR at <LDPR URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCR8-RQ1-OPTIONS-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">OPTIONS <LDPR URI>
</div>
<span property="tn:usesInput" resource="#TCR8-I1-LDPR-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCR8-RP1-Response-1-OPTIONS" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 OPTIONS></em>. <span property="dc:description">The response of the OPTIONS request in step 1.</span>
<span property="tn:fromStep" resource="#TCR8-RQ1-OPTIONS-LDPR-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCR8-A1-Response-1-OPTIONS" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCR8-O1-Response-1-OPTIONS">Assert <Response 1 OPTIONS> (<span property="dc:title">OPTIONS correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx<strong> </strong></li>
<li>[entity-header].Allow exists</li>
</ul>
</div>
</div></li>
</ul>
</section>
</section>
<section>
<h2><a id="Tests-LDPCs"></a>Tests for LDPCs</h2>
<p>These tests involve LDPCs and LDPRs.</p>
<section resource="#TCC1" typeof="td:TestCase">
<h3><a id="TC-C1"><span property="rdfs:label">TC-C1</span>. <span property="dc:title">GET on an LDPC</span></a></h3>
<p property="dc:description">Tests making a GET request on an LDPC.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.8 LDPR server responses MUST use entity tags (either weak or strong ones) as response ETag header values.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to the resource's HTTP Request-URI. [...]</span><span
property="rdfs:seeAlso"
href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.3.1 LDPR servers MUST support the HTTP GET Method for LDPRs.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.2.7 The representation of a LDPC MUST have rdf:type of ldp:Container, [...].</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.2.4 An LDPC representation MUST contain exactly one triple whose subject is the LDPC URI, whose predicate is the ldp:membershipSubject, and whose object is the LDPC's membership subject URI.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.2.5 An LDPC representation MUST contain exactly one triple whose subject is the LDPC URI, and whose predicate is either ldp:membershipPredicate or ldp:membershipPredicateInverse. [...]</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.2.5.1 For a given triple T with a subject C of the LDPC and predicate of ldp:membershipPredicate, the object MUST be the URI of the membership predicate P used to indicate membership to the linked to LDPC, [...]</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.2.5.2 For a given triple T with a subject C of the LDPC and predicate of ldp:membershipPredicateInverse, the object MUST be the URI of the membership predicate P used to indicate membership to the linked to LDPC, [...]</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCC1-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
<li property="td:input" resource="#TCC1-I2-S-URI" typeof="tn:TestInput"><em property="dc:title"><S URI></em>. <span property="dc:description">The URI of an RDF resource.</span></li>
<li property="td:input" resource="#TCC1-I3-P-URI" typeof="tn:TestInput"><em property="dc:title"><P URI></em>. <span property="dc:description">The URI of an RDF property.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
<li property="td:precondition">The membership subject used by the LDPC is identified by <S URI></li>
<li property="td:precondition">The membership predicate used by the LDPC is identified by <P URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC1-RQ1-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI></div>
<span property="tn:usesInput" resource="#TCC1-I1-LDPC-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC1-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
<span property="tn:fromStep" resource="#TCC1-RQ1-GET-LDPC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC1-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC1-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET resource correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC1-A2-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC1-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET container correct</span>):
<div property="dc:description">
<ul>
<li>[message-body] contains <LDPC URI> rdf:type ldp:Container .</li>
<li>[message-body] contains <LDPC URI> ldp:membershipSubject <S URI> .</li>
<li>[message-body] contains <LDPC URI> ldp:membershipPredicate <P URI> . or <LDPC URI> ldp:membershipPredicateInverse <P URI> .</li>
</ul>
</div>
</div></li>
</ul>
</section>
<!-- RGC: Test removed since 4.3.4 is no longer an absolute requirement
<section resource="#TCC2" typeof="td:TestCase">
<h3><a id="TC-C2"><span property="rdfs:label">TC-C2</span>. <span property="dc:title">GET on an LDPC without content type</span></a></h3>
<p property="dc:description">Tests making a GET request on an LDPC without content type.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.3.4 [...] If the client does not indicate a preference, text/turtle SHOULD be returned.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCC2-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC2-RQ1-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI>
</div>
<span property="tn:usesInput" resource="#TCC2-I1-LDPC-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC2-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
<span property="tn:fromStep" resource="#TCC2-RQ1-GET-LDPC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC2-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC2-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET resource correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[entity-header].Content-Type = text/turtle</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC2-A2-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC2-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET container correct</span>):
<div property="dc:description">
<ul>
<li>[message-body] contains rdf:type ldp:Container</li>
</ul>
</div>
</div></li>
</ul>
</section>
-->
<section resource="#TCC3" typeof="td:TestCase">
<h3><a id="TC-C3"><span property="rdfs:label">TC-C3</span>. <span property="dc:title">GET on a non-existing LDPC</span></a></h3>
<p property="dc:description">Tests making a GET request on an non-existing LDPC.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.6.1 LDPR servers MUST remove the resource identified by the Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET on the same Request-URI MUST result in a 404 (Not found) or 410 (Gone) status code.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCC3-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of a non-existing LDPC.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server does not contain an LDPC at <LDPC URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC3-RQ1-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI></div>
<span property="tn:usesInput" resource="#TCC3-I1-LDPC-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC3-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
<span property="tn:fromStep" resource="#TCC3-RQ1-GET-LDPC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC3-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC3-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET incorrect</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 404 or 410</li>
</ul>
</div>
</div></li>
</ul>
</section>
<!-- RGC: Test removed since 4.5.2 is not an absolute requirement
<section resource="#TCC4" typeof="td:TestCase">
<h3><a id="TC-C4"><span property="rdfs:label">TC-C4</span>. <span property="dc:title">PUT on an LDPC</span></a></h3>
<p property="dc:description">Tests making a PUT request on an LDPC.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a>:</em></p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to the resource's HTTP Request-URI. [...]</span><span
property="rdfs:seeAlso"
href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<p><em><a target="_blank" href="http://tools.ietf.org/html/rfc2616" property="rdfs:seeAlso">Hypertext Transfer Protocol - HTTP/1.1</a>:</em></p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">3.11 [...] An entity tag MUST be unique across all versions of all entities associated with a particular resource.</span><span property="rdfs:seeAlso" href="http://tools.ietf.org/html/rfc2616"></span></div>
</li>
</ul>
<h4>Input </h4>
<ul>
<li property="td:input" resource="#TCC4-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
<li property="td:precondition">The LDPC at <LDPC URI> allows PUT</li>
<li property="td:precondition">The LDP server allows updating in the LDPC the current representation at <LDPC URI></li>
<li property="td:precondition">The LDP server does not desire that the request be applied to a different URI</li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC4-RQ1-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI></div>
<span property="tn:usesInput" resource="#TCC4-I1-LDPC-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCC4-RQ2-PUT-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">PUT <LDPC URI>
<ul>
<li>[request-header].If-Match = <Response GET 1>.[response-header].ETag</li>
<li>[message-body] = <Response GET 1>.[message-body]</li>
</ul>
</div>
<span property="tn:usesInput" resource="#TCC4-I1-LDPC-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCC4-RQ3-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI></div>
<span property="tn:usesInput" resource="#TCC4-I1-LDPC-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC4-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
<span property="tn:fromStep" resource="#TCC4-RQ1-GET-LDPC-URI">
</span>
</li>
<li property="td:output" resource="#TCC4-O2-Response-2-PUT" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 2 PUT></em>. <span property="dc:description">The response of the PUT request in step 2.</span>
<span property="tn:fromStep" resource="#TCC4-RQ2-PUT-LDPC-URI">
</span>
</li>
<li property="td:output" resource="#TCC4-O3-Response-3-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 3 GET></em>. <span property="dc:description">The response of the GET request in step 3.</span>
<span property="tn:fromStep" resource="#TCC4-RQ3-GET-LDPC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC4-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC4-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET resource correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC4-A2-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC4-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET container correct</span>):
<div property="dc:description">
<ul>
<li>[message-body] contains rdf:type ldp:Container</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC4-A3-Response-2-PUT" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC4-O2-Response-2-PUT">Assert <Response 2 PUT> (<span property="dc:title">PUT correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC4-A4-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC4-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">GET resource correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC4-A5-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC4-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">GET container correct</span>):
<div property="dc:description">
<ul>
<li>[message-body] contains rdf:type ldp:Container</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC4-A6-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC4-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">LDPC updated</span>):
<div property="dc:description">
<ul>
<li>[response-header].ETag != <Response 1 GET>.[response-header].ETag</li>
</ul>
</div>
</div></li>
</ul>
</section>
-->
<!-- RGC: Test removed since 4.5.2 is not an absolute requirement
<section resource="#TCC5" typeof="td:TestCase">
<h3><a id="TC-C5"><span property="rdfs:label">TC-C5</span>. <span property="dc:title">PUT on an LDPC without matching ETags</span></a></h3>
<p property="dc:description">Tests making a PUT request on an LDPC without matching ETags.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.5.2 [...] LDPR servers MUST respond with status code 412 (Condition Failed) if ETags fail to match when there are no other errors with the request. [...]</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCC5-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
<li property="td:precondition">The LDPC at <LDPC URI> allows PUT</li>
<li property="td:precondition">The LDP server allows updating in the LDPC the current representation at <LDPC URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC5-RQ1-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI></div>
<span property="tn:usesInput" resource="#TCC5-I1-LDPC-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCC5-RQ2-PUT-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">PUT <LDPC URI>
<ul>
<li>[request-header].If-Match = <Response GET 1>.[response-header].ETag + 'M'</li>
<li>[message-body] = <Response GET 1>.[message-body]</li>
</ul>
</div>
<span property="tn:usesInput" resource="#TCC5-I1-LDPC-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC5-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
<span property="tn:fromStep" resource="#TCC5-RQ1-GET-LDPC-URI">
</span>
</li>
<li property="td:output" resource="#TCC5-O2-Response-2-PUT" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 2 PUT></em>. <span property="dc:description">The response of the PUT request in step 2.</span>
<span property="tn:fromStep" resource="#TCC5-RQ2-PUT-LDPC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC5-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC5-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET resource correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC5-A2-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC5-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET container correct</span>):
<div property="dc:description">
<ul>
<li>[message-body] contains rdf:type ldp:Container</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC5-A3-Response-2-PUT" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC5-O2-Response-2-PUT">Assert <Response 2 PUT> (<span property="dc:title">PUT correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 412</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
</ul>
</section>
-->
<section resource="#TCC6" typeof="td:TestCase">
<h3><a id="TC-C6"><span property="rdfs:label">TC-C6</span>. <span property="dc:title">DELETE on an LDPC</span></a></h3>
<p property="dc:description">Tests making a DELETE request on an LDPC.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to the resource's HTTP Request-URI. [...]</span><span
property="rdfs:seeAlso"
href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.6.1 LDPR servers MUST remove the resource identified by the Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET on the same Request-URI MUST result in a 404 (Not found) or 410 (Gone) status code.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCC6-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
<li property="td:precondition">The LDPC at <LDPC URI> allows DELETE</li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC6-RQ1-DELETE-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">DELETE <LDPC URI>
</div>
<span property="tn:usesInput" resource="#TCC6-I1-LDPC-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCC6-RQ2-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI></div>
<span property="tn:usesInput" resource="#TCC6-I1-LDPC-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC6-O1-Response-1-DELETE" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 DELETE></em>. <span property="dc:description">The response of the DELETE request in step 1.</span>
<span property="tn:fromStep" resource="#TCC6-RQ1-DELETE-LDPC-URI">
</span>
</li>
<li property="td:output" resource="#TCC6-O2-Response-2-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 2 GET></em>. <span property="dc:description">The response of the GET request in step 2.</span>
<span property="tn:fromStep" resource="#TCC6-RQ2-GET-LDPC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC6-A1-Response-1-DELETE" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC6-O1-Response-1-DELETE">Assert <Response 1 DELETE> (<span property="dc:title">DELETE correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC6-A2-Response-1-DELETE" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC6-O1-Response-1-DELETE">Assert <Response 1 DELETE> <Response 2 GET> (<span property="dc:title">DELETE resource correct</span>):
<div property="dc:description">
<ul>
<li><Response 1 DELETE>.[Status-Line].Status-Code = 200 or 204 and <Response 2 GET>.[Status-Line].Status-Code = 404 or 410</li>
<li>or </li>
<li><Response 1 DELETE>.[Status-Line].Status-Code = 2xx (except 200 and 204)</li>
</ul>
</div>
</div></li>
</ul>
</section>
<section resource="#TCC7" typeof="td:TestCase">
<h3><a id="TC-C7"><span property="rdfs:label">TC-C7</span>. <span property="dc:title">DELETE on an LDPR in an LDPC</span></a></h3>
<p property="dc:description">Tests making a DELETE request on an LDPR in an LDPC.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.6.2 When the LDPC server successfully completes the DELETE request on a LDPC, it MUST remove any membership triples associated with the LDPC as indicated by the canonical Request-URI. [...]</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCC7-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
<li property="td:input" resource="#TCC7-I2-LDPR-URI" typeof="tn:TestInput"><em property="dc:title"><LDPR URI></em>. <span property="dc:description">The URI of an LDPR that is a member of the LDPC.</span></li>
<li property="td:input" resource="#TCC7-I3-S-URI" typeof="tn:TestInput"><em property="dc:title"><S URI></em>. <span property="dc:description">The URI of an RDF resource.</span></li>
<li property="td:input" resource="#TCC7-I4-P-URI" typeof="tn:TestInput"><em property="dc:title"><P URI></em>. <span property="dc:description">The URI of an RDF property.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
<li property="td:precondition">The LDP server contains an LDPR at <LDPR URI></li>
<li property="td:precondition">The LDPR is a member of the LDPC</li>
<li property="td:precondition">The LDPR at <LDPR URI> allows DELETE</li>
<li property="td:precondition">The LDPR was originally created by the LDPC</li>
<li property="td:precondition">The membership subject used by the LDPC is identified by <S URI></li>
<li property="td:precondition">The membership predicate used by the LDPC is identified by <P URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC7-RQ1-DELETE-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">DELETE <LDPR URI>
</div>
<span property="tn:usesInput" resource="#TCC7-I2-LDPR-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCC7-RQ2-GET-LDPR-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPR URI></div>
<span property="tn:usesInput" resource="#TCC7-I2-LDPR-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCC7-RQ3-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI></div>
<span property="tn:usesInput" resource="#TCC7-I1-LDPC-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC7-O1-Response-1-DELETE" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 DELETE></em>. <span property="dc:description">The response of the DELETE request in step 1.</span>
<span property="tn:fromStep" resource="#TCC7-RQ1-DELETE-LDPR-URI">
</span>
</li>
<li property="td:output" resource="#TCC7-O2-Response-2-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 2 GET></em>. <span property="dc:description">The response of the GET request in step 2.</span>
<span property="tn:fromStep" resource="#TCC7-RQ2-GET-LDPR-URI">
</span>
</li>
<li property="td:output" resource="#TCC7-O3-Response-3-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 3 GET></em>. <span property="dc:description">The response of the GET request in step 3.</span>
<span property="tn:fromStep" resource="#TCC7-RQ3-GET-LDPC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC7-A1-Response-1-DELETE" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC7-O1-Response-1-DELETE">Assert <Response 1 DELETE> (<span property="dc:title">DELETE correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC7-A2-Response-1-DELETE" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC7-O1-Response-1-DELETE">Assert <Response 1 DELETE> <Response 2 GET> (<span property="dc:title">DELETE resource correct</span>):
<div property="dc:description">
<ul>
<li><Response 1 DELETE>.[Status-Line].Status-Code = 200 or 204 and <Response 2 GET>.[Status-Line].Status-Code = 404 or 410</li>
<li>or </li>
<li><Response 1 DELETE>.[Status-Line].Status-Code = 2xx (except 200 and 204)</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC7-A3-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC7-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">GET resource correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC7-A4-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC7-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">GET container correct</span>):
<div property="dc:description">
<ul>
<li>[message-body] contains <LDPC URI> rdf:type ldp:Container .</li>
<li>[message-body] contains <LDPC URI> ldp:membershipSubject <S URI> .</li>
<li>[message-body] contains <LDPC URI> ldp:membershipPredicate <P URI> . or <LDPC URI> ldp:membershipPredicateInverse <P URI> .</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC7-A5-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC7-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">member removed from container</span>)
<div property="dc:description">
<ul>
<li>[message-body] does not contain <S URI> <P URI> <LDPR URI> .</li>
</ul>
</div>
</div></li>
</ul>
</section>
<section resource="#TCC8" typeof="td:TestCase">
<h3><a id="TC-C8"><span property="rdfs:label">TC-C8</span>. <span property="dc:title">HEAD on an LDPC</span></a></h3>
<p property="dc:description">Tests making a HEAD request on an LDPC.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to the resource's HTTP Request-URI. [...]</span><span
property="rdfs:seeAlso"
href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.7.1 LDPR servers MUST support the HTTP HEAD method.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<p><a target="_blank" href="http://tools.ietf.org/html/rfc2616" property="rdfs:seeAlso"><em>Hypertext Transfer Protocol - HTTP/1.1</em></a>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">9.4 The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response.</span><span property="rdfs:seeAlso" href="http://tools.ietf.org/html/rfc2616"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCC8-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC8-RQ1-HEAD-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">HEAD <LDPC URI>
</div>
<span property="tn:usesInput" resource="#TCC8-I1-LDPC-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC8-O1-Response-1-HEAD" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 HEAD></em>. <span property="dc:description">The response of the HEAD request in step 1.</span>
<span property="tn:fromStep" resource="#TCC8-RQ1-HEAD-LDPC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC8-A1-Response-1-HEAD" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC8-O1-Response-1-HEAD">Assert <Response 1 HEAD> (<span property="dc:title">HEAD correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
<li>[message-body] not exists</li>
</ul>
</div>
</div></li>
</ul>
</section>
<section resource="#TCC9" typeof="td:TestCase">
<h3><a id="TC-C9"><span property="rdfs:label">TC-C9</span>. <span property="dc:title">POST an LDPR on an LDPC</a></h3>
<p property="dc:description">Tests making a POST request of an LDPR on an LDPC.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel="type") in all responses to requests made to the resource's HTTP Request-URI. [...]</span><span
property="rdfs:seeAlso"
href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.4.1 [...] If the resource was created successfully, LDPC servers MUST respond with status code 201 (Created) and the Location header set to the new resource’s URL. [...] </span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.4.2 After a successful HTTP POST request to a LDPC, the new resource MUST appear as a member of the LDPC until the new resource is deleted or removed by other methods. [...] </span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.4.4 For servers that support create, LDPC servers MUST create an LDPR from a RDF representation in the request entity body. [...]</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">5.4.5 LDPC servers MUST accept a request entity body with a request header of Content-Type with value of text/turtle. </span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCC9-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
<li property="td:input" resource="#TCC9-I2-LDPR-REP" typeof="tn:TestInput"><em property="dc:title"><LDPR representation></em>. <span property="dc:description">The representation of the LDPR to be created</span></li>
<li property="td:input" resource="#TCC9-I3-S-URI" typeof="tn:TestInput"><em property="dc:title"><S URI></em>. <span property="dc:description">The URI of an RDF resource.</span></li>
<li property="td:input" resource="#TCC9-I4-P-URI" typeof="tn:TestInput"><em property="dc:title"><P URI></em>. <span property="dc:description">The URI of an RDF property.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
<li property="td:precondition">The LDPC at <LDPC URI> allows POST</li>
<li property="td:precondition">The LDP server does not desire to direct the user agent to retrieve a cacheable resource</li>
<li property="td:precondition"><LDPR representation> is in text/turtle</li>
<li property="td:precondition"><LDPR representation> is a valid representation for a resource to be created in the LDPC</li>
<li property="td:precondition"><LDPR representation> uses null relative URI as the entity in the request body</li>
<li property="td:precondition">The membership subject used by the LDPC is identified by <S URI></li>
<li property="td:precondition">The membership predicate used by the LDPC is identified by <P URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC9-RQ1-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI></div>
<span property="tn:usesInput" resource="#TCC9-I1-LDPC-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCC9-RQ2-POST-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">POST <LDPC URI>
<ul>
<li>[entity-header].Content-type = text/turtle</li>
<li>[message-body] = <LDPR representation></li>
</ul>
</div>
<span property="tn:usesInput" resource="#TCC9-I1-LDPC-URI"> </span>
<span property="tn:usesInput" resource="#TCC9-I2-LDPR-REP"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCC9-RQ3-GET-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <LDPC URI></div>
<span property="tn:usesInput" resource="#TCC9-I1-LDPC-URI"> </span>
</li>
<li inlist="" property="tn:testProcess" resource="#TCC9-RQ4-GET-LOC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">GET <Response 2 POST>.[response-header].Location</div>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC9-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
<span property="tn:fromStep" resource="#TCC9-RQ1-GET-LDPC-URI">
</span>
</li>
<li property="td:output" resource="#TCC9-O2-Response-2-POST" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 2 POST></em>. <span property="dc:description">The response of the POST request in step 2.</span>
<span property="tn:fromStep" resource="#TCC9-RQ2-POST-LDPC-URI">
</span>
</li>
<li property="td:output" resource="#TCC9-O3-Response-3-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 3 GET></em>. <span property="dc:description">The response of the GET request in step 3.</span>
<span property="tn:fromStep" resource="#TCC9-RQ3-GET-LDPC-URI">
</span>
</li>
<li property="td:output" resource="#TCC9-O4-Response-4-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 4 GET></em>. <span property="dc:description">The response of the GET request in step 4.</span>
<span property="tn:fromStep" resource="#TCC9-RQ4-GET-LOC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC9-A1-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC9-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET resource correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC9-A2-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC9-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET container correct</span>):
<div property="dc:description">
<ul>
<li>[message-body] contains <LDPC URI> rdf:type ldp:Container .</li>
<li>[message-body] contains <LDPC URI> ldp:membershipSubject <S URI> .</li>
<li>[message-body] contains <LDPC URI> ldp:membershipPredicate <P URI> . or <LDPC URI> ldp:membershipPredicateInverse <P URI> .</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC9-A3-Response-1-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC9-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">container does not have member</span>):
<div property="dc:description">
<ul>
<li>[message-body] does not contain <S URI> <P URI> <Response 2
POST>.[response-header].Location .</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC9-A4-Response-2-POST" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC9-O2-Response-2-POST">Assert <Response 2 POST> (<span property="dc:title">POST correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 201</li>
<li>[response-header].Location exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC9-A5-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC9-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">GET resource correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC9-A6-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC9-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">GET container correct</span>):
<div property="dc:description">
<ul>
<li>[message-body] contains <LDPC URI> rdf:type ldp:Container .</li>
<li>[message-body] contains <LDPC URI> ldp:membershipSubject <S URI> .</li>
<li>[message-body] contains <LDPC URI> ldp:membershipPredicate <P URI> . or <LDPC URI> ldp:membershipPredicateInverse <P URI> .</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC9-A7-Response-3-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC9-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">container has member</span>):
<div property="dc:description">
<ul>
<li>[message-body] contains <S URI> <P URI> <Response 2 POST>.[response-header].Location .</li>
</ul>
</div>
</div></li>
<li property="tn:testAssertion" resource="#TCC9-A8-Response-4-GET" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC9-O4-Response-4-GET">Assert <Response 4 GET> (<span property="dc:title">GET resource correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx</li>
<li>[response-header].ETag exists</li>
<li>[response-header].Link = ldp:Resource; rel="type"</li>
</ul>
</div>
</div></li>
</ul>
</section>
<section resource="#TCC10" typeof="td:TestCase">
<h3><a id="TC-C10"><span property="rdfs:label">TC-C10</span>. <span property="dc:title">OPTIONS on an LDPC</span></a></h3>
<p property="dc:description">Tests making an OPTIONS request on an LDPC.</p>
<p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Raúl García-Castro</span> <span property="owl:sameAs" href="http://delicias.dia.fi.upm.es/%7Ergarcia/#me"></span></p>
<p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
<h4>Related specification</h4>
<p><em><a target="_blank" href="http://www.w3.org/TR/ldp/" property="rdfs:seeAlso">Linked Data Platform 1.0</a></em>:</p>
<ul>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.9.1 LDPR servers MUST support the HTTP OPTIONS method.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
<li property="td:specificationReference" typeof="tn:Excerpt">
<div><span property="tn:includesText">4.9.2 LDPR servers MUST indicate their support for HTTP Methods by responding to a HTTP OPTIONS request on the LDPR’s URL with the HTTP Method tokens in the HTTP response header Allow.</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
</li>
</ul>
<h4>Input</h4>
<ul>
<li property="td:input" resource="#TCC10-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
</ul>
<h4>Preconditions</h4>
<ul>
<li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
</ul>
<h4>Process</h4>
<ol>
<li inlist="" property="tn:testProcess" resource="#TCC10-RQ1-OPTIONS-LDPC-URI" typeof="tn:Step ht:Request">
<div property="dc:description">OPTIONS <LDPC URI>
</div>
<span property="tn:usesInput" resource="#TCC10-I1-LDPC-URI"> </span>
</li>
</ol>
<h4>Output</h4>
<ul>
<li property="td:output" resource="#TCC10-RP1-Response-1-OPTIONS" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 OPTIONS></em>. <span property="dc:description">The response of the OPTIONS request in step 1.</span>
<span property="tn:fromStep" resource="#TCC10-RQ1-OPTIONS-LDPC-URI">
</span>
</li>
</ul>
<h4>Assertions</h4>
<ul>
<li property="tn:testAssertion" resource="#TCC10-A1-Response-1-OPTIONS" typeof="tn:TestAssertion"><div property="tn:outputAsserted" resource="TCC10-O1-Response-1-OPTIONS">Assert <Response 1 OPTIONS> (<span property="dc:title">OPTIONS correct</span>):
<div property="dc:description">
<ul>
<li>[Status-Line].Status-Code = 2xx<strong> </strong></li>
<li>[entity-header].Allow exists</li>
</ul>
</div>
</div></li>
</ul>
</section>
+
+ <section resource="#TCC11" typeof="td:TestCase">
+ <h3><a id="TC-C11"><span property="rdfs:label">TC-C11</span>. <span property="dc:title">POST an LDPC on an LDPC as a sub-container</span></a></h3>
+ <p property="dc:description">Tests making a POST request of an LDPC on an LDPC as a sub-container.</p>
+ <p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Eric Prud'hommeaux</span> <span property="owl:sameAs" href="http://www.w3.org/People/Eric/ericP-foaf#ericP"></span></p>
+ <p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
+ <h4>Related specification</h4>
+ <p>see <a href="#TC-C9">TC-C9</a></p>
+ <!-- ul>
+ <li property="td:specificationReference" typeof="tn:Excerpt">
+ <div><span property="tn:includesText">4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel=profile) in all responses to requests made to the resource's HTTP Request-URI. [...]</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
+ </li>
+ <li property="td:specificationReference" typeof="tn:Excerpt"> <div><span property="tn:includesText">5.4.1 [...] If the resource was created successfully, LDPC servers MUST respond with status code 201 (Created) and the Location header set to the new resource’s URL. [...] </span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div> </li>
+ <li property="td:specificationReference" typeof="tn:Excerpt"> <div><span property="tn:includesText">5.4.2 After a successful HTTP POST request to a LDPC, the new resource MUST appear as a member of the LDPC until the new resource is deleted or removed by other methods. [...] </span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div> </li>
+ <li property="td:specificationReference" typeof="tn:Excerpt"> <div><span property="tn:includesText">5.4.4 For servers that support create, LDPC servers MUST create an LDPR from a RDF representation in the request entity body. [...]</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div> </li>
+ <li property="td:specificationReference" typeof="tn:Excerpt"> <div><span property="tn:includesText">5.4.5 LDPC servers MUST accept a request entity body with a request header of Content-Type with value of text/turtle. </span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div> </li>
+ </ul -->
+ <h4>Input</h4>
+ <ul>
+ <li property="td:input" resource="#TCC11-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
+ <li property="td:input" resource="#TCC11-I2-LDPC2-REP" typeof="tn:TestInput"><em property="dc:title"><LDPC2 representation></em>. <span property="dc:description">The representation of the nested LDPC to be created</span></li>
+ <li property="td:input" resource="#TCC11-I3-S-URI" typeof="tn:TestInput"><em property="dc:title"><S URI></em>. <span property="dc:description">The URI of an RDF resource.</span></li>
+ <li property="td:input" resource="#TCC11-I4-P-URI" typeof="tn:TestInput"><em property="dc:title"><P URI></em>. <span property="dc:description">The URI of an RDF property.</span></li>
+ </ul>
+ <h4>Preconditions</h4>
+ <ul>
+ <li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
+ <li property="td:precondition">The LDPC at <LDPC URI> allows POST</li>
+ <li property="td:precondition">The LDP server does not desire to direct the user agent to retrieve a cacheable resource <span class="issue">Would this be cachable?</span></li>
+ <li property="td:precondition"><LDPC2 representation> is in text/turtle</li>
+ <li property="td:precondition"><span style="background-color: #cff;"><LDPC2 representation> is a valid representation for a sub-container to be created in the LDPC</span></li>
+ <li property="td:precondition"><LDPC2 representation> uses null relative URI as the entity in the request body</li>
+ <li property="td:precondition">The membership subject used by the LDPC is identified by <S URI></li>
+ <li property="td:precondition">The membership predicate used by the LDPC is identified by <P URI></li>
+ </ul>
+ <h4>Process</h4>
+ <ol>
+ <li inlist="" property="tn:testProcess" resource="#TCC11-RQ1-GET-LDPC-URI" typeof="tn:Step ht:Request">
+ <div property="dc:description">GET <LDPC URI></div>
+ <span property="tn:usesInput" resource="#TCC11-I1-LDPC-URI">
+ </span>
+ </li>
+ <li inlist="" property="tn:testProcess" resource="#TCC11-RQ2-POST-LDPC-URI" typeof="tn:Step ht:Request">
+ <div property="dc:description">POST <LDPC URI>
+ <ul>
+ <li>[entity-header].Content-type = text/turtle</li>
+ <li><span style="background-color: #cff;">[entity-header].Link: val=<LDP1ContainerInteraction>; rel=profile;</span></li>
+ <li>[message-body] = <LDPC2 representation></li>
+ </ul>
+ </div>
+ <span property="tn:usesInput" resource="#TCC11-I1-LDPC-URI">
+ </span>
+ <span property="tn:usesInput" resource="#TCC11-I2-LDPC2-REP">
+ </span>
+ </li>
+ <li inlist="" property="tn:testProcess" resource="#TCC11-RQ3-GET-LDPC-URI" typeof="tn:Step ht:Request">
+ <div property="dc:description">GET <LDPC URI></div>
+ <span property="tn:usesInput" resource="#TCC11-I1-LDPC-URI">
+ </span>
+ </li>
+ <li inlist="" property="tn:testProcess" resource="#TCC11-RQ4-GET-LOC-URI" typeof="tn:Step ht:Request">
+ <div property="dc:description">GET <Response 2 POST>.[response-header].Location <span style="color: #f30;">(location of created sub-container)</span></div>
+ </li>
+ <li inlist="" property="tn:testProcess" resource="#TCC11-RQ4-TEST-CONTAINER" typeof="tn:Step ht:Group">
+ <div property="dc:description"><span style="background-color: #cff;">Pass <a href="#TC-C9">TC-C9</a> <span style="color: #f30;">(test created sub-container)</span></span></div>
+ </li>
+ </ol>
+ <h4>Output</h4>
+ <ul>
+ <li property="td:output" resource="#TCC11-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
+ <span property="tn:fromStep" resource="#TCC11-RQ1-GET-LDPC-URI">
+ </span>
+ </li>
+ <li property="td:output" resource="#TCC11-O2-Response-2-POST" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 2 POST></em>. <span property="dc:description">The response of the POST request in step 2.</span>
+ <span property="tn:fromStep" resource="#TCC11-RQ2-POST-LDPC-URI">
+ </span>
+ </li>
+ <li property="td:output" resource="#TCC11-O3-Response-3-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 3 GET></em>. <span property="dc:description">The response of the GET request in step 3.</span>
+ <span property="tn:fromStep" resource="#TCC11-RQ3-GET-LDPC-URI">
+ </span>
+ </li>
+ <li property="td:output" resource="#TCC11-O4-Response-4-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 4 GET></em>. <span property="dc:description">The response of the GET request in step 4.</span>
+ <span property="tn:fromStep" resource="#TCC11-RQ4-GET-LOC-URI">
+ </span>
+ </li>
+ </ul>
+ <h4>Assertions</h4>
+ <ul>
+ <li property="tn:testAssertion" resource="#TCC11-A1-Response-1-GET" typeof="tn:TestAssertion">
+ <div property="tn:outputAsserted" resource="TCC11-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET resource correct</span>):
+ <div property="dc:description">
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ <li>[response-header].ETag exists</li>
+ <li>[response-header].Link: val=<LDP1ResourceInteraction>; rel=profile</li>
+ </ul>
+ </div>
+ </div>
+ </li>
+ <li property="tn:testAssertion" resource="#TCC11-A2-Response-1-GET" typeof="tn:TestAssertion">
+ <div property="tn:outputAsserted" resource="TCC11-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET container correct</span>):
+ <div property="dc:description">
+ <ul>
+ <li>[message-body] contains <LDPC URI> rdf:type ldp:Container .</li>
+ <li>[message-body] contains <LDPC URI> ldp:membershipSubject <S URI> .</li>
+ <li>[message-body] contains <LDPC URI> ldp:membershipPredicate <P URI> . or <LDPC URI> ldp:membershipPredicateInverse <P URI> .</li>
+ </ul>
+ </div>
+ </div>
+ </li>
+ <li property="tn:testAssertion" resource="#TCC11-A3-Response-1-GET" typeof="tn:TestAssertion">
+ <div property="tn:outputAsserted" resource="TCC11-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">container does not have <span style="color: #f30;">the to-be-created</span> member</span>):
+ <div property="dc:description">
+ <ul>
+ <li>[message-body] does not contain <S URI> <P URI> <Response 2 POST>.[response-header].Location .</li>
+ </ul>
+ </div>
+ </div>
+ </li>
+ <li property="tn:testAssertion" resource="#TCC11-A4-Response-2-POST" typeof="tn:TestAssertion">
+ <div property="tn:outputAsserted" resource="TCC11-O2-Response-2-POST">Assert <Response 2 POST> (<span property="dc:title">POST correct</span>):
+ <div property="dc:description">
+ <ul>
+ <li>[Status-Line].Status-Code = 201</li>
+ <li>[response-header].Location exists</li>
+ <li><span style="background-color: #cff;">[response-header].Link<span style="color: #f30;">:</span> <span style="color: #f30;">val=</span><LDP1ContainerInteraction>; rel=profile</span></li>
+ </ul>
+ </div>
+ </div>
+ </li>
+ <li property="tn:testAssertion" resource="#TCC11-A5-Response-3-GET" typeof="tn:TestAssertion">
+ <div property="tn:outputAsserted" resource="TCC11-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">GET resource correct</span>):
+ <div property="dc:description">
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ <li>[response-header].ETag exists</li>
+ <li><span style="background-color: #cff;">[response-header].Link: val=<LDP1ContainerInteraction>; rel=profile</span></li>
+ </ul>
+ </div>
+ </div>
+ </li>
+ <li property="tn:testAssertion" resource="#TCC11-A6-Response-3-GET" typeof="tn:TestAssertion">
+ <div property="tn:outputAsserted" resource="TCC11-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">GET container correct</span>):
+ <div property="dc:description">
+ <ul>
+ <li>[message-body] contains <LDPC URI> rdf:type ldp:Container .</li>
+ <li>[message-body] contains <LDPC URI> ldp:membershipSubject <S URI> .</li>
+ <li>[message-body] contains <LDPC URI> ldp:membershipPredicate <P URI> . or <LDPC URI> ldp:membershipPredicateInverse <P URI> .</li>
+ </ul>
+ </div>
+ </div>
+ </li>
+ <li property="tn:testAssertion" resource="#TCC11-A7-Response-3-GET" typeof="tn:TestAssertion">
+ <div property="tn:outputAsserted" resource="TCC11-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">container has member</span>):
+ <div property="dc:description">
+ <ul>
+ <li>[message-body] contains <S URI> <P URI> <Response 2 POST>.[response-header].Location .</li>
+ </ul>
+ </div>
+ </div>
+ </li>
+ <li property="tn:testAssertion" resource="#TCC11-A8-Response-4-GET" typeof="tn:TestAssertion">
+ <div property="tn:outputAsserted" resource="TCC11-O4-Response-4-GET">Assert <Response 4 GET> (<span property="dc:title">GET resource correct</span>):
+ <div property="dc:description">
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ <li>[response-header].ETag exists</li>
+ <li>[response-header].Link: val=<LDP1ResourceInteraction>; rel=profile</li>
+ </ul>
+ </div>
+ </div>
+ </li>
+ </ul>
+ </section>
+
+ <section resource="#TCC12" typeof="td:TestCase">
+ <h3><a id="TC-C12"><span property="rdfs:label">TC-C12</span>. <span property="dc:title">POST an LDPC on an LDPC as a sub-container</span></a></h3>
+ <p property="dc:description">Tests making a POST request of an LDPC on an LDPC as a sub-container.</p>
+ <p property="dc:contributor" resource="#RaulGarciaCastro" typeof="foaf:Person"><strong>Contributor: </strong> <span property="rdfs:label">Eric Prud'hommeaux</span> <span property="owl:sameAs" href="http://www.w3.org/People/Eric/ericP-foaf#ericP"></span></p>
+ <p property="td:reviewStatus" resource="td:unreviewed" typeof="td:ReviewStatus"><strong>Status: </strong>Unreviewed</p>
+ <h4>Related specification</h4>
+ <p>see <a href="#TC-C9">TC-C9</a></p>
+ <!-- ul>
+ <li property="td:specificationReference" typeof="tn:Excerpt">
+ <div><span property="tn:includesText">4.2.10 LDPR servers MUST advertise their LDP support by exposing a HTTP Link header with a target URI of http://www.w3.org/ns/ldp/Resource, and a link relation type of type (that is, rel=profile) in all responses to requests made to the resource's HTTP Request-URI. [...]</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div>
+ </li>
+ <li property="td:specificationReference" typeof="tn:Excerpt"> <div><span property="tn:includesText">5.4.1 [...] If the resource was created successfully, LDPC servers MUST respond with status code 201 (Created) and the Location header set to the new resource’s URL. [...] </span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div> </li>
+ <li property="td:specificationReference" typeof="tn:Excerpt"> <div><span property="tn:includesText">5.4.2 After a successful HTTP POST request to a LDPC, the new resource MUST appear as a member of the LDPC until the new resource is deleted or removed by other methods. [...] </span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div> </li>
+ <li property="td:specificationReference" typeof="tn:Excerpt"> <div><span property="tn:includesText">5.4.4 For servers that support create, LDPC servers MUST create an LDPR from a RDF representation in the request entity body. [...]</span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div> </li>
+ <li property="td:specificationReference" typeof="tn:Excerpt"> <div><span property="tn:includesText">5.4.5 LDPC servers MUST accept a request entity body with a request header of Content-Type with value of text/turtle. </span><span property="rdfs:seeAlso" href="http://www.w3.org/TR/ldp/"></span></div> </li>
+ </ul -->
+ <h4>Input</h4>
+ <ul>
+ <li property="td:input" resource="#TCC12-I1-LDPC-URI" typeof="tn:TestInput"><em property="dc:title"><LDPC URI></em>. <span property="dc:description">The URI of an LDPC.</span></li>
+ <li property="td:input" resource="#TCC12-I2-LDPC2-REP" typeof="tn:TestInput"><em property="dc:title"><LDPC2 representation></em>. <span property="dc:description">The representation of the nested LDPC to be created</span></li>
+ <li property="td:input" resource="#TCC12-I3-S-URI" typeof="tn:TestInput"><em property="dc:title"><S URI></em>. <span property="dc:description">The URI of an RDF resource.</span></li>
+ <li property="td:input" resource="#TCC12-I4-P-URI" typeof="tn:TestInput"><em property="dc:title"><P URI></em>. <span property="dc:description">The URI of an RDF property.</span></li>
+ </ul>
+ <h4>Preconditions</h4>
+ <ul>
+ <li property="td:precondition">The LDP server contains an LDPC at <LDPC URI></li>
+ <li property="td:precondition">The LDPC at <LDPC URI> allows POST</li>
+ <li property="td:precondition">The LDP server does not desire to direct the user agent to retrieve a cacheable resource <span class="issue">Would this be cachable?</span></li>
+ <li property="td:precondition"><LDPC2 representation> is in text/turtle</li>
+ <li property="td:precondition"><span style="background-color: #cff;"><LDPC2 representation> is a valid representation for a sub-container to be stored in the LDPC</span></li>
+ <li property="td:precondition"><LDPC2 representation> uses null relative URI as the entity in the request body</li>
+ <li property="td:precondition">The membership subject used by the LDPC is identified by <S URI></li>
+ <li property="td:precondition">The membership predicate used by the LDPC is identified by <P URI></li>
+ </ul>
+ <h4>Process</h4>
+ <ol>
+ <li inlist="" property="tn:testProcess" resource="#TCC12-RQ1-GET-LDPC-URI" typeof="tn:Step ht:Request">
+ <div property="dc:description">GET <LDPC URI></div>
+ <span property="tn:usesInput" resource="#TCC12-I1-LDPC-URI">
+ </span>
+ </li>
+ <li inlist="" property="tn:testProcess" resource="#TCC12-RQ2-POST-LDPC-URI" typeof="tn:Step ht:Request">
+ <div property="dc:description">POST <LDPC URI>
+ <ul>
+ <li>[entity-header].Content-type = text/turtle</li>
+ <li><span style="background-color: #cff;">[entity-header].Link: val=<LDP1ResourceInteraction> rel="profile"</span></li>
+ <li>[message-body] = <LDPC2 representation></li>
+ </ul>
+ </div>
+ <span property="tn:usesInput" resource="#TCC12-I1-LDPC-URI">
+ </span>
+ <span property="tn:usesInput" resource="#TCC12-I2-LDPC2-REP">
+ </span>
+ </li>
+ <li inlist="" property="tn:testProcess" resource="#TCC12-RQ3-GET-LDPC-URI" typeof="tn:Step ht:Request">
+ <div property="dc:description">GET <LDPC URI></div>
+ <span property="tn:usesInput" resource="#TCC12-I1-LDPC-URI">
+ </span>
+ </li>
+ <li inlist="" property="tn:testProcess" resource="#TCC12-RQ4-GET-LOC-URI" typeof="tn:Step ht:Request">
+ <div property="dc:description">GET <Response 2 POST>.[response-header].Location <span style="color: #f30;">(location of archived container)</span></div>
+ </li>
+ <li inlist="" property="tn:testProcess" resource="#TCC12-RQ4-TEST-CONTAINER" typeof="tn:Step ht:Group">
+ <div property="dc:description"><span style="background-color: #cff;">Fail <a href="#TC-C9">TC-C9</a> step 2 <span style="color: #f30;">(test that created object is NOT a container)</span></span></div>
+ </li>
+ </ol>
+ <h4>Output</h4>
+ <ul>
+ <li property="td:output" resource="#TCC12-O1-Response-1-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 1 GET></em>. <span property="dc:description">The response of the GET request in step 1.</span>
+ <span property="tn:fromStep" resource="#TCC12-RQ1-GET-LDPC-URI">
+ </span>
+ </li>
+ <li property="td:output" resource="#TCC12-O2-Response-2-POST" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 2 POST></em>. <span property="dc:description">The response of the POST request in step 2.</span>
+ <span property="tn:fromStep" resource="#TCC12-RQ2-POST-LDPC-URI">
+ </span>
+ </li>
+ <li property="td:output" resource="#TCC12-O3-Response-3-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 3 GET></em>. <span property="dc:description">The response of the GET request in step 3.</span>
+ <span property="tn:fromStep" resource="#TCC12-RQ3-GET-LDPC-URI">
+ </span>
+ </li>
+ <li property="td:output" resource="#TCC12-O4-Response-4-GET" typeof="tn:TestOutput ht:Response"><em property="dc:title"><Response 4 GET></em>. <span property="dc:description">The response of the GET request in step 4.</span>
+ <span property="tn:fromStep" resource="#TCC12-RQ4-GET-LOC-URI">
+ </span>
+ </li>
+ </ul>
+ <h4>Assertions</h4>
+ <ul>
+ <li property="tn:testAssertion" resource="#TCC12-A1-Response-1-GET" typeof="tn:TestAssertion">
+ <div property="tn:outputAsserted" resource="TCC12-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET resource correct</span>):
+ <div property="dc:description">
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ <li>[response-header].ETag exists</li>
+ <li>[response-header].Link: val=<LDP1ResourceInteraction>; rel=profile</li>
+ </ul>
+ </div>
+ </div>
+ </li>
+ <li property="tn:testAssertion" resource="#TCC12-A2-Response-1-GET" typeof="tn:TestAssertion">
+ <div property="tn:outputAsserted" resource="TCC12-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">GET container correct</span>):
+ <div property="dc:description">
+ <ul>
+ <li>[message-body] contains <LDPC URI> rdf:type ldp:Container .</li>
+ <li>[message-body] contains <LDPC URI> ldp:membershipSubject <S URI> .</li>
+ <li>[message-body] contains <LDPC URI> ldp:membershipPredicate <P URI> . or <LDPC URI> ldp:membershipPredicateInverse <P URI> .</li>
+ </ul>
+ </div>
+ </div>
+ </li>
+ <li property="tn:testAssertion" resource="#TCC12-A3-Response-1-GET" typeof="tn:TestAssertion">
+ <div property="tn:outputAsserted" resource="TCC12-O1-Response-1-GET">Assert <Response 1 GET> (<span property="dc:title">container does not have <span style="color: #f30;">the to-be-created</span> member</span>):
+ <div property="dc:description">
+ <ul>
+ <li>[message-body] does not contain <S URI> <P URI> <Response 2 POST>.[response-header].Location .</li>
+ </ul>
+ </div>
+ </div>
+ </li>
+ <li property="tn:testAssertion" resource="#TCC12-A4-Response-2-POST" typeof="tn:TestAssertion">
+ <div property="tn:outputAsserted" resource="TCC12-O2-Response-2-POST">Assert <Response 2 POST> (<span property="dc:title">POST correct</span>):
+ <div property="dc:description">
+ <ul>
+ <li>[Status-Line].Status-Code = 201</li>
+ <li>[response-header].Location exists</li>
+ <li><span style="background-color: #cff;">[response-header].Link<span style="color: #f30;">:</span> <span style="color: #f30;">val=</span>ldp:Resource; rel=profile</span></li>
+ </ul>
+ </div>
+ </div>
+ </li>
+ <li property="tn:testAssertion" resource="#TCC12-A5-Response-3-GET" typeof="tn:TestAssertion">
+ <div property="tn:outputAsserted" resource="TCC12-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">GET resource correct</span>):
+ <div property="dc:description">
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ <li>[response-header].ETag exists</li>
+ <li><span style="background-color: #cff;">[response-header].Link: val=ldp:Resource; rel=profile</span></li>
+ </ul>
+ </div>
+ </div>
+ </li>
+ <li property="tn:testAssertion" resource="#TCC12-A6-Response-3-GET" typeof="tn:TestAssertion">
+ <div property="tn:outputAsserted" resource="TCC12-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">GET container correct</span>):
+ <div property="dc:description">
+ <ul>
+ <li>[message-body] contains <LDPC URI> rdf:type ldp:Container .</li>
+ <li>[message-body] contains <LDPC URI> ldp:membershipSubject <S URI> .</li>
+ <li>[message-body] contains <LDPC URI> ldp:membershipPredicate <P URI> . or <LDPC URI> ldp:membershipPredicateInverse <P URI> .</li>
+ </ul>
+ </div>
+ </div>
+ </li>
+ <li property="tn:testAssertion" resource="#TCC12-A7-Response-3-GET" typeof="tn:TestAssertion">
+ <div property="tn:outputAsserted" resource="TCC12-O3-Response-3-GET">Assert <Response 3 GET> (<span property="dc:title">container has member</span>):
+ <div property="dc:description">
+ <ul>
+ <li>[message-body] contains <S URI> <P URI> <Response 2 POST>.[response-header].Location .</li>
+ </ul>
+ </div>
+ </div>
+ </li>
+ <li property="tn:testAssertion" resource="#TCC12-A8-Response-4-GET" typeof="tn:TestAssertion">
+ <div property="tn:outputAsserted" resource="TCC12-O4-Response-4-GET">Assert <Response 4 GET> (<span property="dc:title">GET resource correct</span>):
+ <div property="dc:description">
+ <ul>
+ <li>[Status-Line].Status-Code = 2xx</li>
+ <li>[response-header].ETag exists</li>
+ <li>[response-header].Link: val=<LDP1ResourceInteraction>; rel=profile</li>
+ </ul>
+ </div>
+ </div>
+ </li>
+ </ul>
+ </section>
+
+</section>
<section class="appendix">
<h2><a id="ChangeHistory">Change history</a></h2>
<ul>
<li>2013-08-27 Updated according to Last Call Working Draft from 30 July 2013 (RGC)</li>
<li>2013-06-03 Updated to use ReSpec (RGC)</li>
<li>2013-06-03 Implemented <a href="http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0153.html">changes suggested by Eric Prud'hommeaux</a> (RGC)</li>
</ul>
</section>
<section class="appendix">
<h2><a id="EditorNotes">Editor TODOs and notes</a></h2>
<ul>
<li>Define the type of document: Working Draft, Note, etc.</li>
<li>Choose a URI for the test cases (this) document</li>
<li>Choose a namespace for the new vocabulary terms and for the test cases</li>
<li>Include the RDF description of the test suite</li>
</ul>
</section>
</body>
</html>
\ No newline at end of file
Binary file images/ldpc-basic.png has changed
Binary file images/ldpc-hierarchy.png has changed
Binary file images/ldpc1.png has changed
Binary file images/ldpr1.png has changed
Binary file images/ldpr2.png has changed
--- a/ldp-bp/ldp-bp.html Wed Mar 05 16:33:45 2014 +0000
+++ b/ldp-bp/ldp-bp.html Wed Mar 05 16:34:18 2014 +0000
@@ -16,6 +16,8 @@
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus : "ED",
+ edDraftURI : "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html",
+
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName : "ldp-bp",
@@ -55,6 +57,12 @@
companyURL : "http://base22.com/"
},
{
+ name : "Miguel Esteban Gutiérrez",
+ url : "http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/phdstudents/27-mesteban",
+ company : "Ontology Engineering Group, Universidad Politécnica de Madrid",
+ companyURL : "http://www.oeg-upm.net/"
+ },
+ {
name : "Nandana Mihindukulasooriya",
url : "http://www.nandana.org/",
company : "Ontology Engineering Group, Universidad Politécnica de Madrid",
@@ -84,87 +92,73 @@
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
- wgPatentURI : "http://www.w3.org/2004/01/pp-impl/55082/status",
- localBiblio: {
- "LD-DI": {
- title: "Linked Data - Design Issues",
- href: "http://www.w3.org/DesignIssues/LinkedData.html",
- authors: ["Tim Berners-Lee"],
- //status: "WD"//,
- //deliveredBy: [
- // "http://www.w3.org/2012/ldp/"
- //],
- //publisher: "W3C"
- },
- "LDP-TESTS": {
- title: "Linked Data Platform 1.0 Test Cases",
- href: "https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html",
- authors: [
- "Raúl García-Castro"
- ],
- status: "WD",
- deliveredBy: [
- "http://www.w3.org/2012/ldp/"
- ],
- publisher: "W3C"
- },
- "LD-GLOSSARY": {
- title: "Linked Data Glossary",
- href: "http://www.w3.org/TR/ld-glossary/",
- authors: [
- "B Hyland", "G Atemezing", "M Pendleton", "B Srivastava"
- ],
- //status: "WD",
- //deliveredBy: [
- // "http://www.w3.org/2012/ldp/"
- //],
- publisher: "W3C"
- },
- "LDP-PRIMER": {
- title: "Linked Data Platforn Primer",
- href: "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-primer/ldp-primer.html",
- authors: [
- "Nandana Mihindukulasooriya","Roger Menday"
- ],
- status: "WD",
- deliveredBy: [
- "http://www.w3.org/2012/ldp/"
- ],
- publisher: "W3C"
- },
- "LDP-UCR": {
- title: "Linked Data Platform Use Cases and Requirements",
- href: "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-ucr.html",
- editors: [
- "Steve Battle","Steve Speicher"
- ],
- status: "ED",
- deliveredBy: [
- "http://www.w3.org/2012/ldp/"
- ],
- publisher: "W3C"
- },
- "LDP1": {
- title: "Linked Data Platform 1.0",
- href: "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html",
- editors: [
- "Steve Speicher",
- "John Arwe",
- "Ashok Malhotra"
- ],
- status: "ED",
- deliveredBy: [
- "http://www.w3.org/2012/ldp/"
- ],
- publisher: "W3C"
- },
- "LOD-COMMON-VOCABS": {
- title: "Common Vocabularies / Ontologies / Micromodels ",
- href: "http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies",
- publisher: "SWEO Community Project: Linking Open Data on the Semantic Web"
- },
+ //wgPatentURI : "http://www.w3.org/2004/01/pp-impl/55082/status",
+ localBiblio : {
+ "LD-DI" : {
+ title : "Linked Data - Design Issues",
+ href : "http://www.w3.org/DesignIssues/LinkedData.html",
+ authors : [ "Tim Berners-Lee" ],
+ //status: "WD"//,
+ //deliveredBy: [
+ // "http://www.w3.org/2012/ldp/"
+ //],
+ //publisher: "W3C"
+ },
+ "LDP-TESTS" : {
+ title : "Linked Data Platform 1.0 Test Cases",
+ href : "https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html",
+ authors : [ "Raúl García-Castro" ],
+ status : "WD",
+ deliveredBy : [ "http://www.w3.org/2012/ldp/" ],
+ publisher : "W3C"
+ },
+ "LD-GLOSSARY" : {
+ title : "Linked Data Glossary",
+ href : "http://www.w3.org/TR/ld-glossary/",
+ authors : [ "B Hyland", "G Atemezing", "M Pendleton",
+ "B Srivastava" ],
+ //status: "WD",
+ //deliveredBy: [
+ // "http://www.w3.org/2012/ldp/"
+ //],
+ publisher : "W3C"
+ },
+ "LDP-PRIMER" : {
+ title : "Linked Data Platforn Primer",
+ href : "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-primer/ldp-primer.html",
+ authors : [ "Nandana Mihindukulasooriya", "Roger Menday" ],
+ status : "WD",
+ deliveredBy : [ "http://www.w3.org/2012/ldp/" ],
+ publisher : "W3C"
+ },
+ "LDP-UCR" : {
+ title : "Linked Data Platform Use Cases and Requirements",
+ href : "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-ucr.html",
+ editors : [ "Steve Battle", "Steve Speicher" ],
+ status : "ED",
+ deliveredBy : [ "http://www.w3.org/2012/ldp/" ],
+ publisher : "W3C"
+ },
+ "LDP1" : {
+ title : "Linked Data Platform 1.0",
+ href : "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html",
+ editors : [ "Steve Speicher", "John Arwe", "Ashok Malhotra" ],
+ status : "ED",
+ deliveredBy : [ "http://www.w3.org/2012/ldp/" ],
+ publisher : "W3C"
+ },
+ "LOD-COMMON-VOCABS" : {
+ title : "Common Vocabularies / Ontologies / Micromodels ",
+ href : "http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies",
+ publisher : "SWEO Community Project: Linking Open Data on the Semantic Web"
+ },
+ "LOV" : {
+ title : "Linked Open Vocabularies (LOV)",
+ href : "http://lov.okfn.org/dataset/lov/",
+ publisher : "Open Knowledge Foundation (OKFN)"
+ }
}
-
+
};
// Replaces HTML characters (brackets and quotes) with legal HTML representations
@@ -185,7 +179,7 @@
}
</script>
-
+
</head>
@@ -194,603 +188,843 @@
<body>
- <section id='abstract'>
- This document provides best practices and general guidelines for Implementing
- Linked Data Platform servers, clients and related systems.
- </section>
-
- <section>
-
- <h2>About this Document</h2>
-
- <section>
-
- <h3>Impetus</h3>
-
- <p>
- While writing the Linked Data Platform Specification, the authors
- and contributors felt compelled to share common conventions and
- valuable lessons-learned. Yet, at the same time, they did not wish
- to impose or imply unnecessary restrictions, or to make the formal
- specification unnecessarily verbose. This document, along with the LDP Primer [[LDP-PRIMER]], was
- therefore developed to provide additional context. Drawing upon the
- professional experiences of its authors and contributors, research
- into the rich history of all related technologies, and continuous
- feedback from the community at large, it aims to help system
- implementers:
- </p>
- <ul>
- <li>avoid common pitfalls,</li>
- <li>improve quality,</li>
- <li>improve development and maintenance efficiency, and</li>
- <li>achieve greater interoperability with LDP’s within the
- enterprise, between enterprises, and across the World Wide Web.</li>
- </ul>
- </section>
-
- <section>
-
- <h3>Terminology</h3>
-
- <p>For the purposes of this document, we have found it useful to
- make a minor, yet important distinction between the term 'best
- practice' and the term 'guideline'. For the purposes of this
- document, we define and differentiate the terms as such:</p>
-
- <dl>
- <dt>best practice</dt>
- <dd>A good implementation practice (method or technique) that
- has consistently shown results superior to those achieved with
- other means and that is used as a benchmark. Best practices within
- this document apply specifically to the ways that one should
- implement technology (i.e. LDP servers, clients, and related
- systems). In this document, the best practices might be used as a
- kind of check-list against which one can directly evaluate a
- system's design and code. Lack of adherence to any given best
- practice, however, does not necessarily imply a lack of quality;
- they are recommendations that are said to be 'best' in most cases
- and in most contexts, but not all. A best practice is always
- subject to improvement as we learn and evolve the Web together.</dd>
- <dt>guideline</dt>
- <dd>A tip, a trick, a note, a suggestion, or answer to a
- frequently asked question. Guidelines within this document provide
- useful information that can advance your knowledge and
- understanding, but that may not be directly applicable to your implementation
- or recognized by consensus as the 'best' method or technique.</dd>
- </dl>
-
- <p>
- Please see the Terminology section of the LDP specification [[LDP1]] as well as the Linked Data Glossary [[LD-GLOSSARY]]
- for definitions to a variety of terms used in this document and
- related to the Linked Data sphere of knowledge.
- </p>
-
- </section>
-
- <section>
-
- <h3>Prerequisites and Assumptions</h3>
-
- <p>
- Implementers should have at least a general familiarity with the <a href="#informative-references">informative references</a> cited in
- this document - especially the following:
- </p>
-
- <ul>
- <li><strong>Linked Data Glossary</strong> [[LD-GLOSSARY]] - A useful glossary containing terms defined and used to describe Linked Data, and its associated vocabularies
- and best practices for publishing structured data on the Web.</li>
- <li><strong>Linked Data Platform 1.0</strong> [[LDP1]] - the formal specification for the LDP read-write Linked Data architecture, based on HTTP access to web resources that describe their state using the RDF data model.
- <li><strong>Linked Data Platform 1.0 Test Cases</strong> [[LDP-TESTS]] - A standard set of tests provided by the W3C, which can be use to verify an implementation's conformance to the LDP specification.</li>
- <li><strong>Linked Data Platform Primer</strong> [[LDP-PRIMER]] - An introduction to LDP, which describes the basic concepts of LDP such as Linked Data Platform Resources (LDPRs), Linked Data Platform Containers (LDPCs), and their affordances. The Primer provides a running example illustrating how an LDP client can interact with an LDP server in the context of a read-write Linked Data application (i.e. how to use HTTP for accessing, updating, creating and deleting resources from servers that expose their resources as Linked Data).</li>
- <li><strong>Linked Data Platform Use Cases and Requirements</strong> [[LDP-UCR]] - a set of user stories, use cases, scenarios and requirements that motivate a simple read-write Linked Data architecture, based on HTTP access to web resources that describe their state using RDF.</li>
- </ul>
+ <section id='abstract'>This document provides best practices
+ and general guidelines for implementing Linked Data Platform servers
+ and clients.</section>
- </section>
-
- </section>
-
+ <section id="intro">
+
+ <h2>About this Document</h2>
+
<section>
-
- <h2>Best Practices</h2>
-
- <section>
-
- <h3>Predicate URIs should be HTTP URLs</h3>
-
- <p>URIs are used to uniquely identify resources and URLs are
- used to locate resources on the Web. That is to say that a URL is
- expected to resolve to an actual resource, which can be retrieved
- from the host. A URI, on the other hand, may also be a URL, but it
- does not have to be; it may refer to something that has no
- retrievable representation.</p>
-
- <p>
- One of the fundamental ideas behind Linked Data is that the things
- referred to by HTTP URIs can actually be looked up
- ("dereferenced"). This important principle was originally
- outlined by Tim Berners-Lee as rule #2 of "the four
- rules" for linking data [[LD-DI]]]. It is therefore ideal that predicate URIs
- identify LDPRs with representations that are retrievable. LDP
- servers should at least provide [[RDF-SCHEMA]] representations of
- these predicates where possible.
- </p>
-
- <p>Of course, it is also a common practice to reuse properties
- from vocabularies that you don't own. In this case, you typically
- have no control over the result when attempting to dereference the
- URI. For this reason, publishers who wish to make their
- vocabularies useful for linking data should strive to provide a
- retrievable representation of the properties their vocabularies
- define. Consequently, implementers are also expected to use this
- standard as a benchmark for which to judge the efficacy of a
- vocabulary's use for linking data.</p>
-
- </section>
-
- <section>
-
- <h3>Use and include the predicate rdf:type to represent the
- concept of type in LDPRs</h3>
-
- <p>
- It is often very useful to know the type (class) of an LDPR, though
- it is not essential to work with the interaction capabilities that
- LDP offers. Still, to make your data more useful in the broadest
- context, you should explicitly define the type when possible and
- appropriate and you should use the
- <code>rdf:type</code>
- predicate defined by [[RDF-SCHEMA]] when doing so.
- </p>
-
- <p>This provides a way for clients to easily determine the type
- of a resource without having to perform additional processing or
- make additional HTTP requests. For example, clients that cannot
- infer the type because they do not support inferencing can benefit
- from this explicit declaration.</p>
-
- <pre title="Turtle with explicit declaration of rdf:type"
- class='example' data-include='include-rdf-type.ttl'
- data-oninclude='fixCode'></pre>
-
- </section>
-
- <section>
-
- <h3>Use relative URIs</h3>
-
- <!-- http://www.w3.org/2012/ldp/track/issues/29 -->
- <p>Relative URIs are useful to the Linked Data Platform in much the same ways that
- relative URLs [[RFC1808]] have been useful to traditional web systems. Since the things
- referred to by Linked Data URIs should ideally provide a retrievable representation, Linked Data URIs are usually also URLs; they locate rather than just identify. As such, the utilitarian value of relative URLs still applies; especially since the Container model of the LDP promotes hierarchical representations.</p>
+ <h3>Impetus</h3>
- <p>Implementers should therefore align the function of relative URIs in LDP with those of traditional relative URLs where possible and appropriate. Aside from giving developers the
- comfort and convenience of familiarity, they provide many of the same advantages.</p>
+ <p>While writing the Linked Data Platform Specification, the
+ authors and contributors felt compelled to share common conventions
+ and valuable lessons-learned. Yet, at the same time, they did not
+ wish to impose or imply unnecessary restrictions, or to make the
+ formal specification unnecessarily verbose. This document, along
+ with the LDP Primer [[LDP-PRIMER]], was therefore developed to
+ provide additional context. Drawing upon the professional
+ experiences of its authors and contributors, research into the rich
+ history of related technologies, and continuous feedback from the
+ community at large, it aims to help system implementers avoid common
+ pitfalls, improve quality, and achieve greater interoperability with
+ other Linked Data systems.</p>
- <dl>
- <dt>Relative URIs are shorter than absolute URIs.</dt>
- <dd>
- <p>In many cases, this can aid development by making code and RDF easier for humans to read. It can also reduce the size of payloads, which in turn, can reduce network traffic and stress on servers, while improving response times for end-users.</p>
+ </section>
- <pre title="Turtle RDF representation of http://example.org/container1/ with absolute URIs"
+ <section>
+
+ <h3>Terminology</h3>
+
+ <p>For the purposes of this document, it is useful to
+ make a minor, yet important distinction between the term 'best
+ practice' and the term 'guideline'. For the purposes of this
+ document, we define and differentiate the terms as follows:</p>
+
+ <dl>
+ <dt>best practice</dt>
+ <dd>An implementation practice (method or technique) that has
+ consistently shown results superior to those achieved with other
+ means and that is used as a benchmark. Best practices within this
+ document apply specifically to the ways that LDP servers and
+ clients are implemented as well as how certain resources should are
+ prepared and used with them. In this document, the best practices
+ might be used as a kind of check-list against which an implementer
+ can directly evaluate a system's design and code. Lack of adherence
+ to any given best practice, however, does not necessarily imply a
+ lack of quality; they are recommendations that are said to be
+ 'best' in most cases and in most contexts, but not all. A best
+ practice is always subject to improvement as we learn and evolve
+ the Web together.</dd>
+ <dt>guideline</dt>
+ <dd>A tip, a trick, a note, a suggestion, or answer to a
+ frequently asked question. Guidelines within this document provide
+ useful information that can advance an implementer's knowledge and
+ understanding, but that may not be directly applicable to an
+ implementation or recognized by consensus as a 'best practice'.</dd>
+ </dl>
+
+ <p>Please see the Terminology section in Linked Data Platform 1.0
+ [[LDP1]] as well as the Linked Data Glossary [[LD-GLOSSARY]] for
+ definitions to a variety of terms used in this document and related
+ to the Linked Data sphere of knowledge.</p>
+
+ </section>
+
+ <section>
+
+ <h3>Prerequisites and Assumptions</h3>
+
+ <p>
+ Implementers should have at least a general familiarity with the <a
+ href="#informative-references">informative references</a> cited in
+ this document - especially the following:
+ </p>
+
+ <ul>
+ <li><strong>RDF Vocabulary Description Language 1.0:
+ RDF Schema</strong> [[RDF-SCHEMA]] - The Resource Description Framework
+ (RDF) is a general-purpose language for representing information in
+ the Web and it is the defacto language for expressing Linked Data.
+ This specification describes how to use RDF to describe RDF
+ vocabularies.</li>
+ <li><strong>RDF Primer</strong> - This Primer is designed to
+ provide the reader with the basic knowledge required to effectively
+ use RDF. It introduces the basic concepts of RDF and describes its
+ XML syntax. It describes how to define RDF vocabularies using the
+ RDF Vocabulary Description Language, and gives an overview of some
+ deployed RDF applications. It also describes the content and
+ purpose of other RDF specification documents.</li>
+ <li><strong>Turtle - Terse RDF Triple Language</strong>
+ [[TURTLE]] - defines a textual syntax for RDF called Turtle that
+ allows RDF graphs to be completely written in a compact and natural
+ text form, with abbreviations for common usage patterns and
+ datatypes. RDF examples used in this document are expressed in
+ Turtle.</li>
+ <li><strong>Linked Data Glossary</strong> [[LD-GLOSSARY]] - a
+ useful glossary containing terms defined and used to describe
+ Linked Data, and its associated vocabularies and best practices for
+ publishing structured data on the Web.</li>
+ <li><strong>Linked Data Platform 1.0</strong> [[LDP1]] - the
+ formal specification for the LDP read-write Linked Data
+ architecture, based on HTTP access to web resources that describe
+ their state using the RDF data model.
+ <li><strong>Linked Data Platform 1.0 Test Cases</strong>
+ [[LDP-TESTS]] - a standard set of tests provided by the W3C, which
+ can be use to verify an implementation's conformance to the LDP
+ specification.</li>
+ <li><strong>Linked Data Platform Primer</strong> [[LDP-PRIMER]]
+ - an introduction to LDP, which describes the basic concepts of LDP
+ such as Linked Data Platform Resources (LDPRs), Linked Data
+ Platform Containers (LDPCs), and their affordances. The Primer
+ provides a running example illustrating how an LDP client can
+ interact with an LDP server in the context of a read-write Linked
+ Data application (i.e. how to use HTTP for accessing, updating,
+ creating and deleting resources from servers that expose their
+ resources as Linked Data).</li>
+ <li><strong>Linked Data Platform Use Cases and
+ Requirements</strong> [[LDP-UCR]] - a set of user stories, use cases,
+ scenarios and requirements that motivate a simple read-write Linked
+ Data architecture, based on HTTP access to web resources that
+ describe their state using RDF.</li>
+ </ul>
+
+
+ </section>
+
+ </section>
+
+ <section>
+
+ <h2>Best Practices</h2>
+
+ <section>
+
+ <h3>Predicate URIs should be HTTP URLs</h3>
+
+ <p>URIs are used to uniquely identify resources and URLs are used
+ to locate resources on the Web. That is to say that a URL is
+ expected to resolve to an actual resource, which can be retrieved
+ from the host. A URI, on the other hand, may also be a URL, but it
+ does not have to be; it may refer to something that has no
+ retrievable representation.</p>
+
+ <p>One of the fundamental ideas behind Linked Data is that the
+ things referred to by HTTP URIs can actually be looked up
+ ("dereferenced"). This important principle was originally
+ outlined by Tim Berners-Lee as rule #2 of "the four rules"
+ for linking data [[LD-DI]]]. It is therefore ideal that predicate
+ URIs identify LDPRs with representations that are retrievable. LDP
+ servers should at least provide [[RDF-SCHEMA]] representations of
+ these predicates where possible.</p>
+
+ <p>Of course, it is also a common practice to reuse properties
+ from open vocabularies that are publicly available. In this case,
+ implementers have no control over the result when attempting to
+ dereference the URI. For this reason, publishers who wish to make
+ their vocabularies useful for linking data should strive to provide
+ a retrievable representation of the properties their vocabularies
+ define. Consequently, implementers are also expected to use this
+ standard as a benchmark for which to judge the efficacy of a
+ vocabulary's use for linking data.</p>
+
+ </section>
+
+ <section>
+
+ <h3>Use and include the predicate rdf:type to represent the
+ concept of type in LDPRs</h3>
+
+ <p>
+ It is often very useful to know the type (class) of an LDPR, though
+ it is not essential to work with the interaction capabilities that
+ LDP offers. Still, to make data more useful in the broadest context,
+ type should be explicitly defined using the
+ <code>rdf:type</code>
+ predicate defined by [[RDF-SCHEMA]].
+ </p>
+
+ <p>This provides a way for clients to easily determine the type
+ of a resource without having to perform additional processing or
+ make additional HTTP requests. For example, clients that cannot
+ infer the type because they do not support inferencing can benefit
+ from this explicit declaration.</p>
+
+ <pre
+ title="Representation of an LDPR with explicit declaration of rdf:type"
+ class='example' data-include='include-rdf-type.ttl'
+ data-oninclude='fixCode'></pre>
+
+ </section>
+
+ <section>
+
+ <h3>Use relative URIs</h3>
+
+ <!-- http://www.w3.org/2012/ldp/track/issues/29 -->
+
+ <p>Relative URIs are useful to the Linked Data Platform in much
+ the same ways that relative URLs [[RFC1808]] have been useful to
+ traditional web systems. Since the things referred to by Linked Data
+ URIs should ideally provide a retrievable representation, Linked
+ Data URIs are usually also URLs; they locate rather than just
+ identify. As such, the utilitarian value of relative URLs still
+ applies; especially since the LDP Container model promotes
+ hierarchical representations.</p>
+
+ <p>Implementers should therefore align the function of relative
+ URIs in LDP with those of traditional relative URLs where possible
+ and appropriate. Aside from giving developers the comfort and
+ convenience of familiarity, they provide many of the same
+ advantages.</p>
+
+ <dl>
+ <dt>Relative URIs are shorter than absolute URIs.</dt>
+ <dd>
+ <p>In many cases, this can aid development by making code and
+ RDF easier for humans to read. It can also reduce the size of
+ payloads, which in turn, can reduce network traffic and stress on
+ servers, while improving response times for end-users.</p>
+
+ <pre
+ title="Representation of http://example.org/container1/ with absolute URIs"
class='example' data-include='rdf-absolute-uris.ttl'
data-oninclude='fixCode'></pre>
- <pre title="Turtle RDF representation of http://example.org/container1/ with relative URIs"
+ <pre
+ title="Representation of http://example.org/container1/ with relative URIs"
class='example' data-include='rdf-relative-uris.ttl'
data-oninclude='fixCode'></pre>
- </dd>
-
- <dt>Relative URIs can make resources more portable.</dt>
- <dd>When information which is already known from the context of the base
- resource's retrieval is omitted, there can be less information to modify when that
- information changes. This can make moving resources to new servers or to a new position in a containment hierarchy easier.</dd>
-
- <dt>Relative URIs are convenient during development.</dt>
- <dd>During development the scheme and network location information in a URI may either be unknown or likely to change. The commonly used 'localhost' for example, is better
- expressed by the server name or a domain name. Developers often experience less
- hassle by omitting this information. Additionally, the hierarchy implied by a relative URI may be mimicked in a server file system, which can help developers
- find and work with information, even the server isn't running.</dd>
-
- <dt>Relative URIs support arbitrary, machine-generated URIs.</dt>
- <dd>RESTful URLs are often defined by a pattern of hierarchical 'collections', which
- clients interact with in very logical ways. For example, when creating a new resource the client does not typically know the name of the resource until after a successful POST to a collection's URL. A POST to <code>/people/</code> for example, may create the resource <code>/people/1</code>. LDP Containers are such collections whose URIs can benefit from the same model,
- which in some implementations, may actually be crucial.</dd>
- </dl>
- </section>
-
- <section>
-
- <h3>Represent container membership with hierarchical URIs</h3>
-
- <p>Hierarchical URIs are good for containers because they enable the use of relative URIs. They also promote easy interaction with resources that are modeled to represent parent-child relationships where the child logically belongs
- to the parent.</p>
-
- <p>One example of such a model can be found in the case of the <code>oslc_cm:attachment</code> container from the vocabularies defined by the <a href="http://open-services.net/">Open Service for Lifecycle Management (OSLC)</a> community. The OSLC defines specifications and vocabularies that are well-aligned to the LDP. A resource in an OSLC compliant change management system such as an issue or bug tracker may have attachments represented by the <code>oslc_cm:attachment</code>
- container. The URI for such a container might be represented as follows:</p>
-
- <p><code>http://example.org/bugs/2314/attachments/</code></p>
-
- <p>From this URI, you can easily discern the URI of the parent resource, which holds the attachments. You can also discern the base container for other sibling resources by moving up the hierarchy, which is implied by the URI. You might also go down the hierarchy to fetch meta-data or binary content using a URI such as the following:</p>
-
- <p><code>http://example.org/bugs/2314/attachments/1</code></p>
-
- <p>As you can see, in addition to making the use of relative URIs possible, hierarchical URIs make interacting with resources easier because they represent the actual structure of the underlying graph.</p>
-
- </section>
-
-
- <section>
-
- <!-- http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0071.html -->
-
- <h4>Include a trailing slash in container URIs</h4>
-
- <p>When representing container membership with hierarchical URLs, there is an advantage to including the trailing
- slash in the URI of a given container. Take the following container URI for example:</p>
+ </dd>
- <p><code>http://example.org/container1</code></p>
-
- <p>It is more advantageous to use the following instead:</p>
-
- <p><code>http://example.org/container1/</code></p>
-
- <p>To illustrate the advantage, let's start with the following container expressed in Turtle RDF using absolute URIs:</p>
-
- <pre title="A simple container" class='example' data-include='trailing-slash-1.ttl' data-oninclude='fixCode'></pre>
-
- <p>Suppose now that we wish to reflect the same resource using relative URIs. If the URI of the container includes
- the trailing slash, we end up with a very elegant representation, as shown below.</p>
-
- <pre title="Container URI is http://example.org/container1/" class='example' data-include='trailing-slash-2.ttl' data-oninclude='fixCode'></pre>
-
- <p>But suppose that we ommit the trailing slash, issued an HTTP GET, and the container returned the representation
- shown above. This could produce a graph that is isomorphic to the following:</p>
-
- <pre title="Container URI is http://example.org/container1" class='example' data-include='trailing-slash-3.ttl' data-oninclude='fixCode'></pre>
-
- <p>That is not what was intended. The returned document would have to be more verbose:</p>
-
- <pre title="Container URI is http://example.org/container1" class='example' data-include='trailing-slash-4.ttl' data-oninclude='fixCode'></pre>
-
- <p>So, clearly, the better solution is to ensure that container URIs end with the trailing slash.</p>
+ <dt>Relative URIs can make resources more portable.</dt>
+ <dd>When information which is already known from the context of
+ the base resource's retrieval is omitted, there can be less
+ information to modify when that information changes. This can make
+ moving resources to new servers or to a new position in a
+ containment hierarchy easier.</dd>
- </section>
-
-
- <section>
-
- <h3>Use fragments as object identifiers</h3>
-
- <p>The fragment identifier introduced by a hash mark <b><code>#</code></b> is the optional last part of a URI for an object, which is typically used to identify a subordinate or related object.</p>
+ <dt>Relative URIs are convenient during development.</dt>
+ <dd>During development the scheme and network location
+ information in a URI may either be unknown or likely to change. The
+ commonly used 'localhost' for example, is better expressed by the
+ server name or a domain name. Developers often experience less
+ hassle by omitting this information. Additionally, the hierarchy
+ implied by a relative URI may be mimicked in a server file system,
+ which can help developers find and work with information, even when
+ the server isn't running.</dd>
- <p>
- Take the URI, <code>http://www.example.org/products#item10245</code>, for example. The base URI is the part preceding the hash mark, <code>http://www.example.org/products</code>, and the fragment identifier is the part that follows,
- <code>item10245</code>.
- </p>
+ <dt>Relative URIs support arbitrary, machine-generated URIs.</dt>
+ <dd>
+ RESTful URLs are often defined by a pattern of hierarchical
+ 'collections', which clients interact with in very logical ways.
+ For example, when creating a new resource the client does not
+ typically know the name of the resource until after a successful
+ POST to a collection's URL. A POST to
+ <code>/people/</code>
+ for example, may create the resource
+ <code>/people/1</code>
+ . LDP Containers are such collections whose URIs can benefit from
+ the same model, which in some implementations, may actually be
+ crucial.
+ </dd>
+ </dl>
+ </section>
- <p>
- When expressing Linked Data Platform Resources in RDF, fragments are useful because they can be expressed as
- relative URIs on the document describing them. This is particularly handy for describing multiple LDPRs whose
- representations are contained within a single document.
- </p>
+ <section>
- <p>
- First, it provides the convenience and efficiency of brevity. Suppose, for example that you want to describe
- the resources foo, bar and baz, which are contained in the same document. Since serving all of the descriptions
- in a single document is a acceptable, we can mint relative URIs within the document using the fragment identifier
- (<code><#foo></code>, <code><#bar></code> and <code><#baz></code>). The full URI is assumed to
- be the base URI, plus the hash mark, and the fragment identifier.
- </p>
+ <h3>Represent container membership with hierarchical URIs</h3>
+
+ <p>Hierarchical URIs are good for containers because they enable
+ the use of relative URIs. They also promote easy interaction with
+ resources that are modeled to represent parent-child relationships
+ where the child logically belongs to the parent.</p>
+
+ <p>
+ One example of such a model can be found in the case of the
+ <code>oslc_cm:attachment</code>
+ container from the vocabularies defined by the <a
+ href="http://open-services.net/">Open Service for Lifecycle
+ Management (OSLC)</a> community. The OSLC defines specifications and
+ vocabularies that are well-aligned to LDP. A resource in an OSLC
+ compliant change management system such as an issue or bug tracker
+ may have attachments represented by the
+ <code>oslc_cm:attachment</code>
+ container. The URI for such a container might be represented as
+ follows:
+ </p>
+
+ <p>
+ <code>http://example.org/bugs/2314/attachments/</code>
+ </p>
+
+ <p>From this URI, the URI of the parent resource which holds the
+ attachments is easily discerned. The base container for other
+ sibling resources can be discerned by moving up the hierarchy, which
+ is implied by the URI. Meta-data or binary content might be fetched
+ further down the hierarchy by using a URI such as the following:</p>
+
+ <p>
+ <code>http://example.org/bugs/2314/attachments/1</code>
+ </p>
+
+ <p>In addition to making the use of relative URIs possible,
+ hierarchical URIs make interacting with resources easier because
+ they represent the actual structure of the underlying graph.</p>
+
+ </section>
- <p>
- Second, it can help avoid certain complexities inherent with other approaches. Achieving the same result using
- three independent dereferenceable URIs could be more involved because you'd need to create and publish multiple
- documents, perhaps also having to setup 303 redirects.
- </p>
-
- <p><strong>See also:</strong></p>
-
- <p>
- <a href="http://www.w3.org/TR/cooluris">Cool URIs for the Semantic Web</a>
- <ul>
- <li><a href="http://www.w3.org/TR/cooluris/#hashuri">http://www.w3.org/TR/cooluris/#hashuri</a></li>
- <li><a href="http://www.w3.org/TR/cooluris/#choosing">http://www.w3.org/TR/cooluris/#choosing</a></li>
- </ul>
- </p>
-
- <p><a href="http://www.w3.org/DesignIssues/Fragment.html">Axioms of Web Architecture, URI References: Fragment Identifiers on URIs</a><br/>
- http://www.w3.org/DesignIssues/Fragment.html</p>
-
- <p><a href="http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14">Dereferencing HTTP URIs</a><br/>
- http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14</p>
-
- </section>
-
-
- <section>
- <h3>Prefer standard datatypes</h3>
-
- <p>LDPR representations should use only the following standard datatypes. RDF does not by itself define datatypes to be used for literal property values, therefore a set of standard datatypes
- based on [[XMLSCHEMA11-2]] and [[RDF-PRIMER]] should be used:</p>
-
- <table class="simple">
- <thead>
- <tr>
- <th>URI</th>
- <th>Description</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td><a href="http://www.w3.org/2001/XMLSchema#boolean">http://www.w3.org/2001/XMLSchema#boolean</a></td>
- <td>Boolean type as specified by XSD Boolean</td>
- </tr>
- <tr>
- <td><a href="http://www.w3.org/2001/XMLSchema#date">http://www.w3.org/2001/XMLSchema#date</a></td>
- <td>Date type as specified by XSD date</td>
- </tr>
- <tr>
- <td><a href="http://www.w3.org/2001/XMLSchema#dateTime">http://www.w3.org/2001/XMLSchema#dateTime</a></td>
- <td>Date and Time type as specified by XSD dateTime</td>
- </tr>
- <tr>
- <td><a href="http://www.w3.org/2001/XMLSchema#decimal">http://www.w3.org/2001/XMLSchema#decimal</a></td>
- <td>Decimal number type as specified by XSD Decimal</td>
- </tr>
- <tr>
- <td><a href="http://www.w3.org/2001/XMLSchema#double">http://www.w3.org/2001/XMLSchema#double</a></td>
- <td>Double floating-point number type as specified by XSD
- Double</td>
- </tr>
- <tr>
- <td><a href="http://www.w3.org/2001/XMLSchema#float">http://www.w3.org/2001/XMLSchema#float</a></td>
- <td>Floating-point number type as specified by XSD Float</td>
- </tr>
- <tr>
- <td><a href="http://www.w3.org/2001/XMLSchema#integer">http://www.w3.org/2001/XMLSchema#integer</a></td>
- <td>Integer number type as specified by XSD Integer</td>
- </tr>
- <tr>
- <td><a href="http://www.w3.org/2001/XMLSchema#string">http://www.w3.org/2001/XMLSchema#string</a></td>
- <td>String type as specified by XSD String</td>
- </tr>
- <tr>
- <td><a href="http://www.w3.org/2001/XMLSchema#base64Binary">http://www.w3.org/2001/XMLSchema#base64Binary</a></td>
- <td>Binary type as specified by XSD Base64Binary</td>
- </tr>
- <tr>
- <td><a
- href="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral</a></td>
- <td>Literal XML value as specified by RDF</td>
- </tr>
- </tbody>
- </table>
-
- </section>
-
-
- <section>
+ <section>
- <h3>Re-use established linked data vocabularies instead of (re-)inventing duplicates</h3>
-
- <p>This section summarizes some well-known RDF vocabularies that
- should be used in Linked Data Platform Resources wherever a resource
- needs to use a predicate whose meaning matches one of these. For
- example, if a resource has a description, and the application
- semantic of that description is compatible with <code>dcterms:description</code>,
- then <code>dcterms:description</code> should be used. If needed, additional application-specific predicates may be used.
- A specification for a domain may require one or more of these properties for a particular resource type.
- The Range column in the tables below identifies the recommended <code>rdfs:range</code> for the properties.</p>
-
- <h4>Common Properties</h4>
-
- <p><strong>From Dublin Core URI: <a href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a></strong></p>
-
- <table class="simple">
- <thead>
- <tr>
- <th>Property</th>
- <th>Range/DataType</th>
- <th>Comment</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td>dcterms:contributor</td>
- <td>dcterms:Agent</td>
- <td></td>
- </tr>
- <tr>
- <td>dcterms:creator</td>
- <td>dcterms:Agent</td>
- <td></td>
- </tr>
- <tr>
- <td>dcterms:created</td>
- <td>xsd:dateTime</td>
- <td></td>
- </tr>
- <tr>
- <td>dcterms:description</td>
- <td>rdf:XMLLiteral</td>
- <td>Descriptive text about the resource represented as rich
- text in XHTML format. should include only content that is valid
- and suitable inside an XHTML element.</td>
- </tr>
- <tr>
- <td>dcterms:identifier</td>
- <td>rdfs:Literal</td>
- <td></td>
- </tr>
- <tr>
- <td>dcterms:modified</td>
- <td>xsd:dateTime</td>
- <td></td>
- </tr>
- <tr>
- <td>dcterms:relation</td>
- <td>rdfs:Resource</td>
- <td>The HTTP URI of a related resource. This is the
- predicate to use when you don't know what else to use. If you
- know more specifically what sort of relationship it is, use a
- more specific predicate.</td>
- </tr>
- <tr>
- <td>dcterms:subject</td>
- <td>rdfs:Resource</td>
- <td></td>
- </tr>
- <tr>
- <td>dcterms:title</td>
- <td>rdf:XMLLiteral</td>
- <td>A name given to the resource. Represented as rich text
- in XHTML format. should include only content that is valid
- inside an XHTML element.</td>
- </tr>
- </tbody>
- </table>
-
- <p>The predicate <code>dcterms:type</code> should not be used, instead use <code>rdf:type</code>. [[DC-RDF]].</p>
-
- <p><strong>From RDF URI: <a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#">http://www.w3.org/1999/02/22-rdf-syntax-ns#</a></strong></p>
-
- <table class="simple">
- <thead>
- <tr>
- <th>Property</th>
- <th>Range/DataType</th>
- <th>Comment</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td>rdf:type</td>
- <td>rdfs:Class</td>
- <td>The type or types of the resource</td>
- </tr>
- </tbody>
- </table>
-
- <p><strong>From RDF Schema URI: <a href="http://www.w3.org/2000/01/rdf-schema#">http://www.w3.org/2000/01/rdf-schema#</a></strong></p>
-
- <table class="simple">
- <thead>
- <tr>
- <th>Property</th>
- <th>Range/DataType</th>
- <th>Comment</th>
- </tr>
- </thead>
- <tbody>
- <tr>
- <td>rdfs:member</td>
- <td>rdfs:Resource</td>
- <td> </td>
- </tr>
- <tr>
- <td>rdfs:label</td>
- <td>rdfs:Literal</td>
- <td>Only use this in vocabulary documents, to define the name of the vocabulary term.</td>
- </tr>
- </tbody>
- </table>
-
- <h4>Common Vocabularies</h4>
-
- <p>
- The Linked Data LOD community project maintain a wiki list of common vocabularies, which may also be of interest to implementers. [[LOD-COMMON-VOCABS]]
- </p>
-
- </section>
-
-
- <section>
- <h3>Use qvalues properly</h3>
-
- <p>Quality factors allow the user or user agent to indicate the relative degree of preference for a media-range,
- using the qvalue scale from 0 to 1. The default value is q=1. Take the following for example:</p>
+ <!-- http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0071.html -->
- <p><code>Accept: text/turtle; q=0.5, application/json</code></p>
-
- <p>This should be interpreted as "I prefer application/json, but send me text/turtle if it is the best available
- after a 50% mark-down in quality."</p>
-
- <p>Improper handling of qvalues is a common problem in implementations of content negotiation.
-
- <p>Refer to Section 14, Header Field Definitions, in the [[HTTP11]] specification to understand the proper use and evaluation
- of qvalues for both client and server implementations.</p>
-
- </section>
-
- <section>
- <h3>Respond with canonical URLs and use them for identity comparison</h3>
-
- <p>Clients can access an LDPR using multiple URLs. An LDPR server should respond to each of those requests
- using a single consistent URL, a canonical URL, for the LDPR. This canonical URL may be found in the response's
- Location and/or Content-Location headers, and potentially also in the representation of the LDPR. A common case
- is URLs that vary by protocol, one HTTP and one HTTPS, but are otherwise identical. In most cases those two URLs
- refer to the same resource, and the server should respond to requests to either URL with a single (canonical) URL.</p>
-
- <p>Clients should use the canonical URL as an LDPR's identity; for example, when determining if two URLs refer to the same resource clients should compare the canonical URLs, not the URLs used to access the resources.</p>
+ <h4>Include a trailing slash in container URIs</h4>
- </section>
-
- <section>
- <h3>Representing relationships between resources</h3>
- <p>
- LDPRs can use one RDF triple to represent a link (relationship) to another resource.
- Having the source resource’s URI as the subject and the target resource’s URI as the object of
- the triple is enough. Contrary to a misconception that readers with certain backgrounds may assume,
- the creation of an "intermediate link" resource is not required to express the relationship.
- </p>
- </section>
-
- </section><!-- End Best Practices Section -->
-
- <section>
-
- <h2>Guidelines</h2>
-
- <section>
-
- <h3>Containers are not limited to same-subject, same-predicate
- triples</h3>
-
- <p>
- The LDP specification defines a Container as "a Linked Data
- Platform Resource (LDPR) representing a collection of same-subject,
- same-predicate triples." This can easily be misconstrued to
- mean that a Container should <em>only</em> contain same-subject,
- same-predicate triples. While Containers <em>may</em> contain only
- same-subject, same-predicate triples (i.e. the membership subjects
- and membership predicates of its membership triples), it is free to
- contain others. The definition is meant to clarify only those
- attributes that are directly relavant to the interaction model of a
- Container, but not to limit them to those attributes alone.
- </p>
-
- <p>It is important to remember that a Linked Data Platform
- Container (LDPC) is also a Linked Data Platform Resource (LDPR) and
- though it might exist as a membership controller, it may also
- represent additional data that is valuable to the agents that
- access it.</p>
-
- </section>
-
- </section><!-- End Guidelines Section -->
-
- <section class='appendix'>
- <h2>Acknowledgements</h2>
- <p>Many thanks to Robin Berjon for making our lives so much easier with his cool tool.</p>
- <p>To Ashok Malhotra, Melvin Carvalho, Richard Cyganiak, and Steve Speicher for providing recommendations for improvement to the editors.</p>
+ <p>When representing container membership with hierarchical URLs,
+ there is an advantage to including the trailing slash in the URI of
+ a given container. Take the following container URI for example:</p>
+
+ <p>
+ <code>http://example.org/container1</code>
+ </p>
+
+ <p>It is more advantageous to use the following instead:</p>
+
+ <p>
+ <code>http://example.org/container1/</code>
+ </p>
+
+ <p>To illustrate the advantage, let's start with the following
+ container using absolute URIs:</p>
+
+ <pre title="A simple container" class='example'
+ data-include='trailing-slash-1.ttl' data-oninclude='fixCode'></pre>
+
+ <p>Suppose now that we wish to reflect the same resource using
+ relative URIs. If the URI of the container includes the trailing
+ slash, we end up with a very elegant representation, as shown below.</p>
+
+ <pre title="Container URI is http://example.org/container1/"
+ class='example' data-include='trailing-slash-2.ttl'
+ data-oninclude='fixCode'></pre>
+
+ <p>But suppose that we ommit the trailing slash, issued an HTTP
+ GET, and the container returned the representation shown above. This
+ could produce a graph that is isomorphic to the following:</p>
+
+ <pre title="Container URI is http://example.org/container1"
+ class='example' data-include='trailing-slash-3.ttl'
+ data-oninclude='fixCode'></pre>
+
+ <p>That is not what was intended. The returned document would
+ have to be more verbose:</p>
+
+ <pre title="Container URI is http://example.org/container1"
+ class='example' data-include='trailing-slash-4.ttl'
+ data-oninclude='fixCode'></pre>
+
+ <p>So, clearly, the better solution is to ensure that container
+ URIs end with a trailing slash.</p>
+
</section>
-
+
+ <section>
+
+ <h3>Use fragments as object identifiers</h3>
+
+ <p>
+ The fragment identifier introduced by a hash mark (<b><code>#</code></b>)
+ is the optional last part of a URI for an object, which is typically
+ used to identify a subordinate or related object.
+ </p>
+
+ <p>
+ Take the URI,
+ <code>http://www.example.org/products#item10245</code>
+ , for example. The base URI is the part preceding the hash mark,
+ <code>http://www.example.org/products</code>
+ , and the fragment identifier is the part that follows,
+ <code>item10245</code>
+ .
+ </p>
+
+ <p>When expressing Linked Data Platform Resources in RDF,
+ fragments are useful because they can be expressed as relative URIs
+ on the document describing them. This is particularly handy for
+ describing multiple LDPRs whose representations are contained within
+ a single document.</p>
+
+ <p>
+ First, it provides the convenience and efficiency of brevity.
+ Suppose, for example, the resources foo, bar and baz, which are
+ contained in the same document. Since serving all of the
+ descriptions in a single document is acceptable, we can mint
+ relative URIs within the document using the fragment identifier (
+ <code><#foo></code>
+ ,
+ <code><#bar></code>
+ and
+ <code><#baz></code>
+ ). The full URI is assumed to be the base URI, plus the hash mark,
+ and the fragment identifier.
+ </p>
+
+
+ <p>Second, it can help avoid certain complexities inherent with
+ other approaches. Achieving the same result using three independent
+ dereferenceable URIs could be more involved because multiple
+ documents would have to be published, perhaps also including the
+ setup of 303 redirects.</p>
+
+ <p>
+ <strong>See also:</strong>
+ </p>
+
+ <p>
+ <a href="http://www.w3.org/TR/cooluris">Cool URIs for the
+ Semantic Web</a>
+ <ul>
+ <li><a href="http://www.w3.org/TR/cooluris/#hashuri">http://www.w3.org/TR/cooluris/#hashuri</a></li>
+ <li><a href="http://www.w3.org/TR/cooluris/#choosing">http://www.w3.org/TR/cooluris/#choosing</a></li>
+ </ul>
+ </p>
+
+ <p>
+ <a href="http://www.w3.org/DesignIssues/Fragment.html">Axioms of
+ Web Architecture, URI References: Fragment Identifiers on URIs</a><br />
+ http://www.w3.org/DesignIssues/Fragment.html
+ </p>
+
+ <p>
+ <a
+ href="http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14">Dereferencing
+ HTTP URIs</a><br />
+ http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14
+ </p>
+
+ </section>
+
+
+ <section>
+ <h3>Prefer standard datatypes</h3>
+
+ <p>LDPR representations should use only the following standard
+ datatypes. RDF does not by itself define datatypes to be used for
+ literal property values, therefore a set of standard datatypes based
+ on [[XMLSCHEMA11-2]] and [[RDF-PRIMER]] should be used:</p>
+
+ <table class="simple">
+ <thead>
+ <tr>
+ <th>URI</th>
+ <th>Description</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td><a href="http://www.w3.org/2001/XMLSchema#boolean">http://www.w3.org/2001/XMLSchema#boolean</a></td>
+ <td>Boolean type as specified by XSD Boolean</td>
+ </tr>
+ <tr>
+ <td><a href="http://www.w3.org/2001/XMLSchema#date">http://www.w3.org/2001/XMLSchema#date</a></td>
+ <td>Date type as specified by XSD date</td>
+ </tr>
+ <tr>
+ <td><a href="http://www.w3.org/2001/XMLSchema#dateTime">http://www.w3.org/2001/XMLSchema#dateTime</a></td>
+ <td>Date and Time type as specified by XSD dateTime</td>
+ </tr>
+ <tr>
+ <td><a href="http://www.w3.org/2001/XMLSchema#decimal">http://www.w3.org/2001/XMLSchema#decimal</a></td>
+ <td>Decimal number type as specified by XSD Decimal</td>
+ </tr>
+ <tr>
+ <td><a href="http://www.w3.org/2001/XMLSchema#double">http://www.w3.org/2001/XMLSchema#double</a></td>
+ <td>Double floating-point number type as specified by XSD
+ Double</td>
+ </tr>
+ <tr>
+ <td><a href="http://www.w3.org/2001/XMLSchema#float">http://www.w3.org/2001/XMLSchema#float</a></td>
+ <td>Floating-point number type as specified by XSD Float</td>
+ </tr>
+ <tr>
+ <td><a href="http://www.w3.org/2001/XMLSchema#integer">http://www.w3.org/2001/XMLSchema#integer</a></td>
+ <td>Integer number type as specified by XSD Integer</td>
+ </tr>
+ <tr>
+ <td><a href="http://www.w3.org/2001/XMLSchema#string">http://www.w3.org/2001/XMLSchema#string</a></td>
+ <td>String type as specified by XSD String</td>
+ </tr>
+ <tr>
+ <td><a href="http://www.w3.org/2001/XMLSchema#base64Binary">http://www.w3.org/2001/XMLSchema#base64Binary</a></td>
+ <td>Binary type as specified by XSD Base64Binary</td>
+ </tr>
+ <tr>
+ <td><a
+ href="http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral">http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral</a></td>
+ <td>Literal XML value as specified by RDF</td>
+ </tr>
+ </tbody>
+ </table>
+
+ </section>
+
+
+ <section>
+
+ <h3>Re-use established linked data vocabularies instead of
+ (re-)inventing duplicates</h3>
+
+ <p>
+ This section summarizes some well-known RDF vocabularies that should
+ be used in Linked Data Platform Resources wherever a resource needs
+ to use a predicate whose meaning matches one of these. For example,
+ if a resource has a description, and the application semantics of
+ that description is compatible with
+ <code>dcterms:description</code>
+ , then
+ <code>dcterms:description</code>
+ should be used. If needed, additional application-specific
+ predicates may be used. A specification for a domain may require one
+ or more of these properties for a particular resource type. The
+ Range column in the tables below identifies the defined
+ <code>rdfs:range</code>
+ for the properties.
+ </p>
+
+ <h4>Common Properties</h4>
+
+ <p>
+ <strong>From Dublin Core URI: <a
+ href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a></strong>
+ </p>
+
+ <table class="simple">
+ <thead>
+ <tr>
+ <th>Property</th>
+ <th>Range/DataType</th>
+ <th>Comment</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>dcterms:contributor</td>
+ <td>dcterms:Agent</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>dcterms:creator</td>
+ <td>dcterms:Agent</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>dcterms:created</td>
+ <td>xsd:dateTime</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>dcterms:description</td>
+ <td>rdf:XMLLiteral</td>
+ <td>Descriptive text about the resource represented as rich
+ text in XHTML format. should include only content that is valid
+ and suitable inside an XHTML element.</td>
+ </tr>
+ <tr>
+ <td>dcterms:identifier</td>
+ <td>rdfs:Literal</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>dcterms:modified</td>
+ <td>xsd:dateTime</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>dcterms:relation</td>
+ <td>rdfs:Resource</td>
+ <td>The HTTP URI of a related resource. This is the predicate
+ to use when you don't know what else to use. If you know more
+ specifically what sort of relationship it is, use a more specific
+ predicate.</td>
+ </tr>
+ <tr>
+ <td>dcterms:subject</td>
+ <td>rdfs:Resource</td>
+ <td></td>
+ </tr>
+ <tr>
+ <td>dcterms:title</td>
+ <td>rdf:XMLLiteral</td>
+ <td>A name given to the resource. Represented as rich text in
+ XHTML format. should include only content that is valid inside an
+ XHTML element.</td>
+ </tr>
+ </tbody>
+ </table>
+
+ <p>
+ The predicate
+ <code>dcterms:type</code>
+ should not be used, instead use
+ <code>rdf:type</code>
+ . [[DC-RDF]].
+ </p>
+
+ <p>
+ <strong>From RDF URI: <a
+ href="http://www.w3.org/1999/02/22-rdf-syntax-ns#">http://www.w3.org/1999/02/22-rdf-syntax-ns#</a></strong>
+ </p>
+
+ <table class="simple">
+ <thead>
+ <tr>
+ <th>Property</th>
+ <th>Range/DataType</th>
+ <th>Comment</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>rdf:type</td>
+ <td>rdfs:Class</td>
+ <td>The type or types of the resource</td>
+ </tr>
+ </tbody>
+ </table>
+
+ <p>
+ <strong>From RDF Schema URI: <a
+ href="http://www.w3.org/2000/01/rdf-schema#">http://www.w3.org/2000/01/rdf-schema#</a></strong>
+ </p>
+
+ <table class="simple">
+ <thead>
+ <tr>
+ <th>Property</th>
+ <th>Range/DataType</th>
+ <th>Comment</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>rdfs:member</td>
+ <td>rdfs:Resource</td>
+ <td> </td>
+ </tr>
+ <tr>
+ <td>rdfs:label</td>
+ <td>rdfs:Literal</td>
+ <td>Only use this in vocabulary documents, to define the name
+ of the vocabulary term.</td>
+ </tr>
+ </tbody>
+ </table>
+
+
+
+ </section>
+
+
+ <section>
+ <h3>Use qvalues properly</h3>
+
+ <p>Quality factors allow the user or user agent to indicate the
+ relative degree of preference for a media-range, using the qvalue
+ scale from 0 to 1. The default value is q=1. Take the following for
+ example:</p>
+
+ <p>
+ <code>Accept: text/turtle; q=0.5, application/json</code>
+ </p>
+
+ <p>This should be interpreted as "I prefer application/json, but
+ send me text/turtle if it is the best available after a 50%
+ mark-down in quality."</p>
+
+ <p>Improper handling of qvalues is a common problem in
+ implementations of content negotiation.
+ <p>Refer to Section 14, Header Field Definitions, in the
+ [[HTTP11]] specification to understand the proper use and evaluation
+ of qvalues for both client and server implementations.</p>
+
+ </section>
+
+ <section>
+ <h3>Respond with canonical URLs and use them for identity
+ comparison</h3>
+
+ <p>Clients can access an LDPR using multiple URLs. An LDPR server
+ should respond to each of those requests using a single consistent
+ URL, a canonical URL, for the LDPR. This canonical URL may be found
+ in the response's Location and/or Content-Location headers, and
+ potentially also in the representation of the LDPR. A common case is
+ URLs that vary by protocol, one HTTP and one HTTPS, but are
+ otherwise identical. In most cases those two URLs refer to the same
+ resource, and the server should respond to requests to either URL
+ with a single (canonical) URL.</p>
+
+ <p>Clients should use the canonical URL as an LDPR's identity;
+ for example, when determining if two URLs refer to the same resource
+ clients should compare the canonical URLs, not the URLs used to
+ access the resources.</p>
+
+ </section>
+
+ <section>
+ <h3>Representing relationships between resources</h3>
+ <p>LDPRs can use one RDF triple to represent a link
+ (relationship) to another resource. Having the source resource’s URI
+ as the subject and the target resource’s URI as the object of the
+ triple is enough. Contrary to a misconception that readers with
+ certain backgrounds may assume, the creation of an
+ "intermediate link" resource is not required to express
+ the relationship.</p>
+ </section>
+
+ <section>
+ <h3>Minimize server-specific constraints</h3>
+ <p>LDPR servers should enable simple creation and modification of
+ LDPRs.</p>
+
+ <P>It may be common for LDP servers to put restrictions on
+ representations – for example, the range of rdf:type predicates,
+ datatypes of the objects of predicates, and the number of
+ occurrences of predicates in an LDPR, but servers should minimize
+ such restrictions.</p>
+
+ <p>For some server applications, excessive constraints on
+ modification of resources may be required. However, enforcement of
+ more complex constraints will greatly restrict the set of clients
+ that can modify resources. For interoperability with a wider range
+ of clients, implementers are therefore encouraged to minimize
+ server-specific constraints.</p>
+ </section>
+
+ </section>
+ <!-- End Best Practices Section -->
+
+ <section>
+
+ <h2>Guidelines</h2>
+
+ <section>
+
+ <h3>Containers are not limited to same-subject, same-predicate
+ triples</h3>
+
+ <p>
+ The LDP specification defines a Container as "a Linked Data
+ Platform Resource (LDPR) representing a collection of same-subject,
+ same-predicate triples." This can easily be misconstrued to
+ mean that a Container should <em>only</em> contain same-subject,
+ same-predicate triples. While Containers <em>may</em> contain only
+ same-subject, same-predicate triples (i.e. the membership subjects
+ and membership predicates of its membership triples), it is free to
+ contain others. The definition is meant to clarify only those
+ attributes that are directly relavant to the interaction model of a
+ Container, but not to limit them to those attributes alone.
+ </p>
+
+ <p>It is important to remember that a Linked Data Platform
+ Container (LDPC) is also a Linked Data Platform Resource (LDPR) and
+ though it might exist as a membership controller, it may also
+ represent additional data that is valuable to the agents that access
+ it.</p>
+
+ </section>
+
+ <section>
+ <h3>Finding established vocabularies</h3>
+
+ <p>Following are some useful resources for finding and leveraging
+ pre-existing, common, and well-established vocabularies.</p>
+
+ <p style="clear: both">
+ <img src="lov-thumb.jpg" width="150"
+ style="float: left; margin: 0 20px 20px 0"> <a
+ href="http://lov.okfn.org" target="_blank">Linked Open
+ Vocabularies (LOV)</a><br /> LOV is an entry point to the growing
+ ecosystem of linked open vocabularies (RDFS or OWL ontologies) used
+ in the Linked Data Cloud. Users can find vocabularies listed and
+ individually described by metadata, classified by vocabulary spaces,
+ and interlinked using the dedicated vocabulary VOAF. The site allows
+ users to query the LOV dataset either at vocabulary level or at
+ element level, exploring the vocabulary content using full-text
+ faceted search, and finding metrics about the use of vocabularies in
+ the Semantic Web. Users can also suggest a new vocabulary to add to
+ LOV. [[LOV]]
+ </p>
+
+ <p style="clear: both">
+ <img src="lodCommonVocabs-thumb.jpg" width="150"
+ style="float: left; margin: 0 20px 20px 0"> <a
+ href="http://www.w3.org/wiki/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies"
+ target="_blank">Common Vocabularies / Ontologies / Micromodels</a><br />
+ A wiki list maintained by the Linked Data LOD community project.
+ [[LOD-COMMON-VOCABS]]
+ </p>
+
+ <div style="clear: both"></div>
+
+ </section>
+
+ </section>
+ <!-- End Guidelines Section -->
+
+ <section class='appendix'>
+ <h2>Acknowledgements</h2>
+ <p>Many thanks to Robin Berjon and all contributors to the <a href="http://www.w3.org/respec/">ReSpec</a> tool, which makes writing these kinds of documents much easier.
+ </p>
+ <p>To the following individuals who, in addition to the editors, have contributed either directly or indirectly to the ongoing improvement of this document:
+ <ul>
+ <li><a href="http://lehors.wordpress.com/">Arnaud Le Hors</a>, IBM</li>
+ <li><a href="http://www.linkedin.com/pub/ashok-malhotra/4/675/6a2">Ashok Malhotra</a>, Oracle</li>
+ <li>Bart van Leeuwen</li>
+ <li>David Wood</li>
+ <li><a href="http://www.w3.org/People/Eric/">Eric Prud'hommeaux</a>, W3C</li>
+ <li>Henry Story</li>
+ <li>John Arwe, IBM</li>
+ <li>Kevin Page</li>
+ <li>Miel Vander Sande</li>
+ <li><a href="http://melvincarvalho.com/">Melvin Carvalho</a></li>
+ <li>Raúl García Castro</li>
+ <li><a href="http://richard.cyganiak.de/">Richard Cyganiak</a></li>
+ <li><a href="http://www.linkedin.com/in/yadnem">Roger Menday</a>, Fujitsu Laboratories of Europe</li>
+ <li><a href="http://www.w3.org/People/Sandro/">Sandro Hawke</a>, W3C</li>
+ <li><a href="http://stevespeicher.blogspot.com/">Steve Speicher</a>, IBM</li>
+ <li>Ted Thibodeau</li>
+ </ul>
+ </section>
+
+
</body>
</html>
Binary file ldp-bp/lodCommonVocabs-thumb.jpg has changed
Binary file ldp-bp/lov-thumb.jpg has changed
--- a/ldp-bp/rdf-absolute-uris.ttl Wed Mar 05 16:33:45 2014 +0000
+++ b/ldp-bp/rdf-absolute-uris.ttl Wed Mar 05 16:34:18 2014 +0000
@@ -8,5 +8,4 @@
rdfs:member
<http://example.org/container1/member1>,
<http://example.org/container1/member2>,
- <http://example.org/container1/member3>.
-]]
\ No newline at end of file
+ <http://example.org/container1/member3>.
\ No newline at end of file
--- a/ldp-bp/rdf-relative-uris.ttl Wed Mar 05 16:33:45 2014 +0000
+++ b/ldp-bp/rdf-relative-uris.ttl Wed Mar 05 16:34:18 2014 +0000
@@ -5,4 +5,3 @@
<> a ldp:Container;
dcterms:title "A very simple container";
rdfs:member <member1>, <member2>, <member3> .
-]]
--- a/ldp-bp/trailing-slash-1.ttl Wed Mar 05 16:33:45 2014 +0000
+++ b/ldp-bp/trailing-slash-1.ttl Wed Mar 05 16:34:18 2014 +0000
@@ -8,5 +8,4 @@
rdfs:member
<http://example.org/container1/member1>,
<http://example.org/container1/member2>,
- <http://example.org/container1/member3>.
-]]
\ No newline at end of file
+ <http://example.org/container1/member3>.
\ No newline at end of file
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp-diff-20140210.html Wed Mar 05 16:34:18 2014 +0000
@@ -0,0 +1,23508 @@
+<!--
+ Editor TODO:
+ - Search "TODO" within this document.
+ - Once companion documents (best practices, primer) have URLs, link to them. Search on "companion".
+ - Once the membership* names stabilize, take a pass through for "membership consistent value", membership-constant-URI
+ and see if there is a friendlier way to phrase it.
+ - Paging intro: add 3rd example showing header linkage amongst pages and (HEAD on) the base resource.
+ Maybe also insert HEAD on base as new first example instead of relying on text alone.
+ - The ReSpec SPARQL QUERY link is http://www.w3.org/TR/rdf-sparql-query/ , which has highlighted text
+ referring readers to SPARQL 1.1. Which normative reference do we want?
+ Various pre-LC comments:
+ - 5.2.5.1 For a given triple T with a subject C of the LDPC and predicate of ldp:containsRelation,
+ 5.2.5.2 For a given triple T with a subject C of the LDPC and predicate of ldp:containedByRelation,
+ 5.2.10 Some LDPC's have membership object's that are not directly URIs minted upon LDPC member creation,
+ (JohnA) I found these particularly hard to read. And I perpetrated the SortCollation paragraphs.
+ Links to examples might be an 80-20 solution.
+ - 5.3.1: I'd change the link to the example ("as in the example") to refer the concrete example #, I think example 9.
+ Currently does not work when printing.
+ Misc during LC comments:
+ - http://lists.w3.org/Archives/Public/public-ldp/2013Aug/0002.html
+ #1 Should update example in 5.1.3 to be more clear on what the request vs base URI is. Also example is missing ldp:nextPage.
+ -->
+<html xmlns="http://www.w3.org/1999/xhtml">
+<head>
+<title>Linked Data Platform 1.0</title>
+<!-- Changed by: , 07-Feb-2014 -->
+<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,
+ -->
+
+<script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async="" type="text/javascript">
+</script>
+<script class='remove' type="text/javascript">
+//<![CDATA[
+ var respecConfig = {
+ // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+ specStatus: "ED",
+
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ shortName: "ldp",
+
+ // if your specification has a subtitle that goes below the main
+ // formal title, define it here
+ // subtitle : "an excellent document",
+
+ // if you wish the publication date to be other than today, set this
+ publishDate: "",
+
+ // if the specification's copyright date is a range of years, specify
+ // the start date here:
+ // copyrightStart: "2005"
+
+ // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+ // and its maturity status
+ previousPublishDate: "2013-07-30",
+ previousMaturity: "LC",
+ previousURI: "http://www.w3.org/TR/2013/WD-ldp-20130730/",
+
+ // if there a publicly available Editor's Draft, this is the link
+ edDraftURI: "http://www.w3.org/2012/ldp/hg/ldp.html",
+
+ // if this is a LCWD, uncomment and set the end of its review period
+ lcEnd: "2013-09-02",
+
+ // Only include h1 and h2 level
+ maxTocLevel: 2,
+
+ // if you want to have extra CSS, append them to this list
+ // it is recommended that the respec.css stylesheet be kept
+ //extraCSS: ["https://dvcs.w3.org/hg/ldpwg/css/respec.css"],
+
+ // editors, add as many as you like
+ // only "name" is required
+ editors: [
+ { name: "Steve Speicher", url: "http://stevespeicher.blogspot.com",
+ company: "IBM Corporation", companyURL: "http://ibm.com/" },
+ { name: "John Arwe", url: "https://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/allcommunities?userid=120000CAW7",
+ company: "IBM Corporation", companyURL: "http://ibm.com/" },
+ {name: "Ashok Malhotra", url: "mailto:ashok.malhotra@oracle.com",
+ company: "Oracle Corporation", companyURL: "http://www.oracle.com" },
+ ],
+
+ // authors, add as many as you like.
+ // This is optional, uncomment if you have authors as well as editors.
+ // only "name" is required. Same format as editors.
+
+ //authors: [
+ // { name: "Your Name", url: "http://example.org/",
+ // company: "Your Company", companyURL: "http://example.com/" },
+ //],
+
+ // name of the WG
+ wg: "Linked Data Platform Working Group",
+
+ // URI of the public WG page
+ wgURI: "http://www.w3.org/2012/ldp",
+
+ // name (without the @w3c.org) of the public mailing to which comments are due
+ wgPublicList: "public-ldp-comments",
+
+ // URI of the patent status for this WG, for Rec-track documents
+ // !!!! IMPORTANT !!!!
+ // This is important for Rec-track documents, do not copy a patent URI from a random
+ // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+ // Team Contact.
+ wgPatentURI: "http://www.w3.org/2004/01/pp-impl/55082/status",
+ doRDFa: "1.1",
+ localBiblio: {
+ "HTTPBIS-SEMANTICS": {
+ title: "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"
+ , href: "http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics/"
+ , authors: [
+ "R. Fielding"
+ , "J. Reschke"
+ ]
+ , status: "In Last Call"
+ , publisher: "IETF"
+ },
+ "RFC2817": {
+ title: "Upgrading to TLS Within HTTP/1.1"
+ , href: "http://tools.ietf.org/html/rfc2817"
+ , authors: [
+ "R. Khare"
+ , "S. Lawrence"
+ ]
+ , status: "Proposed Standard"
+ , publisher: "IETF"
+ },
+ "RFC5005": {
+ title: "Feed Paging and Archiving"
+ , href: "http://tools.ietf.org/html/rfc5005"
+ , authors: [
+ "M. Nottingham"
+ ]
+ , status: "Proposed Standard"
+ , publisher: "IETF"
+ }
+ },
+ };
+//]]>
+</script>
+<style type="text/css">
+/*<![CDATA[*/
+ 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;
+ }
+ .normal {
+ font-weight: normal;
+ font: normal 100% sans-serif;
+ }
+
+/*]]>*/
+</style>
+
+<style type="text/css" media="all">
+/*<![CDATA[*/
+ 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 type='text/css'>
+.diff-old-a {
+ font-size: smaller;
+ color: red;
+}
+
+.diff-new { background-color: yellow; }
+.diff-chg { background-color: lime; }
+.diff-new:before,
+.diff-new:after
+ { content: "\2191" }
+.diff-chg:before, .diff-chg:after
+ { content: "\2195" }
+.diff-old { text-decoration: line-through; background-color: #FBB; }
+.diff-old:before,
+.diff-old:after
+ { content: "\2193" }
+:focus { border: thin red solid}
+</style>
+</head>
+<body>
+<del class="diff-old">Linked
+Data
+Platform
+1.0
+W3C
+Last
+Call
+Working
+Draft
+30
+July
+2013
+This
+version:
+http://www.w3.org/TR/2013/WD-ldp-20130730/
+Latest
+published
+version:
+http://www.w3.org/TR/ldp/
+Latest
+editor's
+draft:
+http://www.w3.org/2012/ldp/hg/ldp.html
+Previous
+version:
+http://www.w3.org/TR/2013/WD-ldp-20130307/
+Editors:
+Steve
+Speicher
+,
+IBM
+Corporation
+John
+Arwe
+,
+IBM
+Corporation
+Ashok
+Malhotra
+,
+Oracle
+Corporation
+Copyright
+©
+2013
+W3C
+®
+(
+MIT
+,
+ERCIM
+,
+Keio
+,
+Beihang
+),
+All
+Rights
+Reserved.
+W3C
+liability
+,
+trademark
+and
+document
+use
+rules
+apply.
+Abstract
+</del>
+<section id='abstract'>
+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.
+<del class="diff-old">Status
+of
+This
+Document
+This
+section
+describes
+the
+status
+of
+this
+document
+at
+the
+time
+of
+its
+publication.
+Other
+documents
+may
+supersede
+this
+document.
+A
+list
+of
+current
+W3C
+publications
+and
+the
+latest
+revision
+of
+this
+technical
+report
+can
+be
+found
+in
+the
+W3C
+technical
+reports
+index
+at
+http://www.w3.org/TR/.
+This
+document
+was
+published
+by
+the
+Linked
+Data
+Platform
+Working
+Group
+as
+a
+Last
+Call
+Working
+Draft.
+This
+document
+is
+intended
+to
+become
+a
+W3C
+Recommendation.
+If
+you
+wish
+to
+make
+comments
+regarding
+this
+document,
+please
+send
+them
+to
+public-ldp-comments@w3.org
+(
+subscribe
+,
+archives
+).
+The
+Last
+Call
+period
+ends
+02
+September
+2013.
+All
+comments
+are
+welcome.
+Publication
+as
+a
+Last
+Call
+Working
+Draft
+does
+not
+imply
+endorsement
+by
+the
+W3C
+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.
+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.
+This
+document
+was
+produced
+by
+a
+group
+operating
+under
+the
+5
+February
+2004
+W3C
+Patent
+Policy
+.
+W3C
+maintains
+a
+public
+list
+of
+any
+patent
+disclosures
+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
+Essential
+Claim(s)
+must
+disclose
+the
+information
+in
+accordance
+with
+section
+6
+of
+the
+W3C
+Patent
+Policy
+.
+Table
+of
+Contents
+1.
+Introduction
+2.
+Terminology
+2.1
+Conventions
+Used
+in
+This
+Document
+3.
+Conformance
+4.
+Linked
+Data
+Platform
+Resources
+4.1
+Informative
+4.2
+General
+4.3
+HTTP
+GET
+4.4
+HTTP
+POST
+4.5
+HTTP
+PUT
+4.6
+HTTP
+DELETE
+4.7
+HTTP
+HEAD
+4.8
+HTTP
+PATCH
+4.9
+HTTP
+OPTIONS
+4.10
+Paging
+4.10.1
+Introduction
+4.10.2
+HTTP
+GET
+4.10.3
+HTTP
+OPTIONS
+4.11
+Resource
+Inlining:
+Representing
+Multiple
+Resources
+in
+a
+Response
+4.11.1
+Introduction
+4.11.2
+Use
+with
+Care
+4.11.3
+HTTP
+GET
+5.
+Linked
+Data
+Platform
+Containers
+5.1
+Informative
+5.2
+General
+5.3
+HTTP
+GET
+5.4
+HTTP
+POST
+5.5
+HTTP
+PUT
+5.6
+HTTP
+DELETE
+5.7
+HTTP
+HEAD
+5.8
+HTTP
+PATCH
+5.9
+HTTP
+OPTIONS
+5.10
+Member
+Inlining:
+Returning
+All
+of
+a
+Container
+Page's
+Members
+in
+a
+Response
+5.10.1
+Introduction
+5.10.2
+HTTP
+GET
+6.
+HTTP
+Header
+Definitions
+6.1
+The
+Accept-Post
+Response
+Header
+A.
+Acknowledgements
+B.
+References
+B.1
+Normative
+references
+B.2
+Informative
+references
+</del>
+</section>
+<del class="diff-old">1.
+</del>
+<section class="informative" id="intro">
+<h1>
+Introduction
+<del class="diff-old">This
+section
+is
+non-normative.
+</del>
+</h1>
+<p>
+This
+<del class="diff-old">document
+</del>
+<ins class="diff-chg">specification
+</ins>
+describes
+the
+use
+of
+HTTP
+for
+accessing,
+updating,
+creating
+and
+deleting
+resources
+from
+servers
+that
+expose
+their
+resources
+as
+Linked
+Data.
+<del class="diff-old"> It
+</del>
+<ins class="diff-chg"> It
+</ins>
+provides
+clarifications
+and
+extensions
+of
+the
+<del class="diff-old">four
+</del>
+rules
+of
+Linked
+Data
+<del class="diff-old">[
+LINKED-DATA
+]:
+</del>
+<ins class="diff-chg">[[LINKED-DATA]]:
+</ins>
+</p>
+<del class="diff-old">1.
+</del>
+<ol>
+<li>
+Use
+URIs
+as
+names
+for
+things
+<del class="diff-old">2.
+</del>
+</li>
+<li>
+Use
+HTTP
+URIs
+so
+that
+people
+can
+look
+up
+those
+names
+<del class="diff-old">3.
+</del>
+</li>
+<li>
+When
+someone
+looks
+up
+a
+URI,
+provide
+useful
+information,
+using
+the
+standards
+<del class="diff-old">(
+RDF
+*,
+</del>
+<ins class="diff-chg">(RDF*,
+</ins>
+<abbr title="SPARQL Protocol and RDF Query Language">
+SPARQL
+</abbr>
+)
+<del class="diff-old">4.
+</del>
+</li>
+<li>
+Include
+links
+to
+other
+URIs,
+so
+that
+they
+can
+discover
+more
+things
+</li>
+</ol>
+<p>
+This
+specification
+discusses
+standard
+HTTP
+and
+RDF
+techniques
+<ins class="diff-new">used
+when
+constructing
+clients
+</ins>
+and
+<ins class="diff-new">servers
+that
+create,
+read,
+and
+write
+</ins><a title="Linked Data Platform Resource"><ins class="diff-new">
+Linked
+Data
+Platform
+Resources
+</ins></a>.<ins class="diff-new">
+A
+companion
+document
+discusses
+</ins>
+best
+practices
+that
+you
+should
+use,
+and
+anti-patterns
+you
+should
+avoid,
+when
+constructing
+<ins class="diff-new">these
+</ins>
+clients
+and
+<del class="diff-old">servers
+that
+read
+and
+write
+Linked
+Data
+</del>
+<ins class="diff-chg">servers.
+</ins></p><p><ins class="diff-chg">
+This
+specification
+provides
+a
+widely
+re-usable
+pattern
+to
+deal
+with
+large
+</ins>
+resources.
+<ins class="diff-new">Depending
+on
+the
+server’s
+capabilities,
+a
+GET
+request
+on
+a
+</ins><a title="Paged resource"><ins class="diff-new">
+resource
+</ins></a><ins class="diff-new">
+can
+be
+redirected
+to
+a
+</ins><a title="Single-page resource"><ins class="diff-new">
+subset
+of
+the
+resource
+(one
+page)
+</ins></a>,<ins class="diff-new">
+that
+provides
+access
+to
+subsequent
+pages
+(see
+</ins><a href="#ldpr-Paging" class="sectionRef"></a><ins class="diff-new">
+).
+</ins>
+</p>
+<p>
+<del class="diff-old">A
+</del>
+<ins class="diff-chg">This
+specification
+defines
+a
+</ins>
+special
+type
+of
+<a>
+Linked
+Data
+Platform
+Resource
+<del class="diff-old">is
+</del>
+</a>:
+a
+<a title="Linked Data Platform Container">
+Container
+</a>.
+Containers
+are
+very
+useful
+in
+building
+application
+models
+involving
+collections
+of
+<ins class="diff-new">resources,
+often
+</ins>
+homogeneous
+<del class="diff-old">resources.
+</del>
+<ins class="diff-chg">ones.
+</ins>
+For
+example,
+universities
+offer
+a
+collection
+of
+classes
+and
+have
+a
+collection
+of
+faculty
+members,
+each
+faculty
+member
+teaches
+a
+collection
+of
+courses,
+<del class="diff-old">etc.
+</del>
+<ins class="diff-chg">and
+so
+on.
+</ins>
+This
+specification
+discusses
+how
+to
+work
+with
+containers.
+Resources
+can
+be
+added
+to
+containers
+<del class="diff-old">in
+several
+ways.
+As
+a
+special
+case,
+members
+can
+both
+be
+created
+and
+added
+to
+a
+container
+by
+overloading
+the
+</del>
+<ins class="diff-chg">using
+standard
+HTTP
+operations
+like
+</ins>
+POST
+<del class="diff-old">operation
+</del>
+(see
+<a href="#ldpc-HTTP_POST" class="sectionRef">
+<del class="diff-old">section
+5.4
+).
+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
+section
+4.10
+</del>
+</a>
+).
+</p>
+<p>
+The
+intention
+of
+this
+<del class="diff-old">document
+</del>
+<ins class="diff-chg">specification
+</ins>
+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>
+<p>
+<ins class="diff-chg">For
+context
+and
+background,
+it
+could
+be
+useful
+to
+read
+</ins><a href="#bib-LDP-UCR"><ins class="diff-chg">
+Linked
+Data
+Platform
+Use
+Case
+and
+Requirements
+</ins></a><ins class="diff-chg">
+[[LDP-UCR]]
+and
+</ins><a href="#base-specs" class="sectionRef">
+<del class="diff-old">2.
+</del>
+</a>.
+</p>
+</section>
+<section id="terms">
+<h1>
+Terminology
+</h1>
+<p>
+Terminology
+is
+based
+on
+<del class="diff-old">W3C
+'s
+</del>
+<ins class="diff-chg">W3C's
+</ins>
+Architecture
+of
+the
+World
+Wide
+Web
+<del class="diff-old">[
+WEBARCH
+]
+</del>
+<ins class="diff-chg">[[WEBARCH]]
+</ins>
+and
+Hyper-text
+Transfer
+Protocol
+<del class="diff-old">[
+HTTP11
+].
+</del>
+<ins class="diff-chg">[[HTTP11]].
+</ins>
+</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
+<del class="diff-old">[
+WEBARCH
+].
+</del>
+<ins class="diff-chg">[[WEBARCH]].
+</ins>
+<p>
+</p>
+</dd>
+<dt>
+Linked
+Data
+</dt>
+<dd>
+As
+defined
+by
+Tim
+Berners-Lee
+<del class="diff-old">[
+LINKED-DATA
+].
+Linked
+Data
+Platform
+Resource
+(
+LDPR
+)
+HTTP
+resource
+whose
+state
+is
+represented
+in
+RDF
+that
+conforms
+to
+the
+simple
+lifecycle
+patterns
+and
+conventions
+in
+section
+4.
+.
+Linked
+Data
+Platform
+Container
+(
+LDPC
+)
+An
+LDPR
+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.
+</del>
+<ins class="diff-chg">[[LINKED-DATA]].
+</ins>
+<p>
+</p>
+</dd>
+<dt>
+Client
+</dt>
+<dd>
+A
+program
+that
+establishes
+connections
+for
+the
+purpose
+of
+sending
+requests
+<del class="diff-old">[
+HTTP11
+].
+</del>
+<ins class="diff-chg">[[HTTP11]].
+</ins>
+<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
+<del class="diff-old">[
+</del>
+<ins class="diff-chg">[[HTTP11]].
+</ins></p></dd><dt>
+<del class="diff-old">HTTP11
+</del>
+<dfn>
+<ins class="diff-chg">Linked
+Data
+Platform
+Resource
+</ins></dfn><ins class="diff-chg">
+(
+</ins><abbr title="Linked Data Platform Resource"><ins class="diff-chg">
+LDPR
+</ins></abbr><ins class="diff-chg">
+)
+</ins></dt><dd><ins class="diff-chg">
+A
+HTTP
+resource
+whose
+state
+is
+represented
+in
+any
+way
+that
+conforms
+to
+the
+simple
+lifecycle
+patterns
+and
+conventions
+in
+</ins><a href="#ldpr" class="sectionRef"></a>.<p></p></dd><dt><dfn><ins class="diff-chg">
+Linked
+Data
+Platform
+RDF
+Resource
+</ins></dfn><ins class="diff-chg">
+(
+</ins><abbr title="Linked Data Platform RDF Resource"><ins class="diff-chg">
+LDP-RR
+</ins></abbr><ins class="diff-chg">
+)
+</ins></dt><dd><ins class="diff-chg">
+An
+</ins><a title="Linked Data Platform Resource"><ins class="diff-chg">
+LDPR
+</ins></a><ins class="diff-chg">
+whose
+state
+is
+represented
+in
+RDF,
+corresponding
+to
+an
+RDF
+</ins><a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph"><ins class="diff-chg">
+named
+graph
+</ins>
+</a>
+<ins class="diff-new">[[rdf11-concepts]].
+</ins><p>
+<del class="diff-old">].
+</del>
+</p>
+</dd>
+<dt>
+<dfn>
+<ins class="diff-new">Linked
+Data
+Platform
+Binary
+Resource
+</ins></dfn><ins class="diff-new">
+(
+</ins><abbr title="Linked Data Platform Binary Resource"><ins class="diff-new">
+LDP-BR
+</ins></abbr><ins class="diff-new">
+)
+</ins></dt><dd><ins class="diff-new">
+A
+</ins><a title="Linked Data Platform Resource"><ins class="diff-new">
+LDPR
+</ins></a><ins class="diff-new">
+whose
+state
+is
+</ins><em><ins class="diff-new">
+not
+</ins></em><ins class="diff-new">
+represented
+in
+RDF.
+These
+are
+binary
+or
+text
+documents
+that
+do
+not
+have
+useful
+RDF
+representations.
+</ins><p>
+</p>
+</dd>
+<dt>
+<dfn>
+<ins class="diff-chg">Linked
+Data
+Platform
+Container
+</ins></dfn><ins class="diff-chg">
+(
+</ins><abbr title="Linked Data Platform Container"><ins class="diff-chg">
+LDPC
+</ins></abbr><ins class="diff-chg">
+)
+</ins></dt><dd><ins class="diff-chg">
+An
+LDPR
+representing
+a
+collection
+of
+</ins><a title="Membership"><ins class="diff-chg">
+member
+</ins></a><ins class="diff-chg">
+resources
+and/or
+</ins><a title="Containment"><ins class="diff-chg">
+contained
+</ins></a><ins class="diff-chg">
+documents
+(information
+resources
+[[!WEBARCH]])
+that
+responds
+to
+client
+requests
+for
+creation,
+modification,
+and/or
+enumeration
+of
+its
+members
+and
+documents,
+and
+that
+conforms
+to
+the
+simple
+lifecycle
+patterns
+and
+conventions
+in
+</ins><a href="#ldpc" class="sectionRef"></a>.<p></p></dd><dt><dfn><ins class="diff-chg">
+Linked
+Data
+Platform
+Basic
+Container
+</ins></dfn><ins class="diff-chg">
+(
+</ins><abbr title="Linked Data Platform Basic Container"><ins class="diff-chg">
+LDP-BC
+</ins></abbr><ins class="diff-chg">
+)
+</ins></dt><dd><ins class="diff-chg">
+A
+</ins><a title="Linked Data Platform Container"><ins class="diff-chg">
+LDPC
+</ins></a><ins class="diff-chg">
+that
+uses
+a
+single
+pre-defined
+predicate
+to
+link
+to
+both
+its
+</ins><a title="Containment"><ins class="diff-chg">
+contained
+</ins></a><ins class="diff-chg">
+and
+</ins><a title="Membership"><ins class="diff-chg">
+member
+</ins></a><ins class="diff-chg">
+documents
+(information
+resources)
+[[!WEBARCH]].
+</ins><p></p></dd><dt><dfn><ins class="diff-chg">
+Linked
+Data
+Platform
+Direct
+Container
+</ins></dfn><ins class="diff-chg">
+(
+</ins><abbr title="Linked Data Platform Direct Container"><ins class="diff-chg">
+LDP-DC
+</ins></abbr><ins class="diff-chg">
+)
+</ins></dt><dd><ins class="diff-chg">
+A
+</ins><a title="Linked Data Platform Container"><ins class="diff-chg">
+LDPC
+</ins></a><ins class="diff-chg">
+that
+has
+the
+flexibility
+of
+choosing
+what
+form
+its
+</ins><a title="Membership triples"><ins class="diff-chg">
+membership
+triples
+</ins></a><ins class="diff-chg">
+take,
+and
+allows
+</ins><a title="Membership"><ins class="diff-chg">
+members
+</ins></a><ins class="diff-chg">
+to
+be
+any
+resources
+[[!WEBARCH]],
+not
+only
+documents.
+</ins><p></p></dd><dt><dfn><ins class="diff-chg">
+Linked
+Data
+Platform
+Indirect
+Container
+</ins></dfn><ins class="diff-chg">
+(
+</ins><abbr title="Linked Data Platform Indirect Container"><ins class="diff-chg">
+LDP-IC
+</ins></abbr><ins class="diff-chg">
+)
+</ins></dt><dd><ins class="diff-chg">
+A
+</ins><a title="Linked Data Platform Container"><ins class="diff-chg">
+LDPC
+</ins></a><ins class="diff-chg">
+that
+is
+similar
+to
+a
+</ins><a title="Linked Data Platform Direct Container"><ins class="diff-chg">
+LDP-DC
+</ins></a><ins class="diff-chg">
+and
+is
+capable
+of
+accepting
+creation
+requests
+that
+result
+in
+</ins><a title="Membership"><ins class="diff-chg">
+members
+</ins></a><ins class="diff-chg">
+being
+added
+based
+on
+the
+content
+of
+its
+</ins><a title="Containment"><ins class="diff-chg">
+contained
+</ins></a><ins class="diff-chg">
+documents
+rather
+than
+the
+URIs
+assigned
+to
+those
+documents.
+</ins><p></p></dd><dt><dfn><ins class="diff-chg">
+Membership
+</ins></dfn></dt><dd><ins class="diff-chg">
+The
+relationship
+linking
+an
+LDP-RR
+(LDPCs
+are
+also
+LDP-RRs)
+and
+its
+member
+LDPRs.
+There
+often
+is
+a
+linked
+LDPC
+that
+assists
+with
+managing
+the
+member
+LDPRs.
+</ins><p></p></dd><dt><dfn>
+Membership
+triples
+</dfn>
+</dt>
+<dd>
+A
+set
+of
+triples
+in
+an
+<del class="diff-old">LDPC
+'s
+</del>
+<ins class="diff-chg">LDPC's
+</ins>
+state
+that
+lists
+its
+members.
+<del class="diff-old">The
+</del>
+<ins class="diff-chg">A
+container's
+</ins>
+membership
+triples
+<ins class="diff-new">all
+have
+one
+</ins>
+of
+<ins class="diff-new">the
+following
+patterns:
+</ins><table style="margin-left: +3em"><tr><td style="padding:0 0 0 +2ex"><var style="background:#DDDDDD"><ins class="diff-new">
+membership-constant-URI
+</ins></var></td><td style="padding:0 0 0 +2ex"><var><ins class="diff-new">
+membership-predicate
+</ins></var></td><td style="padding:0 0 0 +2ex"><var style="background:#CCFFFF"><ins class="diff-new">
+member-derived-URI
+</ins></var></td></tr><tr><td style="padding:0 0 0 +2ex"><var style="background:#CCFFFF"><ins class="diff-new">
+member-derived-URI
+</ins></var></td><td style="padding:0 0 0 +2ex"><var><ins class="diff-new">
+membership-predicate
+</ins></var></td><td style="padding:0 0 0 +2ex"><var style="background:#DDDDDD"><ins class="diff-new">
+membership-constant-URI
+</ins></var></td></tr></table><ins class="diff-new">
+The
+difference
+between
+the
+two
+is
+simply
+which
+position
+member-derived-URI
+occupies,
+which
+is
+usually
+driven
+by
+the
+choice
+of
+</ins><var><ins class="diff-new">
+membership-predicate
+</ins></var>.<ins class="diff-new">
+Most
+predicates
+have
+</ins>
+a
+<ins class="diff-new">natural
+forward
+direction
+inherent
+in
+their
+name,
+and
+existing
+vocabularies
+contain
+useful
+examples
+that
+read
+naturally
+in
+each
+direction.
+</ins><code><ins class="diff-new">
+ldp:member
+</ins></code><ins class="diff-new">
+and
+</ins><code><ins class="diff-new">
+dcterms:isPartOf
+</ins></code><ins class="diff-new">
+are
+representative
+examples.
+</ins><p><ins class="diff-new">
+Each
+</ins>
+container
+<del class="diff-old">all
+have
+</del>
+<ins class="diff-chg">exposes
+properties
+(see
+</ins><a href="#ldpc-general" class="sectionRef"></a><ins class="diff-chg">
+)
+that
+allow
+clients
+to
+determine
+which
+pattern
+it
+uses,
+what
+</ins>
+the
+<del class="diff-old">same
+subject
+</del>
+<ins class="diff-chg">actual
+</ins><var><ins class="diff-chg">
+membership-predicate
+</ins></var>
+and
+<del class="diff-old">predicate,
+</del>
+<var>
+<ins class="diff-chg">membership-constant-URI
+</ins></var><ins class="diff-chg">
+values
+are,
+</ins>
+and
+<ins class="diff-new">(for
+containers
+that
+allow
+</ins>
+the
+<del class="diff-old">objects
+</del>
+<ins class="diff-chg">creation
+</ins>
+of
+<ins class="diff-new">new
+members)
+what
+value
+is
+used
+for
+</ins>
+the
+<del class="diff-old">membership
+triples
+identify
+</del>
+<var>
+<ins class="diff-chg">member-derived-URI
+</ins></var><ins class="diff-chg">
+based
+on
+</ins>
+the
+<del class="diff-old">container's
+members.
+</del>
+<ins class="diff-chg">client's
+input
+to
+the
+creation
+process.
+</ins></p>
+<p>
+</p>
+</dd>
+<dt>
+<dfn>
+Membership
+<del class="diff-old">subject
+</del>
+<ins class="diff-chg">predicate
+</ins>
+</dfn>
+</dt>
+<dd>
+The
+<del class="diff-old">subject
+</del>
+<ins class="diff-chg">predicate
+</ins>
+of
+all
+a
+<del class="diff-old">LDPC
+'s
+</del>
+<ins class="diff-chg">LDPC's
+</ins><a title="Membership triples">
+membership
+triples
+</a>.
+<p>
+</p>
+</dd>
+<dt>
+<del class="diff-old">Membership
+predicate
+</del>
+<dfn>
+<ins class="diff-chg">Containment
+</ins>
+</dfn>
+</dt>
+<dd>
+The
+<del class="diff-old">predicate
+</del>
+<ins class="diff-chg">relationship
+binding
+an
+LDPC
+to
+LDPRs
+whose
+lifecycle
+it
+controls
+and
+is
+aware
+of.
+The
+lifecycle
+</ins>
+of
+<del class="diff-old">all
+</del>
+<ins class="diff-chg">the
+contained
+LDPR
+is
+limited
+by
+the
+lifecycle
+of
+the
+containing
+LDPC;
+that
+is,
+</ins>
+a
+<ins class="diff-chg">contained
+LDPR
+cannot
+be
+created
+(through
+LDP-defined
+means)
+before
+its
+containing
+</ins>
+LDPC
+<del class="diff-old">'s
+membership
+triples
+.
+</del>
+<ins class="diff-chg">exists.
+</ins>
+<p>
+</p>
+</dd>
+<dt>
+<del class="diff-old">Page
+resource
+</del>
+<dfn>
+<ins class="diff-chg">Containment
+triples
+</ins>
+</dfn>
+</dt>
+<dd>
+A
+<del class="diff-old">type
+</del>
+<ins class="diff-chg">set
+</ins>
+of
+<del class="diff-old">LDPR
+</del>
+<ins class="diff-chg">triples
+in
+an
+LDPC's
+state,
+maintained
+by
+the
+LDPC,
+that
+lists
+documents
+created
+by
+the
+LDPC
+but
+not
+yet
+deleted.
+These
+triples
+</ins><strong><ins class="diff-chg">
+always
+</ins></strong><ins class="diff-chg">
+have
+the
+form:
+</ins><var><ins class="diff-chg">
+(
+LDPC
+URI,
+ldp:contains
+,
+document-URI
+)
+</ins></var>.<p></p></dd><dt><dfn><ins class="diff-chg">
+Empty-container
+triples
+</ins></dfn></dt><dd><ins class="diff-chg">
+The
+portion
+of
+an
+LDPC's
+state
+</ins>
+that
+<ins class="diff-new">would
+be
+present
+when
+the
+container
+</ins>
+is
+<del class="diff-old">associated
+</del>
+<ins class="diff-chg">empty.
+Currently,
+this
+definition
+is
+equivalent
+</ins>
+to
+<del class="diff-old">another
+LDPR
+</del>
+<ins class="diff-chg">all
+the
+LDPC's
+triples
+minus
+its
+containment
+triples
+</ins>
+and
+<del class="diff-old">whose
+representation
+includes
+a
+subset
+</del>
+<ins class="diff-chg">minus
+its
+membership
+triples,
+but
+if
+future
+versions
+of
+LDP
+define
+additional
+classes
+</ins>
+of
+<del class="diff-old">the
+</del>
+triples
+<del class="diff-old">in
+the
+associated
+LDPR
+.
+</del>
+<ins class="diff-chg">then
+this
+definition
+would
+expand
+to
+subtract
+out
+those
+classes
+as
+well.
+</ins>
+<p>
+</p>
+</dd>
+<dt>
+<del class="diff-old">Non-member
+</del>
+<dfn>
+<ins class="diff-chg">Paged
+</ins>
+resource
+</dfn>
+</dt>
+<dd>
+A
+<del class="diff-old">resource
+associated
+with
+a
+LDPC
+by
+</del>
+<ins class="diff-chg">LDP-RR
+whose
+representation
+may
+be
+too
+large
+to
+fit
+in
+</ins>
+a
+<del class="diff-old">server
+</del>
+<ins class="diff-chg">single
+HTTP
+response,
+</ins>
+for
+<del class="diff-old">the
+purpose
+of
+enabling
+clients
+to
+retrieve
+</del>
+<ins class="diff-chg">which
+an
+LDP
+server
+offers
+</ins>
+a
+<del class="diff-old">subset
+</del>
+<ins class="diff-chg">sequence
+</ins>
+of
+<ins class="diff-new">single-page
+</ins><a title="Linked Data Platform RDF Resource"><ins class="diff-new">
+LDP-RRs
+</ins></a>.<ins class="diff-new">
+When
+</ins>
+the
+<del class="diff-old">LDPC
+'s
+state,
+namely
+the
+subset
+that
+omits
+</del>
+<ins class="diff-chg">representations
+of
+</ins>
+the
+<del class="diff-old">LDPC
+'s
+membership
+triples.
+In
+other
+words,
+</del>
+<ins class="diff-chg">sequence's
+resources
+are
+combined
+by
+a
+client,
+</ins>
+the
+<del class="diff-old">union
+</del>
+<ins class="diff-chg">client
+has
+a
+(potentially
+incomplete
+or
+incoherent)
+copy
+</ins>
+of
+the
+<del class="diff-old">non-member
+</del>
+<ins class="diff-chg">paged
+</ins>
+resource's
+<del class="diff-old">state
+</del>
+<ins class="diff-chg">state.
+If
+a
+paged
+resource
+</ins><var><ins class="diff-chg">
+P
+</ins></var><ins class="diff-chg">
+is
+a
+LDP-RR
+</ins>
+and
+<ins class="diff-new">is
+broken
+into
+a
+sequence
+of
+pages
+(single-page
+resources)
+</ins><var><ins class="diff-new">
+P
+</ins><sub><ins class="diff-new">
+1
+</ins></sub>,<ins class="diff-new">
+P
+</ins><sub><ins class="diff-new">
+2
+</ins></sub>,<ins class="diff-new">
+...,P
+</ins><sub><ins class="diff-new">
+n
+</ins></sub></var>,<ins class="diff-new">
+the
+representation
+of
+each
+</ins><var><ins class="diff-new">
+P
+</ins><sub><ins class="diff-new">
+i
+</ins></sub></var><ins class="diff-new">
+contains
+a
+subset
+of
+</ins>
+the
+<del class="diff-old">LDPC
+'s
+membership
+</del>
+triples
+<ins class="diff-new">in
+</ins><var><ins class="diff-new">
+P
+</ins></var>.<ins class="diff-new">
+LDP
+allows
+paging
+of
+resources
+other
+than
+</ins><a title="Linked Data Platform RDF Resource"><ins class="diff-new">
+LDP-RRs
+</ins></a>,<ins class="diff-new">
+but
+does
+not
+specify
+how
+clients
+combine
+their
+representations.
+See
+</ins><a href="#ldpr-Paging" class="sectionRef"></a><ins class="diff-new">
+for
+additional
+details.
+For
+readers
+familiar
+with
+paged
+feeds
+[[RFC5005]],
+a
+paged
+resource
+is
+similar
+to
+a
+logical
+feed.
+Any
+resource
+could
+be
+considered
+to
+be
+a
+paged
+resource
+consisting
+of
+</ins>
+exactly
+<del class="diff-old">equals
+the
+LDPC
+'s
+state.
+</del>
+<ins class="diff-chg">one
+page,
+although
+there
+is
+no
+known
+advantage
+in
+doing
+so.
+</ins>
+<p>
+</p>
+</dd>
+<dt>
+<del class="diff-old">Resource
+inlining
+</del>
+<dfn>
+<ins class="diff-chg">Single-page
+resource
+</ins>
+</dfn>
+</dt>
+<dd>
+<del class="diff-old">The
+practice
+</del>
+<ins class="diff-chg">One
+</ins>
+of
+<del class="diff-old">responding
+to
+</del>
+a
+<del class="diff-old">HTTP
+GET
+request
+made
+to
+a
+request
+URI
+</del>
+<ins class="diff-chg">sequence
+of
+related
+</ins><a title="Linked Data Platform RDF Resource"><ins class="diff-chg">
+LDP-RRs
+</ins></a>
+<var>
+<del class="diff-old">R
+</del>
+<ins class="diff-chg">P
+</ins>
+<sub>
+<del class="diff-old">0
+</del>
+<ins class="diff-chg">1
+</ins></sub>,<ins class="diff-chg">
+P
+</ins><sub><ins class="diff-chg">
+2
+</ins></sub>,<ins class="diff-chg">
+...,P
+</ins><sub><ins class="diff-chg">
+n
+</ins>
+</sub>
+</var>,
+<ins class="diff-new">each
+of
+which
+contains
+a
+subset
+of
+the
+state
+of
+another
+resource
+</ins><var><ins class="diff-new">
+P
+</ins></var>.<var><ins class="diff-new">
+P
+</ins>
+</var>
+<ins class="diff-new">is
+called
+the
+paged
+resource.
+For
+readers
+familiar
+</ins>
+with
+<ins class="diff-new">paged
+feeds
+[[RFC5005]],
+</ins>
+a
+<del class="diff-old">representation
+</del>
+<ins class="diff-chg">single-page
+resource
+is
+similar
+to
+a
+feed
+document
+and
+the
+same
+coherency/completeness
+considerations
+apply.
+</ins><a href="#ldpr-pagingGET-sequences-change"><ins class="diff-chg">
+LDP
+provides
+no
+guarantees
+</ins>
+that
+<del class="diff-old">includes
+</del>
+the
+<del class="diff-old">state
+</del>
+<ins class="diff-chg">sequence
+is
+stable
+</ins></a>.<p><ins class="diff-chg">
+Note:
+the
+choice
+</ins>
+of
+<del class="diff-old">R
+0
+,
+</del>
+<ins class="diff-chg">terms
+was
+designed
+to
+help
+authors
+and
+readers
+clearly
+differentiate
+between
+</ins>
+the
+<a title="Paged resource">
+<em>
+<del class="diff-old">entire
+</del>
+<ins class="diff-chg">resource
+being
+paged
+</ins>
+</em>
+<del class="diff-old">state
+of
+resources
+accessed
+through
+</del>
+</a>,
+<ins class="diff-chg">and
+the
+</ins><a title="Single-page resource">
+<em>
+<del class="diff-old">other
+</del>
+<ins class="diff-chg">individual
+page
+resources
+</ins>
+</em>
+<del class="diff-old">request
+URI(s)
+</del>
+</a>,
+<ins class="diff-chg">in
+cases
+where
+both
+are
+mentioned
+in
+close
+proximity.
+</ins></p><p></p></dd><dt><dfn><ins class="diff-chg">
+first
+page
+link
+</ins></dfn></dt><dd><ins class="diff-chg">
+A
+link
+to
+the
+first
+</ins><a title="Single-page resource"><ins class="diff-chg">
+single-page
+resource
+</ins></a><ins class="diff-chg">
+of
+a
+</ins><a title="Paged resource"><ins class="diff-chg">
+paged
+resource
+</ins></a>
+<var>
+<del class="diff-old">R
+</del>
+<ins class="diff-chg">P
+</ins></var>.<ins class="diff-chg">
+Syntactically,
+a
+HTTP
+</ins><code><ins class="diff-chg">
+Link
+<
+</ins><var><ins class="diff-chg">
+P
+</ins>
+<sub>
+1
+</sub>
+<del class="diff-old">...
+</del>
+</var>
+<ins class="diff-chg">>;
+rel='first'
+</ins></code><ins class="diff-chg">
+header
+[[!RFC5988]].
+</ins><p></p></dd><dt><dfn><ins class="diff-chg">
+next
+page
+link
+</ins></dfn></dt><dd><ins class="diff-chg">
+A
+link
+to
+the
+next
+</ins><a title="Single-page resource"><ins class="diff-chg">
+single-page
+resource
+</ins></a><ins class="diff-chg">
+of
+a
+</ins><a title="Paged resource"><ins class="diff-chg">
+paged
+resource
+</ins></a>
+<var>
+<del class="diff-old">R
+</del>
+<ins class="diff-chg">P
+</ins></var>.<ins class="diff-chg">
+Syntactically,
+a
+HTTP
+</ins><code><ins class="diff-chg">
+Link
+<
+</ins><var><ins class="diff-chg">
+P
+</ins>
+<sub>
+<del class="diff-old">n
+</del>
+<ins class="diff-chg">i
+</ins>
+</sub>
+<del class="diff-old">,
+and
+assertions
+from
+the
+server
+identifying
+</del>
+</var>
+<ins class="diff-chg">>;
+rel='next'
+</ins></code><ins class="diff-chg">
+header
+[[!RFC5988]]
+where
+</ins>
+the
+<del class="diff-old">additional
+resources
+whose
+entire
+state
+has
+been
+provided.
+</del>
+<ins class="diff-chg">target
+URI
+is
+</ins>
+<var>
+<del class="diff-old">R
+</del>
+<ins class="diff-chg">P
+</ins>
+<sub>
+<del class="diff-old">1
+</del>
+<ins class="diff-chg">i=2...n
+</ins>
+</sub>
+<del class="diff-old">...
+</del>
+</var>.
+<p>
+</p>
+</dd>
+<dt>
+<dfn>
+<ins class="diff-chg">last
+page
+link
+</ins></dfn></dt><dd><ins class="diff-chg">
+A
+link
+to
+the
+last
+</ins><a title="Single-page resource"><ins class="diff-chg">
+single-page
+resource
+</ins></a><ins class="diff-chg">
+of
+a
+</ins><a title="Paged resource"><ins class="diff-chg">
+paged
+resource
+</ins></a>
+<var>
+<del class="diff-old">R
+</del>
+<ins class="diff-chg">P
+</ins></var>.<ins class="diff-chg">
+Syntactically,
+a
+HTTP
+</ins><code><ins class="diff-chg">
+Link
+<
+</ins><var><ins class="diff-chg">
+P
+</ins>
+<sub>
+n
+</sub>
+</var>
+<del class="diff-old">identify
+the
+inlined
+resource(s).
+See
+section
+4.11
+for
+details.
+</del>
+<ins class="diff-chg">>;
+rel='last'
+</ins></code><ins class="diff-chg">
+header
+[[!RFC5988]].
+</ins>
+<p>
+</p>
+</dd>
+<dt>
+<del class="diff-old">Member
+inlining
+</del>
+<dfn>
+<ins class="diff-chg">previous
+page
+link
+</ins>
+</dfn>
+</dt>
+<dd>
+A
+<del class="diff-old">special
+case
+of
+</del>
+<ins class="diff-chg">link
+to
+the
+previous
+</ins><a title="Single-page resource"><ins class="diff-chg">
+single-page
+</ins>
+resource
+<del class="diff-old">inlining
+,
+where
+all
+members
+</del>
+</a>
+of
+a
+<del class="diff-old">container
+on
+</del>
+<a title="Paged resource">
+<ins class="diff-chg">paged
+resource
+</ins></a><var><ins class="diff-chg">
+P
+</ins></var>.<ins class="diff-chg">
+Syntactically,
+</ins>
+a
+<del class="diff-old">given
+page
+are
+inlined.
+The
+response
+page
+may
+or
+may
+not
+include
+all
+of
+</del>
+<ins class="diff-chg">HTTP
+</ins><code><ins class="diff-chg">
+Link
+<
+</ins><var><ins class="diff-chg">
+P
+</ins><sub><ins class="diff-chg">
+i
+</ins></sub></var><ins class="diff-chg">
+>;
+rel='prev'
+</ins></code><ins class="diff-chg">
+header
+[[!RFC5988]]
+where
+</ins>
+the
+<del class="diff-old">container's
+members.
+See
+section
+5.10
+for
+details.
+</del>
+<ins class="diff-chg">target
+URI
+is
+</ins><var><ins class="diff-chg">
+P
+</ins><sub><ins class="diff-chg">
+i=1...n-1
+</ins></sub></var>.
+<p>
+</p>
+</dd>
+</dl>
+<del class="diff-old">2.1
+</del>
+<section id="conventions">
+<h2>
+Conventions
+Used
+in
+This
+Document
+</h2>
+<p>
+Sample
+resource
+representations
+are
+provided
+in
+<code>
+text/turtle
+</code>
+format
+<del class="diff-old">[
+TURTLE
+].
+</del>
+<ins class="diff-chg">[[TURTLE]].
+</ins>
+</p>
+<p>
+Commonly
+used
+namespace
+prefixes:
+</p>
+<del class="diff-old"> @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#>.
+</del>
+<pre style="word-wrap: break-word; white-space: pre-wrap;">
+<ins class="diff-chg"> @prefix dcterms: <http://purl.org/dc/terms/>.
+ @prefix foaf: <http://xmlns.com/foaf/0.1/>.
+ @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
+ @prefix ldp: <http://www.w3.org/ns/ldp#>.
+ @prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
+</ins>
+</pre>
+</section>
+</section>
+<del class="diff-old">3.
+Conformance
+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.
+The
+key
+words
+MUST
+,
+MUST
+NOT
+,
+REQUIRED
+,
+SHOULD
+,
+SHOULD
+NOT
+,
+RECOMMENDED
+,
+MAY
+,
+and
+OPTIONAL
+in
+this
+specification
+are
+to
+be
+interpreted
+as
+described
+in
+[
+RFC2119
+].
+</del>
+<section id='conformance'>
+<p>
+The
+status
+of
+the
+sections
+of
+Linked
+Data
+Platform
+1.0
+(this
+document)
+is
+as
+follows:
+</p>
+<ul>
+<li>
+1.
+Introduction:
+<b>
+<del class="diff-old">informative
+</del>
+<ins class="diff-chg">non-normative
+</ins>
+</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>
+<del class="diff-old">informative
+</del>
+<ins class="diff-chg">non-normative
+</ins>
+</b>
+</li>
+<li>
+B.1
+Normative
+references:
+<b>
+normative
+</b>
+</li>
+<li>
+B.2
+<del class="diff-old">Informative
+</del>
+<ins class="diff-chg">Non-normative
+</ins>
+references:
+<b>
+<del class="diff-old">informative
+</del>
+<ins class="diff-chg">non-normative
+</ins>
+</b>
+</li>
+</ul>
+<p>
+A
+conforming
+<b>
+<dfn>
+LDP
+<del class="diff-old">server
+</del>
+<ins class="diff-chg">client
+</ins></dfn>
+</b>
+is
+<del class="diff-old">an
+application
+program
+that
+processes
+HTTP
+requests
+and
+generates
+</del>
+<ins class="diff-chg">a
+conforming
+</ins>
+HTTP
+<del class="diff-old">responses
+</del>
+<ins class="diff-chg">client
+[[!HTTP11]]
+</ins>
+that
+<del class="diff-old">conform
+to
+</del>
+<ins class="diff-chg">follows
+</ins>
+the
+rules
+defined
+<ins class="diff-new">by
+LDP
+</ins>
+in
+<del class="diff-old">section
+4.
+Linked
+Data
+Platform
+Resources
+and
+section
+5.
+Linked
+Data
+Platform
+Containers
+</del>
+<a href="#ldpclient" class="sectionRef">
+</a>.
+</p>
+<p>
+A
+conforming
+<b>
+<dfn>
+LDP
+<del class="diff-old">client
+</del>
+<ins class="diff-chg">server
+</ins></dfn>
+</b>
+is
+<del class="diff-old">an
+application
+program
+that
+generates
+HTTP
+requests
+and
+processes
+</del>
+<ins class="diff-chg">a
+conforming
+</ins>
+HTTP
+<del class="diff-old">responses
+</del>
+<ins class="diff-chg">server
+[[!HTTP11]]
+</ins>
+that
+<del class="diff-old">conform
+to
+</del>
+<ins class="diff-chg">follows
+</ins>
+the
+rules
+defined
+<ins class="diff-new">by
+LDP
+</ins>
+in
+<del class="diff-old">section
+4.
+Linked
+Data
+Platform
+Resources
+</del>
+<a href="#ldpr" class="sectionRef">
+</a>
+<ins class="diff-new">when
+it
+is
+serving
+LDPRs,
+</ins>
+and
+<del class="diff-old">section
+5.
+</del>
+<ins class="diff-chg">also
+</ins><a href="#ldpc" class="sectionRef"></a><ins class="diff-chg">
+when
+it
+is
+serving
+LDPCs.
+LDP
+does
+not
+constrain
+its
+behavior
+when
+serving
+other
+HTTP
+resources.
+</ins></p></section><section id="ldpclient"><h1>
+Linked
+Data
+Platform
+<del class="diff-old">Containers
+</del>
+<ins class="diff-chg">Clients
+</ins></h1><p><ins class="diff-chg">
+All
+of
+the
+following
+are
+conformance
+rules
+for
+</ins><a title="LDP server"><ins class="diff-chg">
+LDP
+Clients
+</ins>
+</a>.
+</p>
+<section>
+<h2>
+<ins class="diff-new">General
+</ins></h2><section id="ldp-cli-multitype"><h2 class="normal"><ins class="diff-new">
+In
+the
+absence
+of
+special
+knowledge
+of
+the
+application
+or
+domain,
+</ins><a title="LDP client"><ins class="diff-new">
+LDP
+clients
+</ins></a><ins class="diff-new">
+MUST
+assume
+that
+any
+LDP-RR
+can
+have
+multiple
+values
+for
+</ins><code><ins class="diff-new">
+rdf:type
+</ins></code>.</h2>
+</section>
+<section id="ldpr-cli-typeschange">
+<h2 class="normal">
+<ins class="diff-chg">In
+the
+absence
+of
+special
+knowledge
+of
+the
+application
+or
+domain,
+</ins><a title="LDP client"><ins class="diff-chg">
+LDP
+clients
+</ins></a><ins class="diff-chg">
+MUST
+assume
+that
+the
+</ins><code><ins class="diff-chg">
+rdf:type
+</ins></code><ins class="diff-chg">
+values
+of
+a
+given
+LDP-RR
+can
+change
+over
+time.
+</ins></h2></section><section id="ldpr-cli-openpreds"><h2 class="normal">
+<del class="diff-old">4.
+</del>
+<a title="LDP client">
+<ins class="diff-chg">LDP
+clients
+</ins></a><ins class="diff-chg">
+SHOULD
+always
+assume
+that
+the
+set
+of
+predicates
+for
+a
+LDP-RR
+of
+a
+particular
+type
+at
+an
+arbitrary
+server
+is
+open,
+in
+the
+sense
+that
+different
+resources
+of
+the
+same
+type
+may
+not
+all
+have
+the
+same
+set
+of
+predicates
+in
+their
+triples,
+and
+the
+set
+of
+predicates
+that
+are
+used
+in
+the
+state
+of
+any
+one
+LDP-RR
+is
+not
+limited
+to
+any
+pre-defined
+set.
+</ins></h2></section><section id="ldpr-cli-preservetriples"><h2 class="normal"><ins class="diff-chg">
+A
+</ins><a title="LDP client"><ins class="diff-chg">
+LDP
+client
+</ins></a><ins class="diff-chg">
+MUST
+preserve
+all
+triples
+retrieved
+from
+an
+LDP-RR
+using
+HTTP
+</ins><code><ins class="diff-chg">
+GET
+</ins></code><ins class="diff-chg">
+that
+it
+doesn’t
+change
+whether
+it
+understands
+the
+predicates
+or
+not,
+when
+its
+intent
+is
+to
+perform
+an
+update
+using
+HTTP
+</ins><code><ins class="diff-chg">
+PUT
+</ins></code>.<ins class="diff-chg">
+ The
+use
+of
+HTTP
+</ins><code><ins class="diff-chg">
+PATCH
+</ins></code><ins class="diff-chg">
+instead
+of
+HTTP
+</ins><code><ins class="diff-chg">
+PUT
+</ins></code><ins class="diff-chg">
+for
+update
+avoids
+this
+burden
+for
+clients
+[[RFC5789]].
+</ins></h2></section><section id="ldpr-cli-can-hint"><h2 class="normal"><a title="LDP client"><ins class="diff-chg">
+LDP
+clients
+</ins></a><ins class="diff-chg">
+MAY
+provide
+LDP-defined
+hints
+that
+allow
+servers
+to
+optimize
+the
+content
+of
+responses.
+</ins><a href="#prefer-parameters" class="sectionRef"></a><ins class="diff-chg">
+defines
+hints
+that
+apply
+to
+</ins><a title="Linked Data Platform RDF Resource"><ins class="diff-chg">
+LDP-RRs
+</ins></a>.</h2></section><section id="ldpr-cli-hints-ignorable"><h2 class="normal"><a title="LDP client"><ins class="diff-chg">
+LDP
+clients
+</ins></a><ins class="diff-chg">
+MUST
+be
+capable
+of
+processing
+responses
+formed
+by
+an
+LDP
+server
+that
+ignores
+hints,
+including
+LDP-defined
+hints.
+</ins></h2></section></section></section><section id="ldpr"><h1>
+Linked
+Data
+Platform
+Resources
+</h1>
+<section class="informative" id="ldpr-informative">
+<h2>
+<ins class="diff-new">Introduction
+</ins>
+</h2>
+<del class="diff-old">4.1
+Informative
+This
+section
+is
+non-normative.
+</del>
+<p>
+Linked
+Data
+Platform
+Resources
+(
+<dfn>
+<abbr title="Linked Data Platform Resources">
+LDPRs
+</abbr>
+</dfn>
+)
+are
+HTTP
+resources
+that
+conform
+to
+the
+simple
+patterns
+and
+conventions
+in
+this
+section.
+HTTP
+requests
+to
+access,
+modify,
+create
+or
+delete
+LDPRs
+are
+accepted
+and
+processed
+by
+<del class="diff-old">LDPR
+servers.
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+servers
+</ins></a>.
+Most
+LDPRs
+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
+<del class="diff-old">[
+LINKED-DATA
+];
+</del>
+<ins class="diff-chg">[[LINKED-DATA]];
+</ins>
+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
+<del class="diff-old">entries
+</del>
+<ins class="diff-chg">representation
+</ins>
+of
+a
+large
+<del class="diff-old">resources
+</del>
+<ins class="diff-chg">resource
+</ins>
+broken
+up
+into
+pages?
+</li>
+</ul>
+<p>
+Additional
+<del class="diff-old">informative
+</del>
+<ins class="diff-chg">non-normative
+</ins>
+guidance
+is
+available
+<del class="diff-old">on
+</del>
+<ins class="diff-chg">in
+</ins>
+the
+<del class="diff-old">working
+group's
+wiki
+</del>
+<a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html" class="external" title="LDP Best Practices and Guidelines" rel="nofollow">
+<ins class="diff-chg">LDP
+Best
+Practices
+and
+Guidelines
+editor's
+draft
+</ins>
+</a>
+that
+addresses
+<del class="diff-old">deployment
+</del>
+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
+<ins class="diff-new">conformance
+</ins>
+rules
+<del class="diff-old">and
+guidelines
+</del>
+for
+<del class="diff-old">use
+of
+LDPRs
+.
+</del>
+<ins class="diff-chg">LDP
+servers
+when
+serving
+LDPRs.
+</ins>
+This
+document
+also
+explains
+<a href="#ldpr-Paging">
+how
+<del class="diff-old">to
+include
+information
+about
+each
+member
+in
+the
+resource’s
+own
+representation
+and
+how
+to
+paginate
+the
+resource
+</del>
+<ins class="diff-chg">a
+server
+paginates
+an
+LDP-RR's
+</ins>
+representation
+</a>
+if
+it
+gets
+too
+big.
+<ins class="diff-new">Companion
+non-normative
+documents
+describe
+additional
+guidelines
+for
+use
+when
+interacting
+with
+LDPRs.
+</ins>
+</p>
+<p>
+<ins class="diff-chg">An
+LDP
+server
+manages
+two
+kinds
+of
+</ins><a title="Linked Data Platform Resources"><ins class="diff-chg">
+LDPRs
+</ins></a>,<ins class="diff-chg">
+those
+resources
+who
+whose
+state
+is
+represented
+using
+RDF
+(LDP-RR)
+and
+those
+using
+other
+formats
+(LDP-BR).
+LDP-RRs
+have
+the
+unique
+quality
+that
+their
+representation
+is
+based
+on
+RDF,
+which
+addresses
+a
+number
+of
+use
+cases
+from
+web
+metadata,
+open
+data
+models,
+machine
+processable
+information,
+and
+automated
+processing
+by
+software
+agents
+[[!RDF-CONCEPTS]].
+LDP-BRs
+are
+almost
+anything
+on
+the
+Web
+today:
+images,
+HTML
+pages,
+word
+processing
+documents,
+spreadsheets,
+etc.
+and
+LDP-RRs
+hold
+metadata
+associated
+with
+LDP-BRs
+in
+some
+cases.
+</ins></p><figure id="fig-ldpr-types">
+<del class="diff-old">4.2
+</del>
+<img src="images/ldpr1.png" alt="Sample separation of Linked Data Platform Resource" />
+<figcaption>
+<ins class="diff-chg">Samples
+of
+different
+types
+of
+LDPRs
+</ins></figcaption></figure><p><ins class="diff-chg">
+The
+LDP-BRs
+and
+LDP-RRs
+are
+simply
+sub-types
+of
+LDPRs,
+as
+illustrated
+in
+</ins><a href="#fig-ldpr-class"></a>.</p><figure id="fig-ldpr-class"><img src="images/ldpr2.png" alt="Class Diagram of Linked Data Platform Resource" /><figcaption><ins class="diff-chg">
+Class
+relationship
+of
+types
+of
+LDPRs
+</ins></figcaption></figure></section><section id="ldpr-general"><h2>
+General
+<del class="diff-old">4.2.1
+LDPR
+</del>
+</h2>
+<section id="ldpr-gen-http">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+MUST
+at
+least
+be
+HTTP/1.1
+conformant
+servers
+<del class="diff-old">[
+HTTP11
+</del>
+<ins class="diff-chg">[[!HTTP11]].
+</ins></h2></section><section id="ldpr-gen-rdf"><h2 class="normal">
+<del class="diff-old">].
+4.2.2
+LDPR
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+MUST
+provide
+an
+RDF
+representation
+for
+<del class="diff-old">LDPRs
+.
+</del>
+<a title="Linked Data Platform RDF Resource">
+<ins class="diff-chg">LDP-RRs
+</ins></a>.
+The
+HTTP
+<code>
+Request-URI
+</code>
+of
+the
+<del class="diff-old">LDPR
+</del>
+<ins class="diff-chg">LDP-RR
+</ins>
+is
+typically
+the
+subject
+of
+most
+triples
+in
+the
+response.
+<del class="diff-old">4.2.3
+LDPR
+</del>
+</h2>
+</section>
+<section id="ldpr-gen-binary">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+MAY
+host
+a
+mixture
+of
+<del class="diff-old">LDPRs
+</del>
+<ins class="diff-chg">LDPRs,
+</ins><a title="Linked Data Platform RDF Resource"><ins class="diff-chg">
+LDP-RRs
+</ins></a>
+and
+<del class="diff-old">non-
+LDPRs
+.
+</del>
+<a title="Linked Data Platform Binary Resource">
+<ins class="diff-chg">LDP-BRs
+</ins></a>.
+For
+example,
+it
+is
+common
+for
+<del class="diff-old">LDPR
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+to
+need
+to
+host
+binary
+or
+text
+resources
+that
+do
+not
+have
+useful
+RDF
+representations.
+<del class="diff-old">4.2.4
+LDPRs
+</del>
+</h2>
+</section>
+<section id="ldpr-gen-reusevocab">
+<h2 class="normal">
+<a title="Linked Data Platform RDF Resource">
+<ins class="diff-chg">LDP-RRs
+</ins></a>
+SHOULD
+reuse
+existing
+vocabularies
+instead
+of
+creating
+their
+own
+duplicate
+vocabulary
+terms.
+In
+addition
+to
+this
+general
+rule,
+some
+specific
+cases
+are
+covered
+by
+other
+conformance
+rules.
+<del class="diff-old">4.2.4.1
+LDPR
+</del>
+</h2>
+</section>
+<section id="ldpr-gen-reusevocabsuchas">
+<h2 class="normal">
+<a title="Linked Data Platform RDF Resource">
+<ins class="diff-chg">LDP-RRs
+</ins></a>
+predicates
+SHOULD
+use
+standard
+vocabularies
+such
+as
+Dublin
+Core
+<del class="diff-old">[
+DC-TERMS
+],
+</del>
+<ins class="diff-chg">[[!DC-TERMS]],
+</ins>
+RDF
+<del class="diff-old">[
+RDF-CONCEPTS
+]
+</del>
+<ins class="diff-chg">[[!RDF-CONCEPTS]]
+</ins>
+and
+RDF
+Schema
+<del class="diff-old">[
+RDF-SCHEMA
+],
+</del>
+<ins class="diff-chg">[[!RDF-SCHEMA]],
+</ins>
+whenever
+possible.
+<del class="diff-old">4.2.5
+LDPR
+</del>
+</h2>
+</section>
+<section id="ldpr-gen-atleast1rdftype">
+<h2 class="normal">
+<a title="Linked Data Platform RDF Resource">
+<ins class="diff-chg">LDP-RRs
+</ins></a>
+representations
+SHOULD
+have
+at
+least
+one
+<code>
+rdf:type
+</code>
+set
+explicitly.
+<del class="diff-old"> This
+</del>
+<ins class="diff-chg"> This
+</ins>
+makes
+the
+representations
+much
+more
+useful
+to
+client
+applications
+that
+don’t
+support
+inferencing.
+<del class="diff-old">4.2.6
+LDPR
+servers
+MAY
+support
+standard
+representations
+beyond
+those
+necessary
+to
+conform
+to
+this
+specification.
+These
+could
+be
+other
+RDF
+formats,
+like
+N3
+or
+NTriples,
+but
+non-
+RDF
+formats
+like
+HTML
+[
+HTML401
+]
+and
+JSON
+[
+RFC4627
+]
+would
+likely
+be
+common.
+4.2.7
+LDPRs
+MAY
+be
+created,
+updated
+and
+deleted
+using
+methods
+not
+defined
+in
+this
+document,
+for
+example
+through
+application-specific
+means,
+SPARQL
+UPDATE,
+etc.
+[
+SPARQL-UPDATE
+</del>
+</h2>
+</section>
+<section id="ldpr-gen-etags">
+<h2 class="normal">
+<del class="diff-old">],
+as
+long
+as
+those
+methods
+do
+not
+conflict
+with
+this
+specification's
+normative
+requirements.
+4.2.8
+LDPR
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+server
+</a>
+responses
+MUST
+use
+entity
+tags
+(either
+weak
+or
+strong
+ones)
+as
+response
+<code>
+ETag
+</code>
+header
+values.
+<del class="diff-old">4.2.9
+LDPR
+</del>
+</h2>
+</section>
+<section id="ldpr-gen-linktypehdr">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+<del class="diff-old">SHOULD
+enable
+simple
+creation
+and
+modification
+of
+</del>
+</a>
+<ins class="diff-chg">exposing
+</ins>
+LDPRs
+<del class="diff-old">.
+It
+is
+common
+for
+LDPR
+servers
+to
+put
+restrictions
+on
+representations
+–
+for
+example,
+the
+range
+of
+rdf:type
+predicates,
+datatypes
+of
+the
+objects
+of
+predicates,
+and
+the
+number
+of
+occurrences
+of
+predicates
+in
+an
+LDPR
+,
+but
+servers
+SHOULD
+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.
+4.2.10
+LDPR
+servers
+</del>
+MUST
+advertise
+their
+LDP
+support
+by
+exposing
+a
+HTTP
+<code>
+Link
+</code>
+header
+with
+a
+target
+URI
+of
+<code>
+<del class="diff-old">http://www.w3.org/ns/ldp/Resource
+</del>
+<ins class="diff-chg">http://www.w3.org/ns/ldp#Resource
+</ins>
+</code>,
+and
+a
+link
+relation
+type
+of
+<code>
+type
+</code>
+(that
+is,
+<code>
+<del class="diff-old">rel="type"
+</del>
+<ins class="diff-chg">rel='type'
+</ins>
+</code>
+)
+in
+all
+responses
+to
+requests
+made
+to
+the
+<del class="diff-old">resource's
+</del>
+<ins class="diff-chg">LDPR's
+</ins>
+HTTP
+<code>
+Request-URI
+</code>.
+<del class="diff-old">This
+is
+notionally
+equivalent
+to
+the
+presence
+of
+a
+(subject-URI,
+rdf:type
+,
+ldp:Resource
+)
+triple
+in
+the
+resource.
+</del>
+</h2>
+</section>
+<blockquote>
+<p>
+<ins class="diff-chg">Note:
+</ins>
+The
+HTTP
+<code>
+Link
+</code>
+header
+is
+the
+method
+by
+which
+servers
+assert
+their
+support
+for
+the
+LDP
+specification
+<ins class="diff-new">on
+a
+specific
+resource
+</ins>
+in
+a
+way
+that
+clients
+can
+<del class="diff-old">introspect
+</del>
+<ins class="diff-chg">inspect
+</ins>
+dynamically
+at
+run-time.
+<del class="diff-old">Conservative
+clients
+should
+note
+that
+</del>
+<ins class="diff-chg">This
+is
+</ins><strong><ins class="diff-chg">
+not
+</ins></strong><ins class="diff-chg">
+equivalent
+to
+the
+presence
+of
+</ins>
+a
+<var>
+<ins class="diff-new">(subject-URI,
+</ins><code><ins class="diff-new">
+rdf:type
+</ins></code>,<code><ins class="diff-new">
+ldp:Resource
+</ins></code><ins class="diff-new">
+)
+</ins></var><ins class="diff-new">
+triple
+in
+an
+RDF
+resource.
+The
+presence
+of
+this
+header
+asserts
+that
+the
+server
+complies
+with
+the
+LDP
+specification's
+constraints
+on
+HTTP
+interactions
+with
+LDPRs,
+that
+is
+it
+asserts
+that
+the
+resource
+</ins><a href="#ldpr-gen-tags"><ins class="diff-new">
+has
+Etags
+</ins></a>,<a href="#ldpr-gen-rdf"><ins class="diff-new">
+has
+an
+RDF
+representation
+</ins></a>,<ins class="diff-new">
+and
+so
+on,
+which
+is
+not
+true
+of
+all
+Web
+resources
+served
+as
+RDF
+media
+types.
+</ins></p><p><ins class="diff-new">
+Note:
+</ins><a href="#ldpr-gen-binary"><ins class="diff-new">
+A
+LDP
+</ins>
+server
+can
+host
+a
+mixture
+of
+LDPRs
+and
+other
+resources
+</a>,
+and
+therefore
+there
+is
+no
+implication
+that
+LDP
+support
+advertised
+on
+one
+HTTP
+<code>
+Request-URI
+</code>
+means
+that
+other
+resources
+on
+the
+same
+server
+are
+also
+<del class="diff-old">LDPRs
+.
+</del>
+<ins class="diff-chg">LDPRs.
+</ins>
+Each
+HTTP
+<code>
+Request-URI
+</code>
+needs
+to
+be
+individually
+<del class="diff-old">introspected
+by
+a
+conservative
+client,
+</del>
+<ins class="diff-chg">inspected,
+</ins>
+in
+the
+absence
+of
+outside
+information.
+<del class="diff-old">4.2.11
+LDPR
+</del>
+</p>
+</blockquote>
+<section id="ldpr-gen-noinferencing">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+MUST
+NOT
+require
+LDP
+clients
+to
+implement
+inferencing
+in
+order
+to
+recognize
+the
+subset
+of
+content
+defined
+by
+LDP.
+Other
+specifications
+built
+on
+top
+of
+LDP
+may
+require
+clients
+to
+implement
+inferencing
+<del class="diff-old">[
+RDF-CONCEPTS
+].
+</del>
+<ins class="diff-chg">[[!RDF-CONCEPTS]].
+</ins>
+The
+practical
+implication
+is
+that
+all
+content
+defined
+by
+LDP
+must
+be
+explicitly
+represented.
+<del class="diff-old">4.2.12
+LDPR
+</del>
+</h2>
+</section>
+<section id="ldpr-gen-defbaseuri">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+MUST
+assign
+the
+default
+base-URI
+for
+<del class="diff-old">[
+RFC3987
+]
+</del>
+<ins class="diff-chg">[[!RFC3987]]
+</ins>
+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.
+</h2>
+</section>
+<section id="ldpr-gen-pubclireqs">
+<h2 class="normal">
+<del class="diff-old">4.3
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+servers
+</ins></a><ins class="diff-chg">
+MUST
+publish
+any
+constraints
+on
+</ins><a title="LDP client"><ins class="diff-chg">
+LDP
+clients’
+</ins></a><ins class="diff-chg">
+ability
+to
+create
+or
+update
+LDPRs,
+by
+adding
+a
+Link
+header
+with
+</ins><code><ins class="diff-chg">
+rel='describedby'
+</ins></code><ins class="diff-chg">
+[[!POWDER-DR]]
+to
+all
+responses
+to
+requests
+which
+fail
+due
+to
+violation
+of
+those
+constraints.
+For
+example,
+a
+server
+that
+refuses
+resource
+creation
+requests
+via
+HTTP
+PUT,
+POST,
+or
+PATCH
+would
+return
+this
+</ins><code><ins class="diff-chg">
+Link
+</ins></code><ins class="diff-chg">
+header
+on
+its
+4xx
+responses
+to
+such
+requests.
+The
+same
+</ins><code><ins class="diff-chg">
+Link
+</ins></code><ins class="diff-chg">
+header
+MAY
+be
+provided
+on
+other
+responses.
+LDP
+neither
+defines
+nor
+constrains
+the
+representation
+of
+the
+link's
+target
+resource;
+as
+stated
+in
+[[POWDER-DR]],
+the
+target
+might
+(or
+might
+not)
+be
+a
+POWDER
+document.
+Natural
+language
+constraint
+documents
+are
+therefore
+permitted,
+although
+machine-readable
+ones
+facilitate
+better
+client
+interactions.
+</ins></h2></section><section id="ldpr-page-large"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a><ins class="diff-chg">
+SHOULD
+allow
+clients
+to
+retrieve
+large
+LDP-RRs
+in
+pages.
+See
+</ins><a href="#ldpr-Paging" class="sectionRef"></a><ins class="diff-chg">
+for
+additional
+requirements
+associated
+with
+</ins><a title="Paged resource"><ins class="diff-chg">
+paged
+resources
+</ins></a>.</h2></section><section id="ldpr-split-any"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a><ins class="diff-chg">
+MAY
+treat
+any
+resource
+(LDP-RR
+or
+not)
+as
+a
+</ins><a title="Paged resource"><ins class="diff-chg">
+paged
+resource
+</ins></a>.<ins class="diff-chg">
+See
+</ins><a href="#ldpr-Paging" class="sectionRef"></a><ins class="diff-chg">
+for
+additional
+details.
+</ins></h2></section></section><section id="ldpr-HTTP_GET"><h2>
+HTTP
+GET
+<del class="diff-old">4.3.1
+LDPR
+</del>
+</h2>
+<section id="ldpr-get-must">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+MUST
+support
+the
+HTTP
+<code>
+GET
+</code>
+Method
+for
+<del class="diff-old">LDPRs
+.
+4.3.2
+LDPR
+</del>
+<ins class="diff-chg">LDPRs.
+</ins></h2></section><section id="ldpr-get-options"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
+LDP
+</ins>
+servers
+</a>
+MUST
+support
+the
+HTTP
+response
+headers
+defined
+in
+<a href="#ldpr-HTTP_OPTIONS" class="sectionRef">
+<del class="diff-old">section
+4.9
+</del>
+</a>.
+<del class="diff-old">4.3.3
+LDPR
+</del>
+</h2>
+</section>
+<section id="ldpr-get-turtle">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+<del class="diff-old">SHOULD
+</del>
+</a>
+<ins class="diff-chg">MUST
+</ins>
+provide
+a
+<code>
+text/turtle
+</code>
+representation
+of
+the
+requested
+<del class="diff-old">LDPR
+[
+TURTLE
+].
+4.3.4
+LDPR
+servers
+MAY
+provide
+representations
+of
+the
+requested
+LDPR
+beyond
+those
+necessary
+to
+conform
+to
+this
+specification,
+using
+standard
+HTTP
+content
+negotiation
+([
+HTTP11
+</del>
+<a title="Linked Data Platform RDF Resource">
+<ins class="diff-chg">LDP-RR
+</ins>
+</a>
+<del class="diff-old">]
+Section
+12
+-
+Content
+Negotiation).
+If
+the
+client
+does
+not
+indicate
+a
+preference,
+text/turtle
+SHOULD
+be
+returned.
+4.3.5
+In
+the
+absence
+of
+special
+knowledge
+of
+the
+application
+or
+domain,
+LDPR
+clients
+MUST
+assume
+that
+any
+LDPR
+can
+have
+multiple
+values
+for
+rdf:type
+.
+4.3.6
+In
+the
+absence
+of
+special
+knowledge
+of
+the
+application
+or
+domain,
+LDPR
+clients
+MUST
+assume
+that
+the
+rdf:type
+values
+of
+a
+given
+LDPR
+can
+change
+over
+time.
+</del>
+<ins class="diff-chg">[[!TURTLE]].
+</ins></h2>
+</section>
+<del class="diff-old">4.4
+</del>
+</section>
+<section id="ldpr-HTTP_POST">
+<h2>
+HTTP
+POST
+</h2>
+<p>
+This
+specification
+adds
+no
+new
+requirements
+on
+HTTP
+<code>
+POST
+</code>
+for
+LDPRs
+even
+when
+the
+LDPR
+supports
+that
+method.
+This
+specification
+does
+not
+impose
+any
+new
+requirement
+to
+support
+that
+method,
+and
+<del class="diff-old">[
+HTTP11
+]
+</del>
+<ins class="diff-chg">[[!HTTP11]]
+</ins>
+makes
+it
+optional.
+</p>
+<p>
+<del class="diff-old">Creation
+of
+LDPRs
+</del>
+<ins class="diff-chg">Clients
+</ins>
+can
+<del class="diff-old">be
+done
+</del>
+<ins class="diff-chg">create
+LDPRs
+</ins>
+via
+<code>
+POST
+</code>
+(
+<a href="#ldpc-HTTP_POST" class="sectionRef">
+<del class="diff-old">section
+5.4
+</del>
+</a>
+)
+or
+<code>
+PUT
+</code>
+(
+<a href="#ldpc-HTTP_PUT" class="sectionRef">
+<del class="diff-old">section
+5.5
+</del>
+</a>
+)
+to
+a
+<del class="diff-old">LDPC
+,
+</del>
+<ins class="diff-chg">LDPC,
+</ins>
+see
+those
+sections
+for
+more
+details.
+<ins class="diff-new">Any
+server-imposed
+constraints
+on
+LDPR
+creation
+or
+update
+</ins><a href="#ldpr-gen-pubclireqs"><ins class="diff-new">
+must
+be
+advertised
+</ins></a><ins class="diff-new">
+to
+clients.
+</ins>
+</p>
+</section>
+<del class="diff-old">4.5
+</del>
+<section id="ldpr-HTTP_PUT">
+<h2>
+HTTP
+PUT
+</h2>
+<p>
+<del class="diff-old">This
+</del>
+<ins class="diff-chg">Per
+[HTTP11],
+this
+HTTP
+method
+is
+optional
+and
+this
+specification
+does
+not
+require
+</ins><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a><ins class="diff-chg">
+to
+support
+it.
+When
+a
+LDP
+server
+chooses
+to
+support
+this
+method,
+this
+</ins>
+specification
+imposes
+the
+following
+new
+requirements
+<del class="diff-old">on
+HTTP
+PUT
+</del>
+for
+<del class="diff-old">LDPRs
+only
+when
+the
+</del>
+<ins class="diff-chg">LDPRs.
+</ins></p><p><ins class="diff-chg">
+Any
+server-imposed
+constraints
+on
+</ins>
+LDPR
+<del class="diff-old">supports
+that
+method.
+This
+specification
+does
+not
+impose
+any
+new
+requirement
+to
+support
+that
+method,
+and
+[
+HTTP11
+</del>
+<ins class="diff-chg">creation
+or
+update
+</ins><a href="#ldpr-gen-pubclireqs"><ins class="diff-chg">
+must
+be
+advertised
+</ins>
+</a>
+<del class="diff-old">]
+makes
+it
+optional.
+</del>
+<ins class="diff-chg">to
+clients.
+</ins>
+</p>
+<del class="diff-old">4.5.1
+</del>
+<section id="ldpr-put-replaceall">
+<h2 class="normal">
+If
+<ins class="diff-new">a
+</ins>
+HTTP
+<code>
+PUT
+</code>
+is
+<del class="diff-old">performed
+</del>
+<ins class="diff-chg">accepted
+</ins>
+on
+an
+existing
+resource,
+<del class="diff-old">LDPR
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+MUST
+replace
+the
+entire
+persistent
+state
+of
+the
+identified
+resource
+with
+the
+entity
+representation
+in
+the
+body
+of
+the
+request.
+<del class="diff-old">LDPR
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+MAY
+ignore
+server
+managed
+properties
+such
+as
+<code>
+dcterms:modified
+</code>
+and
+<code>
+dcterms:creator
+</code>
+if
+they
+are
+not
+under
+client
+control.
+Any
+<del class="diff-old">LDPR
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+that
+wish
+to
+support
+a
+more
+sophisticated
+merge
+of
+data
+provided
+by
+the
+client
+with
+existing
+state
+stored
+on
+the
+server
+for
+a
+resource
+MUST
+use
+HTTP
+<code>
+PATCH
+</code>,
+not
+HTTP
+<code>
+PUT
+</code>.
+<del class="diff-old">4.5.2
+LDPR
+</del>
+</h2>
+</section>
+<section id="ldpr-put-servermanagedprops">
+<h2 class="normal">
+<ins class="diff-chg">If
+an
+otherwise
+valid
+HTTP
+</ins><code><ins class="diff-chg">
+PUT
+</ins></code><ins class="diff-chg">
+request
+is
+received
+that
+attempts
+to
+change
+triples
+the
+server
+does
+not
+allow
+</ins>
+clients
+<ins class="diff-chg">to
+modify,
+</ins><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a><ins class="diff-chg">
+MUST
+respond
+with
+a
+4xx
+range
+status
+code
+(typically
+409
+Conflict).
+</ins><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a><ins class="diff-chg">
+SHOULD
+provide
+a
+corresponding
+response
+body
+containing
+information
+about
+which
+triples
+could
+not
+be
+persisted.
+The
+format
+of
+the
+4xx
+response
+body
+is
+not
+constrained
+by
+LDP.
+</ins></h2></section><blockquote><ins class="diff-chg">
+Non-normative
+note:
+Clients
+might
+provide
+triples
+equivalent
+to
+those
+already
+in
+the
+resource's
+state,
+e.g.
+as
+part
+of
+a
+GET/update
+representation/PUT
+sequence,
+and
+those
+PUT
+requests
+are
+intended
+to
+work
+as
+long
+as
+the
+server-controlled
+triples
+are
+identical
+on
+the
+GET
+response
+and
+the
+subsequent
+PUT
+request.
+</ins></blockquote><section id="ldpr-put-precond"><h2 class="normal"><a title="LDP client"><ins class="diff-chg">
+LDP
+clients
+</ins></a>
+SHOULD
+use
+the
+HTTP
+<code>
+If-Match
+</code>
+header
+and
+HTTP
+<code>
+ETags
+</code>
+to
+ensure
+it
+isn’t
+modifying
+a
+resource
+that
+has
+changed
+since
+the
+client
+last
+retrieved
+its
+representation.
+<del class="diff-old">LDPR
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+SHOULD
+require
+the
+HTTP
+<code>
+If-Match
+</code>
+header
+and
+HTTP
+<code>
+ETags
+</code>
+to
+detect
+collisions.
+<del class="diff-old">LDPR
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+MUST
+respond
+with
+status
+code
+412
+(Condition
+Failed)
+if
+<code>
+ETag
+</code>
+s
+fail
+to
+match
+when
+there
+are
+no
+other
+errors
+with
+the
+request
+<del class="diff-old">[
+HTTP11
+].
+LDPR
+</del>
+<ins class="diff-chg">[[!HTTP11]].
+</ins><a title="LDP server"><ins class="diff-chg">
+LDP
+</ins>
+servers
+</a>
+that
+require
+conditional
+requests
+MUST
+respond
+with
+status
+code
+428
+(Precondition
+Required)
+when
+the
+absence
+of
+a
+precondition
+is
+the
+only
+reason
+for
+rejecting
+the
+request
+<del class="diff-old">[
+RFC6585
+].
+4.5.3
+LDPR
+clients
+SHOULD
+always
+assume
+that
+the
+set
+of
+predicates
+for
+a
+resource
+of
+a
+particular
+type
+at
+</del>
+<ins class="diff-chg">[[!RFC6585]].
+</ins></h2></section><section id="ldpr-put-failed"><h2 class="normal"><ins class="diff-chg">
+If
+</ins>
+an
+<del class="diff-old">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
+</del>
+<ins class="diff-chg">otherwise
+valid
+HTTP
+</ins><code><ins class="diff-chg">
+PUT
+</ins></code><ins class="diff-chg">
+request
+</ins>
+is
+<del class="diff-old">not
+limited
+to
+any
+pre-defined
+set.
+4.5.4
+LDPR
+clients
+SHOULD
+assume
+</del>
+<ins class="diff-chg">received
+</ins>
+that
+<del class="diff-old">an
+LDPR
+server
+could
+discard
+</del>
+<ins class="diff-chg">contains
+</ins>
+triples
+<del class="diff-old">whose
+predicates
+</del>
+the
+server
+<del class="diff-old">does
+not
+recognize
+or
+otherwise
+</del>
+chooses
+not
+to
+<del class="diff-old">persist.
+In
+other
+words,
+LDPR
+</del>
+<ins class="diff-chg">persist,
+e.g.
+unknown
+content,
+</ins><a title="LDP server"><ins class="diff-chg">
+LDP
+</ins>
+servers
+<del class="diff-old">MAY
+restrict
+themselves
+to
+a
+known
+set
+of
+predicates,
+but
+LDPR
+clients
+</del>
+</a>
+MUST
+<del class="diff-old">NOT
+restrict
+themselves
+to
+a
+known
+set
+of
+predicates
+when
+their
+intent
+is
+to
+perform
+</del>
+<ins class="diff-chg">respond
+with
+an
+appropriate
+4xx
+range
+status
+code
+[[HTTP11]].
+</ins><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a><ins class="diff-chg">
+SHOULD
+provide
+</ins>
+a
+<del class="diff-old">later
+HTTP
+PUT
+to
+update
+the
+resource.
+4.5.5
+An
+LDPR
+client
+MUST
+preserve
+all
+</del>
+<ins class="diff-chg">corresponding
+response
+body
+containing
+information
+about
+which
+</ins>
+triples
+<del class="diff-old">retrieved
+using
+HTTP
+GET
+that
+it
+doesn’t
+change
+whether
+it
+understands
+</del>
+<ins class="diff-chg">could
+not
+be
+persisted.
+The
+format
+of
+</ins>
+the
+<del class="diff-old">predicates
+or
+not,
+when
+its
+intent
+</del>
+<ins class="diff-chg">4xx
+response
+body
+</ins>
+is
+<del class="diff-old">to
+perform
+an
+update
+using
+HTTP
+PUT
+.
+ The
+use
+of
+HTTP
+PATCH
+instead
+of
+HTTP
+PUT
+for
+update
+avoids
+this
+burden
+for
+clients
+[
+RFC5789
+</del>
+<ins class="diff-chg">not
+constrained
+by
+LDP.
+</ins></h2></section><section id="ldpr-put-create"><h2 class="normal">
+<del class="diff-old">].
+4.5.6
+LDPR
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+MAY
+choose
+to
+allow
+the
+creation
+of
+new
+resources
+using
+HTTP
+<code>
+PUT
+</code>.
+<del class="diff-old">4.5.7
+LDPR
+</del>
+</h2>
+</section>
+<section id="ldpr-put-simpleupdate">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+SHOULD
+allow
+clients
+to
+update
+resources
+without
+requiring
+detailed
+knowledge
+of
+server-specific
+constraints.
+<del class="diff-old">
+</del>
+<ins class="diff-chg"> 
+</ins>
+This
+is
+a
+consequence
+of
+the
+requirement
+to
+enable
+simple
+creation
+and
+modification
+of
+<del class="diff-old">LPDRs.
+</del>
+<ins class="diff-chg">LDPRs.
+</ins></h2>
+</section>
+<del class="diff-old">4.6
+</del>
+</section>
+<section id="ldpr-HTTP_DELETE">
+<h2>
+HTTP
+DELETE
+</h2>
+<p>
+<del class="diff-old">This
+specification
+imposes
+the
+following
+new
+requirements
+on
+</del>
+<ins class="diff-chg">Per
+[HTTP11],
+this
+</ins>
+HTTP
+<del class="diff-old">DELETE
+for
+LDPRs
+only
+when
+the
+LDPR
+supports
+that
+method.
+This
+</del>
+<ins class="diff-chg">method
+is
+optional
+and
+this
+</ins>
+specification
+does
+not
+<del class="diff-old">impose
+any
+new
+requirement
+</del>
+<ins class="diff-chg">require
+</ins><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a>
+to
+support
+<del class="diff-old">that
+</del>
+<ins class="diff-chg">it.
+When
+a
+LDP
+server
+chooses
+to
+support
+this
+</ins>
+method,
+<del class="diff-old">and
+[
+HTTP11
+]
+makes
+it
+optional.
+</del>
+<ins class="diff-chg">this
+specification
+imposes
+the
+following
+new
+requirements
+for
+LDPRs.
+</ins>
+</p>
+<p>
+Additional
+requirements
+on
+HTTP
+<code>
+DELETE
+</code>
+of
+LDPRs
+within
+containers
+can
+be
+found
+in
+<a href="#ldpc-HTTP_DELETE" class="sectionRef">
+<del class="diff-old">section
+5.6
+</del>
+</a>.
+</p>
+<del class="diff-old">4.6.1
+LDPR
+servers
+MUST
+remove
+the
+resource
+identified
+by
+the
+Request-URI
+.
+After
+a
+successful
+HTTP
+DELETE
+,
+a
+subsequent
+HTTP
+GET
+on
+the
+same
+Request-URI
+MUST
+result
+in
+a
+404
+(Not
+found)
+or
+410
+(Gone)
+status
+code.
+Clients
+SHOULD
+note
+that
+servers
+MAY
+reuse
+a
+URI
+under
+some
+circumstances.
+4.6.2
+LDPR
+servers
+MAY
+alter
+the
+state
+of
+other
+resources
+as
+a
+result
+of
+an
+HTTP
+DELETE
+request.
+For
+example,
+it
+is
+acceptable
+for
+the
+server
+to
+remove
+triples
+from
+other
+resources
+whose
+subject
+or
+object
+is
+the
+deleted
+resource.
+It
+is
+also
+acceptable
+and
+common
+for
+LDPR
+servers
+to
+not
+do
+this
+–
+behavior
+is
+server
+application
+specific.
+</del>
+</section>
+<del class="diff-old">4.7
+</del>
+<section id="ldpr-HTTP_HEAD">
+<h2>
+HTTP
+HEAD
+</h2>
+<p>
+Note
+that
+certain
+LDP
+mechanisms,
+such
+as
+<del class="diff-old">paging,
+</del>
+<a href="#ldpr-Paging">
+<ins class="diff-chg">paging
+</ins></a>,
+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
+<del class="diff-old">section
+4.3
+</del>
+<ins class="diff-chg">sections
+</ins><a href="#ldpr-HTTP_GET">
+</a>
+and
+<del class="diff-old">section
+4.9
+</del>
+<a href="#ldpr-HTTP_OPTIONS">
+</a>.
+</p>
+<del class="diff-old">4.7.1
+LDPR
+</del>
+<section id="ldpr-head-must">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+MUST
+support
+the
+HTTP
+<code>
+HEAD
+</code>
+method.
+</h2>
+</section>
+<del class="diff-old">4.8
+</del>
+</section>
+<section id="ldpr-HTTP_PATCH">
+<h2>
+HTTP
+PATCH
+</h2>
+<p>
+<del class="diff-old">This
+specification
+imposes
+the
+following
+new
+requirements
+on
+</del>
+<ins class="diff-chg">Per
+[HTTP11],
+this
+</ins>
+HTTP
+<del class="diff-old">PATCH
+for
+LDPRs
+only
+when
+the
+LDPR
+supports
+that
+method.
+This
+</del>
+<ins class="diff-chg">method
+is
+optional
+and
+this
+</ins>
+specification
+does
+not
+<del class="diff-old">impose
+any
+new
+requirement
+</del>
+<ins class="diff-chg">require
+</ins><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a>
+to
+support
+<del class="diff-old">that
+</del>
+<ins class="diff-chg">it.
+When
+a
+LDP
+server
+chooses
+to
+support
+this
+</ins>
+method,
+<del class="diff-old">and
+[
+HTTP11
+]
+makes
+it
+optional.
+</del>
+<ins class="diff-chg">this
+specification
+imposes
+the
+following
+new
+requirements
+for
+LDPRs.
+</ins>
+</p>
+<del class="diff-old">4.8.1
+</del>
+<p>
+<ins class="diff-chg">Any
+server-imposed
+constraints
+on
+</ins>
+LDPR
+<del class="diff-old">servers
+MAY
+implement
+HTTP
+PATCH
+to
+allow
+modifications,
+especially
+partial
+replacement,
+of
+their
+resources
+[
+RFC5789
+</del>
+<ins class="diff-chg">creation
+or
+update
+</ins><a href="#ldpr-gen-pubclireqs"><ins class="diff-chg">
+must
+be
+advertised
+</ins>
+</a>
+<ins class="diff-new">to
+clients.
+</ins></p><section id="ldpr-patch-create"><h2 class="normal">
+<del class="diff-old">].
+No
+minimal
+set
+of
+patch
+document
+formats
+is
+mandated
+by
+this
+document.
+4.8.2
+LDPR
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+<del class="diff-old">SHOULD
+allow
+clients
+to
+update
+resources
+without
+requiring
+detailed
+knowledge
+of
+server-specific
+constraints.
+
+This
+is
+a
+consequence
+of
+the
+requirement
+to
+enable
+simple
+creation
+and
+modification
+</del>
+</a>
+<del class="diff-old">of
+LPDRs.
+4.8.3
+LDPR
+servers
+</del>
+SHOULD
+NOT
+allow
+clients
+to
+create
+new
+resources
+using
+<code>
+PATCH
+</code>.
+<a href="#ldpc-HTTP_POST">
+<code>
+POST
+</code>
+(to
+an
+<del class="diff-old">LDPC
+)
+</del>
+<ins class="diff-chg">LDPC)
+</ins>
+</a>
+and/or
+<a href="#ldpr-HTTP_PUT">
+<code>
+PUT
+</code>
+</a>
+should
+be
+used
+as
+the
+standard
+way
+to
+create
+new
+<del class="diff-old">LDPRs
+.
+4.8.4
+LDPR
+</del>
+<ins class="diff-chg">LDPRs.
+</ins></h2></section><section id="ldpr-patch-acceptpatch"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
+LDP
+</ins>
+servers
+</a>
+that
+support
+<code>
+PATCH
+</code>
+MUST
+include
+an
+<code>
+Accept-Patch
+</code>
+HTTP
+response
+header
+<del class="diff-old">[
+RFC5789
+]
+</del>
+<ins class="diff-chg">[[!RFC5789]]
+</ins>
+on
+HTTP
+<code>
+OPTIONS
+</code>
+requests,
+listing
+patch
+document
+media
+type(s)
+supported
+by
+the
+server.
+</h2>
+</section>
+<del class="diff-old">4.9
+</del>
+</section>
+<section id="ldpr-HTTP_OPTIONS">
+<h2>
+HTTP
+OPTIONS
+</h2>
+<p>
+This
+specification
+imposes
+the
+following
+new
+requirements
+on
+HTTP
+<code>
+OPTIONS
+</code>
+for
+LDPRs
+beyond
+those
+in
+<del class="diff-old">[
+HTTP11
+].
+</del>
+<ins class="diff-chg">[[!HTTP11]].
+</ins>
+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>
+<del class="diff-old">4.9.1
+LDPR
+</del>
+<section id="ldpr-options-must">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+MUST
+support
+the
+HTTP
+<code>
+OPTIONS
+</code>
+method.
+<del class="diff-old">4.9.2
+LDPR
+</del>
+</h2>
+</section>
+<section id="ldpr-options-allow">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+MUST
+indicate
+their
+support
+for
+HTTP
+Methods
+by
+responding
+to
+a
+HTTP
+<code>
+OPTIONS
+</code>
+request
+on
+the
+<del class="diff-old">LDPR
+’s
+</del>
+<ins class="diff-chg">LDPR’s
+</ins>
+URL
+with
+the
+HTTP
+Method
+tokens
+in
+the
+HTTP
+response
+header
+<code>
+Allow
+</code>.
+</h2>
+</section>
+<del class="diff-old">4.10
+</del>
+</section>
+<section id="ldpr-Paging">
+<h2>
+Paging
+<del class="diff-old">4.10.1
+</del>
+</h2>
+<section class="informative" id="ldpr-PagingIntro">
+<h3>
+Introduction
+<del class="diff-old">This
+section
+is
+non-normative.
+</del>
+</h3>
+<p>
+It
+sometimes
+happens
+that
+a
+resource
+is
+too
+large
+to
+reasonably
+transmit
+its
+representation
+in
+a
+single
+HTTP
+response.
+<del class="diff-old">This
+will
+be
+especially
+true
+if
+the
+resource
+representation
+includes
+many
+triples
+both
+from
+its
+own
+representation
+and
+from
+the
+representations
+of
+any
+inlined
+resources
+.
+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.
+</del>
+To
+address
+this
+problem,
+<del class="diff-old">LDPRs
+</del>
+<ins class="diff-chg">servers
+</ins>
+should
+support
+a
+technique
+called
+Paging.
+<del class="diff-old"> Paging
+can
+be
+achieved
+with
+</del>
+<ins class="diff-chg"> 
+When
+a
+client
+retrieves
+such
+</ins>
+a
+<del class="diff-old">simple
+RDF
+pattern.
+For
+each
+</del>
+resource,
+<del class="diff-old"><resourceURL>
+,
+we
+define
+</del>
+<ins class="diff-chg">the
+server
+redirects
+the
+client
+to
+</ins>
+a
+<del class="diff-old">new
+'first
+page'
+resource.
+In
+this
+example,
+</del>
+<ins class="diff-chg">"first
+page"
+resource,
+and
+includes
+in
+</ins>
+its
+<del class="diff-old">URL
+will
+be
+<resourceURL>?firstPage
+,
+but
+servers
+are
+free
+</del>
+<ins class="diff-chg">response
+a
+link
+</ins>
+to
+<del class="diff-old">construct
+</del>
+the
+<del class="diff-old">URL
+as
+they
+see
+fit.
+</del>
+<ins class="diff-chg">next
+part
+of
+the
+resource's
+state,
+all
+at
+a
+URLs
+of
+the
+server's
+choosing.
+</ins>
+The
+triples
+in
+the
+representation
+of
+the
+<a title="Single-page resource">
+each
+page
+<ins class="diff-new">of
+an
+LDPR
+</ins></a>
+are
+typically
+a
+subset
+of
+the
+triples
+<del class="diff-old">in
+</del>
+<ins class="diff-chg">from
+</ins>
+the
+<a title="Paged resource">
+<ins class="diff-new">paged
+</ins>
+resource
+<del class="diff-old">-
+same
+subject,
+predicate
+and
+object.
+</del>
+</a>.
+</p>
+<p>
+<del class="diff-old">LDPR
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+may
+respond
+to
+requests
+for
+a
+resource
+by
+redirecting
+<del class="diff-old">the
+client
+</del>
+to
+the
+first
+page
+<ins class="diff-new">of
+the
+</ins>
+resource
+<del class="diff-old">–
+using
+</del>
+<ins class="diff-chg">and,
+with
+that,
+returning
+</ins>
+a
+<del class="diff-old">303
+“See
+Other”
+redirect
+to
+</del>
+<code>
+<ins class="diff-chg">Link
+<next-page-URL>;type='next'
+</ins></code><ins class="diff-chg">
+header
+containing
+</ins>
+the
+<del class="diff-old">actual
+</del>
+URL
+for
+the
+<del class="diff-old">page
+resource.
+Alternatively,
+clients
+may
+introspect
+the
+resource
+</del>
+<ins class="diff-chg">next
+page.
+Clients
+inspect
+each
+response
+</ins>
+for
+<del class="diff-old">a
+paged
+representation
+</del>
+<ins class="diff-chg">the
+link
+header
+to
+see
+if
+additional
+pages
+are
+available;
+paging
+does
+not
+affect
+the
+choice
+of
+HTTP
+status
+code.
+Note
+that
+paging
+is
+lossy,
+as
+described
+in
+[[RFC5005]],
+</ins>
+and
+<del class="diff-old">use
+it
+preferentially
+when
+available.
+</del>
+<ins class="diff-chg">so
+(as
+stated
+there)
+clients
+should
+not
+make
+any
+assumptions
+about
+a
+set
+of
+pages
+being
+a
+complete
+or
+coherent
+snapshot
+of
+a
+resource's
+state.
+</ins>
+</p>
+<p>
+Looking
+at
+an
+example
+resource
+representing
+Example
+Co.'s
+customer
+relationship
+data,
+<ins class="diff-new">identified
+by
+the
+URI
+</ins><code><ins class="diff-new">
+http://example.org/customer-relations
+</ins></code>,
+we’ll
+split
+the
+response
+across
+two
+pages.
+<del class="diff-old">
+To
+find
+the
+URL
+of
+the
+first
+page,
+the
+</del>
+<ins class="diff-chg"> 
+The
+</ins>
+client
+<del class="diff-old">makes
+a
+</del>
+<ins class="diff-chg">retrieves
+</ins>
+<code>
+<del class="diff-old">OPTIONS
+request
+to
+the
+resource's
+URL,
+</del>
+<ins class="diff-chg">http://example.org/customer-relations
+</ins></code>,
+and
+<del class="diff-old">in
+</del>
+the
+<del class="diff-old">response
+looks
+for
+a
+HTTP
+</del>
+<ins class="diff-chg">server
+responds
+with
+</ins><a href="#atrisk-333"><ins class="diff-chg">
+status
+code
+</ins>
+<code>
+<del class="diff-old">Link
+</del>
+<ins class="diff-chg">333
+(Returning
+Related)
+</ins>
+</code>
+<del class="diff-old">header
+with
+</del>
+</a>,
+<ins class="diff-chg">a
+</ins>
+<code>
+<del class="diff-old">rel="first"
+</del>
+<ins class="diff-chg">Location:
+http://example.org/customer-relations?page1
+</ins>
+</code>
+<del class="diff-old">;
+the
+target
+URI
+in
+the
+header
+is
+the
+URL
+of
+the
+first
+page
+resource.
+The
+client
+then
+requests
+</del>
+<ins class="diff-chg">HTTP
+response
+header,
+and
+</ins>
+the
+<del class="diff-old">first
+page
+as
+http://example.org/customer-relations?firstPage
+:
+</del>
+<ins class="diff-chg">following
+representation:
+</ins>
+</p>
+<del class="diff-old"># The following is the representation of
+# http://example.org/customer-relations?firstPage
+</del>
+<pre class="example" id="ldpc-ex-page1">
+<ins class="diff-chg"># The following is the representation of
+# http://example.org/customer-relations?page1
+# Requests on the URI will result in responses that include the following HTTP header
+# Link: <http://example.org/customer-relations?p=2>; rel='next'
+# This Link header is how clients discover the URI of the next page in sequence,
+# and that the resource supports paging.
+</ins>
+@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/>.
+<ins class="diff-new">@base <http://example.org/customer-relations>.
+</ins>
+<del class="diff-old"><http://example.org/customer-relations>
+</del>
+<ins class="diff-chg"><>
+</ins>
+ a o:CustomerRelations;
+<del class="diff-old"> 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>.
+</del>
+<ins class="diff-chg"> dcterms:title "The customer information for Example Co.";
+ o:client <#JohnZSmith>, <#BettyASmith>, <#JoanRSmith>.
+</ins>
+<del class="diff-old"><client#JohnZSmith>
+ a foaf:Person;
+</del>
+<ins class="diff-chg"><#JohnZSmith>
+ a foaf:Person;
+</ins>
+ o:status o:ActiveCustomer;
+<del class="diff-old"> foaf:name "John Z. Smith".
+<client#BettyASmith>
+ a foaf:Person;
+</del>
+<ins class="diff-chg"> foaf:name "John Z. Smith".
+<#BettyASmith>
+ a foaf:Person;
+</ins>
+ o:status o:PreviousCustomer;
+<del class="diff-old"> foaf:name "Betty A. Smith".
+ <client#BettyASmith>
+ a foaf:Person;
+</del>
+<ins class="diff-chg"> foaf:name "Betty A. Smith".
+ <#JoanRSmith>
+ a foaf:Person;
+</ins>
+ o:status o:PotentialCustomer;
+<del class="diff-old">
+foaf:name
+"Joan
+R.
+Smith".
+</del>
+<ins class="diff-chg"> foaf:name "Joan R. Smith".
+</ins>
+</pre>
+<p>
+<ins class="diff-new">Because
+the
+server
+includes
+a
+</ins><code><ins class="diff-new">
+Link:
+<http://example.org/customer-relations?p=2>;
+rel='next'
+</ins></code><ins class="diff-new">
+response
+header,
+and
+the
+status
+code
+is
+3xx
+(
+</ins><code><ins class="diff-new">
+333
+(Returning
+Related)
+</ins></code><ins class="diff-new">
+in
+this
+case),
+the
+client
+knows
+that
+more
+data
+exists
+and
+where
+to
+find
+it.
+</ins>
+The
+server
+determines
+the
+size
+of
+the
+pages
+using
+application
+specific
+methods
+not
+defined
+within
+this
+specificiation.
+<del class="diff-old">Note
+also,
+the
+actual
+name
+for
+the
+query
+parameter
+(such
+as
+?p=2)
+</del>
+<ins class="diff-chg">The
+next
+page
+link's
+target
+URI
+</ins>
+is
+also
+defined
+by
+the
+server
+and
+not
+this
+specification.
+</p>
+<p>
+The
+following
+example
+is
+the
+result
+of
+retrieving
+the
+<del class="diff-old">representation
+for
+the
+</del>
+next
+<del class="diff-old">page:
+</del>
+<ins class="diff-chg">page;
+the
+server
+responds
+with
+status
+code
+</ins><code><ins class="diff-chg">
+200
+(OK)
+</ins></code><ins class="diff-chg">
+and
+the
+following
+representation:
+</ins>
+</p>
+<del class="diff-old"># The following is the representation of
+</del>
+<pre class="example" id="ldpc-ex-page2">
+<ins class="diff-chg"># The following is the representation of
+</ins>
+# http://example.org/customer-relations?p=2
+<ins class="diff-new">#
+# There is no "next" Link in the server's response, so this is the final page.
+#
+</ins>
+@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/>.
+<ins class="diff-new">@base <http://example.org/customer-relations>.
+</ins>
+<del class="diff-old"><http://example.org/customer-relations>
+ o:client <client#GlenWSmith>, <client#AlfredESmith>.
+</del>
+<ins class="diff-chg"><>
+ o:client <#GlenWSmith>, <#AlfredESmith>.
+</ins>
+
+<del class="diff-old"><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;
+</del>
+<ins class="diff-chg"><#GlenWSmith>
+ a foaf:Person;
+</ins>
+ o:status o:ActiveCustomer, o:GoldCustomer;
+<del class="diff-old"> foaf:name "Glen W. Smith".
+</del>
+<ins class="diff-chg"> foaf:name "Glen W. Smith".
+</ins>
+<del class="diff-old"><client#AlfredESmith>
+ a foaf:Person;
+</del>
+<ins class="diff-chg"><#AlfredESmith>
+ a foaf:Person;
+</ins>
+ o:status o:ActiveCustomer, o:BronzeCustomer;
+<del class="diff-old">
+foaf:name
+"Alfred
+E.
+Smith".
+</del>
+<ins class="diff-chg"> foaf:name "Alfred E. Smith".
+
+</ins>
+</pre>
+<p>
+In
+this
+example,
+there
+are
+only
+two
+customers
+provided
+in
+the
+final
+page.
+<del class="diff-old"> To
+</del>
+<ins class="diff-chg"> To
+</ins>
+indicate
+this
+is
+the
+last
+page,
+<del class="diff-old">a
+value
+of
+rdf:nil
+is
+used
+for
+</del>
+<ins class="diff-chg">the
+server
+omits
+</ins>
+the
+<code>
+<del class="diff-old">ldp:nextPage
+</del>
+<ins class="diff-chg">Link:
+rel='next'
+</ins>
+</code>
+<del class="diff-old">predicate
+</del>
+<ins class="diff-chg">header
+in
+its
+response.
+</ins></p><p><ins class="diff-chg">
+As
+mentioned
+above,
+retrieving
+all
+the
+pages
+offered
+by
+a
+server
+gives
+no
+guarantee
+to
+a
+client
+that
+it
+knows
+the
+entire
+state
+</ins>
+of
+the
+<ins class="diff-new">server.
+For
+example,
+after
+the
+server
+constructs
+the
+the
+first
+</ins>
+page
+<del class="diff-old">resource.
+</del>
+<ins class="diff-chg">representation,
+another
+actor
+could
+delete
+</ins><code><ins class="diff-chg">
+client#BettyASmith
+</ins></code><ins class="diff-chg">
+from
+the
+server.
+</ins>
+</p>
+</section>
+<del class="diff-old">4.10.2
+</del>
+<section id="ldpr-PagingGET">
+<h3>
+HTTP
+GET
+</h3>
+<p>
+In
+addition
+to
+the
+requirements
+set
+forth
+in
+<a href="#ldpr-HTTP_GET" class="sectionRef">
+<del class="diff-old">section
+4.3
+</del>
+</a>
+on
+HTTP
+<code>
+GET
+</code>,
+<del class="diff-old">LDPR
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+that
+support
+paging
+must
+also
+follow
+the
+requirements
+in
+this
+section
+<ins class="diff-new">for
+all
+</ins><a title="Paged resource"><ins class="diff-new">
+paged
+resources
+</ins></a><ins class="diff-new">
+and
+their
+associated
+</ins><a title="Single-page resource"><ins class="diff-new">
+single-page
+resources
+</ins></a>.
+</p>
+<del class="diff-old">4.10.2.1
+LDPR
+</del>
+<section id="ldpr-pagingGET-sequences-change">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+<ins class="diff-chg">MAY
+add
+</ins><a title="Single-page resource"><ins class="diff-chg">
+single-page
+resources
+</ins></a><ins class="diff-chg">
+to
+a
+</ins><a title="Paged resource"><ins class="diff-chg">
+paged
+resource's
+</ins></a><ins class="diff-chg">
+sequence
+over
+time,
+but
+</ins>
+SHOULD
+<del class="diff-old">allow
+clients
+</del>
+<ins class="diff-chg">only
+add
+pages
+</ins>
+to
+<del class="diff-old">retrieve
+large
+LDPRs
+</del>
+<ins class="diff-chg">the
+end
+of
+a
+sequence.
+</ins></h2><blockquote><ins class="diff-chg">
+Non-normative
+note:
+As
+a
+result,
+clients
+retrieving
+any
+</ins><a title="Single-page resource"><ins class="diff-chg">
+single-page
+resource
+</ins></a><ins class="diff-chg">
+several
+times
+can
+observe
+its
+place
+</ins>
+in
+<ins class="diff-new">the
+sequence
+change
+as
+the
+state
+of
+the
+</ins><a title="Paged resource"><ins class="diff-new">
+paged
+resource
+</ins></a><ins class="diff-new">
+changes.
+For
+example,
+a
+nominally
+last
+page's
+server
+might
+provide
+a
+</ins><a><ins class="diff-new">
+next
+page
+link
+</ins></a><ins class="diff-new">
+when
+the
+page
+is
+retrieved.
+Similar
+situations
+arise
+when
+the
+page
+sequence
+crosses
+server
+boundaries;
+server
+A
+might
+host
+the
+initial
+portion
+of
+a
+sequence
+that
+links
+to
+the
+last
+page
+server
+A
+is
+aware
+of,
+hosted
+on
+server
+B,
+and
+server
+B
+might
+extend
+the
+sequence
+of
+</ins>
+pages.
+<del class="diff-old">In
+</del>
+</blockquote>
+<section id="ldpr-pagingGET-first-allowed-onpages">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+servers
+</ins></a><ins class="diff-chg">
+MAY
+provide
+a
+</ins><a><ins class="diff-chg">
+first
+page
+link
+</ins></a><ins class="diff-chg">
+when
+responding
+to
+requests
+with
+any
+</ins><a title="Single-page resource"><ins class="diff-chg">
+single-page
+resource
+</ins></a><ins class="diff-chg">
+as
+the
+</ins><code><ins class="diff-chg">
+Request-URI
+</ins></code>.</h2></section><section id="ldpr-pagingGET-last-allowed-onpages"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a><ins class="diff-chg">
+MAY
+provide
+a
+</ins><a><ins class="diff-chg">
+last
+page
+link
+</ins></a><ins class="diff-chg">
+in
+</ins>
+responses
+to
+<code>
+GET
+</code>
+requests
+with
+<del class="diff-old">an
+LDPR
+</del>
+<ins class="diff-chg">any
+</ins><a title="Single-page resource"><ins class="diff-chg">
+single-page
+resource
+</ins></a>
+as
+the
+<code>
+Request-URI
+<del class="diff-old">,
+LDPR
+</del>
+</code>.
+</h2>
+</section>
+</section>
+<section id="ldpr-pagingGET-next-reqd">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+<del class="diff-old">that
+support
+paging
+SHOULD
+</del>
+</a>
+<ins class="diff-chg">MUST
+</ins>
+provide
+<del class="diff-old">an
+HTTP
+Link
+header
+whose
+target
+URI
+is
+the
+first
+</del>
+<ins class="diff-chg">a
+</ins><a><ins class="diff-chg">
+next
+</ins>
+page
+<del class="diff-old">resource,
+and
+whose
+</del>
+link
+<del class="diff-old">relation
+type
+is
+</del>
+</a>
+<ins class="diff-chg">in
+responses
+to
+</ins>
+<code>
+<del class="diff-old">first
+</del>
+<ins class="diff-chg">GET
+</ins>
+</code>
+<del class="diff-old">[
+RFC5988
+</del>
+<ins class="diff-chg">requests
+with
+any
+</ins><a title="Single-page resource"><ins class="diff-chg">
+single-page
+resource
+</ins>
+</a>
+<del class="diff-old">].
+</del>
+<em>
+<ins class="diff-chg">other
+than
+the
+final
+page
+</ins></em><ins class="diff-chg">
+as
+the
+</ins><code><ins class="diff-chg">
+Request-URI
+</ins></code>.
+This
+is
+the
+mechanism
+by
+which
+clients
+<ins class="diff-new">can
+</ins>
+discover
+the
+URL
+of
+the
+<del class="diff-old">first
+</del>
+<ins class="diff-chg">next
+</ins>
+page.
+<del class="diff-old">If
+no
+such
+Link
+header
+is
+present,
+then
+conservative
+clients
+will
+assume
+that
+the
+LDPR
+does
+not
+support
+paging.
+For
+example,
+if
+there
+is
+</del>
+</h2>
+<section id="ldpr-pagingGET-lastnext-prohibited">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+servers
+</ins></a><ins class="diff-chg">
+MUST
+NOT
+provide
+</ins>
+a
+<del class="diff-old">LDPR
+with
+URL
+<resourceURL>
+that
+supports
+paging
+and
+whose
+first
+</del>
+<a>
+<ins class="diff-chg">next
+</ins>
+page
+<del class="diff-old">URL
+is
+<resourceURL>?theFirstPage
+,
+then
+the
+corresponding
+</del>
+link
+<del class="diff-old">header
+would
+be
+</del>
+</a>
+<ins class="diff-chg">in
+responses
+to
+</ins>
+<code>
+<del class="diff-old">Link:
+<?theFirstPage>;rel="first"
+.
+The
+representation
+for
+any
+page,
+including
+the
+first,
+will
+include
+the
+URL
+for
+</del>
+<ins class="diff-chg">GET
+</ins></code><ins class="diff-chg">
+requests
+with
+</ins>
+the
+<del class="diff-old">next
+page. See
+section
+4.10
+</del>
+<ins class="diff-chg">final
+</ins><a title="Single-page resource"><ins class="diff-chg">
+single-page
+resource
+</ins>
+</a>
+<del class="diff-old">for
+additional
+details.
+4.10.2.2
+LDPR
+servers
+MAY
+split
+</del>
+<ins class="diff-chg">as
+</ins>
+the
+<del class="diff-old">response
+representation
+of
+any
+LDPR
+.
+</del>
+<code>
+<ins class="diff-chg">Request-URI
+</ins></code>.
+This
+is
+<del class="diff-old">known
+as
+server-initiated
+paging.
+See
+section
+4.10
+for
+additional
+details.
+4.10.2.3
+LDPR
+servers
+that
+initiate
+paging
+SHOULD
+respond
+to
+requests
+for
+a
+LDPR
+</del>
+<ins class="diff-chg">the
+mechanism
+</ins>
+by
+<del class="diff-old">redirecting
+</del>
+<ins class="diff-chg">which
+clients
+can
+discover
+</ins>
+the
+<del class="diff-old">client
+to
+</del>
+<ins class="diff-chg">end
+of
+</ins>
+the
+<del class="diff-old">first
+</del>
+page
+<del class="diff-old">resource
+using
+</del>
+<ins class="diff-chg">sequence
+as
+currently
+known
+by
+the
+server.
+</ins></h2></section><section id="ldpr-pagingGET-prev-allowed"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a><ins class="diff-chg">
+MAY
+provide
+</ins>
+a
+<a>
+<ins class="diff-new">previous
+page
+link
+</ins></a><ins class="diff-new">
+in
+responses
+to
+</ins>
+<code>
+<del class="diff-old">303
+See
+Other
+</del>
+<ins class="diff-chg">GET
+</ins>
+</code>
+<del class="diff-old">response
+</del>
+<ins class="diff-chg">requests
+</ins>
+with
+<del class="diff-old">an
+HTTP
+Location
+header
+providing
+the
+first
+page
+</del>
+<ins class="diff-chg">any
+</ins><a title="Single-page resource"><ins class="diff-chg">
+single-page
+</ins>
+resource
+<del class="diff-old">URL.
+4.10.2.4
+LDPR
+servers
+that
+support
+paging
+MUST
+include
+a
+representation
+for
+</del>
+</a>
+<em>
+<ins class="diff-chg">other
+than
+</ins>
+the
+<ins class="diff-new">first
+</ins>
+page
+<del class="diff-old">resource.
+4.10.2.4.1
+The
+page
+resource
+representation
+MUST
+</del>
+</em>
+<del class="diff-old">have
+one
+triple
+with
+the
+subject
+of
+</del>
+<ins class="diff-chg">as
+</ins>
+the
+<del class="diff-old">page,
+predicate
+of
+</del>
+<code>
+<del class="diff-old">ldp:nextPage
+and
+object
+being
+</del>
+<ins class="diff-chg">Request-URI
+</ins></code>.<ins class="diff-chg">
+This
+is
+one
+mechanism
+by
+which
+clients
+can
+discover
+</ins>
+the
+URL
+<del class="diff-old">for
+</del>
+<ins class="diff-chg">of
+</ins>
+the
+<del class="diff-old">subsequent
+</del>
+<ins class="diff-chg">previous
+</ins>
+page.
+<del class="diff-old"><http://example.org/customer-relations?firstPage>
+ldp:nextPage
+<http://example.org/customer-relations?p=2>
+.
+</del>
+</h2>
+</section>
+<section id="ldpr-pagingGET-firstprev-prohibited">
+<h2 class="normal">
+<del class="diff-old">4.10.2.4.2
+The
+last
+page
+resource
+representation
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+servers
+</ins></a>
+MUST
+<del class="diff-old">have
+one
+triple
+with
+the
+subject
+of
+the
+last
+page,
+predicate
+of
+ldp:nextPage
+and
+object
+being
+rdf:nil
+.
+<http://example.org/customer-relations?p=2>
+ldp:nextPage
+rdf:nil
+.
+4.10.2.4.3
+The
+</del>
+<ins class="diff-chg">NOT
+provide
+a
+</ins><a><ins class="diff-chg">
+previous
+</ins>
+page
+<del class="diff-old">resource
+representation
+SHOULD
+have
+one
+triple
+</del>
+<ins class="diff-chg">link
+</ins></a><ins class="diff-chg">
+in
+responses
+</ins>
+to
+<del class="diff-old">indicate
+its
+type,
+whose
+subject
+is
+the
+URL
+of
+the
+page,
+whose
+predicate
+is
+</del>
+<code>
+<del class="diff-old">rdf:type
+</del>
+<ins class="diff-chg">GET
+</ins>
+</code>
+<del class="diff-old">and
+object
+is
+ldp:Page
+.
+It
+also
+SHOULD
+have
+1
+triple
+to
+indicate
+</del>
+<ins class="diff-chg">requests
+with
+</ins>
+the
+<em>
+<ins class="diff-new">first
+</ins></em><a title="Single-page resource"><ins class="diff-new">
+single-page
+</ins>
+resource
+<del class="diff-old">it
+is
+paging,
+whose
+ subject
+is
+the
+URL
+of
+</del>
+</a>
+<ins class="diff-chg">as
+</ins>
+the
+<del class="diff-old">page,
+predicate
+is
+</del>
+<code>
+<del class="diff-old">ldp:pageOf
+,
+and
+object
+</del>
+<ins class="diff-chg">Request-URI
+</ins></code>.<ins class="diff-chg">
+This
+</ins>
+is
+<ins class="diff-new">one
+mechanism
+by
+which
+clients
+can
+discover
+</ins>
+the
+<del class="diff-old">URL
+</del>
+<ins class="diff-chg">beginning
+</ins>
+of
+the
+<del class="diff-old">LDPR
+.
+<http://example.org/customer-relations?firstPage>
+ rdf:type ldp:Page;
+ldp:pageOf
+<http://example.org/customer-relations>.
+</del>
+<ins class="diff-chg">page
+sequence
+as
+currently
+known
+by
+the
+server.
+</ins></h2>
+</section>
+</section>
+<section id="ldpr-pagingGET-page-type-reqd">
+<h2 class="normal">
+<del class="diff-old">4.10.3
+HTTP
+OPTIONS
+4.10.3.1
+LDPR
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+MUST
+<del class="diff-old">indicate
+their
+support
+for
+client-initiated
+paging
+by
+responding
+to
+a
+</del>
+<ins class="diff-chg">provide
+an
+</ins>
+HTTP
+<code>
+<del class="diff-old">OPTIONS
+</del>
+<ins class="diff-chg">Link
+</ins>
+</code>
+<del class="diff-old">request
+on
+the
+LDPR
+’s
+URL
+with
+the
+HTTP
+response
+</del>
+header
+<del class="diff-old">for
+link
+relations
+using
+the
+header
+name
+of
+</del>
+<ins class="diff-chg">whose
+target
+URI
+is
+</ins>
+<code>
+<del class="diff-old">Link
+</del>
+<ins class="diff-chg">http://www.w3.org/ns/ldp#Page
+</ins></code>,
+and
+<ins class="diff-new">whose
+</ins>
+link
+relation
+type
+<ins class="diff-new">is
+</ins>
+<code>
+<del class="diff-old">first
+</del>
+<ins class="diff-chg">type
+</ins>
+</code>
+<del class="diff-old">[
+RFC5988
+].
+4.11
+Resource
+Inlining:
+Representing
+Multiple
+Resources
+</del>
+<ins class="diff-chg">[[!RFC5988]]
+</ins>
+in
+<ins class="diff-new">responses
+to
+</ins><code><ins class="diff-new">
+GET
+</ins></code><ins class="diff-new">
+requests
+with
+any
+</ins><a title="Single-page resource"><ins class="diff-new">
+single-page
+resource
+</ins></a><ins class="diff-new">
+as
+the
+</ins><code><ins class="diff-new">
+Request-URI
+</ins></code>.<ins class="diff-new">
+This
+is
+one
+mechanism
+by
+which
+clients
+know
+that
+the
+resource
+is
+one
+of
+</ins>
+a
+<del class="diff-old">Response
+</del>
+<ins class="diff-chg">sequence
+of
+pages.
+</ins></h2></section><div class="atrisk" id="atrisk-333">
+<p class="atrisktext">
+Feature
+At
+Risk
+</p>
+<p>
+The
+LDP
+Working
+Group
+proposes
+incorporation
+of
+the
+features
+described
+in
+<del class="diff-old">this
+section.
+</del>
+<ins class="diff-chg">the
+next
+compliance
+clause.
+</ins>
+</p>
+<ul>
+<li>
+<del class="diff-old">The
+addition
+of
+resource
+inlining
+to
+save
+application
+latency
+and
+server/network
+load
+in
+controlled
+environments.
+Feedback,
+both
+positive
+and
+negative,
+is
+invited
+by
+sending
+email
+to
+the
+mailing
+list
+in
+Status
+of
+This
+Document
+.
+4.11.1
+Introduction
+</del>
+<p>
+<del class="diff-old">This
+section
+is
+non-normative.
+Servers
+</del>
+<ins class="diff-chg">A
+</ins><a href="http://lists.w3.org/Archives/Public/www-tag/2013Dec/0041.html"><ins class="diff-chg">
+TAG
+discussion
+</ins></a><ins class="diff-chg">
+has
+started,
+</ins>
+whose
+<del class="diff-old">resources
+are
+relatively
+granular
+may
+wish
+to
+optimistically
+provide
+more
+information
+in
+a
+response
+than
+what
+the
+client
+actually
+requested,
+in
+order
+</del>
+<ins class="diff-chg">goal
+is
+</ins>
+to
+reduce
+the
+<del class="diff-old">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
+resource
+inlining
+and
+member
+inlining
+.
+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
+</del>
+<ins class="diff-chg">need
+for
+two
+request-response
+round
+trips
+down
+</ins>
+to
+<del class="diff-old">influence
+which
+(if
+any)
+resources
+are
+inlined
+in
+any
+given
+response.
+Servers
+can
+return
+extra
+triples
+on
+any
+response,
+but
+fail
+</del>
+<ins class="diff-chg">one
+when
+retrieving
+what
+turns
+out
+</ins>
+to
+<del class="diff-old">meet
+</del>
+<ins class="diff-chg">be
+</ins>
+the
+<del class="diff-old">definition
+</del>
+<ins class="diff-chg">first
+page
+</ins>
+of
+<del class="diff-old">resource
+inlining
+,
+</del>
+<ins class="diff-chg">a
+paged
+resource,
+</ins>
+by
+<del class="diff-old">either
+returning
+</del>
+<ins class="diff-chg">defining
+</ins>
+a
+<del class="diff-old">subset
+of
+</del>
+<ins class="diff-chg">new
+HTTP
+response
+code
+in
+</ins>
+the
+<del class="diff-old">other
+resource(s)
+triples
+</del>
+<code>
+<ins class="diff-chg">2xx
+</ins></code>
+or
+<del class="diff-old">by
+failing
+to
+assert
+</del>
+<code>
+<ins class="diff-chg">3xx
+</ins></code><ins class="diff-chg">
+class
+</ins>
+that
+<del class="diff-old">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
+</del>
+would
+<del class="diff-old">be
+to
+make
+</del>
+<ins class="diff-chg">allow
+</ins>
+a
+<del class="diff-old">HTTP
+</del>
+<ins class="diff-chg">server
+to
+respond
+to
+</ins>
+<code>
+GET
+<ins class="diff-new">request-uri
+</ins>
+</code>
+<del class="diff-old">request
+against
+all
+the
+other
+resource(s).
+In
+some
+applications,
+knowing
+that
+these
+</del>
+requests
+<del class="diff-old">are
+unnecessary
+saves
+significant
+latency
+and
+server/network
+load.
+4.11.2
+Use
+</del>
+with
+<del class="diff-old">Care
+This
+section
+is
+non-normative.
+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
+</del>
+the
+<del class="diff-old">general
+case
+—
+so
+if
+you
+care
+about
+any
+</del>
+<ins class="diff-chg">representation
+</ins>
+of
+the
+<del class="diff-old">following
+in
+a
+given
+application,
+your
+server
+should
+avoid
+returning
+any
+triples
+beyond
+those
+found
+at
+the
+HTTP
+Request-URI
+.
+Provenance
+is
+lost:
+because
+RDF
+graphs
+from
+multiple
+HTTP
+resources
+are
+merged
+in
+the
+response
+without
+attributing
+each
+statement
+to
+its
+originating
+graph
+(i.e.
+without
+quotation),
+it
+</del>
+<ins class="diff-chg">first
+page
+(whose
+URI
+</ins>
+is
+<del class="diff-old">impossible
+for
+</del>
+<code>
+<ins class="diff-chg">first-page-uri
+</ins></code>,<ins class="diff-chg">
+not
+</ins><code><ins class="diff-chg">
+request-uri
+</ins></code><ins class="diff-chg">
+)
+of
+</ins>
+a
+<del class="diff-old">client
+to
+reliably
+know
+which
+triples
+came
+from
+which
+HTTP
+resource(s).
+A
+general
+solution
+allowing
+quotation
+is
+RDF
+Datasets;
+that
+is
+expected
+to
+be
+standardized
+independently,
+and
+can
+be
+used
+in
+these
+cases
+once
+it
+is
+available.
+</del>
+<ins class="diff-chg">multi-page
+response.
+</ins>
+</p>
+</li>
+<li>
+<p>
+<del class="diff-old">The
+response
+may
+contain
+contradictions
+that
+are
+trivially
+obvious
+(or
+subtle),
+and
+those
+may
+or
+may
+not
+be
+a
+problem
+at
+the
+application
+level.
+</del>
+For
+<del class="diff-old">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
+RDF
+Datasets
+(or
+any
+equivalent
+mechanism)
+is
+believed
+to
+provide
+a
+long
+term
+solution
+once
+standardized.
+4.11.3
+HTTP
+GET
+In
+addition
+to
+</del>
+the
+<del class="diff-old">requirements
+set
+forth
+in
+other
+sections,
+LDPR
+servers
+that
+support
+resource
+inlining
+must
+also
+follow
+the
+requirements
+in
+</del>
+<ins class="diff-chg">purposes
+of
+drafting
+</ins>
+this
+<del class="diff-old">section.
+4.11.3.1
+LDPR
+servers
+</del>
+<ins class="diff-chg">section,
+we
+assume
+</ins>
+that
+<del class="diff-old">support
+resource
+inlining
+MUST
+include
+a
+ldp:Page
+resource
+in
+the
+representation
+describing
+</del>
+the
+<del class="diff-old">set
+of
+inlined
+resources,
+whether
+or
+not
+the
+representation
+contains
+subsequent
+pages.
+The
+ldp:Page
+resource
+conceptually
+contains
+metadata
+about
+the
+representation;
+it
+</del>
+<ins class="diff-chg">new
+code's
+value
+</ins>
+is
+<del class="diff-old">usually
+not
+part
+of
+the
+HTTP
+resource's
+state,
+</del>
+<code>
+<ins class="diff-chg">333
+(Returning
+Related)
+</ins></code>,<a href="http://lists.w3.org/Archives/Public/www-tag/2014Jan/0023.html"><ins class="diff-chg">
+an
+LDP
+extrapolation
+from
+TAG
+discussions,
+</ins></a>
+and
+its
+<del class="diff-old">presence
+does
+not
+indicate
+that
+</del>
+<ins class="diff-chg">definition
+is
+given
+by
+</ins><a href="http://lists.w3.org/Archives/Public/www-tag/2014Jan/0015.html"><ins class="diff-chg">
+Henry
+Thompson's
+strawman
+</ins></a>,<ins class="diff-chg">
+with
+</ins>
+the
+<del class="diff-old">LDPR
+server
+supports
+paging
+in
+general.
+LDPR
+</del>
+<ins class="diff-chg">substitution
+of
+333
+for
+2xx.
+Note:
+nothing
+prevents
+</ins>
+servers
+<del class="diff-old">that
+include
+the
+</del>
+<ins class="diff-chg">or
+clients
+from
+using
+</ins>
+<code>
+<del class="diff-old">ldp:Page
+</del>
+<ins class="diff-chg">303
+See
+Other
+</ins>
+</code>
+<del class="diff-old">resource
+</del>
+<ins class="diff-chg">responses
+to
+requests
+</ins>
+for
+<del class="diff-old">inlining
+</del>
+<a title="Paged resource">
+<ins class="diff-chg">paged
+resources
+</ins></a>.<ins class="diff-chg">
+The
+only
+significant
+difference
+between
+303
+</ins>
+and
+<del class="diff-old">also
+support
+paging
+MUST
+use
+</del>
+<ins class="diff-chg">333
+responses
+is
+</ins>
+the
+<del class="diff-old">same
+ldp:Page
+resource
+</del>
+<ins class="diff-chg">extra
+round
+trip
+required
+</ins>
+for
+the
+<del class="diff-old">triples
+required
+by
+both,
+in
+order
+to
+minimize
+</del>
+client
+<del class="diff-old">code
+complexity.
+The
+ldp:Page
+resource's
+triples
+are
+the
+LDP-defined
+means
+by
+which
+the
+servers
+communicate
+</del>
+to
+<del class="diff-old">LDP
+clients
+</del>
+<ins class="diff-chg">retrieve
+</ins>
+the
+<del class="diff-old">set
+</del>
+<ins class="diff-chg">representation
+</ins>
+of
+<del class="diff-old">HTTP
+resources
+whose
+state
+</del>
+<ins class="diff-chg">the
+first
+page
+when
+using
+303.
+</ins></p></li><li><p><ins class="diff-chg">
+Once
+LDP
+</ins>
+is
+<del class="diff-old">included
+in
+</del>
+a
+<del class="diff-old">representation,
+allowing
+clients
+</del>
+<ins class="diff-chg">Candidate
+Recommendation,
+the
+LDP
+WG
+will
+make
+an
+assessment
+based
+on
+the
+status
+at
+IETF,
+working
+with
+the
+W3C
+Director,
+</ins>
+to
+<del class="diff-old">avoid
+HTTP
+GET
+requests
+for
+them.
+4.11.3.2
+LDPR
+servers
+that
+support
+resource
+inlining
+MUST
+include
+</del>
+<ins class="diff-chg">either
+use
+</ins>
+the
+<del class="diff-old">ldp:Page
+resource
+described
+</del>
+<ins class="diff-chg">newly
+defined
+response
+code
+as
+documented
+</ins>
+in
+<ins class="diff-chg">this
+</ins>
+section
+<del class="diff-old">4.11.3.1
+one
+triple
+for
+each
+inlined
+resource,
+whose
+subject
+is
+the
+ldp:Page
+resource
+URI,
+whose
+predicate
+is
+ldp:inlinedResource
+,
+and
+whose
+object
+is
+the
+HTTP
+</del>
+<ins class="diff-chg">or
+to
+revert
+to
+a
+classic
+</ins>
+<code>
+<del class="diff-old">Request-URI
+</del>
+<ins class="diff-chg">303
+</ins>
+</code>
+<del class="diff-old">of
+an
+inlined
+resource
+[
+</del>
+<ins class="diff-chg">response
+pattern.
+</ins></p></li></ul></div><section id="ldpr-status-code"><h2 class="normal">
+<del class="diff-old">HTTP11
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+servers
+</ins>
+</a>
+<del class="diff-old">].
+4.11.3.3
+LDPR
+clients
+</del>
+SHOULD
+<del class="diff-old">avoid
+making
+</del>
+<ins class="diff-chg">respond
+with
+</ins>
+HTTP
+<ins class="diff-new">status
+code
+</ins><code><ins class="diff-new">
+333
+(Returning
+Related)
+</ins></code><ins class="diff-new">
+to
+successful
+</ins>
+<code>
+GET
+</code>
+requests
+<del class="diff-old">against
+</del>
+<ins class="diff-chg">with
+</ins>
+any
+<a title="Paged resource">
+<ins class="diff-new">paged
+</ins>
+resource
+<del class="diff-old">whose
+HTTP
+</del>
+</a>
+<ins class="diff-chg">as
+the
+</ins>
+<code>
+Request-URI
+<del class="diff-old">is
+the
+object
+of
+a
+triple
+of
+the
+form
+described
+in
+section
+4.11.3.2
+,
+unless
+there
+are
+application-specific
+reasons
+for
+doing
+so.
+Clients
+should
+note
+that
+by
+the
+time
+the
+representation
+is
+received,
+the
+actual
+state
+of
+</del>
+</code>,
+<ins class="diff-chg">although
+</ins>
+any
+<del class="diff-old">inlined
+resource(s)
+may
+have
+changed
+due
+</del>
+<ins class="diff-chg">appropriate
+code
+MAY
+be
+used.
+</ins></h2></section></section><section id="ldpr-paging-HTTP_OPTIONS"><h3><ins class="diff-chg">
+HTTP
+OPTIONS
+</ins></h3><p><ins class="diff-chg">
+In
+addition
+</ins>
+to
+<del class="diff-old">subsequent
+requests.
+4.11.3.4
+LDPR
+clients
+MUST
+NOT
+assume
+that
+LDPR
+representations
+lacking
+a
+ldp:Page
+resource
+or
+lacking
+</del>
+the
+<del class="diff-old">triple
+described
+</del>
+<ins class="diff-chg">requirements
+set
+forth
+</ins>
+in
+<del class="diff-old">section
+4.11.3.2
+</del>
+<a href="#ldpr-HTTP_OPTIONS" class="sectionRef">
+</a>
+<del class="diff-old">contain
+all
+the
+triples
+for
+any
+resource(s)
+listed
+in
+the
+representation
+whose
+HTTP
+Request-URI
+differs
+from
+the
+</del>
+<ins class="diff-chg">on
+</ins>
+HTTP
+<code>
+<del class="diff-old">Request-URI
+used
+by
+</del>
+<ins class="diff-chg">OPTIONS
+</ins></code>,<a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a><ins class="diff-chg">
+that
+support
+paging
+must
+also
+follow
+</ins>
+the
+<del class="diff-old">client.
+The
+representation
+might
+</del>
+<ins class="diff-chg">requirements
+</ins>
+in
+<del class="diff-old">fact
+contain
+</del>
+<ins class="diff-chg">this
+section
+for
+</ins>
+all
+<del class="diff-old">such
+triples,
+or
+some
+subset
+of
+them,
+and
+</del>
+<a title="Paged resource">
+<ins class="diff-chg">paged
+resources
+</ins></a>.<ins class="diff-chg">
+Note
+</ins>
+that
+<del class="diff-old">might
+or
+might
+not
+be
+completely
+adequate
+for
+the
+client's
+intended
+usage,
+but
+an
+</del>
+LDP
+<del class="diff-old">client
+has
+no
+way
+to
+discern
+</del>
+<ins class="diff-chg">only
+requires
+enough
+</ins>
+from
+<del class="diff-old">such
+</del>
+<code>
+<ins class="diff-chg">OPTIONS
+</ins></code><ins class="diff-chg">
+for
+discovery
+of
+paging
+support
+on
+</ins>
+a
+<del class="diff-old">representation
+</del>
+<ins class="diff-chg">resource,
+</ins>
+which
+<del class="diff-old">interpretation
+</del>
+is
+<del class="diff-old">accurate.
+</del>
+<ins class="diff-chg">considerably
+less
+than
+is
+required
+for
+HTTP
+</ins><code><ins class="diff-chg">
+GET
+</ins></code>.<ins class="diff-chg">
+This
+lowers
+server
+implementation
+effort.
+</ins></p>
+</section>
+</section>
+</section>
+<del class="diff-old">5.
+</del>
+<section id="ldpc">
+<h1>
+Linked
+Data
+Platform
+Containers
+</h1>
+<section class="informative" id="ldpc-informative">
+<h2>
+<ins class="diff-new">Introduction
+</ins>
+</h2>
+<del class="diff-old">5.1
+Informative
+This
+section
+is
+non-normative.
+</del>
+<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
+<a title="Membership triples">
+membership
+<del class="diff-old">triples.
+</del>
+<ins class="diff-chg">triples
+</ins></a><ins class="diff-chg">
+that
+follow
+a
+consistent
+pattern
+(see
+the
+linked-to
+definition
+for
+the
+possible
+patterns).
+</ins>
+The
+membership
+triples
+of
+a
+container
+all
+have
+the
+same
+<del class="diff-old">subject
+</del>
+<ins class="diff-chg">predicate,
+called
+the
+membership
+predicate,
+</ins>
+and
+<del class="diff-old">predicate
+</del>
+<ins class="diff-chg">either
+the
+subject
+or
+the
+object
+is
+also
+a
+consistent
+value
+</ins>
+–
+the
+<del class="diff-old">objects
+</del>
+<ins class="diff-chg">remaining
+position
+</ins>
+of
+the
+membership
+triples
+<ins class="diff-new">(the
+one
+that
+varies)
+</ins>
+define
+the
+members
+of
+the
+container.
+<del class="diff-old">The
+subject
+of
+the
+membership
+triples
+is
+called
+the
+membership
+subject
+and
+the
+predicate
+is
+called
+the
+membership
+predicate.
+</del>
+In
+the
+simplest
+cases,
+the
+<del class="diff-old">membership
+subject
+</del>
+<ins class="diff-chg">consistent
+value
+</ins>
+will
+be
+the
+LDPC
+<del class="diff-old">resource
+itself,
+</del>
+<ins class="diff-chg">resource's
+URI,
+</ins>
+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>
+<del class="diff-old">rdfs:member
+</del>
+<ins class="diff-chg">ldp:member
+</ins>
+</code>
+predicate.
+</p>
+<p>
+This
+document
+includes
+a
+set
+of
+guidelines
+for
+<del class="diff-old">using
+POST
+to
+create
+</del>
+<ins class="diff-chg">creating
+</ins>
+new
+resources
+and
+<del class="diff-old">add
+</del>
+<ins class="diff-chg">adding
+</ins>
+them
+to
+the
+list
+of
+members
+of
+a
+container.
+It
+goes
+on
+to
+explain
+how
+to
+learn
+about
+a
+set
+of
+related
+resources,
+<ins class="diff-new">regardless
+of
+how
+</ins>
+they
+<del class="diff-old">may
+have
+been
+</del>
+<ins class="diff-chg">were
+</ins>
+created
+<del class="diff-old">using
+POST
+</del>
+or
+<del class="diff-old">through
+other
+means.
+</del>
+<ins class="diff-chg">added
+to
+the
+container's
+membership.
+</ins>
+It
+also
+defines
+behavior
+when
+<del class="diff-old">POST
+created
+</del>
+resources
+<del class="diff-old">are
+deleted,
+to
+clean
+up
+</del>
+<ins class="diff-chg">created
+using
+a
+</ins>
+container
+<del class="diff-old">membership,
+and
+</del>
+<ins class="diff-chg">are
+later
+deleted;
+</ins>
+deleting
+containers
+removes
+membership
+information
+and
+possibly
+<del class="diff-old">perform
+</del>
+<ins class="diff-chg">performs
+</ins>
+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>
+<del class="diff-old"># The following is the representation of
+# http://example.org/container1/
+</del>
+<pre class="example" id="ldpc-ex-simple">
+<ins class="diff-chg"># The following is the representation of
+# http://example.org/c1/
+# @base <http://example.org/c1/>
+</ins>
+@prefix dcterms: <http://purl.org/dc/terms/>.
+<del class="diff-old">@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+</del>
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+<>
+<del class="diff-old"> a ldp:Container;
+ ldp:membershipSubject <>
+ ldp:membershipPredicate rdfs:member;
+ ldp:membershipObject ldp:MemberSubject;
+ dcterms:title "A very simple container";
+
+rdfs:member
+<member1>,
+<member2>,
+<member3>.
+</del>
+<ins class="diff-chg"> a ldp:Container, ldp:BasicContainer;
+ dcterms:title "A very simple container";
+ ldp:contains <r1>, <r2>, <r3>.
+</ins>
+</pre>
+<figure id="fig-ldpc-basic">
+<img src="images/ldpc-basic.png" alt="Sample Linked Data Platform Basic Container" />
+<figcaption>
+<ins class="diff-chg">Sample
+of
+Linked
+Data
+Platform
+Basic
+Container
+</ins></figcaption></figure>
+<p>
+This
+example
+is
+very
+straightforward
+-
+the
+membership
+<ins class="diff-new">and
+containment
+</ins>
+predicate
+<del class="diff-old">is
+</del>
+<ins class="diff-chg">are
+both
+</ins>
+<code>
+<del class="diff-old">rdfs:member
+</del>
+<ins class="diff-chg">ldp:contains
+</ins>
+</code>
+and
+the
+<ins class="diff-new">other
+consistent
+</ins>
+membership
+<del class="diff-old">subject
+</del>
+<ins class="diff-chg">value
+</ins>
+is
+the
+<del class="diff-old">container
+itself.
+</del>
+<ins class="diff-chg">container's
+URI,
+occurring
+in
+the
+subject
+position
+of
+the
+triples.
+</ins>
+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.
+<ins class="diff-new">This
+type
+of
+container
+is
+also
+refered
+to
+as
+</ins><a title="Linked Data Platform Basic Container"><ins class="diff-new">
+LDP
+Basic
+Container
+</ins></a>.
+</p>
+<p>
+Sometimes
+it
+is
+useful
+to
+use
+a
+subject
+other
+than
+the
+container
+itself
+as
+the
+<ins class="diff-new">consistent
+</ins>
+membership
+<del class="diff-old">subject
+and
+</del>
+<ins class="diff-chg">value,
+and/or
+</ins>
+to
+use
+a
+predicate
+<del class="diff-old">other
+than
+rdfs:member
+</del>
+<ins class="diff-chg">from
+an
+application's
+domain
+model
+</ins>
+as
+the
+membership
+predicate.
+Let's
+start
+with
+a
+domain
+resource
+for
+a
+person's
+net
+worth,
+as
+illustrated
+below:
+</p>
+<del class="diff-old"># The following is a partial representation of
+# http://example.org/netWorth/nw1
+</del>
+<pre class="example" id="ldpc-ex-membership-partial">
+<ins class="diff-chg"># The following is a partial representation of
+# http://example.org/netWorth/nw1
+# @base <http://example.org/netWorth/nw1/>
+</ins>
+@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>,
+<del class="diff-old"><liabilityContainer/l3>.
+</del>
+<ins class="diff-chg"> <liabilityContainer/l3>.
+</ins>
+</pre>
+<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
+<ins class="diff-new">in
+the
+3
+examples
+</ins>
+below:
+</p>
+<del class="diff-old"># The following is an elaborated representation of
+# http://example.org/netWorth/nw1/
+</del>
+<pre class="example" id="ldpc-ex-membership-full">
+<ins class="diff-chg"># The following is an elaborated representation of LDPR
+# http://example.org/netWorth/nw1
+# @base <http://example.org/netWorth/nw1/>.
+</ins>
+@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>.
+</pre>
+<pre class="example" id="ldpc-ex-membership-subj">
+<ins class="diff-new"># The following is an elaborated representation of LDPC
+# http://example.org/netWorth/nw1/assetContainer/
+</ins>
+<del class="diff-old"><assetContainer/>
+ a ldp:Container;
+</del>
+<ins class="diff-chg"># @base <http://example.org/netWorth/nw1/assetContainer/>
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix o: <http://example.org/ontology/>.
+<>
+ a ldp:Container, ldp:DirectContainer;
+</ins>
+ dcterms:title "The assets of JohnZSmith";
+<del class="diff-old"> ldp:membershipSubject <>;
+ ldp:membershipPredicate o:asset;
+ ldp:membershipObject ldp:MemberSubject.
+</del>
+<ins class="diff-chg"> ldp:containerResource <>;
+ ldp:containsRelation o:asset;
+ ldp:contains <a1>, <a2>.
+</ins></pre><pre class="example" id="ldpc-ex-membership-full-liabcont"><ins class="diff-chg">
+# The following is an elaborated representation of LDPC
+# http://example.org/netWorth/nw1/liabilityContainer/
+</ins>
+<del class="diff-old"><liabilityContainer/>
+ a ldp:Container;
+</del>
+<ins class="diff-chg"># @base <http://example.org/netWorth/nw1/liabilityContainer/>
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix o: <http://example.org/ontology/>.
+<>
+ a ldp:Container, ldp:DirectContainer;
+</ins>
+ dcterms:title "The liabilities of JohnZSmith";
+<del class="diff-old"> ldp:membershipSubject <>;
+ ldp:membershipPredicate o:liability;
+ldp:membershipObject
+ldp:MemberSubject.
+</del>
+<ins class="diff-chg"> ldp:containerResource <>;
+ ldp:containsRelation o:liability;
+ ldp:contains <l1>, <l2>, <l3>.
+</ins>
+</pre>
+<p>
+The
+essential
+structure
+of
+the
+container
+is
+the
+same,
+but
+in
+this
+example,
+the
+<ins class="diff-new">consistent
+</ins>
+membership
+<ins class="diff-new">value
+(still
+in
+the
+</ins>
+subject
+<ins class="diff-new">position)
+</ins>
+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
+<ins class="diff-new">resource
+and
+containment
+triple
+to
+the
+</ins>
+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>
+<del class="diff-old"># 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>.
+</del>
+<p>
+<del class="diff-old">In
+this
+example,
+clients
+cannot
+simply
+guess
+which
+resource
+</del>
+<ins class="diff-chg">This
+type
+of
+container
+is
+refered
+to
+as
+an
+</ins><a title="Linked Data Platform Direct Container"><ins class="diff-chg">
+LDP
+Direct
+Container
+</ins></a>.<ins class="diff-chg">
+An
+</ins><a title="Linked Data Platform Basic Container"><ins class="diff-chg">
+LDP
+Basic
+Container
+</ins></a>
+is
+<ins class="diff-new">a
+constrained
+form
+of
+</ins><a title="Linked Data Platform Direct Container"><ins class="diff-new">
+LDP
+Direct
+Container
+</ins></a><ins class="diff-new">
+where
+</ins>
+the
+membership
+<del class="diff-old">subject
+and
+which
+</del>
+predicate
+is
+<code>
+<ins class="diff-new">ldp:contains
+</ins></code><ins class="diff-new">
+and
+the
+container
+resource
+is
+the
+container
+itself.
+</ins></p><p><ins class="diff-new">
+As
+seen
+in
+the
+</ins><a href="#ldpc-ex-membership-subj"><code><ins class="diff-new">
+assetContainer/
+</ins></code><ins class="diff-new">
+example
+</ins></a>,<ins class="diff-new">
+clients
+cannot
+correctly
+guess
+at
+</ins>
+the
+membership
+<del class="diff-old">predicate,
+</del>
+<ins class="diff-chg">triples,
+</ins>
+so
+the
+example
+includes
+this
+information
+in
+triples
+whose
+subject
+is
+the
+LDPC
+resource
+itself.
+</p>
+<del class="diff-old">5.1.1
+Container
+Member
+Information
+</del>
+<p>
+<del class="diff-old">In
+many
+–
+perhaps
+most
+–
+applications
+involving
+containers,
+it
+is
+desirable
+</del>
+<ins class="diff-chg">Alternatively,
+servers
+may
+provide
+the
+net
+worth
+resource
+and
+supporting
+containers
+in
+a
+single
+response
+representations.
+When
+doing
+this,
+a
+preference
+would
+be
+for
+RDF
+formats
+that
+support
+multiple
+named
+graphs,
+one
+named
+graph
+</ins>
+for
+the
+<del class="diff-old">client
+</del>
+<ins class="diff-chg">net
+worth
+resource
+and
+then
+two
+others
+for
+asset
+and
+liability
+containers.
+This
+allows
+for
+the
+membership
+triples
+</ins>
+to
+be
+<del class="diff-old">able
+to
+get
+information
+about
+each
+container
+member
+without
+having
+</del>
+<ins class="diff-chg">represented
+with
+the
+named
+graph
+for
+the
+net
+worth
+resource,
+while
+the
+containment
+triples
+would
+be
+represented
+within
+the
+liability
+and
+asset
+containers
+[[rdf11-concepts]].
+Generally,
+the
+membership
+triples
+belong
+</ins>
+to
+<del class="diff-old">do
+</del>
+<ins class="diff-chg">the
+representation
+of
+</ins>
+a
+<del class="diff-old">GET
+on
+each
+one.
+LDPC
+allows
+servers
+</del>
+<ins class="diff-chg">LDP-RR
+and
+the
+containment
+triples
+belong
+</ins>
+to
+<del class="diff-old">include
+this
+information
+directly
+in
+</del>
+the
+representation
+of
+the
+<del class="diff-old">container.
+The
+server
+decides
+</del>
+<ins class="diff-chg">LDPC.
+</ins></p><p><ins class="diff-chg">
+Additionally,
+we
+could
+extend
+our
+net
+worth
+example
+to
+include
+a
+container
+for
+advisors
+(people)
+that
+have
+managed
+</ins>
+the
+<del class="diff-old">amount
+</del>
+<ins class="diff-chg">assets
+and
+liabilities.
+We
+have
+decided
+to
+identify
+these
+advisors
+with
+URLs
+that
+contain
+a
+fragment
+(hash)
+to
+represent
+these
+real-world
+resources,
+not
+the
+documents
+that
+describe
+them.
+</ins></p><pre class="example" id="ldpc-ex-membership-full"><ins class="diff-chg">
+# The following is an elaborated representation of
+# http://example.org/netWorth/nw1
+# Adding o:advisor but eaving off o:asset and o:liability for brevity.
+# @base <http://example.org/netWorth/nw1/>
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix foaf: <http://xmlns.com/foaf/0.1/>.
+@prefix o: <http://example.org/ontology/>.
+<>
+ a o:NetWorth;
+ o:netWorthOf <http://example.org/users/JohnZSmith>;
+ o:advisor
+ <advisorContainer/bob#me>,
+ <advisorContainer/marsha#me>.
+
+<advisorContainer/>
+ a ldp:Container, ldp:IndirectContainer;
+ dcterms:title "The asset advisors of JohnZSmith";
+ ldp:containerResource <>;
+ ldp:containsRelation o:advisor;
+ ldp:insertedContentRelation foaf:primaryTopic;
+ ldp:contains
+ <advisorContainer/bob>,
+ <advisorContainer/marsha>.
+</ins></pre><p><ins class="diff-chg">
+To
+handle
+this
+type
+</ins>
+of
+<del class="diff-old">data
+about
+each
+member
+</del>
+<ins class="diff-chg">indirection,
+the
+triple
+with
+predicate
+of
+</ins><code><ins class="diff-chg">
+ldp:insertedContentRelation
+</ins></code><ins class="diff-chg">
+and
+object
+of
+</ins><code><ins class="diff-chg">
+foaf:primaryTopic
+</ins></code><ins class="diff-chg">
+informs
+clients
+</ins>
+that
+<del class="diff-old">is
+provided.
+Some
+common
+strategies
+</del>
+<ins class="diff-chg">when
+POSTing
+to
+this
+container,
+they
+need
+to
+</ins>
+include
+<del class="diff-old">providing
+</del>
+a
+<del class="diff-old">fixed
+number
+</del>
+<ins class="diff-chg">triple
+</ins>
+of
+<del class="diff-old">standard
+properties,
+or
+providing
+</del>
+the
+<del class="diff-old">entire
+RDF
+representation
+</del>
+<ins class="diff-chg">form
+</ins><code><ins class="diff-chg">
+(<>,
+foaf:primaryTopic,
+topic-URI)
+</ins></code><ins class="diff-chg">
+to
+inform
+the
+server
+which
+URI
+to
+use
+(
+</ins><code><ins class="diff-chg">
+topic-URI
+</ins></code><ins class="diff-chg">
+)
+in
+the
+new
+membership
+triple.
+</ins></p><p><ins class="diff-chg">
+This
+type
+</ins>
+of
+<del class="diff-old">each
+</del>
+<ins class="diff-chg">container
+is
+also
+referred
+to
+as
+an
+</ins><a title="Linked Data Platform Indirect Container"><ins class="diff-chg">
+LDP
+Indirect
+Container
+</ins></a>.<ins class="diff-chg">
+It
+is
+similar
+to
+a
+an
+</ins><a title="Linked Data Platform Direct Container"><ins class="diff-chg">
+LDP
+Direct
+Container
+</ins></a><ins class="diff-chg">
+but
+it
+provides
+an
+indirection
+to
+add
+(via
+a
+create
+request)
+as
+</ins>
+member
+<ins class="diff-new">any
+</ins>
+resource,
+<del class="diff-old">or
+providing
+nothing.
+The
+server
+application
+domain
+and
+its
+use-cases
+will
+determine
+how
+much
+information
+</del>
+<ins class="diff-chg">such
+as
+a
+URI
+representing
+a
+real-world
+object,
+that
+</ins>
+is
+<del class="diff-old">required.
+</del>
+<ins class="diff-chg">different
+from
+the
+document
+that
+is
+created.
+</ins>
+</p>
+<p>
+<del class="diff-old">Continuing
+on
+from
+</del>
+<a href="#fig-ldpc-types">
+</a>
+<ins class="diff-chg">illustrates
+</ins>
+the
+<del class="diff-old">net
+worth
+example,
+</del>
+<ins class="diff-chg">3
+types:
+Basic,
+Direct
+and
+Indirect,
+along
+with
+their
+relationship
+to
+types
+of
+LDPRs.
+It
+is
+not
+expected
+that
+</ins>
+there
+will
+be
+<del class="diff-old">additional
+triples
+for
+the
+member
+resources
+(assets)
+in
+the
+representation:
+</del>
+<ins class="diff-chg">a
+container
+with
+a
+</ins><code><ins class="diff-chg">
+rdf:type
+</ins></code><ins class="diff-chg">
+solely
+of
+</ins><code><ins class="diff-chg">
+ldp:Container
+</ins></code>.
+</p>
+<del class="diff-old"># 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.
+</del>
+<figure id="fig-ldpc-types">
+<img src="images/ldpc1.png" alt="Types of Linked Data Platform Containers" />
+<figcaption>
+<ins class="diff-chg">Types
+of
+Linked
+Data
+Platform
+Containers
+</ins></figcaption></figure><div class="ldp-issue-pending">
+<p>
+<del class="diff-old">In
+a
+similar
+manner,
+when
+the
+representation
+for
+</del>
+<ins class="diff-chg">PENDING
+--
+table
+work
+in
+progress,
+if
+found
+valuable...we'll
+keep.
+</ins></p><p><ins class="diff-chg">
+The
+following
+table
+illustrates
+some
+differences
+between
+</ins><a title="membership"><ins class="diff-chg">
+membership
+</ins></a><ins class="diff-chg">
+and
+</ins><a title="containment"><ins class="diff-chg">
+containment
+</ins></a><ins class="diff-chg">
+triples.
+For
+details
+on
+</ins>
+the
+<del class="diff-old">resource
+</del>
+<ins class="diff-chg">normative
+behavior,
+see
+appropriate
+sections
+below.
+</ins></p><table border="1" id="ldpc-mbrcntdiff"><thead><tr><th rowspan="2"><ins class="diff-chg">
+Completed
+Request
+</ins></th><th colspan="2"><ins class="diff-chg">
+Effects
+</ins></th></tr><tr><th><ins class="diff-chg">
+Membership
+</ins></th><th><ins class="diff-chg">
+Containment
+</ins></th></tr></thead><tr><td><ins class="diff-chg">
+LDPR
+created
+in
+LDPC
+(any
+subtype)
+</ins></td><td><ins class="diff-chg">
+New
+triple
+based
+on
+type
+</ins>
+of
+<del class="diff-old">asset
+.../<a1>
+is
+returned
+a
+server
+</del>
+<ins class="diff-chg">container
+(see
+following
+rows)
+</ins></td><td><ins class="diff-chg">
+New
+triple:
+(LDPC,
+ldp:contains,
+LDPR)
+</ins></td></tr><tr><td><ins class="diff-chg">
+LDPR
+created
+in
+LDP-BC
+</ins></td><td><ins class="diff-chg">
+New
+triple:
+(LDPC,
+ldp:contains,
+LDPR)
+</ins></td><td><ins class="diff-chg">
+Same
+</ins></td></tr><tr><td><ins class="diff-chg">
+LDPR
+created
+in
+LDP-DC
+</ins></td><td><ins class="diff-chg">
+New
+triple
+links
+LDP-RR
+to
+created
+LDPR.
+LDP-RR
+URI
+</ins>
+may
+<del class="diff-old">include
+the
+membership
+</del>
+<ins class="diff-chg">be
+same
+as
+LDP-DC
+</ins></td><td><ins class="diff-chg">
+New
+triple:
+(LDPC,
+ldp:contains,
+LDPR)
+</ins></td></tr><tr><td><ins class="diff-chg">
+LDPR
+created
+in
+LDP-IC
+</ins></td><td><ins class="diff-chg">
+New
+</ins>
+triple
+<ins class="diff-new">links
+LDP-RR
+to
+content
+indicated
+URI
+</ins></td><td><ins class="diff-new">
+New
+triple:
+(LDPC,
+ldp:contains,
+LDPR)
+</ins></td></tr><tr><td><ins class="diff-new">
+LDPR
+is
+deleted
+</ins></td><td><ins class="diff-new">
+Triples
+may
+be
+removed
+</ins></td><td><ins class="diff-new">
+Triples
+are
+removed
+</ins></td></tr><tr><td><ins class="diff-new">
+LDPC
+is
+deleted
+</ins></td><td><ins class="diff-new">
+Triples
+and
+member
+resources
+may
+be
+removed
+</ins></td><td><ins class="diff-new">
+Triples
+</ins>
+of
+<del class="diff-old">the
+</del>
+form
+<del class="diff-old">(.../nw1,
+o:asset,
+.../a1).
+5.1.2 Retrieving
+Only
+Non-member
+Properties
+</del>
+<ins class="diff-chg">(LDPC,
+ldp:contains,
+LDPR)
+and
+contained
+LDPRs
+may
+be
+removed
+</ins></td></tr></table>
+</div>
+<section id="ldpc-get_empty-container_props">
+<h2 class="normal">
+<ins class="diff-new">Retrieving
+Only
+Empty-Container
+Triples
+</ins></h2>
+<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
+<del class="diff-old">non-member
+</del>
+<ins class="diff-chg">subset
+of
+the
+container's
+</ins>
+properties
+<ins class="diff-new">that
+are
+unrelated
+to
+member
+resources
+and
+unrelated
+to
+contained
+documents,
+for
+example
+to
+determine
+the
+membership
+triple
+pattern
+and
+membership
+predicate
+</ins>
+of
+<ins class="diff-new">a
+LDP-DC.
+LDP
+calls
+these
+</ins><a title="Empty-container triples"><ins class="diff-new">
+empty-container
+triples
+</ins></a>,<ins class="diff-new">
+because
+they
+are
+what
+remains
+when
+</ins>
+the
+<del class="diff-old">container.
+</del>
+<ins class="diff-chg">container
+has
+zero
+members
+and
+zero
+contained
+resources.
+</ins>
+Since
+retrieving
+the
+whole
+container
+representation
+to
+get
+this
+information
+may
+be
+onerous
+for
+clients
+and
+cause
+unnecessary
+overhead
+on
+servers,
+<del class="diff-old">it
+is
+desired
+to
+</del>
+<ins class="diff-chg">we
+</ins>
+define
+a
+way
+to
+retrieve
+only
+<del class="diff-old">the
+non-member
+</del>
+<ins class="diff-chg">these
+</ins>
+property
+<del class="diff-old">values.
+Defining
+for
+each
+LDPC
+</del>
+<ins class="diff-chg">values
+(and
+more
+generally,
+</ins>
+a
+<del class="diff-old">corresponding
+resource,
+called
+</del>
+<ins class="diff-chg">way
+to
+retrieve
+only
+</ins>
+the
+<del class="diff-old">“
+non-member
+resource
+”,
+whose
+state
+is
+a
+</del>
+subset
+of
+<del class="diff-old">the
+state
+</del>
+<ins class="diff-chg">properties
+used
+to
+address
+other
+major
+clusters
+</ins>
+of
+<ins class="diff-new">use
+cases).
+LDP
+adds
+parameters
+to
+</ins>
+the
+<del class="diff-old">container,
+does
+this.
+</del>
+<ins class="diff-chg">HTTP
+</ins><code><ins class="diff-chg">
+Prefer
+</ins></code><ins class="diff-chg">
+header's
+</ins><code><ins class="diff-chg">
+return=representation
+</ins></code><ins class="diff-chg">
+preference
+for
+this
+(see
+</ins><a href= "#prefer-parameters" class="sectionRef"></a><ins class="diff-chg">
+for
+details).
+</ins>
+</p>
+<p>
+The
+example
+listed
+here
+only
+<del class="diff-old">show
+</del>
+<ins class="diff-chg">shows
+</ins>
+a
+simple
+case
+where
+<del class="diff-old">only
+a
+</del>
+few
+<del class="diff-old">simple
+non-member
+properties
+</del>
+<ins class="diff-chg">empty-container
+triples
+</ins>
+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
+SPARQL
+endpoints.
+<del class="diff-old">[
+SPARQL-QUERY
+]
+</del>
+<ins class="diff-chg">[[SPARQL-QUERY]]
+</ins>
+</p>
+<p>
+Here
+is
+an
+example
+requesting
+the
+<del class="diff-old">non-member
+properties
+</del>
+<ins class="diff-chg">empty-container
+triples
+</ins>
+of
+a
+container
+identified
+by
+the
+URL
+<code>
+http://example.org/container1/
+</code>.
+<del class="diff-old">In
+this
+case,
+the
+non-member
+resource
+is
+identified
+by
+the
+URL
+http://example.org/container1?non-member-properties
+:
+</del>
+</p>
+<p id="ldpc-ex-empty-container">
+Request:
+</p>
+<del class="diff-old">GET /container1?non-member-properties HTTP/1.1
+</del>
+<pre class="example">
+<ins class="diff-chg">GET /container1 HTTP/1.1
+</ins>
+Host: example.org
+<del class="diff-old">Accept:
+text/turtle;
+charset=UTF-8
+</del>
+<ins class="diff-chg">Accept: text/turtle; charset=UTF-8
+Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferEmptyContainer"
+</ins>
+</pre>
+<p>
+Response:
+</p>
+<del class="diff-old">HTTP/1.1 200 OK
+</del>
+<pre class="example">
+<ins class="diff-chg">HTTP/1.1 200 OK
+</ins>
+Content-Type: text/turtle; charset=UTF-8
+ETag: "_87e52ce291112"
+Content-Length: 325
+<ins class="diff-new">Link: <http://www.w3.org/ns/ldp/Container>; rel="type"
+Preference-Applied: return=representation
+</ins>
+<del class="diff-old">@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+</del>
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+<http://example.org/container1/>
+<del class="diff-old"> 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/>.
+</del>
+<ins class="diff-chg"> a ldp:Container, ldp:DirectContainer;
+ dcterms:title "A Linked Data Platform Container of Acme Resources";
+ ldp:containerResource <http://example.org/container1/>;
+ ldp:containsRelation ldp:member;
+ ldp:insertedContentRelation ldp:MemberSubject;
+ dcterms:publisher <http://acme.com/>.
+</ins>
+</pre>
+<p>
+<del class="diff-old">While
+the
+same
+non-member
+resource
+could
+be
+used
+to
+update
+the
+non-member
+properties
+via
+PUT,
+</del>
+LDP
+recommends
+using
+PATCH
+<ins class="diff-new">to
+update
+these
+properties,
+if
+necessary.
+It
+provides
+no
+facility
+</ins>
+for
+<del class="diff-old">this
+purpose.
+</del>
+<ins class="diff-chg">updating
+them
+via
+PUT
+without
+replacing
+the
+entire
+container's
+state.
+</ins>
+</p>
+<del class="diff-old">5.1.3
+</del>
+</section>
+<section id="ldpc-ordering">
+<h2 class="normal">
+Ordering
+</h2>
+<p>
+There
+are
+many
+cases
+where
+an
+ordering
+of
+the
+members
+of
+the
+container
+is
+important.
+LDPC
+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,
+LDPC
+avoids
+the
+use
+of
+RDF
+constructs
+like
+Seq
+and
+List
+for
+expressing
+order.
+</p>
+<p>
+Order
+becomes
+more
+important
+for
+<del class="diff-old">LDPC
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+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
+LDPC
+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
+<del class="diff-old">higher
+</del>
+sort
+order
+<ins class="diff-new">no
+lower
+</ins>
+than
+all
+members
+on
+the
+previous
+page
+and
+<del class="diff-old">lower
+</del>
+sort
+order
+<ins class="diff-new">no
+higher
+</ins>
+than
+all
+the
+members
+on
+the
+next
+<del class="diff-old">page.
+</del>
+<ins class="diff-chg">page;
+that
+is,
+it
+proceeds
+from
+low
+to
+high,
+but
+keep
+in
+mind
+that
+several
+consecutive
+pages
+might
+have
+members
+whose
+sort
+criteria
+are
+equal.
+</ins>
+When
+the
+sort
+is
+descending,
+the
+opposite
+order
+is
+used.
+Since
+more
+than
+one
+value
+may
+be
+used
+to
+sort
+members,
+the
+LDPC
+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>
+<del class="diff-old"># The following is the ordered representation of
+</del>
+<pre class="example" id="ldpc-ex-ordering">
+<ins class="diff-chg"># The following is the ordered representation of
+</ins>
+# http://example.org/netWorth/nw1/assetContainer/
+<ins class="diff-new"># @base <http://example.org/netWorth/nw1/assetContainer/>
+</ins>
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix o: <http://example.org/ontology/>.
+<>
+<del class="diff-old"> a ldp:Container;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:membershipSubject <http://example.org/netWorth/nw1>;
+ ldp:membershipPredicate o:asset;
+ ldp:membershipObject ldp:MemberSubject.
+</del>
+<ins class="diff-chg"> a ldp:Container, ldp:DirectContainer;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:containerResource <http://example.org/netWorth/nw1>;
+ ldp:containsRelation o:asset;
+ ldp:insertedContentRelation ldp:MemberSubject.
+</ins>
+<?firstPage>
+ a ldp:Page;
+<del class="diff-old"> ldp:pageOf <>;
+ ldp:containerSortCriteria (#SortValueAscending).
+</del>
+<ins class="diff-chg"> ldp:pageOf <>;
+ ldp:containerSortCriteria (<#SortValueAscending>).
+</ins>
+<#SortValueAscending>
+ a ldp:ContainerSortCriterion;
+<del class="diff-old"> ldp:containerSortOrder ldp:Ascending;
+</del>
+<ins class="diff-chg"> ldp:containerSortOrder ldp:Ascending;
+</ins>
+ ldp:containerSortPredicate o:value.
+<http://example.org/netWorth/nw1>
+<del class="diff-old"> a o:NetWorth;
+</del>
+<ins class="diff-chg"> a o:NetWorth;
+</ins>
+ o:asset <a1>, <a3>, <a2>.
+<a1>
+<del class="diff-old"> a o:Stock;
+ o:value 100.00.
+</del>
+<ins class="diff-chg"> a o:Stock;
+ o:value 100.00 .
+</ins>
+<a2>
+<del class="diff-old"> a o:Cash;
+ o:value 50.00.
+</del>
+<ins class="diff-chg"> a o:Cash;
+ o:value 50.00 .
+</ins>
+<a3>
+<del class="diff-old"> a o:RealEstateHolding;
+
+ o:value
+300000.
+</del>
+<ins class="diff-chg"> a o:RealEstateHolding;
+ o:value 300000 .
+</ins>
+</pre>
+<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.
+<del class="diff-old"> It
+</del>
+<ins class="diff-chg"> It
+</ins>
+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.
+<ins class="diff-new">Also
+as
+it
+is
+possible
+for
+a
+container
+to
+have
+as
+its
+members
+other
+containers,
+the
+ordering
+approach
+doesn't
+change
+as
+containers
+themselves
+are
+LDPRs
+and
+the
+properties
+from
+the
+domain
+model
+can
+be
+leveraged
+for
+the
+sort
+criteria.
+</ins>
+</p>
+</section>
+<del class="diff-old">5.2
+</del>
+</section>
+<section id="ldpc-general">
+<h2>
+General
+</h2>
+<p>
+The
+Linked
+Data
+Platform
+does
+not
+define
+how
+clients
+discover
+<dfn>
+<abbr title="Linked Data Platform Containers">
+LDPCs
+</abbr>
+</dfn>.
+</p>
+<del class="diff-old">5.2.1
+LDPC
+servers
+MUST
+also
+be
+conformant
+LDPR
+servers.
+A
+</del>
+<section id="ldpc-isldpr">
+<h2 class="normal">
+<ins class="diff-chg">Each
+</ins>
+Linked
+Data
+Platform
+Container
+MUST
+also
+be
+a
+<del class="diff-old">conformant
+</del>
+<ins class="diff-chg">conforming
+</ins><a title="">
+Linked
+Data
+Platform
+<del class="diff-old">Resource.
+5.2.2
+LDPC
+membership
+is
+not
+exclusive;
+this
+means
+that
+the
+same
+resource
+(
+LDPR
+or
+not)
+which
+is
+identified
+by
+its
+canonical
+URI,
+MAY
+be
+</del>
+<ins class="diff-chg">RDF
+Resource
+</ins></a>.</h2></section><section id="ldpc-typecontainer"><h2 class="normal"><ins class="diff-chg">
+The
+representation
+of
+</ins>
+a
+<del class="diff-old">member
+</del>
+<ins class="diff-chg">LDPC
+MUST
+have
+an
+</ins><code><ins class="diff-chg">
+rdf:type
+</ins></code>
+of
+<del class="diff-old">more
+than
+</del>
+<ins class="diff-chg">only
+</ins>
+one
+<ins class="diff-chg">of:
+</ins></h2><ul><li><code><ins class="diff-chg">
+ldp:BasicContainer
+</ins></code><ins class="diff-chg">
+for
+</ins><a title=""><ins class="diff-chg">
+Linked
+Data
+Platform
+Basic
+Container
+</ins></a></li><li><code><ins class="diff-chg">
+ldp:DirectContainer
+</ins></code><ins class="diff-chg">
+for
+</ins><a title=""><ins class="diff-chg">
+Linked
+Data
+Platform
+Direct
+Container
+</ins></a></li><li><code><ins class="diff-chg">
+ldp:IndirectContainer
+</ins></code><ins class="diff-chg">
+for
+</ins><a title=""><ins class="diff-chg">
+Linked
+Data
+Platform
+Indirect
+Container
+</ins></a></li></ul><ins class="diff-chg">
+Non-normative
+note:
+</ins><a href="#ldp-rdfconcepts-extra-triples-types"><ins class="diff-chg">
+LDPCs
+might
+have
+additional
+types
+</ins></a>,<ins class="diff-chg">
+like
+any
+RDF
+resource.
+</ins></section><section id="ldpc-nordfcontainertypes"><h2 class="normal">
+LDPC
+<del class="diff-old">.
+5.2.3
+</del>
+<ins class="diff-chg">representations
+SHOULD
+NOT
+use
+RDF
+container
+types
+</ins><code><ins class="diff-chg">
+rdf:Bag
+</ins></code>,<code><ins class="diff-chg">
+rdf:Seq
+</ins></code><ins class="diff-chg">
+or
+</ins><code><ins class="diff-chg">
+rdf:List
+</ins></code>.</h2></section><section id="ldpc-mbrpred"><h2 class="normal"><a title="Linked Data Platform Direct Container"><ins class="diff-chg">
+LDP
+Direct
+Containers
+</ins></a><ins class="diff-chg">
+and
+</ins><a title="Linked Data Platform Indirect Container"><ins class="diff-chg">
+LDP
+Indirect
+Containers
+</ins></a><ins class="diff-chg">
+SHOULD
+use
+the
+</ins><code><ins class="diff-chg">
+ldp:member
+</ins></code><ins class="diff-chg">
+predicate
+as
+an
+LDPC's
+</ins><a title="Membership predicate"><ins class="diff-chg">
+membership
+predicate
+</ins></a><ins class="diff-chg">
+if
+there
+is
+no
+obvious
+predicate
+from
+an
+application
+vocabulary
+to
+use
+(
+</ins><a title="Linked Data Platform Basic Container"><ins class="diff-chg">
+LDP-BCs
+</ins></a><a href="#ldpc-containtriple-basic"><ins class="diff-chg">
+always
+use
+</ins><code><ins class="diff-chg">
+ldp:contains
+</ins></code></a><ins class="diff-chg">
+).
+</ins>
+The
+state
+of
+an
+LDPC
+includes
+information
+about
+which
+resources
+are
+its
+<del class="diff-old">members.
+In
+the
+simplest
+cases,
+</del>
+<ins class="diff-chg">members,
+in
+</ins>
+the
+<ins class="diff-new">form
+of
+</ins><a title="Membership triples">
+membership
+<del class="diff-old">subject
+will
+be
+the
+LDPC
+resource
+itself,
+but
+it
+does
+not
+have
+to
+be.
+</del>
+<ins class="diff-chg">triples
+</ins></a><ins class="diff-chg">
+that
+follow
+a
+consistent
+pattern.
+</ins>
+The
+<ins class="diff-new">LDPC's
+state
+contains
+enough
+information
+for
+clients
+to
+discern
+the
+</ins><a title="Membership predicate">
+membership
+predicate
+<del class="diff-old">is
+also
+variable
+and
+will
+often
+be
+a
+predicate
+from
+</del>
+</a>,
+the
+<del class="diff-old">server
+application
+vocabulary.
+If
+there
+is
+no
+obvious
+predicate
+from
+</del>
+<ins class="diff-chg">other
+consistent
+membership
+value
+used
+in
+</ins>
+the
+<del class="diff-old">server
+application
+vocabulary
+to
+use,
+LDPC
+servers
+SHOULD
+use
+</del>
+<ins class="diff-chg">container's
+membership
+triples
+(
+</ins><var><ins class="diff-chg">
+membership-constant-URI
+</ins></var><ins class="diff-chg">
+),
+and
+</ins>
+the
+<del class="diff-old">rdfs:member
+predicate.
+</del>
+<ins class="diff-chg">position
+(subject
+or
+object)
+where
+those
+URIs
+occurs
+in
+the
+</ins><a title="Membership triples"><ins class="diff-chg">
+membership
+triples
+</ins></a>.
+Member
+resources
+can
+be
+any
+kind
+of
+resource
+identified
+by
+<del class="diff-old">its
+</del>
+<ins class="diff-chg">a
+</ins>
+URI,
+LDPR
+or
+otherwise.
+<del class="diff-old">5.2.4
+An
+LDPC
+</del>
+</h2>
+</section>
+<section id="ldpc-containres">
+<h2 class="normal">
+<ins class="diff-chg">Each
+</ins><a title="Linked Data Platform Direct Container"><ins class="diff-chg">
+LDP
+Direct
+Container
+</ins></a><ins class="diff-chg">
+and
+</ins><a title="Linked Data Platform Indirect Container"><ins class="diff-chg">
+LDP
+Indirect
+Container
+</ins></a>
+representation
+MUST
+contain
+exactly
+one
+triple
+whose
+subject
+is
+the
+LDPC
+URI,
+whose
+predicate
+is
+the
+<code>
+<del class="diff-old">ldp:membershipSubject
+</del>
+<ins class="diff-chg">ldp:containerResource
+</ins>
+</code>,
+and
+whose
+object
+is
+the
+<del class="diff-old">LDPC
+'s
+membership
+</del>
+<ins class="diff-chg">LDPC's
+</ins><var><ins class="diff-chg">
+membership-constant-URI
+</ins></var>.<ins class="diff-chg">
+Commonly
+the
+LDPC's
+URI
+is
+the
+</ins><var><ins class="diff-chg">
+membership-constant-URI
+</ins></var>,<ins class="diff-chg">
+but
+LDP
+does
+not
+require
+this.
+</ins></h2><section id="ldpc-containres-basic"><h2 class="normal"><a title="Linked Data Platform Basic Container"><ins class="diff-chg">
+LDP-BCs
+</ins></a><ins class="diff-chg">
+MUST
+behave
+as
+if
+their
+state
+contains
+the
+triple
+whose
+</ins>
+subject
+<del class="diff-old">URI.
+5.2.5
+An
+</del>
+<ins class="diff-chg">is
+the
+</ins>
+LDPC
+<ins class="diff-chg">URI,
+whose
+predicate
+is
+</ins><code><ins class="diff-chg">
+ldp:containerResource
+</ins></code>,<ins class="diff-chg">
+and
+whose
+object
+is
+the
+LDPC
+URI
+(subject
+and
+object
+are
+the
+same
+URI),
+but
+there
+is
+no
+requirement
+to
+materialize
+this
+triple
+in
+LDP-BC
+representations.
+</ins></h2></section></section><section id="ldpc-containtriples"><h2 class="normal"><ins class="diff-chg">
+Each
+</ins><a title="Linked Data Platform Direct Container"><ins class="diff-chg">
+LDP
+Direct
+Container
+</ins></a><ins class="diff-chg">
+and
+</ins><a title="Linked Data Platform Indirect Container"><ins class="diff-chg">
+LDP
+Indirect
+Container
+</ins></a>
+representation
+MUST
+contain
+exactly
+one
+triple
+whose
+subject
+is
+the
+LDPC
+URI,
+and
+whose
+predicate
+is
+either
+<code>
+<del class="diff-old">ldp:membershipPredicate
+</del>
+<ins class="diff-chg">ldp:containsRelation
+</ins>
+</code>
+or
+<code>
+<del class="diff-old">ldp:membershipPredicateInverse
+</del>
+<ins class="diff-chg">ldp:containedByRelation
+</ins>
+</code>.
+The
+object
+of
+the
+triple
+is
+constrained
+by
+other
+sections,
+such
+as
+<del class="diff-old">5.2.5.1
+</del>
+<a href="#ldpc-containtriple-relation" class="sectionRef">
+<ins class="diff-chg">ldp:containsRelation
+</ins>
+</a>
+or
+<del class="diff-old">5.2.5.2
+.
+5.2.5.1
+For
+a
+given
+</del>
+<a href="#ldpc-containtriple-byrelation" class="sectionRef">
+<ins class="diff-chg">ldp:containedByRelation
+</ins></a>,<ins class="diff-chg">
+based
+on
+the
+</ins><a title="Membership triples"><ins class="diff-chg">
+membership
+triple
+</ins></a><ins class="diff-chg">
+pattern
+used
+by
+the
+container.
+</ins></h2><section id="ldpc-containtriple-relation"><h2 class="normal"><ins class="diff-chg">
+LDPCs
+(
+</ins><a title="Linked Data Platform Direct Container"><ins class="diff-chg">
+Direct
+</ins></a><ins class="diff-chg">
+and
+</ins><a title="Linked Data Platform Indirect Container"><ins class="diff-chg">
+Indirect
+</ins></a><ins class="diff-chg">
+Containers
+only)
+whose
+</ins><a title="Membership triples"><ins class="diff-chg">
+membership
+</ins>
+triple
+</a>
+<ins class="diff-new">pattern
+is
+</ins>
+<var>
+<del class="diff-old">T
+</del>
+<ins class="diff-chg">(
+membership-constant-URI
+,
+membership-predicate
+,
+member-derived-URI
+)
+</ins>
+</var>
+<del class="diff-old">with
+a
+</del>
+<ins class="diff-chg">MUST
+contain
+exactly
+one
+triple
+whose
+</ins>
+subject
+<del class="diff-old">C
+of
+</del>
+<ins class="diff-chg">is
+</ins>
+the
+LDPC
+<del class="diff-old">and
+</del>
+<ins class="diff-chg">URI,
+whose
+</ins>
+predicate
+<del class="diff-old">of
+</del>
+<ins class="diff-chg">is
+</ins>
+<code>
+<del class="diff-old">ldp:membershipPredicate
+</del>
+<ins class="diff-chg">ldp:containsRelation
+</ins>
+</code>,
+<del class="diff-old">the
+</del>
+<ins class="diff-chg">and
+whose
+</ins>
+object
+<del class="diff-old">MUST
+be
+</del>
+<ins class="diff-chg">is
+</ins>
+the
+URI
+of
+<del class="diff-old">the
+membership
+predicate
+</del>
+<var>
+<del class="diff-old">P
+used
+to
+indicate
+membership
+to
+</del>
+<ins class="diff-chg">membership-predicate
+</ins></var>.</h2><section id="ldpc-containtriple-basic"><h2 class="normal"><a title="Linked Data Platform Basic Container"><ins class="diff-chg">
+LDP-BCs
+</ins></a><ins class="diff-chg">
+MUST
+behave
+as
+if
+their
+state
+contains
+the
+triple
+whose
+subject
+is
+</ins>
+the
+<del class="diff-old">linked
+to
+</del>
+LDPC
+<del class="diff-old">,
+or
+simply:
+T
+=
+(
+C
+,
+</del>
+<ins class="diff-chg">URI,
+whose
+predicate
+is
+</ins>
+<code>
+<del class="diff-old">ldp:membershipPredicate
+</del>
+<ins class="diff-chg">ldp:containsRelation
+</ins>
+</code>,
+<del class="diff-old">P)
+.
+For
+the
+membership
+predicate
+URI
+</del>
+<ins class="diff-chg">and
+whose
+</ins>
+object
+<del class="diff-old">used
+in
+the
+</del>
+<ins class="diff-chg">is
+</ins><code><ins class="diff-chg">
+ldp:contains
+</ins></code>,<ins class="diff-chg">
+but
+there
+is
+no
+requirement
+to
+materialize
+this
+</ins>
+triple
+<del class="diff-old">T
+,
+it
+would
+be
+found
+</del>
+in
+<del class="diff-old">a
+resource's
+same
+subject
+R
+</del>
+<ins class="diff-chg">LDP-BC
+representations.
+</ins></h2></section></section><section id="ldpc-containtriple-byrelation"><h2 class="normal"><ins class="diff-chg">
+LDPCs
+(
+</ins><a title="Linked Data Platform Direct Container"><ins class="diff-chg">
+Direct
+</ins></a>
+and
+<del class="diff-old">same
+predicate
+P
+</del>
+<a title="Linked Data Platform Indirect Container">
+<ins class="diff-chg">Indirect
+</ins></a><ins class="diff-chg">
+Containers
+only)
+whose
+</ins><a title="Membership triples">
+membership
+<del class="diff-old">triples
+of
+the
+form:
+(
+R
+,
+P
+,
+MR
+),
+where
+MR
+represents
+URI
+of
+a
+member
+resource.
+5.2.5.2
+For
+a
+given
+</del>
+triple
+</a>
+<ins class="diff-new">pattern
+is
+</ins>
+<var>
+<del class="diff-old">T
+</del>
+<ins class="diff-chg">(
+member-derived-URI
+,
+membership-predicate
+,
+membership-constant-URI
+)
+</ins>
+</var>
+<del class="diff-old">with
+a
+</del>
+<ins class="diff-chg">MUST
+contain
+exactly
+one
+triple
+whose
+</ins>
+subject
+<del class="diff-old">C
+of
+</del>
+<ins class="diff-chg">is
+</ins>
+the
+LDPC
+<del class="diff-old">and
+</del>
+<ins class="diff-chg">URI,
+whose
+</ins>
+predicate
+<del class="diff-old">of
+</del>
+<ins class="diff-chg">is
+either
+</ins>
+<code>
+<del class="diff-old">ldp:membershipPredicateInverse
+</del>
+<ins class="diff-chg">ldp:containedByRelation
+</ins>
+</code>,
+<del class="diff-old">the
+</del>
+<ins class="diff-chg">and
+whose
+</ins>
+object
+<del class="diff-old">MUST
+be
+</del>
+<ins class="diff-chg">is
+</ins>
+the
+URI
+of
+<del class="diff-old">the
+membership
+predicate
+</del>
+<var>
+<del class="diff-old">P
+used
+to
+indicate
+membership
+to
+</del>
+<ins class="diff-chg">membership-predicate
+</ins></var>.</h2></section></section><section id="ldpc-indirectmbr"><h2 class="normal"><ins class="diff-chg">
+LDP
+</ins><a title="Linked Data Platform Indirect Container"><ins class="diff-chg">
+Indirect
+</ins></a><ins class="diff-chg">
+Containers
+MUST
+contain
+exactly
+one
+triple
+whose
+subject
+is
+</ins>
+the
+<del class="diff-old">linked
+to
+</del>
+LDPC
+<del class="diff-old">,
+or
+simply:
+T
+=
+(
+C
+,
+</del>
+<ins class="diff-chg">URI,
+whose
+predicate
+is
+</ins>
+<code>
+<del class="diff-old">ldp:membershipPredicateInverse
+</del>
+<ins class="diff-chg">ldp:insertedContentRelation
+</ins>
+</code>,
+<del class="diff-old">P)
+.
+For
+the
+membership
+predicate
+URI
+</del>
+<ins class="diff-chg">and
+whose
+</ins>
+object
+<del class="diff-old">used
+in
+</del>
+<var>
+<ins class="diff-chg">ICR
+</ins></var><ins class="diff-chg">
+describes
+how
+</ins>
+the
+<del class="diff-old">triple
+</del>
+<var>
+<del class="diff-old">T
+,
+it
+would
+be
+found
+</del>
+<ins class="diff-chg">member-derived-URI
+</ins></var>
+in
+<del class="diff-old">a
+resource's
+object
+subject
+</del>
+<ins class="diff-chg">the
+container's
+</ins><a title="Membership triples"><ins class="diff-chg">
+membership
+triples
+</ins></a><ins class="diff-chg">
+is
+chosen.
+The
+</ins>
+<var>
+<del class="diff-old">R
+</del>
+<ins class="diff-chg">member-derived-URI
+</ins>
+</var>
+<del class="diff-old">and
+same
+predicate
+</del>
+<ins class="diff-chg">is
+taken
+from
+some
+triple
+</ins>
+<var>
+<del class="diff-old">P
+</del>
+<ins class="diff-chg">(
+S,
+P,
+O
+)
+</ins>
+</var>
+<del class="diff-old">membership
+triples
+of
+</del>
+<ins class="diff-chg">in
+</ins>
+the
+<del class="diff-old">form:
+(
+</del>
+<ins class="diff-chg">document
+supplied
+by
+the
+client
+as
+input
+to
+the
+create
+request;
+if
+</ins>
+<var>
+<del class="diff-old">MR
+,
+</del>
+<ins class="diff-chg">ICR
+</ins></var><ins class="diff-chg">
+'s
+value
+is
+</ins>
+<var>
+P
+</var>,
+<ins class="diff-new">then
+the
+</ins>
+<var>
+<del class="diff-old">R
+</del>
+<ins class="diff-chg">member-derived-URI
+</ins>
+</var>
+<del class="diff-old">),
+where
+</del>
+<ins class="diff-chg">is
+</ins>
+<var>
+<del class="diff-old">MR
+represents
+URI
+of
+a
+member
+resource.
+5.2.6
+The
+representation
+of
+a
+LDPC
+MAY
+include
+an
+arbitrary
+number
+of
+additional
+triples
+whose
+subjects
+are
+</del>
+<ins class="diff-chg">O
+</ins></var>.<ins class="diff-chg">
+LDP
+does
+not
+define
+</ins>
+the
+<del class="diff-old">members
+of
+</del>
+<ins class="diff-chg">behavior
+when
+more
+than
+one
+triple
+containing
+</ins>
+the
+<del class="diff-old">container,
+or
+that
+are
+from
+</del>
+<ins class="diff-chg">predicate
+</ins><var><ins class="diff-chg">
+P
+</ins></var><ins class="diff-chg">
+is
+present
+in
+</ins>
+the
+<del class="diff-old">representations
+of
+</del>
+<ins class="diff-chg">client's
+input.
+For
+example,
+if
+</ins>
+the
+<del class="diff-old">members
+(if
+they
+have
+</del>
+<ins class="diff-chg">client
+POSTs
+</ins>
+RDF
+<del class="diff-old">representations).
+This
+allows
+a
+LDPC
+server
+</del>
+<ins class="diff-chg">content
+</ins>
+to
+<del class="diff-old">provide
+clients
+with
+information
+about
+the
+members
+without
+</del>
+<ins class="diff-chg">a
+container
+that
+causes
+</ins>
+the
+<del class="diff-old">client
+having
+</del>
+<ins class="diff-chg">container
+</ins>
+to
+<del class="diff-old">do
+</del>
+<ins class="diff-chg">create
+</ins>
+a
+<ins class="diff-new">new
+LDPR,
+and
+that
+content
+contains
+the
+triple
+</ins><var><ins class="diff-new">
+(
+<>
+,
+foaf:primaryTopic
+,
+bob#me
+)
+</ins></var>
+<code>
+<del class="diff-old">GET
+</del>
+<ins class="diff-chg">foaf:primaryTopic
+</ins>
+</code>
+<del class="diff-old">on
+each
+member
+individually.
+See
+sections
+5.1.1
+Container
+Member
+Information
+,
+section
+4.11
+,
+</del>
+<ins class="diff-chg">says
+that
+the
+</ins><var><ins class="diff-chg">
+member-derived-URI
+</ins></var><ins class="diff-chg">
+is
+</ins><var><ins class="diff-chg">
+bob#me
+</ins></var>.</h2><section id="ldpc-indirectmbr-basic"><h2 class="normal"><ins class="diff-chg">
+LDP
+</ins><a title="Linked Data Platform Basic Container"><ins class="diff-chg">
+Basic
+</ins></a>
+and
+<del class="diff-old">section
+5.10
+</del>
+<a title="Linked Data Platform Direct Container">
+<ins class="diff-chg">Direct
+</ins>
+</a>
+<del class="diff-old">for
+additional
+details.
+5.2.7
+The
+representation
+of
+a
+LDPC
+</del>
+<ins class="diff-chg">Containers
+</ins>
+MUST
+<ins class="diff-chg">behave
+as
+if
+they
+</ins>
+have
+<ins class="diff-new">a
+</ins><var><ins class="diff-new">
+(
+LDPC
+URI,
+</ins>
+<code>
+<del class="diff-old">rdf:type
+</del>
+<ins class="diff-chg">ldp:insertedContentRelation
+</ins>
+</code>
+<del class="diff-old">of
+ldp:Container
+,
+but
+it
+MAY
+have
+additional
+</del>
+<ins class="diff-chg">,
+</ins>
+<code>
+<del class="diff-old">rdf:type
+</del>
+<ins class="diff-chg">ldp:MemberSubject
+</ins>
+</code>
+<del class="diff-old">s.
+5.2.8
+LDPC
+representations
+SHOULD
+NOT
+use
+RDF
+container
+types
+rdf:Bag
+,
+</del>
+<ins class="diff-chg">)
+</ins></var><ins class="diff-chg">
+triple,
+but
+LDP
+imposes
+no
+requirement
+to
+materialize
+such
+a
+triple
+in
+representations.
+The
+value
+</ins>
+<code>
+<del class="diff-old">rdf:Seq
+</del>
+<ins class="diff-chg">ldp:MemberSubject
+</ins>
+</code>
+<del class="diff-old">or
+rdf:List
+.
+5.2.9
+LDPC
+servers
+SHOULD
+NOT
+re-use
+URIs,
+regardless
+of
+</del>
+<ins class="diff-chg">means
+that
+</ins>
+the
+<del class="diff-old">mechanism
+</del>
+<var>
+<ins class="diff-chg">member-derived-URI
+</ins></var><ins class="diff-chg">
+is
+the
+URI
+assigned
+</ins>
+by
+<del class="diff-old">which
+members
+are
+created
+(
+POST
+,
+PUT
+,
+etc.).
+Certain
+specific
+cases
+exist
+where
+a
+LDPC
+</del>
+<ins class="diff-chg">the
+</ins>
+server
+<del class="diff-old">MAY
+delete
+</del>
+<ins class="diff-chg">to
+</ins>
+a
+<del class="diff-old">resource
+and
+then
+later
+re-use
+the
+URI
+when
+</del>
+<ins class="diff-chg">document
+</ins>
+it
+<del class="diff-old">identifies
+</del>
+<ins class="diff-chg">creates;
+for
+example,
+if
+</ins>
+the
+<del class="diff-old">same
+resource,
+but
+only
+when
+consistent
+with
+Web
+architecture
+[
+WEBARCH
+].
+While
+it
+is
+difficult
+</del>
+<ins class="diff-chg">client
+POSTs
+content
+</ins>
+to
+<del class="diff-old">provide
+absolute
+implementation
+guarantees
+of
+non-reuse
+in
+all
+failure
+scenarios,
+re-using
+URIs
+creates
+ambiguities
+for
+clients
+</del>
+<ins class="diff-chg">a
+container
+</ins>
+that
+<del class="diff-old">are
+best
+avoided.
+5.2.10
+Some
+LDPC
+s
+have
+membership
+objects
+</del>
+<ins class="diff-chg">causes
+the
+container
+to
+create
+a
+new
+LDPR,
+</ins><code><ins class="diff-chg">
+ldp:MemberSubject
+</ins></code><ins class="diff-chg">
+says
+</ins>
+that
+<del class="diff-old">are
+not
+directly
+URIs
+minted
+upon
+LDPC
+member
+creation,
+for
+example
+URIs
+with
+non-empty
+fragment
+identifier
+[
+RFC3986
+].
+To
+determine
+which
+object
+</del>
+<ins class="diff-chg">the
+</ins><var><ins class="diff-chg">
+member-derived-URI
+</ins></var><ins class="diff-chg">
+is
+the
+</ins>
+URI
+<ins class="diff-new">assigned
+</ins>
+to
+<del class="diff-old">use
+for
+</del>
+the
+<del class="diff-old">membership
+triple,
+LDPC
+s
+</del>
+<ins class="diff-chg">newly
+created
+LDPR.
+</ins></h2></section></section><section id="ldpc-linktypehdr"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a><ins class="diff-chg">
+exposing
+LDPCs
+</ins>
+MUST
+<del class="diff-old">contain
+one
+triple
+whose
+subject
+is
+the
+LDPC
+URI,
+predicate
+is
+</del>
+<ins class="diff-chg">advertise
+their
+LDP
+support
+by
+exposing
+a
+HTTP
+</ins>
+<code>
+<del class="diff-old">ldp:membershipObject
+,
+</del>
+<ins class="diff-chg">Link
+</ins></code><ins class="diff-chg">
+header
+</ins>
+with
+<del class="diff-old">an
+object
+MO
+.
+Where
+MO
+and
+the
+HTTP
+</del>
+<ins class="diff-chg">a
+target
+</ins>
+URI
+<del class="diff-old">R
+from
+</del>
+<ins class="diff-chg">of
+</ins>
+<code>
+<del class="diff-old">POST
+</del>
+<ins class="diff-chg">http://www.w3.org/ns/ldp#Container
+</ins></code>,<ins class="diff-chg">
+and
+a
+link
+relation
+type
+of
+</ins><code><ins class="diff-chg">
+type
+</ins>
+</code>
+<del class="diff-old">create
+(as
+found
+</del>
+<ins class="diff-chg">(that
+is,
+</ins><code><ins class="diff-chg">
+rel='type'
+</ins></code><ins class="diff-chg">
+)
+</ins>
+in
+<ins class="diff-new">all
+responses
+to
+requests
+made
+to
+the
+LDPC's
+</ins>
+HTTP
+<del class="diff-old">response
+</del>
+<code>
+<del class="diff-old">Location
+</del>
+<ins class="diff-chg">Request-URI
+</ins></code>.<a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a><ins class="diff-chg">
+MAY
+provide
+additional
+HTTP
+</ins><code><ins class="diff-chg">
+Link:
+rel='type'
+</ins>
+</code>
+<del class="diff-old">header)
+can
+be
+used
+</del>
+<ins class="diff-chg">headers
+</ins>
+to
+<del class="diff-old">locate
+</del>
+<ins class="diff-chg">advertise
+their
+support
+for
+</ins><a href="#ldpc-typecontainer"><ins class="diff-chg">
+specific
+LDPC
+types
+</ins></a>.<ins class="diff-chg">
+The
+</ins><a href="#ldpr-gen_linktypehdr"><ins class="diff-chg">
+notes
+on
+the
+corresponding
+LDPR
+constraint
+</ins></a><ins class="diff-chg">
+apply
+equally
+to
+LDPCs.
+</ins></h2></section><section id="ldpc-prefer"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a><ins class="diff-chg">
+SHOULD
+respect
+all
+of
+</ins>
+a
+<del class="diff-old">triple
+</del>
+<ins class="diff-chg">client's
+LDP-defined
+hints,
+for
+example
+</ins><a href="#prefer-parameters"><ins class="diff-chg">
+which
+subsets
+</ins>
+of
+<ins class="diff-new">LDP-defined
+state
+</ins></a>
+the
+<del class="diff-old">form:
+(R,
+MO,
+N)
+and
+where
+N
+can
+be
+used
+</del>
+<ins class="diff-chg">client
+is
+interested
+in
+processing,
+</ins>
+to
+<del class="diff-old">construct
+</del>
+<ins class="diff-chg">influence
+</ins>
+the
+<del class="diff-old">membership
+triple
+</del>
+<ins class="diff-chg">set
+</ins>
+of
+<del class="diff-old">the
+form:
+(membership
+subject,
+membership
+predicate,
+N)
+.
+When
+ldp:membershipPredicateInverse
+is
+used
+instead
+</del>
+<ins class="diff-chg">triples
+returned
+in
+representations
+</ins>
+of
+<del class="diff-old">ldp:membershipPredicate
+,
+</del>
+<ins class="diff-chg">an
+LDPC,
+particularly
+for
+large
+LDPCs.
+Non-normative
+note:
+</ins>
+the
+<del class="diff-old">membership
+triple
+MUST
+</del>
+<ins class="diff-chg">LDPC
+might
+</ins>
+be
+<del class="diff-old">of
+the
+form:
+(N,
+membership
+predicate,
+membership
+subject)
+.
+To
+indicate
+</del>
+<ins class="diff-chg">paged;
+</ins><a title="Paged resource"><ins class="diff-chg">
+paged
+resources
+</ins></a><ins class="diff-chg">
+provide
+no
+guarantee
+</ins>
+that
+<del class="diff-old">the
+member
+resource
+URI
+is
+the
+membership
+object
+(the
+default
+</del>
+<ins class="diff-chg">all
+triples
+of
+a
+given
+subset,
+for
+example
+</ins><a title="Containment triples"><ins class="diff-chg">
+containment
+triples
+</ins></a>,<ins class="diff-chg">
+are
+grouped
+together
+on
+one
+page
+</ins>
+or
+<del class="diff-old">typical
+case),
+the
+object
+MUST
+be
+set
+to
+predefined
+URI
+ldp:MemberSubject
+such
+that
+it
+forms
+the
+triple:
+(
+LDPC
+URI,
+ldp:membershipObject
+,
+ldp:MemberSubject
+)
+.
+</del>
+<ins class="diff-chg">on
+a
+sequence
+of
+consecutive
+</ins><a title="Single-page resource"><ins class="diff-chg">
+pages
+</ins></a><ins class="diff-chg">
+(see
+</ins><a href="#ldpr-Paging" class="sectionRef">
+<del class="diff-old">5.3
+</del>
+</a>
+<ins class="diff-chg">).
+</ins></h2></section></section><section id="ldpc-HTTP_GET"><h2>
+HTTP
+GET
+<del class="diff-old">5.3.1
+</del>
+</h2>
+<section id="ldpc-get-mbrtriples">
+<h2 class="normal">
+The
+representation
+of
+a
+LDPC
+MUST
+contain
+a
+set
+of
+<a title="Membership triples">
+<ins class="diff-new">membership
+</ins>
+triples
+<del class="diff-old">with
+a
+consistent
+subject
+and
+predicate
+whose
+objects
+indicate
+members
+</del>
+</a>
+<ins class="diff-chg">following
+one
+</ins>
+of
+the
+<del class="diff-old">container.
+</del>
+<ins class="diff-chg">consistent
+patterns
+from
+that
+definition.
+</ins>
+The
+<del class="diff-old">subject
+</del>
+<ins class="diff-chg">membership-constant-URI
+</ins>
+of
+the
+triples
+MAY
+be
+the
+container
+itself
+or
+MAY
+be
+another
+resource
+(as
+in
+the
+<a href="#ldpc-ex-membership-subj">
+example
+</a>
+).
+<del class="diff-old"> See
+</del>
+<ins class="diff-chg"> See
+</ins>
+also
+<del class="diff-old">5.2.3
+.
+5.3.2
+</del>
+<ins class="diff-chg">section
+on
+</ins><a href="#ldpc-mbrpred">
+LDPC
+<ins class="diff-chg">membership
+predicates
+</ins></a>.</h2></section><section id="ldpc-sortcriteriaobj"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
+LDP
+</ins>
+servers
+</a>
+MAY
+represent
+the
+members
+of
+a
+paged
+LDPC
+in
+a
+sequential
+order.
+<del class="diff-old"> If
+</del>
+<ins class="diff-chg"> If
+</ins>
+the
+server
+does
+so,
+it
+MUST
+<del class="diff-old">be
+</del>
+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
+MUST
+be
+as
+defined
+by
+SPARQL
+<code>
+SELECT
+</code>
+’s
+<code>
+ORDER
+BY
+</code>
+clause
+<del class="diff-old">[
+SPARQL-QUERY
+].
+</del>
+<ins class="diff-chg">[[!SPARQL-QUERY]].
+</ins>
+Sorting
+criteria
+<del class="diff-old">MUST
+ be
+</del>
+<ins class="diff-chg">MUST be
+</ins>
+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
+<del class="diff-old">5.1.4
+Ordering
+</del>
+<a href="#ldpc-ordering" class="sectionRef">
+</a>
+for
+an
+example.
+<del class="diff-old">5.3.3
+</del>
+</h2>
+</section>
+<section id="ldpc-sortliteraltype">
+<h2 class="normal">
+LDPC
+page
+representations
+ordered
+using
+<code>
+ldp:containerSortCriteria
+</code>
+MUST
+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>
+page-ordering
+values
+</dfn>
+).
+The
+only
+<del class="diff-old">predicate
+</del>
+<ins class="diff-chg">literal
+</ins>
+data
+types
+whose
+behavior
+LDP
+constrains
+are
+those
+defined
+by
+SPARQL
+<code>
+SELECT
+</code>
+’s
+<code>
+ORDER
+BY
+</code>
+clause
+<del class="diff-old">[
+SPARQL-QUERY
+].
+</del>
+<ins class="diff-chg">[[!SPARQL-QUERY]].
+</ins>
+Other
+data
+types
+can
+be
+used,
+but
+LDP
+assigns
+no
+meaning
+to
+them
+and
+interoperability
+will
+be
+limited.
+<del class="diff-old">5.3.4
+</del>
+</h2>
+</section>
+<section id="ldpc-sortorder">
+<h2 class="normal">
+LDPC
+page
+representations
+ordered
+using
+<code>
+ldp:containerSortCriteria
+</code>
+MUST
+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.
+<del class="diff-old">5.3.5
+</del>
+</h2>
+</section>
+<section id="ldpc-sortcollation">
+<h2 class="normal">
+LDPC
+page
+representations
+ordered
+using
+<code>
+ldp:containerSortCriteria
+</code>
+MAY
+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">
+page-ordering
+values
+</a>
+are
+strings
+or
+simple
+literals
+<del class="diff-old">[
+SPARQL-QUERY
+],
+</del>
+<ins class="diff-chg">[[!SPARQL-QUERY]],
+</ins>
+the
+resulting
+order
+is
+as
+defined
+by
+SPARQL
+SELECT’s
+ORDER
+BY
+clause
+<del class="diff-old">[
+SPARQL-QUERY
+]
+</del>
+<ins class="diff-chg">[[!SPARQL-QUERY]]
+</ins>
+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">
+page-ordering
+values
+</a>
+are
+strings
+or
+simple
+literals
+<del class="diff-old">[
+SPARQL-QUERY
+],
+</del>
+<ins class="diff-chg">[[!SPARQL-QUERY]],
+</ins>
+the
+resulting
+order
+is
+as
+defined
+by
+SPARQL
+SELECT’s
+ORDER
+BY
+clause
+<del class="diff-old">[
+SPARQL-QUERY
+]
+</del>
+<ins class="diff-chg">[[!SPARQL-QUERY]]
+</ins>
+using
+three-argument
+<code>
+fn:compare
+</code>,
+that
+is,
+the
+specified
+collation.
+The
+<code>
+ldp:containerSortCollation
+</code>
+triple
+<del class="diff-old">SHOULD
+</del>
+<ins class="diff-chg">MUST
+</ins>
+be
+omitted
+for
+comparisons
+involving
+<a title="page-ordering values">
+page-ordering
+values
+</a>
+for
+which
+<del class="diff-old">[
+SPARQL-QUERY
+]
+</del>
+<ins class="diff-chg">[[!SPARQL-QUERY]]
+</ins>
+does
+not
+use
+collations.
+</h2>
+</section>
+<del class="diff-old">5.4
+</del>
+</section>
+<section id="ldpc-HTTP_POST">
+<h2>
+HTTP
+POST
+</h2>
+<p>
+<del class="diff-old">This
+specification
+imposes
+the
+following
+new
+requirements
+on
+</del>
+<ins class="diff-chg">Per
+[HTTP11],
+this
+</ins>
+HTTP
+<del class="diff-old">POST
+for
+LDPCs
+only
+when
+an
+LDPC
+supports
+that
+method.
+This
+</del>
+<ins class="diff-chg">method
+is
+optional
+and
+this
+</ins>
+specification
+does
+not
+<del class="diff-old">impose
+any
+new
+requirement
+</del>
+<ins class="diff-chg">require
+</ins><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a>
+to
+support
+<del class="diff-old">that
+</del>
+<ins class="diff-chg">it.
+When
+a
+LDP
+server
+chooses
+to
+support
+this
+</ins>
+method,
+<del class="diff-old">and
+[
+HTTP11
+</del>
+<ins class="diff-chg">this
+specification
+imposes
+the
+following
+new
+requirements
+for
+LDPCs.
+</ins></p><p><ins class="diff-chg">
+Any
+server-imposed
+constraints
+on
+creation
+or
+update
+</ins><a href="#ldpr-gen-pubclireqs"><ins class="diff-chg">
+must
+be
+advertised
+</ins>
+</a>
+<del class="diff-old">]
+makes
+it
+optional.
+</del>
+<ins class="diff-chg">to
+clients.
+</ins>
+</p>
+<del class="diff-old">5.4.1
+</del>
+<section id="ldpc-post-created201">
+<h2 class="normal">
+LDPC
+clients
+SHOULD
+create
+member
+resources
+by
+submitting
+a
+representation
+as
+the
+entity
+body
+of
+the
+HTTP
+<code>
+POST
+</code>
+to
+a
+known
+<del class="diff-old">LDPC
+.
+</del>
+<ins class="diff-chg">LDPC.
+</ins>
+If
+the
+resource
+was
+created
+successfully,
+<del class="diff-old">LDPC
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+MUST
+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.
+<del class="diff-old">5.4.2
+After
+</del>
+</h2>
+</section>
+<section id="ldpc-post-createdmbr-contains">
+<h2 class="normal">
+<ins class="diff-chg">When
+</ins>
+a
+successful
+HTTP
+<code>
+POST
+</code>
+request
+to
+a
+LDPC
+<del class="diff-old">,
+</del>
+<ins class="diff-chg">results
+in
+</ins>
+the
+<del class="diff-old">new
+resource
+</del>
+<ins class="diff-chg">creation
+of
+an
+LDPR,
+the
+newly
+created
+document
+</ins>
+MUST
+appear
+as
+a
+<del class="diff-old">member
+</del>
+<ins class="diff-chg">contained
+resource
+</ins>
+of
+the
+LDPC
+until
+the
+<del class="diff-old">new
+resource
+</del>
+<ins class="diff-chg">newly
+created
+document
+</ins>
+is
+deleted
+or
+removed
+by
+other
+methods.
+<del class="diff-old">An
+</del>
+</h2>
+</section>
+<section id="ldpc-post-createdmbr-member">
+<h2 class="normal">
+<ins class="diff-chg">When
+a
+successful
+HTTP
+</ins><code><ins class="diff-chg">
+POST
+</ins></code><ins class="diff-chg">
+request
+to
+a
+</ins>
+LDPC
+<del class="diff-old">MAY
+also
+contain
+resources
+that
+were
+added
+through
+other
+means
+-
+for
+example
+through
+</del>
+<ins class="diff-chg">results
+in
+</ins>
+the
+<del class="diff-old">user
+interface
+</del>
+<ins class="diff-chg">creation
+</ins>
+of
+<ins class="diff-new">an
+LDPR,
+</ins>
+the
+<del class="diff-old">site
+</del>
+<ins class="diff-chg">LDPC
+MUST
+update
+its
+membership
+triples
+to
+reflect
+</ins>
+that
+<del class="diff-old">implements
+</del>
+<ins class="diff-chg">addition,
+and
+</ins>
+the
+<del class="diff-old">LDPC
+.
+5.4.3
+LDPC
+</del>
+<ins class="diff-chg">resulting
+membership
+triple
+MUST
+be
+consistent
+with
+any
+LDP-defined
+predicates
+it
+exposes.
+A
+Direct
+or
+Indirect
+container's
+membership
+triples
+MAY
+also
+be
+modified
+via
+through
+other
+means.
+</ins></h2></section><section id="ldpc-post-createbins"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
+LDP
+</ins>
+servers
+</a>
+MAY
+accept
+an
+HTTP
+<code>
+POST
+</code>
+of
+<del class="diff-old">non-
+RDF
+</del>
+<ins class="diff-chg">non-RDF
+</ins>
+representations
+<a title="Linked Data Platform Binary Resource">
+<ins class="diff-new">(LDP-BRs)
+</ins></a>
+for
+creation
+of
+any
+kind
+of
+resource,
+for
+example
+binary
+resources.
+See
+<del class="diff-old">5.4.13
+</del>
+<a href="#ldpc-post-acceptposthdr">
+<ins class="diff-chg">the
+Accept-Post
+section
+</ins>
+</a>
+for
+<del class="diff-old">introspection
+details.
+5.4.4
+For
+servers
+that
+support
+create,
+</del>
+<ins class="diff-chg">details
+on
+how
+clients
+can
+discover
+whether
+a
+</ins>
+LDPC
+<ins class="diff-chg">supports
+this
+behavior.
+</ins></h2></section><section id="ldpc-post-createrdf"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
+LDP
+</ins>
+servers
+<del class="diff-old">MUST
+</del>
+</a>
+<ins class="diff-chg">that
+successfully
+</ins>
+create
+<del class="diff-old">an
+LDPR
+</del>
+<ins class="diff-chg">a
+resource
+</ins>
+from
+a
+RDF
+representation
+in
+the
+request
+entity
+<del class="diff-old">body.
+</del>
+<ins class="diff-chg">body
+MUST
+honor
+the
+client's
+requested
+interaction
+model(s).
+</ins>
+The
+<del class="diff-old">newly
+</del>
+created
+<del class="diff-old">LDPR
+could
+also
+</del>
+<ins class="diff-chg">resource
+can
+</ins>
+be
+<del class="diff-old">a
+</del>
+<ins class="diff-chg">thought
+of
+as
+an
+RDF
+</ins><a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph"><ins class="diff-chg">
+named
+graph
+</ins></a><ins class="diff-chg">
+[[rdf11-concepts]].
+If
+any
+model
+cannot
+be
+honored,
+the
+server
+MUST
+fail
+the
+request.
+</ins></h2><ul><li><ins class="diff-chg">
+If
+the
+request
+header
+</ins><a href="#ldpr-gen-linktypehdr"><ins class="diff-chg">
+specifies
+an
+LDPR
+interaction
+model
+</ins></a>,<ins class="diff-chg">
+then
+the
+server
+MUST
+create
+an
+LDPR.
+</ins></li><li><ins class="diff-chg">
+If
+the
+request
+header
+</ins><a href="#ldpc-linktypehdr"><ins class="diff-chg">
+specifies
+an
+</ins>
+LDPC
+<del class="diff-old">,
+therefore
+servers
+MAY
+allow
+</del>
+<ins class="diff-chg">interaction
+model
+</ins></a>,<ins class="diff-chg">
+then
+</ins>
+the
+<del class="diff-old">creation
+</del>
+<ins class="diff-chg">server
+MUST
+create
+an
+LDPC.
+</ins></li><li><ins class="diff-chg">
+This
+specification
+does
+not
+constrain
+the
+server's
+behavior
+in
+other
+cases.
+</ins></li><li style="list-style: none; display: inline"><p><ins class="diff-chg">
+Note:
+A
+consequence
+</ins>
+of
+<ins class="diff-chg">this
+is
+that
+</ins>
+LDPCs
+<del class="diff-old">within
+a
+LDPC
+.
+5.4.5
+LDPC
+</del>
+<ins class="diff-chg">can
+be
+used
+to
+create
+LDPCs,
+if
+the
+server
+supports
+doing
+so.
+</ins></p></li></ul></section><section id="ldpc-post-turtle"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
+LDP
+</ins>
+servers
+</a>
+MUST
+accept
+a
+request
+entity
+body
+with
+a
+request
+header
+of
+<code>
+Content-Type
+</code>
+with
+value
+of
+<code>
+text/turtle
+</code>
+<del class="diff-old">[
+TURTLE
+</del>
+<ins class="diff-chg">[[!TURTLE]].
+</ins></h2></section><section id="ldpc-post-contenttype"><h2 class="normal">
+<del class="diff-old">].
+5.4.6
+LDPC
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+SHOULD
+use
+the
+<code>
+Content-Type
+</code>
+request
+header
+to
+determine
+the
+representation
+format
+when
+the
+request
+has
+an
+entity
+body.
+<del class="diff-old">When
+the
+header
+is
+absent,
+LDPC
+servers
+MAY
+infer
+the
+content
+type
+by
+inspecting
+the
+entity
+body
+contents
+[
+HTTP11
+].
+5.4.7
+</del>
+</h2>
+</section>
+<section id="ldpc-post-rdfnullrel">
+<h2 class="normal">
+In
+RDF
+representations,
+<del class="diff-old">LDPC
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+MUST
+interpret
+the
+null
+relative
+URI
+for
+the
+subject
+of
+triples
+in
+the
+LDPR
+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”
+<del class="diff-old">LDPR
+,
+</del>
+<ins class="diff-chg">LDPR,
+</ins>
+so
+triples
+whose
+subject
+is
+the
+null
+relative
+URI
+will
+usually
+result
+in
+triples
+in
+the
+created
+resource
+whose
+subject
+is
+the
+created
+resource.
+<del class="diff-old">
+5.4.8
+LDPC
+</del>
+<ins class="diff-chg"> 
+</ins></h2></section><section id="ldpc-post-serverassignuri"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
+LDP
+</ins>
+servers
+</a>
+SHOULD
+assign
+the
+<del class="diff-old">subject
+</del>
+URI
+for
+the
+resource
+to
+be
+created
+using
+server
+application
+specific
+rules
+in
+the
+absence
+of
+a
+<a href="#ldpc-post-slug">
+client
+hint
+</a>.
+<del class="diff-old">5.4.9
+LDPC
+</del>
+</h2>
+</section>
+<section id="ldpc-post-mincontraints">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+SHOULD
+allow
+clients
+to
+create
+new
+resources
+without
+requiring
+detailed
+knowledge
+of
+application-specific
+constraints.
+This
+is
+a
+consequence
+of
+the
+requirement
+to
+enable
+simple
+creation
+and
+modification
+of
+<del class="diff-old">LPDRs.
+5.4.10
+LDPC
+</del>
+<ins class="diff-chg">LDPRs.
+</ins></h2></section><section id="ldpc-post-slug"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
+LDP
+</ins>
+servers
+</a>
+MAY
+allow
+clients
+to
+suggest
+the
+URI
+for
+a
+resource
+created
+through
+<code>
+POST
+</code>,
+using
+the
+HTTP
+<code>
+Slug
+</code>
+header
+as
+defined
+in
+<del class="diff-old">[
+RFC5023
+].
+</del>
+<ins class="diff-chg">[[!RFC5023]].
+</ins>
+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.
+<del class="diff-old">5.4.11
+LDPC
+</del>
+</h2>
+</section>
+<section id="ldpc-post-dontreuseuris">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+that
+allow
+member
+creation
+via
+<code>
+POST
+</code>
+SHOULD
+NOT
+re-use
+<del class="diff-old">URIs,
+per
+the
+general
+requirements
+on
+LDPCs
+.
+5.4.12
+</del>
+<ins class="diff-chg">URIs.
+</ins></h2></section><section id="ldpc-post-createbinlinkmetahdr"><h2 class="normal">
+Upon
+successful
+creation
+of
+a
+<del class="diff-old">non-
+RDF
+and
+therefore
+non-
+LDPR
+member
+</del>
+<a title="Linked Data Platform Binary Resource">
+<ins class="diff-chg">LDP-BR
+</ins></a>
+(HTTP
+status
+code
+of
+201-Created
+and
+URI
+indicated
+by
+<code>
+Location
+</code>
+response
+header),
+<del class="diff-old">LDPC
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+MAY
+create
+an
+associated
+<del class="diff-old">LDPR
+</del>
+<a title="Linked Data Platform RDF Resource">
+<ins class="diff-chg">LDP-RR
+</ins></a>
+to
+contain
+data
+about
+the
+<ins class="diff-new">newly
+</ins>
+created
+<del class="diff-old">resource.
+</del>
+<ins class="diff-chg">LDP-BR.
+</ins>
+If
+an
+LDPC
+server
+creates
+this
+associated
+<del class="diff-old">LDPR
+</del>
+<a title="Linked Data Platform RDF Resource">
+<ins class="diff-chg">LDP-RR
+</ins></a>
+it
+MUST
+indicate
+its
+location
+on
+the
+HTTP
+response
+using
+the
+HTTP
+<del class="diff-old">response
+header
+</del>
+<code>
+Link
+</code>
+<del class="diff-old">and
+relationship
+type
+</del>
+<ins class="diff-chg">response
+header
+with
+link
+relation
+</ins>
+<code>
+meta
+</code>
+and
+<code>
+href
+</code>
+to
+be
+the
+URI
+of
+the
+meta-resource
+<del class="diff-old">[
+RFC5988
+</del>
+<ins class="diff-chg">[[!RFC5988]].
+</ins></h2></section><section id="ldpc-post-acceptposthdr"><h2 class="normal">
+<del class="diff-old">].
+5.4.13
+LDPC
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+that
+support
+<code>
+POST
+</code>
+MUST
+include
+an
+<a href="#header-accept-post">
+<code>
+Accept-Post
+</code>
+response
+header
+</a>
+on
+HTTP
+<code>
+OPTIONS
+</code>
+responses,
+listing
+post
+document
+media
+type(s)
+supported
+by
+the
+server.
+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.
+<del class="diff-old">5.4.14
+</del>
+</h2>
+</section>
+<section id="ldpc-post-ldpcreated">
+<h2 class="normal">
+LDPCs
+that
+create
+new
+member
+resources
+MAY
+add
+triples
+to
+the
+container
+as
+part
+of
+member
+creation
+to
+reflect
+its
+factory
+role.
+LDP
+defines
+the
+<code>
+<del class="diff-old">ldp:created
+</del>
+<ins class="diff-chg">ldp:contains
+</ins>
+</code>
+predicate
+for
+this
+purpose.
+An
+LDPC
+that
+tracks
+members
+created
+through
+the
+LDPC
+MUST
+add
+a
+triple
+<ins class="diff-new">to
+the
+container
+</ins>
+whose
+subject
+is
+the
+container's
+URI,
+whose
+predicate
+is
+<code>
+<del class="diff-old">ldp:created
+</del>
+<ins class="diff-chg">ldp:contains
+</ins>
+</code>,
+and
+whose
+object
+is
+the
+newly
+created
+member
+resource's
+URI;
+it
+MAY
+add
+other
+triples
+as
+well.
+</h2>
+</section>
+<del class="diff-old">5.5
+HTTP
+PUT
+This
+specification
+imposes
+the
+following
+new
+requirements
+on
+HTTP
+</del>
+<section id="ldpc-post-indirectmbrrel">
+<h2 class="normal">
+<ins class="diff-chg">LDPCs
+whose
+</ins>
+<code>
+<del class="diff-old">PUT
+</del>
+<ins class="diff-chg">ldp:insertedContentRelation
+</ins>
+</code>
+<del class="diff-old">for
+LDPCs
+only
+when
+</del>
+<ins class="diff-chg">triple
+has
+</ins>
+an
+<del class="diff-old">LDPC
+supports
+</del>
+<ins class="diff-chg">object
+</ins><strong><ins class="diff-chg">
+other
+than
+</ins></strong><code><ins class="diff-chg">
+ldp:MemberSubject
+</ins></code><ins class="diff-chg">
+and
+</ins>
+that
+<del class="diff-old">method.
+</del>
+<ins class="diff-chg">create
+new
+resources
+MUST
+add
+a
+triple
+to
+the
+container
+whose
+subject
+is
+the
+container's
+URI,
+whose
+predicate
+is
+</ins><code><ins class="diff-chg">
+ldp:contains
+</ins></code>,<ins class="diff-chg">
+and
+whose
+object
+is
+the
+newly
+created
+resource's
+URI
+(which
+will
+be
+different
+from
+the
+</ins><var><a href="#ldpc-indirectmbr"><ins class="diff-chg">
+member-derived
+URI
+</ins></a></var><ins class="diff-chg">
+in
+this
+case).
+</ins>
+This
+<code>
+<ins class="diff-new">ldp:contains
+</ins></code><ins class="diff-new">
+triple
+can
+be
+the
+only
+link
+from
+the
+container
+to
+the
+newly
+created
+resource
+in
+certain
+cases.
+</ins></h2></section></section><section id="ldpc-HTTP_PUT"><h2><ins class="diff-new">
+HTTP
+PUT
+</ins></h2><p><ins class="diff-new">
+Per
+[HTTP11],
+this
+HTTP
+method
+is
+optional
+and
+this
+</ins>
+specification
+does
+not
+<del class="diff-old">impose
+any
+new
+requirement
+</del>
+<ins class="diff-chg">require
+</ins><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a>
+to
+support
+<del class="diff-old">that
+</del>
+<ins class="diff-chg">it.
+When
+a
+LDP
+server
+chooses
+to
+support
+this
+</ins>
+method,
+<del class="diff-old">and
+[
+HTTP11
+</del>
+<ins class="diff-chg">this
+specification
+imposes
+the
+following
+new
+requirements
+for
+LDPCs.
+</ins></p><p><ins class="diff-chg">
+Any
+server-imposed
+constraints
+on
+creation
+or
+update
+</ins><a href="#ldpr-gen-pubclireqs"><ins class="diff-chg">
+must
+be
+advertised
+</ins>
+</a>
+<del class="diff-old">]
+makes
+it
+optional.
+</del>
+<ins class="diff-chg">to
+clients.
+</ins>
+</p>
+<del class="diff-old">5.5.1
+LDPC
+</del>
+<section id="ldpc-put-mbrprops">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+SHOULD
+NOT
+allow
+HTTP
+<code>
+PUT
+</code>
+to
+update
+a
+<del class="diff-old">LDPC
+’s
+</del>
+<ins class="diff-chg">LDPC’s
+</ins><a>
+membership
+triples
+</a>
+;
+if
+the
+server
+receives
+such
+a
+request,
+it
+SHOULD
+respond
+with
+a
+409
+(Conflict)
+status
+code.
+<del class="diff-old">5.5.2
+LDPC
+servers
+MAY
+allow
+updating
+LDPC
+non-membership
+properties
+using
+HTTP
+PUT
+on
+a
+corresponding
+non-member
+resource
+,
+which
+MAY
+exclude
+server-managed
+properties
+such
+as
+ldp:membershipSubject
+,
+ldp:membershipPredicate
+and
+ldp:membershipPredicateInverse
+.
+The
+section
+5.9
+describes
+the
+process
+by
+which
+clients
+use
+HTTP
+OPTIONS
+to
+discover
+whether
+the
+server
+offers
+such
+a
+resource,
+and
+if
+so
+its
+URL.
+5.5.3
+LDPC
+</del>
+</h2>
+</section>
+<section id="ldpc-put-create">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+<del class="diff-old">SHOULD
+NOT
+allow
+HTTP
+PUT
+requests
+with
+inlined
+member
+information
+in
+the
+request
+representation.
+See
+section
+5.1.1
+Container
+Member
+Information
+</del>
+</a>
+<del class="diff-old">for
+additional
+details.
+5.5.4
+LDPC
+servers
+</del>
+that
+allow
+member
+creation
+via
+<code>
+PUT
+</code>
+SHOULD
+NOT
+re-use
+<del class="diff-old">URIs,
+per
+the
+general
+requirements
+on
+LDPCs
+.
+</del>
+<ins class="diff-chg">URIs.
+For
+RDF
+representations
+(LDP-RRs),the
+created
+resource
+can
+be
+thought
+of
+as
+a
+RDF
+</ins><a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph"><ins class="diff-chg">
+named
+graph
+</ins></a><ins class="diff-chg">
+[[rdf11-concepts]].
+</ins></h2>
+</section>
+<del class="diff-old">5.6
+</del>
+</section>
+<section id="ldpc-HTTP_DELETE">
+<h2>
+HTTP
+DELETE
+</h2>
+<p>
+<del class="diff-old">This
+specification
+imposes
+the
+following
+new
+requirements
+on
+</del>
+<ins class="diff-chg">Per
+[HTTP11],
+this
+</ins>
+HTTP
+<del class="diff-old">DELETE
+for
+LDPRs
+</del>
+<ins class="diff-chg">method
+is
+optional
+</ins>
+and
+<del class="diff-old">LDPCs
+only
+when
+a
+LDPC
+supports
+that
+method.
+This
+</del>
+<ins class="diff-chg">this
+</ins>
+specification
+does
+not
+<del class="diff-old">impose
+any
+new
+requirement
+</del>
+<ins class="diff-chg">require
+</ins><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a>
+to
+support
+<del class="diff-old">that
+</del>
+<ins class="diff-chg">it.
+When
+a
+LDP
+server
+chooses
+to
+support
+this
+</ins>
+method,
+<del class="diff-old">and
+[
+HTTP11
+]
+makes
+it
+optional.
+</del>
+<ins class="diff-chg">this
+specification
+imposes
+the
+following
+new
+requirements
+for
+LDPCs.
+</ins>
+</p>
+<del class="diff-old">5.6.1
+</del>
+<section id="ldpc-del-contremovesmbrtriple">
+<h2 class="normal">
+When
+a
+LDPC
+<del class="diff-old">member
+</del>
+<ins class="diff-chg">contained
+</ins>
+resource
+<del class="diff-old">originally
+created
+by
+the
+LDPC
+(for
+example,
+one
+whose
+representation
+was
+HTTP
+POST
+ed
+to
+the
+LDPC
+and
+then
+referenced
+by
+a
+membership
+triple)
+</del>
+is
+deleted,
+<del class="diff-old">and
+</del>
+the
+LDPC
+server
+<del class="diff-old">is
+aware
+of
+the
+member's
+deletion
+(for
+example,
+the
+member
+is
+managed
+by
+the
+same
+server),
+the
+LDPC
+server
+</del>
+MUST
+also
+remove
+it
+from
+the
+LDPC
+by
+removing
+the
+corresponding
+<ins class="diff-new">containment
+and
+</ins>
+membership
+<del class="diff-old">triple.
+5.6.2
+When
+the
+LDPC
+server
+successfully
+completes
+the
+DELETE
+request
+on
+a
+LDPC
+,
+it
+MUST
+remove
+any
+membership
+triples
+associated
+with
+the
+LDPC
+as
+indicated
+by
+the
+canonical
+Request-URI
+.
+</del>
+<ins class="diff-chg">triples.
+</ins></h2><blockquote><ins class="diff-chg">
+Non-normative
+note:
+</ins>
+The
+<del class="diff-old">LDPC
+</del>
+<a>
+<ins class="diff-chg">LDP
+</ins>
+server
+<del class="diff-old">MAY
+</del>
+</a>
+<ins class="diff-chg">might
+</ins>
+perform
+additional
+<del class="diff-old">removal
+of
+member
+resources.
+</del>
+<ins class="diff-chg">actions,
+as
+described
+in
+the
+</ins><a href="#ldp-http-method-side-effects"><ins class="diff-chg">
+normative
+references
+</ins></a><ins class="diff-chg">
+like
+[[HTTP11]].
+</ins>
+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.
+<del class="diff-old">5.6.3
+When
+the
+conditions
+in
+5.6.1
+hold,
+and
+the
+LDPC
+tracks
+member
+resources
+that
+it
+created
+using
+the
+ldp:created
+predicate,
+the
+LDPC
+server
+MUST
+also
+remove
+the
+deleted
+member's
+ldp:created
+triple.
+5.6.4
+</del>
+</blockquote>
+</section>
+<section id="ldpc-del-contremovesmbrres">
+<h2 class="normal">
+When
+a
+LDPC
+<del class="diff-old">member
+</del>
+<ins class="diff-chg">contained
+</ins>
+resource
+<del class="diff-old">originally
+created
+by
+the
+LDPC
+(for
+example,
+one
+whose
+representation
+was
+HTTP
+POST
+ed
+to
+the
+LDPC
+and
+then
+referenced
+by
+a
+membership
+triple)
+</del>
+is
+deleted,
+and
+the
+LDPC
+server
+created
+an
+associated
+<del class="diff-old">LDPR
+</del>
+<ins class="diff-chg">LDP-RR
+</ins>
+(see
+<del class="diff-old">5.4.12
+</del>
+<ins class="diff-chg">the
+</ins><a href="#ldpc-post-createbinlinkmetahdr"><ins class="diff-chg">
+LDPC
+POST
+section
+</ins>
+</a>
+),
+the
+LDPC
+server
+<del class="diff-old">must
+</del>
+<ins class="diff-chg">MUST
+</ins>
+also
+remove
+the
+associated
+<del class="diff-old">LDPR
+</del>
+<ins class="diff-chg">LDP-RR
+</ins>
+it
+created.
+</h2>
+</section>
+<del class="diff-old">5.7
+</del>
+</section>
+<section id="ldpc-HTTP_HEAD">
+<h2>
+HTTP
+HEAD
+</h2>
+<p>
+Note
+that
+certain
+LDP
+mechanisms,
+such
+as
+<del class="diff-old">paging,
+</del>
+<a href="#ldpr-Paging">
+<ins class="diff-chg">paging
+</ins></a>,
+rely
+on
+HTTP
+headers,
+and
+HTTP
+generally
+requires
+that
+<code>
+HEAD
+</code>
+responses
+include
+the
+same
+headers
+as
+<code>
+GET
+</code>
+responses.
+Also
+<del class="diff-old">LDPC
+</del>
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+must
+also
+include
+HTTP
+headers
+on
+response
+to
+<code>
+OPTIONS
+</code>,
+see
+<a href="#ldpr-HTTP_OPTIONS" class="sectionRef">
+</a>.
+Thus,
+implementers
+supporting
+<code>
+HEAD
+</code>
+should
+also
+carefully
+read
+the
+<a href="#ldpc-HTTP_GET" class="sectionRef">
+<del class="diff-old">section
+5.3
+</del>
+</a>
+and
+<a href="#ldpc-HTTP_OPTIONS" class="sectionRef">
+<del class="diff-old">section
+5.9
+</del>
+</a>.
+</p>
+</section>
+<del class="diff-old">5.8
+</del>
+<section id="ldpc-HTTP_PATCH">
+<h2>
+HTTP
+PATCH
+</h2>
+<p>
+<del class="diff-old">This
+specification
+imposes
+the
+following
+new
+requirements
+on
+</del>
+<ins class="diff-chg">Per
+[HTTP11],
+this
+</ins>
+HTTP
+<del class="diff-old">PATCH
+for
+LDPCs
+only
+when
+a
+LDPC
+supports
+that
+method.
+This
+</del>
+<ins class="diff-chg">method
+is
+optional
+and
+this
+</ins>
+specification
+does
+not
+<del class="diff-old">impose
+any
+new
+requirement
+</del>
+<ins class="diff-chg">require
+</ins><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a>
+to
+support
+<del class="diff-old">that
+</del>
+<ins class="diff-chg">it.
+When
+a
+LDP
+server
+chooses
+to
+support
+this
+</ins>
+method,
+<del class="diff-old">and
+[
+HTTP11
+</del>
+<ins class="diff-chg">this
+specification
+imposes
+the
+following
+new
+requirements
+for
+LDPCs.
+</ins></p><p><ins class="diff-chg">
+Any
+server-imposed
+constraints
+on
+LDPR
+creation
+or
+update
+</ins><a href="#ldpr-gen-pubclireqs"><ins class="diff-chg">
+must
+be
+advertised
+</ins>
+</a>
+<del class="diff-old">]
+makes
+it
+optional.
+</del>
+<ins class="diff-chg">to
+clients.
+</ins>
+</p>
+<del class="diff-old">5.8.1
+LDPC
+</del>
+<section id="ldpc-patch-req">
+<h2 class="normal">
+<a title="LDP server">
+<ins class="diff-chg">LDP
+</ins>
+servers
+</a>
+are
+RECOMMENDED
+to
+support
+HTTP
+<code>
+PATCH
+</code>
+as
+the
+preferred
+method
+for
+updating
+<del class="diff-old">LDPC
+non-membership
+properties.
+</del>
+<ins class="diff-chg">a
+LDPC's
+</ins><a title="Empty-container triples"><ins class="diff-chg">
+empty-container
+triples
+</ins></a>.</h2>
+</section>
+<del class="diff-old">5.9
+</del>
+</section>
+<section id="ldpc-HTTP_OPTIONS">
+<h2>
+HTTP
+OPTIONS
+</h2>
+<p>
+This
+specification
+imposes
+the
+following
+new
+requirements
+on
+HTTP
+<code>
+OPTIONS
+</code>
+for
+<del class="diff-old">LDPCs
+.
+</del>
+<ins class="diff-chg">LDPCs.
+</ins>
+</p>
+<del class="diff-old">5.9.1
+LDPC
+servers
+SHOULD
+define
+a
+corresponding
+non-member
+resource
+to
+support
+requests
+for
+information
+about
+a
+LDPC
+without
+retrieving
+a
+full
+representation
+including
+all
+of
+its
+members;
+see
+section
+5.1.2
+Retrieving
+Only
+Non-member
+Properties
+for
+examples.
+In
+responses
+to
+OPTIONS
+requests
+with
+an
+LDPC
+as
+the
+Request-URI
+,
+LDPC
+servers
+that
+define
+a
+non-member
+resource
+SHOULD
+provide
+an
+HTTP
+Link
+header
+whose
+target
+URI
+is
+the
+non-member
+resource
+,
+and
+whose
+link
+relation
+type
+is
+http://www.w3.org/ns/ldp#nonMemberResource
+[
+RFC5988
+].
+This
+is
+the
+mechanism
+by
+which
+clients
+discover
+the
+URL
+of
+the
+non-member
+resource.
+If
+no
+such
+Link
+header
+is
+present,
+then
+conservative
+clients
+will
+assume
+that
+the
+LDPC
+does
+not
+have
+a
+corresponding
+non-member
+resource.
+For
+example,
+if
+there
+is
+a
+LDPC
+with
+URL
+<containerURL>
+whose
+corresponding
+non-member
+resource
+URL
+is
+<containerURL>?nonMemberProperties
+,
+then
+the
+corresponding
+link
+header
+would
+be
+Link:
+<?nonMemberProperties>;rel="http://www.w3.org/ns/ldp#nonMemberResource"
+5.9.2
+</del>
+<section id="ldpc-options-linkmetahdr">
+<h2 class="normal">
+When
+a
+LDPC
+creates
+a
+<del class="diff-old">non-
+LDPR
+(e.g.
+binary)
+</del>
+<a title="Linked Data Platform Binary Resource">
+<ins class="diff-chg">LDP-BR
+</ins></a>
+member
+(for
+example,
+one
+whose
+representation
+was
+HTTP
+<code>
+POST
+</code>
+ed
+to
+the
+LDPC
+and
+then
+referenced
+by
+a
+membership
+triple)
+it
+might
+create
+an
+associated
+<del class="diff-old">LDPR
+</del>
+<a title="Linked Data Platform RDF Resource">
+<ins class="diff-chg">LDP-RR
+</ins></a>
+to
+contain
+data
+about
+the
+<del class="diff-old">non-
+LDPR
+</del>
+<ins class="diff-chg">non-LDPR
+</ins>
+(see
+<del class="diff-old">5.4.12
+</del>
+<a href="#ldpc-post-createbinlinkmetahdr">
+<ins class="diff-chg">LDPC
+POST
+section
+</ins>
+</a>
+).
+For
+<del class="diff-old">non-
+LDPRs
+</del>
+<ins class="diff-chg">LDP-BRs
+</ins>
+that
+have
+this
+associated
+<del class="diff-old">LDPR
+,
+</del>
+<ins class="diff-chg">LDP-RR,
+</ins>
+an
+LDPC
+server
+MUST
+provide
+an
+HTTP
+<code>
+Link
+</code>
+header
+whose
+target
+URI
+is
+the
+associated
+<del class="diff-old">LDPR
+,
+</del>
+<ins class="diff-chg">LDP-RR,
+</ins>
+and
+whose
+link
+relation
+type
+is
+<code>
+meta
+</code>
+<del class="diff-old">[
+RFC5988
+].
+</del>
+<ins class="diff-chg">[[!RFC5988]].
+</ins></h2>
+</section>
+<del class="diff-old">5.10
+Member
+Inlining:
+Returning
+All
+of
+a
+Container
+Page's
+Members
+in
+a
+Response
+Feature
+At
+Risk
+</del>
+</section>
+</section>
+<section id="base-specs" class="informative">
+<h1>
+<ins class="diff-chg">Notable
+information
+from
+normative
+references
+</ins></h1>
+<p>
+<del class="diff-old">The
+LDP
+Working
+Group
+proposes
+incorporation
+of
+the
+features
+described
+in
+this
+section.
+The
+addition
+</del>
+<ins class="diff-chg">While
+readers,
+and
+especially
+implementers,
+</ins>
+of
+<del class="diff-old">resource
+inlining
+</del>
+<ins class="diff-chg">LDP
+are
+assumed
+</ins>
+to
+<del class="diff-old">save
+application
+latency
+and
+server/network
+load
+</del>
+<ins class="diff-chg">understand
+the
+information
+</ins>
+in
+<del class="diff-old">controlled
+environments.
+Feedback,
+both
+positive
+and
+negative,
+is
+invited
+by
+sending
+email
+</del>
+<ins class="diff-chg">its
+normative
+references,
+the
+working
+group
+has
+found
+that
+certain
+points
+are
+particularly
+important
+</ins>
+to
+<ins class="diff-new">understand.
+For
+those
+thoroughly
+familiar
+with
+</ins>
+the
+<del class="diff-old">mailing
+list
+in
+Status
+</del>
+<ins class="diff-chg">referenced
+specifications,
+these
+points
+might
+seem
+obvious,
+yet
+experience
+has
+shown
+that
+few
+non-experts
+find
+all
+</ins>
+of
+<del class="diff-old">This
+Document
+.
+5.10.1
+Introduction
+</del>
+<ins class="diff-chg">them
+obvious.
+</ins>
+This
+section
+<ins class="diff-new">enumerates
+these
+topics;
+it
+</ins>
+is
+<del class="diff-old">non-normative.
+One
+of
+</del>
+<ins class="diff-chg">simply
+re-stating
+(non-normatively)
+information
+locatable
+via
+</ins>
+the
+<del class="diff-old">most
+commonly
+cited
+scenarios
+for
+resource
+inlining
+is
+to
+save
+clients
+enumerating
+a
+container
+</del>
+<ins class="diff-chg">normative
+references.
+</ins></p><section id="specs-webarch" class="informative"><h2><ins class="diff-chg">
+Architecture
+</ins>
+of
+<del class="diff-old">m
+members
+from
+having
+to
+perform
+m+1
+HTTP
+requests
+(or
+m+p
+,
+if
+</del>
+the
+<del class="diff-old">container
+is
+paged
+into
+p
+pages).
+The
+desire
+</del>
+<ins class="diff-chg">World
+Wide
+Web
+</ins></h2><ins class="diff-chg">
+Reference:
+[[!WEBARCH]]
+</ins><section id="ldp-webarch-nonexcl-membership"><h2 class="normal"><ins class="diff-chg">
+LDPC
+membership
+</ins>
+is
+<del class="diff-old">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
+</del>
+<ins class="diff-chg">not
+exclusive;
+this
+means
+that
+</ins>
+the
+<del class="diff-old">general
+</del>
+<ins class="diff-chg">same
+</ins>
+resource
+<del class="diff-old">inlining
+mechanism
+useful
+in
+cases
+where
+only
+</del>
+<ins class="diff-chg">(LDPR
+or
+not)
+can
+be
+</ins>
+a
+<del class="diff-old">subset
+</del>
+<ins class="diff-chg">member
+</ins>
+of
+<del class="diff-old">the
+members'
+content
+is
+inlined,
+</del>
+<ins class="diff-chg">more
+than
+one
+LDPC.
+</ins></h2></section><section id="ldp-webarch-uri-reuse"><h2 class="normal"><a title="LDP server">
+LDP
+<del class="diff-old">also
+provides
+a
+predicate
+for
+the
+special
+case
+where
+all
+</del>
+<ins class="diff-chg">servers
+</ins></a><ins class="diff-chg">
+should
+not
+re-use
+URIs,
+regardless
+</ins>
+of
+<del class="diff-old">a
+container's
+or
+page's
+</del>
+<ins class="diff-chg">the
+mechanism
+by
+which
+</ins>
+members
+are
+<del class="diff-old">inlined.
+Rather
+than
+forcing
+the
+</del>
+<ins class="diff-chg">created
+(
+</ins><code><ins class="diff-chg">
+POST
+</ins></code>,<code><ins class="diff-chg">
+PUT
+</ins></code>,<ins class="diff-chg">
+etc.).
+Certain
+specific
+cases
+exist
+where
+a
+LDPC
+</ins>
+server
+<del class="diff-old">to
+add
+</del>
+<ins class="diff-chg">might
+delete
+</ins>
+a
+<del class="diff-old">triple
+for
+each
+inlined
+member,
+forcing
+clients
+to
+compare
+the
+list
+of
+inlined
+members
+against
+the
+set
+of
+members
+in
+the
+representation,
+</del>
+<ins class="diff-chg">resource
+</ins>
+and
+<del class="diff-old">enlarging
+</del>
+<ins class="diff-chg">then
+later
+re-use
+</ins>
+the
+<del class="diff-old">representation
+needlessly,
+a
+single
+triple
+can
+be
+used.
+This
+is
+called
+member
+inlining
+.
+LDP
+does
+not
+provide
+clients
+with
+any
+way
+to
+detect
+whether
+or
+not
+</del>
+<ins class="diff-chg">URI
+when
+it
+identifies
+</ins>
+the
+<del class="diff-old">server
+is
+capable
+of
+resource
+inlining
+(all
+its
+resources
+or
+any
+specific
+resource),
+nor
+does
+</del>
+<ins class="diff-chg">same
+resource,
+but
+only
+when
+consistent
+with
+Web
+architecture.
+While
+</ins>
+it
+<ins class="diff-new">is
+difficult
+to
+</ins>
+provide
+<ins class="diff-new">absolute
+implementation
+guarantees
+of
+non-reuse
+in
+all
+failure
+scenarios,
+re-using
+URIs
+creates
+ambiguities
+for
+</ins>
+clients
+<del class="diff-old">with
+any
+way
+to
+influence
+which
+(if
+any)
+resources
+</del>
+<ins class="diff-chg">that
+</ins>
+are
+<del class="diff-old">inlined
+in
+any
+given
+response.
+The
+inlining
+building
+blocks
+</del>
+<ins class="diff-chg">best
+avoided.
+</ins></h2></section></section><section id="specs-http" class="informative"><h2><ins class="diff-chg">
+HTTP
+1.1
+</ins></h2><ins class="diff-chg">
+Reference:
+[[!HTTP11]]
+</ins><section id="ldp-http-other-representations"><h2 class="normal"><a title="LDP server">
+LDP
+<del class="diff-old">provides
+</del>
+<ins class="diff-chg">servers
+</ins></a>
+can
+<del class="diff-old">only
+</del>
+<ins class="diff-chg">support
+representations
+beyond
+those
+necessary
+to
+conform
+to
+this
+specification.
+These
+could
+</ins>
+be
+<del class="diff-old">safely
+used
+if
+certain
+assumptions
+hold.
+This
+</del>
+<ins class="diff-chg">other
+RDF
+formats,
+like
+N3
+or
+NTriples,
+but
+non-RDF
+formats
+like
+HTML
+[[HTML401]]
+and
+JSON
+[[RFC4627]]
+would
+likely
+be
+common.
+HTTP
+content
+negotiation
+([[HTTP11]]
+Section
+12
+-
+Content
+Negotiation)
+</ins>
+is
+<del class="diff-old">no
+less
+true
+for
+containers
+than
+for
+</del>
+<ins class="diff-chg">used
+to
+select
+the
+format.
+</ins></h2></section><section id="ldp-http-other-methods"><h2 class="normal">
+LDPRs
+<ins class="diff-chg">can
+be
+created,
+updated
+and
+deleted
+using
+methods
+not
+defined
+</ins>
+in
+<del class="diff-old">general.
+See
+the
+general
+cautions
+on
+resource
+inlining
+.
+</del>
+<ins class="diff-chg">this
+document,
+for
+example
+through
+application-specific
+means,
+SPARQL
+UPDATE,
+etc.
+[[SPARQL-UPDATE]],
+as
+long
+as
+those
+methods
+do
+not
+conflict
+with
+this
+specification's
+normative
+requirements.
+</ins></h2>
+</section>
+<section id="ldp-http-delete-uri-reuse">
+<h2 class="normal">
+<del class="diff-old">5.10.2
+HTTP
+GET
+In
+addition
+to
+the
+requirements
+set
+forth
+in
+other
+sections,
+LDPC
+servers
+that
+support
+member
+inlining
+,
+and
+</del>
+<a title="LDP server">
+LDP
+<del class="diff-old">clients
+aware
+of
+</del>
+<ins class="diff-chg">servers
+</ins></a><ins class="diff-chg">
+remove
+</ins>
+the
+<del class="diff-old">same
+facility,
+must
+also
+follow
+</del>
+<ins class="diff-chg">resource
+identified
+by
+</ins>
+the
+<del class="diff-old">requirements
+</del>
+<code>
+<ins class="diff-chg">Request-URI
+</ins></code>
+in
+<del class="diff-old">this
+section.
+5.10.2.1
+LDPC
+representations
+that
+are
+member
+inlined
+MUST
+include
+</del>
+<ins class="diff-chg">response
+to
+a
+successful
+HTTP
+</ins><code><ins class="diff-chg">
+DELETE
+</ins></code><ins class="diff-chg">
+request.
+After
+such
+a
+request,
+</ins>
+a
+<ins class="diff-new">subsequent
+HTTP
+</ins>
+<code>
+<del class="diff-old">ldp:Page
+</del>
+<ins class="diff-chg">GET
+</ins>
+</code>
+<del class="diff-old">resource
+in
+</del>
+<ins class="diff-chg">on
+</ins>
+the
+<del class="diff-old">representation,
+whether
+</del>
+<ins class="diff-chg">same
+</ins><code><ins class="diff-chg">
+Request-URI
+</ins></code><ins class="diff-chg">
+usually
+results
+in
+a
+404
+(Not
+found)
+</ins>
+or
+<del class="diff-old">not
+</del>
+<ins class="diff-chg">410
+(Gone)
+status
+code,
+although
+HTTP
+allows
+others.
+</ins></h2></section><section id="ldp-http-method-side-effects"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a><ins class="diff-chg">
+can
+alter
+</ins>
+the
+<del class="diff-old">representation
+contains
+multiple
+pages,
+</del>
+<ins class="diff-chg">state
+of
+other
+resources
+</ins>
+as
+<del class="diff-old">described
+in
+</del>
+<ins class="diff-chg">a
+result
+of
+any
+HTTP
+request,
+especially
+when
+non-safe
+methods
+are
+used
+([[HTTP11]]
+</ins>
+section
+<del class="diff-old">4.11.3.1
+.
+In
+addition
+to
+satisfying
+those
+requirements,
+</del>
+<ins class="diff-chg">9.1).
+For
+example,
+it
+is
+acceptable
+for
+</ins>
+the
+<del class="diff-old">representation
+MUST
+contain
+a
+triple
+</del>
+<ins class="diff-chg">server
+to
+remove
+triples
+from
+other
+resources
+</ins>
+whose
+subject
+<ins class="diff-new">or
+object
+</ins>
+is
+the
+<ins class="diff-new">deleted
+resource
+as
+the
+result
+of
+a
+successful
+HTTP
+</ins>
+<code>
+<del class="diff-old">ldp:Page
+</del>
+<ins class="diff-chg">DELETE
+</ins>
+</code>
+<del class="diff-old">resource
+URI,
+whose
+predicate
+</del>
+<ins class="diff-chg">request.
+It
+</ins>
+is
+<del class="diff-old">ldp:membersInlined
+,
+</del>
+<ins class="diff-chg">also
+acceptable
+</ins>
+and
+<del class="diff-old">whose
+object
+is
+"true"^^xsd:boolean
+.
+This
+is
+means
+by
+which
+the
+server
+communicates
+</del>
+<ins class="diff-chg">common
+for
+</ins><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a>
+to
+<ins class="diff-new">not
+do
+this
+–
+the
+server's
+behavior
+can
+vary,
+so
+</ins>
+LDP
+clients
+<del class="diff-old">that
+they
+</del>
+<ins class="diff-chg">cannot
+depend
+on
+it.
+</ins></h2></section><section id="ldp-http-patch-allowed"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a>
+can
+<del class="diff-old">avoid
+</del>
+<ins class="diff-chg">implement
+</ins>
+HTTP
+<code>
+<del class="diff-old">GET
+</del>
+<ins class="diff-chg">PATCH
+</ins>
+</code>
+<del class="diff-old">requests
+for
+the
+members
+listed
+on
+</del>
+<ins class="diff-chg">to
+allow
+modifications,
+especially
+partial
+replacement,
+of
+their
+resources.
+No
+minimal
+set
+of
+patch
+document
+formats
+is
+mandated
+by
+this
+document
+or
+by
+</ins>
+the
+<del class="diff-old">page.
+5.10.2.2
+LDPC
+clients
+SHOULD
+avoid
+making
+HTTP
+</del>
+<ins class="diff-chg">definition
+of
+</ins>
+<code>
+<del class="diff-old">GET
+</del>
+<ins class="diff-chg">PATCH
+</ins>
+</code>
+<del class="diff-old">requests
+against
+any
+members
+in
+a
+LDPC
+representation
+containing
+a
+</del>
+<ins class="diff-chg">[[RFC5789]].
+</ins></h2></section><section id="ldp-http-content-sniffing"><h2 class="normal"><ins class="diff-chg">
+When
+the
+</ins>
+<code>
+<del class="diff-old">ldp:Page
+</del>
+<ins class="diff-chg">Content-Type
+</ins>
+</code>
+<del class="diff-old">resource
+with
+</del>
+<ins class="diff-chg">request
+header
+is
+absent
+from
+a
+request,
+</ins><a title="LDP server"><ins class="diff-chg">
+LDP
+servers
+</ins></a><ins class="diff-chg">
+might
+infer
+</ins>
+the
+<del class="diff-old">triple
+described
+in
+section
+5.10.2.1
+,
+unless
+there
+are
+application-specific
+reasons
+for
+doing
+so.
+Clients
+should
+note
+that
+</del>
+<ins class="diff-chg">content
+type
+</ins>
+by
+<ins class="diff-new">inspecting
+</ins>
+the
+<del class="diff-old">time
+</del>
+<ins class="diff-chg">entity
+body
+contents
+[[HTTP11]].
+</ins></h2></section></section><section id="specs-rdf" class="informative"><h2><ins class="diff-chg">
+RDF
+</ins></h2><ins class="diff-chg">
+Reference:
+[[RDF-CONCEPTS]]
+</ins><section id="ldp-rdfconcepts-extra-triples-any"><h2 class="normal"><ins class="diff-chg">
+The
+state
+of
+an
+LDPR
+can
+have
+triples
+with
+any
+subject(s).
+The
+URL
+used
+to
+retrieve
+</ins>
+the
+representation
+<del class="diff-old">is
+received,
+</del>
+<ins class="diff-chg">of
+an
+LDPR
+need
+not
+be
+</ins>
+the
+<del class="diff-old">actual
+state
+</del>
+<ins class="diff-chg">subject
+</ins>
+of
+<del class="diff-old">inlined
+</del>
+<ins class="diff-chg">any
+of
+its
+triples.
+</ins></h2></section><section id="ldp-rdfconcepts-extra-triples-members"><h2 class="normal"><ins class="diff-chg">
+The
+representation
+of
+an
+LDPC
+can
+include
+an
+arbitrary
+number
+of
+additional
+triples
+whose
+subjects
+are
+the
+</ins>
+members
+<del class="diff-old">may
+</del>
+<ins class="diff-chg">of
+the
+container,
+or
+that
+are
+from
+the
+representations
+of
+the
+members
+(if
+they
+</ins>
+have
+<del class="diff-old">changed
+due
+</del>
+<ins class="diff-chg">RDF
+representations).
+This
+allows
+a
+</ins><a><ins class="diff-chg">
+LDP
+server
+</ins></a>
+to
+<del class="diff-old">subsequent
+requests.
+5.10.2.3
+LDPC
+</del>
+<ins class="diff-chg">provide
+</ins>
+clients
+<del class="diff-old">MUST
+NOT
+assume
+that
+LDPC
+representations
+lacking
+</del>
+<ins class="diff-chg">with
+information
+about
+the
+members
+without
+the
+client
+having
+to
+do
+</ins>
+a
+<code>
+<del class="diff-old">ldp:Page
+</del>
+<ins class="diff-chg">GET
+</ins>
+</code>
+<del class="diff-old">resource
+or
+lacking
+the
+triple
+described
+in
+section
+5.10.2.1
+</del>
+<ins class="diff-chg">on
+each
+member
+individually.
+See
+</ins><a href="#ldpc-member_data"><ins class="diff-chg">
+Container
+Member
+Information
+</ins>
+</a>
+<del class="diff-old">contain
+all
+the
+triples
+</del>
+for
+<del class="diff-old">all
+members
+listed
+in
+the
+representation.
+</del>
+<ins class="diff-chg">additional
+details.
+</ins></h2></section><section id="ldp-rdfconcepts-extra-triples-types"><h2 class="normal">
+The
+<del class="diff-old">representation
+might
+in
+fact
+contain
+all
+those
+triples,
+or
+some
+subset
+</del>
+<ins class="diff-chg">state
+</ins>
+of
+<del class="diff-old">them,
+that
+might
+or
+might
+not
+be
+completely
+adequate
+for
+the
+client's
+intended
+usage,
+but
+</del>
+an
+<ins class="diff-new">LDPR
+can
+have
+more
+than
+one
+triple
+with
+a
+</ins><code><ins class="diff-new">
+rdf:type
+</ins></code><ins class="diff-new">
+predicate.
+</ins></h2></section></section><section id="specs-paging" class="informative"><h2><ins class="diff-new">
+Feed
+paging
+and
+archiving
+</ins></h2><ins class="diff-new">
+Reference:
+[[RFC5005]]
+</ins><section id="ldp-paging-incomplete"><h2 class="normal"><ins class="diff-new">
+A
+</ins><a title="LDP client">
+LDP
+client
+<del class="diff-old">has
+no
+way
+</del>
+</a>
+<ins class="diff-chg">SHOULD
+NOT
+present
+</ins><a title="paged resource"><ins class="diff-chg">
+paged
+resources
+</ins></a><ins class="diff-chg">
+as
+coherent
+or
+complete,
+or
+make
+assumptions
+</ins>
+to
+<del class="diff-old">discern
+from
+such
+a
+representation
+which
+interpretation
+is
+accurate.
+</del>
+<ins class="diff-chg">that
+effect.
+[[RFC5005]].
+</ins></h2>
+</section>
+</section>
+</section>
+<del class="diff-old">6.
+</del>
+<section>
+<h1>
+HTTP
+Header
+Definitions
+<del class="diff-old">6.1
+</del>
+</h1>
+<section id="header-accept-post">
+<h2>
+The
+Accept-Post
+Response
+Header
+</h2>
+<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
+<code>
+Accept-Post
+</code>
+in
+this
+specification
+is
+pending
+advancement
+of
+an
+<a href="https://datatracker.ietf.org/doc/draft-wilde-accept-post/">
+IETF
+draft
+</a>
+that
+would
+fully
+include
+it,
+<del class="diff-old">see
+[
+RFC5789
+].
+</del>
+<ins class="diff-chg">based
+on
+the
+Accept-Patch
+header's
+design
+from
+[[!RFC5789]].
+</ins>
+Once
+LDP
+is
+in
+Candidate
+Recommendation,
+the
+LDP
+WG
+will
+make
+an
+assessment
+based
+on
+the
+status
+at
+IETF
+working
+with
+the
+W3C
+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
+<del class="diff-old">modeled
+</del>
+<ins class="diff-chg">modelled
+</ins>
+after
+the
+<code>
+Accept-Patch
+</code>
+header
+defined
+in
+<del class="diff-old">[
+RFC5789
+].
+</del>
+<ins class="diff-chg">[[!RFC5789]].
+</ins>
+</p>
+<del class="diff-old">6.1.1
+</del>
+<section id="header-accept-post-1">
+<h2 class="normal">
+The
+syntax
+for
+<code>
+Accept-Post
+</code>,
+using
+the
+ABNF
+syntax
+defined
+in
+Section
+2.1
+of
+<del class="diff-old">[
+HTTP11
+],
+</del>
+<ins class="diff-chg">[[!HTTP11]],
+</ins>
+is:
+</h2>
+<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
+<del class="diff-old">[
+HTTP11
+],
+</del>
+<ins class="diff-chg">[[!HTTP11]],
+</ins>
+Section
+3.7.
+</p>
+</blockquote>
+<del class="diff-old">6.1.2
+</del>
+</section>
+<section id="header-accept-post-2">
+<h2 class="normal">
+The
+<code>
+Accept-Post
+</code>
+HTTP
+header
+SHOULD
+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>.
+<del class="diff-old">6.1.3
+</del>
+</h2>
+</section>
+<section id="header-accept-post-iana">
+<h2 class="normal">
+IANA
+Registration
+Template
+</h2>
+<div>
+<blockquote>
+<p>
+The
+Accept-Post
+response
+header
+must
+be
+added
+to
+the
+permanent
+registry
+(see
+<del class="diff-old">[
+RFC3864
+]).
+</del>
+<ins class="diff-chg">[[!RFC3864]]).
+</ins>
+</p>
+<p>
+Header
+field
+name:
+Accept-Post
+</p>
+<p>
+Applicable
+Protocol:
+HTTP
+</p>
+<p>
+Author/Change
+controller:
+W3C
+</p>
+<p>
+Specification
+document:
+this
+specification
+</p>
+</blockquote>
+</div>
+</section>
+</section>
+<section id="prefer-parameters">
+<h2>
+<del class="diff-old">A.
+Acknowledgements
+</del>
+<ins class="diff-chg">Preferences
+on
+the
+Prefer
+Request
+Header
+</ins>
+</h2>
+<section id="prefer-summary">
+<h3>
+<ins class="diff-new">Summary
+</ins></h3><div class="ldp-issue-pending"><div class="ldp-issue-title"><ins class="diff-new">
+Need
+to
+update
+normative
+reference
+once
+RFC
+number
+is
+assigned.
+</ins></div><ins class="diff-new">
+The
+</ins><a href="http://tools.ietf.org/html/draft-snell-http-prefer-18"><ins class="diff-new">
+HTTP
+Prefer
+header
+</ins></a><ins class="diff-new">
+is
+queued
+for
+an
+RFC
+number
+behind
+HTTPbis,
+whose
+BNF
+Prefer
+normatively
+refers
+to.
+</ins></div><p><ins class="diff-new">
+This
+specification
+introduces
+new
+parameters
+on
+the
+HTTP
+</ins><code><ins class="diff-new">
+Prefer
+</ins></code><ins class="diff-new">
+request
+header's
+</ins><code><ins class="diff-new">
+return=representation
+</ins></code><ins class="diff-new">
+preference
+[[!Prefer]],
+used
+optionally
+by
+clients
+to
+supply
+a
+hint
+to
+help
+the
+server
+form
+a
+response
+that
+is
+most
+appropriate
+to
+the
+client's
+needs.
+The
+LDP-defined
+parameters
+suggest
+the
+portion(s)
+of
+a
+resource's
+state
+that
+the
+client
+application
+is
+interested
+in
+and,
+if
+received,
+is
+likely
+to
+be
+processed.
+LDP
+Containers
+with
+large
+numbers
+of
+associated
+documents
+and/or
+members
+will
+have
+large
+representations,
+and
+many
+client
+applications
+may
+be
+interested
+in
+processing
+only
+a
+subset
+of
+the
+LDPC's
+information
+(for
+example,
+only
+membership
+triples
+or
+only
+containment
+triples),
+resulting
+in
+a
+potentially
+large
+savings
+in
+server,
+client,
+and
+network
+processing.
+</ins></p><p><ins class="diff-new">
+Non-normative
+note:
+LDP
+server
+implementers
+should
+carefully
+consider
+the
+effects
+of
+these
+preferences
+on
+caching,
+as
+described
+in
+section
+2
+of
+[[!Prefer]].
+</ins></p><p><ins class="diff-new">
+Non-normative
+note:
+[[!Prefer]]
+recommends
+that
+server
+implementers
+include
+a
+</ins><code><ins class="diff-new">
+Preference-Applied
+</ins></code><ins class="diff-new">
+response
+header
+when
+the
+client
+cannot
+otherwise
+determine
+the
+server's
+behavior
+with
+respect
+to
+honoring
+hints
+from
+the
+response
+content.
+</ins><a href="#prefer-examples"><ins class="diff-new">
+Examples
+</ins></a><ins class="diff-new">
+illustrates
+some
+cases
+where
+the
+header
+is
+unnecessary.
+</ins></p></section><section id="prefer-rules"><h3><ins class="diff-new">
+Specification
+</ins></h3><section id="prefer-include"><h2 class="normal"><ins class="diff-new">
+The
+</ins><code><ins class="diff-new">
+include
+</ins></code><ins class="diff-new">
+hint
+defines
+a
+subset
+of
+an
+LDPR's
+content
+that
+a
+client
+would
+like
+included
+in
+a
+representation.
+The
+syntax
+for
+the
+</ins><code><ins class="diff-new">
+include
+</ins></code><ins class="diff-new">
+parameter
+of
+the
+HTTP
+</ins><code><ins class="diff-new">
+Prefer
+</ins></code><ins class="diff-new">
+request
+header's
+</ins><code><ins class="diff-new">
+return=representation
+</ins></code><ins class="diff-new">
+preference
+[[!Prefer]]
+is:
+</ins></h2><blockquote>
+<code>
+<ins class="diff-new">include-parameter
+=
+"include"
+*WSP
+"="
+*WSP
+ldp-uri-list
+</ins></code><p><ins class="diff-new">
+Where
+</ins><code><ins class="diff-new">
+WSP
+</ins></code><ins class="diff-new">
+is
+whitespace
+[[!RFC5234]],
+and
+</ins><code><ins class="diff-new">
+ldp-uri-list
+</ins></code><ins class="diff-new">
+is
+a
+double-quoted
+blank-delimited
+unordered
+set
+of
+URIs
+whose
+ABNF
+is
+given
+below.
+The
+generic
+preference
+BNF
+[[!Prefer]]
+allows
+either
+a
+quoted
+string
+or
+a
+token
+as
+the
+value
+of
+a
+preference
+parameter;
+LDP
+assigns
+a
+meaning
+to
+the
+value
+only
+when
+it
+is
+a
+quoted
+string
+of
+the
+form:
+</ins></p><code><ins class="diff-new">
+ldp-uri-list
+=
+DQUOTE
+*WSP
+URI
+*[
+1*WSP
+URI
+]
+*WSP
+DQUOTE
+</ins></code>
+<p>
+<ins class="diff-new">where
+</ins><code><ins class="diff-new">
+DQUOTE
+</ins></code><ins class="diff-new">
+is
+a
+double
+quote
+[[!RFC5234]],
+and
+</ins><code><ins class="diff-new">
+URI
+</ins></code><ins class="diff-new">
+is
+an
+absolute
+URI
+with
+an
+optional
+fragment
+component
+[[!RFC3986]].
+</ins></p></blockquote></section><section id="prefer-omit"><h2 class="normal"><ins class="diff-new">
+The
+</ins><code><ins class="diff-new">
+omit
+</ins></code><ins class="diff-new">
+hint
+defines
+a
+subset
+of
+an
+LDPR's
+content
+that
+a
+client
+would
+like
+omitted
+from
+a
+representation.
+The
+syntax
+for
+the
+</ins><code><ins class="diff-new">
+omit
+</ins></code><ins class="diff-new">
+parameter
+of
+the
+HTTP
+</ins><code><ins class="diff-new">
+Prefer
+</ins></code><ins class="diff-new">
+request
+header's
+</ins><code><ins class="diff-new">
+return=representation
+</ins></code><ins class="diff-new">
+preference
+[[!Prefer]]
+is:
+</ins></h2><blockquote>
+<code>
+<ins class="diff-chg">omit-parameter
+=
+"omit"
+*WSP
+"="
+*WSP
+ldp-uri-list
+</ins></code><p><ins class="diff-chg">
+Where
+</ins><code><ins class="diff-chg">
+WSP
+</ins></code><ins class="diff-chg">
+and
+</ins><code><ins class="diff-chg">
+ldp-uri-list
+</ins></code><ins class="diff-chg">
+are
+defined
+as
+above
+for
+</ins><a href="#prefer-include"><ins class="diff-chg">
+include
+</ins></a>.</p></blockquote></section><section id="prefer-conflicts"><h2 class="normal"><ins class="diff-chg">
+When
+LDP
+servers
+receive
+a
+request
+with
+conflicting
+hints,
+this
+specification
+imposes
+no
+requirements
+on
+their
+behavior.
+They
+are
+free
+to
+reject
+the
+request,
+process
+it
+applying
+some
+subset
+of
+the
+hints,
+or
+anything
+else
+appropriate
+to
+the
+server.
+[[!Prefer]]
+suggests
+treating
+similar
+requests
+as
+though
+none
+of
+the
+conflicting
+preferences
+were
+specified.
+</ins></h2></section><section id="prefer-uris"><h2 class="normal">
+This
+<del class="diff-old">section
+</del>
+<ins class="diff-chg">specification
+defines
+the
+following
+URIs
+for
+clients
+to
+use
+with
+</ins><code><ins class="diff-chg">
+include
+</ins></code><ins class="diff-chg">
+and
+</ins><code><ins class="diff-chg">
+omit
+</ins></code><ins class="diff-chg">
+parameters.
+It
+assigns
+no
+meaning
+to
+other
+URIs,
+although
+other
+specifications
+MAY
+do
+so.
+</ins></h2><table style="margin-left: +3em"><tr style="background:#F2F2F2"><td style="padding:0 0 0 +2ex"><a title="Containment triples"><ins class="diff-chg">
+Containment
+triples
+</ins></a></td><td style="padding:0 0 0 +2ex; white-space:nowrap"><code><ins class="diff-chg">
+http://www.w3.org/ns/ldp#PreferContainment
+</ins></code></td></tr><tr><td style="padding:0 0 0 +2ex"><a title="Membership triples"><ins class="diff-chg">
+Membership
+triples
+</ins></a></td><td style="padding:0 0 0 +2ex; white-space:nowrap"><code><ins class="diff-chg">
+http://www.w3.org/ns/ldp#PreferMembership
+</ins></code></td></tr><tr style="background:#F2F2F2"><td style="padding:0 0 0 +2ex"><a title="Empty-container triples"><ins class="diff-chg">
+Empty-container
+triples
+</ins></a></td><td style="padding:0 0 0 +2ex; white-space:nowrap"><code><ins class="diff-chg">
+http://www.w3.org/ns/ldp#PreferEmptyContainer
+</ins></code></td></tr></table><blockquote><p><ins class="diff-chg">
+Non-normative
+note:
+all
+currently
+defined
+URIs
+are
+only
+coherent
+for
+LDP-RRs,
+and
+in
+fact
+only
+for
+LDPCs,
+however
+in
+the
+future
+it
+</ins>
+is
+<del class="diff-old">non-normative.
+</del>
+<ins class="diff-chg">possible
+that
+additional
+URIs
+with
+other
+scopes
+of
+applicability
+could
+be
+defined.
+</ins></p></blockquote></section></section><section id="prefer-examples" class="informative"><h3><ins class="diff-chg">
+Examples
+</ins></h3><p><ins class="diff-chg">
+If
+we
+assume
+a
+container
+like
+the
+one
+below:
+</ins></p><pre class="example" id="prefer-examples-direct"><ins class="diff-chg">
+ # The following is the representation of
+ # http://example.org/netWorth/nw1/assetContainer/
+
+ # @base <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, ldp:DirectContainer;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:containerResource <http://example.org/netWorth/nw1>;
+ ldp:containsRelation o:asset;
+ ldp:insertedContentRelation ldp:MemberSubject.
+ <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 .
+
+</ins></pre><p id="prefer-examples-direct-empty-container-only1"><ins class="diff-chg">
+Clients
+interested
+only
+in
+information
+about
+the
+container
+(for
+example,
+which
+membership
+predicate
+it
+uses)
+might
+use
+this
+hint
+on
+a
+</ins><code><ins class="diff-chg">
+GET
+</ins></code><ins class="diff-chg">
+request:
+</ins><code><ins class="diff-chg">
+Prefer:
+return=representation;
+include="http://www.w3.org/ns/ldp#PreferEmptyContainer"
+</ins></code></p><p><ins class="diff-chg">
+A
+server
+that
+honors
+this
+hint
+would
+return
+a
+following
+response
+containing
+the
+HTTP
+header
+</ins><code><ins class="diff-chg">
+Preference-Applied:
+return=representation
+</ins></code><ins class="diff-chg">
+and
+this
+representation:
+</ins></p><pre class="example"><ins class="diff-chg">
+ # The following is the ordered representation of
+ # http://example.org/netWorth/nw1/assetContainer/
+
+ # @base <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/>.
+</ins>
+<ins class="diff-new"> <>
+ a ldp:Container, ldp:DirectContainer;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:containerResource <http://example.org/netWorth/nw1>;
+ ldp:containsRelation o:asset;
+ ldp:insertedContentRelation ldp:MemberSubject.
+
+</ins></pre><p id="prefer-examples-direct-empty-container-only2"><ins class="diff-new">
+Clients
+interested
+only
+in
+information
+about
+the
+container
+(same
+as
+before)
+might
+use
+this
+hint
+instead:
+</ins><code><ins class="diff-new">
+Prefer:
+return=representation;
+omit="http://www.w3.org/ns/ldp#PreferMembership
+http://www.w3.org/ns/ldp#PreferContainment"
+</ins></code>.<ins class="diff-new">
+Note:
+</ins><strong><ins class="diff-new">
+Treating
+the
+two
+as
+equivalent
+is
+not
+recommended.
+</ins></strong><ins class="diff-new">
+While
+today
+this
+</ins><code><ins class="diff-new">
+omit
+</ins></code><ins class="diff-new">
+parameter
+value
+is
+equivalent
+to
+the
+preceding
+</ins><code><ins class="diff-new">
+include
+</ins></code><ins class="diff-new">
+parameter
+value,
+they
+may
+not
+be
+equivalent
+in
+the
+future
+due
+to
+the
+definition
+of
+</ins><a title="Empty-container triples"><ins class="diff-new">
+empty-container
+triples
+</ins></a>.<ins class="diff-new">
+Clients
+should
+preferentially
+use
+the
+</ins><code><ins class="diff-new">
+include
+</ins></code><ins class="diff-new">
+parameter,
+as
+it
+more
+precisely
+communicates
+their
+needs.
+</ins>
+</p>
+<p>
+<ins class="diff-new">A
+</ins><strong><ins class="diff-new">
+LDP
+1.0
+</ins></strong><ins class="diff-new">
+server
+that
+honors
+this
+hint
+would
+return
+the
+following
+response.
+Servers
+implementing
+later
+versions
+of
+LDP
+might
+return
+substantively
+different
+responses.
+</ins></p><pre class="example"><ins class="diff-new">
+ # The following is the ordered representation of
+ # http://example.org/netWorth/nw1/assetContainer/
+
+ # @base <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, ldp:DirectContainer;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:containerResource <http://example.org/netWorth/nw1>;
+ ldp:containsRelation o:asset;
+ ldp:insertedContentRelation ldp:MemberSubject.
+
+</ins></pre><p id="prefer-examples-direct-membershiponly"><ins class="diff-new">
+Clients
+interested
+only
+in
+information
+about
+the
+container
+(for
+example,
+which
+membership
+predicate
+it
+uses)
+and
+its
+membership
+might
+use
+this
+hint
+on
+a
+</ins><code><ins class="diff-new">
+GET
+</ins></code><ins class="diff-new">
+request:
+</ins><code><ins class="diff-new">
+Prefer:
+return=representation;
+include="http://www.w3.org/ns/ldp#PreferMembership
+http://www.w3.org/ns/ldp#PreferEmptyContainer"
+</ins></code></p><p><ins class="diff-new">
+A
+server
+that
+honors
+this
+hint
+would
+return
+(at
+least)
+the
+following
+response,
+and
+perhaps
+only
+this
+(it
+might
+well
+omit
+containment
+triples
+if
+they
+are
+not
+specifically
+requested).
+In
+cases
+like
+this
+example,
+where
+a
+client
+can
+detect
+from
+the
+content
+that
+its
+hints
+were
+honored
+(the
+presence
+of
+the
+predicates
+</ins><code><ins class="diff-new">
+dcterms:title
+</ins></code><ins class="diff-new">
+and
+</ins><code><ins class="diff-new">
+o:asset
+</ins></code><ins class="diff-new">
+demonstrate
+this
+in
+the
+representation
+below),
+there
+is
+no
+need
+for
+the
+server
+to
+include
+a
+</ins><code><ins class="diff-new">
+Preference-Applied
+</ins></code><ins class="diff-new">
+response
+header
+in
+many
+common
+cases
+like
+a
+</ins><code><ins class="diff-new">
+200
+(OK)
+</ins></code><ins class="diff-new">
+response.
+In
+other
+cases,
+like
+status
+code
+</ins><code><ins class="diff-new">
+303
+</ins></code>,<ins class="diff-new">
+the
+header
+would
+still
+be
+required
+for
+the
+client
+to
+know
+that
+the
+</ins><code><ins class="diff-new">
+303
+</ins></code><ins class="diff-new">
+response
+entity
+is
+a
+representation
+of
+the
+resource
+identified
+by
+the
+</ins><code><ins class="diff-new">
+Location
+</ins></code><ins class="diff-new">
+URI
+instead
+of
+a
+short
+hypertext
+note
+(one
+with
+a
+hyperlink
+to
+the
+same
+URI
+reference
+provided
+in
+the
+</ins><code><ins class="diff-new">
+Location
+</ins></code><ins class="diff-new">
+header
+field
+[[HTTPbis]]).
+</ins></p><pre class="example"><ins class="diff-new">
+ # The following is the representation of
+ # http://example.org/netWorth/nw1/assetContainer/
+
+ # @base <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, ldp:DirectContainer;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:containerResource <http://example.org/netWorth/nw1>;
+ ldp:containsRelation o:asset;
+ ldp:insertedContentRelation ldp:MemberSubject.
+ <http://example.org/netWorth/nw1>
+ a o:NetWorth;
+ o:asset <a1>, <a3>, <a2>.
+
+</ins></pre></section></section></section><section class='informative' id='security'><h1><ins class="diff-new">
+Security
+Considerations
+</ins></h1><ins class="diff-new">
+As
+with
+any
+protocol
+that
+is
+implemented
+leveraging
+HTTP,
+implementations
+should
+take
+advantage
+of
+the
+many
+security-related
+facilities
+associated
+with
+it
+and
+are
+not
+required
+to
+carry
+out
+LDP
+operations
+that
+may
+be
+in
+contradistinction
+to
+a
+particular
+security
+policy
+in
+place.
+For
+example,
+when
+faced
+with
+an
+unauthenticated
+request
+to
+replace
+system
+critical
+RDF
+statements
+in
+a
+graph
+through
+the
+PUT
+method,
+applications
+may
+consider
+responding
+with
+the
+401
+status
+code
+(Unauthorized),
+indicating
+that
+the
+appropriate
+authorization
+is
+required.
+In
+cases
+where
+authentication
+is
+provided
+fails
+to
+meet
+the
+requirements
+of
+a
+particular
+access
+control
+policy,
+the
+403
+status
+code
+(Forbidden)
+can
+be
+sent
+back
+to
+the
+client
+to
+indicate
+this
+failure
+to
+meet
+the
+access
+control
+policy.
+</ins></section><section class='appendix informative'><h2><ins class="diff-new">
+Acknowledgements
+</ins></h2><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;">
+<del class="diff-old">Tim
+Berners-Lee,
+Steve
+Battle,
+Olivier
+Berger,
+</del>
+Alexandre
+Bertails,
+<del class="diff-old">Reza
+B'Far,
+Cody
+Burleson,
+Richard
+Cyganiak,
+Raúl
+García
+Castro,
+Miguel
+Esteban
+Gutiérrez,
+Sandro
+Hawke,
+Kingsley
+Idehen,
+Yves
+Lafon,
+</del>
+<ins class="diff-chg">Andrei
+Sambra,
+Andy
+Seaborne,
+Antonis
+Loizou,
+</ins>
+Arnaud
+Le
+Hors,
+<del class="diff-old">Antonis
+Loizou,
+</del>
+Ashok
+Malhota,
+<del class="diff-old">Roger
+Menday,
+Nandana
+Mihindukulasooriya,
+Kevin
+Page,
+</del>
+<ins class="diff-chg">Bart
+van
+Leeuwen,
+Cody
+Burleson,
+David
+Wood,
+</ins>
+Eric
+Prud'hommeaux,
+<del class="diff-old">Andy
+Seaborne,
+Steve
+Speicher,
+</del>
+<ins class="diff-chg">Erik
+Wilde,
+</ins>
+Henry
+Story,
+<del class="diff-old">Ted
+Thibodeau,
+Bart
+van
+Leeuwen,
+</del>
+<ins class="diff-chg">John
+Arwe,
+Kevin
+Page,
+Kingsley
+Idehen,
+Mark
+Baker,
+Martin
+P.
+Nally,
+</ins>
+Miel
+Vander
+Sande,
+<ins class="diff-new">Miguel
+Esteban
+Gutiérrez,
+Nandana
+Mihindukulasooriya,
+Olivier
+Berger,
+Pierre-Antoine
+Champin,
+Raúl
+García
+Castro,
+Reza
+B'Far,
+Richard
+Cyganiak,
+Roger
+Menday,
+</ins>
+Ruben
+Verborgh,
+<ins class="diff-new">Sandro
+Hawke,
+</ins>
+Serena
+Villata,
+<del class="diff-old">Erik
+Wilde,
+David
+Wood,
+Martin
+P.
+Nally
+</del>
+<ins class="diff-chg">Sergio
+Fernandez,
+Steve
+Battle,
+Steve
+Speicher,
+Ted
+Thibodeau,
+Tim
+Berners-Lee,
+Yves
+Lafon
+</ins>
+</p>
+</section>
+<del class="diff-old">B.
+References
+B.1
+Normative
+references
+[DC-TERMS]
+Dublin
+Core
+Metadata
+Initiative.
+Dublin
+Core
+Metadata
+Initiative
+Terms,
+version
+1.1.
+11
+October
+2010.
+DCMI
+Recommendation.
+URL:
+http://dublincore.org/documents/2010/10/11/dcmi-terms/
+.
+[HTML401]
+Dave
+Raggett;
+</del>
+<section class='appendix informative' id="history">
+<h1>
+<ins class="diff-chg">Change
+History
+</ins></h1><p><ins class="diff-chg">
+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.
+</ins></p><ul><li><ins class="diff-chg">
+2014-02-08
+-
+Put
+final
+stake
+in
+heart
+of
+'informative'
+(waves
+to
+Sandro),
+update
+boilerplate
+for
+readability
+per
+</ins>
+Arnaud
+<del class="diff-old">Le
+Hors;
+Ian
+Jacobs.
+HTML
+4.01
+Specification
+</del>
+<ins class="diff-chg">(JA)
+</ins></li><li><ins class="diff-chg">
+2014-02-08
+-
+ACTION-132:
+Use
+Prefer
+in
+place
+of
+non-member
+properties
+resource
+(JA)
+</ins></li><li><ins class="diff-chg">
+2014-02-08
+-
+Add
+Prefer
+header
+examples,
+define
+new
+URIs
+from
+-126
+in
+ttl,
+tweak
+acks
+per
+Arnaud
+email
+(JA)
+</ins></li><li><ins class="diff-chg">
+2014-02-07
+-
+ACTION-126:
+Add
+Prefer
+header
+(JA)
+</ins></li><li><ins class="diff-chg">
+2014-02-07
+-
+LDP-BCs
+use
+ldp:contains
+not
+ldp:member
+(JA)
+</ins></li><li><ins class="diff-chg">
+2014-02-07
+-
+Simplified
+some
+of
+the
+container
+examples
+(SS)
+</ins></li><li><ins class="diff-chg">
+2014-02-06
+-
+partial
+first
+pass
+at
+arnaud's
+email
+comments
+(JA)
+</ins></li><li><ins class="diff-chg">
+2014-02-06
+-
+fixing
+containment
+def,
+adding
+containment
+triples
+to
+terminology
+(JA)
+</ins></li><li><ins class="diff-chg">
+2014-02-06
+-
+fixing
+POST
+to
+create
+containment/membership
+triples,
+which
+was
+mangled
+(JA)
+</ins></li><li><ins class="diff-chg">
+2014-02-06
+-
+fully
+aligning
+SS
+changes
+with
+http://www.w3.org/2012/ldp/wiki/Containers
+for
+basic
+containers,
+allowing
+them
+to
+omit
+the
+standard
+predicates
+in
+representations
+despite
+requiring
+behavior
+consistent
+with
+the
+presence
+of
+those
+triples
+(JA)
+</ins></li><li><ins class="diff-chg">
+2014-02-06
+-
+editorial
+fixes
+(JA)
+</ins></li><li><ins class="diff-chg">
+2014-02-06
+-
+ACTION-127
+(complete)
+use
+the
+TAG's
+new
+[23]xx
+code;
+if
+that
+code
+is
+not
+sufficiently
+through
+IETF
+process
+by
+CR,
+we
+will
+use
+a
+303
+(JA)
+</ins></li><li><ins class="diff-chg">
+2014-02-05
+-
+ACTION-133
+Get
+rid
+of
+ldp:created
+which
+is
+subsumed
+by
+ldp:contains
+(SS)
+</ins></li><li><ins class="diff-chg">
+2014-02-04
+-
+ACTION-124
+LDPR-RR
+as
+named
+graphs
+(SS)
+</ins></li><li><ins class="diff-chg">
+2014-02-04
+-
+ACTION-120
+(complete)
+Updated
+LDPC
+general,
+GET
+and
+POST
+sections
+(SS)
+</ins></li><li><ins class="diff-chg">
+2014-02-04
+-
+ACTION-120
+(Part
+3)
+Added
+ldp:member
+(SS)
+</ins></li><li><ins class="diff-chg">
+2014-02-04
+-
+ACTION-120
+(Part
+2)
+Added
+concepts
+of
+containers
+(basic,
+direct
+and
+indirect)
+to
+LDPC
+intro
+(SS)
+</ins></li><li><ins class="diff-chg">
+2014-01-30
+-
+ACTION-120
+(Part
+1)
+Added
+concepts
+of
+containers
+(basic,
+direct
+and
+indirect)
+(SS)
+</ins></li><li><ins class="diff-chg">
+2014-01-30
+-
+ACTION-123
+Added
+concepts
+of
+LDP-RDF-Resource
+and
+LDP-Binary-Resource
+(SS)
+</ins></li><li><ins class="diff-chg">
+2014-01-29
+-
+Fix
+up
+conformance
+section
+to
+use
+new
+LDP
+client
+section
+(SS)
+</ins></li><li><ins class="diff-chg">
+2014-01-21
+-
+Updated
+reference
+to
+LDP
+BP&G
+editor's
+draft
+and
+added
+ref
+to
+LDP-UCR
+(SS)
+</ins></li><li><ins class="diff-chg">
+2014-01-21
+-
+Removed
+redudant
+reqs
+that
+have
+been
+moved
+to
+</ins><a href="#ldpclient">
+<del class="diff-old">.
+24
+December
+1999.
+W3C
+Recommendation.
+URL:
+http://www.w3.org/TR/html401
+</del>
+</a>
+<del class="diff-old">[HTTP11]
+R.
+Fielding
+et
+al.
+Hypertext
+Transfer
+Protocol
+</del>
+<ins class="diff-chg">(SS)
+</ins></li><li><ins class="diff-chg">
+2014-01-21
+</ins>
+-
+<del class="diff-old">HTTP/1.1
+.
+June
+1999.
+RFC.
+URL:
+http://www.ietf.org/rfc/rfc2616.txt
+</del>
+<ins class="diff-chg">Fixed
+formating
+with
+>h2
+formatting
+(SS)
+</ins></li><li><ins class="diff-chg">
+2014-01-21
+-
+Put
+reference
+to
+</ins><a href="#base-specs"><ins class="diff-chg">
+base-specs
+</ins>
+</a>
+<del class="diff-old">[RDF-CONCEPTS]
+Graham
+Klyne;
+Jeremy
+Carroll.
+Resource
+Description
+Framework
+(RDF):
+Concepts
+</del>
+<ins class="diff-chg">into
+intro
+section
+(SS)
+</ins></li><li><ins class="diff-chg">
+2014-01-17
+-
+First
+attempt
+at
+correcting
+section
+ordering
+</ins>
+and
+<del class="diff-old">Abstract
+Syntax
+.
+10
+February
+2004.
+W3C
+Recommendation.
+URL:
+http://www.w3.org/TR/rdf-concepts/
+[RDF-SCHEMA]
+Dan
+Brickley;
+Ramanathan
+Guha.
+RDF
+Vocabulary
+Description
+Language
+1.0:
+RDF
+Schema
+.
+10
+February
+2004.
+W3C
+Recommendation.
+URL:
+http://www.w3.org/TR/rdf-schema
+</del>
+<ins class="diff-chg">anchors
+(SS)
+</ins></li><li><ins class="diff-chg">
+2014-01-02
+-
+ACTION-122
+Updated
+4.2.10,
+5.4.4,
+example
+8
++
+added
+5.2.11
+requiring
+rel=type
+for
+interaction
+model
+(JA)
+</ins></li><li><ins class="diff-chg">
+2014-01-02
+-
+ACTION-119
+Added
+5.4.15
+requiring
+ldp:created
+for
+indirect
+containers
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-11-27
+-
+ACTION-101
+Added
+informative
+</ins><a href="#security"><ins class="diff-chg">
+security
+</ins>
+</a>
+<del class="diff-old">[RFC2119]
+S.
+Bradner.
+Key
+words
+</del>
+<ins class="diff-chg">section
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-11-27
+-
+ACTION-100
+Added
+informative
+note
+to
+Ordering
+section
+that
+containers
+can
+be
+nested
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-11-18
+-
+Various
+editorial
+and
+validation
+fixes
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-11-12
+-
+Clean
+up
+some
+remnants
+of
+inlining
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-11-12
+-
+Clean
+up
+some
+overly
+specific
+language
+(implications
+that
+POST
+is
+the
+only
+way
+to
+create
+members,
+etc)
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-11-12
+-
+Resolve
+ACTION-112
+Update
+spec
+to
+reflect
+10/28
+resolution
+</ins>
+for
+<ins class="diff-new">Issue-81
+part
+1:
+new
+predicate
+names
+(JA)
+</ins></li><li><ins class="diff-new">
+2013-11-12
+-
+Fix
+respec
+messages
+that
+only
+show
+up
+on
+remote
+server,
+hit
+paging
+examples
+to
+remove
+appearance
+of
+inlining
+(JA)
+</ins></li><li><ins class="diff-new">
+2013-11-11
+-
+Resolve
+ACTION-113
+Update
+spec
+to
+reflect
+11/04
+resolution
+to
+remove
+303
+and
+have
+client
+</ins>
+use
+<ins class="diff-new">first/next
+links
+to
+detect
+paging
+(JA)
+</ins></li><li><ins class="diff-new">
+2013-10-25
+-
+Resolve
+ACTION-105
+Update
+spec
+to
+reflect
+9/30
+resolution
+moving
+Paging
+links
+to
+HTTP
+headers
+(JA)
+</ins></li><li><ins class="diff-new">
+2013-10-25
+-
+Resolve
+ACTION-110
+Update
+spec
+to
+reflect
+10/21
+resolution
+for
+normative
+changes
+to
+align
+vanilla/chocolate
+(JA)
+</ins></li><li><ins class="diff-new">
+2013-10-22
+-
+Resolve
+ACTION-109
+Update
+spec
+to
+reflect
+10/21
+resolution
+for
+ignoring
+triples
+on
+PUT
+(JA)
+</ins></li><li><ins class="diff-new">
+2013-10-22
+-
+Resolve
+ACTION-107
+Update
+spec
+to
+reflect
+10/07
+resolution
+on
+5.6.2
+LDPC
+deletion
+(JA)
+</ins></li><li><ins class="diff-new">
+2013-10-22
+-
+Resolve
+ACTION-102
+Make
+4.6.2
+informative,
+clarify
+that
+it
+re-states
+what
+http
+allows,
+and
+</ins>
+in
+<del class="diff-old">RFCs
+</del>
+<ins class="diff-chg">fact
+it
+applies
+</ins>
+to
+<del class="diff-old">Indicate
+Requirement
+Levels.
+</del>
+<ins class="diff-chg">all
+methods
+not
+just
+delete.
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-10-22
+-
+Resolve
+ACTION-103
+Change
+SHOULD
+to
+MUST
+in
+4.10.2.3
+"LDPR
+servers
+that
+initiate
+paging
+SHOULD
+respond
+to
+request
+..."
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-10-22
+-
+Resolve
+ACTION-108
+move
+restatements
+of
+HTTP
+et
+al.
+out
+of
+normative
+sections
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-10-22
+-
+Resolve
+ACTION-106
+5.3.5
+MUST
+->
+SHOULD
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-10-21
+-
+Mock
+up
+status
+code
+209
+Related
+Content
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-10-01
+-
+Mock
+up
+new
+section
+for
+rules
+declared
+to
+be
+non-normative
+restatements
+of
+info
+from
+other
+specs
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-10-01
+-
+Revising
+terminology
+-
+membership
+triples
+and
+friends
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-10-01
+-
+Revising
+introduction
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-10-01
+-
+Conformance
+section
+drafting
++
+mock
+up
+"LDP
+Clients"
+section
+as
+part
+of
+that
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-09-23
+-
+Remove
+client/server-initiated
+paging
+terms
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-09-17
+-
+Change
+must
+to
+MUST
+in
+</ins><a href="#ldpc-5_6_4"><ins class="diff-chg">
+5.6.4
+</ins>
+</a>
+<del class="diff-old">March
+1997.
+Internet
+RFC
+2119.
+URL:
+http://www.ietf.org/rfc/rfc2119.txt
+</del>
+<ins class="diff-chg">(SS)
+</ins></li><li><ins class="diff-chg">
+2013-09-17
+-
+Removed
+"at-risk"
+inlining
+feature
+from
+spec,
+</ins><a href="https://www.w3.org/2012/ldp/track/actions/98"><ins class="diff-chg">
+ACTION-98
+</ins>
+</a>
+<del class="diff-old">[RFC3864]
+G.
+Klyne;
+M.
+Nottingham;
+J.
+Mogul.
+Registration
+Procedures
+</del>
+<ins class="diff-chg">(SS)
+</ins></li><li><ins class="diff-chg">
+2013-09-17
+-
+Fixed
+vanishing
+section
+ref
+problem
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-08-19
+-
+Basic
+preparation
+</ins>
+for
+<del class="diff-old">Message
+Header
+Fields
+.
+September
+2004.
+RFC.
+URL:
+http://www.ietf.org/rfc/rfc3864.txt
+[RFC3987]
+M.
+Dürst;
+M.
+Suignard.
+</del>
+<ins class="diff-chg">edits
+unto
+LC
+draft
+(SS)
+</ins></li></ul><blockquote>
+<del class="diff-old">Internationalized
+Resource
+Identifiers
+(IRIs)
+</del>
+<em>
+<del class="diff-old">.
+January
+2005.
+RFC.
+URL:
+http://www.ietf.org/rfc/rfc3987.txt
+</del>
+<a href="http://www.w3.org/TR/2013/WD-ldp-20130730/">
+<ins class="diff-chg">Last
+Call
+Draft
+</ins>
+</a>
+<del class="diff-old">[RFC4627]
+</del>
+</em>
+<del class="diff-old">D.
+Crockford.
+</del>
+</blockquote>
+<ul>
+<li>
+<ins class="diff-chg">2013-07-24
+-
+Moved
+4.7.2
+(from
+HEAD)
+to
+4.3.2
+(GET),
+shifted
+rest
+of
+GET
+section
+by
+one
+(SS)
+</ins></li><li><ins class="diff-chg">
+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)
+</ins></li><li><ins class="diff-chg">
+2013-07-24
+-
+Changed
+ldp:ascending->ldp:Ascending,
+ldp:descending->ldp:Descending,
+ldp:non-member-resource
+->ldp:nonMemberResource
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-07-24
+-
+Added
+term
+"Page
+resource"
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-07-24
+-
+Removed
+5.4.8.1
+and
+added
+4.2.12
+to
+better
+handle
+base/rel
+URI
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-07-23
+-
+Added
+informative
+</ins><a href="#ldpr-informative" class="sectionRef">
+<del class="diff-old">The
+application/json
+Media
+Type
+for
+JavaScript
+Object
+Notation
+(JSON)
+(RFC
+4627)
+</del>
+</a>,
+<ins class="diff-chg">therefore
+shifting
+all
+sections
+by
+one
+4.1->4.2,
+etc
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-07-23
+-
+Changed
+</ins><a href="#header-accept-post" class="sectionRef">
+<del class="diff-old">.
+July
+2006.
+RFC.
+URL:
+http://www.ietf.org/rfc/rfc4627.txt
+</del>
+</a>
+<del class="diff-old">[RFC5023]
+J.
+Gregorio;
+B.
+de
+hOra.
+The
+Atom
+Publishing
+Protocol
+.
+October
+2007.
+RFC.
+URL:
+http://www.ietf.org/rfc/rfc5023.txt
+</del>
+<ins class="diff-chg">to
+at
+risk
+as
+possibly
+moving
+to
+IETF
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-07-23
+-
+ISSUE-53
+4.2.3
+changed
+MUST
+to
+SHOULD
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-07-22
+-
+ISSUE-53
+4.2.2
+changed
+MUST
+to
+SHOULD
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-07-17
+-
+Various
+updates
+from
+suggests
+from
+</ins><a href="http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0067.html"><ins class="diff-chg">
+Raúl
+</ins>
+</a>
+<del class="diff-old">[RFC5789]
+L
+Dusseault;
+J.
+Snell.
+</del>
+<ins class="diff-chg">(SS)
+</ins></li><li><ins class="diff-chg">
+2013-07-15
+-
+Inserted
+ldp:insertedContentRelation
+into
+examples
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-07-15
+-
+ISSUE-79
+ldp:contains
+=>
+ldp:created
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-07-11
+-
+Improving
+working
+in
+</ins><a href="#ldpr-Paging" class="sectionRef">
+<del class="diff-old">PATCH
+Method
+</del>
+</a>
+<ins class="diff-chg">to
+remove
+container
+references
+(SS)
+</ins></li><li><ins class="diff-chg">
+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)
+</ins></li><li><ins class="diff-chg">
+2013-07-11
+-
+Removed
+all
+stubbed
+out
+sections
+5.1.3,
+5.3.2-6
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-07-11
+-
+Various
+editorial
+clean
+up
+items
+from
+editor
+todo
+list
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-07-11
+-
+Removed
+closed
+issues
+that
+required
+no
+new
+spec
+changes:
+50,
+56,
+16,
+19,
+17
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-07-11
+-
+ISSUE-51
+Added
+how
+a
+LDPR
+can
+show
+which
+LDPC
+is
+it
+in
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-07-10
+-
+Removed
+closed
+issues
+that
+required
+no
+new
+spec
+changes:
+18,
+35,
+20
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-07-10
+-
+ISSUE-44
+move
+section
+4.1.7
+(relationships
+are
+simple
+RDF
+links)
+to
+guidance
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-07-10
+-
+ISSUE-72
+take
+2
+-
+added
+ldp:MemberSubject
+to
+handle
+default
+case
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-07-10
+-
+ISSUE-72
+adding
+5.2.10
+</ins>
+for
+<del class="diff-old">HTTP
+(RFC
+5789)
+.
+March
+2010.
+RFC.
+URL:
+http://tools.ietf.org/html/rfc5789
+</del>
+<ins class="diff-chg">ldp:insertedContentRelation
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-07-09
+-
+ISSUE-58
+inlining
+-
+actions
+87-89
+inclusive
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-07-08
+-
+Moved
+5.7.*
+sections
+out
+of
+HEAD
+and
+into
+OPTIONS
+as
+5.9.*,
+added
+4.6.2
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-07-08
+-
+ISSUE-15
+Inserted
+5.4.12,
+5.6.4,
+5.7.2
+to
+describe
+link-relation
+meta
+usage
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-07-08
+-
+ISSUE-79
+ldp:contains
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-07-08
+-
+ISSUE-80
+Accept-Post
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-07-08
+-
+ISSUE-32
+Must
+support
+options
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-07-08
+-
+ISSUE-78
+No
+client
+inferencing
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-07-08
+-
+ISSUE-77
+Move
+"must
+have
+rdf:type
+explicitly"
+to
+Best
+Practices
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-07-08
+-
+ISSUE-57
+Knowing
+it's
+an
+LDP
+server
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-07-01
+-
+ISSUE-33
+Moved
+5.1.3
+Paging
+(LDPC)
+to
+4.8
+(LDPR)
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-06-18
+-
+ISSUE-75
+5.2.5
+membershipxxx
+predicates
+required,
+per
+2013-06-18
+F2F
+resolution
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-06-18
+-
+ISSUE-63
+End
+of
+5.3
++
+example
+rewritten
+for
+2013-06-18
+F2F
+resolution
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-06-15
+-
+ISSUE-14
+End
+of
+5.3
++
+example
+rewritten
+for
+ascending/descending
+sorts
+with
+optional
+collation
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-06-13
+-
+ISSUE-54
+New
+5.4.8.1
+to
+set
+base
+URI
+on
+create
+for
+relative
+URI
+resolution
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-06-10
+-
+ISSUE-74
+4.4.2
+require
+428
+Condition
+Required
+status
+code
+when
+appropriate;
+SS
+adding
+6585
+to
+biblio
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-06-05
+-
+ISSUE-64
+Remove
+?non-member-properties;
+5.1.2,
+5.3.2,
+5.5.2
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-05-21
+-
+ISSUE-35
+Re-use
+of
+URIs
+on
+create;
+5.2.9,
+5.4.11,
+5.5.4
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-05-21
+-
+ISSUE-43
+Slug
+in
+LDPC
+POSTs;
+5.4.8,
+5.4.10
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-05-21
+-
+ISSUE-65
+Remove
+firstPage
+in
+favor
+of
+Link
+rel=first,
+mostly
+hits
+5.3.3/5.3.4
+(JA)
+</ins></li><li><ins class="diff-chg">
+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)
+</ins></li><li><ins class="diff-chg">
+2013-05-17
+-
+Tweaks
+to
+Terminology
+section
+for
+LDPR
+and
+LDPC
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-05-17
+-
+ISSUE-9
+Moved
+section
+4.1.7
+out
+of
+spec
+to
+the
+</ins><a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Servers_should_serve_up_canonical_URLs"><ins class="diff-chg">
+deployment
+guide
+</ins>
+</a>
+<del class="diff-old">[RFC5988]
+Mark
+Nottingham.
+Web
+Linking
+(RFC
+5988)
+</del>
+<ins class="diff-chg">(SS)
+</ins></li><li><ins class="diff-chg">
+2013-05-15
+-
+Updated
+wording
+for
+5.2.2
+from
+to
+be
+more
+clear
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-05-13
+-
+ISSUE-49
+Moved
+section
+4.1.4
+out
+of
+spec
+to
+the
+</ins><a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Predicate_URIs_SHOULD_be_HTTP_URLs"><ins class="diff-chg">
+deployment
+guide
+</ins>
+</a>.
+<del class="diff-old">October
+2010.
+RFC.
+URL:
+http://www.ietf.org/rfc/rfc5988.txt
+[RFC6585]
+M.
+Nottingham;
+R.
+Fielding.
+</del>
+<ins class="diff-chg">(SS)
+</ins></li><li><ins class="diff-chg">
+2013-05-08
+-
+Removed
+closed
+issues
+5,
+7,
+55
+and
+38
+as
+the
+don't
+require
+edits.
+Added
+64
+and
+65.
+(SS)
+</ins></li><li><ins class="diff-chg">
+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)
+</ins></li><li><ins class="diff-chg">
+2013-04-15
+-
+ISSUE-21
+Added
+ldp:containedByRelation
+to
+5.2.5
+&
+5.5.2,
+created
+5.2.5.1
+&
+5.3.5.2
+to
+indicate
+difference.
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-04-15
+-
+ISSUE-39
+Moved
+informative
+text
+from
+5.4.5
+into
+5.4.1,
+shifted
+subsections
+.6-.10
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-04-15
+-
+Expanded
+on
+wording
+for
+4.3
+to
+be
+more
+consistent
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-04-08
+-
+Fixed
+two
+old
+references
+to
+BPR
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-03-17
+-
+Inserted
+examples
+2&3,
+a
+more
+complete
+NetWorth
+resource
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-03-15
+-
+Update
+LDPC
+glossary
+term
+based
+on
+Cody's
+feedback
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-03-15
+-
+</ins>
+Additional
+<del class="diff-old">HTTP
+Status
+Codes
+.
+April
+2012.
+RFC.
+URL:
+http://www.ietf.org/rfc/rfc6585.txt
+[SPARQL-QUERY]
+Eric
+Prud'hommeaux;
+Andy
+Seaborne.
+SPARQL
+Query
+Language
+</del>
+<ins class="diff-chg">fix
+in
+5.2.2
+</ins>
+for
+<del class="diff-old">RDF
+</del>
+<ins class="diff-chg">ISSUE-34
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-03-15
+-
+Remove
+reference
+to
+closed
+issues
+that
+don't
+require
+edits:
+ISSUE-27
+&
+ISSUE-45
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-03-14
+-
+General
+prep
+for
+3rd
+draft,
+cleanup
+and
+a
+little
+restructure
+(SS)
+</ins></li></ul><blockquote>
+<del class="diff-old">.
+15
+January
+2008.
+W3C
+Recommendation.
+URL:
+http://www.w3.org/TR/rdf-sparql-query/
+</del>
+<em>
+<del class="diff-old">[SPARQL-UPDATE]
+</del>
+<a href="http://www.w3.org/TR/2013/WD-ldp-20130307/">
+<ins class="diff-chg">Second
+Public
+Working
+Draft
+</ins></a>
+<del class="diff-old">Paul
+Gearon;
+Alexandre
+Passant;
+Axel
+Polleres.
+</del>
+</em>
+</blockquote>
+<ul>
+<li>
+<ins class="diff-chg">2013-03-14
+-
+Fixed
+up
+broken
+fragments
+and
+typos
+before
+publication
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-03-04
+-
+Comments
+received
+from
+David
+Wood:
+5.3.7
+&
+5.1.3
+clarity,
+other
+minor
+edits
+(part
+2)
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-03-04
+-
+Comments
+received
+from
+David
+Wood:
+abstract,
+paging
+informative
+(part
+1)
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-03-04
+-
+ISSUE-36
+-
+Added
+informative
+text
+regarding
+creationg
+of
+containers
+in
+5.4.4
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-03-04
+-
+ISSUE-12
+-
+Added
+section
+4.7.3
+not
+to
+allow
+PATCH
+for
+create
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-03-03
+-
+Adjustments
+to
+language
+about
+different
+container
+behavior
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-03-02
+-
+Adding
+trailing
+'/'
+on
+Container
+URLs
+to
+help
+with
+readability
+based
+on
+WG
+suggestion
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-02-26
+-
+Updated
+Acknowledgements
+section
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-02-25
+-
+ISSUE-29
+-
+Use
+relative
+URIs
+in
+examples
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-02-25
+-
+ISSUE-31
+-
+Added
+a
+more
+complete
+conformance
+section,
+motived
+by
+</ins>
+SPARQL
+1.1
+<del class="diff-old">Update
+.
+21
+March
+2013.
+W3C
+Recommendation.
+URL:
+http://www.w3.org/TR/sparql11-update/
+</del>
+<ins class="diff-chg">(SS)
+</ins></li><li><ins class="diff-chg">
+2013-02-25
+-
+Updating
+some
+simple
+formatting,
+reorganizing
+open
+issues
+and
+todos.
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-02-15
+-
+ISSUE-34
+-
+Aggregration:
+5.6.1
+and
+5.6.2
+updated
+for
+review.
+(JA)
+</ins></li><li><ins class="diff-chg">
+2013-02-13
+-
+ISSUE-42
+-
+4.8
+Common
+Properties
+moved
+to
+</ins><a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Re-use_established_linked_data_vocabularies_instead_of_.28re-.29inventing_duplicates"><ins class="diff-chg">
+Deploment
+Guide
+</ins>
+</a>
+<del class="diff-old">[TURTLE]
+David
+Beckett;
+Tim
+Berners-Lee.
+</del>
+<ins class="diff-chg">(JA)
+</ins></li><li><ins class="diff-chg">
+2013-02-12
+-
+Fixed
+up
+previous
+publication
+links
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-02-12
+-
+ISSUE-10
+-
+4.1.12
+to
+be
+MUST
+use
+entity
+tags
+(either
+weak
+or
+strong
+ones)
+(SS)
+</ins></li><li><ins class="diff-chg">
+2013-02-12
+-
+ISSUE-11
+-
+4.4.1
+Relaxed
+the
+MUST
+ignore
+dc:modified/creator
+to
+MAY
+(SS)
+</ins></li><li><ins class="diff-chg">
+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)
+</ins></li><li><ins class="diff-chg">
+2013-01-16
+-
+Added
+new
+issues
+ranging
+from
+26-43.
+Removed
+closed/deferred
+issues:
+2
+&
+3
+(SS)
+</ins></li><li><ins class="diff-chg">
+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)
+</ins></li><li><ins class="diff-chg">
+2012-11-05
+-
+minor
+rewording
+from
+ISSUE-24
+</ins></li><li><ins class="diff-chg">
+2012-11-03
+-
+ISSUE-22,
+ISSUE-23:
+changed
+sections
+4.2.3
+and
+5.4.7.
+Removed
+closed
+issues.
+(SS)
+</ins></li><li><ins class="diff-chg">
+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."
+</ins></li><li><ins class="diff-chg">
+2012-11-03
+-
+ISSUE-6
+Removed
+section
+4.1.9.
+Shifted
+up
+sections
+.10
+through
+.13.
+</ins></li><li><ins class="diff-chg">
+2012-11-01
+-
+Fixed
+minor
+typo
+and
+added
+some
+notes
+(SS)
+</ins></li></ul><blockquote>
+<del class="diff-old">Turtle:
+Terse
+RDF
+Triple
+Language
+</del>
+<em>
+<del class="diff-old">.
+January
+2008.
+W3C
+Team
+Submission.
+URL:
+http://www.w3.org/TeamSubmission/turtle/
+</del>
+<a href="http://www.w3.org/TR/2012/WD-ldp-20121025/">
+<ins class="diff-chg">First
+Public
+Working
+Draft
+</ins>
+</a>
+</em>
+<del class="diff-old">B.2
+Informative
+</del>
+</blockquote>
+<ul>
+<li>
+<ins class="diff-chg">2012-10-15
+-
+ISSUE-8
+Changed
+</ins>
+references
+<del class="diff-old">[LINKED-DATA]
+Tim
+Berners-Lee.
+</del>
+<ins class="diff-chg">from
+LDBP
+to
+LDP,
+removed
+definition
+for
+"profile"
+and
+new
+namespace
+(SS)
+</ins></li><li><ins class="diff-chg">
+2012-10-15
+-
+Included
+additional
+open
+ISSUES
+from
+Oct
+15
+WG
+meeting:
+22,
+23,
+24
+(SS)
+</ins></li><li><ins class="diff-chg">
+2012-10-14
+-
+Added
+open
+ISSUES
+and
+formating
+to
+prep
+for
+public
+working
+draft
+(SS)
+</ins></li><li><ins class="diff-chg">
+2012-09-20
+-
+Sent
+pull
+request
+re
+LINKED-DATA
+and
+added
+suggestion
+for
+</ins><code><ins class="diff-chg">
+ldp
+</ins></code><ins class="diff-chg">
+namespace
+(SS)
+</ins></li><li><ins class="diff-chg">
+2012-09-19
+-
+Repairing
+references
+and
+forward
+reference
+to
+biblio.js
+updates
+(SS)
+</ins></li><li><ins class="diff-chg">
+2012-09-19
+-
+Fixed
+rdfs:label
+range
+to
+be
+rdfs:Literal
+(SS)
+</ins></li><li><ins class="diff-chg">
+2012-09-19
+-
+ISSUE-1
+Define
+Turtle
+as
+the
+required
+serialization
+format
+for
+LDP
+(SS)
+</ins></li><li><ins class="diff-chg">
+2012-09-18
+-
+Initial
+ReSpec'ing
+of
+</ins><a href="http://www.w3.org/Submission/ldbp/"><ins class="diff-chg">
+Member
+Submission
+-
+</ins>
+Linked
+Data
+<del class="diff-old">Design
+Issues
+.
+27
+July
+2006.
+W3C-Internal
+Document.
+URL:
+http://www.w3.org/DesignIssues/LinkedData.html
+[RFC3986]
+T.
+Berners-Lee;
+R.
+Fielding;
+L.
+Masinter.
+Uniform
+Resource
+Identifier
+(URI):
+Generic
+Syntax
+(RFC
+3986)
+.
+January
+2005.
+RFC.
+URL:
+http://www.ietf.org/rfc/rfc3986.txt
+</del>
+<ins class="diff-chg">Basic
+Profile
+1.0
+</ins>
+</a>
+<del class="diff-old">[WEBARCH]
+Ian
+Jacobs;
+Norman
+Walsh.
+</del>
+<ins class="diff-chg">(SS)
+</ins></li><li><ins class="diff-chg">
+2012-09-18
+-
+Fixed
+up
+some
+links
+and
+worked
+on
+references,
+work
+left
+to
+do.
+(SS)
+</ins></li></ul><blockquote>
+<del class="diff-old">Architecture
+of
+the
+World
+Wide
+Web,
+Volume
+One
+</del>
+<em>
+<del class="diff-old">.
+15
+December
+2004.
+W3C
+Recommendation.
+URL:
+http://www.w3.org/TR/webarch/
+</del>
+<a href="http://www.w3.org/Submission/2012/SUBM-ldbp-20120326/">
+<ins class="diff-chg">Submission
+</ins>
+</a>
+</em>
+</blockquote>
+</section>
+</body>
+</html>
+
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp-paging.html Wed Mar 05 16:34:18 2014 +0000
@@ -0,0 +1,973 @@
+
+<!DOCTYPE html>
+<!--
+ TODO: Missing link header for equivalent of ldp:pageOf? Need to verify. Also we have ldp-paging:pageOf in samples
+ but it doesn't exist in rules or vocabulary doc, oversight?
+ TODO: Example 11 is missing ldp:contains, true? Omit due to GET on page resource, should make it more clear.
+ TODO: Paging intro: add 3rd example showing header link age amongst pages and (HEAD on) the base resource.
+ Maybe also insert HEAD on base as new first example instead of relying on text alone.
+ TODO: Missing namespace definition clause?
+ -->
+<html>
+ <head>
+ <title>Linked Data Platform Paging 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,
+ -->
+ <script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script>
+ <script class='remove'>
+ var respecConfig = {
+ // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+ specStatus: "ED",
+
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ shortName: "ldp-paging",
+
+ // if your specification has a subtitle that goes below the main
+ // formal title, define it here
+ // subtitle : "an excellent document",
+
+ // if you wish the publication date to be other than today, set this
+ publishDate: "",
+
+ // if the specification's copyright date is a range of years, specify
+ // the start date here:
+ // copyrightStart: "2005"
+
+ // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+ // and its maturity status
+ previousPublishDate: "2013-07-30",
+ previousMaturity: "LC",
+ previousURI: "http://www.w3.org/TR/2013/WD-ldp-20130730/",
+
+ // if there a publicly available Editor's Draft, this is the link
+ edDraftURI: "http://www.w3.org/2012/ldp/hg/ldp-paging.html",
+
+ // if this is a LCWD, uncomment and set the end of its review period
+ lcEnd: "2013-09-02",
+
+ // Only include h1 and h2 level
+ maxTocLevel: 2,
+
+ // if you want to have extra CSS, append them to this list
+ // it is recommended that the respec.css stylesheet be kept
+ //extraCSS: ["https://dvcs.w3.org/hg/ldpwg/css/respec.css"],
+
+ // editors, add as many as you like
+ // only "name" is required
+ editors: [
+ { name: "Steve Speicher", url: "http://stevespeicher.blogspot.com",
+ company: "IBM Corporation", companyURL: "http://ibm.com/" },
+ { name: "John Arwe", url: "https://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/allcommunities?userid=120000CAW7",
+ company: "IBM Corporation", companyURL: "http://ibm.com/" },
+ {name: "Ashok Malhotra", url: "mailto:ashok.malhotra@oracle.com",
+ company: "Oracle Corporation", companyURL: "http://www.oracle.com" },
+ ],
+
+ // authors, add as many as you like.
+ // This is optional, uncomment if you have authors as well as editors.
+ // only "name" is required. Same format as editors.
+
+ //authors: [
+ // { name: "Your Name", url: "http://example.org/",
+ // company: "Your Company", companyURL: "http://example.com/" },
+ //],
+
+ // name of the WG
+ wg: "Linked Data Platform Working Group",
+
+ // URI of the public WG page
+ wgURI: "http://www.w3.org/2012/ldp",
+
+ // name (without the @w3c.org) of the public mailing to which comments are due
+ wgPublicList: "public-ldp-comments",
+
+ // URI of the patent status for this WG, for Rec-track documents
+ // !!!! IMPORTANT !!!!
+ // This is important for Rec-track documents, do not copy a patent URI from a random
+ // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+ // Team Contact.
+ wgPatentURI: "http://www.w3.org/2004/01/pp-impl/55082/status",
+ doRDFa: "1.1",
+ localBiblio: {
+ "HTTPBIS-SEMANTICS": {
+ title: "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"
+ , href: "http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics/"
+ , authors: [
+ "R. Fielding"
+ , "J. Reschke"
+ ]
+ , status: "In Last Call"
+ , publisher: "IETF"
+ },
+ "RFC2817": {
+ title: "Upgrading to TLS Within HTTP/1.1"
+ , href: "http://tools.ietf.org/html/rfc2817"
+ , authors: [
+ "R. Khare"
+ , "S. Lawrence"
+ ]
+ , status: "Proposed Standard"
+ , publisher: "IETF"
+ },
+ "RFC5005": {
+ title: "Feed Paging and Archiving"
+ , href: "http://tools.ietf.org/html/rfc5005"
+ , authors: [
+ "M. Nottingham"
+ ]
+ , status: "Proposed Standard"
+ , publisher: "IETF"
+ }
+ },
+ };
+ </script>
+ <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;
+ }
+ .normal {
+ font-weight: normal;
+ font: normal 100% sans-serif;
+ }
+ .indented {
+ margin-left: +3em;
+ }
+ tr:nth-of-type(odd),.oddrow {
+ background:#F2F2F2; /* light grey, just enough to differentiate from white */
+ }
+ td {
+ padding:0 +1ex 0 +1ex; /* add a bit of space from rule/edge to text */
+ }
+
+ </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>
+ </head>
+<body>
+<section id='abstract'>
+This document describes a model for clients and servers to be able to efficiently retrieve large Linked Data Platform
+Resources representations by splitting up the responses into separate URL-addressable page resources.
+</section>
+
+<section class="informative" id="intro">
+<h1>Introduction</h1>
+ <p>This specification provides a widely re-usable pattern to deal with large resources.
+ Depending on the server’s capabilities, a GET request on a <a title="Paged resource">resource</a> can
+ be redirected to a <a title="Single-page resource">subset of the resource (one page)</a>, that provides access to subsequent pages
+ (see <a href="#ldpr-Paging" class="sectionRef"></a>).
+ </p>
+ <p>For context and background, it could be useful to read <a href="#bib-LDP-UCR">Linked Data Platform Use Case and Requirements</a> [[LDP-UCR]]
+ and <a href="#base-specs" class="sectionRef"></a>.</p>
+</section>
+
+<section id="terms">
+<h1>Terminology</h1>
+
+<p>Terminology is based on W3C's Architecture of the World Wide Web [[WEBARCH]], Hyper-text Transfer Protocol [[HTTP11]] and Linked Data Platform [[LDP]].
+</p>
+ <dl class="glossary">
+ <dt><dfn>Paged resource</dfn></dt>
+ <dd>A LDP-RS whose representation may be too large to fit in a single HTTP response, for which an
+ LDP server offers a sequence of single-page <a title="Linked Data Platform RDF Source">LDP-RSs</a>.
+ When the representations of the sequence's resources
+ are combined by a client, the client has a (potentially incomplete or incoherent) copy of the paged resource's
+ state. If a paged resource <var>P</var> is a LDP-RS and is broken into a sequence of pages
+ (single-page resources) <var>P<sub>1</sub>, P<sub>2</sub>, ...,P<sub>n</sub></var>,
+ the representation of each <var>P<sub>i</sub></var> contains
+ a subset of the triples in <var>P</var>.
+ LDP allows paging of resources other than <a title="Linked Data Platform RDF Source">LDP-RSs</a>,
+ but does not specify how clients combine
+ their representations. See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details. For readers
+ familiar with paged feeds [[RFC5005]], a paged resource is similar to a logical feed.
+ Any resource could be considered to be a paged resource consisting of exactly one page,
+ although there is no known advantage in doing so.
+ <p></p></dd>
+
+ <dt><dfn>Single-page resource</dfn></dt>
+ <dd>One of a sequence of related <a title="Linked Data Platform RDF Source">LDP-RSs</a>
+ <var>P<sub>1</sub>, P<sub>2</sub>, ...,P<sub>n</sub></var>,
+ each of which contains a subset of the state
+ of another resource <var>P</var>. <var>P</var> is called the paged resource.
+ For readers
+ familiar with paged feeds [[RFC5005]], a single-page resource is similar to a feed document and the same
+ coherency/completeness considerations apply.
+ <a href="#ldpr-pagingGET-sequences-change">LDP provides no guarantees that the sequence is stable</a>.
+ <p>
+ Note: the choice of terms was designed to help authors and readers clearly differentiate between
+ the <a title="Paged resource"><em>resource being paged</em></a>, and the
+ <a title="Single-page resource"><em>individual page resources</em></a>,
+ in cases where both are mentioned in
+ close proximity.
+ <p></p></dd>
+
+ <dt><dfn>first page link</dfn></dt>
+ <dd>A link to the first <a title="Single-page resource">single-page resource</a>
+ of a <a title="Paged resource">paged resource</a> <var>P</var>. Syntactically, a
+ HTTP <code>Link <<var>P<sub>1</sub></var>>; rel='first'</code>
+ header [[!RFC5988]].
+ <p></p></dd>
+
+ <dt><dfn>next page link</dfn></dt>
+ <dd>A link to the next <a title="Single-page resource">single-page resource</a>
+ of a <a title="Paged resource">paged resource</a> <var>P</var>. Syntactically, a
+ HTTP <code>Link <<var>P<sub>i</sub></var>>; rel='next'</code>
+ header [[!RFC5988]] where the target URI is <var>P<sub>i=2...n</sub></var>.
+ <p></p></dd>
+
+ <dt><dfn>last page link</dfn></dt>
+ <dd>A link to the last <a title="Single-page resource">single-page resource</a>
+ of a <a title="Paged resource">paged resource</a> <var>P</var>. Syntactically, a
+ HTTP <code>Link <<var>P<sub>n</sub></var>>; rel='last'</code>
+ header [[!RFC5988]].
+ <p></p></dd>
+
+ <dt><dfn>previous page link</dfn></dt>
+ <dd>A link to the previous <a title="Single-page resource">single-page resource</a>
+ of a <a title="Paged resource">paged resource</a> <var>P</var>. Syntactically, a
+ HTTP <code>Link <<var>P<sub>i</sub></var>>; rel='prev'</code>
+ header [[!RFC5988]] where the target URI is <var>P<sub>i=1...n-1</sub></var>.
+ <p></p></dd>
+
+ </dl>
+
+<section id="conventions">
+<h2>Conventions Used in This Document</h2>
+
+ <p>Sample resource representations are provided in <code>text/turtle</code>
+ format [[turtle]].</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 foaf: <http://xmlns.com/foaf/0.1/>.
+ @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
+ @prefix ldp: <http://www.w3.org/ns/ldp#>.
+ @prefix ldp-paging: <http://www.w3.org/ns/ldp-paging#>.
+ @prefix xsd: <http://www.w3.org/2001/XMLSchema#>.</pre>
+</section>
+</section>
+
+<section id='conformance'>
+
+<p>The status of the sections of Linked Data Platform Paging 1.0 (this document) is as follows:</p>
+<p><em>TODO</em>: Update this section list</p>
+<ul>
+ <li>1. Introduction: <b>non-normative</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>non-normative</b></li>
+ <li>B.1 Normative references: <b>normative</b></li>
+ <li>B.2 Non-normative references: <b>non-normative</b></li>
+</ul>
+
+<p>A conforming <b><dfn>LDP Paging client</dfn></b> is a conforming LDP client [[!LDP]] that follows the rules defined by LDP.
+</p>
+
+<p>A conforming <b><dfn>LDP Paging server</dfn></b> is a conforming LDP server [[!LDP]] that follows the rules defined by LDP.</p>
+</section>
+
+<section id="ldppclient">
+<h1>Linked Data Platform Paging Clients</h1>
+<p>All of the following are conformance rules for <a title="LDP Paging client">LDP Paging Clients</a>.
+</p>
+<section><h2>General</h2>
+
+ <section id="ldpp-server-initiated"><h2 class="normal"><a title="LDP Paging client">LDP Paging clients</a> MUST
+ be paging-aware in cases where LDP Paging servers initiate paging.
+ </h2>
+ <p><em>TODO</em>: Confirm this client MUST for server-initiated paging</p>
+ </section>
+
+</section>
+</section> <!-- Client constraints -->
+
+<section id="ldpr">
+<h1>Linked Data Platform Resources</h1>
+
+<section class="informative" id="ldpr-informative">
+<h2>Introduction</h2>
+ <p>Linked Data Platform Resources (<dfn><abbr title="Linked Data Platform Resources">LDPRs</abbr></dfn>) are HTTP resources
+ that conform to the simple patterns and conventions in this section.
+ HTTP requests to access, modify, create or delete LDPRs are accepted
+ and processed by <a title="LDP server">LDP servers</a>. Most LDPRs 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 [[LINKED-DATA]];
+ others address additional needs.</p>
+ <p>The following sections define the conformance rules for LDP servers when serving LDPRs.
+ This document also explains <a href="#ldpr-Paging">how a server paginates an LDP-RS's representation</a> if it gets too big.
+ Companion non-normative documents describe additional guidelines for use when interacting with LDPRs.
+ </p>
+</section>
+
+<section id="ldpr-Paging">
+<h2>Paging</h2>
+
+<section class="informative" id="ldpr-PagingIntro">
+
+<h3>Introduction</h3>
+ <p>It sometimes happens that a
+ resource is too large to reasonably transmit its representation in a
+ single HTTP response.
+ To address this problem, servers should support a technique called Paging.
+ When a client retrieves such a resource, the server redirects the client to a "first page" resource, and includes in its response
+ a link to the next part of the resource's state, all at a URLs of the server's choosing.
+ The triples in the representation of the <a title="Single-page resource">each page of an LDPR</a>
+ are typically a subset of the triples from the <a title="Paged resource">paged resource</a>.
+ </p>
+ <p><a title="LDP server">LDP servers</a> may respond to requests for a
+ resource by redirecting to the first page of the resource and, with that, returning
+ a <code>Link <next-page-URL>;type='next'</code> header containing the URL for the next page.
+ Clients inspect each response for the link header to see if additional pages
+ are available; paging does not affect the choice of HTTP status code.
+ Note that paging is lossy, as described in [[RFC5005]], and so (as stated there)
+ clients should not make any assumptions about a set of pages being a complete or
+ coherent snapshot of a resource's state.</p>
+ <p>
+ Looking at an example resource representing Example Co.'s customer
+ relationship data, identified by the URI <code>http://example.org/customer-relations</code>,
+ we’ll split the response across two pages.
+ The client
+ retrieves <code>http://example.org/customer-relations</code>, and
+ the server responds with <a href="#atrisk-333">status code <code>333 (Returning Related)</code></a>,
+ a <code>Location: http://example.org/customer-relations?page1</code> HTTP response header,
+ and the following representation:
+ </p>
+
+<pre class="example" id="ldpc-ex-page1"># The following is the representation of
+# http://example.org/customer-relations?page1
+# Requests on the URI will result in responses that include the following HTTP header
+# Link: <http://example.org/customer-relations?p=2>; rel='next'
+# This Link header is how clients discover the URI of the next page in sequence,
+# and that the resource supports paging.
+@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/>.
+@base <http://example.org/customer-relations>.
+
+<>
+ a o:CustomerRelations;
+ dcterms:title "The customer information for Example Co.";
+ o:client <#JohnZSmith>, <#BettyASmith>, <#JoanRSmith>.
+
+<#JohnZSmith>
+ a foaf:Person;
+ o:status o:ActiveCustomer;
+ foaf:name "John Z. Smith".
+<#BettyASmith>
+ a foaf:Person;
+ o:status o:PreviousCustomer;
+ foaf:name "Betty A. Smith".
+ <#JoanRSmith>
+ a foaf:Person;
+ o:status o:PotentialCustomer;
+ foaf:name "Joan R. Smith".</pre>
+
+ <p>
+ Because the server includes a <code>Link: <http://example.org/customer-relations?p=2>; rel='next'</code>
+ response header, and the status code is 3xx (<code>333 (Returning Related)</code> in this case),
+ the client knows that more data exists and where to find it.
+ The server determines the size of the pages using application specific methods not defined
+ within this specificiation. The next page link's target URI is also
+ defined by the server and not this specification.
+ </p>
+ <p>
+ The following example is the result of retrieving
+ the next page;
+ the server responds with status code <code>200 (OK)</code> and the following representation:
+ </p>
+
+<pre class="example" id="ldpc-ex-page2"># The following is the representation of
+# http://example.org/customer-relations?p=2
+#
+# There is no "next" Link in the server's response, so this is the final page.
+#
+@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/>.
+@base <http://example.org/customer-relations>.
+
+<>
+ o:client <#GlenWSmith>, <#AlfredESmith>.
+
+<#GlenWSmith>
+ a foaf:Person;
+ o:status o:ActiveCustomer, o:GoldCustomer;
+ foaf:name "Glen W. Smith".
+
+<#AlfredESmith>
+ a foaf:Person;
+ o:status o:ActiveCustomer, o:BronzeCustomer;
+ foaf:name "Alfred E. Smith".
+ </pre>
+ <p>
+ In this example, there are only two customers provided in the
+ final page. To indicate this is the last page, the server omits the <code>Link: rel='next'</code>
+ header in its response.
+ </p>
+ <p>
+ As mentioned above, retrieving all the pages offered by a server gives no guarantee to a client
+ that it knows the entire state of the server. For example, after the server constructs the
+ the first page representation, another
+ actor could delete <code>client#BettyASmith</code> from the server.
+ </p>
+</section>
+
+<section id="ldpr-PagingGET">
+<h3>HTTP GET</h3>
+ <p>In addition to the requirements set forth in <a href="#ldpr-HTTP_GET" class="sectionRef"></a> on HTTP <code>GET</code>,
+ <a title="LDP server">LDP servers</a> that support paging must
+ also follow the requirements in this section for all <a title="Paged resource">paged resources</a>
+ and their associated <a title="Single-page resource">single-page resources</a>.
+ </p>
+
+ <section id="ldpr-page-large"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to retrieve large LDP-RSs in
+ pages.
+ See <a href="#ldpr-Paging" class="sectionRef"></a> for additional requirements associated with <a title="Paged resource">paged resources</a>.
+ </h2></section><!-- Was 4.2.14 / #ldpr-4_2_14 -->
+
+ <section id="ldpr-split-any"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
+ treat any resource (LDP-RS or not) as a <a title="Paged resource">paged resource</a>.
+ See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.
+ </h2></section><!-- Was 4.2.15 / #ldpr-4_2_15 -->
+
+ <section id="ldpr-pagingGET-sequences-change"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
+ add <a title="Single-page resource">single-page resources</a> to a
+ <a title="Paged resource">paged resource's</a> sequence over time,
+ but SHOULD only add pages to the end of a sequence.
+ </h2><!-- Was 4.10.2.1 / #ldpr-pagingGET-sequences-change -->
+ <blockquote>Non-normative note:
+ As a result, clients retrieving any <a title="Single-page resource">single-page resource</a> several times can observe its place in the sequence
+ change as the state of the <a title="Paged resource">paged resource</a> changes.
+ For example, a nominally last page's server might provide a
+ <a>next page link</a> when the page is retrieved. Similar situations arise when the page sequence crosses server boundaries;
+ server A might host the initial portion of a sequence that links to the last page server A is aware of,
+ hosted on server B, and server B might extend the sequence of pages.
+ </blockquote>
+
+ <section id="ldpr-pagingGET-first-allowed-onpages"><h2 class="normal">
+ <a title="LDP server">LDP servers</a> MAY provide
+ a <a>first page link</a> when responding to
+ requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
+ </h2></section><!-- Was 4.10.2.1.1 / #ldpr-pagingGET-sequences-change -->
+
+ <section id="ldpr-pagingGET-last-allowed-onpages"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
+ provide a <a>last page link</a>
+ in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
+ </h2></section><!-- Was 4.10.2.1.3 / #ldpr-pagingGET-last-allowed-onpages -->
+ </section>
+
+ <section id="ldpr-pagingGET-next-reqd"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST
+ provide a <a>next page link</a>
+ in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a>
+ <em>other than the final page</em>
+ as the <code>Request-URI</code>.
+ This is the mechanism by which clients can discover the URL of the next page.
+ </h2><!-- Was 4.10.2.2 / #ldpr-pagingGET-next-reqd-change -->
+
+ <section id="ldpr-pagingGET-lastnext-prohibited"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST NOT
+ provide a <a>next page link</a>
+ in responses to <code>GET</code> requests with the final <a title="Single-page resource">single-page resource</a>
+ as the <code>Request-URI</code>.
+ This is the mechanism by which clients can discover the end of the page sequence
+ as currently known by the server.
+ </h2></section><!-- Was 4.10.2.2.1 / #ldpr-pagingGET-lastnext-prohibited -->
+
+ <section id="ldpr-pagingGET-prev-allowed"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
+ provide a <a>previous page link</a>
+ in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a>
+ <em>other than the first page</em>
+ as the <code>Request-URI</code>.
+ This is one mechanism by which clients can discover the URL of the previous page.
+ </h2></section><!-- Was 4.10.2.2.2 / #ldpr-pagingGET-prev-allowed -->
+
+ <section id="ldpr-pagingGET-firstprev-prohibited"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST NOT
+ provide a <a>previous page link</a>
+ in responses to <code>GET</code> requests with the <em>first</em> <a title="Single-page resource">single-page resource</a>
+ as the <code>Request-URI</code>.
+ This is one mechanism by which clients can discover the beginning of the page sequence
+ as currently known by the server.
+ </h2></section><!-- Was 4.10.2.2.3 / #ldpr-pagingGET-firstprev-prohibited -->
+ </section>
+
+ <section id="ldpr-pagingGET-page-type-reqd"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST
+ provide an HTTP <code>Link</code>
+ header whose target URI is <code>http://www.w3.org/ns/ldp-paging#Page</code>, and whose link relation type is <code>type</code> [[!RFC5988]]
+ in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a>
+ as the <code>Request-URI</code>.
+ This is one mechanism by which clients know that the resource is one of a sequence of pages.
+ </h2></section><!-- Was 4.10.2.4 / #ldpr-pagingGET-page-type-reqd -->
+
+ <div class="atrisk" id="atrisk-333"><p class="atrisktext">Feature At Risk</p>
+ <p>The LDP Working Group proposes incorporation of the features described in the next compliance clause.</p>
+ <ul>
+ <li><p>
+ A <a href="http://lists.w3.org/Archives/Public/www-tag/2013Dec/0041.html">TAG discussion</a> has started,
+ whose goal is to reduce the need for two request-response round trips down to one when retrieving what
+ turns out to be the first page of a paged resource, by defining a new
+ HTTP response code in the <code>2xx</code> or <code>3xx</code> class that would allow a server to
+ respond to <code>GET request-uri</code> requests with the representation of the first page
+ (whose URI is <code>first-page-uri</code>, not <code>request-uri</code>) of a multi-page response.
+ </p></li>
+ <li><p>
+ For the purposes of drafting this section, we assume that the
+ new code's value is <code>333 (Returning Related)</code>,
+ <a href="http://lists.w3.org/Archives/Public/www-tag/2014Jan/0023.html">an LDP extrapolation from TAG discussions,</a>
+ and its definition is given by
+ <a href="http://lists.w3.org/Archives/Public/www-tag/2014Jan/0015.html">Henry Thompson's strawman</a>, with the substitution of 333 for 2xx.
+ Note: nothing prevents servers or clients from using <code>303 See Other</code> responses to
+ requests for <a title="Paged resource">paged resources</a>. The only significant difference between 303 and 333 responses
+ is the extra round trip required for the client to retrieve the representation of the first page when using 303.
+ </p></li>
+ <li><p>
+ Once LDP-Paging is a
+ Candidate Recommendation, the LDP WG will make an assessment based on the status at IETF,
+ working with the W3C Director, to either use the newly defined response code
+ as documented in this section or to revert to a classic
+ <code>303</code> response pattern.
+ </p></li>
+ </ul>
+ </div>
+
+ <section id="ldpr-status-code"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD respond
+ with HTTP status code <code>333 (Returning Related)</code>
+ to successful <code>GET</code> requests with any <a title="Paged resource">paged resource</a>
+ as the <code>Request-URI</code>, although any appropriate code MAY be used.
+ </h2></section>
+</section>
+
+</section> <!-- h2 -->
+
+</section> <!-- h1 -->
+
+<section id="ldpc">
+<h1>Linked Data Platform Containers</h1>
+
+<section class="informative" id="ldpc-informative">
+<h2>Introduction</h2>
+ <p>Many HTTP applications and sites have organizing
+ concepts that partition the overall space of resources into smaller
+ containers. Blog posts are grouped into blogs, wiki pages are grouped
+ 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. LDP Paging Containers answer some basic questions, which
+ are:</p>
+ <ol>
+ <li>How is the order of the container entries expressed?</li>
+ </ol>
+
+ <section id="ldpc-ordering"><h2 class="normal">Ordering</h2>
+ <p>
+ There are many cases where an ordering of the members of the
+ container is important. LDPC 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, LDPC avoids the use of RDF
+ constructs like Seq and List for expressing order.
+ </p>
+ <p>
+ Order becomes more important for <a title="LDP server">LDP servers</a> 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 LDPC 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
+ sort order no lower than all members on the previous page and
+ sort order no higher than all the members on the next page;
+ that is, it proceeds from low to high, but keep in mind that several
+ consecutive pages might have members whose sort criteria are equal.
+ When the sort is descending, the opposite order is used.
+ Since more than one value may be used to sort members,
+ the LDPC specification allows servers to assert the ordered list
+ of sort criteria used to sort the members, using the
+ <code>ldp-paging:containerSortCriteria</code> relation.
+ Each member of the ordered list exposes one <code>ldp-paging:containerSortCriterion</code>,
+ consisting of a <code>ldp-paging:containerSortOrder</code>,
+ <code>ldp-paging:containerSortPredicate</code>, and
+ optionally a <code>ldp-paging:containerSortCollation</code>.
+ </p>
+ <p>Here is an example container described
+ previously, with representation for ordering of the assets:</p>
+<pre class="example" id="ldpc-ex-ordering">
+# The following is the ordered representation of
+# http://example.org/netWorth/nw1/assetContainer/
+<!-- @base is here only so it's easier to paste into validators for checking -->
+# @base <http://example.org/netWorth/nw1/assetContainer/>
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix ldp-paging: <http://www.w3.org/ns/ldp-paging#>.
+@prefix o: <http://example.org/ontology/>.
+
+<>
+ a ldp:DirectContainer;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:membershipResource <http://example.org/netWorth/nw1>;
+ ldp:hasMemberRelation o:asset;
+ ldp:insertedContentRelation ldp:MemberSubject.
+
+<?firstPage>
+ a ldp-paging:Page;
+ ldp-paging:pageOf <>;
+ ldp-paging:containerSortCriteria (<#SortValueAscending>).
+
+<#SortValueAscending>
+ a ldp-paging:ContainerSortCriterion;
+ ldp-paging:containerSortOrder ldp-paging:Ascending;
+ ldp-paging: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>
+ <p>
+ As you can see by the addition of the <code>ldp-paging: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. Also
+ as it is possible for a container to have as its members other containers,
+ the ordering approach doesn't change as containers themselves are LDPRs and the
+ properties from the domain model can be leveraged for the sort criteria.
+ </p>
+ </section><!-- Was 5.1.2 / #ldpc-ordering -->
+</section>
+
+<section id="ldpc-general">
+<h2>General</h2>
+ <p>The Linked Data Platform does not define how clients
+ discover <dfn><abbr title="Linked Data Platform Containers">LDPCs</abbr></dfn>.</p>
+
+ <section id="ldpc-isldpr"><h2 class="normal">Each Linked Data Platform Paging Container MUST also be
+ a conforming Linked Data Platform Container.
+ </h2></section>
+
+ <section id="ldpp-prefer"><h2 class="normal">(From [[!LDP]])<a title="LDP server">LDP servers</a>
+ SHOULD respect all of a client's LDP-defined hints, for example
+ <a href="#prefer-parameters">which subsets of LDP-defined state</a>
+ the client is interested in processing,
+ to influence the set of triples returned in representations of an LDPC,
+ particularly for large LDPCs [[!LDP]].
+ Non-normative note: the LDPC might be paged; <a title="Paged resource">paged resources</a> provide
+ no guarantee that all triples of a given subset, for example
+ <a title="Containment triples">containment triples</a>,
+ are grouped together on one page or on a sequence of consecutive
+ <a title="Single-page resource">pages</a>
+ (see <a href="#ldpr-Paging" class="sectionRef"></a>).
+ </h2></section>
+ <!-- TODO: Need to rework this^ -->
+
+</section>
+
+<section id="ldpc-HTTP_GET">
+<h2>HTTP GET</h2>
+
+ <section id="ldpc-sortcriteriaobj"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
+ represent the members of a paged LDPC in a sequential
+ order. If the server does so, it MUST specify the order using a triple
+ whose subject is the page URI,
+ whose predicate is <code>ldp-paging:containerSortCriteria</code>,
+ and whose object is a <code>rdf:List</code> of
+ <code>ldp-paging:containerSortCriterion</code> resources.
+ The resulting order MUST be as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause
+ [[!sparql11-query]].
+ Sorting criteria MUST 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 <a href="#ldpc-ordering" class="sectionRef"></a> for
+ an example.
+ </h2></section><!-- Was 5.3.2 / #ldpc-5_3_2 -->
+
+ <section id="ldpc-sortliteraltype"><h2 class="normal">LDPC page representations
+ ordered using <code>ldp-paging:containerSortCriteria</code> MUST contain,
+ in every <code>ldp-paging:containerSortCriterion</code> list entry,
+ a triple
+ whose subject is the sort criterion identifier,
+ whose predicate is <code>ldp-paging:containerSortPredicate</code>
+ and whose object is
+ the predicate whose value is used to order members between pages (the <dfn>page-ordering values</dfn>).
+ The only literal data types whose behavior LDP constrains are those defined
+ by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause [[!sparql11-query]]. Other data types
+ can be used, but LDP
+ assigns no meaning to them and interoperability will be limited.
+ </h2></section><!-- Was 5.3.3 / #ldpc-5_3_3 -->
+
+ <section id="ldpc-sortorder"><h2 class="normal">LDPC page representations
+ ordered using <code>ldp-paging:containerSortCriteria</code> MUST contain,
+ in every <code>ldp-paging:containerSortCriterion</code> list entry,
+ a triple
+ whose subject is the sort criterion identifier,
+ whose predicate is <code>ldp-paging:containerSortOrder</code>
+ and whose object describes the order used.
+ LDP defines two values,
+ <code>ldp-paging:Ascending</code> and <code>ldp-paging: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.
+ </h2></section><!-- Was 5.3.4 / #ldpc-5_3_4 -->
+
+ <section id="ldpc-sortcollation"><h2 class="normal">LDPC page representations
+ ordered using <code>ldp-paging:containerSortCriteria</code> MAY contain,
+ in any <code>ldp-paging:containerSortCriterion</code> list entry,
+ a triple
+ whose subject is the sort criterion identifier,
+ whose predicate is <code>ldp-paging: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-paging:containerSortCollation</code> triple is absent and the
+ <a title="page-ordering values">page-ordering values</a> are strings or simple literals [[!sparql11-query]], the
+ resulting order is as defined by SPARQL SELECT’s ORDER BY clause
+ [[!sparql11-query]] 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-paging:containerSortCollation</code> triple is present and the
+ <a title="page-ordering values">page-ordering values</a> are strings or simple literals
+ [[!sparql11-query]], the
+ resulting order is as defined by SPARQL SELECT’s ORDER BY clause
+ [[!sparql11-query]] using three-argument <code>fn:compare</code>, that is, the
+ specified collation.
+ The <code>ldp-paging:containerSortCollation</code> triple MUST be omitted for comparisons
+ involving <a title="page-ordering values">page-ordering values</a> for which [[!sparql11-query]] does not use collations.
+ </h2></section><!-- Was 5.3.5 / #ldpc-5_3_5 -->
+
+</section> <!-- h2 -->
+
+</section> <!-- h1 LDPC -->
+
+
+<section id="base-specs" class="informative">
+<h1>Notable information from normative references</h1>
+<p>
+While readers, and especially implementers, of LDP are assumed to understand the information in its normative
+references, the working group has found that certain points are particularly important to understand.
+For those thoroughly familiar with the referenced specifications, these points might seem obvious, yet
+experience has shown that few non-experts find all of them obvious. This section enumerates these topics;
+it is simply re-stating (non-normatively) information locatable via the normative references.
+</p>
+
+<section id="specs-paging" class="informative">
+<h2>Feed paging and archiving</h2>
+Reference: [[RFC5005]]
+
+ <section id="ldp-paging-incomplete"><h2 class="normal">A <a title="LDP client">LDP client</a>
+ SHOULD NOT present <a title="paged resource">paged resources</a> as coherent or
+ complete, or make assumptions to that effect.
+ [[RFC5005]].
+ </h2></section>
+
+</section>
+
+</section> <!-- Base specs -->
+
+<section>
+<h1>HTTP Header Definitions</h1>
+
+<p><em>TBD</em></p>
+
+</section> <!-- Header defns -->
+
+<!-- Removed for action-113
+<section>
+<h1>HTTP Status Code Definitions</h1>
+
+<section id="status-code-related-content">
+<h2>209 Related Content</h2>
+
+ <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>209 Related Content</a> in this specification is pending
+ advancement of an <a href="https://datatracker.ietf.org/doc/draft-wilde-related-content/">IETF draft</a>
+ that would fully include it, patterned after the codes defined by [[RFC6585]]. Once LDP is in
+ Candidate Recommendation status, the LDP WG will make an assessment based on the status at IETF
+ working with the W3C Director.</li>
+ </ul>
+ </div>
+
+ <p>The <code>209 Related Content</code> status code indicates that the origin server
+ is supplying the representation of a different resource than the target resource,
+ and the origin server believes that the supplied representation
+ is likely to satisfy the user agent's original request.
+ The resource whose representation is supplied is descriptive of the target resource, in
+ the same way that the <code>Location</code> header in a <code>303 See Other</code>
+ response is descriptive of the target resource.
+ </p>
+ <p><code>209 Related Content</code> is intended to be used in situations where
+ <code>303 See Other</code> could have been used and would most likely result in a
+ user agent retrieving the other resource, but saves the user agent from
+ the latency penalty of having to perform a separate retrieval request.
+ </p>
+
+ <p> LDP uses <code>209 Related Content</code> to provide clients with the
+ <a href="#ldpr-Paging">first page of a large resource</a>, but it can also be used in
+ other common situations. Linked Data clients could benefit by avoiding the latency
+ of additional requests when the target resource is a concept resource (one without any
+ representation capable of transmission over HTTP), and general HTTP clients would
+ benefit in many of the more general cases where <code>303 See Other</code> responses
+ are currently used.
+ </p>
+
+ <div id="status-code-related-content-1" class="rule">7.1.1 A <code>209</code> response to a
+ <code>GET</code> request MUST contain a <code>Location</code> header with the same
+ <code>Location</code> field value as a <code>303 See Other</code> response would use [[!HTTP11]].
+ </div>
+
+ <div id="status-code-related-content-2" class="rule">7.1.2 A <code>209</code> response to a
+ <code>GET</code> request MUST contain a representation of the resource identified
+ by the response's <code>Location</code> header.
+ </div>
+
+ <div id="status-code-related-content-iana" class="rule">7.1.3 IANA Considerations</div>
+ <div>
+ <blockquote>
+ <p>
+ The <code>209 Related Content</code> must be added to the permanent status code registry
+ maintained at <a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>
+ (see [[HTTPBIS-SEMANTICS]], [[!RFC2817]]).
+ </p>
+ <p>
+ Value: 209
+ </p>
+ <p>
+ Description: Related Content
+ </p>
+ <p>
+ Reference: this specification
+ </p>
+ </blockquote>
+ </div>
+
+</section>
+</section> <!-- status code defns -->
+
+
+<section class='informative' id='security'>
+<h1>Security Considerations</h1>
+As with any protocol that is implemented leveraging HTTP, implementations should take advantage of the many
+security-related facilities associated with it and are not required to carry out LDP operations
+that may be in contradistinction to a particular security policy in place. For example, when faced with an
+unauthenticated request to replace system critical RDF statements in a graph through the PUT method, applications may
+consider responding with the 401 status code (Unauthorized), indicating that the appropriate authorization
+is required. In cases where authentication is provided fails to meet the requirements of a particular access control
+policy, the 403 status code (Forbidden) can be sent back to the client to indicate this failure to meet the
+access control policy.
+</section>
+
+
+<section class='appendix informative'>
+<h2>Acknowledgements</h2>
+
+ <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;">
+ Alexandre Bertails, Andrei Sambra, Andy Seaborne, Antonis Loizou, Arnaud Le Hors, Ashok Malhota, Bart van Leeuwen, Cody Burleson, David Wood, Eric Prud'hommeaux, Erik Wilde, Henry Story, John Arwe, Kevin Page, Kingsley Idehen, Mark Baker, Martin P. Nally, Miel Vander Sande, Miguel Esteban Gutiérrez, Nandana Mihindukulasooriya, Olivier Berger, Pierre-Antoine Champin, Raúl García Castro, Reza B'Far, Richard Cyganiak, Roger Menday, Ruben Verborgh, Sandro Hawke, Serena Villata, Sergio Fernandez, Steve Battle, Steve Speicher, Ted Thibodeau, Tim Berners-Lee, Yves Lafon
+ </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-paging-20140930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
+<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-paging-20140730/">Last Call Draft</a></em></blockquote> -->
+<ul>
+ <li>2014-02-18 - Split off LDP-Paging from LDP (SS) </li>
+</ul>
+<blockquote><em><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/94420c5678ae/ldp.html">February 18, 2014 Editor's Draft</a></em></blockquote>
+</section>
+
+ </body>
+</html>
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp-paging.ttl Wed Mar 05 16:34:18 2014 +0000
@@ -0,0 +1,86 @@
+# See details within this document for linkage to specification and purpose.
+# This ontology file is a non-normative supporting document.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix owl: <http://www.w3.org/2002/07/owl#>.
+@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix vs: <http://www.w3.org/2003/06/sw-vocab-status/ns#> .
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix : <http://www.w3.org/ns/ldp-paging#>.
+
+:
+ a owl:Ontology;
+ dcterms:description "Vocabulary URIs defined in the Linked Data Platform Paging (LDP-Paging) namespace.";
+ dcterms:title "The W3C Linked Data Platform Paging (LDP-Paging) Vocabulary";
+ rdfs:label "W3C Linked Data Platform Paging (LDP-Paging)";
+ rdfs:comment "This ontology provides an informal representation of the concepts and terms
+ as defined in the LDP specification. Consult the LDP specification for normative reference.";
+ rdfs:seeAlso <http://www.w3.org/2012/ldp>,
+ <http://www.w3.org/TR/ldp-ucr/>,
+ <http://www.w3.org/TR/ldp/>,
+ <http://www.w3.org/TR/ldp-paging/>,
+ <http://www.w3.org/2011/09/LinkedData/>.
+
+:containerSortCriteria
+ a rdf:Property;
+ rdfs:comment "Link to the list of sorting criteria used by the server in a representation.";
+ vs:term_status "unstable";
+ rdfs:domain :Page;
+ rdfs:isDefinedBy :;
+ rdfs:label "containerSortCriteria";
+ rdfs:range rdf:List.
+
+:ContainerSortCriterion
+ a rdf:Class;
+ rdfs:comment "Element in the list of container sorting criteria used by the server in a representation.";
+ vs:term_status "unstable";
+ rdfs:label "ContainerSortCriterion";
+ rdfs:isDefinedBy :.
+
+:containerSortPredicate
+ a rdf:Property;
+ rdfs:comment "Predicate used to determine the order of the members in a page.";
+ vs:term_status "unstable";
+ rdfs:domain :ContainerSortCriterion;
+ rdfs:isDefinedBy :;
+ rdfs:label "containerSortPredicate";
+ rdfs:range rdf:Property.
+
+:containerSortOrder
+ a rdf:Property;
+ rdfs:comment "The ascending/descending/etc order used to order the members in a page.";
+ vs:term_status "unstable";
+ rdfs:domain :ContainerSortCriterion;
+ rdfs:isDefinedBy :;
+ rdfs:label "containerSortOrder";
+ rdfs:range rdf:Resource.
+
+:containerSortCollation
+ a rdf:Property;
+ rdfs:comment "The collation used to order the members in a page when comparing strings.";
+ vs:term_status "unstable";
+ rdfs:domain :ContainerSortCriterion;
+ rdfs:isDefinedBy :;
+ rdfs:label "containerSortCollation";
+ rdfs:range rdf:Property.
+
+:Ascending
+ a rdf:Description; # individual
+ rdfs:comment "Ascending order.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "Ascending".
+
+:Descending
+ a rdf:Description; # individual
+ rdfs:comment "Descending order.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "Descending".
+
+:Page
+ a rdfs:Class;
+ rdfs:comment "A resource that represents a limited set of members of a LDP Container.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "Page".
\ No newline at end of file
--- a/ldp-primer/ldp-primer.html Wed Mar 05 16:33:45 2014 +0000
+++ b/ldp-primer/ldp-primer.html Wed Mar 05 16:34:18 2014 +0000
@@ -1,1 +1,1 @@
-<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.1//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-2.dtd">
<html
xmlns="http://www.w3.org/1999/xhtml"
prefix="td: http://www.w3.org/2006/03/test-description# tn: http://ldp.example.org/NewTestDefinitions# ht: http://www.w3.org/2011/http#">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Linked Data Platform 1.0 Primer</title>
<style type="text/css">
div.syntaxmenu {
border: 1px dotted black;
padding:0 0 0 0.5em;
margin: 0em;
}
div.code {
font-family: monospace;
font-size: 110%;
}
th {
text-align: left;
}
td {
vertical-align: top;
padding-right: 2em;
}
td.col1 {
width: 300px;
}
</style>
<script type="text/javascript">
var displayed = [];
displayed["turtle"] = 1;
displayed["jsonld"] = 0;
function primerOnLoad() {
setTimeout(function(){
display('turtle', ''); set_display_by_id('hide-ts', ''); set_display_by_id('show-ts', 'none');
display('jsonld', 'none'); set_display_by_id('hide-js', 'none'); set_display_by_id('show-js', '');
},500)
}
function display(syntax,status) {
var howmany = 0;
if (status=='none') {
displayed[syntax] = 0;
} else {
displayed[syntax] = 1;
}
for ( i in displayed ) {
howmany = howmany + displayed[i];
}
set_display_by_class('div',syntax,status);
if ( howmany == 1 ) {
set_display_by_class('b','syntax-head','none');
} else {
set_display_by_class('b','syntax-head','');
}
}
function getElementsByClassName(oElm, strTagName, oClassNames){
var arrElements = (! (! (strTagName == "*") || ! (oElm.all)))? oElm.all : oElm.getElementsByTagName(strTagName);
var arrReturnElements = new Array();
var arrRegExpClassNames = new Array();
if(typeof oClassNames == "object"){
for(var i=0; !(i>=oClassNames.length); i++){ /*>*/
arrRegExpClassNames.push(new RegExp("(^|\\s)" + oClassNames[i].replace(/\-/g, "\\-") + "(\\s|$)"));
}
}
else{
arrRegExpClassNames.push(new RegExp("(^|\\s)" + oClassNames.replace(/\-/g, "\\-") + "(\\s|$)"));
}
var oElement;
var bMatchesAll;
for(var j=0; !(j>=arrElements.length); j++){ /*>*/
oElement = arrElements[j];
bMatchesAll = true;
for(var k=0; !(k>=arrRegExpClassNames.length); k++){ /*>*/
if(!arrRegExpClassNames[k].test(oElement.className)){
bMatchesAll = false;
break;
}
}
if(bMatchesAll){
arrReturnElements.push(oElement);
}
}
return (arrReturnElements)
}
function set_display_by_class(el, cls, newValue) {
var e = getElementsByClassName(document, el, cls);
if (e != null) {
for (var i=0; !(i>=e.length); i++) {
e[i].style.display = newValue;
}
}
}
function set_display_by_id(id, newValue) {
var e = document.getElementById(id);
if (e != null) {
e.style.display = newValue;
}
}
</script>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script>
<script class='remove'>
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "ED",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "ldp-primer",
// TODO: Confirm short name
// if your specification has a subtitle that goes below the main
// formal title, define it here
// subtitle : "an excellent document",
// if you wish the publication date to be other than today, set this
// publishDate: "2009-08-06",
// if the specification's copyright date is a range of years, specify
// the start date here:
// copyrightStart: "2005"
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
//previousPublishDate: "2013-03-07",
//previousMaturity: "FPWD",
//previousURI: "http://www.w3.org/TR/2013/WD-ldp-20130307/",
// if there a publicly available Editor's Draft, this is the link
//edDraftURI: "http://www.w3.org/2012/ldp/hg/ldp.html",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
// if you want to have extra CSS, append them to this list
// it is recommended that the respec.css stylesheet be kept
//extraCSS: ["https://dvcs.w3.org/hg/ldpwg/css/respec.css"],
// editors, add as many as you like
// only "name" is required
editors: [
{ name: "Nandana Mihindukulasooriya",
url: "http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/universitystaff/290-nandana",
company: "Ontology Engineering Group, Universidad Politécnica de Madrid",
companyURL: "http://www.oeg-upm.net/"},
{ name: "Roger Menday",
url: "#",
company: "Fujitsu Laboratories of Europe Limited, London",
companyURL: "#" },
],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
// only "name" is required. Same format as editors.
//authors: [
// { name: "Your Name", url: "http://example.org/",
// company: "Your Company", companyURL: "http://example.com/" },
//],
// name of the WG
wg: "Linked Data Platform Working Group",
// URI of the public WG page
wgURI: "http://www.w3.org/2012/ldp",
// name (without the @w3c.org) of the public mailing to which comments are due
wgPublicList: "public-ldp-wg",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI: "http://www.w3.org/2004/01/pp-impl/55082/status",
doRDFa: "1.1",
localBiblio: {
"LDP-BP": {
title: "LDP Best Practices and Guidelines",
href: "https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-bp/ldp-bp.html",
authors: [
"Cody Burleson",
"Nandana Mihindukulasooriya"
],
status: "WD",
deliveredBy: [
"http://www.w3.org/2012/ldp/"
],
publisher: "W3C"
},
"LDP-TESTS": {
title: "Linked Data Platform 1.0 Test Cases",
href: "https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html",
authors: [
"Raúl García-Castro"
],
status: "WD",
deliveredBy: [
"http://www.w3.org/2012/ldp/"
],
publisher: "W3C"
}
}
};
// Replaces HTML characters (brackets and quotes) with legal HTML representations
// The following example would include a code example from another file and then
// call this function to make the included code renderable in a browser.
//
// <pre class='example' data-include='include-rdf-type.ttl' data-oninclude='fixCode'></pre>
function fixCode(r, content) {
var result = content;
result = result.replace(/</g, "<").replace(/>/g, ">");
result = result.replace(/'/g, "'").replace(/"/g, """);
var ss = result.split('---')
var s1 = "<div class='turtle' style='font-family: sans-serif;'>Turtle:</div><div class='turtle'><pre>"+ss[0]+"</pre></div>";
var s2 = "<div class='jsonld' style='font-family: sans-serif;'>JSON-LD:</div><div class='jsonld'><pre>"+ss[1]+"</pre></div>";
return s1+s2;
}
function highlight(r, content) {
return '<span style="background-color:#ccffcc">' + content + '</span>';
}
</script>
</head>
<body onLoad="primerOnLoad()">
<section id='abstract'>
This primer provides an introduction to Linked Data Platform (LDP), including the basic concepts
of LDP including Linked Data Platform Resource (LDPR) and Linked Data Platform Container (LDPC)
and their affordances, and a running example showing how an LDP client can interact with a LDP server
in the context of read-write Linked Data application i.e. how to HTTP for accessing, updating,
creating and deleting resources from servers that expose their resources as Linked Data.
</section>
<section id="intro-section">
<h1 id="intro">Introduction</h1>
<p>Linked Data is a universal approach for handling data which fundamentally includes the notion linking between data items.
Much like the Web is giant network of interlinked documents for a human reader, the graph of Linked Data in the Web is a
data layer on top of which applications are delivered, information is modified, processed, visualized and shared.
</p>
<p> Linked Data Platform specification discusses standard HTTP and RDF 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>The Primer aims to provide introductory examples and guidance in the use of the LDP protocol. For a systematic account the reader should consult the normative LDP reference [[LDP]]. For an overview of the use cases for LDP and the elicited requirements that guided its design, the reader should consult the LDP Use Cases and Requirements [[LDP-UCR]].</p>
<b id="conventions">Conventions Used in This Document</b>
<p>The examples in this guide are given as a serialization of RDF graphs using the Turtle [[TURTLE]] and JSON-LD [[JSON-LD]] syntaxes of RDF</p>
<div class="syntaxmenu">
<p>The buttons below can be used to show or hide the available syntaxes.</p>
<form><p>
<input id="hide-ts" onclick="display('turtle', 'none'); set_display_by_id('hide-ts', 'none'); set_display_by_id('show-ts', ''); return false;" type="button" value="Hide Turtle Syntax" />
<input id="show-ts" onclick="display('turtle', ''); set_display_by_id('hide-ts', ''); set_display_by_id('show-ts', 'none'); return false;" style="display:none" type="button" value="Show Turtle Syntax" />
<input id="hide-js" onclick="display('jsonld','none'); set_display_by_id('hide-js', 'none'); set_display_by_id('show-js', ''); return false;" type="button" value="Hide JSON-LD Syntax" />
<input id="show-js" onclick="display('jsonld',''); set_display_by_id('hide-js', ''); set_display_by_id('show-js', 'none'); return false;" style="display:none" type="button" value="Show JSON-lD Syntax" />
</p>
</form>
</div>
<p>Commonly used namespace prefixes omitted from the Turtle serialisations:</p>
<pre style="word-wrap: break-word; white-space: pre-wrap;">
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix wdrs: <http://www.w3.org/2007/05/powder-s#> .
@prefix bt: <http://example.org/vocab/bugtracker#> . </pre>
<p>The JSON-LD examples refer to the following (external) context document:</p>
<pre style="word-wrap: break-word; white-space: pre-wrap;">
{
"@context":
{
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"owl": "http://www.w3.org/2002/07/owl#",
"ldp": "http://www.w3.org/ns/ldp#",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"dcterms": "http://purl.org/dc/terms/",
"foaf": "http://xmlns.com/foaf/0.1/",
"wdrs": "http://www.w3.org/2007/05/powder-s#",
"bt": "http://example.org/vocab/bugtracker#"
}
}
</pre>
<p> The LDP consists of two main building blocks: Linked Data Platform Resource (LDPR) and
Linked Data Platform Container (LDPC).Any HTTP resource whose state is represented in RDF that conforms to the simple lifecycle patterns and conventions in LDP
specification is an LDPR. It is recommended that LDPRs reuse existing vocabularies instead of creating their own duplicate
vocabulary terms. It is also recommended that LDPRs have at least one rdf:type set explicitly to make the representations
more useful to client applications that don’t support inferencing. For example, a FOAF file of a person as shown in Example 1
can be an example of an LDPR . It uses terms from Dublin Core [[DC-TERMS]], Friend of a Friend [[FOAF]] vocabularies.
</p>
<table>
<tr>
<td class="col1"><img src="nandana_foaf.png" /></td>
<td>
<pre title="An example LDPR" class='example' data-include='ldpr_ex.txt' data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
<p> Linked Data Platform Container (LDPC) is a specialization of an LDPR. An LDPC is 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.
For example, a set of friends of a person can be a represented as an LDPC as shown in Example 2 that contains a collection of triples
with the pattern <code><#friends, foaf:member, ?friend> </code>.
</p>
<table>
<tr>
<td class="col1"><img src="nandana_friends.png" /></td>
<td>
<pre title="An example LDPC" class='example' data-include='ldpc_ex.txt' data-oninclude='fixCode'></pre>
</td>
</tr>
<tr>
<td class="col1"><img src="roger.png" /></td>
<td>
<pre title="A member resource of LDPC in Example 2" class='example' data-include='ldpc_ex_m.txt' data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
<p>
Elements of the collection of same-subject, same-predicate triples are called Membership triples or simply members of the LDPC. Several predicates
of the LDPC ldp:membershipSubject, ldp:membershipPredicate, ldp:membershipObject defines the different aspects of the membership relation.
</p>
<p> Members of an LDPC does not have to be LDPRs. Any HTTP resource can be a member for an LDPC. For example,
</p>
<table>
<tr>
<td class="col1"><img src="photos.png" /></td>
<td>
<pre title="An example LDPC with non-LDPRs" class='example' data-include='ldpc_ex_non_ldpr.txt' data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
<p>
Use cases that motivated LDP specification varies from just publishing a dataset as Linked Data with advanced features as pagination,
providing read/write access to using Linked Data for application integration. The Linked Data Platform Use Cases and Requirements document provides
a more detailed information on the use cases that motivated the LDP specification.
</p>
<p>There will be several categories of systems implementing the LDP specification. Two main categories of the LDP servers include:</p>
<dl class="glossary">
<dt>Generic / vanilla LDP servers</dt>
<dd>RDF storage systems that allow interacting with their resources by means of the LDP specification. These servers do not impose any restriction on LDPRs.</dd>
<dt>Application specific LDP severs </dt>
<dd>Systems exposing their data using the LDP specification. These systems impose restrictions on LDPRs since they have an underlying business logic and data model.</dd>
</dl>
</section>
<section id="bugtracker">
<h1><a id="bugtracker">Bug Tracker Example</a></h1>
<p>
This section provides a set of examples to show the Linked Data Platform interactions. Note, this is a primer and should
not be considered as a canonical example of ideal LDP modeling.
The examples in this section will revolve around a very simple Bug Tracker application. Bug Tracker application records
the bugs of several products allowing reporting, updating and deleting bugs and products. We can re-use simple domain vocabulary,
e.g. has_bug or related, to express our data. LDP provides the additional interaction capability in the protocol to perform dynamic
evolution of knowledge representation.
</p>
<p>RESTful APIs are often documented by through listing valid operations operating on URLs described as templates. A RESTful API for a simple Bug Tracker system might be described as follows:</p>
<table class="simple">
<thead>
<th>Path</th>
<th>Method</th>
<th>Description</th>
</thead>
<tbody>
<!--tr>
<td rowspan="5">/app/</td>
<td>GET</td>
<td>Lists all the product descriptions.</td>
</tr>
<tr>
<td>POST</td>
<td>Create a new product description.</td>
</tr>
<tr>
<td>PUT</td>
<td>Update the app description and/or list of product descriptions</td>
</tr>
<tr>
<td>PATCH</td>
<td>Update the app description and/or list of product descriptions</td>
</tr>
<tr>
<td>DELETE</td>
<td>Not allowed.</td>
</tr-->
<tr>
<td class="col1" rowspan="5"><div class='code'>/app/{product-id}/</div></td>
<td>GET</td>
<td>Lists the bug reports associated with a product.</td>
</tr>
<tr>
<td>POST</td>
<td>Create a new bug report associated with a product.</td>
</tr>
<tr>
<td>PUT</td>
<td>Update the project description.</td>
</tr>
<tr>
<td>PATCH</td>
<td>Not supported.</td>
</tr>
<tr>
<td>DELETE</td>
<td>Delete the project description and associated bug reports.</td>
</tr>
<tr>
<td rowspan="5"><div class='code'>/app/{product-id}/{bug-id}</div></td>
<td>GET</td>
<td>Gets the bug report.</td>
</tr>
<tr>
<td>POST</td>
<td>Not supported.</td>
</tr>
<tr>
<td>PUT</td>
<td>Update the bug report.</td>
</tr>
<tr>
<td>PATCH</td>
<td>Not supported.</td>
</tr>
<tr>
<td>DELETE</td>
<td>Delete the bug report.</td>
</tr>
<tr>
<td rowspan="2"><div class='code'>/*/*</div></td>
<td>OPTIONS</td>
<td>Discover the allowed operations over a resource</td>
</tr>
<tr>
<td>HEAD</td>
<td>Only retrieve metainformation about a resource</td>
</tr>
</tbody>
</table>
<p class="note">Do we want to say something about suggested, user-friendly URIs ? </p>
<section id="navandret">
<h2>Navigation and Retreival</h2>
<b>Lookup a Product (LDPC?)</b>
<p> One of the main use cases of the example bug tracker is to list of the bugs of a given product. Assuming
that a user got a URL of a product by out of band means, one can look it up to get more information including
the bugs associated with it.</p>
<table>
<tr>
<td class="col1"><img src="product_lookup.png" /></td>
<td>
<p>To get the description of the product, a client can do a GET request on the URI of the known product resource. LDPR
servers should provide text/turtle representations of the requested LDPRs and may provide RDF format representations
using standard HTTP content negotiation. </p>
<pre class="example" title="Product lookup request"
data-include='product_lookup_req.txt' data-oninclude='fixCode'></pre>
<p>If the product resource is available, the server responds with the representation of the resource using the requested media type,
<code>text/turtle</code> in this case.</p>
<pre title="HTTP response for product lookup" class='example' data-include='product_lookup_resp.txt' data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
<p>
The project description resource contains both information about the project such as the title and the information about members of the product LDPC
i.e. the bugs associated with the product.
</p>
<p>Looking up a bug is similar to looking up a product. </p>
<table>
<tr>
<td class="col1"><img src="bug_lookup.png" /></td>
<td>
<p>Based on links in the representation of the Product, the client uses GET to navigate to a known Bug resource.</p>
<pre class="example" title="Bug lookup request"
data-include='bug_look_up_req.txt' data-oninclude='fixCode'></pre>
<p>The server responds with the representation of the bug.</p>
<pre title="Bug lookup response"
class='example' data-include='bug_look_up_resp.txt'
data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
</section>
<section>
<h3 id="BugCreate">Creation</h3>
<p>Continuing from the previous example, we can report a Bug against 'product1' by creating a Bug LDPR under the 'Product' LDPC.
The client POSTs a representation of a Bug to the Bug Tracker LDPC. </p>
<table>
<tr>
<td class="col1"><img src="bug_create.png" /></td>
<td>
<p>The client POSTs a representation of a Bug to the Bug Tracker LDPC.</p>
<pre title="A request for creating a bug"
class='example' data-include='bug_create_req.txt'
data-oninclude='fixCode'></pre>
<p>If the create is successful, the server responds with location of the newly created resource.</p>
<pre title="A response of creating new a bug"
class='example' data-oninclude='fixCode'>
HTTP/1.1 201 Created
Location: /app/product1/67
Content-Length: 0
</pre>
</td>
</tr>
<tr>
<td class="col1"><img src="product_postcreate.png" /></td>
<td>
<p>If the creation fails, the server will respond with an appropriate status code depending on the error.
After the resource is creation, the Product A LDPC will have the following representation.</p>
<pre title="The state of the product LDPC after the bug creation"
class='example' data-include='bug_create_s1.txt'
data-oninclude='fixCode'></pre>
</td>
</tr>
<tr>
<td class="col1"><img src="bug67.png" /></td>
<td>
<p>And the created Bug resource will have the following representation. Note that server has added a
server managed property, creation date (dcterms:created), and a default value for the state (bt:isInState)
to the Bug in addition to what was being POSTed.</p>
<pre title="The state of the bug LDPR"
class='example' data-include='bug_create_s2.txt'
data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
</section>
<section>
<h3 id="BugUpdate">Update</h3>
<p> TODO - Description </p>
<table>
<tr>
<td class="col1"><img src="bug_update.png" /></td>
<td>
<p>TODO - Description</p>
<pre title="A request for updating a bug"
class='example' data-include='bug_update_req.txt'
data-oninclude='fixCode'></pre>
<p>If the update is successful, the server will respond with a success status and a new etag.</p>
<pre class="example">
HTTP/1.1 204 No Content
ETag: W/"123456790"
</pre>
</td>
</tr>
</table>
</section>
<section>
<h3 id="BugDelete">Deletion</h3>
<p> TODO - Description </p>
<table>
<tr>
<td class="col1"><img src="bug_delete.png" /></td>
<td>
<p>TODO - Description</p>
<pre class="example">
DELETE /app/product1/bug3 HTTP/1.1
Host: example.org
</pre>
<p>If the update is successful, the server will respond with a success status and a new etag.</p>
<pre class="example">
HTTP/1.1 204 No Content
ETag: W/"123456790"
</pre>
</td>
</tr>
</table>
</section>
<section>
<h3 id="meta-structure">Structural Manipulation</h3>
<p>If the bug tracker allows creating new Products in the tracker, that can done by posting a representation of a new Product to the Bug Tracker container. In this example the client includes the necessary ldp membership properties making the new Product a container for Bug resources.</p>
<table>
<tr>
<td class='col1'><img src="app.png" /></td>
<td>
<p>The status of the bug tracker before creating the new product.</p>
<pre title="The state of the Bug Tracker LDPC"
class='example' data-include='product_create_s1.txt'
data-oninclude='fixCode'></pre>
</td>
</tr>
<tr>
<td class="col1"><img src="app_post.png" /></td>
<td>
<p>The client POSTs a representation of a Product to the Bug Tracker LDPC.</p>
<pre title="A request for creating a product"
class='example' data-include='product_create_req.txt'
data-oninclude='fixCode'></pre>
<p>If the create is successful, the server responds with location of the newly created resource.</p>
<pre title="The response after creating new product" class="example">
HTTP/1.1 201 Created
Location: /app/product2
Content-Length: 0
</pre>
</td>
</tr>
<tr>
<td></td><td>
<p>After creation of this new container, 'product2', the representation of the 'Tracker' container will be</p>
<pre title="The state of the Bug Tracker after the product creation"
class='example' data-include='product_create_s2.txt'
data-oninclude='fixCode'></pre>
<p>and the 'product2' will have the following representation.</p>
<pre title="The state of the new Product"
class='example' data-include='product_create_s3.txt'
data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
</section>
<section>
<h3 id="ProductLookup">Operation Discovery</h3>
<p>
Assuming that a user got the URL of the product by out of band means, a starting point would be to discover
which operations can be performed on the product resource.
</p>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>The client does an OPTIONS with the URI of a known product description resource.</p>
<pre class="example">OPTIONS /app/product1/ HTTP/1.1
Host: example.org
</pre>
<p>If the product description resource is available, the server responds with the allowed HTTP operations on the product
resource along with some other metadata.</p>
<div class="turtle">
<pre title="HTTP response for OPTIONS on a product" class='example'>
HTTP/1.1 200 OK
Allow: OPTIONS,HEAD,GET,POST,PUT,PATCH
Accept-Post: text/turtle, application/ld+json
Accept-Patch: example/patch
Link: <http://www.w3.org/ns/ldp/Resource>; rel="type"
Link: <?nonMemberProperties>;rel="http://www.w3.org/ns/ldp#nonMemberResource"
Content-Length: 0
</pre>
</div>
</td>
</tr>
</table>
<p> According to the response, HTTP operations {OPTIONS,GET,POST,PUT,PATCH} are allowed on the product description resource.
In addition to the allowed operations, Accept-Post and Accept-Patch provides which media types are supported by respective operations.
The rel="type" Link header advertises that this is resource supports LDP protocol and the the rel="ldp:nonMemberResource" provides a link
to the non-member resource of this product description.
</p>
</section>
<section id="paging">
<h3>Pagination</h3>
<p>It sometimes happens that a resource is too large to reasonably transmit its representation in a single HTTP response. For example, if the
bug resource in our example includes comments, It might happen that it may be become too large. To address this problem, LDPRs should support
a technique called Paging.</p>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>If a client does a get on an LDPR that supports paging, it will be redirected to the first page of the resource.</p>
<pre class="example">
GET /app/product1/bug3 HTTP/1.1
Host: example.org
</pre>
<pre class="example">
HTTP/1.1 303 See Other
Location: /app/product1/bug3?firstpage
</pre>
</td>
</tr>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>Alternatively if the client wants to know in advance whether the resource is paged or not, it can do an OPTIONS request on the LDPR URI</p>
<pre class="example">
OPTIONS /app/product1/bug3 HTTP/1.1
Host: example.org
</pre>
<p>If the resource is paged, the response contains a HTTP Link header with rel="first"; and the target URI of that header would be the URL of
the first page resource. </p>
<pre class="example">
HTTP/1.1 200 OK
Allow: OPTIONS,HEAD,GET,PUT,PATCH
Accept-Patch: example/patch
Link: <http://www.w3.org/ns/ldp/Resource>; rel="type"
Link: </app/product1/bug3?firstpage>; rel="first"
Content-Length: 0
</pre>
</td>
</tr>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>After knowing the URL of the first page resource, the client can retrieve it using a HTTP GET</p>
<pre class="example">
GET /app/product1/bug3?firstpage HTTP/1.1
Host: example.org
Accept: text/turtle; charset=UTF-8
</pre>
<pre title="HTTP response for getting the first page resource"
class='example' data-include='paging_page1_res.txt'
data-oninclude='fixCode'></pre>
<p>The first page contains a link to the second page with LDPR as the subject,
ldp:nextPage as the predicate and the subsequent page as the object.</p>
</td>
</tr>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>The second page can be retrieved the same way as the first page was retrieved.</p>
<pre class="example">
GET /app/product1/bug3?secondPage HTTP/1.1
Host: example.org
Accept: text/turtle; charset=UTF-8
</pre>
<pre title="HTTP response for getting the second page resource"
class='example' data-include='paging_page2_res.txt'
data-oninclude='fixCode'></pre>
<p>The last page of resource contains with LDPR as the subject,
ldp:nextPage as the predicate and the rdf:nil as the object.</p>
</td>
</tr>
</table>
</section>
<section id="odering">
<h3>Ordering</h3>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>There are many cases where an ordering of the members of the container is important. </p>
<pre class="example">
GET /app/product1?firstPage HTTP/1.1
Host: example.org
Accept: text/turtle; charset=UTF-8
</pre>
<pre title="The representation of an ordered LDPC"
class='example' data-include='ordered_ldpc_resp.txt'
data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
</section>
<section id="binary-res">
<h3>Binary resources</h3>
<b>Creating a binary resource</b>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>We have an LDPC which we can use to create binary resources</p>
<pre title="The state of the attachments LDPC"
class='example' data-include='attachments_s1.txt'
data-oninclude='fixCode'></pre>
</td>
</tr>
<tr>
<td><img src="replace.png" /></td>
<td>
<p>The client POSTs a binary resource to the LDPC</p>
<pre title="A request for creating a product"
class='example'>POST /app/product1/bug3/attachments/ HTTP/1.1
Host: example.org
Content-Type: image/png
Slug: login-page.png
Content-Length: 1254
#### binary data #####
</pre>
<p>If the create is successful, the server it responds with a Location header and a Link header to
the automatically created metadata LDPR.</p>
<pre title="A response after creating new a binary resource" class='example'>HTTP/1.1 201 Created
Location: /app/product1/bug3/attachments/login-page.png
Link: </app/product1/bug3/attachments/1>; rel="meta"
Content-Length: 0
</pre>
</td>
</tr>
<tr>
<td></td>
<td>
<p>After the creation, LDPC representation looks like</p>
<pre title="The state of the attachments LDPC after creation"
class='example' data-include='attachments_s2.txt'
data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
</section>
<b>Accessing the binary resource</b>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>The client can retrieve the binary resource by doing a GET on the binary resource URI.</p>
<pre class="example">GET /app/product1/bug3/attachments/login-page.png HTTP/1.1
Host: example.org
Accept: image/png
</pre>
<p>LDPR server responds with</p>
<pre title="HTTP response for getting the binary resource"
class='example'>HTTP/1.1 200 OK
Content-Type: image/png
Link: </app/product1/bug3/attachments/1>; rel="meta"
ETag: W/"123456789"
#### binary data #####
</pre>
</td>
</tr>
</table>
</section>
<b>Accessing the metadata about the binary resource</b>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>The client can retrieve the metadata of the binary resource by doing a GET on the metadata-LDPR URI.</p>
<pre class="example">GET /app/product1/bug3/attachments/1
Host: example.org
Accept: text/turtle
</pre>
<p>LDPR server responds with</p>
<pre title="HTTP response for getting the binary resource"
class='example' data-include='attachments_m_get_res.txt'
data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
</section>
<b>Updating the metadata about the binary resource</b>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>TODO</p>
<pre title="Updating the metadata of the binary resource"
class='example' data-include='attachments_m_update_req.txt'
data-oninclude='fixCode'></pre>
<p>LDPR server responds with</p>
<pre class="example">HTTP/1.1 204 No Content
ETag: W/"123456790"
</pre>
</td>
</tr>
</table>
</section>
<b>Deleting the binary resource</b>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>TODO</p>
<pre class="example"> DELETE /app/product1/bug3/attachments/login-page.png HTTP/1.1
Host: example.org
</pre>
<pre class="example">HTTP/1.1 204 No Content
ETag: W/"123456790"
</pre>
<pre class="example">GET /app/product1/bug3/attachments/login-page.png HTTP/1.1
Host: example.org
</pre>
<pre class="example">HTTP/1.1 410 Gone
</pre>
<pre class="example"> GET /app/product1/bug3/attachments/1
Host: example.org
</pre>
<pre class="example">HTTP/1.1 410 Gone
</pre>
</td>
</tr>
</table>
</section>
</section>
</section>
<section>
<h1 id="advexamples">Advanced Examples</h1>
<section>
<h3 id="ldpmemx">Uses of membership{Subject,Predicate,Object} predicates </h3>
<p>In most of the previous examples we kept the ldp:membershipSubject as the LDPC itself and ldp:membershipObject as the ldp:MemberSubject. However, these
predicates can be used to change the semantics of the membership relationship in LDPCs. </p>
<p class="note">TO DO: A small note on document vs Thing separation linking to <a href="http://www.w3.org/TR/webarch/#id-resources">Web Arch</a>,
, <a href="http://www.w3.org/TR/cooluris/#semweb">Cool URIs</a>, <a href="http://www.w3.org/TR/urls-in-data/#landing-pages">URLs in Data</a>.</p>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>If the separation between real world resource and information is important, the product description of the previous Bug Tracker example can
be alternatively designed as following.</p>
<pre title="Representation of the product description"
class='example' data-include='product_alt_s1.txt'
data-oninclude='fixCode'></pre>
<p>In the above example, the product description information resource is explicitly seperated from the real world product resource. Now the RDF representation
contains information about both the information resource that is identified by the URI </app/product1/> and the real world resource identified by the
URI </app/product1/#it>. </p>
<p>With this seperation, now the ldp:membershipSubject of the container is not the container URI itself but </app/product1/#it>. The effect of these is that
membership relation triples added when new resources are POSTed to this container will now have the subject </app/product1/#it> not the container URI. Further,
ldp:membershipObject of this container is foaf:primaryTopic. Thus, the object of the membership triple will not be the newly created resource but the foaf:primaryTopic
defined inside that newly created resource as shown in the following example. </p>
<pre title="HTTP request for creating a new bug report"
class='example' data-include='bug_alt_create_req.txt'
data-oninclude='fixCode'></pre>
<p>And the server will respond with the URI of the newly created information resource in the Location header.</p>
<pre title="Representation of the newly created bug"
class='example' data-oninclude='fixCode'>
HTTP/1.1 201 Created
Location: /app/product1/67
Content-Length: 0
</pre>
<p>After the resource creation, the representations of the LDPC and newly created LDPR would be </p>
<pre title="Representation of the LDPC"
class='example' data-oninclude='fixCode' data-include='product_alt_s2.txt'></pre>
<pre title="Representation of the newly created bug"
class='example' data-oninclude='fixCode' data-include='bug_alt_s1.txt'></pre>
</td>
</tr>
</table>
</section>
<section>
<h3 id="mempredinv">ldp:membershipPredicateInverse predicate</h3>
<p>In sometimes the membership relationship can defined in a way such that the container is becomes the object of the membership triple. For example,
in our example, if the membership triple was like < bug, bt:relatedProduct, product > the product container would look like</p>
<pre title="Representation of an LDPC with ldp:membershipPredicateInverse predicate"
class='example' data-oninclude='fixCode' data-include='product_inv_s1.txt'></pre>
<p>TODO - Find a better example</p>
</section>
<section id="res-inlining">
<h3>Resource Inlining</h3>
<p> TODO - Description </p>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>TODO - Description</p>
<pre title="A HTTP request to a LDPR with inlined resources"
class='example' data-oninclude='fixCode' data-include='res_inline_req.txt'></pre>
<p> </p>
<pre title="A HTTP response from a LDPR with inlined resources"
class='example' data-oninclude='fixCode' data-include='res_inline_res.txt'></pre>
</td>
</tr>
</table>
</section>
<section id="mem-inlining">
<h3>Member Inlining</h3>
</section>
</section>
<section>
<h1 id="ldpc">LDP Implementations</h1>
A list of implementations that plan to be LDP compliant is available in the LDP Implementations wiki page.
LDP Implementation report provides the coverage of the specification by each LDP implementation.
</section>
<section>
<h1 id="next">What To Read Next</h1>
The primer only provide an overview of the Linked Data Platform specifications. LDP WG has produced following documents that contribute to the Linked Data Platform specification.
<ul>
<li><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/TR/ldp-ucr.html">Linked Data Platform Use Cases and Requirements</a> [[LDP-UCR]]</li>
<li><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html">Linked Data Platform 1.0 specifcation</a> [[LDP]]</li>
<li>Linked Data Platform 1.0 Primer (This document)</li>
<li><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html">LDP Best Practices and Guidelines</a> [[LDP-BP]]</li>
<li><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/Test%20Cases/LDP%20Test%20Cases.html">Linked Data Platform 1.0 Test Cases</a>[[LDP-TESTS]]</li>
</ul>
</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>
<ul>
<li>2013-08-05 - Providing JSON-LD representations of the examples.</li>
<li>2013-07-03 - Moving the content from the wiki to the note.</li>
</ul>
</section>
</body>
</html>
\ No newline at end of file
+<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.1//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-2.dtd">
<html
xmlns="http://www.w3.org/1999/xhtml"
prefix="td: http://www.w3.org/2006/03/test-description# tn: http://ldp.example.org/NewTestDefinitions# ht: http://www.w3.org/2011/http#">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Linked Data Platform 1.0 Primer</title>
<style type="text/css">
div.syntaxmenu {
border: 1px dotted black;
padding:0 0 0 0.5em;
margin: 0em;
}
div.code {
font-family: monospace;
font-size: 110%;
}
th {
text-align: left;
}
td {
vertical-align: top;
padding-right: 2em;
}
td.col1 {
width: 300px;
}
</style>
<script type="text/javascript">
var displayed = [];
displayed["turtle"] = 1;
displayed["jsonld"] = 0;
function primerOnLoad() {
setTimeout(function(){
display('turtle', ''); set_display_by_id('hide-ts', ''); set_display_by_id('show-ts', 'none');
display('jsonld', 'none'); set_display_by_id('hide-js', 'none'); set_display_by_id('show-js', '');
},500)
}
function display(syntax,status) {
var howmany = 0;
if (status=='none') {
displayed[syntax] = 0;
} else {
displayed[syntax] = 1;
}
for ( i in displayed ) {
howmany = howmany + displayed[i];
}
set_display_by_class('div',syntax,status);
if ( howmany == 1 ) {
set_display_by_class('b','syntax-head','none');
} else {
set_display_by_class('b','syntax-head','');
}
}
function getElementsByClassName(oElm, strTagName, oClassNames){
var arrElements = (! (! (strTagName == "*") || ! (oElm.all)))? oElm.all : oElm.getElementsByTagName(strTagName);
var arrReturnElements = new Array();
var arrRegExpClassNames = new Array();
if(typeof oClassNames == "object"){
for(var i=0; !(i>=oClassNames.length); i++){ /*>*/
arrRegExpClassNames.push(new RegExp("(^|\\s)" + oClassNames[i].replace(/\-/g, "\\-") + "(\\s|$)"));
}
}
else{
arrRegExpClassNames.push(new RegExp("(^|\\s)" + oClassNames.replace(/\-/g, "\\-") + "(\\s|$)"));
}
var oElement;
var bMatchesAll;
for(var j=0; !(j>=arrElements.length); j++){ /*>*/
oElement = arrElements[j];
bMatchesAll = true;
for(var k=0; !(k>=arrRegExpClassNames.length); k++){ /*>*/
if(!arrRegExpClassNames[k].test(oElement.className)){
bMatchesAll = false;
break;
}
}
if(bMatchesAll){
arrReturnElements.push(oElement);
}
}
return (arrReturnElements)
}
function set_display_by_class(el, cls, newValue) {
var e = getElementsByClassName(document, el, cls);
if (e != null) {
for (var i=0; !(i>=e.length); i++) {
e[i].style.display = newValue;
}
}
}
function set_display_by_id(id, newValue) {
var e = document.getElementById(id);
if (e != null) {
e.style.display = newValue;
}
}
</script>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script>
<script class='remove'>
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "ED",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "ldp-primer",
// TODO: Confirm short name
// if your specification has a subtitle that goes below the main
// formal title, define it here
// subtitle : "an excellent document",
// if you wish the publication date to be other than today, set this
// publishDate: "2009-08-06",
// if the specification's copyright date is a range of years, specify
// the start date here:
// copyrightStart: "2005"
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
//previousPublishDate: "2013-03-07",
//previousMaturity: "FPWD",
//previousURI: "http://www.w3.org/TR/2013/WD-ldp-20130307/",
// if there a publicly available Editor's Draft, this is the link
//edDraftURI: "http://www.w3.org/2012/ldp/hg/ldp.html",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
// if you want to have extra CSS, append them to this list
// it is recommended that the respec.css stylesheet be kept
//extraCSS: ["https://dvcs.w3.org/hg/ldpwg/css/respec.css"],
// editors, add as many as you like
// only "name" is required
editors: [
{ name: "Nandana Mihindukulasooriya",
url: "http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/universitystaff/290-nandana",
company: "Ontology Engineering Group, Universidad Politécnica de Madrid",
companyURL: "http://www.oeg-upm.net/"},
{ name: "Roger Menday",
url: "#",
company: "Fujitsu Laboratories of Europe Limited, London",
companyURL: "#" },
],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
// only "name" is required. Same format as editors.
//authors: [
// { name: "Your Name", url: "http://example.org/",
// company: "Your Company", companyURL: "http://example.com/" },
//],
// name of the WG
wg: "Linked Data Platform Working Group",
// URI of the public WG page
wgURI: "http://www.w3.org/2012/ldp",
// name (without the @w3c.org) of the public mailing to which comments are due
wgPublicList: "public-ldp-wg",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI: "http://www.w3.org/2004/01/pp-impl/55082/status",
doRDFa: "1.1",
localBiblio: {
"LDP-BP": {
title: "LDP Best Practices and Guidelines",
href: "https://dvcs.w3.org/hg/ldpwg/raw-file/tip/ldp-bp/ldp-bp.html",
authors: [
"Cody Burleson",
"Nandana Mihindukulasooriya"
],
status: "WD",
deliveredBy: [
"http://www.w3.org/2012/ldp/"
],
publisher: "W3C"
},
"LDP-TESTS": {
title: "Linked Data Platform 1.0 Test Cases",
href: "https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html",
authors: [
"Raúl García-Castro"
],
status: "WD",
deliveredBy: [
"http://www.w3.org/2012/ldp/"
],
publisher: "W3C"
}
}
};
// Replaces HTML characters (brackets and quotes) with legal HTML representations
// The following example would include a code example from another file and then
// call this function to make the included code renderable in a browser.
//
// <pre class='example' data-include='include-rdf-type.ttl' data-oninclude='fixCode'></pre>
function fixCode(r, content) {
var result = content;
result = result.replace(/</g, "<").replace(/>/g, ">");
result = result.replace(/'/g, "'").replace(/"/g, """);
var ss = result.split('---')
var s1 = "<div class='turtle' style='font-family: sans-serif;'>Turtle:</div><div class='turtle'><pre>"+ss[0]+"</pre></div>";
var s2 = "<div class='jsonld' style='font-family: sans-serif;'>JSON-LD:</div><div class='jsonld'><pre>"+ss[1]+"</pre></div>";
return s1+s2;
}
function highlight(r, content) {
return '<span style="background-color:#ccffcc">' + content + '</span>';
}
</script>
</head>
<body onLoad="primerOnLoad()">
<section id='abstract'>
This primer provides an introduction to Linked Data Platform (LDP), including the basic concepts
of LDP including Linked Data Platform Resource (LDPR) and Linked Data Platform Container (LDPC)
and their affordances, and a running example showing how an LDP client can interact with a LDP server
in the context of read-write Linked Data application i.e. how to HTTP for accessing, updating,
creating and deleting resources from servers that expose their resources as Linked Data.
</section>
<section id="intro-section">
<h1 id="intro">Introduction</h1>
<p>Linked Data is a universal approach for handling data which fundamentally includes the notion linking between data items.
Much like the Web is giant network of interlinked documents for a human reader, the graph of Linked Data in the Web is a
data layer on top of which applications are delivered, information is modified, processed, visualized and shared.
</p>
<p> Linked Data Platform specification discusses standard HTTP and RDF 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>The Primer aims to provide introductory examples and guidance in the use of the LDP protocol. For a systematic account the reader should consult the normative LDP reference [[LDP]]. For an overview of the use cases for LDP and the elicited requirements that guided its design, the reader should consult the LDP Use Cases and Requirements [[LDP-UCR]].</p>
<b id="conventions">Conventions Used in This Document</b>
<p>The examples in this guide are given as a serialization of RDF graphs using the Turtle [[TURTLE]] and JSON-LD [[JSON-LD]] syntaxes of RDF</p>
<div class="syntaxmenu">
<p>The buttons below can be used to show or hide the available syntaxes.</p>
<form><p>
<input id="hide-ts" onclick="display('turtle', 'none'); set_display_by_id('hide-ts', 'none'); set_display_by_id('show-ts', ''); return false;" type="button" value="Hide Turtle Syntax" />
<input id="show-ts" onclick="display('turtle', ''); set_display_by_id('hide-ts', ''); set_display_by_id('show-ts', 'none'); return false;" style="display:none" type="button" value="Show Turtle Syntax" />
<input id="hide-js" onclick="display('jsonld','none'); set_display_by_id('hide-js', 'none'); set_display_by_id('show-js', ''); return false;" type="button" value="Hide JSON-LD Syntax" />
<input id="show-js" onclick="display('jsonld',''); set_display_by_id('hide-js', ''); set_display_by_id('show-js', 'none'); return false;" style="display:none" type="button" value="Show JSON-lD Syntax" />
</p>
</form>
</div>
<p>Commonly used namespace prefixes omitted from the Turtle serialisations:</p>
<pre style="word-wrap: break-word; white-space: pre-wrap;">
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix wdrs: <http://www.w3.org/2007/05/powder-s#> .
@prefix bt: <http://example.org/vocab/bugtracker#> . </pre>
<p>The JSON-LD examples refer to the following (external) context document:</p>
<pre style="word-wrap: break-word; white-space: pre-wrap;">
{
"@context":
{
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"owl": "http://www.w3.org/2002/07/owl#",
"ldp": "http://www.w3.org/ns/ldp#",
"xsd": "http://www.w3.org/2001/XMLSchema#",
"dcterms": "http://purl.org/dc/terms/",
"foaf": "http://xmlns.com/foaf/0.1/",
"wdrs": "http://www.w3.org/2007/05/powder-s#",
"bt": "http://example.org/vocab/bugtracker#"
}
}
</pre>
<p> The LDP consists of two main building blocks: Linked Data Platform Resource (LDPR) and
Linked Data Platform Container (LDPC).Any HTTP resource whose state is represented in RDF that conforms to the simple lifecycle patterns and conventions in LDP
specification is an LDPR. It is recommended that LDPRs reuse existing vocabularies instead of creating their own duplicate
vocabulary terms. It is also recommended that LDPRs have at least one rdf:type set explicitly to make the representations
more useful to client applications that don’t support inferencing. For example, a FOAF file of a person as shown in Example 1
can be an example of an LDPR . It uses terms from Dublin Core [[DC-TERMS]], Friend of a Friend [[FOAF]] vocabularies.
</p>
<table>
<tr>
<td class="col1"><img src="nandana_foaf.png" /></td>
<td>
<pre title="An example LDPR" class='example' data-include='ldpr_ex.txt' data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
<p> Linked Data Platform Container (LDPC) is a specialization of an LDPR. An LDPC is 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.
For example, a set of friends of a person can be a represented as an LDPC as shown in Example 2 that contains a collection of triples
with the pattern <code><#friends, foaf:member, ?friend> </code>.
</p>
<table>
<tr>
<td class="col1"><img src="nandana_friends.png" /></td>
<td>
<pre title="An example LDPC" class='example' data-include='ldpc_ex.txt' data-oninclude='fixCode'></pre>
</td>
</tr>
<tr>
<td class="col1"><img src="roger.png" /></td>
<td>
<pre title="A member resource of LDPC in Example 2" class='example' data-include='ldpc_ex_m.txt' data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
<p>
Elements of the collection of same-subject, same-predicate triples are called Membership triples or simply members of the LDPC. Several predicates
of the LDPC ldp:membershipSubject, ldp:membershipPredicate, ldp:membershipObject defines the different aspects of the membership relation.
</p>
<p> Members of an LDPC does not have to be LDPRs. Any HTTP resource can be a member for an LDPC. For example,
</p>
<table>
<tr>
<td class="col1"><img src="photos.png" /></td>
<td>
<pre title="An example LDPC with non-LDPRs" class='example' data-include='ldpc_ex_non_ldpr.txt' data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
<p>
Use cases that motivated LDP specification varies from just publishing a dataset as Linked Data with advanced features as pagination,
providing read/write access to using Linked Data for application integration. The Linked Data Platform Use Cases and Requirements document provides
a more detailed information on the use cases that motivated the LDP specification.
</p>
<p>There will be several categories of systems implementing the LDP specification. Two main categories of the LDP servers include:</p>
<dl class="glossary">
<dt>Generic / vanilla LDP servers</dt>
<dd>RDF storage systems that allow interacting with their resources by means of the LDP specification. These servers do not impose any restriction on LDPRs.</dd>
<dt>Application specific LDP severs </dt>
<dd>Systems exposing their data using the LDP specification. These systems impose restrictions on LDPRs since they have an underlying business logic and data model.</dd>
</dl>
</section>
<section id="bugtracker">
<h1><a id="bugtracker">Bug Tracker Example</a></h1>
<p>
This section provides a set of examples to show the Linked Data Platform interactions. Note, this is a primer and should
not be considered as a canonical example of ideal LDP modeling.
The examples in this section will revolve around a very simple Bug Tracker application. Bug Tracker application records
the bugs of several products allowing reporting, updating and deleting bugs and products. We can re-use simple domain vocabulary,
e.g. has_bug or related, to express our data. LDP provides the additional interaction capability in the protocol to perform dynamic
evolution of knowledge representation.
</p>
<p>RESTful APIs are often documented by through listing valid operations operating on URLs described as templates. A RESTful API for a simple Bug Tracker system might be described as follows:</p>
<table class="simple">
<thead>
<th>Path</th>
<th>Method</th>
<th>Description</th>
</thead>
<tbody>
<!--tr>
<td rowspan="5">/app/</td>
<td>GET</td>
<td>Lists all the product descriptions.</td>
</tr>
<tr>
<td>POST</td>
<td>Create a new product description.</td>
</tr>
<tr>
<td>PUT</td>
<td>Update the app description and/or list of product descriptions</td>
</tr>
<tr>
<td>PATCH</td>
<td>Update the app description and/or list of product descriptions</td>
</tr>
<tr>
<td>DELETE</td>
<td>Not allowed.</td>
</tr-->
<tr>
<td class="col1" rowspan="5"><div class='code'>/app/{product-id}/</div></td>
<td>GET</td>
<td>Lists the bug reports associated with a product.</td>
</tr>
<tr>
<td>POST</td>
<td>Create a new bug report associated with a product.</td>
</tr>
<tr>
<td>PUT</td>
<td>Update the project description.</td>
</tr>
<tr>
<td>PATCH</td>
<td>Not supported.</td>
</tr>
<tr>
<td>DELETE</td>
<td>Delete the project description and associated bug reports.</td>
</tr>
<tr>
<td rowspan="5"><div class='code'>/app/{product-id}/{bug-id}</div></td>
<td>GET</td>
<td>Gets the bug report.</td>
</tr>
<tr>
<td>POST</td>
<td>Not supported.</td>
</tr>
<tr>
<td>PUT</td>
<td>Update the bug report.</td>
</tr>
<tr>
<td>PATCH</td>
<td>Not supported.</td>
</tr>
<tr>
<td>DELETE</td>
<td>Delete the bug report.</td>
</tr>
<tr>
<td rowspan="2"><div class='code'>/*/*</div></td>
<td>OPTIONS</td>
<td>Discover the allowed operations over a resource</td>
</tr>
<tr>
<td>HEAD</td>
<td>Only retrieve metainformation about a resource</td>
</tr>
</tbody>
</table>
<p class="note">Do we want to say something about suggested, user-friendly URIs ? </p>
<section id="navandret">
<h2>Navigation and Retreival</h2>
<b>Lookup a Product (LDPC?)</b>
<p> One of the main use cases of the example bug tracker is to list of the bugs of a given product. Assuming
that a user got a URL of a product by out of band means, one can look it up to get more information including
the bugs associated with it.</p>
<table>
<tr>
<td class="col1"><img src="product_lookup.png" /></td>
<td>
<p>To get the description of the product, a client can do a GET request on the URI of the known product resource. LDPR
servers should provide text/turtle representations of the requested LDPRs and may provide RDF format representations
using standard HTTP content negotiation. </p>
<pre class="example" title="Product lookup request"
data-include='product_lookup_req.txt' data-oninclude='fixCode'></pre>
<p>If the product resource is available, the server responds with the representation of the resource using the requested media type,
<code>text/turtle</code> in this case.</p>
<pre title="HTTP response for product lookup" class='example' data-include='product_lookup_resp.txt' data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
<p>
The project description resource contains both information about the project such as the title and the information about members of the product LDPC
i.e. the bugs associated with the product.
</p>
<p>Looking up a bug is similar to looking up a product. </p>
<table>
<tr>
<td class="col1"><img src="bug_lookup.png" /></td>
<td>
<p>Based on links in the representation of the Product, the client uses GET to navigate to a known Bug resource.</p>
<pre class="example" title="Bug lookup request"
data-include='bug_look_up_req.txt' data-oninclude='fixCode'></pre>
<p>The server responds with the representation of the bug.</p>
<pre title="Bug lookup response"
class='example' data-include='bug_look_up_resp.txt'
data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
</section>
<section>
<h3 id="BugCreate">Creation</h3>
<p>Continuing from the previous example, we can report a Bug against 'product1' by creating a Bug LDPR under the 'Product' LDPC.
The client POSTs a representation of a Bug to the Bug Tracker LDPC. </p>
<table>
<tr>
<td class="col1"><img src="bug_create.png" /></td>
<td>
<p>The client POSTs a representation of a Bug to the Bug Tracker LDPC.</p>
<pre title="A request for creating a bug"
class='example' data-include='bug_create_req.txt'
data-oninclude='fixCode'></pre>
<p>If the create is successful, the server responds with location of the newly created resource.</p>
<pre title="A response of creating new a bug"
class='example' data-oninclude='fixCode'>
HTTP/1.1 201 Created
Location: /app/product1/67
Content-Length: 0
</pre>
</td>
</tr>
<tr>
<td class="col1"><img src="product_postcreate.png" /></td>
<td>
<p>If the creation fails, the server will respond with an appropriate status code depending on the error.
After the resource is creation, the Product A LDPC will have the following representation.</p>
<pre title="The state of the product LDPC after the bug creation"
class='example' data-include='bug_create_s1.txt'
data-oninclude='fixCode'></pre>
</td>
</tr>
<tr>
<td class="col1"><img src="bug67.png" /></td>
<td>
<p>And the created Bug resource will have the following representation. Note that server has added a
server managed property, creation date (dcterms:created), and a default value for the state (bt:isInState)
to the Bug in addition to what was being POSTed.</p>
<pre title="The state of the bug LDPR"
class='example' data-include='bug_create_s2.txt'
data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
</section>
<section>
<h3 id="BugUpdate">Update</h3>
<p> TODO - Description </p>
<table>
<tr>
<td class="col1"><img src="bug_update.png" /></td>
<td>
<p>TODO - Description</p>
<pre title="A request for updating a bug"
class='example' data-include='bug_update_req.txt'
data-oninclude='fixCode'></pre>
<p>If the update is successful, the server will respond with a success status and a new etag.</p>
<pre class="example">
HTTP/1.1 204 No Content
ETag: W/"123456790"
</pre>
</td>
</tr>
</table>
</section>
<section>
<h3 id="BugDelete">Deletion</h3>
<p> TODO - Description </p>
<table>
<tr>
<td class="col1"><img src="bug_delete.png" /></td>
<td>
<p>TODO - Description</p>
<pre class="example">
DELETE /app/product1/bug3 HTTP/1.1
Host: example.org
</pre>
<p>If the update is successful, the server will respond with a success status and a new etag.</p>
<pre class="example">
HTTP/1.1 204 No Content
ETag: W/"123456790"
</pre>
</td>
</tr>
</table>
</section>
<section>
<h3 id="meta-structure">Structural Manipulation</h3>
<p>If the bug tracker allows creating new Products in the tracker, that can done by posting a representation of a new Product to the Bug Tracker container. In this example the client includes the necessary ldp membership properties making the new Product a container for Bug resources.</p>
<table>
<tr>
<td class='col1'><img src="app.png" /></td>
<td>
<p>The status of the bug tracker before creating the new product.</p>
<pre title="The state of the Bug Tracker LDPC"
class='example' data-include='product_create_s1.txt'
data-oninclude='fixCode'></pre>
</td>
</tr>
<tr>
<td class="col1"><img src="app_post.png" /></td>
<td>
<p>The client POSTs a representation of a Product to the Bug Tracker LDPC.</p>
<pre title="A request for creating a product"
class='example' data-include='product_create_req.txt'
data-oninclude='fixCode'></pre>
<p>If the create is successful, the server responds with location of the newly created resource.</p>
<pre title="The response after creating new product" class="example">
HTTP/1.1 201 Created
Location: /app/product2
Content-Length: 0
</pre>
</td>
</tr>
<tr>
<td></td><td>
<p>After creation of this new container, 'product2', the representation of the 'Tracker' container will be</p>
<pre title="The state of the Bug Tracker after the product creation"
class='example' data-include='product_create_s2.txt'
data-oninclude='fixCode'></pre>
<p>and the 'product2' will have the following representation.</p>
<pre title="The state of the new Product"
class='example' data-include='product_create_s3.txt'
data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
</section>
<section>
<h3 id="ProductLookup">Operation Discovery</h3>
<p>
Assuming that a user got the URL of the product by out of band means, a starting point would be to discover
which operations can be performed on the product resource.
</p>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>The client does an OPTIONS with the URI of a known product description resource.</p>
<pre class="example">OPTIONS /app/product1/ HTTP/1.1
Host: example.org
</pre>
<p>If the product description resource is available, the server responds with the allowed HTTP operations on the product
resource along with some other metadata.</p>
<div class="turtle">
<pre title="HTTP response for OPTIONS on a product" class='example'>
HTTP/1.1 200 OK
Allow: OPTIONS,HEAD,GET,POST,PUT,PATCH
Accept-Post: text/turtle, application/ld+json
Accept-Patch: example/patch
Link: <http://www.w3.org/ns/ldp/Resource>; rel="type"
Link: <?nonMemberProperties>;rel="http://www.w3.org/ns/ldp#nonMemberResource"
Content-Length: 0
</pre>
</div>
</td>
</tr>
</table>
<p> According to the response, HTTP operations {OPTIONS,GET,POST,PUT,PATCH} are allowed on the product description resource.
In addition to the allowed operations, Accept-Post and Accept-Patch provides which media types are supported by respective operations.
The rel="type" Link header advertises that this is resource supports LDP protocol and the the rel="ldp:nonMemberResource" provides a link
to the non-member resource of this product description.
</p>
</section>
<section id="paging">
<h3>Pagination</h3>
<p>It sometimes happens that a resource is too large to reasonably transmit its representation in a single HTTP response. For example, if the
bug resource in our example includes comments, It might happen that it may be become too large. To address this problem, LDPRs should support
a technique called Paging.</p>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>If a client does a get on an LDPR that supports paging, it will be redirected to the first page of the resource.</p>
<pre class="example">
GET /app/product1/bug3 HTTP/1.1
Host: example.org
</pre>
<pre class="example">
HTTP/1.1 303 See Other
Location: /app/product1/bug3?firstpage
</pre>
</td>
</tr>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>Alternatively if the client wants to know in advance whether the resource is paged or not, it can do an OPTIONS request on the LDPR URI</p>
<pre class="example">
OPTIONS /app/product1/bug3 HTTP/1.1
Host: example.org
</pre>
<p>If the resource is paged, the response contains a HTTP Link header with rel="first"; and the target URI of that header would be the URL of
the first page resource. </p>
<pre class="example">
HTTP/1.1 200 OK
Allow: OPTIONS,HEAD,GET,PUT,PATCH
Accept-Patch: example/patch
Link: <http://www.w3.org/ns/ldp/Resource>; rel="type"
Link: </app/product1/bug3?firstpage>; rel="first"
Content-Length: 0
</pre>
</td>
</tr>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>After knowing the URL of the first page resource, the client can retrieve it using a HTTP GET</p>
<pre class="example">
GET /app/product1/bug3?firstpage HTTP/1.1
Host: example.org
Accept: text/turtle; charset=UTF-8
</pre>
<pre title="HTTP response for getting the first page resource"
class='example' data-include='paging_page1_res.txt'
data-oninclude='fixCode'></pre>
<p>The first page contains a link to the second page with LDPR as the subject,
ldp:nextPage as the predicate and the subsequent page as the object.</p>
</td>
</tr>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>The second page can be retrieved the same way as the first page was retrieved.</p>
<pre class="example">
GET /app/product1/bug3?secondPage HTTP/1.1
Host: example.org
Accept: text/turtle; charset=UTF-8
</pre>
<pre title="HTTP response for getting the second page resource"
class='example' data-include='paging_page2_res.txt'
data-oninclude='fixCode'></pre>
<p>The last page of resource contains with LDPR as the subject,
ldp:nextPage as the predicate and the rdf:nil as the object.</p>
</td>
</tr>
</table>
</section>
<section id="odering">
<h3>Ordering</h3>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>There are many cases where an ordering of the members of the container is important. </p>
<pre class="example">
GET /app/product1?firstPage HTTP/1.1
Host: example.org
Accept: text/turtle; charset=UTF-8
</pre>
<pre title="The representation of an ordered LDPC"
class='example' data-include='ordered_ldpc_resp.txt'
data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
</section>
<section id="binary-res">
<h3>Binary resources</h3>
<b>Creating a binary resource</b>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>We have an LDPC which we can use to create binary resources</p>
<pre title="The state of the attachments LDPC"
class='example' data-include='attachments_s1.txt'
data-oninclude='fixCode'></pre>
</td>
</tr>
<tr>
<td><img src="replace.png" /></td>
<td>
<p>The client POSTs a binary resource to the LDPC</p>
<pre title="A request for creating a product"
class='example'>POST /app/product1/bug3/attachments/ HTTP/1.1
Host: example.org
Content-Type: image/png
Slug: login-page.png
Content-Length: 1254
#### binary data #####
</pre>
<p>If the create is successful, the server it responds with a Location header and a Link header to
the automatically created metadata LDPR.</p>
<pre title="A response after creating new a binary resource" class='example'>HTTP/1.1 201 Created
Location: /app/product1/bug3/attachments/login-page.png
Link: </app/product1/bug3/attachments/1>; rel="meta"
Content-Length: 0
</pre>
</td>
</tr>
<tr>
<td></td>
<td>
<p>After the creation, LDPC representation looks like</p>
<pre title="The state of the attachments LDPC after creation"
class='example' data-include='attachments_s2.txt'
data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
</section>
<b>Accessing the binary resource</b>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>The client can retrieve the binary resource by doing a GET on the binary resource URI.</p>
<pre class="example">GET /app/product1/bug3/attachments/login-page.png HTTP/1.1
Host: example.org
Accept: image/png
</pre>
<p>LDPR server responds with</p>
<pre title="HTTP response for getting the binary resource"
class='example'>HTTP/1.1 200 OK
Content-Type: image/png
Link: </app/product1/bug3/attachments/1>; rel="meta"
ETag: W/"123456789"
#### binary data #####
</pre>
</td>
</tr>
</table>
</section>
<b>Accessing the metadata about the binary resource</b>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>The client can retrieve the metadata of the binary resource by doing a GET on the metadata-LDPR URI.</p>
<pre class="example">GET /app/product1/bug3/attachments/1
Host: example.org
Accept: text/turtle
</pre>
<p>LDPR server responds with</p>
<pre title="HTTP response for getting the binary resource"
class='example' data-include='attachments_m_get_res.txt'
data-oninclude='fixCode'></pre>
</td>
</tr>
</table>
</section>
<b>Updating the metadata about the binary resource</b>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>TODO</p>
<pre title="Updating the metadata of the binary resource"
class='example' data-include='attachments_m_update_req.txt'
data-oninclude='fixCode'></pre>
<p>LDPR server responds with</p>
<pre class="example">HTTP/1.1 204 No Content
ETag: W/"123456790"
</pre>
</td>
</tr>
</table>
</section>
<b>Deleting the binary resource</b>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>TODO</p>
<pre class="example"> DELETE /app/product1/bug3/attachments/login-page.png HTTP/1.1
Host: example.org
</pre>
<pre class="example">HTTP/1.1 204 No Content
ETag: W/"123456790"
</pre>
<pre class="example">GET /app/product1/bug3/attachments/login-page.png HTTP/1.1
Host: example.org
</pre>
<pre class="example">HTTP/1.1 410 Gone
</pre>
<pre class="example"> GET /app/product1/bug3/attachments/1
Host: example.org
</pre>
<pre class="example">HTTP/1.1 410 Gone
</pre>
</td>
</tr>
</table>
</section>
</section>
</section>
<section>
<h1 id="advexamples">Advanced Examples</h1>
<section>
<h3 id="ldpmemx">Uses of membership{Subject,Predicate,Object} predicates </h3>
<p>In most of the previous examples we kept the ldp:membershipSubject as the LDPC itself and ldp:membershipObject as the ldp:MemberSubject. However, these
predicates can be used to change the semantics of the membership relationship in LDPCs. </p>
<p class="note">TO DO: A small note on document vs Thing separation linking to <a href="http://www.w3.org/TR/webarch/#id-resources">Web Arch</a>,
, <a href="http://www.w3.org/TR/cooluris/#semweb">Cool URIs</a>, <a href="http://www.w3.org/TR/urls-in-data/#landing-pages">URLs in Data</a>.</p>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>If the separation between real world resource and information is important, the product description of the previous Bug Tracker example can
be alternatively designed as following.</p>
<pre title="Representation of the product description"
class='example' data-include='product_alt_s1.txt'
data-oninclude='fixCode'></pre>
<p>In the above example, the product description information resource is explicitly seperated from the real world product resource. Now the RDF representation
contains information about both the information resource that is identified by the URI </app/product1/> and the real world resource identified by the
URI </app/product1/#it>. </p>
<p>With this seperation, now the ldp:membershipSubject of the container is not the container URI itself but </app/product1/#it>. The effect of these is that
membership relation triples added when new resources are POSTed to this container will now have the subject </app/product1/#it> not the container URI. Further,
ldp:membershipObject of this container is foaf:primaryTopic. Thus, the object of the membership triple will not be the newly created resource but the foaf:primaryTopic
defined inside that newly created resource as shown in the following example. </p>
<pre title="HTTP request for creating a new bug report"
class='example' data-include='bug_alt_create_req.txt'
data-oninclude='fixCode'></pre>
<p>And the server will respond with the URI of the newly created information resource in the Location header.</p>
<pre title="Representation of the newly created bug"
class='example' data-oninclude='fixCode'>
HTTP/1.1 201 Created
Location: /app/product1/67
Content-Length: 0
</pre>
<p>After the resource creation, the representations of the LDPC and newly created LDPR would be </p>
<pre title="Representation of the LDPC"
class='example' data-oninclude='fixCode' data-include='product_alt_s2.txt'></pre>
<pre title="Representation of the newly created bug"
class='example' data-oninclude='fixCode' data-include='bug_alt_s1.txt'></pre>
</td>
</tr>
</table>
</section>
<section>
<h3 id="mempredinv">ldp:membershipPredicateInverse predicate</h3>
<p>In sometimes the membership relationship can defined in a way such that the container is becomes the object of the membership triple. For example,
in our example, if the membership triple was like < bug, bt:relatedProduct, product > the product container would look like</p>
<pre title="Representation of an LDPC with ldp:membershipPredicateInverse predicate"
class='example' data-oninclude='fixCode' data-include='product_inv_s1.txt'></pre>
<p>TODO - Find a better example</p>
</section>
<section id="res-inlining">
<h3>Resource Inlining</h3>
<p> TODO - Description </p>
<table>
<tr>
<td class="col1"><img src="replace.png" /></td>
<td>
<p>TODO - Description</p>
<pre title="A HTTP request to a LDPR with inlined resources"
class='example' data-oninclude='fixCode' data-include='res_inline_req.txt'></pre>
<p> </p>
<pre title="A HTTP response from a LDPR with inlined resources"
class='example' data-oninclude='fixCode' data-include='res_inline_res.txt'></pre>
</td>
</tr>
</table>
</section>
<section id="mem-inlining">
<h3>Member Inlining</h3>
</section>
</section>
<section>
<h1>Security</h1>
<p class="note">Mention a little bit about security</p>
</section>
<section>
<h1 id="ldpc">LDP Implementations</h1>
A list of implementations that plan to be LDP compliant is available in the LDP Implementations wiki page.
LDP Implementation report provides the coverage of the specification by each LDP implementation.
</section>
<section>
<h1 id="next">What To Read Next</h1>
The primer only provide an overview of the Linked Data Platform specifications. LDP WG has produced following documents that contribute to the Linked Data Platform specification.
<ul>
<li><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/TR/ldp-ucr.html">Linked Data Platform Use Cases and Requirements</a> [[LDP-UCR]]</li>
<li><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html">Linked Data Platform 1.0 specifcation</a> [[LDP]]</li>
<li>Linked Data Platform 1.0 Primer (This document)</li>
<li><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html">LDP Best Practices and Guidelines</a> [[LDP-BP]]</li>
<li><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/Test%20Cases/LDP%20Test%20Cases.html">Linked Data Platform 1.0 Test Cases</a>[[LDP-TESTS]]</li>
</ul>
</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>
<ul>
<li>2013-08-05 - Providing JSON-LD representations of the examples.</li>
<li>2013-07-03 - Moving the content from the wiki to the note.</li>
</ul>
</section>
</body>
</html>
\ No newline at end of file
--- a/ldp.html Wed Mar 05 16:33:45 2014 +0000
+++ b/ldp.html Wed Mar 05 16:34:18 2014 +0000
@@ -1,36 +1,9 @@
<!DOCTYPE html>
<!--
- Editor TODO:
- - Once companion documents have URLs, link to them. Search on "companion".
- - In #ldpr-HTTP_POST, move "Clients can create LDPRs via" content into an intro/overview section and add PATCH.
- - Once the membership* names stabilize, take a pass through for "membership consistent value", membership-constant-URI
- and see if there is a friendlier way to phrase it.
- - Paging intro: add 3rd example showing header linkage amongst pages and (HEAD on) the base resource.
- Maybe also insert HEAD on base as new first example instead of relying on text alone.
- - The word "canonical" is used twice in the document. Since we do not deal with URI
- canonicalization in the specification, I would remove the word and the meaning of
- the sentences is the same.
- - section 4.6...respec is adding extra spaces to the sectionRefs
- carefully read section 4.2 .
- ->
- carefully read section 4.2.
-
- defined in section 4.8 .
- ->
- defined in section 4.8.
- - The ReSpec SPARQL QUERY link is http://www.w3.org/TR/rdf-sparql-query/ , which has highlighted text
- referring readers to SPARQL 1.1. Which normative reference do we want?
- Various pre-LC comments:
- - 5.2.5.1 For a given triple T with a subject C of the LDPC and predicate of ldp:membershipPredicate,
- 5.2.5.2 For a given triple T with a subject C of the LDPC and predicate of ldp:membershipPredicateInverse,
- 5.2.10 Some LDPC's have membership object's that are not directly URIs minted upon LDPC member creation,
- (JohnA) I found these particularly hard to read. And I perpetrated the SortCollation paragraphs.
- Links to examples might be an 80-20 solution.
- - 5.3.1: I'd change the link to the example ("as in the example") to refer the concrete example #, I think example 9.
- Currently does not work when printing.
- Misc during LC comments:
- - http://lists.w3.org/Archives/Public/public-ldp/2013Aug/0002.html
- #1 Should update example in 5.1.3 to be more clear on what the request vs base URI is. Also example is missing ldp:nextPage.
+ TODO: Search for them within this document.
+ TODO: Once companion documents (best practices, primer) have URLs, link to them. Search on "companion".
+ TODO: Add new "discovery of server capabilities" non-norm section
+ TODO: Consider adding Venn diagram for differences of LDPCs
-->
<html>
<head>
@@ -44,8 +17,8 @@
<script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script>
<script class='remove'>
var respecConfig = {
- // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
- specStatus: "ED",
+ // specification status (e.g. ED, WD, LC, NOTE, etc.). If in doubt use ED.
+ specStatus: "LC",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "ldp",
@@ -55,7 +28,7 @@
// subtitle : "an excellent document",
// if you wish the publication date to be other than today, set this
- publishDate: "",
+ publishDate: "2014-03-11",
// if the specification's copyright date is a range of years, specify
// the start date here:
@@ -71,7 +44,10 @@
edDraftURI: "http://www.w3.org/2012/ldp/hg/ldp.html",
// if this is a LCWD, uncomment and set the end of its review period
- lcEnd: "2013-09-02",
+ lcEnd: "2014-04-02",
+
+ // Only include h1 and h2 level
+ maxTocLevel: 2,
// if you want to have extra CSS, append them to this list
// it is recommended that the respec.css stylesheet be kept
@@ -133,7 +109,34 @@
]
, status: "Proposed Standard"
, publisher: "IETF"
- }
+ },
+ "RFC5005": {
+ title: "Feed Paging and Archiving"
+ , href: "http://tools.ietf.org/html/rfc5005"
+ , authors: [
+ "M. Nottingham"
+ ]
+ , status: "Proposed Standard"
+ , publisher: "IETF"
+ },
+ "LDP-PAGING": {
+ title: "Linked Data Platform Paging"
+ , href: "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-paging.html"
+ , authors: [
+ "S. Speicher", "J. Arwe", "A. Malhotra"
+ ]
+ , status: "Editor's Working Draft"
+ , publisher: "W3C"
+ },
+ "Prefer": {
+ title: "Prefer"
+ , href: "http://tools.ietf.org/html/draft-snell-http-prefer-18"
+ , authors: [
+ "J. Snell"
+ ]
+ , status: "Internet Draft"
+ , publisher: "IETF"
+ },
},
};
</script>
@@ -190,7 +193,20 @@
background: #fff;
padding: 3px 1em;
}
-
+ .normal {
+ font-weight: normal;
+ font: normal 100% sans-serif;
+ }
+ .indented {
+ margin-left: +3em;
+ }
+ tr:nth-of-type(odd),.oddrow {
+ background:#F2F2F2; /* light grey, just enough to differentiate from white */
+ }
+ td {
+ padding:0 +1ex 0 +1ex; /* add a bit of space from rule/edge to text */
+ }
+
</style>
<style type="text/css" media="all">
code {
@@ -209,12 +225,21 @@
HTTP access to web resources that describe their state using the <abbr title="Resource Description Framework">RDF</abbr>
data model.
</section>
+
+ <section id='sotd'>
+ <p>
+ This is the 2nd Last Call for Comments where the Working Group has addressed all
+ raised issues and as a result some significant changes have been made, see <a href="#history" class="sectionRef"></a>. Most notably
+ the Working Group has decided to handle paging as an extension to LDP in a separate
+ REC-track specification. [[LDP-PAGING]]
+ </p>
+ </section>
<section class="informative" id="intro">
<h1>Introduction</h1>
<p>This specification describes the use
of HTTP for accessing, updating, creating and deleting resources from
- servers that expose their resources as Linked Data. It provides clarifications
+ servers that expose their resources as Linked Data. It provides clarifications
and extensions of the rules of Linked Data [[LINKED-DATA]]:</p>
<ol>
<li>Use URIs as names for things</li>
@@ -224,16 +249,12 @@
</li>
<li>Include links to other URIs, so that they can discover more things</li>
</ol>
- <p>This specification discusses standard HTTP and RDF techniques that you
- should use when constructing clients and servers that
+ <p>This specification discusses standard HTTP and RDF techniques
+ used when constructing clients and servers that
create, read, and write <a title="Linked Data Platform Resource">Linked Data Platform Resources</a>.
A companion document discusses best practices that you
should use, and anti-patterns you should avoid, when constructing these clients and servers.
</p>
- <p>This specification provides a widely re-usable pattern to deal with large resources.
- Depending on the server’s capabilities, a GET request on a <a title="Paged resource">resource</a> can
- return a <a title="Single-page resource">subset of the resource (one page)</a>, that provides access to subsequent pages
- (see <a href="#ldpr-Paging" class="sectionRef"></a>). </p>
<p>This specification defines a special type of <a>Linked Data Platform Resource</a>: a
<a title="Linked Data Platform Container">Container</a>. Containers are very useful
in building application models involving collections of resources, often homogeneous ones.
@@ -246,6 +267,10 @@
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>
+ <p>This specification provides some approaches to deal with large resources. An extension to this specification
+ provides the ability to break large resource representations into multiple paged responses [[LDP-PAGING]].</p>
+ <p>For context and background, it could be useful to read <a href="#bib-LDP-UCR">Linked Data Platform Use Case and Requirements</a> [[LDP-UCR]]
+ and <a href="#base-specs" class="sectionRef"></a>.</p>
</section>
<section id="terms">
@@ -262,15 +287,6 @@
<dt>Linked Data</dt>
<dd>As defined by Tim Berners-Lee [[LINKED-DATA]].<p></p></dd>
- <dt><dfn>Linked Data Platform Resource</dfn> (<abbr title="Linked Data Platform Resource">LDPR</abbr>)</dt>
- <dd>HTTP resource whose state is represented in RDF that conforms to the simple lifecycle
- patterns and conventions in <a href="#ldpr" class="sectionRef"></a>.<p></p></dd>
-
- <dt><dfn>Linked Data Platform Container</dfn> (<abbr title="Linked Data Platform Container">LDPC</abbr>)</dt>
- <dd>An LDPR representing a collection of <a title="Membership triples">membership triples</a> 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 [[HTTP11]].<p></p></dd>
@@ -285,185 +301,153 @@
Likewise, any server may act as an origin server, proxy, gateway,
or tunnel, switching behavior based on the nature of each request
[[HTTP11]]. </p></dd>
+
+ <dt><dfn>Linked Data Platform Resource</dfn> (<abbr title="Linked Data Platform Resource">LDPR</abbr>)</dt>
+ <dd>A HTTP resource whose state is represented in any way that conforms to the simple lifecycle
+ patterns and conventions in <a href="#ldpr" class="sectionRef"></a>.<p></p></dd>
+
+ <dt><dfn>Linked Data Platform RDF Source</dfn> (<abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>)</dt>
+ <dd>An <a title="Linked Data Platform Resource">LDPR</a> whose state is fully represented in RDF, corresponding to
+ an RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a>. See also the term
+ <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-source">RDF Source</a> from [[!rdf11-concepts]].
+ <p></p></dd>
+
+ <dt><dfn>Linked Data Platform Non-RDF Source</dfn> (<abbr title="Linked Data Platform Non-RDF Source">LDP-NR</abbr>)</dt>
+ <dd>An <a title="Linked Data Platform Resource">LDPR</a> whose state is <em>not</em> represented in RDF.
+ These are binary or text documents that do not have useful RDF representations.
+ <p></p></dd>
+
+ <dt><dfn>Linked Data Platform Container</dfn> (<abbr title="Linked Data Platform Container">LDPC</abbr>)</dt>
+ <dd>An LDP-RS representing a collection of linked
+ documents (<a href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-document">RDF Document</a> [[!rdf11-concepts]] or information resources [[!WEBARCH]])
+ that responds to client requests for creation, modification, and/or enumeration of its linked members and documents,
+ and that conforms to the simple lifecycle
+ patterns and conventions in <a href="#ldpc" class="sectionRef"></a>.
+ <p></p></dd>
+
+ <dt><dfn>Linked Data Platform Basic Container</dfn> (<abbr title="Linked Data Platform Basic Container">LDP-BC</abbr>)</dt>
+ <dd>An <a title="Linked Data Platform Container">LDPC</a> that defines a simple link to
+ its <a title="Containment">contained</a> documents (information resources) [[!WEBARCH]].
+ <p></p></dd>
+
+ <dt><dfn>Linked Data Platform Direct Container</dfn> (<abbr title="Linked Data Platform Direct Container">LDP-DC</abbr>)</dt>
+ <dd>An <a title="Linked Data Platform Container">LDPC</a> adds the concept <a title="Membership">membership</a>, allows the flexibility of choosing what form its
+ <a title="Membership triples">membership triples</a> take, and allows <a title="Membership">members</a> to be
+ any resources [[!WEBARCH]], not only documents.
+ <p></p></dd>
+
+ <dt><dfn>Linked Data Platform Indirect Container</dfn> (<abbr title="Linked Data Platform Indirect Container">LDP-IC</abbr>)</dt>
+ <dd>An <a title="Linked Data Platform Container">LDPC</a> that is similar to a <a title="Linked Data Platform Direct Container">LDP-DC</a>
+ and is capable of having <a title="Membership">members</a> whose URIs are based
+ on the content of its <a title="Containment">contained</a> documents rather than the URIs assigned to those documents.
+ <p></p></dd>
+
+ <dt><dfn>Membership</dfn></dt>
+ <dd>The relationship linking an LDP-RS (LDPCs are also LDP-RSs) and its member LDPRs.
+ There often is a linked LDPC that assists with managing the member LDPRs.<p></p></dd>
<dt><dfn>Membership triples</dfn></dt>
- <dd>A set of triples in an LDPC's state that lists its members.
- A container's membership triples all have one of the following patterns:
- <table style="margin-left: +3em">
+ <dd>A set of triples in an LDP-RS's state that lists its members.
+ An LDP-RS's membership triples all have one of the following patterns:
+ <table class="indented">
<tr>
- <td style="padding:0 0 0 +2ex"> <var style="background:#DDDDDD">membership-constant-URI</var> </td>
- <td style="padding:0 0 0 +2ex"> <var>membership-predicate</var> </td>
- <td style="padding:0 0 0 +2ex"> <var style="background:#CCFFFF">member-URI</var> </td>
+ <td style="background:#DDDDDD"> <var>membership-constant-URI</var> </td>
+ <td style="background:#FFFFFF"> <var>membership-predicate</var> </td>
+ <td style="background:#CCFFFF"> <var>member-derived-URI</var> </td>
</tr>
<tr>
- <td style="padding:0 0 0 +2ex"> <var style="background:#CCFFFF">member-URI</var> </td>
- <td style="padding:0 0 0 +2ex"> <var>membership-predicate</var> </td>
- <td style="padding:0 0 0 +2ex"> <var style="background:#DDDDDD">membership-constant-URI</var> </td>
+ <td style="background:#CCFFFF"> <var>member-derived-URI</var> </td>
+ <td style="background:#FFFFFF"> <var>membership-predicate</var> </td>
+ <td style="background:#DDDDDD"> <var>membership-constant-URI</var> </td>
</tr>
</table>
- The difference between the two is simply which position member-URI occupies, which is usually
+ The difference between the two is simply which position member-derived-URI occupies, which is usually
driven by the choice of <var>membership-predicate</var>. Most predicates have a natural forward direction
inherent in their name, and existing vocabularies contain useful examples that read naturally in
- each direction. <code>rdfs:member</code> and <code>dcterms:isPartOf</code> are representative examples.
+ each direction. <code>ldp:member</code> and <code>dcterms:isPartOf</code> are representative examples.
<p>
- Each container exposes properties that allow clients to determine which pattern it
+ Each linked container exposes properties (see <a href="#ldpc-general" class="sectionRef"></a>)
+ that allow clients to determine which pattern it
uses, what the actual <var>membership-predicate</var> and <var>membership-constant-URI</var> values are,
and (for containers that allow the creation of new members) what value is used
- for the <var>member-URI</var> based on the client's input to the
+ for the <var>member-derived-URI</var> based on the client's input to the
creation process.</p>
<p></p></dd>
<dt><dfn>Membership predicate</dfn></dt>
- <dd>The predicate of all a LDPC's <a title="Membership triples">membership triples</a>.
- <p></p></dd>
-
- <dt><dfn>Paged resource</dfn></dt>
- <dd>A resource whose representation may be too large to fit in a single HTTP response, for which an
- LDP server offers a sequence of single-page resources. When the representations of the sequence's resources
- are combined by a client, the client has a (potentially incomplete) copy of the paged resource's
- state. If a paged resource <var>P</var> is an LDPR and is broken into a sequence of pages
- (single-page resources) <var>P<sub>1</sub>, P<sub>2</sub>, ...,P<sub>n</sub></var>,
- the representation of each <var>P<sub>i</sub></var> contains
- a subset of the triples in <var>P</var>.
- LDP allows paging of resources other than LDPRs, but does not specify how clients combine
- their representations. See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.
+ <dd>The predicate of all an LDP-RS's <a title="Membership triples">membership triples</a>.
<p></p></dd>
- <dt><dfn>Single-page resource</dfn></dt>
- <dd>One of a sequence of related resources <var>P<sub>1</sub>, P<sub>2</sub>, ...,P<sub>n</sub></var>,
- each of which contains a subset of the state
- of another resource <var>P</var>. <var>P</var> is called the paged resource.
- </p><p>
- Note: the choice of terms was designed to help authors and readers clearly differentiate between
- the <a title="Paged resource"><em>resource being paged</em></a>, and the
- <a title="Single-page resource"><em>individual page resources</em></a>,
- in cases where both are mentioned in
- close proximity. Both are resources in both the HTTP and RDF senses.
+ <dt><dfn>Containment</dfn></dt>
+ <dd>The relationship binding an LDPC to LDPRs whose lifecycle it controls and is aware of. The
+ lifecycle of the contained LDPR is limited by the lifecycle of the containing LDPC;
+ that is, a contained LDPR cannot be created (through LDP-defined means) before its containing LDPC exists.
<p></p></dd>
-
- <dt><dfn>Non-member resource</dfn></dt>
- <dd>A resource associated with a LDPC by a server for the purpose of enabling clients to
- retrieve a subset of the LDPC's state, namely the subset that omits the LDPC's membership triples.
- In other words, the union of the non-member resource's state and the LDPC's membership triples
- exactly equals the LDPC's state.
+
+ <dt><dfn>Containment triples</dfn></dt>
+ <dd>
+ A set of triples in an LDPC's state, maintained by the LDPC, that lists documents created by the LDPC but not yet deleted.
+ These triples <strong>always</strong> have the form: <var>( LDPC URI, ldp:contains , document-URI )</var>.
<p></p></dd>
-
+
+ <dt><dfn>Empty-container triples</dfn></dt>
+ <dd>
+ The portion of an LDPC's state that would be present when the container is empty. Currently, this definition
+ is equivalent to all the LDPC's triples minus its containment triples and minus its membership
+ triples, but if future versions of LDP define additional classes of triples then this definition
+ would expand to subtract out those classes as well.
+ <p></p></dd>
</dl>
<section id="conventions">
<h2>Conventions Used in This Document</h2>
-
+ <p>The namespace for LDP is <code>http://www.w3.org/ns/ldp#</code>.</p>
<p>Sample resource representations are provided in <code>text/turtle</code>
- format [[TURTLE]].</p>
+ format [[turtle]].</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>
+ @prefix foaf: <http://xmlns.com/foaf/0.1/>.
+ @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
+ @prefix ldp: <http://www.w3.org/ns/ldp#>.
+ @prefix xsd: <http://www.w3.org/2001/XMLSchema#>.</pre>
</section>
</section>
<section id='conformance'>
-<p>LDP uses the term <b><dfn>informative</dfn></b> as a synonym for non-normative.</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>1. Introduction: <b>non-normative</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>
+ <li>6. Notable information from normative references: <b>non-normative</b></li>
+ <li>7. HTTP Header Definitions: <b>normative</b></li>
+ <li>8. Security Considerations: <b>non-normative</b></li>
+ <li>A. Acknowledgements: <b>non-normative</b></li>
+ <li>B. Change History: <b>non-normative</b></li>
+ <li>C.1 Normative references: <b>normative</b></li>
+ <li>C.2 Non-normative references: <b>non-normative</b></li>
</ul>
-<div class="ldp-issue-closed">
-<p>(OLD) 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="#ldpr" class="sectionRef"></a> and <a href="#ldpc" class="sectionRef"></a>.
+<p>A conforming <b><dfn>LDP client</dfn></b> is a conforming HTTP client [[!HTTP11]] that follows the rules defined by LDP in
+<a href="#ldpr" class="sectionRef"></a> and also
+<a href="#ldpc" class="sectionRef"></a>.
</p>
-<p>(OLD) 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="#ldpr" class="sectionRef"></a>
-and <a href="#ldpc" class="sectionRef"></a>.
-</p>
-</div>
-
-<div class="ldp-issue-open">
-<p>(NEW) A conforming <b><dfn>LDP client</dfn></b> is a conforming HTTP client [[!HTTP11]] that follows the rules defined by LDP in
-<a href="#ldpclient" class="sectionRef"></a>.
-</p>
-
-<p>(NEW) A conforming <b><dfn>LDP server</dfn></b> is a conforming HTTP server [[!HTTP11]] that follows the rules defined by LDP in
+<p>A conforming <b><dfn>LDP server</dfn></b> is a conforming HTTP server [[!HTTP11]] that follows the rules defined by LDP in
<a href="#ldpr" class="sectionRef"></a> when it is serving LDPRs, and also
<a href="#ldpc" class="sectionRef"></a> when it is serving LDPCs.
LDP does not constrain its behavior when serving other HTTP resources.
</p>
-
-<p>(NEW) LDP defines several classes of LDP servers, and places different conformance requirements on each of them.
-NOTE: "Basic" and "advanced" used here for drafting purposes; they correspond to 'vanilla' and 'chocolate', respectively.
-Final names TBD.
-</p>
-<ul>
- <li><p>A conforming <b><dfn>basic LDP server</dfn></b> is a conforming LDP server that follows the rules defined by LDP
- for basic LDP servers, as shown below. Its content model is generally open and the server typically stores triples on behalf of clients
- with minimal (if any) restrictions.
- </p></li>
- <li><p>A conforming <b><dfn>advanced LDP server</dfn></b> is a conforming LDP server that follows the rules defined by LDP
- for advanced LDP servers, as shown below. Its content model can be open or closed, and the server may impose non-trivial
- restrictions on triples stored on behalf of conforming HTTP clients.
- </p></li>
-</ul>
-
-<section>
-<h5>Example conformance rules</h5>
-
-<p>The following informative examples show how LDP assigns conformance criteria to each class of LDP servers using a single rule.</p>
-
-<section>
-<h6>Example: the same criteria apply to both basic and advanced LDP servers</h6>
-<div class="example">
- <div class="rule">LDP servers SHOULD ... </div>
-</div>
-
-<p>The preceding rule is equivalent to the following pair of rules:</p>
-<div class="example">
- <div class="rule">Basic LDP servers SHOULD ... </div>
- <div class="rule">Advanced LDP servers SHOULD ... </div>
-</div>
</section>
-<section>
-<h6>Example: different criteria apply to basic and advanced LDP servers</h6>
-<p>Trying out different ways of covering each class while minimizing text duplication here. Final format TBD.</p>
-<div class="example">
- <div class="rule">(proposal 1) LDP servers MUST (basic)/SHOULD (advanced) ... </div>
- <div class="rule">(proposal 2) Basic LDP servers MUST, and advanced LDP servers SHOULD, ... </div>
- <div class="rule">(proposal 3) Basic LDP servers MUST ... . Advanced LDP servers SHOULD do so. </div>
-</div>
-
-<p>Each of the preceding rules is equivalent to the following pair of rules:</p>
-<div class="example">
- <div class="rule">4.8.2 Basic LDP servers MUST ...
- </div>
- <div class="rule">4.8.2 Advanced LDP servers SHOULD ...
- </div>
-</div>
-</section>
-
-</div>
-
-</section>
-
-
<section id="ldpr">
<h1>Linked Data Platform Resources</h1>
<section class="informative" id="ldpr-informative">
-<h2>Informative</h2>
+<h2>Introduction</h2>
<p>Linked Data Platform Resources (<dfn><abbr title="Linked Data Platform Resources">LDPRs</abbr></dfn>) are HTTP resources
that conform to the simple patterns and conventions in this section.
HTTP requests to access, modify, create or delete LDPRs are accepted
@@ -482,176 +466,155 @@
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>
+ <li>How do I GET the representation of a large resource 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
+ <p>Additional non-normative guidance is available in the <a
+ href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html"
+ class="external"
+ title="LDP Best Practices and Guidelines"
+ rel="nofollow">LDP Best Practices and Guidelines editor's draft</a> that addresses
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 conformance rules for LDP servers when serving LDPRs.
- This document also explains <a href="#ldpr-Paging">how to paginate an LDPR's representation</a> if it gets too big.
- Companion documents describe additional guidelines for use when interacting with LDPRs.
+ Companion non-normative documents describe additional guidelines for use when interacting with LDPRs.
</p>
+ <p>LDP-RS's representations may be too big, one strategy is to break up the response representation
+ into client consumable chunks called pages. A separate LDP specification outlines the conformance
+ rules around pagination [[LDP-PAGING]].
+ </p>
+ <p>An LDP server manages two kinds of <a title="Linked Data Platform Resources">LDPRs</a>, those resources who whose state
+ is represented using RDF (LDP-RS) and those using other formats (LDP-NR). LDP-RSs have the unique
+ quality that their representation is based on RDF, which addresses a number of use cases from web metadata, open data
+ models, machine processable information, and automated processing by software agents [[!rdf11-concepts]]. LDP-NRs are almost anything
+ on the Web today: images, HTML pages, word processing documents, spreadsheets, etc. and LDP-RSs hold
+ metadata associated with LDP-NRs in some cases.
+ </p>
+ <figure id="fig-ldpr-types">
+ <img src="images/ldpr1.png" alt="Sample separation of Linked Data Platform Resource" />
+ <figcaption>Samples of different types of LDPRs</figcaption>
+ </figure>
+ <p>The LDP-NRs and LDP-RSs are simply sub-types of LDPRs, as illustrated in <a href="#fig-ldpr-class"></a>.</p>
+ <figure id="fig-ldpr-class">
+ <img src="images/ldpr2.png" alt="Class Diagram of Linked Data Platform Resource" />
+ <figcaption>Class relationship of types of Linked Data Platform Resources</figcaption>
+ </figure>
+
+</section>
-</section>
+<section id="ldpr-resource">
+<h2>Resource</h2>
<section id="ldpr-general">
<h2>General</h2>
- <div id="ldpr-4_2_1" class="rule">4.2.1 <a title="LDP server">LDP servers</a> MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].</div>
- <div id="ldpr-4_2_2" class="rule">4.2.2 <a title="LDP server">LDP servers</a> MUST provide an RDF representation for LDPRs.
- The HTTP <code>Request-URI</code> of the LDPR is typically the subject of most triples in the response.
- </div>
- <div id="ldpr-4_2_3" class="rule">4.2.3 <a title="LDP server">LDP servers</a> MAY host a mixture of LDPRs and non-LDPRs. For example, it
+ <section id="ldpr-gen-http"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].
+ </h2></section><!-- Was 4.2.1 / #ldpr-4_2_1 -->
+
+ <section id="ldpr-gen-binary"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY host a mixture of LDPRs, <a title="Linked Data Platform RDF Source">LDP-RSs</a>
+ and <a title="Linked Data Platform Non-RDF Source">LDP-NRs</a>. For example, it
is common for <a title="LDP server">LDP servers</a> to need to host binary or text resources
- that do not have useful RDF representations.
- </div>
+ that do not have useful RDF representations.</h2></section><!-- Was 4.2.3 / #ldpr-4_2_3 -->
- <div id="ldpr-4_2_4" class="rule">4.2.4 LDPRs SHOULD reuse existing vocabularies instead of creating
- their own duplicate vocabulary terms. In addition to this general rule, some specific cases are
- covered by other conformance rules.
- </div>
- <div id="ldpr-4_2_4_1" class="rule">4.2.4.1 LDPR predicates SHOULD use standard vocabularies such as Dublin Core
- [[!DC-TERMS]], RDF [[!RDF-CONCEPTS]] and RDF Schema [[!RDF-SCHEMA]], whenever
- possible.
- </div>
- <div id="ldpr-4_2_5" class="rule">4.2.5 LDPR representations SHOULD have at least one <code>rdf:type</code>
- set explicitly. This makes the representations much more useful to
- client applications that don’t support inferencing.
- </div>
- <!-- Action-108 removed this 2013-10-22
- <div id="ldpr-4_2_6" class="rule">4.2.6 <a title="LDP server">LDP servers</a> MAY support standard representations beyond those
- necessary to conform to this specification. These
- could be other RDF formats, like N3 or NTriples, but non-RDF formats
- like HTML [[!HTML401]] and JSON [[!RFC4627]] would likely be common.
- </div>
- -->
- <!-- Action-108 removed this 2013-10-22
- <div id="ldpr-4_2_7" class="rule">4.2.7 LDPRs MAY be created, updated and deleted using methods not defined in
- this document, for example through application-specific means, SPARQL
- UPDATE, etc. [[!SPARQL-UPDATE]], as long as those methods do not conflict with this specification's
- normative requirements.
- </div>
- -->
- <div id="ldpr-4_2_8" class="rule">4.2.8 <a title="LDP server">LDP server</a> responses MUST use entity tags (either weak or strong
-ones) as response <code>ETag</code> header values.
- </div>
- <!-- Action-110 removed this 2013-10-25
- <div id="ldpr-4_2_9" class="rule">4.2.9 LDPR
- servers SHOULD enable simple creation and modification of LDPRs.
- It is
- common for <a title="LDP server">LDP servers</a> 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 LDPR, but
- servers SHOULD 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 <a title="LDP server">LDP servers</a>
+ <section id="ldpr-gen-etags"><h2 class="normal"><a title="LDP server">LDP server</a> responses MUST use entity tags (either
+ weak or strong ones) as response <code>ETag</code> header values.
+ </h2></section><!-- Was 4.2.8 / #ldpr-4_2_8 -->
+
+ <section id="ldpr-gen-linktypehdr"><h2 class="normal"><a title="LDP server">LDP servers</a>
+ exposing LDPRs
MUST advertise their LDP support by exposing a HTTP <code>Link</code> header
- with a target URI of <code>http://www.w3.org/ns/ldp/Resource</code>, and
+ 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 inspect dynamically at run-time. Conservative clients should note that
- <a href="#ldpr-4_2_3">a server can host a mixture of LDPRs and other resources</a>, and therefore there is no implication
+ to the LDPR's HTTP <code>Request-URI</code>.
+ </h2></section><!-- Was 4.2.10 / #ldpr-4_2_10 -->
+ <blockquote>
+ <p>
+ Note:
+ The HTTP <code>Link</code> header is the method by which servers assert their support for the LDP specification
+ on a specific resource in a way that clients can inspect dynamically at run-time.
+ This is <strong>not</strong> equivalent to the
+ presence of a <var>(subject-URI, <code>rdf:type</code>, <code>ldp:Resource</code>)</var> triple in an LDP-RS.
+ The presence of this header asserts that the server complies with the LDP specification's constraints on
+ HTTP interactions with LDPRs, that is
+ it asserts that the resource <a href="#ldpr-gen-etags">has Etags</a>, <a href="#ldprs-gen-rdf">has an RDF representation</a>, and so on,
+ which is not true of all Web resources served as RDF media types.
+ </p>
+ <p>
+ Note:
+ <a href="#ldpr-gen-binary">An LDP server can host a mixture of LDPRs and other resources</a>, and therefore there is no implication
that LDP support advertised on one HTTP <code>Request-URI</code> means that other
resources on the same server are also LDPRs. Each HTTP <code>Request-URI</code> needs to be
- individually inspected by a conservative client, in the absence of outside information.
- </div>
- <div id="ldpr-4_2_11" class="rule">4.2.11 <a title="LDP server">LDP servers</a>
- MUST NOT require LDP clients to implement inferencing in order to recognize the subset
- of content defined by LDP. Other specifications built on top of LDP may require clients
- to implement inferencing [[!RDF-CONCEPTS]]. 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 <a title="LDP server">LDP servers</a> MUST assign the default base-URI for [[!RFC3987]] relative-URI resolution to be the HTTP
+ individually inspected, in the absence of outside information.
+ </p>
+ </blockquote>
+
+ <section id="ldpr-gen-defbaseuri"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST assign the default
+ base-URI for [[!RFC3987]] relative-URI resolution to be the HTTP
<code>Request-URI</code> when the resource already exists, and to the URI of the created resource when the request results
in the creation of a new resource.
- </div>
- <div id="ldpr-4_2_13" class="rule">4.2.13 <a title="LDP server">LDP servers</a> MUST
+ </h2></section><!-- Was 4.2.12 / #ldpr-4_2_12 -->
+
+ <section id="ldpr-gen-pubclireqs"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST
publish any constraints on <a title="LDP client">LDP clients’</a> ability to
create or update LDPRs, by adding a Link header with <code>rel='describedby'</code>
- [[!POWDER-DR]] to all responses to requests which fail due to violation of
+ [[!RFC5988]] to all responses to requests which fail due to violation of
those constraints. For example, a server that refuses resource creation
requests via HTTP PUT, POST, or PATCH would return this <code>Link</code> header on its
4xx responses to such requests.
The same <code>Link</code> header MAY be provided on other responses. LDP neither
- defines nor constrains the representation of the link's target resource;
- as stated in [[POWDER-DR]], the target might (or might not) be a POWDER
- document. Natural language constraint documents are therefore permitted,
+ defines nor constrains the representation of the link's target resource. Natural language
+ constraint documents are therefore permitted,
although machine-readable ones facilitate better client interactions.
- </div>
- <div id="ldpr-page-large" class="rule">4.2.14 <a title="LDP server">LDP servers</a> SHOULD allow clients to retrieve large LDPRs in
- pages.
- See <a href="#ldpr-Paging" class="sectionRef"></a> for additional requirements associated with <a title="Paged resource">paged resources</a>.
- </div>
- <div id="ldpr-split-any" class="rule">4.2.15 <a title="LDP server">LDP servers</a> MAY
- treat any resource (LDPR or not) as a <a title="Paged resource">paged resource</a>.
- See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.
- </div>
+ </h2></section><!-- Was 4.2.13 / #ldpr-4_2_13 -->
</section>
<section id="ldpr-HTTP_GET">
<h2>HTTP GET</h2>
- <div id="ldpr-4_3_1" class="rule">4.3.1 <a title="LDP server">LDP servers</a> MUST support the HTTP <code>GET</code> Method for LDPRs.
- </div>
- <div id="ldpr-4_3_2" class="rule">4.3.2 <a title="LDP server">LDP servers</a> MUST support the HTTP response headers defined in
+ <section id="ldpr-get-must"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST support the HTTP <code>GET</code> Method for LDPRs.
+ </h2></section><!-- Was 4.3.1 / #ldpr-4_3_1 -->
+
+ <section id="ldpr-get-options"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST support the HTTP response headers defined in
<a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
- </div>
- <div id="ldpr-4_3_3" class="rule">4.3.3 <a title="LDP server">LDP servers</a> MUST provide a <code>text/turtle</code>
- representation of the requested LDPR [[!TURTLE]].
- </div>
- <!-- Action-108 removed this 2013-10-22
- <div id="ldpr-4_3_4" class="rule">4.3.4 <a title="LDP server">LDP servers</a> MAY provide
- representations of the requested LDPR beyond those
- necessary to conform to this specification, using standard HTTP content negotiation ([[!HTTP11]] Section 12 - Content Negotiation).
- If the client does not indicate a preference, <code>text/turtle</code> SHOULD 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,
- <a title="LDP client">LDP clients</a> MUST assume that any LDPR 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,
- <a title="LDP client">LDP clients</a> MUST assume that the <code>rdf:type</code> values
- of a given LDPR can change over time.
- </div>
+ </h2></section><!-- Was 4.3.2 / #ldpr-4_3_2 -->
+
</section>
<section id="ldpr-HTTP_POST">
<h2>HTTP POST</h2>
- <p>This specification adds no new requirements on HTTP <code>POST</code> for LDPRs
- even when the LDPR supports that method. This specification does not impose any
- new requirement to support that method, and [[!HTTP11]] makes it optional.
+ <p>
+ Per [[HTTP11]], this HTTP method is optional and
+ this specification does not require <a title="LDP server">LDP servers</a> to support it.
+ When an LDP server supports this method,
+ this specification imposes no new requirements for LDPRs.
</p>
- <p>Clients can create LDPRs via <code>POST</code> (<a href="#ldpc-HTTP_POST" class="sectionRef"></a>) or
- <code>PUT</code> (<a href="#ldpc-HTTP_PUT" class="sectionRef"></a>) to a LDPC, see those
- sections for more details. Any server-imposed constraints on LDPR creation or update
- <a href="#ldpr-4_2_13">must be advertised</a> to clients.
+
+ <p>Clients can create LDPRs via <code>POST</code> (<a href="#ldpc-HTTP_POST" class="sectionRef"></a>) to an LDPC,
+ via <code>PUT</code> (<a href="#ldpr-HTTP_PUT" class="sectionRef"></a>), or any other methods allowed
+ for HTTP resources. Any server-imposed constraints on LDPR creation or update
+ <a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
+
</p>
</section>
<section id="ldpr-HTTP_PUT">
<h2>HTTP PUT</h2>
- <p>This specification imposes the following new requirements on HTTP <code>PUT</code> for LDPRs
- only when the LDPR supports that method. This specification does not impose any
- new requirement to support that method, and [[!HTTP11]] makes it optional.
- Any server-imposed constraints on LDPR creation or update
- <a href="#ldpr-4_2_13">must be advertised</a> to clients.
+ <p>
+ Per [[HTTP11]], this HTTP method is optional and
+ this specification does not require <a title="LDP server">LDP servers</a> to support it.
+ When an LDP server supports this method,
+ this specification imposes the following new requirements for LDPRs.
</p>
- <div id="ldpr-4_5_1" class="rule">4.5.1 If a HTTP <code>PUT</code> is accepted on an existing resource,
+ <p>
+ Any server-imposed constraints on LDPR creation or update
+ <a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
+ </p>
+
+ <section id="ldpr-put-replaceall"><h2 class="normal">If a HTTP <code>PUT</code> is accepted on an existing resource,
<a title="LDP server">LDP servers</a> MUST
replace the entire persistent state of the identified resource with
the entity representation in the body of the request.
@@ -661,26 +624,43 @@
to support a more sophisticated merge of data provided by the client
with existing state stored on the server for a resource MUST use HTTP
<code>PATCH</code>, not HTTP <code>PUT</code>.
- </div>
+ </h2></section><!-- Was 4.5.1 / #ldpr-4_5_1 -->
- <div id="ldpr-4_5_1_1" class="rule">4.5.1.1
+ <section id="ldpr-put-simpleupdate"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to update resources without
+ requiring detailed knowledge of server-specific constraints.
+ This is a consequence of the requirement to enable simple creation and modification of LDPRs.
+ </h2></section><!-- Was 4.5.7 / #ldpr-4_5_7 -->
+
+ <section id="ldprs-put-servermanagedprops"><h2 class="normal">
If an otherwise valid HTTP <code>PUT</code> request is received
- that attempts to change triples the server does not allow clients to modify,
+ that attempts to change properties the server does not allow clients to modify,
<a title="LDP server">LDP servers</a> MUST
respond with a 4xx range status code (typically
409 Conflict).
<a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
- information about which triples could not be
+ information about which properties could not be
persisted.
The format of the 4xx response body is not constrained by LDP.
- </div>
+ </h2></section><!-- Was 4.5.1.1 / #ldpr-4_5_1_1 -->
<blockquote>
- Informative note: Clients might provide triples equivalent to those already in the resource's state,
+ Non-normative note: Clients might provide properties equivalent to those already in the resource's state,
e.g. as part of a GET/update representation/PUT sequence, and those PUT requests are intended to work as long as the
- server-controlled triples are identical on the GET response and the subsequent PUT request.
+ server-controlled properties are identical on the GET response and the subsequent PUT request.
</blockquote>
-
- <div id="ldpr-4_5_2" class="rule">4.5.2 <a title="LDP client">LDP clients</a> SHOULD use the HTTP <code>If-Match</code>
+
+ <section id="ldprs-put-failed"><h2 class="normal">
+ If an otherwise valid HTTP <code>PUT</code> request is received that contains properties the server
+ chooses not to persist, e.g. unknown content,
+ <a title="LDP server">LDP servers</a> MUST respond with an appropriate 4xx range status code
+ [[HTTP11]].
+ <a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
+ information about which properties could not be
+ persisted.
+ The format of the 4xx response body is not constrained by LDP. LDP servers
+ expose these application-specific constraints as described in <a href="#ldpr-general" class="sectionRef"></a>.
+ </h2></section><!-- Was 4.5.4 / #ldpr-4_5_4 -->
+
+ <section id="ldpr-put-precond"><h2 class="normal"><a title="LDP client">LDP clients</a> SHOULD use the HTTP <code>If-Match</code>
header and HTTP <code>ETags</code> to ensure it isn’t
modifying a resource that has changed since the client last retrieved
its representation. <a title="LDP server">LDP servers</a> SHOULD require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
@@ -688,94 +668,55 @@
(Condition Failed) if <code>ETag</code>s fail to match when there are no other
errors with the request [[!HTTP11]]. <a title="LDP server">LDP servers</a> that require conditional requests MUST respond with status code 428
(Precondition Required) when the absence of a precondition is the only reason for rejecting the request [[!RFC6585]].
- </div>
- <div id="ldpr-4_5_3" class="rule">4.5.3 <a title="LDP client">LDP clients</a> SHOULD always assume that the set of predicates for a
- resource of a particular type at an arbitrary server is open, in the
- 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
- If an otherwise valid HTTP <code>PUT</code> request is received that contains triples the server
- chooses not to persist, e.g. unknown content,
- <a title="LDP server">LDP servers</a> MUST respond with an appropriate 4xx range status code
- [[HTTP11]].
- <a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
- information about which triples could not be
- persisted.
- The format of the 4xx response body is not constrained by LDP.
- </div>
- <div id="ldpr-4_5_5" class="rule">4.5.5 An <a title="LDP client">LDP client</a> MUST preserve all triples retrieved using HTTP <code>GET</code> that
- it doesn’t change whether it understands the predicates or not, when
- its intent is to perform an update using HTTP <code>PUT</code>. The use of HTTP
- <code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
- [[RFC5789]].
- </div>
- <div id="ldpr-4_5_6" class="rule">4.5.6 <a title="LDP server">LDP servers</a> MAY choose to allow the creation of new resources using HTTP <code>PUT</code>.
- </div>
- <div id="ldpr-4_5_7" class="rule">4.5.7 <a title="LDP server">LDP servers</a> SHOULD allow clients to update resources without
- 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>
+ </h2></section><!-- Was 4.5.2 / #ldpr-4_5_2 -->
+
+ <section id="ldpr-put-create"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY choose to allow the creation of new resources using HTTP <code>PUT</code>.
+ </h2></section><!-- Was 4.5.6 / #ldpr-4_5_6 -->
+
</section>
<section id="ldpr-HTTP_DELETE">
<h2>HTTP DELETE</h2>
- <p>This specification imposes the following new requirements on HTTP <code>DELETE</code> for LDPRs
- only when the LDPR supports that method. This specification does not impose any
- new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
- <p>Additional requirements on HTTP <code>DELETE</code> of LDPRs within containers can be found in
- <a href="#ldpc-HTTP_DELETE" class="sectionRef"></a>.</p>
+ <p>
+ Per [[HTTP11]], this HTTP method is optional and
+ this specification does not require <a title="LDP server">LDP servers</a> to support it.
+ When an LDP server supports this method,
+ this specification imposes the following new requirements for LDPRs.
+ </p>
- <!-- Action-108 removed this 2013-10-22
- <div id="ldpr-4_6_1" class="rule">4.6.1 <a title="LDP server">LDP servers</a> MUST remove the resource identified by the <code>Request-URI</code>.
- After a successful HTTP <code>DELETE</code>, a subsequent HTTP <code>GET</code> on the same
- <code>Request-URI</code> MUST result in a 404 (Not found) or 410 (Gone) status
- code. Clients SHOULD note that servers MAY reuse a URI under some circumstances.
- </div>
- -->
-
- <!-- Action-108 removed this 2013-10-22
- <div id="ldpr-4_6_2" class="rule">4.6.2 <a title="LDP server">LDP servers</a> MAY alter the state of other resources as a result of an
- 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 <a title="LDP server">LDP servers</a> to
- not do this – behavior is server application specific.
- </div>
- -->
+ <p>Additional requirements on HTTP <code>DELETE</code> of LDPRs within containers can be found in
+ <a href="#ldpc-HTTP_DELETE" class="sectionRef"></a>.
+ </p>
</section>
<section id="ldpr-HTTP_HEAD">
<h2>HTTP HEAD</h2>
- <p>Note that certain LDP mechanisms, such as <a href="#ldpr-Paging">paging</a>, rely on HTTP headers, and HTTP generally requires that
+ <p>Note that certain LDP mechanisms 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 sections <a href="#ldpr-HTTP_GET"></a>
and <a href="#ldpr-HTTP_OPTIONS"></a>.</p>
- <div id="ldpr-4_7_1" class="rule">4.7.1 <a title="LDP server">LDP servers</a> MUST support the HTTP <code>HEAD</code> method.</div>
+ <section id="ldpr-head-must"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST support the HTTP <code>HEAD</code> method.
+ </h2></section><!-- Was 4.7.1 / #ldpr-4_7_1 -->
</section>
<section id="ldpr-HTTP_PATCH">
<h2>HTTP PATCH</h2>
- <p>This specification imposes the following new requirements on HTTP <code>PATCH</code> for LDPRs
- only when the LDPR supports that method. This specification does not impose any
- new requirement to support that method, and [[!HTTP11]] makes it optional.
+ <p>
+ Per [[RFC5789]], this HTTP method is optional and
+ this specification does not require <a title="LDP server">LDP servers</a> to support it.
+ When an LDP server supports this method,
+ this specification imposes the following new requirements for LDPRs.
+ </p>
+
+ <p>
Any server-imposed constraints on LDPR creation or update
- <a href="#ldpr-4_2_13">must be advertised</a> to clients.
- </p>
- <!-- Action-108 removed this 2013-10-22
- <div id="ldpr-4_8_1" class="rule">4.8.1 <a title="LDP server">LDP servers</a> MAY implement HTTP <code>PATCH</code> to allow modifications,
- especially partial replacement, of their resources [[!RFC5789]]. No
- minimal set of patch document formats is mandated by this document.
- </div>
- -->
- <div id="ldpr-4_8_3" class="rule">4.8.3 <a title="LDP server">LDP servers</a> SHOULD NOT allow clients to create new resources using <code>PATCH</code>.
- <a href="#ldpc-HTTP_POST"><code>POST</code> (to an LDPC)</a> and/or <a href="#ldpr-HTTP_PUT"><code>PUT</code></a> should be used as the standard way to create new LDPRs.
- </div>
- <div id="ldpr-4_8_4" class="rule">4.8.4 <a title="LDP server">LDP servers</a> that support <code>PATCH</code> MUST
+ <a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
+ </p>
+
+ <section id="ldpr-patch-acceptpatch"><h2 class="normal"><a title="LDP server">LDP servers</a> that support <code>PATCH</code> MUST
include an <code>Accept-Patch</code> HTTP response header [[!RFC5789]] on HTTP <code>OPTIONS</code>
requests, listing patch document media type(s) supported by the server.
- </div>
+ </h2></section><!-- Was 4.8.4 / #ldpr-4_8_4 -->
</section>
@@ -784,254 +725,155 @@
<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for LDPRs
beyond those in [[!HTTP11]]. 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>,
+ <a href="#header-accept-post">Accept-Post</a>,
add other requirements on <code>OPTIONS</code> responses.
</p>
- <div id="ldpr-4_9_1" class="rule">4.9.1 <a title="LDP server">LDP servers</a> MUST support the HTTP <code>OPTIONS</code> method.</div>
- <div id="ldpr-4_9_2" class="rule">4.9.2 <a title="LDP server">LDP servers</a> MUST indicate their support for HTTP Methods by
+ <section id="ldpr-options-must"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST support the HTTP <code>OPTIONS</code> method.
+ </h2></section><!-- Was 4.9.1 / #ldpr-4_9_1 -->
+
+ <section id="ldpr-options-allow"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST indicate their support for HTTP Methods by
responding to a HTTP <code>OPTIONS</code> request on the LDPR’s URL with the HTTP
Method tokens in the HTTP response header <code>Allow</code>.
- </div>
-
-</section>
-
-<section id="ldpr-Paging">
-<h2>Paging</h2>
-
-<section class="informative" id="ldpr-PagingIntro">
-<h3>Introduction</h3>
- <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
- is a container whose
- representation includes many triples both from itself and
- from its member resources. 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, resources should support a technique called Paging. Paging can be achieved with a
- simple 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 of an LDPR
- are typically a subset of the triples in the resource
- - same subject, predicate and object.
- </p>
- <p><a title="LDP server">LDP servers</a> may respond to requests for a
- resource by returning the first page resource –
- using a <a href="#status-code-related-content"><code>209 Related Content</code></a> response
- with a <code>Location</code> header containing the URL for the page
- resource. Alternatively, clients may inspect 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, identified by the URI <code>http://example.org/customer-relations</code>,
- we’ll split the response across two pages.
- To find out if the resource supports paging, and if it does the URL of the first page,
- the client makes a <code>OPTIONS</code> or <code>HEAD</code> request
- to <code>http://example.org/customer-relations</code>, 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>, and
- the server responds with the following representation:
- </p>
-
-<pre class="example"># The following is the representation of
-# http://example.org/customer-relations?firstPage
-# Requests on the ?firstPage URI will result in responses that include the following HTTP header
-# Link: <http://example.org/customer-relations?p=2>; rel='next'
-# This Link header is how clients discover the URI of the next page in sequence.
-@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>.
-
-<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>
-
- <p>
- The server determines the size of the pages using application specific methods not defined
- within this specificiation. The next page link's target URI 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>
-
-<pre class="example"># The following is the representation of
-# http://example.org/customer-relations?p=2
-#
-# There is no "next" Link in the server's response, so this is the final page.
-#
-@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>.
-
-<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>
- <p>
- In this example, there are only two customers provided in the
- final page. To indicate this is the last page, the server omits the <code>Link rel='next'</code>
- header in its response.
- </p>
-</section>
-
-<section id="ldpr-PagingGET">
-<h3>HTTP GET</h3>
- <p>In addition to the requirements set forth in <a href="#ldpr-HTTP_GET" class="sectionRef"></a> on HTTP <code>GET</code>,
- <a title="LDP server">LDP servers</a> that support paging must
- also follow the requirements in this section for all <a title="Paged resource">paged resources</a>
- and their associated <a title="Single-page resource">single-page resources</a>.
- </p>
-
- <div id="ldpr-pagingGET-first-reqd-onbase" class="rule">4.10.2.1 <a title="LDP server">LDP servers</a> MUST
- provide an HTTP <code>Link</code>
- header whose target URI is the <em>first</em> <a title="Single-page resource">single-page resource</a>, and whose link relation type is <code>first</code> [[!RFC5988]]
- in responses to <code>GET</code> requests with a <a title="Paged resource">paged resource</a> as the <code>Request-URI</code>.
- This is the mechanism by which clients can discover the URL of the first page.
- For example, if there is a LDPR 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>.
- If no such <code>Link</code> header is present,
- then clients have no LDP-defined way to discover that the resource supports paging or the
- URI of the first page.
- </div>
- <div id="ldpr-pagingGET-first-allowed-onpages" class="rule">4.10.2.1.1
- <a title="LDP server">LDP servers</a> MAY provide
- a <a href="#ldpr-pagingGET-first-reqd-onbase">first page link</a> when responding to
- requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
- </div>
- <div id="ldpr-pagingGET-last-allowed-onbase" class="rule">4.10.2.1.2 <a title="LDP server">LDP servers</a> MAY
- provide an HTTP <code>Link</code>
- header whose target URI is the final <a title="Single-page resource">single-page resource</a>,
- and whose link relation type is <code>last</code> [[!RFC5988]]
- in responses to <code>GET</code> requests with a <a title="Paged resource">paged resource</a> as the <code>Request-URI</code> and/or
- requests with a <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
- This is the mechanism by which clients can discover the URL of the final page without
- following a potentially long sequence of next links.
- If no such <code>Link</code> header is present,
- then clients can only find the final page using LDP-defined means
- by following the <code>next</code> links to the end.
- </div>
- <div id="ldpr-pagingGET-last-allowed-onpages" class="rule">4.10.2.1.3 <a title="LDP server">LDP servers</a> MAY
- provide a <a href="#ldpr-pagingGET-last-allowed-onbase">last page link</a>
- in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a> as the <code>Request-URI</code>.
- </div>
- <div id="ldpr-pagingGET-next-reqd" class="rule">4.10.2.2 <a title="LDP server">LDP servers</a> MUST
- provide an HTTP <code>Link</code>
- header whose target URI is the next page resource, and whose link relation type is <code>next</code> [[!RFC5988]]
- in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a>
- <em>other than the final page</em>
- as the <code>Request-URI</code>.
- This is the mechanism by which clients can discover the URL of the next page.
- </div>
- <div id="ldpr-pagingGET-lastnext-prohibited" class="rule">4.10.2.2.1 <a title="LDP server">LDP servers</a> MUST NOT
- provide a <a href="#ldpr-pagingGET-next-reqd">next page link</a>
- in responses to <code>GET</code> requests with the final <a title="Single-page resource">single-page resource</a>
- as the <code>Request-URI</code>.
- This is the mechanism by which clients can discover the end of the page sequence.
- </div>
- <div id="ldpr-pagingGET-prev-allowed" class="rule">4.10.2.2.2 <a title="LDP server">LDP servers</a> MAY
- provide an HTTP <code>Link</code>
- header whose target URI is the previous page resource, and whose link relation type is <code>prev</code> [[!RFC5988]]
- in responses to <code>GET</code> requests with any page resource <em>other than the first page</em>
- as the <code>Request-URI</code>.
- This is one mechanism by which clients can discover the URL of the previous page.
- </div>
- <div id="ldpr-pagingGET-firstprev-prohibited" class="rule">4.10.2.2.3 <a title="LDP server">LDP servers</a> MUST NOT
- provide a <a href="#ldpr-pagingGET-prev-reqd">previous page link</a>
- in responses to <code>GET</code> requests with the <em>first</em> <a title="Single-page resource">single-page resource</a>
- as the <code>Request-URI</code>.
- This is one mechanism by which clients can discover the beginning of the page sequence.
- </div>
- <div id="ldpr-pagingGET-next-reqd" class="rule">4.10.2.2.4 <a title="LDP server">LDP servers</a> MUST
- provide an HTTP <code>Link</code>
- header whose target URI is the <a title="Paged resource">paged resource</a>, and whose link relation type is <code>collection</code> [[!RFC5988]]
- in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a>
- as the <code>Request-URI</code>.
- This is the mechanism by which clients can discover the URL of the resource whose representation
- has been broken into pages, in cases where some other actor gives the client
- a <a title="Single-page resource">single-page resource</a> URL.
- </div>
- <div id="ldpr-pagingGET-redirect" class="rule">4.10.2.3 <a title="LDP server">LDP servers</a>
- that initiate paging for a LDPR MUST respond
- by returning the first page resource using a <code>209 Related Content</code> response
- with an HTTP <code>Location</code> header providing the first <a title="Single-page resource">single-page resource</a> URL.
- </div>
- <div id="ldpr-pagingGET-page-type-reqd" class="rule">4.10.2.4 <a title="LDP server">LDP servers</a> MUST
- provide an HTTP <code>Link</code>
- header whose target URI is <code>http://www.w3.org/ns/ldp#Page</code>, and whose link relation type is <code>type</code> [[!RFC5988]]
- in responses to <code>GET</code> requests with any <a title="Single-page resource">single-page resource</a>
- as the <code>Request-URI</code>.
- This is one mechanism by which clients know that the resource is one of a sequence of pages.
- </div>
-</section>
-
-<section id="ldpr-paging-HTTP_OPTIONS">
-<h3>HTTP OPTIONS</h3>
-
- <p>In addition to the requirements set forth in
- <a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a> on HTTP <code>OPTIONS</code>,
- <a title="LDP server">LDP servers</a> that support paging must also
- follow the requirements in this section for all <a title="Paged resource">paged resources</a>.
- Note that LDP only requires enough from <code>OPTIONS</code>
- for discovery of paging support on a resource, which is considerably
- less than is required for HTTP <code>GET</code>.
- This lowers server implementation effort.
- </p>
-
- <div id="ldpr-4_10_3_1" class="rule">4.10.3.1 <a title="LDP server">LDP servers</a> MUST indicate their support for paging by
- providing a <a href="#ldpr-pagingGET-first-reqd-onbase">first page link</a> when responding to HTTP <code>OPTIONS</code>
- requests with a <a title="Paged resource">paged resource</a> as the <code>Request-URI</code>.
- </div>
-
-</section> <!-- h3 -->
+ </h2></section><!-- Was 4.9.2 / #ldpr-4_9_2 -->
</section> <!-- h2 -->
-</section> <!-- h1 -->
+</section> <!-- ldpr-resource -->
+
+<section id="ldprs">
+<h2>RDF Source</h2>
+
+<p>The following section contains normative clauses for <a title="">Linked Data Platform RDF Source</a>.</p>
+
+<section id="ldprs-general">
+<h2>General</h2>
+
+ <section id="ldprs-are-ldpr"><h2 class="normal">Each <a title="Linked Data Platform RDF Source">LDP RDF Source</a> MUST also be
+ a conforming <a title="Linked Data Platform Resource">LDP Resource</a> in <a href="#ldpr-resource" class="sectionRef"></a> along the
+ following restrictions in this section. <a title="">LDP client</a>s MAY infer the following triple:
+ whose subject is <code>ldp:RDFSource</code>,
+ whose predicate is <code>rdfs:subClassOf</code>,
+ and whose object is <code>ldp:Resource</code>,
+ but there is no requirement to materialize this triple in the LDP-RS representation.
+ </h2></section>
+
+ <section id="ldprs-gen-atleast1rdftype"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> representations SHOULD have at least one <code>rdf:type</code>
+ set explicitly. This makes the representations much more useful to
+ client applications that don’t support inferencing.
+ </h2></section><!-- Was 4.2.5 / #ldpr-4_2_5 -->
+
+ <section id="ldprs-rdftype"><h2 class="normal">The representation of an LDP-RS MAY have an <code>rdf:type</code>
+ of only one of <code>ldp:RDFSource</code> for <a title="">Linked Data Platform RDF Source</a>.
+ </h2></section><!-- Was 5.2.7 / #ldpc-5_2_7 -->
+
+ <section id="ldprs-gen-rdf"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide an RDF representation for <a title="Linked Data Platform RDF Source">LDP-RSs</a>.
+ The HTTP <code>Request-URI</code> of the LDP-RS is typically the subject of most triples in the response.
+ </h2></section><!-- Was 4.2.2 / #ldpr-4_2_2 -->
+
+ <section id="ldprs-gen-reusevocab"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> SHOULD reuse existing vocabularies instead of creating
+ their own duplicate vocabulary terms. In addition to this general rule, some specific cases are
+ covered by other conformance rules.
+ </h2></section><!-- Was 4.2.4 / #ldpr-4_2_4 -->
+
+ <section id="ldprs-gen-reusevocabsuchas"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> predicates SHOULD use standard vocabularies such as Dublin Core
+ [[!DC-TERMS]], RDF [[!rdf11-concepts]] and RDF Schema [[!rdf-schema]], whenever
+ possible.
+ </h2></section><!-- Was 4.2.4.1 / #ldpr-4_2_4_1 -->
+
+ <section id="ldp-cli-multitype"><h2 class="normal">In the absence of special knowledge of the application or domain,
+ <a title="LDP client">LDP clients</a> MUST assume that any LDP-RS can have multiple values for <code>rdf:type</code>.
+ </h2></section> <!-- Was 4.3.5 / #ldpr-4_3_5 -->
+
+ <section id="ldpr-cli-typeschange"><h2 class="normal">In the absence of special knowledge of the application or domain,
+ <a title="LDP client">LDP clients</a> MUST assume that the <code>rdf:type</code> values
+ of a given LDP-RS can change over time.
+ </h2></section> <!-- Was 4.3.6 / #ldpr-4_3_6 -->
+
+ <section id="ldpr-cli-openpreds"><h2 class="normal"><a title="LDP client">LDP clients</a> SHOULD always assume that the set of predicates for a
+ LDP-RS 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 LDP-RS is not limited to any pre-defined
+ set.
+ </h2></section> <!-- Was 4.5.3 / #ldpr-ldpr-4_5_3 -->
+
+ <section id="ldprs-gen-noinferencing"><h2 class="normal"><a title="LDP server">LDP servers</a>
+ MUST NOT require LDP clients to implement inferencing in order to recognize the subset
+ of content defined by LDP. Other specifications built on top of LDP may require clients
+ to implement inferencing [[!rdf11-concepts]]. The practical implication is that all content defined by LDP
+ must be explicitly represented, unless noted otherwise within this document.
+ </h2></section><!-- Was 4.2.11 / #ldpr-4_2_11 -->
+
+ <section id="ldpr-cli-preservetriples"><h2 class="normal">
+ A <a title="LDP client">LDP client</a> MUST preserve all triples retrieved from an LDP-RS using HTTP <code>GET</code> that
+ it doesn’t change whether it understands the predicates or not, when
+ its intent is to perform an update using HTTP <code>PUT</code>. The use of HTTP
+ <code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
+ [[RFC5789]].
+ </h2></section> <!-- Was 4.5.5 / #ldpr-ldpr-4_5_5 -->
+
+ <section id="ldpr-cli-can-hint"><h2 class="normal">
+ <a title="LDP client">LDP clients</a> MAY
+ provide LDP-defined hints that allow servers to optimize the content of responses.
+ <a href="#prefer-parameters" class="sectionRef"></a> defines hints that apply to
+ <a title="Linked Data Platform RDF Source">LDP-RSs</a>.
+ </h2></section>
+
+ <section id="ldpr-cli-hints-ignorable"><h2 class="normal">
+ <a title="LDP client">LDP clients</a> MUST
+ be capable of processing responses formed by an LDP server that ignores hints,
+ including LDP-defined hints.
+ </h2></section>
+
+ <div class="atrisk" id="atrisk-paging"><p class="atrisktext">Feature At Risk</p>
+ <p>The LDP Working Group proposes incorporation of the following clause to make LDP clients paging aware:</p>
+ <section id="ldpr-cli-paging"><h2 class="normal">
+ <a title="LDP client">LDP clients</a> SHOULD
+ be capable of processing successful HTTP <code>GET</code> responses formed by an LDP server
+ that independently initiated paging, returning a page of representation instead of full resource
+ representation [[!LDP-PAGING]].
+ </h2>
+ </section>
+ </div>
+
+</section> <!-- ldprs-general -->
+
+<section id="ldprs-HTTP_GET">
+<h2>HTTP GET</h2>
+ <section id="ldprs-get-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide a <code>text/turtle</code>
+ representation of the requested <a title="Linked Data Platform RDF Source">LDP-RS</a> [[!turtle]].
+ </h2></section><!-- Was 4.3.3 / #ldpr-4_3_3 -->
+
+</section> <!-- ldprs-HTTP_GET -->
+
+</section> <!-- ldprs RDF Source-->
+
+<section id="ldpnr">
+<h2>Non-RDF Source</h2>
+
+<p>The following section contains normative clauses for <a title="">Linked Data Platform Non-RDF Source</a>.</p>
+
+<section id="ldpnr-general">
+<h2>General</h2>
+
+ <section id="ldpnr-are-ldpr"><h2 class="normal">Each <a title="Linked Data Platform Non-RDF Source">LDP Non-RDF Source</a> MUST also be
+ a conforming <a title="Linked Data Platform Resource">LDP Resource</a> in <a href="#ldpr-resource" class="sectionRef"></a>.
+ <a title="Linked Data Platform Non-RDF Source">LDP Non-RDF Source</a> may not be able to fully express their
+ state using RDF. [[rdf11-concepts]]
+ </h2></section>
+
+</section> <!-- ldpnr Non-RDF Source-->
+
+</section>
+
+</section> <!-- ldpr h1 -->
<section id="ldpc">
<h1>Linked Data Platform Containers</h1>
<section class="informative" id="ldpc-informative">
-<h2>Informative</h2>
+<h2>Introduction</h2>
<p>Many HTTP applications and sites have organizing
concepts that partition the overall space of resources into smaller
containers. Blog posts are grouped into blogs, wiki pages are grouped
@@ -1043,14 +885,19 @@
<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>
+ <li>How is the order of the container entries expressed? [[LDP-PAGING]]</li>
</ol>
<p>
This document defines the representation and behavior of containers
- that address these issues. The set of members of a container is
+ that address these issues. There are multiple types of containers defined
+ to support a variety of use cases, all that support a base set of capabilities.
+ The contents of a container is
defined by a set of triples in its representation (and state) called
+ the <a title="Containment triples">containment triples</a> that follow a fixed pattern.
+ Additional types of containers allow for the set of members of a container to be
+ defined by a set of triples in its representation called
the <a title="Membership triples">membership triples</a> that follow a consistent pattern
(see the linked-to definition for the possible patterns).
The membership triples of a container all
@@ -1061,51 +908,54 @@
In the simplest cases, the
consistent value will be the LDPC resource's URI, 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.
+ be a predicate from the server application vocabulary or the <code>ldp: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>
+ creating new resources and adding them to the list of
+ resources linked to a container. It goes on to explain how to learn about a set of related
+ resources, regardless of how they were created or added to the container's membership.
+ It also defines behavior when resources created using a container are later deleted;
+ deleting containers removes membership information and
+ possibly performs 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>
-<pre class="example"># The following is the representation of
-# http://example.org/container1/
+<pre class="example" id="ldpc-ex-simple"># The following is the representation of
+# http://example.org/c1/
<!-- @base is here only so it's easier to paste into validators for checking -->
-# @base <http://example.org/container1/>
+# @base <http://example.org/c1/>
@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>
+ a ldp:BasicContainer;
+ dcterms:title "A very simple container";
+ ldp:contains <r1>, <r2>, <r3>.</pre>
+
+ <!-- TODO: consider if basic container diagram helps, if so...add for other cases too
+ <figure id="fig-ldpc-basic">
+ <img src="images/ldpc-basic.png" alt="Sample Linked Data Platform Basic Container" />
+ <figcaption>Sample of Linked Data Platform Basic Container</figcaption>
+ </figure>
+ -->
- <p>This example is very straightforward - the
- membership predicate is <code>rdfs:member</code> and the other
- consistent membership value is the container's
- URI, occurring in the subject position of the triples.
- 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>This example is very straightforward - there is the containment triple
+ with subject of the container, predicate of
+ <code>ldp:contains</code> and objects indicating the URIs of the contained resources.
+ A POST to this container will create a new resource
+ and add it to the list of contained resources by adding a new containment triple
+ to the container. This type of container is also referred to as
+ <a title="">Linked Data Platform Basic Container</a>.</p>
<p>Sometimes it is useful to use a subject
other than the container itself as the consistent membership value, and/or to use
- a predicate other than <code>rdfs:member</code> as the membership predicate. Let's
+ a predicate from an application's domain model as the membership predicate. Let's
start with a domain resource for a person's net worth, as illustrated below:</p>
<pre class="example" id="ldpc-ex-membership-partial"># The following is a partial representation of
-# http://example.org/netWorth/nw1
+# http://example.org/netWorth/nw1
<!-- @base is here only so it's easier to paste into validators for checking -->
# @base <http://example.org/netWorth/nw1/>
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@@ -1126,13 +976,13 @@
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:
+ illustrated in the set of related examples (one example per HTTP resource) below:
</p>
-<pre class="example" id="ldpc-ex-membership-full"># The following is an elaborated representation of
-# http://example.org/netWorth/nw1/
+<pre class="example" id="ldpc-ex-membership-full"># The following is an elaborated representation of LDPR
+# http://example.org/netWorth/nw1
<!-- @base is here only so it's easier to paste into validators for checking -->
-# @base <http://example.org/netWorth/nw1/>
+# @base <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/>.
@@ -1146,29 +996,46 @@
<liabilityContainer/l1>,
<liabilityContainer/l2>,
<liabilityContainer/l3>.
+</pre>
-<assetContainer/>
- a ldp:Container;
+<pre class="example" id="ldpc-ex-membership-subj"># The following is an elaborated representation of LDPC
+# http://example.org/netWorth/nw1/assetContainer/
+<!-- @base is here only so it's easier to paste into validators for checking -->
+# @base <http://example.org/netWorth/nw1/assetContainer/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix o: <http://example.org/ontology/>.
+<>
+ a ldp:DirectContainer;
dcterms:title "The assets of JohnZSmith";
- ldp:membershipSubject <>;
- ldp:membershipPredicate o:asset;
- ldp:membershipObject ldp:MemberSubject.
+ ldp:membershipResource <http://example.org/netWorth/nw1/>;
+ ldp:hasMemberRelation o:asset;
+ ldp:contains <a1>, <a2>.
+</pre>
-<liabilityContainer/>
- a ldp:Container;
+<pre class="example" id="ldpc-ex-membership-full-liabcont"># The following is an elaborated representation of LDPC
+# http://example.org/netWorth/nw1/liabilityContainer/
+<!-- @base is here only so it's easier to paste into validators for checking -->
+# @base <http://example.org/netWorth/nw1/liabilityContainer/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix o: <http://example.org/ontology/>.
+<>
+ a ldp:DirectContainer;
dcterms:title "The liabilities of JohnZSmith";
- ldp:membershipSubject <>;
- ldp:membershipPredicate o:liability;
- ldp:membershipObject ldp:MemberSubject.
+ ldp:membershipResource <http://example.org/netWorth/nw1/>;
+ ldp:hasMemberRelation o:liability;
+ ldp:contains <l1>, <l2>, <l3>.
</pre>
<p>The essential structure of the container is
- the same, but in this example, the consistent membership value (still in the subject position) is not the
+ the same, but in this example, the consistent membership value
+ (<a title="Membership triples">membership-constant-URI</a>, still in the subject position) 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
+ to the resource and containment 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,
@@ -1177,495 +1044,321 @@
and <code>http://example.org/netWorth/nw1/liabilityContainer/</code> container
resources allows both assets and liabilities to be created.
</p>
-
-<pre class="example" id="ldpc-ex-membership-subj"># The following is the representation of
-# http://example.org/netWorth/nw1/assetContainer/
-<!-- @base is here only so it's easier to paste into validators for checking -->
-# @base <http://example.org/netWorth/nw1/assetContainer/>
-@prefix ldp: <http://www.w3.org/ns/ldp#>.
-@prefix o: <http://example.org/ontology/>.
+ <p>This type of container is referred to as an <a title="Linked Data Platform Direct Container">LDP Direct Container</a>.
+ <a title="Linked Data Platform Direct Container">LDP Direct Container</a> adds the concept of <a title="Membership">membership</a>
+ and flexibilty on how to specify the <a title="Membership triples">membership triples</a>.
+ </p>
-<>
- 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>
-
- <p>In this example, clients cannot correctly guess
- at the membership triples, so the example includes this information in
- triples whose subject is the LDPC resource itself.
+ <p>As seen in the <a href="#ldpc-ex-membership-subj"><code>assetContainer/</code> example</a>,
+ clients cannot correctly guess
+ at the membership triples, so the example includes this information in
+ triples whose subject is the LDPC 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. LDPC 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 RDF 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>
-
-<pre class="example"># The following is the representation of
-# http://example.org/netWorth/nw1/assetContainer/
+ <p>Alternatively, servers may provide the net worth resource and supporting containers in a single response
+ representations. When doing this, a preference would be for RDF formats that support multiple named graphs, one
+ named graph for the net worth resource and then two others for asset and liability containers. This allows for
+ the membership triples to be represented with the named graph for the net worth resource, while the containment triples
+ would be represented within the liability and asset containers [[rdf11-concepts]]. Generally, the membership triples belong
+ to the representation of an LDP-RS and the containment triples belong to the representation of the LDPC.
+ </p>
+
+ <p>Additionally, we could extend our net worth example to include a container for
+ advisors (people) that have managed the assets and liabilities. We have decided
+ to identify these advisors with URLs that contain a fragment (hash) to represent
+ these real-world resources, not the documents that describe them.</p>
+
+<pre class="example" id="ldpc-ex-membership-full-elab"># The following is an elaborated representation of
+# http://example.org/netWorth/nw1
+# Adding o:advisor but eaving off o:asset and o:liability for brevity.
<!-- @base is here only so it's easier to paste into validators for checking -->
-# @base <http://example.org/netWorth/nw1/assetContainer/>
+# @base <http://example.org/netWorth/nw1/>
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
-@prefix ldp: <http://www.w3.org/ns/ldp#>.
-@prefix o: <http://example.org/ontology/>.
+@prefix foaf: <http://xmlns.com/foaf/0.1/>.
+@prefix o: <http://example.org/ontology/>.
+<>
+ a o:NetWorth;
+ o:netWorthOf <http://example.org/users/JohnZSmith>;
+ o:advisor
+ <advisorContainer/bob#me>,
+ <advisorContainer/marsha#me>.
+
+<advisorContainer/>
+ a ldp:IndirectContainer;
+ dcterms:title "The asset advisors of JohnZSmith";
+ ldp:membershipResource <>;
+ ldp:hasMemberRelation o:advisor;
+ ldp:insertedContentRelation foaf:primaryTopic;
+ ldp:contains
+ <advisorContainer/bob>,
+ <advisorContainer/marsha>.
+</pre>
+
+ <p>To handle this type of indirection, the triple with predicate of <code>ldp:insertedContentRelation</code> and object of
+ <code>foaf:primaryTopic</code> informs clients that when POSTing to this container, they need to include a triple of the
+ form <code>(<>, foaf:primaryTopic, topic-URI)</code> to inform the server which URI to use
+ (<code>topic-URI</code>) in the new membership triple.</p>
+
+ <p>This type of container is also referred to as a <a title="Linked Data Platform Indirect Container">LDP Indirect Container</a>.
+ It is similar to an <a title="Linked Data Platform Direct Container">LDP Direct Container</a>
+ but it provides an indirection to add (via a create request) as member any resource,
+ such as a URI representing a real-world object,
+ that is different from the document that is created.</p>
-<>
- 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>.
+ <p><a href="#fig-ldpc-types"></a> illustrates the 3 types: Container, Basic Container and Direct Container, along
+ with their class relationship to types of LDPRs.</p>
+
+ <figure id="fig-ldpc-types">
+ <img src="images/ldpc-hierarchy.png" alt="Types of Linked Data Platform Containers" />
+ <figcaption>Class relationship of types of Linked Data Platform Containers</figcaption>
+ </figure>
-<a1>
- a o:Stock;
- o:value 10000 .
-<a2>
- a o:Bond;
- o:value 20000 .
-<a3>
- a o:RealEstateHolding;
- o:value 300000 .</pre>
- <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>
+ <p>The following table illustrates some differences between <a title="membership">membership</a> and
+ <a title="containment">containment</a> triples. For details on the normative behavior, see appropriate sections
+ below.
+ </p>
+ <table style="border: 1px solid gray" id="ldpc-mbrcntdiff">
+ <thead><tr><th rowspan="2">Completed Request</th><th colspan="2">Effects</th></tr>
+ <tr class="oddrow"><th>Membership</th><th>Containment</th></tr></thead>
+ <tr><td>LDPR created in LDP-BC</td><td>New triple: (LDPC, ldp:contains, LDPR)</td><td>Same</td></tr>
+ <tr><td>LDPR created in LDP-DC</td><td>New triple links LDP-RS to created LDPR. LDP-RS URI may be same as LDP-DC</td>
+ <td>New triple: (LDPC, ldp:contains, LDPR)</td></tr>
+ <tr><td>LDPR created in LDP-IC</td><td>New triple links LDP-RS to content indicated URI</td>
+ <td>New triple: (LDPC, ldp:contains, LDPR)</td></tr>
+ <tr><td>LDPR is deleted</td><td>Membership triple may be removed</td><td>(LDPC, ldp:contains, LDPR) triple is removed
+ </td></tr>
+ <tr><td>LDPC is deleted</td><td>Triples and member resources may be removed</td><td>Triples of form
+ (LDPC, ldp:contains, LDPR) and contained LDPRs may be removed</td></tr>
+ </table>
- <div id="ldpc-get_non-member_props" class="rule">5.1.2 Retrieving Only Non-member Properties
- </div>
+<section id="ldpc-get_empty-container_props"><h2 class="normal">Retrieving Only Empty-Container Triples
+ </h2><!-- Was 5.1.1 / #ldpc-get_empty-container_props -->
<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
+ cases where clients need to access only the subset of the container's properties
+ that are unrelated to member resources and unrelated to contained documents, for
+ example to determine the membership triple pattern and membership predicate of an
+ LDP-DC. LDP calls these <a title="Empty-container triples">empty-container triples</a>,
+ because they are what remains when the container has zero members and zero contained resources.
+ 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 LDPC a corresponding
- resource, called the “<a>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
+ overhead on servers, we define a way to retrieve only
+ these property values (and more generally, a way to retrieve only the
+ subset of properties used to address other major clusters of use cases).
+ LDP adds parameters to the HTTP <code>Prefer</code> header's
+ <code>return=representation</code> preference for this
+ (see <a href="#prefer-parameters" class="sectionRef"></a> for details).
+ </p>
+ <p>The example listed here only shows
+ a simple case where few empty-container triples 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 SPARQL endpoints. [[SPARQL-QUERY]]</p>
+ associating SPARQL endpoints. [[sparql11-query]]</p>
<p>
- Here is an example requesting the non-member properties of a
+ Here is an example requesting the empty-container triples 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>
-<pre class="example">GET /container1?non-member-properties HTTP/1.1
+<p id="ldpc-ex-empty-container">Request:</p>
+<pre class="example">GET /container1 HTTP/1.1
Host: example.org
Accept: text/turtle; charset=UTF-8
+Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferEmptyContainer"
</pre>
<p>Response:</p>
<pre class="example">HTTP/1.1 200 OK
Content-Type: text/turtle; charset=UTF-8
ETag: "_87e52ce291112"
Content-Length: 325
+Link: <http://www.w3.org/ns/ldp#Container>; rel="type"
+Preference-Applied: return=representation
-@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;
+ a ldp:DirectContainer;
+ dcterms:title "A Linked Data Platform Container of Acme Resources";
+ ldp:membershipResource <http://example.org/container1/>;
+ ldp:hasMemberRelation ldp:member;
+ ldp:insertedContentRelation ldp:MemberSubject;
dcterms:publisher <http://acme.com/>.</pre>
- <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. LDPC 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, LDPC avoids the use of RDF
- constructs like Seq and List for expressing order.
- </p>
<p>
- Order becomes more important for <a title="LDP server">LDP servers</a> 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 LDPC 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
- sort order no lower than all members on the previous page and
- sort order no higher than all the members on the next page;
- that is, it proceeds from low to high, but keep in mind that several
- consecutive pages might have members whose sort criteria are equal.
- When the sort is descending, the opposite order is used.
- Since more than one value may be used to sort members,
- the LDPC 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>.
+ LDP recommends using PATCH to update these properties, if necessary. It provides no facility
+ for updating them via PUT without replacing the entire container's state.
</p>
- <p>Here is an example container described
- previously, with representation for ordering of the assets:</p>
-<pre class="example"># The following is the ordered representation of
-# http://example.org/netWorth/nw1/assetContainer/
-<!-- @base is here only so it's easier to paste into validators for checking -->
-# @base <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>).
+ </section><!-- ldpc-get_empty-container_props -->
-<#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>.
+</section>
-<a1>
- a o:Stock;
- o:value 100.00 .
-<a2>
- a o:Cash;
- o:value 50.00 .
-<a3>
- a o:RealEstateHolding;
- o:value 300000 .</pre>
- <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 id="ldpc-container">
+<h2>Container</h2>
+<p>The following section contains normative clauses for <a title="">Linked Data Platform Container</a>.</p>
<section id="ldpc-general">
<h2>General</h2>
<p>The Linked Data Platform does not define how clients
discover <dfn><abbr title="Linked Data Platform Containers">LDPCs</abbr></dfn>.</p>
- <div id="ldpc-5_2_1" class="rule">5.2.1
- Each Linked Data Platform Container MUST also be a conforming Linked Data Platform Resource.
- </div>
- <!-- Action-108 removed this 2013-10-22
- <div id="ldpc-5_2_2" class="rule">5.2.2 LDPC membership is not exclusive; this means that the same resource
- (LDPR or not) MAY be a member of more than one LDPC.
- </div>
- -->
- <div id="ldpc-5_2_3" class="rule">5.2.3 <a title="LDP server">LDP servers</a>
- SHOULD use the <code>rdfs:member</code> predicate
- If there is no obvious predicate from an application vocabulary to use.
- The state of an LDPC includes information about which
- resources are its members, in the form of <a title="Membership triples">membership triples</a> that
- follow a consistent pattern. The LDPC's state contains enough information for clients to discern
- the <a title="Membership predicate">membership predicate</a>, the other consistent membership
- value used in the container's membership triples, and the position (subject or object) where the member's URI
- occurs in those triples.
- Member resources can be
- any kind of resource identified by a URI, LDPR or otherwise.
- </div>
- <div id="ldpc-5_2_4" class="rule">5.2.4 An LDPC representation MUST contain exactly one triple
- whose subject is the LDPC URI,
- whose predicate is the <code>ldp:membershipSubject</code>,
- and whose object is the LDPC's membership subject URI.
- </div>
-<div class="ldp-issue-open">
-<div class="ldp-issue-title">Issue-81: confusing predicate names</div>
-"membership subject" has been removed too. Remove this use of it as part of Issue-81 resolution.
-</div>
- <div id="ldpc-5_2_5" class="rule">5.2.5 An LDPC representation MUST contain exactly one triple
- whose subject is the LDPC URI,
- and whose predicate is either <code>ldp:membershipPredicate</code> or <code>ldp:membershipPredicateInverse</code>.
- The object of the triple is constrained by other sections, such as
- <a href="#ldpc-5_2_5_1">5.2.5.1</a> or <a href="#ldpc-5_2_5_2">5.2.5.2</a>.
- </div>
- <div id="ldpc-5_2_5_1" class="rule">5.2.5.1 For a given triple <var>T</var> with a subject <var>C</var>
- of the LDPC and predicate of
- <code>ldp:membershipPredicate</code>, the object MUST be the URI of the membership predicate <var>P</var> used to
- indicate membership to the linked to LDPC, 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 LDPC and predicate of
- <code>ldp:membershipPredicateInverse</code>, the object MUST be the URI of the membership predicate <var>P</var> used to
- indicate membership to the linked to LDPC, 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>
- <!-- Action-108 removed this 2013-10-22
- <div id="ldpc-5_2_6" class="rule">5.2.6 The representation of a LDPC MAY include an arbitrary number of
- additional triples whose subjects are the members of the container,
- or that are from the representations of the members (if they have RDF
- representations). This allows a LDPC server to provide clients with
- information about the members without the client having to do a <code>GET</code>
- on each member individually. See <a href="#ldpc-member_data">section 5.1.1 Container
- Member Information</a> for additional details.
- </div>
- -->
- <div id="ldpc-5_2_7" class="rule">5.2.7 The representation of a LDPC MUST have an <code>rdf:type</code>
- of <code>ldp:Container</code>. Informative note: <a href="#ldp-rdfconcepts-extra-triples-types">LDPCs
- might have additional types</a>, like any RDF resource.
- </div>
- <div id="ldpc-5_2_8" class="rule">5.2.8 LDPC representations SHOULD NOT use RDF container types <code>rdf:Bag</code>,
+ <section id="ldpc-isldpr"><h2 class="normal">Each <a title="">Linked Data Platform Container</a> MUST also be
+ a conforming <a title="">Linked Data Platform RDF Source</a>. <a title="">LDP client</a>s MAY infer the following triple:
+ whose subject is <code>ldp:Container</code>,
+ whose predicate is <code>rdfs:subClassOf</code>,
+ and whose object is <code>ldp:RDFSource</code>,
+ but there is no requirement to materialize this triple in the LDPC representation.
+ </h2></section><!-- Was 5.2.1 / #ldpc-5_2_1 -->
+
+ <section id="ldpc-typecontainer"><h2 class="normal">The representation of an LDPC MAY have an <code>rdf:type</code>
+ of only one of <code>ldp:Container</code> for <a title="">Linked Data Platform Container</a>.
+ Non-normative note: <a href="#ldp-rdfconcepts-extra-triples-types">LDPCs
+ might have additional types</a>, like any <a title="Linked Data Platform RDF Source">LDP-RS</a>.
+ </h2></section><!-- Was 5.2.7 / #ldpc-5_2_7 -->
+
+ <section id="ldpc-nordfcontainertypes"><h2 class="normal">LDPC representations SHOULD NOT use RDF container types <code>rdf:Bag</code>,
<code>rdf:Seq</code> or <code>rdf:List</code>.
- </div>
- <!-- Action-108 removed this 2013-10-22
- <div id="ldpc-5_2_9" class="rule">5.2.9 <a title="LDP server">LDP servers</a> SHOULD NOT re-use URIs,
- regardless of the mechanism by which members are created (<code>POST</code>, <code>PUT</code>, etc.).
- Certain specific cases exist where a LDPC server MAY delete a resource and then later re-use the
- URI when it identifies the same resource, but only when consistent with Web architecture [[WEBARCH]].
- 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 LDPCs have members whose URIs are not directly
- URIs minted upon LDPC member creation, for example URIs with a non-empty fragment identifier [[RFC3986]].
- To determine which member URI to use in the membership triple, LDPCs MUST contain one triple whose
- subject is the LDPC URI, whose predicate is <code>ldp:membershipObject</code>, and whose object is <var>MO</var>.
- <var>MO</var> and the HTTP URI <var>R</var> from <code>POST</code> create
- (as found in HTTP response <code>Location</code> header) are
- used to locate a triple in <var>R</var> of the form <var>(R, MO, N)</var>.
- When the LDPC uses <code>ldp:membershipPredicate</code>,
- <var>N</var> is then used to construct the membership triple of the form:
- <var>(membership consistent value, membership predicate, N)</var>.
- When the LDPC uses <code>ldp:membershipPredicateInverse</code>,
- the membership triple is
- of the form: <var>(N, membership predicate, membership consistent value)</var>.
- To indicate that the member resource URI is the membership object
- (the default or typical case), the object MUST be set to predefined URI <code>ldp:MemberSubject</code>
- such that it forms the triple:
- <var>(LDPC URI, <code>ldp:membershipObject</code>, <code>ldp:MemberSubject</code>)</var>.
- </div>
+ </h2></section><!-- Was 5.2.8 / #ldpc-5_2_8 -->
- <!-- 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
+ <section id="ldpc-linktypehdr"><h2 class="normal"><a title="LDP server">LDP servers</a>
+ exposing LDPCs
+ MUST advertise their LDP support by exposing a HTTP <code>Link</code> header
+ with a target URI matching the type of container (see below) the
+ server supports, and
+ a link relation type of <code>type</code> (that is, <code>rel='type'</code>)
+ in all responses to requests made
+ to the LDPC's HTTP <code>Request-URI</code>.
+ <a title="LDP server">LDP servers</a> MAY provide additional HTTP <code>Link: rel='type'</code> headers.
+ The <a href="#ldpr-gen-linktypehdr">notes on the corresponding LDPR constraint</a> apply
+ equally to LDPCs.
+ </h2>
+ <p>Valid container type URIs for <code>rel='type'</code> defined by this document are:
+ <ul>
+ <li><code>http://www.w3.org/ns/ldp#BasicContainer</code> - for <a href="#ldpbc">LDP Basic Containers</a></li>
+ <li><code>http://www.w3.org/ns/ldp#DirectContainer</code> - for <a href="#ldpdc">LDP Direct Containers</a></li>
+ <li><code>http://www.w3.org/ns/ldp#IndirectContainer</code> - for <a href="#ldpic">LDP Indirect Containers</a></li>
+ </ul>
+ </p>
+ </section><!-- Was 5.2.11 / #ldpc-5_2_11 -->
- </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 id="ldpc-prefer"><h2 class="normal"><a title="LDP server">LDP servers</a>
+ SHOULD respect all of a client's LDP-defined hints, for example
+ <a href="#prefer-parameters">which subsets of LDP-defined state</a>
+ the client is interested in processing,
+ to influence the set of triples returned in representations of an LDPC,
+ particularly for large LDPCs. See also [[LDP-PAGING]].
+ </h2></section>
</section>
<section id="ldpc-HTTP_GET">
<h2>HTTP GET</h2>
-
- <div id="ldpc-5_3_1" class="rule">5.3.1 The representation of a LDPC MUST contain a set of
- <a href="Membership triples">membership triples</a> following one of the consistent
- patterns from that definition.
- The membership-constant-URI of the triples MAY be the container itself
- or MAY be another resource (as in the <a href="#ldpc-ex-membership-subj">example</a>). See also
- <a href="#ldpc-5_2_3">5.2.3</a>.
- </div>
- <div id="ldpc-5_3_2" class="rule">5.3.2 <a title="LDP server">LDP servers</a> MAY
- represent the members of a paged LDPC in a sequential
- order. If the server does so, it MUST be specify the order using a triple
- whose subject is the page URI,
- 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 MUST be as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause
- [[!SPARQL-QUERY]].
- Sorting criteria MUST 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 LDPC page representations
- ordered using <code>ldp:containerSortCriteria</code> MUST 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>page-ordering values</dfn>).
- The only predicate data types whose behavior LDP constrains are those defined
- by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause [[!SPARQL-QUERY]]. 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 LDPC page representations
- ordered using <code>ldp:containerSortCriteria</code> MUST 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 LDPC page representations
- ordered using <code>ldp:containerSortCriteria</code> MAY 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">page-ordering values</a> are strings or simple literals [[!SPARQL-QUERY]], the
- resulting order is as defined by SPARQL SELECT’s ORDER BY clause
- [[!SPARQL-QUERY]] 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">page-ordering values</a> are strings or simple literals
- [[!SPARQL-QUERY]], the
- resulting order is as defined by SPARQL SELECT’s ORDER BY clause
- [[!SPARQL-QUERY]] using three-argument <code>fn:compare</code>, that is, the
- specified collation.
- The <code>ldp:containerSortCollation</code> triple MUST be omitted for comparisons
- involving <a title="page-ordering values">page-ordering values</a> for which [[!SPARQL-QUERY]] does not use collations.
- </div>
+ <p>
+ Per <a href="#ldpr-HTTP_GET" class="sectionRef"></a> the HTTP GET method is required and
+ additional requirements can be found in <a href="#ldpc-general" class="sectionRef"></a>.
+ </p>
+
</section>
<section id="ldpc-HTTP_POST">
<h2>HTTP POST</h2>
- <p>This specification imposes the following new requirements on HTTP <code>POST</code> for LDPCs
- only when an LDPC supports that method. This specification does not impose any
- new requirement to support that method, and [[!HTTP11]] makes it optional.
- Any server-imposed constraints on creation or update
- <a href="#ldpr-4_2_13">must be advertised</a> to clients.
+ <p>
+ Per [[HTTP11]], this HTTP method is optional and
+ this specification does not require <a title="LDP server">LDP servers</a> to support it.
+ When an LDP server supports this method,
+ this specification imposes the following new requirements for LDPCs.
</p>
- <div id="ldpc-5_4_1" class="rule">5.4.1 LDPC clients SHOULD create member resources by submitting a representation as
+ <p>
+ Any server-imposed constraints on creation or update
+ <a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
+ </p>
+
+ <section id="ldpc-post-created201"><h2 class="normal">LDPC clients SHOULD create member resources by submitting a representation as
the entity body of the HTTP <code>POST</code> to a known LDPC. If the resource was created successfully, <a title="LDP server">LDP servers</a> MUST
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>
+ </h2></section><!-- Was 5.4.1 / #ldpc-5_4_1 -->
- <div id="ldpc-5_4_2" class="rule">5.4.2 After a successful HTTP <code>POST</code> request to a LDPC, the new resource MUST
- appear as a member of the LDPC until the new resource is deleted or
- removed by other methods. An LDPC MAY also contain resources that were
- added through other means - for example through the user interface of
- the site that implements the LDPC.
- </div>
+ <section id="ldpc-post-createdmbr-contains"><h2 class="normal">
+ When a successful HTTP <code>POST</code> request to an LDPC results in the creation of an LDPR, a
+ <a title="Containment triples">containment triple</a> MUST be added to the state of LDPC. The
+ <a title="Containment triples">containment triple</a> whose subject is the LDPC URI,
+ whose predicate is <code>ldp:contains</code> and whose object is the URI for the newly created document (LDPR).
+ The newly created LDPR appears as a contained resource of the LDPC until the
+ newly created document is deleted or removed by other methods. Other triples may be added as well.
+ </h2></section>
- <div id="ldpc-5_4_3" class="rule">5.4.3 <a title="LDP server">LDP servers</a> MAY accept an HTTP <code>POST</code> of non-RDF representations for
- creation of any kind of resource, for example binary resources. See <a href="#ldpc-5_4_13">5.4.13</a> for
- details on how clients can discover whether a LDPC supports this behavior.
- </div>
- <div id="ldpc-5_4_4" class="rule">5.4.4 For servers that support create, <a title="LDP server">LDP servers</a> MUST create an LDPR from a
- RDF representation in the request entity body. The newly created LDPR could also be a LDPC, therefore servers MAY
- allow the creation of LDPCs within a LDPC.
- </div>
+ <section id="ldpc-post-createbins"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY accept an HTTP <code>POST</code> of non-RDF representations
+ <a title="Linked Data Platform Non-RDF Source">(LDP-NRs)</a> for
+ creation of any kind of resource, for example binary resources. See <a href="#ldpc-post-acceptposthdr">the Accept-Post section</a> for
+ details on how clients can discover whether an LDPC supports this behavior.
+ </h2></section><!-- Was 5.4.3 / #ldpc-5_4_3 -->
- <div id="ldpc-5_4_5" class="rule">5.4.5 <a title="LDP server">LDP servers</a> MUST accept a request entity body with a request header
- of <code>Content-Type</code> with value of <code>text/turtle</code> [[!TURTLE]].
- </div>
- <div id="ldpc-5_4_6" class="rule">5.4.6 <a title="LDP server">LDP servers</a> SHOULD use the <code>Content-Type</code> request header
- to determine the representation format when the request has an entity body.
- <!-- Action-108 removed this 2013-10-22
- When the header is absent,
- <a title="LDP server">LDP servers</a> MAY infer the content type by inspecting the entity body contents [[!HTTP11]].
- -->
- </div>
- <div id="ldpc-5_4_7" class="rule">5.4.7 In RDF representations, <a title="LDP server">LDP servers</a> MUST interpret the null relative
+ <section id="ldpc-post-createrdf"><h2 class="normal"><a title="LDP server">LDP servers</a> that successfully create a resource from a
+ RDF representation in the request entity body MUST honor the client's requested interaction model(s). The created resource
+ can be thought of as an RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[!rdf11-concepts]].
+ If any model cannot be honored, the server MUST fail the request.
+ </h2><!-- Was 5.4.4 / #ldpc-5_4_4 -->
+ <ul>
+ <li>If the request header <a href="#ldpr-gen-linktypehdr">specifies an LDPR interaction model</a>, then the server MUST handle subsequent
+ requests to the newly created resource's URI as if it is an LDPR.
+ (even if the content contains an <code>rdf:type</code> triple indicating a type of LDPC).</li>
+ <li>If the request header <a href="#ldpc-linktypehdr">specifies an LDPC interaction model</a>, then the server MUST handle subsequent
+ requests to the newly created resource's URI as if it is an LDPC.
+ </li>
+ <li>This specification does not constrain the server's behavior in other cases.</li>
+ </ul>
+ <p>Note: A consequence of this is that LDPCs can be used to create LDPCs, if the server supports doing so.</p>
+ </section>
+
+ <section id="ldpc-post-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST accept a request entity body with a request header
+ of <code>Content-Type</code> with value of <code>text/turtle</code> [[!turtle]].
+ </h2></section><!-- Was 5.4.5 / #ldpc-5_4_5 -->
+
+ <section id="ldpc-post-contenttype"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD use the <code>Content-Type</code> request header
+ to determine the representation format when the request has an entity body.
+ </h2></section><!-- Was 5.4.6 / #ldpc-5_4_6 -->
+
+ <section id="ldpc-post-rdfnullrel"><h2 class="normal">In RDF representations, <a title="LDP server">LDP servers</a> MUST interpret the null relative
URI for the subject of triples in the LDPR 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” LDPR, 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 <a title="LDP server">LDP servers</a> SHOULD assign the 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 <a title="LDP server">LDP servers</a> SHOULD allow clients to create new resources without
+ resource.
+ </h2></section><!-- Was 5.4.7 / #ldpc-5_4_7 -->
+
+ <section id="ldpc-post-serverassignuri"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD assign the URI for the resource to be
+ created using server application specific rules in the absence of a <a href="#ldpc-post-slug">client hint</a>.
+ </h2></section><!-- Was 5.4.8 / #ldpc-5_4_8 -->
+
+ <section id="ldpc-post-mincontraints"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to create new resources without
requiring detailed knowledge of application-specific constraints.
- This is a consequence of the requirement to
- <a href="#ldpr-4_2_9">enable simple creation and modification</a> of LPDRs.
- </div>
- <div id="ldpc-5_4_10" class="rule">5.4.10 <a title="LDP server">LDP servers</a> MAY allow clients to suggest the URI for a resource
+ This is a consequence of the requirement to enable simple creation and modification of LDPRs. LDP servers
+ expose these application-specific constraints as described in <a href="#ldpr-general" class="sectionRef"></a>.
+ </h2></section><!-- Was 5.4.9 / #ldpc-5_4_9 -->
+
+ <section id="ldpc-post-slug"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY allow clients to suggest the URI for a resource
created through <code>POST</code>, using the HTTP <code>Slug</code> header as defined in [[!RFC5023]]. 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 <a title="LDP server">LDP servers</a> that allow member creation via <code>POST</code>
- SHOULD NOT re-use URIs, per the<a href="#ldpc-5_2_9">
- general requirements on LDPCs</a>.
- </div>
+ </h2></section><!-- Was 5.4.10 / #ldpc-5_4_10 -->
- <div id="ldpc-5_4_12" class="rule">5.4.12 Upon successful creation of a non-RDF and therefore non-LDPR member (HTTP status code of
- 201-Created and URI indicated by <code>Location</code> response header), <a title="LDP server">LDP servers</a> MAY create an associated LDPR
- to contain data about the created resource. If an LDPC server creates this associated LDPR it MUST indicate
- its location on the HTTP response using the HTTP response header <code>Link</code> and relationship type <code>meta</code>
- and <code>href</code> to be the URI of the meta-resource [[!RFC5988]].
- </div>
- <div id="ldpc-5_4_13" class="rule">5.4.13 <a title="LDP server">LDP servers</a> that support <code>POST</code> MUST
+ <section id="ldpc-post-dontreuseuris"><h2 class="normal"><a title="LDP server">LDP servers</a> that allow member creation via <code>POST</code>
+ SHOULD NOT re-use URIs.
+ </h2></section><!-- Was 5.4.11 / #ldpc-5_4_11 -->
+
+ <section id="ldpc-post-createbinlinkmetahdr"><h2 class="normal">Upon successful creation of an
+ <a title="Linked Data Platform Non-RDF Source">LDP-NR</a> (HTTP status code of
+ 201-Created and URI indicated by <code>Location</code> response header), <a title="LDP server">LDP servers</a> MAY create an associated
+ <a title="Linked Data Platform RDF Source">LDP-RS</a>
+ to contain data about the newly created LDP-NR. If an LDPC server creates this associated <a title="Linked Data Platform RDF Source">LDP-RS</a> it MUST indicate
+ its location on the HTTP response using the HTTP <code>Link</code> response header with link relation <code>describedby</code>
+ and <code>href</code> to be the URI of the associated LDP-RS resource [[!RFC5988]].
+ </h2></section><!-- Was 5.4.12 / #ldpc-5_4_12 -->
+
+ <section id="ldpc-post-acceptposthdr"><h2 class="normal"><a title="LDP server">LDP servers</a> that support <code>POST</code> MUST
include an <a href="#header-accept-post"><code>Accept-Post</code> response header</a> on HTTP <code>OPTIONS</code>
responses, listing post document media type(s) supported by the server.
LDP only specifies the use of <code>POST</code> for the purpose of creating new resources, but a server
@@ -1679,90 +1372,67 @@
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 LDPCs that create new member resources MAY 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 LDPC that tracks members created through the LDPC MUST 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 MAY add other triples as well.
- </div>
+ </h2></section><!-- Was 5.4.13 / #ldpc-5_4_13 -->
</section>
<section id="ldpc-HTTP_PUT">
<h2>HTTP PUT</h2>
- <p>This specification imposes the following new requirements on HTTP <code>PUT</code> for LDPCs
- only when an LDPC supports that method. This specification does not impose any
- new requirement to support that method, and [[!HTTP11]] makes it optional.
- Any server-imposed constraints on creation or update
- <a href="#ldpr-4_2_13">must be advertised</a> to clients.
+ <p>
+ Per [[HTTP11]], this HTTP method is optional and
+ this specification does not require <a title="LDP server">LDP servers</a> to support it.
+ When an LDP server supports this method,
+ this specification imposes the following new requirements for LDPCs.
</p>
- <div id="ldpc-5_5_1" class="rule">5.5.1 <a title="LDP server">LDP servers</a> SHOULD NOT allow HTTP <code>PUT</code> to update a LDPC’s <a>membership triples</a>;
+ <p>
+ Any server-imposed constraints on creation or update
+ <a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
+ </p>
+
+ <section id="ldpc-put-mbrprops"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD NOT allow HTTP <code>PUT</code> to update an LDPC’s <a>containment triples</a>;
if the server receives such a request, it SHOULD respond with a 409
(Conflict) status code.
- </div>
- <div id="ldpc-5_5_2" class="rule">5.5.2 <a title="LDP server">LDP servers</a> MAY allow updating LDPC non-membership properties using
- HTTP <code>PUT</code> on a corresponding <a>non-member resource</a>, which
- MAY exclude server-managed properties such as <code>ldp:membershipSubject</code>, <code>ldp:membershipPredicate</code>
- and <code>ldp:membershipPredicateInverse</code>.
- The <a href="#ldpc-HTTP_OPTIONS" class="sectionRef"></a> describes the process by which clients
- use HTTP <code>OPTIONS</code> to discover whether the server offers such a resource, and if so its URL.
- </div>
-
- <div id="ldpc-5_5_3" class="rule">5.5.3 <a title="LDP server">LDP servers</a> SHOULD NOT allow HTTP <code>PUT</code> requests
- with member resource information in the request representation.
- See section <a href="#ldpc-member_data">5.1.1 Container
- Member Information</a> for additional details.
- </div>
+ </h2></section><!-- Was 5.5.1 / #ldpc-5_5_1 -->
- <div id="ldpc-5_5_4" class="rule">5.5.4 <a title="LDP server">LDP servers</a> that allow member creation via <code>PUT</code>
- SHOULD NOT re-use URIs, per the <a href="#ldpc-5_2_9">
- general requirements on LDPCs</a>.
- </div>
+ <section id="ldpc-put-create"><h2 class="normal"><a title="LDP server">LDP servers</a> that allow LDPR creation via <code>PUT</code>
+ SHOULD NOT re-use URIs. For RDF representations (LDP-RSs),the created resource
+ can be thought of as an RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[!rdf11-concepts]].
+ </h2></section><!-- Was 5.5.4 / #ldpc-5_5_4 -->
</section>
<section id="ldpc-HTTP_DELETE">
<h2>HTTP DELETE</h2>
- <p>This specification imposes the following new requirements on HTTP <code>DELETE</code> for LDPRs and LDPCs
- only when a LDPC supports that method. This specification does not impose any
- new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
+ <p>
+ Per [[HTTP11]], this HTTP method is optional and
+ this specification does not require <a title="LDP server">LDP servers</a> to support it.
+ When an LDP server supports this method,
+ this specification imposes the following new requirements for LDPCs.
+ </p>
- <div id="ldpc-5_6_1" class="rule">5.6.1 When a LDPC member resource originally created by the LDPC (for example, one whose representation
- was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server is aware of the member's deletion
- (for example, the member is managed by the same server), the LDPC server MUST also remove it from
- the LDPC by removing the corresponding membership triple.
- </div>
- <div id="ldpc-5_6_2" class="rule">5.6.2 When a <a>LDP server</a> successfully completes a <code>DELETE</code> request
- on a LDPC member resource, it MUST remove any
- membership triples associated with the deleted member resource identified by the <code>Request-URI</code>.
- </div>
+ <section id="ldpc-del-contremovesconttriple"><h2 class="normal">
+ When an LDPR identified by the object of a <a title="containment triples">containment triple</a> is deleted, the LDPC server MUST also remove
+ the LDPR from the containing LDPC by removing the corresponding containment triple.
+ </h2>
<blockquote>
- Informative note: The <a>LDP server</a> might perform additional removal
- of member resources, as described in the <a href="#ldp-http-method-side-effects">normative references</a> like [[HTTP11]].
+ Non-normative note: The <a>LDP server</a> might perform additional actions,
+ as described in the <a href="#ldp-http-method-side-effects">normative references</a> like [[HTTP11]].
For example, the server could perform additional cleanup tasks for resources it knows are no longer referenced or have not
been accessed for some period of time.
</blockquote>
- <div id="ldpc-5_6_3" class="rule">5.6.3 When the conditions in <a href="#ldpc-5_6_1">5.6.1</a> hold, and the LDPC tracks member
- resources that it created using the <code>ldp:created</code> predicate, the LDPC server MUST also remove
- the deleted member's <code>ldp:created</code> triple.
- </div>
+ </section><!-- Was 5.6.1 / #ldpc-5_6_1 -->
- <div id="ldpc-5_6_4" class="rule">5.6.4 When a LDPC member resource originally created by the LDPC (for example, one whose
- representation was HTTP <code>POST</code>dd to the LDPC and then referenced by a membership triple) is deleted, and the LDPC server
- created an associated LDPR (see <a href="#ldpc-5_4_12">5.4.12</a>), the LDPC server MUST also remove the associated LDPR it created.
- </div>
+ <section id="ldpc-del-contremovescontres"><h2 class="normal">
+ When an LDPR identified by the object of a <a title="containment triples">containment triple</a> is deleted, and the LDPC server
+ created an associated LDP-RS (see the <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>), the LDPC server MUST also remove the associated LDP-RS it created.
+ </h2></section><!-- Was 5.6.4 / #ldpc-5_6_4 -->
</section>
<section id="ldpc-HTTP_HEAD">
<h2>HTTP HEAD</h2>
- <p>Note that certain LDP mechanisms, such as <a href="#ldpr-Paging">paging</a>,
+ <p>Note that certain LDP mechanisms
rely on HTTP headers, and HTTP generally requires that
<code>HEAD</code> responses include the same headers as <code>GET</code> responses. Also <a title="LDP server">LDP servers</a> must also include HTTP headers
on response to <code>OPTIONS</code>, see <a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
@@ -1772,16 +1442,23 @@
<section id="ldpc-HTTP_PATCH">
<h2>HTTP PATCH</h2>
- <p>This specification imposes the following new requirements on HTTP <code>PATCH</code> for LDPCs
- only when a LDPC supports that method. This specification does not impose any
- new requirement to support that method, and [[!HTTP11]] makes it optional.
- Any server-imposed constraints on LDPR creation or update
- <a href="#ldpr-4_2_13">must be advertised</a> to clients.
+ <p>
+ Per [[HTTP11]], this HTTP method is optional and
+ this specification does not require <a title="LDP server">LDP servers</a> to support it.
+ When an LDP server supports this method,
+ this specification imposes the following new requirements for LDPCs.
</p>
- <div id="ldpc-5_8_1" class="rule">5.8.1 <a title="LDP server">LDP servers</a> are RECOMMENDED to support HTTP <code>PATCH</code> as the preferred
- method for updating LDPC non-membership properties.
- </div>
+ <p>
+ Any server-imposed constraints on LDPR creation or update
+ <a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
+ </p>
+
+ <section id="ldpc-patch-req"><h2 class="normal">
+ <a title="LDP server">LDP servers</a> are RECOMMENDED
+ to support HTTP <code>PATCH</code> as the preferred method for
+ updating an LDPC's <a title="Empty-container triples">empty-container triples</a>.
+ </h2></section><!-- Was 5.8.1 / #ldpc-5_8_1 -->
</section>
<section id="ldpc-HTTP_OPTIONS">
@@ -1789,35 +1466,310 @@
<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for LDPCs.
</p>
- <div id="ldpc-5_9_1" class="rule">5.9.1
- <a title="LDP server">LDP servers</a> SHOULD define a corresponding
- <a>non-member resource</a>
- to support requests for information about a LDPC
- 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 LDPC as the <code>Request-URI</code>,
- <a title="LDP server">LDP servers</a> that define a non-member resource SHOULD provide an HTTP <code>Link</code>
- header whose target URI is the <a>non-member resource</a>, and whose link relation type is
- <code>http://www.w3.org/ns/ldp#nonMemberResource</code> [[!RFC5988]].
- 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 LDPC does not have a corresponding
- non-member resource.
- For example, if there is a LDPC 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>
+ <section id="ldpc-options-linkmetahdr"><h2 class="normal">When an LDPC server creates an
+ <a title="Linked Data Platform Non-RDF Source">LDP-NR</a> (for example, one whose
+ representation was HTTP <code>POST</code>ed to the LDPC)
+ the LDP server might create an associated <a title="Linked Data Platform RDF Source">LDP-RS</a>
+ to contain data about the non-LDPR (see <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>).
+ For LDP-NRs that have this associated LDP-RS, an LDPC server MUST provide an HTTP <code>Link</code>
+ header whose target URI is the associated LDP-RS, and whose link relation type is
+ <code>describedby</code> [[!RFC5988]].
+ </h2></section><!-- Was 5.9.2 / #ldpc-5_9_2 -->
+</section> <!-- h2 -->
+</section> <!-- ldpc-container -->
+
+<section id="ldpbc">
+<h2>Basic</h2>
+
+<p>The following section contains normative clauses for <a title="">Linked Data Platform Basic Container</a>.</p>
+
+
+<section id="ldpbc-general">
+<h2>General</h2>
+
+<section id="ldpbc-are-ldpcs"><h2 class="normal">Each <a title="Linked Data Platform Basic Container">LDP Basic Container</a> MUST also be
+ a conforming <a title="Linked Data Platform Container">LDP Container</a> in <a href="#ldpc-container" class="sectionRef"></a> along the
+ following restrictions in this section. <a title="">LDP client</a>s MAY infer the following triple:
+ whose subject is <code>ldp:BasicContainer</code>,
+ whose predicate is <code>rdfs:subClassOf</code>,
+ and whose object is <code>ldp:Container</code>,
+ but there is no requirement to materialize this triple in the LDP-BC representation.
+</h2></section>
+
+</section> <!-- ldpbc General -->
+
+</section> <!-- ldpbc Basic -->
+
+
+<section id="ldpdc">
+<h2>Direct</h2>
+
+<p>The following section contains normative clauses for <a title="">Linked Data Platform Direct Container</a>.</p>
- <div id="ldpc-5_9_2" class="rule">5.9.2 When a LDPC creates a non-LDPR (e.g. binary) member (for example, one whose
- representation was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) it might create an associated LDPR to contain data about the
- non-LDPR (see <a href="#ldpc-5_4_12">5.4.12</a>). For non-LDPRs that have this associated LDPR, an LDPC server MUST provide an HTTP <code>Link</code>
- header whose target URI is the associated LDPR, and whose link relation type is
- <code>meta</code> [[!RFC5988]].</div>
-</section> <!-- h2 -->
+<section id="ldpdc-general">
+<h2>General</h2>
-</section> <!-- h1 -->
+<section id="ldpdc-are-ldpcs"><h2 class="normal">Each <a title="Linked Data Platform Direct Container">LDP Direct Container</a> MUST also be
+ a conforming <a title="Linked Data Platform Container">LDP Container</a> in <a href="#ldpc-container" class="sectionRef"></a> along the following
+ restrictions. <a title="">LDP client</a>s MAY infer the following triple:
+ whose subject is <code>ldp:BasicContainer</code>,
+ whose predicate is <code>rdfs:subClassOf</code>,
+ and whose object is <code>ldp:Container</code>,
+ but there is no requirement to materialize this triple in the LDP-DC representation.
+</h2></section>
+
+<section id="ldpdc-mbrpred"><h2 class="normal">
+ <a title="Linked Data Platform Direct Container">LDP Direct Containers</a>
+ SHOULD use the <code>ldp:member</code> predicate as an LDPC's <a title="Membership predicate">membership predicate</a>
+ if there is no obvious predicate from an application vocabulary to use..
+ The state of an LDPC includes information about which
+ resources are its members, in the form of <a title="Membership triples">membership triples</a> that
+ follow a consistent pattern. The LDPC's state contains enough information for clients to discern
+ the <a title="Membership predicate">membership predicate</a>, the other consistent membership
+ value used in the container's membership triples (<var>membership-constant-URI</var>),
+ and the position (subject or object) where those URIs
+ occurs in the <a title="Membership triples">membership triples</a>.
+ Member resources can be
+ any kind of resource identified by a URI, LDPR or otherwise.
+</h2></section><!-- Was 5.2.3 / #ldpc-5_2_3 -->
+
+<section id="ldpdc-containres"><h2 class="normal">Each <a title="Linked Data Platform Direct Container">LDP Direct Container</a>
+ representation MUST contain exactly one triple
+ whose subject is the LDPC URI,
+ whose predicate is the <code>ldp:membershipResource</code>,
+ and whose object is the LDPC's <var>membership-constant-URI</var>.
+ Commonly the LDPC's URI is the <var>membership-constant-URI</var>, but LDP does not require this.
+</h2>
+</section><!-- Was 5.2.4 / #ldpc-5_2_4 -->
+
+<section id="ldpdc-containtriples"><h2 class="normal">Each <a title="Linked Data Platform Direct Container">LDP Direct Container</a>
+ representation MUST contain exactly one triple
+ whose subject is the LDPC URI,
+ and whose predicate is either <code>ldp:hasMemberRelation</code> or <code>ldp:isMemberOfRelation</code>.
+ The object of the triple is constrained by other sections, such as
+ <a href="#ldpdc-containtriple-relation" class="sectionRef">ldp:hasMemberRelation</a> or
+ <a href="#ldpdc-containtriple-byrelation" class="sectionRef">ldp:isMemberOfRelation</a>, based on the
+ <a title="Membership triples">membership triple</a>
+ pattern used by the container.
+</h2><!-- Was 5.2.5 / #ldpc-5_2_5 -->
+
+<section id="ldpdc-containtriple-relation"><h2 class="normal"><a title="Linked Data Platform Direct Container">LDP Direct Containers</a>
+ whose <a title="Membership triples">membership triple</a>
+ pattern is <var>( membership-constant-URI , membership-predicate , member-derived-URI )</var> MUST
+ contain exactly one triple
+ whose subject is the LDPC URI,
+ whose predicate is <code>ldp:hasMemberRelation</code>,
+ and whose object is the URI of <var>membership-predicate</var>.
+</h2>
+</section><!-- Was 5.2.5.1 / #ldpc-5_2_5_1 -->
+
+<section id="ldpdc-containtriple-byrelation"><h2 class="normal"><a title="Linked Data Platform Direct Container">LDP Direct Containers</a>
+ whose <a title="Membership triples">membership triple</a>
+ pattern is <var>( member-derived-URI , membership-predicate , membership-constant-URI )</var> MUST
+ contain exactly one triple
+ whose subject is the LDPC URI,
+ whose predicate is either <code>ldp:isMemberOfRelation</code>,
+ and whose object is the URI of <var>membership-predicate</var>.
+</h2></section><!-- Was 5.2.5.2 / #ldpc-5_2_5_2 -->
+</section>
+
+<section id="ldpdc-indirectmbr-basic"><h2 class="normal">
+ <a title="Linked Data Platform Direct Container">LDP Direct Containers</a>
+ MUST behave as if they
+ have a <var>( LDPC URI, <code>ldp:insertedContentRelation</code> , <code>ldp:MemberSubject</code> )</var>
+ triple, but LDP imposes no requirement to materialize such a triple in the LDP-DC representation.
+ The value <code>ldp:MemberSubject</code> means that the
+ <var>member-derived-URI</var> is the URI assigned by the server to a
+ document it creates; for example, if the client POSTs content to a container
+ that causes the container to create a new LDPR, <code>ldp:MemberSubject</code> says
+ that the <var>member-derived-URI</var> is the URI assigned to the newly created LDPR.
+</h2></section>
+
+</section> <!-- ldpdc-general -->
+
+<section id="ldpdc-HTTP_POST">
+<h2>HTTP POST</h2>
+ <section id="ldpdc-post-createdmbr-member"><h2 class="normal">
+ When a successful HTTP <code>POST</code> request to an LDPC results in the creation of an LDPR,
+ the LDPC MUST update its membership triples to reflect that addition, and the resulting
+ membership triple MUST be consistent with any LDP-defined predicates it exposes.
+ A <a title="Linked Data Platform Direct Container">LDP Direct Container</a>'s membership triples MAY also be modified via
+ through other means.
+ </h2></section><!-- Was 5.4.2 / #ldpc-5_4_2 -->
+</section> <!-- ldpdc-HTTP_POST -->
+
+<section id="ldpdc-HTTP_DELETE">
+<h2>HTTP DELETE</h2>
+
+ <section id="ldpdc-del-contremovesmbrtriple"><h2 class="normal">
+ When an LDPR identified by the object of a <a title="membership triples">membership triple</a> which was
+ originally created by the LDP-DC is deleted, the LDPC server MUST also remove
+ the corresponding membership triple..
+ </h2>
+ </section><!-- Was 5.6.1 / #ldpc-5_6_1 -->
+
+</section> <!-- ldpdc-HTTP_DELETE -->
+
+</section> <!-- ldpdc Direct -->
+
+<section id="ldpic">
+<h2>Indirect</h2>
+
+<p>The following section contains normative clauses for <a title="">Linked Data Platform Indirect Container</a>.</p>
+
+<section id="ldpic-general">
+<h2>General</h2>
+
+<section id="ldpic-are-ldpcs"><h2 class="normal">Each <a title="Linked Data Platform Indirect Container">LDP Indirect Container</a> MUST also be
+ a conforming <a title="Linked Data Platform Direct Container">LDP Direct Container</a> in <a href="#ldpdc" class="sectionRef"></a> along the following
+ restrictions. <a title="">LDP client</a>s MAY infer the following triple:
+ whose subject is <code>ldp:IndirectContainer</code>,
+ whose predicate is <code>rdfs:subClassOf</code>,
+ and whose object is <code>ldp:Container</code>,
+ but there is no requirement to materialize this triple in the LDP-IC representation.
+</h2></section>
+
+<section id="ldpic-indirectmbr"><h2 class="normal">
+ <a title="Linked Data Platform Indirect Container">LDP Indirect Containers</a>
+ MUST contain exactly one triple whose
+ subject is the LDPC URI,
+ whose predicate is <code>ldp:insertedContentRelation</code>, and
+ whose object <var>ICR</var> describes how the <var>member-derived-URI</var> in
+ the container's <a title="Membership triples">membership triples</a> is chosen.
+ The <var>member-derived-URI</var> is taken from some triple
+ <var>( S, P, O )</var> in the document supplied by the client as input to the create request;
+ if <var>ICR</var>'s value is <var>P</var>, then the <var>member-derived-URI</var> is
+ <var>O</var>. LDP does not define the behavior when more than one triple containing
+ the predicate <var>P</var> is present in the client's input.
+ For example, if the client POSTs RDF content to a container
+ that causes the container to create a new LDP-RS, and that content contains the triple
+ <var>( <> , foaf:primaryTopic , bob#me )</var>
+ <code>foaf:primaryTopic</code> says
+ that the <var>member-derived-URI</var> is <var>bob#me</var>.
+ </h2>
+</section><!-- Was 5.2.10 / #ldpc-5_2_10 -->
+</section> <!-- ldpic General -->
+
+<section id="ldpic-HTTP_POST">
+<h2>HTTP POST</h2>
+ <section id="ldpic-post-indirectmbrrel"><h2 class="normal">LDPCs
+ whose <code>ldp:insertedContentRelation</code> triple has an object
+ <strong>other than</strong> <code>ldp:MemberSubject</code>
+ and that create new resources
+ MUST add a triple to the container
+ whose subject is the container's URI,
+ whose predicate is <code>ldp:contains</code>, and
+ whose object is the newly created resource's URI (which will be different from
+ the <var><a href="#ldpic-indirectmbr">member-derived URI</a></var> in this case).
+ This <code>ldp:contains</code> triple can be the only link from the container to the newly created
+ resource in certain cases.
+ </h2></section><!-- Was 5.4.15 / #ldpc-5_4_15 -->
+</section> <!-- ldpic HTTP_POST -->
+
+</section> <!-- ldpic Indirect -->
+
+</section> <!-- h1 LDPC -->
+
+
+<section id="base-specs" class="informative">
+<h1>Notable information from normative references</h1>
+<p>
+While readers, and especially implementers, of LDP are assumed to understand the information in its normative
+references, the working group has found that certain points are particularly important to understand.
+For those thoroughly familiar with the referenced specifications, these points might seem obvious, yet
+experience has shown that few non-experts find all of them obvious. This section enumerates these topics;
+it is simply re-stating (non-normatively) information locatable via the normative references.
+</p>
+
+<section id="specs-webarch" class="informative">
+<h2>Architecture of the World Wide Web</h2>
+Reference: [[!WEBARCH]]
+
+ <section id="ldp-webarch-nonexcl-membership" ><h2 class="normal">LDPC membership is not exclusive; this means that the same resource
+ (LDPR or not) can be a member of more than one LDPC.
+ </h2></section>
+
+ <section id="ldp-webarch-uri-reuse"><h2 class="normal"><a title="LDP server">LDP servers</a> should not re-use URIs,
+ regardless of the mechanism by which members are created (<code>POST</code>, <code>PUT</code>, etc.).
+ Certain specific cases exist where an LDPC server might delete a resource and then later re-use the
+ URI when it identifies the same resource, but only when consistent with Web architecture.
+ 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.
+ </h2></section>
+
+</section>
+
+<section id="specs-http" class="informative">
+<h2>HTTP 1.1</h2>
+Reference: [[!HTTP11]]
+
+ <section id="ldp-http-other-representations"><h2 class="normal"><a title="LDP server">LDP servers</a> can support representations beyond those
+ necessary to conform to this specification. These
+ could be other RDF formats, like N3 or NTriples, but non-RDF formats
+ like HTML [[HTML401]] and JSON [[RFC4627]] would likely be common.
+ HTTP content negotiation ([[HTTP11]] Section 12 - Content Negotiation) is used to select the format.
+ </h2></section>
+
+ <section id="ldp-http-other-methods"><h2 class="normal">LDPRs can be created, updated and deleted using methods not defined in
+ this document, for example through application-specific means, SPARQL
+ UPDATE, etc. [[SPARQL-UPDATE]], as long as those methods do not conflict with this specification's
+ normative requirements.
+ </h2></section>
+
+ <section id="ldp-http-delete-uri-reuse"><h2 class="normal"><a title="LDP server">LDP servers</a>
+ remove the resource identified by the <code>Request-URI</code> in response to a successful HTTP <code>DELETE</code> request.
+ After such a request, a subsequent HTTP <code>GET</code> on the same
+ <code>Request-URI</code> usually results in a 404 (Not found) or 410 (Gone) status
+ code, although HTTP allows others.
+ </h2></section>
+
+ <section id="ldp-http-method-side-effects"><h2 class="normal"><a title="LDP server">LDP servers</a> can alter the state of other resources
+ as a result of any HTTP request, especially when non-safe methods are used ([[HTTP11]] section 9.1).
+ For example, it is acceptable for the server to
+ remove triples from other resources whose subject or object is the
+ deleted resource as the result of a successful HTTP <code>DELETE</code> request.
+ It is also acceptable and common for <a title="LDP server">LDP servers</a> to
+ not do this – the server's behavior can vary, so LDP clients cannot depend on it.
+ </h2></section>
+
+ <section id="ldp-http-patch-allowed"><h2 class="normal"><a title="LDP server">LDP servers</a> can implement HTTP <code>PATCH</code>
+ to allow modifications,
+ especially partial replacement, of their resources. No
+ minimal set of patch document formats is mandated by this document or by the definition of <code>PATCH</code> [[RFC5789]].
+ </h2></section>
+
+ <section id="ldp-http-content-sniffing"><h2 class="normal">
+ When the <code>Content-Type</code> request header is absent from a request,
+ <a title="LDP server">LDP servers</a> might infer the content type by inspecting the entity body contents [[HTTP11]].
+ </h2></section>
+
+</section>
+
+<section id="specs-rdf" class="informative">
+<h2>RDF</h2>
+Reference: [[rdf11-concepts]]
+
+ <section id="ldp-rdfconcepts-extra-triples-any"><h2 class="normal">The state of an LDPR
+ can have triples with any subject(s). The URL used to retrieve the
+ representation of an LDPR need not be the subject of any of its triples.
+ </h2></section>
+
+ <section id="ldp-rdfconcepts-extra-triples-members"><h2 class="normal">The representation of an LDPC
+ can include an arbitrary number of
+ additional triples whose subjects are the members of the container,
+ or that are from the representations of the members (if they have RDF
+ representations). This allows an <a>LDP server</a> to provide clients with
+ information about the members without the client having to do a <code>GET</code>
+ on each member individually.
+ </h2></section>
+
+ <section id="ldp-rdfconcepts-extra-triples-types"><h2 class="normal">The state of an LDPR can have more than one
+ triple with an <code>rdf:type</code> predicate.
+ </h2></section>
+
+</section>
+
+</section> <!-- Base specs -->
<section>
<h1>HTTP Header Definitions</h1>
@@ -1828,7 +1780,7 @@
<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
+ <li>The addition of <code>Accept-Post</code> in this specification is pending
advancement of an <a href="https://datatracker.ietf.org/doc/draft-wilde-accept-post/">IETF draft</a>
that would fully include it, based on the Accept-Patch header's design from [[!RFC5789]]. Once LDP is in
Candidate Recommendation, the LDP WG will make an assessment based on the status at IETF
@@ -1841,17 +1793,17 @@
It is modelled after the <code>Accept-Patch</code> header defined in [[!RFC5789]].
</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 [[!HTTP11]], is:
+ <section id="header-accept-post-1"><h2 class="normal">The syntax for <code>Accept-Post</code>, using
+ the ABNF syntax defined in Section 2.1 of [[!HTTP11]], is:</h2>
<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 [[!HTTP11]], Section 3.7.
</p>
</blockquote>
- </div>
+ </section><!-- Was 6.1.1 / #header-accept-post-1 -->
- <div id="header-accept-post-2" class="rule">6.1.2
+ <section id="header-accept-post-2"><h2 class="normal">
The <code>Accept-Post</code> HTTP header SHOULD 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
@@ -1859,9 +1811,9 @@
<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>
+ </h2></section><!-- Was 6.1.2 / #header-accept-post-2 -->
- <div id="header-accept-post-iana" class="rule">6.1.3 IANA Registration Template</div>
+ <section id="header-accept-post-iana"><h2 class="normal">IANA Registration Template</h2>
<div>
<blockquote>
<p>
@@ -1881,10 +1833,269 @@
</p>
</blockquote>
</div>
+ </section><!-- Was 6.1.3 / #header-accept-post-iana -->
</section>
+
+<section id="prefer-parameters">
+<h2>Preferences on the Prefer Request Header</h2>
+
+<section id="prefer-summary">
+<h3>Summary</h3>
+
+ <div class="ldp-issue-pending">
+ <div class="ldp-issue-title">Need to update normative reference once RFC number is assigned.</div>
+ The <a href="http://tools.ietf.org/html/draft-snell-http-prefer-18">HTTP Prefer header</a> is queued for an RFC number behind HTTPbis, whose BNF Prefer normatively refers to.
+ </div>
+
+ <p>This specification introduces new parameters on the HTTP <code>Prefer</code> request header's
+ <code>return=representation</code> preference [[!Prefer]], used optionally by clients to
+ supply a hint to help the server form a response that is most appropriate to
+ the client's needs. The LDP-defined parameters suggest the portion(s) of a resource's state that the
+ client application is interested in and, if received, is likely to be
+ processed. LDP Containers with large numbers of associated documents
+ and/or members will have large representations, and many client
+ applications may be interested in processing only a subset of the LDPC's
+ information (for example, only membership triples or only containment triples),
+ resulting in a potentially large savings in server, client,
+ and network processing.
+ </p>
+
+ <p>
+ Non-normative note: LDP server implementers should carefully consider the effects of these
+ preferences on caching, as described in section 2 of [[!Prefer]].
+ </p>
+
+ <p>
+ Non-normative note: [[!Prefer]] recommends that server implementers include a
+ <code>Preference-Applied</code> response header when the client cannot otherwise determine the server's
+ behavior with respect to honoring hints from the response content.
+ <a href="#prefer-examples">Examples</a> illustrates some cases where the header is unnecessary.
+ </p>
+
+</section> <!-- Prefer summary -->
+
+<section id="prefer-rules">
+<h3>Specification</h3>
+
+ <section id="prefer-include"><h2 class="normal">
+ The <code>include</code> hint defines a subset of an LDPR's content that a client
+ would like included in a representation.
+ The syntax for the <code>include</code> parameter of the
+ HTTP <code>Prefer</code> request header's
+ <code>return=representation</code> preference [[!Prefer]] is:</h2>
+ <blockquote>
+ <code>include-parameter = "include" *WSP "=" *WSP ldp-uri-list</code>
+ <p>
+ Where <code>WSP</code> is whitespace [[!RFC5234]], and
+ <code>ldp-uri-list</code> is a double-quoted blank-delimited unordered set of URIs whose ABNF is given below.
+ The generic preference BNF [[!Prefer]] allows either a quoted string or a token as the value of a
+ preference parameter; LDP assigns a meaning to the value only when it is a quoted string of
+ the form:
+ </p>
+ <code>ldp-uri-list = DQUOTE *WSP URI *[ 1*WSP URI ] *WSP DQUOTE</code>
+ <p>
+ where <code>DQUOTE</code> is a double quote [[!RFC5234]], and <code>URI</code> is an absolute URI with an optional
+ fragment component [[!RFC3986]].
+ </p>
+ </blockquote>
+ </section>
+
+ <section id="prefer-omit"><h2 class="normal">
+ The <code>omit</code> hint defines a subset of an LDPR's content that a client
+ would like omitted from a representation.
+ The syntax for the <code>omit</code> parameter of the
+ HTTP <code>Prefer</code> request header's
+ <code>return=representation</code> preference [[!Prefer]] is:</h2>
+ <blockquote>
+ <code>omit-parameter = "omit" *WSP "=" *WSP ldp-uri-list</code>
+ <p>
+ Where <code>WSP</code> and <code>ldp-uri-list</code> are defined as above for <a href="#prefer-include">include</a>.
+ </p>
+ </blockquote>
+ </section>
+
+ <section id="prefer-conflicts"><h2 class="normal">
+ When LDP servers receive a request with conflicting hints, this specification imposes
+ no requirements on their behavior. They are free to reject the request, process it
+ applying some subset of the hints, or anything else appropriate to the server.
+ [[!Prefer]] suggests treating similar requests as though none of the conflicting
+ preferences were specified.
+ </h2>
+ </section>
+
+ <section id="prefer-uris"><h2 class="normal">
+ This specification defines the following URIs for clients to use with <code>include</code>
+ and <code>omit</code> parameters. It assigns no meaning to other URIs, although
+ other specifications MAY do so.</h2>
+ <table class="indented">
+ <tr>
+ <td> <a title="Containment triples">Containment triples </a></td>
+ <td> <code>http://www.w3.org/ns/ldp#PreferContainment</code> </td>
+ </tr>
+ <tr>
+ <td> <a title="Membership triples">Membership triples </a></td>
+ <td> <code>http://www.w3.org/ns/ldp#PreferMembership</code> </td>
+ </tr>
+ <tr>
+ <td> <a title="Empty-container triples">Empty-container triples</a>
+ </td>
+ <td> <code>http://www.w3.org/ns/ldp#PreferEmptyContainer</code> </td>
+ </tr>
+ </table>
+ <blockquote>
+ <p>
+ Non-normative note: all currently defined URIs are only coherent for LDP-RSs,
+ and in fact only for LDPCs, however in
+ the future it is possible that additional URIs with other scopes of applicability
+ could be defined.
+ </p>
+ </blockquote>
+ </section>
+
+</section> <!-- Prefer specification -->
+<section id="prefer-examples" class="informative">
+<h3>Examples</h3>
+ <p>
+ If we assume a container like
+ the one below:
+ </p>
+ <pre class="example" id="prefer-examples-direct">
+ # The following is the representation of
+ # http://example.org/netWorth/nw1/assetContainer/
+ <!-- @base is here only so it's easier to paste into validators for checking -->
+ # @base <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:DirectContainer;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:membershipResource <http://example.org/netWorth/nw1>;
+ ldp:hasMemberRelation o:asset;
+ ldp:insertedContentRelation ldp:MemberSubject.
+
+ <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>
+
+ <p id="prefer-examples-direct-empty-container-only1">
+ Clients interested only in information about the container
+ (for example, which membership predicate it uses) might use this hint on a <code>GET</code> request:
+ <code>Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferEmptyContainer"</code>
+ </p>
+ <p>
+ A server that honors this hint would return a following response containing the HTTP header
+ <code>Preference-Applied: return=representation</code>
+ and this representation:
+ </p>
+
+ <pre class="example">
+ # The following is the ordered representation of
+ # http://example.org/netWorth/nw1/assetContainer/
+ <!-- @base is here only so it's easier to paste into validators for checking -->
+ # @base <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:DirectContainer;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:membershipResource <http://example.org/netWorth/nw1>;
+ ldp:hasMemberRelation o:asset;
+ ldp:insertedContentRelation ldp:MemberSubject.
+ </pre>
+
+ <p id="prefer-examples-direct-empty-container-only2">
+ Clients interested only in information about the container
+ (same as before) might use this hint instead:
+ <code>Prefer: return=representation; omit="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferContainment"</code>. Note: <strong>Treating the two as equivalent is not recommended.</strong> While today this
+ <code>omit</code> parameter value is equivalent to the preceding <code>include</code> parameter value,
+ they may not be equivalent in the future
+ due to the definition of <a title="Empty-container triples">empty-container triples</a>.
+ Clients should preferentially use the <code>include</code> parameter, as it more precisely communicates their needs.
+ </p>
+ <p>
+ A <strong>LDP 1.0</strong> server that honors this hint would return the following response. Servers
+ implementing later versions of LDP might return substantively different responses.
+ </p>
+
+ <pre class="example">
+ # The following is the ordered representation of
+ # http://example.org/netWorth/nw1/assetContainer/
+ <!-- @base is here only so it's easier to paste into validators for checking -->
+ # @base <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:DirectContainer;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:membershipResource <http://example.org/netWorth/nw1>;
+ ldp:hasMemberRelation o:asset;
+ ldp:insertedContentRelation ldp:MemberSubject.
+ </pre>
+
+ <p id="prefer-examples-direct-membershiponly">
+ Clients interested only in information about the container
+ (for example, which membership predicate it uses) and its membership might use this hint on a <code>GET</code> request:
+ <code>Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferEmptyContainer"</code>
+ </p>
+ <p>
+ A server that honors this hint would return
+ (at least) the following response, and perhaps only this (it might
+ well omit containment triples if they are not specifically requested).
+ In cases like this example, where a client can detect from the content that its hints were honored
+ (the presence of the predicates <code>dcterms:title</code> and <code>o:asset</code> demonstrate this in the representation below),
+ there is no need for the server to include a <code>Preference-Applied</code> response header
+ in many common cases like a <code>200 (OK)</code> response. In other cases, like status code <code>303</code>,
+ the header would still be required for the client to know that the <code>303</code> response entity
+ is a representation of the resource identified by the <code>Location</code> URI
+ instead of a short hypertext note (one with a hyperlink to
+ the same URI reference provided in the <code>Location</code> header field [[HTTPBIS-SEMANTICS]]).
+ </p>
+
+ <pre class="example">
+ # The following is the representation of
+ # http://example.org/netWorth/nw1/assetContainer/
+ <!-- @base is here only so it's easier to paste into validators for checking -->
+ # @base <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:DirectContainer;
+ dcterms:title "The assets of JohnZSmith";
+ ldp:membershipResource <http://example.org/netWorth/nw1>;
+ ldp:hasMemberRelation o:asset;
+ ldp:insertedContentRelation ldp:MemberSubject.
+
+ <http://example.org/netWorth/nw1>
+ a o:NetWorth;
+ o:asset <a1>, <a3>, <a2>.
+ </pre>
+
+ </section> <!-- Prefer examples -->
+
+</section> <!-- Prefer defns -->
</section> <!-- Header defns -->
+<!-- Removed for action-113
<section>
<h1>HTTP Status Code Definitions</h1>
@@ -1957,144 +2168,18 @@
</section>
</section> <!-- status code defns -->
-
-<section id="ldpclient">
-<h1>Linked Data Platform Clients</h1>
-<div class="ldp-issue-open">
-
-
-<p>All of the following rules are just copied here, without change; still need to be removed from original section.
-Should consider making this section come before the server sections; doing so would cause mass-renumbering however.
-</p>
- <div id="ldpr-4_3_5" class="rule">4.3.5 In the absence of special knowledge of the application or domain,
- <a title="LDP client">LDP clients</a> MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
- </div>
- <div id="ldpr-4_3_6" class="rule">4.3.6 In the absence of special knowledge of the application or domain,
- <a title="LDP client">LDP clients</a> MUST assume that the <code>rdf:type</code> values
- of a given LDPR can change over time.
- </div>
- <div id="ldpr-4_5_3" class="rule">4.5.3 <a title="LDP client">LDP clients</a> SHOULD always assume that the set of predicates for a
- 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_5" class="rule">4.5.5 An <a title="LDP client">LDP client</a> MUST preserve all triples retrieved using HTTP <code>GET</code> that
- it doesn’t change whether it understands the predicates or not, when
- its intent is to perform an update using HTTP <code>PUT</code>. The use of HTTP
- <code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
- [[RFC5789]].
- </div>
-
-</div>
-</section> <!-- Client constraints -->
-
-<section id="base-specs" class="informative">
-<h1>Notable information from normative references</h1>
-
-<div class="ldp-issue-open">
-<p>
-Given that it's from base specs => important to understand, should be moved up before
-most of the normative sections IMO - renumbering hit again.
-</p>
-</div>
-
-<div class="ldp-issue-pending">
-<p>
-While readers, and especially implementers, of LDP are assumed to understand the information in its normative
-references, the working group has found that certain points are particularly important to understand.
-For those thoroughly familiar with the referenced specifications, these points might seem obvious, yet
-experience has shown that few non-experts find all of them obvious. This section enumerates these topics;
-it is simply re-stating (informatively) information locatable via the normative references.
-</p>
-
-<section id="specs-webarch" class="informative">
-<h1>Architecture of the World Wide Web</h1>
-Reference: [[!WEBARCH]]
-
- <div id="ldp-webarch-nonexcl-membership" class="rule">9.1.1 LDPC membership is not exclusive; this means that the same resource
- (LDPR or not) can be a member of more than one LDPC.
- </div>
- <div id="ldp-webarch-uri-reuse" class="rule">9.1.2 <a title="LDP server">LDP servers</a> should not re-use URIs,
- regardless of the mechanism by which members are created (<code>POST</code>, <code>PUT</code>, etc.).
- Certain specific cases exist where a LDPC server might delete a resource and then later re-use the
- URI when it identifies the same resource, but only when consistent with Web architecture.
- 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>
-
-</section>
-<section id="specs-http" class="informative">
-<h1>HTTP 1.1</h1>
-Reference: [[!HTTP11]]
-
- <div id="ldp-http-other-representations" class="rule">9.2.1 <a title="LDP server">LDP servers</a> can support representations beyond those
- necessary to conform to this specification. These
- could be other RDF formats, like N3 or NTriples, but non-RDF formats
- like HTML [[HTML401]] and JSON [[RFC4627]] would likely be common.
- HTTP content negotiation ([[HTTP11]] Section 12 - Content Negotiation) is used to select the format.
- </div>
- <div id="ldp-http-other-methods" class="rule">9.2.2 LDPRs can be created, updated and deleted using methods not defined in
- this document, for example through application-specific means, SPARQL
- UPDATE, etc. [[SPARQL-UPDATE]], as long as those methods do not conflict with this specification's
- normative requirements.
- </div>
- <div id="ldp-http-delete-uri-reuse" class="rule">9.2.3 <a title="LDP server">LDP servers</a>
- remove the resource identified by the <code>Request-URI</code> in response to a successful HTTP <code>DELETE</code> request.
- After such a request, a subsequent HTTP <code>GET</code> on the same
- <code>Request-URI</code> usually results in a 404 (Not found) or 410 (Gone) status
- code, although HTTP allows others.
- </div>
-
- <div id="ldp-http-method-side-effects" class="rule">9.2.4 <a title="LDP server">LDP servers</a> can alter the state of other resources
- as a result of any HTTP request, especially when non-safe methods are used ([[HTTP11]] section 9.1).
- For example, it is acceptable for the server to
- remove triples from other resources whose subject or object is the
- deleted resource as the result of a successful HTTP <code>DELETE</code> request.
- It is also acceptable and common for <a title="LDP server">LDP servers</a> to
- not do this – the server's behavior can vary, so LDP clients cannot depend on it.
- </div>
- <div id="ldp-http-patch-allowed" class="rule">9.2.5 <a title="LDP server">LDP servers</a> can implement HTTP <code>PATCH</code>
- to allow modifications,
- especially partial replacement, of their resources. No
- minimal set of patch document formats is mandated by this document or by the definition of <code>PATCH</code> [[RFC5789]].
- </div>
- <div id="ldp-http-content-sniffing" class="rule">9.2.6
- When the <code>Content-Type</code> request header is absent from a request,
- <a title="LDP server">LDP servers</a> might infer the content type by inspecting the entity body contents [[HTTP11]].
- </div>
-
-</section>
-
-<section id="specs-rdf" class="informative">
-<h1>RDF</h1>
-Reference: [[RDF-CONCEPTS]]
-
- <div id="ldp-rdfconcepts-extra-triples-any" class="rule">9.3.1 The state of an LDPR
- can have triples with any subject(s). The URL used to retrieve the
- representation of an LDPR need not be the subject of any of its triples.
- </div>
- <div id="ldp-rdfconcepts-extra-triples-members" class="rule">9.3.2 The representation of an LDPC
- can include an arbitrary number of
- additional triples whose subjects are the members of the container,
- or that are from the representations of the members (if they have RDF
- representations). This allows a <a>LDP server</a> to provide clients with
- information about the members without the client having to do a <code>GET</code>
- on each member individually. See <a href="#ldpc-member_data">Container
- Member Information</a> for additional details.
- </div>
- <div id="ldp-rdfconcepts-extra-triples-types" class="rule">9.3.3 The state of an LDPR can have more than one
- triple with a <code>rdf:type</code> predicate.
- </div>
-
-</section>
-
-
-</div>
-</section> <!-- Base specs -->
-
+<section class='informative' id='security'>
+<h1>Security Considerations</h1>
+<p>As with any protocol that is implemented leveraging HTTP, implementations should take advantage of the many
+security-related facilities associated with it and are not required to carry out LDP operations
+that may be in contradistinction to a particular security policy in place. For example, when faced with an
+unauthenticated request to replace system critical RDF statements in a graph through the PUT method, applications may
+consider responding with the 401 status code (Unauthorized), indicating that the appropriate authorization
+is required. In cases where authentication is provided fails to meet the requirements of a particular access control
+policy, the 403 status code (Forbidden) can be sent back to the client to indicate this failure to meet the
+access control policy.</p>
+</section>
<section class='appendix informative'>
<h2>Acknowledgements</h2>
@@ -2102,39 +2187,116 @@
<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>
+ <p style="margin-left: 3em;">
+ Alexandre Bertails, Andrei Sambra, Andy Seaborne, Antonis Loizou, Arnaud Le Hors, Ashok Malhota, Bart van Leeuwen, Cody Burleson, David Wood, Eric Prud'hommeaux, Erik Wilde, Henry Story, John Arwe, Kevin Page, Kingsley Idehen, Mark Baker, Martin P. Nally, Miel Vander Sande, Miguel Esteban Gutiérrez, Nandana Mihindukulasooriya, Olivier Berger, Pierre-Antoine Champin, Raúl García Castro, Reza B'Far, Richard Cyganiak, Roger Menday, Ruben Verborgh, Sandro Hawke, Serena Villata, Sergio Fernandez, Steve Battle, Steve Speicher, Ted Thibodeau, Tim Berners-Lee, Yves Lafon
+ </p>
</section>
<section class='appendix informative' id="history">
<h1>Change History</h1>
+<p>Summary of notable changes from previous public working draft.</p>
+
+<ul>
+ <li>Changed a number of the should/may clauses to must</li>
+ <li>Introduced separate concepts for memerbship and containment</li>
+ <li>Defined sub-types of ldp:Container : Basic, Direct and Indirect</li>
+ <li>Defined sub-types of ldp:Resource : RDF Source and non-RDF Source</li>
+ <li>Improved membership predicate names, changed vocabulary terms</li>
+ <li>Reorganized conformance clauses based on type of resource</li>
+ <li>Moved paging and sorting capability into a separate document [[LDP-PAGING]]</li>
+ <li>Removed non-member property mechanism and replaced with usage of Prefer header</li>
+ <li>Added support for client requested interaction models on containers</li>
+ <li>Move restatements of HTTP et al. out of normative sections</li>
+</ul>
+
+
+<!-- TODO: Full change history removed for Last Call publication -->
+<!--
<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-20130930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
+<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130730/">Last Call Draft</a></em></blockquote> -->
+<!--
<ul>
- <li>2013-10-25 - Resolve ACTION-105 ACTION-105: Update spec to reflect 9/30 resolution moving Paging links to HTTP headers (JA)</li>
+ <li>2014-03-03 - Must use LDPC subtypes for rel='type', per 20140303 resln (SS) </li>
+ <li>2014-03-03 - Removed LDP-BC clauses that introduce membership (SS) </li>
+ <li>2014-03-03 - Tweaked LDPR PUT clauses to better match new defn of LDPR (SS) </li>
+ <li>2014-03-03 - Folded #ldpclients section into #ldprs (SS) </li>
+ <li>2014-03-01 - Split out different kinds of LDPRs into their own subsection (SS)</li>
+ <li>2014-02-28 - Combined rules for container triples (SS) </li>
+ <li>2014-02-28 - Split out different kinds of LDPCs into their own subsection (SS)</li>
+ <li>2014-02-24 - Corrected rel=meta to be rel=describedby (SS) </li>
+ <li>2014-02-24 - Adjusted term membership triples and membership predicate (SS) </li>
+ <li>2014-02-24 - Removed 6.3.1 LDPC GET requirement and put in general clause (SS) </li>
+ <li>2014-02-20 - Changed LDPC SHOULD NOT put (6.5.1) to be about containment (SS) </li>
+ <li>2014-02-20 - Removed rule on PATCH create, as it doesn't add any substantive over RFC5789 (SS) </li>
+ <li>2014-02-18 - Factored out paging and sorting into separate spec LDP-Paging (SS) </li>
+ <li>2014-02-18 - Reference cleanup and tweak LDP-RS term (SS) </li>
+ <li>2014-02-17 - Reference to RDF Document into terms (SS) </li>
+ <li>2014-02-17 - Adopted container hierarchy and merged Indirect Container into Container (SS) </li>
+ <li>2014-02-17 - Adopted new resource types: LDP RDF Source (LDP-RS) (was LDP RDF Resource) and LDP Non-RDF Source (LDP-NR) (was LDP Binary Resource) (SS)</li>
+ <li>2014-02-17 - Adopted new predicate names: ldp:membershipResource, ldp:hasMemberRelation and ldp:isMemberOfRelation (SS) </li>
+ <li>2014-02-12 - Updated LDPR Post reference to Put, which had implied that clients could PUT (to an LDPC) to create an LDPR (JA)</li>
+ <li>2014-02-12 - Updated containerResource on examples 6 and 7, section 6.1, in resp to public-ldp email (JA)</li>
+ <li>2014-02-12 - Updated LDP-IC definition per email thread (JA)</li>
+ <li>2014-02-11 - Updated LDPC create ldp:contains (errant MAY to MUST, resolving conflicting statements) (JA)</li>
+ <li>2014-02-10 - Removed LDPR Paging HTTP OPTIONS section (no longer needed) and more cleanup of todos (SS)</li>
+ <li>2014-02-10 - Updated LDPC DELETE language and cleanup todos (SS)</li>
+ <li>2014-02-10 - Resolved a few editoral TODO's (JA)</li>
+ <li>2014-02-08 - Put final stake in heart of 'informative' (waves to Sandro), update boilerplate for readability per Arnaud (JA)</li>
+ <li>2014-02-08 - ACTION-132: Use Prefer in place of non-member properties resource (JA)</li>
+ <li>2014-02-08 - Add Prefer header examples, define new URIs from -126 in ttl, tweak acks per Arnaud email (JA)</li>
+ <li>2014-02-07 - ACTION-126: Add Prefer header (JA)</li>
+ <li>2014-02-07 - LDP-BCs use ldp:contains not ldp:member (JA)</li>
+ <li>2014-02-07 - Simplified some of the container examples (SS)</li>
+ <li>2014-02-06 - partial first pass at arnaud's email comments (JA)</li>
+ <li>2014-02-06 - fixing containment def, adding containment triples to terminology (JA)</li>
+ <li>2014-02-06 - fixing POST to create containment/membership triples, which was mangled (JA)</li>
+ <li>2014-02-06 - fully aligning SS changes with http://www.w3.org/2012/ldp/wiki/Containers for basic containers, allowing them to omit the standard predicates in representations despite requiring behavior consistent with the presence of those triples (JA)</li>
+ <li>2014-02-06 - editorial fixes (JA)</li>
+ <li>2014-02-06 - ACTION-127 (complete) use the TAG's new [23]xx code; if that code is not sufficiently through IETF process by CR, we will use a 303 (JA)</li>
+ <li>2014-02-05 - ACTION-133 Get rid of ldp:created which is subsumed by ldp:contains (SS)</li>
+ <li>2014-02-04 - ACTION-124 LDPR-RR as named graphs (SS)</li>
+ <li>2014-02-04 - ACTION-120 (complete) Updated LDPC general, GET and POST sections (SS)</li>
+ <li>2014-02-04 - ACTION-120 (Part 3) Added ldp:member (SS)</li>
+ <li>2014-02-04 - ACTION-120 (Part 2) Added concepts of containers (basic, direct and indirect) to LDPC intro (SS)</li>
+ <li>2014-01-30 - ACTION-120 (Part 1) Added concepts of containers (basic, direct and indirect) (SS)</li>
+ <li>2014-01-30 - ACTION-123 Added concepts of LDP-RDF-Resource and LDP-Binary-Resource (SS)</li>
+ <li>2014-01-29 - Fix up conformance section to use new LDP client section (SS)</li>
+ <li>2014-01-21 - Updated reference to LDP BP&G editor's draft and added ref to LDP-UCR (SS)</li>
+ <li>2014-01-21 - Removed redudant reqs that have been moved to #ldpclient (SS)</li>
+ <li>2014-01-21 - Fixed formating with >h2 formatting (SS)</li>
+ <li>2014-01-21 - Put reference to <a href="#base-specs">base-specs</a> into intro section (SS)</li>
+ <li>2014-01-17 - First attempt at correcting section ordering and anchors (SS)</li>
+ <li>2014-01-02 - ACTION-122 Updated 4.2.10, 5.4.4, example 8 + added 5.2.11 requiring rel=type for interaction model (JA)</li>
+ <li>2014-01-02 - ACTION-119 Added 5.4.15 requiring ldp:created for indirect containers (JA)</li>
+ <li>2013-11-27 - ACTION-101 Added informative security section (SS)</li>
+ <li>2013-11-27 - ACTION-100 Added informative note to Ordering section that containers can be nested (SS)</li>
+ <li>2013-11-18 - Various editorial and validation fixes (SS)</li>
+ <li>2013-11-12 - Clean up some remnants of inlining (JA)</li>
+ <li>2013-11-12 - Clean up some overly specific language (implications that POST is the only way to create members, etc) (JA)</li>
+ <li>2013-11-12 - Resolve ACTION-112 Update spec to reflect 10/28 resolution for Issue-81 part 1: new predicate names (JA)</li>
+ <li>2013-11-12 - Fix respec messages that only show up on remote server, hit paging examples to remove appearance of inlining (JA)</li>
+ <li>2013-11-11 - Resolve ACTION-113 Update spec to reflect 11/04 resolution to remove 303 and have client use first/next links to detect paging (JA)</li>
+ <li>2013-10-25 - Resolve ACTION-105 Update spec to reflect 9/30 resolution moving Paging links to HTTP headers (JA)</li>
<li>2013-10-25 - Resolve ACTION-110 Update spec to reflect 10/21 resolution for normative changes to align vanilla/chocolate (JA)</li>
<li>2013-10-22 - Resolve ACTION-109 Update spec to reflect 10/21 resolution for ignoring triples on PUT (JA)</li>
<li>2013-10-22 - Resolve ACTION-107 Update spec to reflect 10/07 resolution on 5.6.2 LDPC deletion (JA)</li>
<li>2013-10-22 - Resolve ACTION-102 Make 4.6.2 informative, clarify that it re-states what http allows, and in fact it applies to all methods not just delete. (JA)</li>
<li>2013-10-22 - Resolve ACTION-103 Change SHOULD to MUST in 4.10.2.3 "LDPR servers that initiate paging SHOULD respond to request ..." (JA)</li>
<li>2013-10-22 - Resolve ACTION-108 move restatements of HTTP et al. out of normative sections (JA)</li>
- <li>2013-10-22 - Resolve ACTION-106 5.3.5 MUST -> SHOULD (JA)</li>
+ <li>2013-10-22 - Resolve ACTION-106 5.3.5 MUST -> SHOULD (JA)</li>
<li>2013-10-21 - Mock up status code 209 Related Content (JA)</li>
<li>2013-10-01 - Mock up new section for rules declared to be non-normative restatements of info from other specs (JA)</li>
<li>2013-10-01 - Revising terminology - membership triples and friends (JA)</li>
<li>2013-10-01 - Revising introduction (JA)</li>
<li>2013-10-01 - Conformance section drafting + mock up "LDP Clients" section as part of that (JA)</li>
<li>2013-09-23 - Remove client/server-initiated paging terms (JA)</li>
- <li>2013-09-17 - Change must to MUST in <a href="#ldpc-5_6_4">5.6.4</a> (SS)</li>
+ <li>2013-09-17 - Change must to MUST in 5.6.4 (SS)</li>
<li>2013-09-17 - Removed "at-risk" inlining feature from spec, <a href="https://www.w3.org/2012/ldp/track/actions/98">ACTION-98</a> (SS)</li>
<li>2013-09-17 - Fixed vanishing section ref problem (SS)</li>
<li>2013-08-19 - Basic preparation for edits unto LC draft (SS)</li>
@@ -2145,25 +2307,25 @@
<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 - Added term "Page resource" (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 - Inserted ldp:insertedContentRelation 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 - Improving working in #ldpr-Paging 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-11 - ISSUE-51 Added how an 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-10 - ISSUE-72 adding 5.2.10 for ldp:insertedContentRelation (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>
@@ -2183,14 +2345,14 @@
<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 - ISSUE-13 Updated 5.2.3 to say any resource can be in an 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-21 Added ldp:containedByRelation 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>
@@ -2248,7 +2410,7 @@
<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>
+<blockquote><em><a href="http://www.w3.org/Submission/2012/SUBM-ldbp-20120326/">Submission</a></em></blockquote> -->
</section>
</body>
--- a/ldp.ttl Wed Mar 05 16:33:45 2014 +0000
+++ b/ldp.ttl Wed Mar 05 16:34:18 2014 +0000
@@ -21,178 +21,145 @@
:Resource
a rdfs:Class;
- rdfs:comment "A HTTP-addressable resource with a linked data representation.";
+ rdfs:comment "A HTTP-addressable resource whose lifecycle is managed by a LDP server.";
vs:term_status "unstable";
rdfs:isDefinedBy :;
rdfs:label "Resource".
+
+:RDFSource
+ a rdfs:Class;
+ rdfs:subClassOf :Resource;
+ rdfs:comment "A Linked Data Platform Resource (LDPR) whose state is represented as
+ RDF.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "RDFSource".
+
+:NonRDFSource
+ a rdfs:Class;
+ rdfs:subClassOf :Resource;
+ rdfs:comment "A Linked Data Platform Resource (LDPR) whose state is NOT represented as
+ RDF.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "NonRDFSource".
:Container
a rdfs:Class;
- rdfs:subClassOf :Resource;
- rdfs:comment "A Linked Data Platform Resource (LDPR) that also conforms to
+ rdfs:subClassOf :RDFSource;
+ rdfs:comment "A Linked Data Platform RDF Source (LDP-RS) that also conforms to
additional patterns and conventions for managing membership.
Readers should refer to the specification defining this ontology for the list of
behaviors associated with it.";
vs:term_status "unstable";
rdfs:isDefinedBy :;
rdfs:label "Container".
-
-:containerSortCriteria
- a rdf:Property;
- rdfs:comment "Link to the list of sorting criteria used by the server in a representation.";
- vs:term_status "unstable";
- rdfs:domain :Page;
- rdfs:isDefinedBy :;
- rdfs:label "containerSortCriteria";
- rdfs:range rdf:List.
-
-:ContainerSortCriterion
- a rdf:Class;
- rdfs:comment "Element in the list of container sorting criteria used by the server in a representation.";
- vs:term_status "unstable";
- rdfs:label "ContainerSortCriterion";
- rdfs:isDefinedBy :.
-
-:containerSortPredicate
- a rdf:Property;
- rdfs:comment "Predicate used to determine the order of the members in a page.";
- vs:term_status "unstable";
- rdfs:domain :ContainerSortCriterion;
- rdfs:isDefinedBy :;
- rdfs:label "containerSortPredicate";
- rdfs:range rdf:Property.
-
-:containerSortOrder
- a rdf:Property;
- rdfs:comment "The ascending/descending/etc order used to order the members in a page.";
- vs:term_status "unstable";
- rdfs:domain :ContainerSortCriterion;
- rdfs:isDefinedBy :;
- rdfs:label "containerSortOrder";
- rdfs:range rdf:Resource.
-
-:containerSortCollation
- a rdf:Property;
- rdfs:comment "The collation used to order the members in a page when comparing strings.";
- vs:term_status "unstable";
- rdfs:domain :ContainerSortCriterion;
- rdfs:isDefinedBy :;
- rdfs:label "containerSortCollation";
- rdfs:range rdf:Property.
-
-:Ascending
- a rdf:Description; # individual
- rdfs:comment "Ascending order.";
+
+:BasicContainer
+ a rdfs:Class;
+ rdfs:subClassOf :Container;
+ rdfs:comment "An LDPC that uses a predefined predicate to simply link to its contained resources.";
vs:term_status "unstable";
rdfs:isDefinedBy :;
- rdfs:label "Ascending".
-
-:Descending
- a rdf:Description; # individual
- rdfs:comment "Descending order.";
+ rdfs:label "BasicContainer".
+
+:DirectContainer
+ a rdfs:Class;
+ rdfs:subClassOf :Container;
+ rdfs:comment "An LDPC that is similar to a LDP-DC but it allows an indirection with the ability to
+ list as member a resource, such as a URI representing a real-world object, that is different
+ from the resource that is created";
vs:term_status "unstable";
rdfs:isDefinedBy :;
- rdfs:label "Descending".
-
-:membershipPredicate
+ rdfs:label "DirectContainer".
+
+:IndirectContainer
+ a rdfs:Class;
+ rdfs:subClassOf :Container;
+ rdfs:comment "An LDPC that has the flexibility of choosing what form the membership triples take.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "IndirectContainer".
+
+:hasMemberRelation
a rdf:Property;
- rdfs:comment "Indicates which predicate of the container should be used to determine the membership.";
+ rdfs:comment "Indicates which predicate is used in membership triples, and that the membership triple pattern is < membership-constant-URI , object-of-hasMemberRelation, member-URI >.";
vs:term_status "unstable";
rdfs:domain :Container;
rdfs:isDefinedBy :;
- rdfs:label "membershipPredicate";
+ rdfs:label "hasMemberRelation";
rdfs:range rdf:Property.
-:membershipPredicateInverse
+:isMemberOfRelation
a rdf:Property;
- rdfs:comment "Indicates which predicate of the container should be used to determine the inverse membership.";
- vs:term_status "unstable";
- rdfs:domain :Container;
- rdfs:isDefinedBy :;
- rdfs:label "membershipPredicateInverse";
- rdfs:range rdf:Property.
-
-:membershipSubject
- a rdf:Property;
- rdfs:comment "Indicates which resource is the subject for the members of the container.";
- vs:term_status "unstable";
- rdfs:domain :Container;
- rdfs:isDefinedBy :;
- rdfs:label "membershipSubject";
- rdfs:range rdf:Property.
-
-:membershipObject
- a rdf:Property;
- rdfs:comment "Indicates which triple in a POSTed resource indicates what should be used as the object for the membership triple's object.";
+ rdfs:comment "Indicates which predicate is used in membership triples, and that the membership triple pattern is < member-URI , object-of-isMemberOfRelation, membership-constant-URI >.";
vs:term_status "unstable";
rdfs:domain :Container;
rdfs:isDefinedBy :;
- rdfs:label "membershipObject";
+ rdfs:label "isMemmberOfRelation";
+ rdfs:range rdf:Property.
+
+:membershipResource
+ a rdf:Property;
+ rdfs:comment "Indicates the membership-constant-URI in a membership triple. Depending upon the membership triple pattern a container uses, as indicated by the presence of ldp:hasMemberRelation or ldp:isMemberOfRelation, the membership-constant-URI might occupy either the subject or object position in membership triples.";
+ vs:term_status "unstable";
+ rdfs:domain :Container;
+ rdfs:isDefinedBy :;
+ rdfs:label "membershipResource";
+ rdfs:range rdf:Property.
+
+:insertedContentRelation
+ a rdf:Property;
+ rdfs:comment "Indicates which triple in a creation request should be used as the member-URI value in the membership triple added when the creation request is successful.";
+ vs:term_status "unstable";
+ rdfs:domain :Container;
+ rdfs:isDefinedBy :;
+ rdfs:label "insertedContentRelation";
rdfs:range rdf:Property.
-:nextPage
+:member
a rdf:Property;
- rdfs:comment "From a known page, how to indicate the next or last page as rdf:nil.";
+ rdfs:comment "LDP servers should use this predicate as the membership predicate if there is no obvious predicate from an application vocabulary to use.";
vs:term_status "unstable";
- rdfs:domain :Page;
- rdfs:isDefinedBy :;
- rdfs:label "nextPage";
- rdfs:range rdfs:Resource.
-
-:Page
- a rdfs:Class;
- rdfs:comment "A resource that represents a limited set of members of a LDP Container.";
- vs:term_status "unstable";
+ rdfs:domain :Resource;
rdfs:isDefinedBy :;
- rdfs:label "Page".
-
-:pageOf
- a rdf:Property;
- rdfs:comment "Associates a page with its resource.";
- vs:term_status "unstable";
- rdfs:domain :Page;
- rdfs:isDefinedBy :;
- rdfs:label "pageOf";
- rdfs:range :Resource.
-
-:nonMemberResource
- a rdf:Description;
- rdfs:comment "Extension link relation type URI for use in HTTP Link header. When a server offers clients the ability to retrieve non-member properties of an LDPC through an associated non-member resource, this Link header is how clients discover the existence of that resource and its URI.";
- vs:term_status "unstable";
- rdfs:isDefinedBy :;
- rdfs:label "nonMemberResource";
- rdfs:domain :Container;
- rdfs:range :Resource.
+ rdfs:label "member";
+ rdfs:range rdfs:Resource.
-:created
+:contains
a rdf:Property;
rdfs:comment "Links a container with resources created through the container.";
vs:term_status "unstable";
rdfs:domain :Container;
rdfs:isDefinedBy :;
- rdfs:label "created";
- rdfs:range rdfs:Resource.
-
-:membersInlined
- a rdf:Property;
- rdfs:comment "Boolean: true indicates that a response includes the triples from all member resources listed in the response, false that not all triples from all members are included.";
- vs:term_status "at-risk";
- rdfs:domain :Page;
- rdfs:isDefinedBy :;
- rdfs:label "membersInlined".
-
-:inlinedResource
- a rdf:Property;
- rdfs:comment "Link to a HTTP request-URI that the representation includes all triples from. In other words, the representation in which the link is found includes all the RDF triples that would be returned in a 200-OK response to a HTTP GET request to that request-URI, which might include multiple RDF subject URIs.";
- vs:term_status "at-risk";
- rdfs:domain :Page;
- rdfs:isDefinedBy :;
- rdfs:label "inlinedResource";
+ rdfs:label "contains";
rdfs:range rdfs:Resource.
:MemberSubject
- a rdf:Description;
- rdfs:comment "Used to indicate default and typical behavior when ldp:membershipObject is the same as the member resource.";
+ a rdf:Description; # individual
+ rdfs:comment "Used to indicate default and typical behavior for ldp:insertedContentRelation, where the member-URI value in the membership triple added when a creation request is successful is the URI assigned to the newly created resource.";
vs:term_status "unstable";
rdfs:isDefinedBy :;
rdfs:label "MemberSubject".
+
+:PreferContainment
+ a rdf:Description; # individual
+ rdfs:comment "URI identifying a LDPC's containment triples, for example to allow clients to express interest in receiving them.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "PreferContainment".
+
+:PreferMembership
+ a rdf:Description; # individual
+ rdfs:comment "URI identifying a LDPC's membership triples, for example to allow clients to express interest in receiving them.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "PreferMembership".
+
+:PreferEmptyContainer
+ a rdf:Description; # individual
+ rdfs:comment "URI identifying the subset of a LDPC's triples present in an empty LDPC, for example to allow clients to express interest in receiving them. Currently this excludes containment and membership triples, but in the future other exclusions might be added. This definition is written to automatically exclude those new classes of triples.";
+ vs:term_status "unstable";
+ rdfs:isDefinedBy :;
+ rdfs:label "PreferEmptyContainer".
+
\ No newline at end of file