--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/TR/CR-ldp-20140619/Overview.html Mon Jun 16 13:53:33 2014 -0400
@@ -0,0 +1,2936 @@
+<!DOCTYPE html>
+<html lang="en" dir="ltr" typeof="bibo:Document w3p:CR" about="" property="dcterms:language" content="en" prefix="bibo: http://purl.org/ontology/bibo/ w3p: http://www.w3.org/2001/02pd/rec54#" xmlns="http://www.w3.org/1999/xhtml">
+<head>
+ <title>Linked Data Platform 1.0</title>
+ <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
+
+<!--
+ === NOTA BENE ===
+ For the three scripts below, if your spec resides on dev.w3 you can check them
+ out in the same tree and use relative links so that they'll work offline,
+ -->
+
+
+
+ <style type="text/css">
+ div.rule {padding-top: 1em;}
+ div.ldp-issue-open {
+ border-color: #E05252;
+ background: #FBE9E9;
+ padding: 0.5em;
+ margin: 1em 0;
+ position: relative;
+ clear: both;
+ border-left-width: .5em;
+ border-left-style: solid;
+ }
+ div.ldp-issue-pending {
+ border-color: #FAF602;
+ background: #F7F6BC;
+ padding: 0.5em;
+ margin: 1em 0;
+ position: relative;
+ clear: both;
+ border-left-width: .5em;
+ border-left-style: solid;
+ }
+ div.ldp-issue-closed {
+ border-color: #009900;
+ background: #BCF7CF;
+ padding: 0.5em;
+ margin: 1em 0;
+ position: relative;
+ clear: both;
+ border-left-width: .5em;
+ border-left-style: solid;
+ }
+ div.ldp-issue-title {
+ color: #E05252;
+ padding-right: 1em;
+ min-width: 7.5em;
+ }
+ .atrisk {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #f00;
+ background: #ffc;
+ }
+ .atrisktext {
+ /* content: "Feature At Risk"; */
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+ }
+ .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-CR" />
+<!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]-->
+</head>
+<body class="h-entry" role="document" id="respecDocument"><div class="head" role="contentinfo" id="respecHeader">
+ <p>
+
+ <a href="http://www.w3.org/"><img width="72" height="48" src="https://www.w3.org/Icons/w3c_home" alt="W3C" /></a>
+
+ </p>
+ <h1 class="title p-name" id="title" property="dcterms:title">Linked Data Platform 1.0</h1>
+
+ <h2 property="dcterms:issued" datatype="xsd:dateTime" content="2014-06-19T21:24:25.000Z" id="w3c-candidate-recommendation-19-june-2014"><abbr title="World Wide Web Consortium">W3C</abbr> Candidate Recommendation <time class="dt-published" datetime="2014-06-19">19 June 2014</time></h2>
+ <dl>
+
+ <dt>This version:</dt>
+ <dd><a class="u-url" href="http://www.w3.org/TR/2014/CR-ldp-20140619/">http://www.w3.org/TR/2014/CR-ldp-20140619/</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>Test suite:</dt>
+ <dd><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-testsuite.html">https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-testsuite.html</a></dd>
+
+
+ <dt>Implementation report:</dt>
+ <dd><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/reports/ldp.html">https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/reports/ldp.html</a></dd>
+
+
+
+
+ <dt>Previous version:</dt>
+ <dd><a rel="dcterms:replaces" href="http://www.w3.org/TR/2014/WD-ldp-20140311/">http://www.w3.org/TR/2014/WD-ldp-20140311/</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.
+
+ <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
+ <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
+
+ <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
+
+ rules apply.
+ </p>
+
+
+ <hr />
+</div>
+<section id="abstract" class="introductory" property="dcterms:abstract" datatype="" typeof="bibo:Chapter" resource="#abstract" rel="bibo:Chapter"><h2 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="#sotd" 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 Candidate Recommendation document where the Working Group has addressed all
+ raised issues and seeks to gather implementation feedback. For changes since last publication, see <a href="#history" class="sectionRef sec-ref">section <span class="secno">B.</span> <span class="sec-title">Change History</span></a>.
+ A test suite is available at [<cite><a class="bibref" href="#bib-LDP-Tests">LDP-Tests</a></cite>].
+ </p>
+ <p>The following features are At Risk:</p>
+ <ol>
+ <li>The <a href="#header-accept-post">HTTP Accept-Post header</a>,
+ that allows clients to determine which media types a server accepts on POST requests.
+ </li>
+ <li>The requirement that LDP clients be <a href="#atrisk-paging">paging-aware</a>.
+ </li>
+ </ol>
+
+ <p>
+ This document was published by the <a href="http://www.w3.org/2012/ldp">Linked Data Platform Working Group</a> as a Candidate Recommendation.
+
+ 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>).
+
+
+
+ <abbr title="World Wide Web Consortium">W3C</abbr> publishes a Candidate Recommendation to indicate that the document is believed to be
+ stable and to encourage implementation by the developer community. This Candidate
+ Recommendation is expected to advance to Proposed Recommendation no earlier than
+ 17 July 2014.
+
+
+ All comments are welcome.
+
+ </p>
+
+ <p>
+ Please see the Working Group's <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/reports/ldp.html">implementation
+ report</a>.
+ </p>
+
+
+ <p>
+ Publication as a Candidate Recommendation 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 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="#link-relations" class="tocxref"><span class="secno">8. </span>Link Relations</a><ul class="toc"><li class="tocline"><a href="#link-relation-describedby" class="tocxref"><span class="secno">8.1 </span>describedby</a></li></ul></li><li class="tocline"><a href="#security" class="tocxref"><span class="secno">9. </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="#intro" 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 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="#terms" 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-RFC7230">RFC7230</a></cite>], [<cite><a class="bibref" href="#bib-RFC7231">RFC7231</a></cite>], [<cite><a class="bibref" href="#bib-RFC7232">RFC7232</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 one or more HTTP requests [<cite><a class="bibref" href="#bib-RFC7230">RFC7230</a></cite>].<p></p></dd>
+
+ <dt>Server</dt>
+ <dd>A program that accepts connections in order to service HTTP requests by sending HTTP responses.
+ <p>
+ The terms "client" and "server" refer only to the roles that these programs perform for a particular connection.
+ The same program might act as a client on some connections and a server on others.
+ </p>
+ <p>
+ HTTP enables the use of intermediaries to satisfy requests through a
+ chain of connections. There are three common forms of HTTP
+ intermediary: proxy, gateway, and tunnel. In some cases, a single
+ intermediary might act as an origin server, proxy, gateway, or
+ tunnel, switching behavior based on the nature of each request.
+ [<cite><a class="bibref" href="#bib-RFC7230">RFC7230</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> graph. 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>.
+ For example, these can be 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>A <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> that adds the concept of <a title="Membership" href="#dfn-membership" class="internalDFN">membership</a>, allowing 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> 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>
+ that is also 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 Container">LDPC</abbr> and its member <abbr title="Linked Data Platform Resources">LDPRs</abbr>,
+ which can be different resources than its <a title="Containment" href="#dfn-containment" class="internalDFN">contained</a> documents.
+ The <abbr title="Linked Data Platform Container">LDPC</abbr> often assists with managing the membership triples, whether or not the <abbr title="Linked Data Platform Container">LDPC</abbr>'s
+ URI occurs in them.
+ <p></p></dd>
+
+ <dt><dfn id="dfn-membership-triples">Membership triples</dfn></dt>
+ <dd>A set of triples that lists an <abbr title="Linked Data Platform Container">LDPC</abbr>'s members.
+ A <abbr title="Linked Data Platform Container">LDPC</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 Container">LDPC</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, 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-minimal-container-triples">Minimal-container triples</dfn></dt>
+ <dd>
+ The portion of an <abbr title="Linked Data Platform Container">LDPC</abbr>'s triples 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 (if either are considered part of its state),
+ 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="#conventions" 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="#conformance" 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-RFC7230">RFC7230</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-RFC7230">RFC7230</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="#ldpr" 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="#ldpr-informative" 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>How can the server make it easy for the client to create resources?</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>A LDP server can manage 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 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="#ldpr-resource" 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="#ldpr-general" 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="#ldpr-gen-http" 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-RFC7230">RFC7230</a></cite>].
+ </h5></section>
+<!-- Was 4.2.1 / #ldpr-4_2_1 -->
+
+
+ <section id="ldpr-gen-binary" typeof="bibo:Chapter" resource="#ldpr-gen-binary" 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 <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="#ldpr-gen-etags" 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, for responses that contain resource representations or
+ successful responses to HTTP <code>HEAD</code> requests.
+ </h5></section>
+<!-- Was 4.2.8 / #ldpr-4_2_8 -->
+
+
+ <section id="ldpr-gen-linktypehdr" typeof="bibo:Chapter" resource="#ldpr-gen-linktypehdr" 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 an <abbr title="Linked Data Platform Resource">LDPR</abbr>'s HTTP <code>Request-URI</code> [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>].
+ </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 the 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="#ldpr-options-must">supports OPTIONS</a>, and so on,
+ which is not true of all Web resources.
+ </p>
+ <p>
+ Note:
+ <a href="#ldpr-gen-binary">A LDP server can host a mixture of LDP-RSs and LDP-NRs</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="#ldpr-gen-defbaseuri" 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="#ldpr-gen-pubclireqs" 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="#ldpr-HTTP_GET" 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="#ldpr-get-must" 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="#ldpr-get-options" 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="#ldpr-HTTP_POST" 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-RFC7231">RFC7231</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 a 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 a <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="#ldpr-HTTP_PUT" 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-RFC7231">RFC7231</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 a 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="#ldpr-put-replaceall" 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="#ldpr-put-simpleupdate" 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="#ldprs-put-servermanagedprops" 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>
+ fail the request by responding 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-managed properties
+ are identical on the GET response and the subsequent PUT request.
+ This is in contrast to other cases like write-once properties that the server does not allow clients to modify once set;
+ write-once properties are under client control, they are not <a href="#ldpr-put-replaceall">server-managed</a>.
+ </blockquote>
+
+ <section id="ldprs-put-failed" typeof="bibo:Chapter" resource="#ldprs-put-failed" 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-RFC7231">RFC7231</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="#ldpr-put-precond" 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-RFC7232">RFC7232</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="#ldpr-put-create" 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="#ldpr-HTTP_DELETE" 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-RFC7231">RFC7231</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 a LDP server supports this method,
+ this specification imposes no new blanket requirements for <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
+ </p>
+
+ <p>Additional requirements on HTTP <code>DELETE</code> for <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="#ldpr-HTTP_HEAD" 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="#ldpr-head-must" 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="#ldpr-HTTP_PATCH" 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 a 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="#ldpr-patch-acceptpatch" 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="#ldpr-HTTP_OPTIONS" 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-RFC7231">RFC7231</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="#ldpr-options-must" 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="#ldpr-options-allow" 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="#ldprs" 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="#ldprs-general" 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="#ldprs-are-ldpr" 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> as defined in <a href="#ldpr-resource" class="sectionRef sec-ref">section <span class="secno">4.2</span> <span class="sec-title">Resource</span></a>, along with the
+ 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: one
+ whose subject is the <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>,
+ whose predicate is <code>rdf:type</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="#ldprs-gen-atleast1rdftype" 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="#ldprs-rdftype" 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 a <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> <em class="rfc2119" title="MAY">MAY</em> have an <code>rdf:type</code>
+ 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="#ldprs-gen-rdf" 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="#ldprs-gen-reusevocab" 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="#ldprs-gen-reusevocabsuchas" 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="#ldp-cli-multitype" 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 <code>rdf:type</code> triples with different objects.
+ </h5></section>
+<!-- Was 4.3.5 / #ldpr-4_3_5 -->
+
+
+ <section id="ldpr-cli-typeschange" typeof="bibo:Chapter" resource="#ldpr-cli-typeschange" 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="#ldpr-cli-openpreds" 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="#ldprs-gen-noinferencing" 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="#ldpr-cli-preservetriples" 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 a <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="#ldpr-cli-can-hint" 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="#ldpr-cli-hints-ignorable" 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 a 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="#ldpr-cli-paging" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-cli-paging">
+ <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 a 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="#ldprs-HTTP_GET" 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="#ldprs-get-turtle" 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> whenever HTTP content negotiation
+ does not force another outcome [<cite><a class="bibref" href="#bib-turtle">turtle</a></cite>]. In other words, if the server receives a <code>GET</code> request whose <code>Request-URI</code>
+ identifies a <a title="" href="#dfn-linked-data-platform-rdf-source" class="internalDFN"><abbr title="Linked Data Platform RDF Source">LDP-RS</abbr></a>, and either <code>text/turtle</code> has the highest relative quality
+ factor (<code>q=</code> value) in the
+ Accept request header or that header is absent, then an <a title="" href="#dfn-ldp-server" class="internalDFN">LDP server</a> has to respond with Turtle.
+ </h5></section>
+<!-- Was 4.3.3 / #ldpr-4_3_3 -->
+
+
+ <section id="ldprs-get-jsonld" typeof="bibo:Chapter" resource="#ldprs-get-jsonld" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldprs-get-jsonld"><span class="secno">4.3.2.2 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="SHOULD">SHOULD</em> offer a <code>application/ld+json</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-JSON-LD">JSON-LD</a></cite>].
+ </h5></section>
+<!-- new -->
+
+
+</section>
+<!-- ldprs-HTTP_GET -->
+
+
+</section>
+<!-- ldprs RDF Source-->
+
+
+<section id="ldpnr" typeof="bibo:Chapter" resource="#ldpnr" 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="#ldpnr-general" 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="#ldpnr-are-ldpr" 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> Sources</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 id="ldpnr-type" typeof="bibo:Chapter" resource="#ldpnr-type" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpnr-type"><span class="secno">4.4.1.2 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> exposing an <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="MAY">MAY</em> advertise this by exposing a HTTP <code>Link</code> header
+ with a target URI of <code>http://www.w3.org/ns/ldp#NonRDFSource</code>, and
+ a link relation type of <code>type</code> (that is, <code>rel='type'</code>)
+ in responses to requests made
+ to the <abbr title="Linked Data Platform Non-RDF Source">LDP-NR</abbr>'s HTTP <code>Request-URI</code> [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>].
+ </h5></section>
+
+</section>
+<!-- ldpnr Non-RDF Source-->
+
+
+</section>
+
+</section>
+<!-- ldpr h1 -->
+
+
+<section id="ldpc" typeof="bibo:Chapter" resource="#ldpc" 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="#ldpc-informative" 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>
+
+<em>Request</em> to <code>http://example.org/c1/</code>:
+<div class="example"><div class="example-title"><span>Example 1</span></div><pre class="example" id="ldpc-ex-simple-req">GET /c1/ HTTP/1.1
+Host: example.org
+Accept: text/turtle</pre></div>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 2</span></div><pre class="example" id="ldpc-ex-simple">HTTP/1.1 200 OK
+Content-Type: text/turtle
+Date: Thu, 12 Jun 2014 18:26:59 GMT
+ETag: "8caab0784220148bfe98b738d5bb6d13"
+Accept-Post: text/turtle, application/ld+json
+Allow: POST,GET,OPTIONS,HEAD,PUT
+Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type",
+ <http://www.w3.org/ns/ldp#Resource>; rel="type"
+Transfer-Encoding: chunked
+
+<!-- @base <http://example.org/c1></http:>. -->
+
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<http://example.org/c1/>
+ 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>The preceding example is very straightforward: there are containment triples
+ whose subject is the container, whose predicate is
+ <code>ldp:contains</code>, and whose objects are the URIs of the contained resources,
+ and there is no distinction between member resources and 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 called a
+ <a title="" href="#dfn-linked-data-platform-basic-container" class="internalDFN">Linked Data Platform Basic Container</a>. </p>
+
+ <p>
+ Sometimes you have to build on existing models incrementally, so you have fewer degrees of
+ freedom in the resource model. In these situations, it can be useful to help clients map
+ LDP patterns onto existing vocabularies, or to include members not created via the container;
+ <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Containers</a>
+ meet those kinds of needs. Direct Containers allow membership triples 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 pre-existing domain resource for a person's net worth, as illustrated below:</p>
+
+<em>Request</em> to <code>http://example.org/netWorth/nw1</code>:
+<div class="example"><div class="example-title"><span>Example 3</span></div><pre class="example" id="ldpc-ex-membership-partial-req">GET /netWorth/nw1 HTTP/1.1
+Host: example.org
+Accept: text/turtle</pre></div>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 4</span></div><pre class="example" id="ldpc-ex-membership-partial">HTTP/1.1 200 OK
+Content-Type: text/turtle
+Date: Thu, 12 Jun 2014 18:26:59 GMT
+ETag: "0f6b5bd8dc1f754a1238a53b1da34f6b"
+Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type",
+ <http://www.w3.org/ns/ldp#Resource>; rel="type"
+Allow: GET,OPTIONS,HEAD,PUT,DELETE
+Transfer-Encoding: chunked
+
+<!-- @base <http://example.org/netWorth/nw1>. -->
+
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix o: <http://example.org/ontology#>.
+
+<http://example.org/netWorth/nw1>
+ a o:NetWorth;
+ o:netWorthOf <http://example.org/users/JohnZSmith>;
+ o:asset
+ <assets/a1>,
+ <assets/a2>;
+ o:liability
+ <liabilities/l1>,
+ <liabilities/l2>,
+ <liabilities/l3>.</pre></div>
+ <p>
+ In the preceding 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 a <code>o:netWorthOf</code> predicate indicating
+ the associated person. There are two sets of same-subject, same-predicate triples; one for assets and
+ one for liabilities. Existing domain-specific applications exist that depend on those types and
+ predicates, so changing them <em>incompatibly</em> would be frowned upon.
+ </p>
+
+ <p>
+ It would be helpful to be able to use LDP patterns to manage the assets and liabilities-related triples.
+ Doing so using a Basic Container would require duplicating much of the information with different types and
+ predicates, which would be onerous for large resources. <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">Direct Containers</a>
+ provide a middle ground, by giving LDP clients a way to map existing domain-specific resources to LDP's
+ types and interaction models.
+ In this specific example,
+ it would be helpful to be able to manage the assets and liabilities triples consistently, for example
+ by using LDP containers.
+ One way to do this is to create two containers, one to manage assets and another liabilities,
+ as separate HTTP resources. Existing clients have no need to interact with those containers,
+ whereas LDP-enabled clients now have container URLs that they can interact with. The existing
+ resource remains unchanged so that existing clients continue to function normally.
+ This is illustrated in the set of related examples, one example per HTTP resource, starting with
+ the <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> example from before:
+ </p>
+
+<em>Request</em> to <code>http://example.org/netWorth/nw1</code>:
+<div class="example"><div class="example-title"><span>Example 5</span></div><pre class="example" id="ldpc-ex-membership-full-req">GET /netWorth/nw1 HTTP/1.1
+Host: example.org
+Accept: text/turtle</pre></div>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 6</span></div><pre class="example" id="ldpc-ex-membership-full">HTTP/1.1 200 OK
+Content-Type: text/turtle
+Date: Thu, 12 Jun 2014 18:26:59 GMT
+ETag: "0f6b5bd8dc1f754a1238a53b1da34f6b"
+Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type",
+ <http://www.w3.org/ns/ldp#Resource>; rel="type"
+Allow: GET,OPTIONS,HEAD,PUT,DELETE
+Transfer-Encoding: chunked
+
+<!-- @base <http://example.org/netWorth/nw1>. -->
+
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix o: <http://example.org/ontology#>.
+
+<http://example.org/netWorth/nw1>
+ a o:NetWorth;
+ o:netWorthOf <http://example.org/users/JohnZSmith>;
+ o:asset
+ <assets/a1>,
+ <assets/a2>;
+ o:liability
+ <liabilities/l1>,
+ <liabilities/l2>,
+ <liabilities/l3>.</pre></div>
+
+
+ <p>The structure of the net worth resource is completely unchanged, so any existing
+ domain-specific applications continue to work without impact.
+ LDP clients, on the other hand, have no way to understand that the asset and
+ liability triples correspond in any way to LDP containers. For that, they need the
+ next two resources.
+ </p>
+ <p>The first container is a <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Container</a> to manage assets.
+ Direct Containers add the concept of <a title="Membership" href="#dfn-membership" class="internalDFN">membership</a>
+ and flexibility on how to specify the <a title="Membership triples" href="#dfn-membership-triples" class="internalDFN">membership triples</a>.
+ </p>
+
+<em>Request</em> to <code>http://example.org/netWorth/nw1/assets/</code>:
+<div class="example"><div class="example-title"><span>Example 7</span></div><pre class="example" id="ldpc-ex-membership-subj-req">GET /netWorth/nw1/assets/ HTTP/1.1
+Host: example.org
+Accept: text/turtle</pre></div>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 8</span></div><pre class="example" id="ldpc-ex-membership-subj">HTTP/1.1 200 OK
+Content-Type: text/turtle
+Date: Thu, 12 Jun 2014 18:26:59 GMT
+ETag: "6df36eef2631a1795bfe9ab76760ea75"
+Accept-Post: text/turtle, application/ld+json
+Allow: POST,GET,OPTIONS,HEAD
+Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
+ <http://www.w3.org/ns/ldp#Resource>; rel="type"
+Transfer-Encoding: chunked
+
+<!-- @base <http://example.org/netWorth/nw1/assets></http:>. -->
+
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix o: <http://example.org/ontology#>.
+
+<http://example.org/netWorth/nw1/assets/>
+ 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>
+
+ <p>
+ In the preceding asset container, 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 the (separate) net worth resource. The
+ membership predicate is <code>o:asset</code>,
+ from the domain model. A POST of an asset representation to the asset container will create a new
+ asset and add it to net-worth's list of assets by adding a new membership triple
+ to the resource and a containment triple to the container.
+ </p>
+
+ <p>The second container is a <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Container</a> to manage liabilities.
+ </p>
+<em>Request</em> to <code>http://example.org/netWorth/nw1/liabilities/</code>:
+<div class="example"><div class="example-title"><span>Example 9</span></div><pre class="example" id="ldpc-ex-membership-full-liabcont-req">GET /netWorth/nw1/liabilities/ HTTP/1.1
+Host: example.org
+Accept: text/turtle</pre></div>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 10</span></div><pre class="example" id="ldpc-ex-membership-full-liabcont">HTTP/1.1 200 OK
+Content-Type: text/turtle
+Date: Thu, 12 Jun 2014 18:26:59 GMT
+ETag: "9f50da01f792281ddcfebe9788372d07"
+Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
+ <http://www.w3.org/ns/ldp#Resource>; rel="type"
+Accept-Post: text/turtle, application/ld+json
+Allow: POST,GET,OPTIONS,HEAD
+Transfer-Encoding: chunked
+
+<!-- @base <http://example.org/netWorth/nw1/liabilities></http:>. -->
+
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix o: <http://example.org/ontology#>.
+
+<http://example.org/netWorth/nw1/liabilities/>
+ 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 preceding liability container is completely analogous to the asset container above, simply
+ managing liabilities instead of assets and using the <code>o:liability</code> predicate.
+ </p>
+ <p>
+ To add a another liability, a client would POST something like this to the liability container:
+ </p>
+
+<em>Request</em> to <code>http://example.org/netWorth/nw1/liabilities/</code>:
+<div class="example"><div class="example-title"><span>Example 11</span></div><pre class="example" id="ldpc-ex-membership-add-new-liability-req">POST /netWorth/nw1/liabilities/ HTTP/1.1
+Host: example.org
+Accept: text/turtle
+Content-Type: text/turtle
+Content-Length: 63
+
+<!-- @base is here only so it's easier to paste into validators for checking -->
+
+@prefix o: <http://example.org/ontology#>.
+
+<>
+ a o:Liability.
+ # plus any other properties that the domain says liabilities have</pre></div>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 12</span></div><pre class="example" id="ldpc-ex-membership-add-new-liability">HTTP/1.1 201 Created
+Location: http://example.org/netWorth/nw1/liabilities/l4
+Date: Thu, 12 Jun 2014 19:56:13 GMT
+Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
+ <http://www.w3.org/ns/ldp#Resource>; rel="type"</pre></div>
+
+ <p>
+ Assuming the server successfully processes this request and assigns the URI
+ <code><http://example.org/netWorth/nw1/liabilities/l4></code> to the
+ newly created liability resource, at least two new triples would be added.
+ </p>
+ <ol>
+ <li>In the net worth resource, <code><http://example.org/netWorth/nw1> o:liability <liabilities/l4></code></li>
+ <li>In the liability container, <code><http://example.org/netWorth/nw1/liabilities/> ldp:contains <l4></code>.</li>
+ </ol>
+
+ <p>
+ You might wonder why we chose to create two new containers instead of making
+ <code>http://example.org/netWorth/nw1</code> itself a container.
+ A single net worth container would be a fine design if <code>http://example.org/netWorth/nw1</code>
+ had only assets or only liabilities (basically: only a single predicate to manage),
+ but since it has separate predicates for assets and liabilities an ambiguity arises:
+ it is unspecified whether a client's creation request (POST)
+ should add a new <code>o:asset</code> or <code>o:liability</code> triple.
+ Having separate <code>http://example.org/netWorth/nw1/assets/</code>
+ and <code>http://example.org/netWorth/nw1/liabilities/</code> containers
+ allows both assets and liabilities to be created
+ and linked to the net-worth resource using the appropriate predicate. Similar ambiguities arise
+ if the client wishes to list the members and/or contained resources.
+ </p>
+
+ <p>Continuing in the multiple containers direction, we will now extend our net worth example to add 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>
+
+<em>Request</em> to <code>http://example.org/netWorth/nw1</code>:
+<div class="example"><div class="example-title"><span>Example 13</span></div><pre class="example" id="ldpc-ex-membership-full-elab-req">GET /netWorth/nw1 HTTP/1.1
+Host: example.org
+Accept: text/turtle</pre></div>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 14</span></div><pre class="example" id="ldpc-ex-membership-full-elab">HTTP/1.1 200 OK
+Content-Type: text/turtle
+Date: Thu, 12 Jun 2014 18:26:59 GMT
+ETag: "e8d129f45ca31848fb56213844a32b49"
+Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
+ <http://www.w3.org/ns/ldp#Resource>; rel="type"
+Allow: GET,OPTIONS,HEAD,PUT,DELETE
+Transfer-Encoding: chunked
+
+<!-- @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#>.
+
+<http://example.org/netWorth/nw1>
+ a o:NetWorth;
+ o:netWorthOf <http://example.org/users/JohnZSmith>;
+ o:advisor
+ <advisors/bob#me>, # URI of a person
+ <advisors/marsha#me>.
+
+<advisors/>
+ a ldp:IndirectContainer;
+ dcterms:title "The asset advisors of JohnZSmith";
+ ldp:membershipResource <>;
+ ldp:hasMemberRelation o:advisor;
+ ldp:insertedContentRelation foaf:primaryTopic;
+ ldp:contains
+ <bob>, # URI of a document a.k.a. an information resource
+ <marsha>. # describing a person</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 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 a member any resource,
+ including a URI representing a real-world object. Create requests to
+ <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Containers</a>
+ can only add information resources [<cite><a class="bibref" href="#bib-WEBARCH">WEBARCH</a></cite>] - the documents they create - as members.
+ </p>
+
+ <p>
+ To add a another advisor, a client would POST something like this to the advisors container:
+ </p>
+<em>Request</em> to <code>http://example.org/netWorth/nw1/advisors/</code>:
+<div class="example"><div class="example-title"><span>Example 15</span></div><pre class="example" id="ldpc-ex-membership-add-new-advisor-req">POST /netWorth/nw1/advisors/ HTTP/1.1
+Host: example.org
+Accept: text/turtle
+Content-Type: text/turtle
+Slug: george
+Content-Length: 72
+
+<!-- @base <http://example.org/netWorth/nw1/advisors/george>. -->
+
+@prefix foaf: <http://xmlns.com/foaf/0.1/>.
+@prefix o: <http://example.org/ontology#>.
+<>
+ a o:Advisor;
+ foaf:primaryTopic <#me>.
+ # plus any other properties that the domain says advisors have</pre></div>
+
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 16</span></div><pre class="example" id="ldpc-ex-membership-add-new-advisor">HTTP/1.1 201 Created
+Location: http://example.org/netWorth/nw1/advisors/george
+Date: Thu, 12 Jun 2014 19:56:13 GMT
+Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type",
+ <http://www.w3.org/ns/ldp#Resource>; rel="type"</pre></div>
+
+ <p>
+ Assuming the server successfully processes this request and assigns the URI
+ <code><http://example.org/netWorth/nw1/advisors/george></code> to the
+ newly created advisor resource, at least two new triples would be added.
+ </p>
+ <ol>
+ <li>In the net worth resource, <code><http://example.org/netWorth/nw1> o:advisor <advisors/george#me></code></li>
+ <li>In the advisors container, <code><http://example.org/netWorth/nw1/advisors/> ldp:contains <george></code></li>
+ </ol>
+
+ <p>In summary, <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 LDP-defined container types: Basic, Direct, and Indirect, 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 style="background:#FFFFFF;" 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_minimal-container_props" typeof="bibo:Chapter" resource="#ldpc-get_minimal-container_props" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpc-get_minimal-container_props"><span class="secno">5.1.1 </span>Retrieving Only Minimal-Container Triples
+ </h4>
+<!-- Was 5.1.1 / #ldpc-get_minimal-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="Minimal-container triples" href="#dfn-minimal-container-triples" class="internalDFN">minimal-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 minimal-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 minimal-container triples of a
+ container identified by the URL <code>http://example.org/container1/</code>.
+ </p>
+<p id="ldpc-ex-minimal-container"><em>Request</em> to <code>http://example.org/container1/</code>:</p>
+<div class="example"><div class="example-title"><span>Example 17</span></div><pre class="example">GET /container1/ HTTP/1.1
+Host: example.org
+Accept: text/turtle
+Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer"</pre></div>
+<p><em>Response:</em></p>
+<div class="example"><div class="example-title"><span>Example 18</span></div><pre class="example">HTTP/1.1 200 OK
+Content-Type: text/turtle
+ETag: "_87e52ce291112"
+Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
+ <http://www.w3.org/ns/ldp#Resource>; rel="type"
+Accept-Post: text/turtle, application/ld+json
+Allow: POST,GET,OPTIONS,HEAD
+Preference-Applied: return=representation
+Transfer-Encoding: chunked
+
+@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_minimal-container_props -->
+
+
+</section>
+
+<section id="ldpc-container" typeof="bibo:Chapter" resource="#ldpc-container" 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="#ldpc-general" 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="#ldpc-isldpr" 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: one
+ whose subject is the <a title="Linked Data Platform Container" href="#dfn-linked-data-platform-container" class="internalDFN"><abbr title="Linked Data Platform Container">LDPC</abbr></a>,
+ whose predicate is <code>rdf:type</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="#ldpc-typecontainer" 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 a <abbr title="Linked Data Platform Container">LDPC</abbr> <em class="rfc2119" title="MAY">MAY</em> have an <code>rdf:type</code>
+ 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="#ldpc-nordfcontainertypes" 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="#ldpc-linktypehdr" 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="#ldpc-prefer" 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 a <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="#ldpc-HTTP_GET" 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="#ldpc-HTTP_POST" 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-RFC7231">RFC7231</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 a 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="#ldpc-post-created201" 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="#ldpc-post-createdmbr-contains" 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 a <abbr title="Linked Data Platform Container">LDPC</abbr> results in the creation of a <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 the <abbr title="Linked Data Platform Container">LDPC</abbr>
+ 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>). Other triples may be added as well.
+ 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.
+ </h5></section>
+
+ <section id="ldpc-post-createbins" typeof="bibo:Chapter" resource="#ldpc-post-createbins" 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 a <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="#ldpc-post-createrdf" 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).
+ If any requested interaction 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 specifies <a href="#ldpr-gen-linktypehdr">a <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 a <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 specifies <a href="#ldpc-linktypehdr">a <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 a <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="#ldpc-post-turtle" 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="#ldpc-post-contenttype" 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="#ldpc-post-rdfnullrel" 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 identifying 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 result in
+ triples in the created resource whose subject is the created
+ resource.
+ </h5></section>
+<!-- Was 5.4.7 / #ldpc-5_4_7 -->
+
+
+<!-- TODO: add link to "relative URIs on post-create are dangerous" -->
+
+
+ <section id="ldpc-post-serverassignuri" typeof="bibo:Chapter" resource="#ldpc-post-serverassignuri" 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="#ldpc-post-mincontraints" 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="#ldpc-post-slug" 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="#ldpc-post-dontreuseuris" 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="#ldpc-post-createbinlinkmetahdr" 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 a LDP 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="#ldpc-post-acceptposthdr" 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 <code>POST</code> request 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 a 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 id="ldpc-post-jsonld" typeof="bibo:Chapter" resource="#ldpc-post-jsonld" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-post-jsonld"><span class="secno">5.2.3.14 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="SHOULD">SHOULD</em> accept a request entity body with a request header
+ of <code>Content-Type</code> with value of <code>application/ld+json</code> [<cite><a class="bibref" href="#bib-JSON-LD">JSON-LD</a></cite>].
+ </h5></section>
+<!-- new -->
+
+
+</section>
+
+<section id="ldpc-HTTP_PUT" typeof="bibo:Chapter" resource="#ldpc-HTTP_PUT" 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-RFC7231">RFC7231</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 a 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="#ldpc-put-mbrprops" 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 a <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="#ldpc-put-create" 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.
+ </h5></section>
+<!-- Was 5.5.4 / #ldpc-5_5_4 -->
+
+
+</section>
+
+<section id="ldpc-HTTP_DELETE" typeof="bibo:Chapter" resource="#ldpc-HTTP_DELETE" 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-RFC7231">RFC7231</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 a 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="#ldpc-del-contremovesconttriple" 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 a <a title="containment" href="#dfn-containment" class="internalDFN">contained <abbr title="Linked Data Platform Resource">LDPR</abbr></a> is deleted, the <abbr title="Linked Data Platform Container">LDPC</abbr> server <em class="rfc2119" title="MUST">MUST</em> also remove
+ the corresponding containment triple, which has the effect of removing the deleted <abbr title="Linked Data Platform Resource">LDPR</abbr> from the containing <abbr title="Linked Data Platform Container">LDPC</abbr>.
+ </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-RFC7231">RFC7231</a></cite>].
+ For example, the server could remove membership triples referring to the deleted <abbr title="Linked Data Platform Resource">LDPR</abbr>,
+ perform additional cleanup tasks for resources it knows are no longer referenced or have not
+ been accessed for some period of time, and so on.
+ </blockquote>
+ </section>
+<!-- Was 5.6.1 / #ldpc-5_6_1 -->
+
+
+ <section id="ldpc-del-contremovescontres" typeof="bibo:Chapter" resource="#ldpc-del-contremovescontres" 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 a <a title="containment triples" href="#dfn-containment-triples" class="internalDFN">contained <abbr title="Linked Data Platform Resource">LDPR</abbr></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 delete 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="#ldpc-HTTP_HEAD" 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 recommends that
+ <code>HEAD</code> responses include the same headers as <code>GET</code> responses.
+ <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> must also include HTTP headers
+ on responses 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="#ldpc-HTTP_PATCH" 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-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 a 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="#ldpc-patch-req" 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 a <abbr title="Linked Data Platform Container">LDPC</abbr>'s <a title="Minimal-container triples" href="#dfn-minimal-container-triples" class="internalDFN">minimal-container triples</a>.
+ </h5></section>
+<!-- Was 5.8.1 / #ldpc-5_8_1 -->
+
+</section>
+
+<section id="ldpc-HTTP_OPTIONS" typeof="bibo:Chapter" resource="#ldpc-HTTP_OPTIONS" 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>.
+ Note that support for this method is required for <abbr title="Linked Data Platform Containers">LDPCs</abbr>, since <a href="#ldpr-HTTP_OPTIONS">it is required for <abbr title="Linked Data Platform Resources">LDPRs</abbr></a> and
+ <a href="#ldpc-isldpr"><abbr title="Linked Data Platform Containers">LDPCs</abbr> adhere to <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> requirements</a>.
+ </p>
+
+ <section id="ldpc-options-linkmetahdr" typeof="bibo:Chapter" resource="#ldpc-options-linkmetahdr" 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 responding to requests whose <code>request-URI</code> is a
+ <a href="#ldpc-post-createbinlinkmetahdr"><abbr title="Linked Data Platform Non-RDF Source">LDP-NR</abbr> with an associated <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr></a>,
+ a <abbr title="Linked Data Platform Container">LDPC</abbr> server <em class="rfc2119" title="MUST">MUST</em> provide the same HTTP <code>Link</code>
+ response header as is <a href="#ldpc-post-createbinlinkmetahdr">required in the create response</a>.
+ </h5></section>
+<!-- Was 5.9.2 / #ldpc-5_9_2 -->
+
+</section>
+<!-- h2 -->
+
+</section>
+<!-- ldpc-container -->
+
+
+<section id="ldpbc" typeof="bibo:Chapter" resource="#ldpbc" 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="#ldpbc-general" 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="#ldpbc-are-ldpcs" 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 with 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 the <a title="Linked Data Platform Basic Container" href="#dfn-linked-data-platform-basic-container" class="internalDFN">LDP Basic Container</a>,
+ whose predicate is <code>rdf:type</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="#ldpdc" 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="#ldpdc-general" 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="#ldpdc-are-ldpcs" 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 the <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Container</a>,
+ whose predicate is <code>rdf:type</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="#ldpdc-mbrpred" 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 a <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 a <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="#ldpdc-containres" 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="#ldpdc-containtriples" 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="#ldpdc-containtriple-relation" 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="#ldpdc-containtriple-byrelation" 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 <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="#ldpdc-indirectmbr-basic" 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="#ldpdc-HTTP_POST" 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="#ldpdc-post-createdmbr-member" 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 a <abbr title="Linked Data Platform Container">LDPC</abbr> results in the creation of a <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="#ldpdc-HTTP_DELETE" 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="#ldpdc-del-contremovesmbrtriple" 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 a <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="#ldpic" 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="#ldpic-general" 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="#ldpic-are-ldpcs" 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> as described in <a href="#ldpdc" class="sectionRef sec-ref">section <span class="secno">5.4</span> <span class="sec-title">Direct</span></a>, along with 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: one
+ whose subject is <a title="Linked Data Platform Indirect Container" href="#dfn-linked-data-platform-indirect-container" class="internalDFN">LDP Indirect Container</a>,
+ whose predicate is <code>rdf:type</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="#ldpic-indirectmbr" 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="#ldpic-HTTP_POST" 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="#ldpic-post-indirectmbrrel" 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="#base-specs" 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="#specs-webarch" 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="#ldp-webarch-nonexcl-membership" 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="#ldp-webarch-uri-reuse" 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 a <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="#specs-http" 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-RFC7230">RFC7230</a></cite>], [<cite><a class="bibref" href="#bib-RFC7231">RFC7231</a></cite>], [<cite><a class="bibref" href="#bib-RFC7232">RFC7232</a></cite>]
+
+ <section id="ldp-http-other-representations" typeof="bibo:Chapter" resource="#ldp-http-other-representations" 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-RFC7231">RFC7231</a></cite>] Section 3.4 - Content Negotiation) is used to select the format.
+ </h4></section>
+
+ <section id="ldp-http-other-methods" typeof="bibo:Chapter" resource="#ldp-http-other-methods" 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="#ldp-http-delete-uri-reuse" 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="#ldp-http-method-side-effects" 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-RFC7231">RFC7231</a></cite>] section 4.2.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="#ldp-http-patch-allowed" 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="#ldp-http-content-sniffing" 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-RFC7231">RFC7231</a></cite>] section 3.1.1.5).
+ </h4></section>
+
+</section>
+
+<section id="specs-rdf" class="informative" typeof="bibo:Chapter" resource="#specs-rdf" 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="#ldp-rdfconcepts-extra-triples-any" 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 a <abbr title="Linked Data Platform Resource">LDPR</abbr>
+ can have triples with any subject(s). The URL used to retrieve the
+ representation of a <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="#ldp-rdfconcepts-extra-triples-members" 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 a <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="#ldp-rdfconcepts-extra-triples-types" 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 a <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="#header-accept-post" 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> [<cite><a class="bibref" href="#bib-Accept-Post">Accept-Post</a></cite>]
+ 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 status, 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="#header-accept-post-1" 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 1.2 of [<cite><a class="bibref" href="#bib-RFC7231">RFC7231</a></cite>], is:</h4>
+ <blockquote><code>Accept-Post = "Accept-Post" ":" # media-range </code>
+ <p>
+ The <code>Accept-Post</code> header specifies a comma-separated list of media
+ ranges (with optional parameters) as defined by [<cite><a class="bibref" href="#bib-RFC7231">RFC7231</a></cite>], Section 5.3.2.
+ The <code>Accept-Post</code> header, in effect, uses the same syntax as the
+ HTTP <code>Accept</code> header minus the optional <code>accept-params</code> BNF production,
+ since the latter does not apply to <code>Accept-Post</code>.
+ </p>
+ </blockquote>
+ </section>
+<!-- Was 6.1.1 / #header-accept-post-1 -->
+
+
+ <section id="header-accept-post-2" typeof="bibo:Chapter" resource="#header-accept-post-2" 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="#header-accept-post-iana" 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="#prefer-parameters" 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="#prefer-summary" rel="bibo:Chapter">
+<h4 aria-level="3" role="heading" id="h4_prefer-summary"><span class="secno">7.2.1 </span>Summary</h4>
+
+ <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-RFC7240">RFC7240</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-RFC7240">RFC7240</a></cite>].
+ </p>
+
+ <p>
+ Non-normative note: [<cite><a class="bibref" href="#bib-RFC7240">RFC7240</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="#prefer-rules" 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="#prefer-include" 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 a <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-RFC7240">RFC7240</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-RFC7240">RFC7240</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="#prefer-omit" 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 a <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-RFC7240">RFC7240</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="#prefer-conflicts" 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-RFC7240">RFC7240</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="#prefer-uris" 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 rowspan="3"> <a title="Minimal-container triples" href="#dfn-minimal-container-triples" class="internalDFN">Minimal-container triples</a>
+ </td>
+ <td> <code>http://www.w3.org/ns/ldp#PreferMinimalContainer</code> </td>
+ </tr>
+ <tr>
+ <td> or the equivalent but deprecated term </td>
+ </tr>
+ <tr>
+ <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="#prefer-examples" 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 19</span></div><pre class="example" id="prefer-examples-direct"># The following is the representation of
+# http://example.org/netWorth/nw1/assets/
+
+<!-- @base is here only so it's easier to paste into validators for checking -->
+
+# @base <http://example.org/netWorth/nw1/assets/>.
+@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-minimal-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#PreferMinimalContainer"</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>
+
+<em>Request</em> to <code>http://example.org/netWorth/nw1/assets/</code>:
+<div class="example"><div class="example-title"><span>Example 20</span></div><pre class="example">GET /netWorth/nw1/assets/ HTTP/1.1
+Host: example.org
+Accept: text/turtle
+Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer"</pre></div>
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 21</span></div><pre class="example">HTTP/1.1 200 OK
+Content-Type: text/turtle
+ETag: "_87e52ce291112"
+Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
+ <http://www.w3.org/ns/ldp#Resource>; rel="type"
+Accept-Post: text/turtle, application/ld+json
+Allow: POST,GET,OPTIONS,HEAD
+Preference-Applied: return=representation
+Transfer-Encoding: chunked
+
+<!-- @base <http://example.org/netWorth/nw1/assets/>. -->
+
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix o: <http://example.org/ontology#>.
+
+<http://example.org/netWorth/nw1/assets/>
+ 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-minimal-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="Minimal-container triples" href="#dfn-minimal-container-triples" class="internalDFN">minimal-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>
+
+<em>Request</em> to <code>http://example.org/netWorth/nw1/assets/</code>:
+<div class="example"><div class="example-title"><span>Example 22</span></div><pre class="example">GET /netWorth/nw1/assets/ HTTP/1.1
+Host: example.org
+Accept: text/turtle
+Prefer: return=representation; omit="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferContainment"</pre></div>
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 23</span></div><pre class="example">HTTP/1.1 200 OK
+Content-Type: text/turtle
+ETag: "_87e52ce291112"
+Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
+ <http://www.w3.org/ns/ldp#Resource>; rel="type"
+Accept-Post: text/turtle, application/ld+json
+Allow: POST,GET,OPTIONS,HEAD
+Preference-Applied: return=representation
+Transfer-Encoding: chunked
+
+<!-- @base <http://example.org/netWorth/nw1/assets/>. -->
+
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix o: <http://example.org/ontology#>.
+
+<http://example.org/netWorth/nw1/assets/>
+ 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#PreferMinimalContainer"</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-RFC7231">RFC7231</a></cite>]).
+ </p>
+
+<em>Request</em> to <code>http://example.org/netWorth/nw1/assets/</code>:
+<div class="example"><div class="example-title"><span>Example 24</span></div><pre class="example">GET /netWorth/nw1/assets/ HTTP/1.1
+Host: example.org
+Accept: text/turtle
+Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferMinimalContainer"</pre></div>
+<em>Response:</em>
+<div class="example"><div class="example-title"><span>Example 25</span></div><pre class="example">HTTP/1.1 200 OK
+Content-Type: text/turtle
+ETag: "_87e52ce291112"
+Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
+ <http://www.w3.org/ns/ldp#Resource>; rel="type"
+Accept-Post: text/turtle, application/ld+json
+Allow: POST,GET,OPTIONS,HEAD
+Preference-Applied: return=representation
+Transfer-Encoding: chunked
+
+<!-- @base <http://example.org/netWorth/nw1/assets/>. -->
+
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix o: <http://example.org/ontology#>.
+
+<http://example.org/netWorth/nw1/assets/>
+ 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 [[RFC7231]], [[!RFC2817]]).
+ </p>
+ <p>
+ Value: 209
+ </p>
+ <p>
+ Description: Related Content
+ </p>
+ <p>
+ Reference: this specification
+ </p>
+ </blockquote>
+ </div>
+
+</section>
+</section> -->
+
+
+<section id="link-relations" typeof="bibo:Chapter" resource="#link-relations" rel="bibo:Chapter">
+
+<!--OddPage-->
+<h2 aria-level="1" role="heading" id="h2_link-relations"><span class="secno">8. </span>Link Relations</h2>
+<p>
+ The intent is that these link relations will be registered with IANA per [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>] section 6.2.1.
+</p>
+<section id="link-relation-describedby" typeof="bibo:Chapter" resource="#link-relation-describedby" rel="bibo:Chapter">
+<h3 aria-level="2" role="heading" id="h3_link-relation-describedby"><span class="secno">8.1 </span>describedby</h3>
+<p>
+ The contents of this section were originally taken from [<cite><a class="bibref" href="#bib-POWDER">POWDER</a></cite>] appendix D, and then modified to comply with the current registration template.
+ The pre-LDP IANA link relation registry entry for
+ <code>describedby</code> refers to a different section of [<cite><a class="bibref" href="#bib-POWDER">POWDER</a></cite>] that was substantively updated in
+ <a href="http://www.w3.org/2007/powder/powder-errata#describedby">an erratum</a>, and that section was not
+ actually the normative definition of the link relation. Since we expect no update to [<cite><a class="bibref" href="#bib-POWDER">POWDER</a></cite>] that incorporates the erratum
+ or fixes the registry link, this superseding registration approach is being taken.
+</p>
+<p>The following Link Relationship will be submitted to IANA for review, approval, and inclusion in the IANA Link Relations registry.</p>
+<dl>
+<dt>Relation Name:</dt>
+<dd><code>describedby</code></dd>
+<dt>Description:</dt>
+<dd>
+The relationship <code>A describedby B</code> asserts that resource B provides a description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource.
+</dd>
+<dt>Reference:</dt>
+<dd>
+ The <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/TR/ldp/">Linked Data Platform specification</a>.
+</dd>
+<dt>Notes:</dt>
+<dd>
+ Descriptions of resources may be socially sensitive, may require processing to be understood and may or may not not be accurate. Consumers of descriptive resources should be aware of the source and chain of custody of the data. Security considerations for URIs (Section 7 of RFC 3986) and IRIs (Section 8 of RFC 3987) apply to the extent that describing resources may affect consumers' decisions about how or whether to retrieve those resources.
+</dd>
+</dl>
+</section>
+</section>
+
+<section class="informative" id="security" typeof="bibo:Chapter" resource="#security" rel="bibo:Chapter">
+
+<!--OddPage-->
+<h2 aria-level="1" role="heading" id="h2_security"><span class="secno">9. </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="#history" 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>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>
+
+<h2 id="summary">Summary</h2>
+<p>Summary of notable changes from the <a href="http://www.w3.org/TR/2013/WD-ldp-20140311/">previous public working draft</a>.</p>
+<ul>
+ <li>Resolved Last Call 2 comments</li>
+ <li>Removed references to <abbr title="Resource Description Framework">RDF</abbr> named graphs</li>
+ <li>Rename empty-container triples to minimal-container triples</li>
+ <li>Duplication (with intent to supersede) of the <code>describedby</code> relation type IANA registration, incorporating POWDER's relevant errata</li>
+ <li>Clarify definitions of membership and containment triples to avoid impression that they must be (stored as) part of the <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>'s state.</li>
+ <li>Servers should offer/accept JSON-LD representations of LDP-RSs</li>
+ <li>Updated all HTTP and Prefer-draft references to newly assigned RFC numbers, with associated BNF hits</li>
+</ul>
+</section>
+
+
+<section id="references" class="appendix" typeof="bibo:Chapter" resource="#references" 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="#normative-references" 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-JSON-LD">[JSON-LD]</dt><dd rel="dcterms:requires">Manu Sporny; Gregg Kellogg; Markus Lanthaler. <a href="http://www.w3.org/TR/json-ld/"><cite>JSON-LD 1.0</cite></a>. 16 January 2014. W3C Recommendation. URL: <a href="http://www.w3.org/TR/json-ld/">http://www.w3.org/TR/json-ld/</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-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. Best Current Practice. 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. Best Current Practice. 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</cite></a>. January 2005. Internet Standard. 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. Duerst; M. Suignard. <a href="http://www.ietf.org/rfc/rfc3987.txt"><cite>Internationalized Resource Identifiers (IRIs)</cite></a>. January 2005. Proposed Standard. 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, Ed.; B. de hOra, Ed.. <a href="http://www.ietf.org/rfc/rfc5023.txt"><cite>The Atom Publishing Protocol</cite></a>. October 2007. Proposed Standard. 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, Ed.; P. Overell. <a href="http://www.ietf.org/rfc/rfc5234.txt"><cite>Augmented BNF for Syntax Specifications: ABNF</cite></a>. January 2008. Internet Standard. 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://www.ietf.org/rfc/rfc5789.txt"><cite>PATCH Method for HTTP</cite></a>. March 2010. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc5789.txt">http://www.ietf.org/rfc/rfc5789.txt</a>
+</dd><dt id="bib-RFC5988">[RFC5988]</dt><dd rel="dcterms:requires">M. Nottingham. <a href="http://www.ietf.org/rfc/rfc5988.txt"><cite>Web Linking</cite></a>. October 2010. Proposed Standard. 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. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc6585.txt">http://www.ietf.org/rfc/rfc6585.txt</a>
+</dd><dt id="bib-RFC7230">[RFC7230]</dt><dd rel="dcterms:requires">R. Fielding; J. Reschke. <a href="http://tools.ietf.org/html/rfc7230"><cite>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</cite></a>. Proposed Standard. URL: <a href="http://tools.ietf.org/html/rfc7230">http://tools.ietf.org/html/rfc7230</a>
+</dd><dt id="bib-RFC7231">[RFC7231]</dt><dd rel="dcterms:requires">R. Fielding; J. Reschke. <a href="http://tools.ietf.org/html/rfc7231"><cite>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</cite></a>. Proposed Standard. URL: <a href="http://tools.ietf.org/html/rfc7231">http://tools.ietf.org/html/rfc7231</a>
+</dd><dt id="bib-RFC7232">[RFC7232]</dt><dd rel="dcterms:requires">R. Fielding; J. Reschke. <a href="http://tools.ietf.org/html/rfc7232"><cite>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</cite></a>. Proposed Standard. URL: <a href="http://tools.ietf.org/html/rfc7232">http://tools.ietf.org/html/rfc7232</a>
+</dd><dt id="bib-RFC7240">[RFC7240]</dt><dd rel="dcterms:requires">J. Snell. <a href="http://tools.ietf.org/html/rfc7240"><cite>Prefer Header for HTTP</cite></a>. Proposed Standard. URL: <a href="http://tools.ietf.org/html/rfc7240">http://tools.ietf.org/html/rfc7240</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>. 25 February 2014. W3C 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>. 25 February 2014. W3C 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>. 25 February 2014. W3C 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="#informative-references" 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-Accept-Post">[Accept-Post]</dt><dd rel="dcterms:references">J. Arwe; S. Speicher; E. Wilde. <a href="http://tools.ietf.org/html/draft-wilde-accept-post"><cite>The Accept-Post HTTP Header</cite></a>. Internet Draft. URL: <a href="http://tools.ietf.org/html/draft-wilde-accept-post">http:tools.ietf.org/html/draft-wilde-accept-post</a>
+</dd><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-LDP-Tests">[LDP-Tests]</dt><dd rel="dcterms:references">R. Garcia-Castro; F. Serena. <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-testsuite.html"><cite>Linked Data Platform 1.0 Test Cases</cite></a>. Editor's Draft of Working Group Note. URL: <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-testsuite.html">https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-testsuite.html</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>. 13 March 2014. W3C Note. 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-POWDER">[POWDER]</dt><dd rel="dcterms:references">Phil Archer; Kevin Smith; Andrea Perego. <a href="http://www.w3.org/TR/2009/REC-powder-dr-20090901/"><cite>Protocol for Web Description Resources (POWDER): Description Resources</cite></a>. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2009/REC-powder-dr-20090901/">http://www.w3.org/TR/2009/REC-powder-dr-20090901/</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)</cite></a>. July 2006. Informational. 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/CR-ldp-20140619/images/ldpc-basic.png has changed
Binary file TR/CR-ldp-20140619/images/ldpc-hierarchy.png has changed
Binary file TR/CR-ldp-20140619/images/ldpc1.png has changed
Binary file TR/CR-ldp-20140619/images/ldpr1.png has changed
Binary file TR/CR-ldp-20140619/images/ldpr2.png has changed
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/TR/CR-ldp-20140619/ldp.ttl Mon Jun 16 13:53:33 2014 -0400
@@ -0,0 +1,174 @@
+# 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 "Archaic alias for ldp:PreferMinimalContainer";
+ vs:term_status "deprecated";
+ rdfs:isDefinedBy :;
+ rdfs:sameAs :PreferMinimalContainer;
+ rdfs:seeAlso :PreferMinimalContainer;
+ rdfs:label "PreferEmptyContainer".
+
+:PreferMinimalContainer
+ 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 "PreferMinimalContainer".
+
\ No newline at end of file
--- a/TR/WD-ldp-20140619/Overview.html Mon Jun 16 13:43:01 2014 -0400
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,2936 +0,0 @@
-<!DOCTYPE html>
-<html lang="en" dir="ltr" typeof="bibo:Document w3p:CR" about="" property="dcterms:language" content="en" prefix="bibo: http://purl.org/ontology/bibo/ w3p: http://www.w3.org/2001/02pd/rec54#" xmlns="http://www.w3.org/1999/xhtml">
-<head>
- <title>Linked Data Platform 1.0</title>
- <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
-
-<!--
- === NOTA BENE ===
- For the three scripts below, if your spec resides on dev.w3 you can check them
- out in the same tree and use relative links so that they'll work offline,
- -->
-
-
-
- <style type="text/css">
- div.rule {padding-top: 1em;}
- div.ldp-issue-open {
- border-color: #E05252;
- background: #FBE9E9;
- padding: 0.5em;
- margin: 1em 0;
- position: relative;
- clear: both;
- border-left-width: .5em;
- border-left-style: solid;
- }
- div.ldp-issue-pending {
- border-color: #FAF602;
- background: #F7F6BC;
- padding: 0.5em;
- margin: 1em 0;
- position: relative;
- clear: both;
- border-left-width: .5em;
- border-left-style: solid;
- }
- div.ldp-issue-closed {
- border-color: #009900;
- background: #BCF7CF;
- padding: 0.5em;
- margin: 1em 0;
- position: relative;
- clear: both;
- border-left-width: .5em;
- border-left-style: solid;
- }
- div.ldp-issue-title {
- color: #E05252;
- padding-right: 1em;
- min-width: 7.5em;
- }
- .atrisk {
- padding: 1em;
- margin: 1em 0em 0em;
- border: 1px solid #f00;
- background: #ffc;
- }
- .atrisktext {
- /* content: "Feature At Risk"; */
- display: block;
- width: 150px;
- margin: -1.5em 0 0.5em 0;
- font-weight: bold;
- border: 1px solid #f00;
- background: #fff;
- padding: 3px 1em;
- }
- .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-CR" />
-<!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]-->
-</head>
-<body class="h-entry" role="document" id="respecDocument"><div class="head" role="contentinfo" id="respecHeader">
- <p>
-
- <a href="http://www.w3.org/"><img width="72" height="48" src="https://www.w3.org/Icons/w3c_home" alt="W3C" /></a>
-
- </p>
- <h1 class="title p-name" id="title" property="dcterms:title">Linked Data Platform 1.0</h1>
-
- <h2 property="dcterms:issued" datatype="xsd:dateTime" content="2014-06-19T21:24:25.000Z" id="w3c-candidate-recommendation-19-june-2014"><abbr title="World Wide Web Consortium">W3C</abbr> Candidate Recommendation <time class="dt-published" datetime="2014-06-19">19 June 2014</time></h2>
- <dl>
-
- <dt>This version:</dt>
- <dd><a class="u-url" href="http://www.w3.org/TR/2014/CR-ldp-20140619/">http://www.w3.org/TR/2014/CR-ldp-20140619/</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>Test suite:</dt>
- <dd><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-testsuite.html">https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-testsuite.html</a></dd>
-
-
- <dt>Implementation report:</dt>
- <dd><a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/reports/ldp.html">https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/reports/ldp.html</a></dd>
-
-
-
-
- <dt>Previous version:</dt>
- <dd><a rel="dcterms:replaces" href="http://www.w3.org/TR/2014/WD-ldp-20140311/">http://www.w3.org/TR/2014/WD-ldp-20140311/</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.
-
- <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
- <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
-
- <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
-
- rules apply.
- </p>
-
-
- <hr />
-</div>
-<section id="abstract" class="introductory" property="dcterms:abstract" datatype="" typeof="bibo:Chapter" resource="#abstract" rel="bibo:Chapter"><h2 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="#sotd" 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 Candidate Recommendation document where the Working Group has addressed all
- raised issues and seeks to gather implementation feedback. For changes since last publication, see <a href="#history" class="sectionRef sec-ref">section <span class="secno">B.</span> <span class="sec-title">Change History</span></a>.
- A test suite is available at [<cite><a class="bibref" href="#bib-LDP-Tests">LDP-Tests</a></cite>].
- </p>
- <p>The following features are At Risk:</p>
- <ol>
- <li>The <a href="#header-accept-post">HTTP Accept-Post header</a>,
- that allows clients to determine which media types a server accepts on POST requests.
- </li>
- <li>The requirement that LDP clients be <a href="#atrisk-paging">paging-aware</a>.
- </li>
- </ol>
-
- <p>
- This document was published by the <a href="http://www.w3.org/2012/ldp">Linked Data Platform Working Group</a> as a Candidate Recommendation.
-
- 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>).
-
-
-
- <abbr title="World Wide Web Consortium">W3C</abbr> publishes a Candidate Recommendation to indicate that the document is believed to be
- stable and to encourage implementation by the developer community. This Candidate
- Recommendation is expected to advance to Proposed Recommendation no earlier than
- 17 July 2014.
-
-
- All comments are welcome.
-
- </p>
-
- <p>
- Please see the Working Group's <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/reports/ldp.html">implementation
- report</a>.
- </p>
-
-
- <p>
- Publication as a Candidate Recommendation 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 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="#link-relations" class="tocxref"><span class="secno">8. </span>Link Relations</a><ul class="toc"><li class="tocline"><a href="#link-relation-describedby" class="tocxref"><span class="secno">8.1 </span>describedby</a></li></ul></li><li class="tocline"><a href="#security" class="tocxref"><span class="secno">9. </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="#intro" 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 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="#terms" 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-RFC7230">RFC7230</a></cite>], [<cite><a class="bibref" href="#bib-RFC7231">RFC7231</a></cite>], [<cite><a class="bibref" href="#bib-RFC7232">RFC7232</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 one or more HTTP requests [<cite><a class="bibref" href="#bib-RFC7230">RFC7230</a></cite>].<p></p></dd>
-
- <dt>Server</dt>
- <dd>A program that accepts connections in order to service HTTP requests by sending HTTP responses.
- <p>
- The terms "client" and "server" refer only to the roles that these programs perform for a particular connection.
- The same program might act as a client on some connections and a server on others.
- </p>
- <p>
- HTTP enables the use of intermediaries to satisfy requests through a
- chain of connections. There are three common forms of HTTP
- intermediary: proxy, gateway, and tunnel. In some cases, a single
- intermediary might act as an origin server, proxy, gateway, or
- tunnel, switching behavior based on the nature of each request.
- [<cite><a class="bibref" href="#bib-RFC7230">RFC7230</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> graph. 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>.
- For example, these can be 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>A <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> that adds the concept of <a title="Membership" href="#dfn-membership" class="internalDFN">membership</a>, allowing 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> 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>
- that is also 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 Container">LDPC</abbr> and its member <abbr title="Linked Data Platform Resources">LDPRs</abbr>,
- which can be different resources than its <a title="Containment" href="#dfn-containment" class="internalDFN">contained</a> documents.
- The <abbr title="Linked Data Platform Container">LDPC</abbr> often assists with managing the membership triples, whether or not the <abbr title="Linked Data Platform Container">LDPC</abbr>'s
- URI occurs in them.
- <p></p></dd>
-
- <dt><dfn id="dfn-membership-triples">Membership triples</dfn></dt>
- <dd>A set of triples that lists an <abbr title="Linked Data Platform Container">LDPC</abbr>'s members.
- A <abbr title="Linked Data Platform Container">LDPC</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 Container">LDPC</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, 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-minimal-container-triples">Minimal-container triples</dfn></dt>
- <dd>
- The portion of an <abbr title="Linked Data Platform Container">LDPC</abbr>'s triples 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 (if either are considered part of its state),
- 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="#conventions" 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="#conformance" 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-RFC7230">RFC7230</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-RFC7230">RFC7230</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="#ldpr" 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="#ldpr-informative" 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>How can the server make it easy for the client to create resources?</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>A LDP server can manage 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 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="#ldpr-resource" 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="#ldpr-general" 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="#ldpr-gen-http" 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-RFC7230">RFC7230</a></cite>].
- </h5></section>
-<!-- Was 4.2.1 / #ldpr-4_2_1 -->
-
-
- <section id="ldpr-gen-binary" typeof="bibo:Chapter" resource="#ldpr-gen-binary" 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 <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="#ldpr-gen-etags" 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, for responses that contain resource representations or
- successful responses to HTTP <code>HEAD</code> requests.
- </h5></section>
-<!-- Was 4.2.8 / #ldpr-4_2_8 -->
-
-
- <section id="ldpr-gen-linktypehdr" typeof="bibo:Chapter" resource="#ldpr-gen-linktypehdr" 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 an <abbr title="Linked Data Platform Resource">LDPR</abbr>'s HTTP <code>Request-URI</code> [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>].
- </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 the 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="#ldpr-options-must">supports OPTIONS</a>, and so on,
- which is not true of all Web resources.
- </p>
- <p>
- Note:
- <a href="#ldpr-gen-binary">A LDP server can host a mixture of LDP-RSs and LDP-NRs</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="#ldpr-gen-defbaseuri" 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="#ldpr-gen-pubclireqs" 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="#ldpr-HTTP_GET" 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="#ldpr-get-must" 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="#ldpr-get-options" 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="#ldpr-HTTP_POST" 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-RFC7231">RFC7231</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 a 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 a <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="#ldpr-HTTP_PUT" 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-RFC7231">RFC7231</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 a 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="#ldpr-put-replaceall" 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="#ldpr-put-simpleupdate" 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="#ldprs-put-servermanagedprops" 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>
- fail the request by responding 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-managed properties
- are identical on the GET response and the subsequent PUT request.
- This is in contrast to other cases like write-once properties that the server does not allow clients to modify once set;
- write-once properties are under client control, they are not <a href="#ldpr-put-replaceall">server-managed</a>.
- </blockquote>
-
- <section id="ldprs-put-failed" typeof="bibo:Chapter" resource="#ldprs-put-failed" 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-RFC7231">RFC7231</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="#ldpr-put-precond" 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-RFC7232">RFC7232</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="#ldpr-put-create" 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="#ldpr-HTTP_DELETE" 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-RFC7231">RFC7231</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 a LDP server supports this method,
- this specification imposes no new blanket requirements for <abbr title="Linked Data Platform Resources">LDPRs</abbr>.
- </p>
-
- <p>Additional requirements on HTTP <code>DELETE</code> for <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="#ldpr-HTTP_HEAD" 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="#ldpr-head-must" 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="#ldpr-HTTP_PATCH" 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 a 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="#ldpr-patch-acceptpatch" 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="#ldpr-HTTP_OPTIONS" 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-RFC7231">RFC7231</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="#ldpr-options-must" 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="#ldpr-options-allow" 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="#ldprs" 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="#ldprs-general" 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="#ldprs-are-ldpr" 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> as defined in <a href="#ldpr-resource" class="sectionRef sec-ref">section <span class="secno">4.2</span> <span class="sec-title">Resource</span></a>, along with the
- 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: one
- whose subject is the <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>,
- whose predicate is <code>rdf:type</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="#ldprs-gen-atleast1rdftype" 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="#ldprs-rdftype" 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 a <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> <em class="rfc2119" title="MAY">MAY</em> have an <code>rdf:type</code>
- 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="#ldprs-gen-rdf" 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="#ldprs-gen-reusevocab" 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="#ldprs-gen-reusevocabsuchas" 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="#ldp-cli-multitype" 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 <code>rdf:type</code> triples with different objects.
- </h5></section>
-<!-- Was 4.3.5 / #ldpr-4_3_5 -->
-
-
- <section id="ldpr-cli-typeschange" typeof="bibo:Chapter" resource="#ldpr-cli-typeschange" 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="#ldpr-cli-openpreds" 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="#ldprs-gen-noinferencing" 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="#ldpr-cli-preservetriples" 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 a <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="#ldpr-cli-can-hint" 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="#ldpr-cli-hints-ignorable" 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 a 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="#ldpr-cli-paging" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpr-cli-paging">
- <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 a 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="#ldprs-HTTP_GET" 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="#ldprs-get-turtle" 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> whenever HTTP content negotiation
- does not force another outcome [<cite><a class="bibref" href="#bib-turtle">turtle</a></cite>]. In other words, if the server receives a <code>GET</code> request whose <code>Request-URI</code>
- identifies a <a title="" href="#dfn-linked-data-platform-rdf-source" class="internalDFN"><abbr title="Linked Data Platform RDF Source">LDP-RS</abbr></a>, and either <code>text/turtle</code> has the highest relative quality
- factor (<code>q=</code> value) in the
- Accept request header or that header is absent, then an <a title="" href="#dfn-ldp-server" class="internalDFN">LDP server</a> has to respond with Turtle.
- </h5></section>
-<!-- Was 4.3.3 / #ldpr-4_3_3 -->
-
-
- <section id="ldprs-get-jsonld" typeof="bibo:Chapter" resource="#ldprs-get-jsonld" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldprs-get-jsonld"><span class="secno">4.3.2.2 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="SHOULD">SHOULD</em> offer a <code>application/ld+json</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-JSON-LD">JSON-LD</a></cite>].
- </h5></section>
-<!-- new -->
-
-
-</section>
-<!-- ldprs-HTTP_GET -->
-
-
-</section>
-<!-- ldprs RDF Source-->
-
-
-<section id="ldpnr" typeof="bibo:Chapter" resource="#ldpnr" 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="#ldpnr-general" 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="#ldpnr-are-ldpr" 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> Sources</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 id="ldpnr-type" typeof="bibo:Chapter" resource="#ldpnr-type" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpnr-type"><span class="secno">4.4.1.2 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> exposing an <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="MAY">MAY</em> advertise this by exposing a HTTP <code>Link</code> header
- with a target URI of <code>http://www.w3.org/ns/ldp#NonRDFSource</code>, and
- a link relation type of <code>type</code> (that is, <code>rel='type'</code>)
- in responses to requests made
- to the <abbr title="Linked Data Platform Non-RDF Source">LDP-NR</abbr>'s HTTP <code>Request-URI</code> [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>].
- </h5></section>
-
-</section>
-<!-- ldpnr Non-RDF Source-->
-
-
-</section>
-
-</section>
-<!-- ldpr h1 -->
-
-
-<section id="ldpc" typeof="bibo:Chapter" resource="#ldpc" 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="#ldpc-informative" 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>
-
-<em>Request</em> to <code>http://example.org/c1/</code>:
-<div class="example"><div class="example-title"><span>Example 1</span></div><pre class="example" id="ldpc-ex-simple-req">GET /c1/ HTTP/1.1
-Host: example.org
-Accept: text/turtle</pre></div>
-
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 2</span></div><pre class="example" id="ldpc-ex-simple">HTTP/1.1 200 OK
-Content-Type: text/turtle
-Date: Thu, 12 Jun 2014 18:26:59 GMT
-ETag: "8caab0784220148bfe98b738d5bb6d13"
-Accept-Post: text/turtle, application/ld+json
-Allow: POST,GET,OPTIONS,HEAD,PUT
-Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type",
- <http://www.w3.org/ns/ldp#Resource>; rel="type"
-Transfer-Encoding: chunked
-
-<!-- @base <http://example.org/c1></http:>. -->
-
-@prefix dcterms: <http://purl.org/dc/terms/>.
-@prefix ldp: <http://www.w3.org/ns/ldp#>.
-
-<http://example.org/c1/>
- 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>The preceding example is very straightforward: there are containment triples
- whose subject is the container, whose predicate is
- <code>ldp:contains</code>, and whose objects are the URIs of the contained resources,
- and there is no distinction between member resources and 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 called a
- <a title="" href="#dfn-linked-data-platform-basic-container" class="internalDFN">Linked Data Platform Basic Container</a>. </p>
-
- <p>
- Sometimes you have to build on existing models incrementally, so you have fewer degrees of
- freedom in the resource model. In these situations, it can be useful to help clients map
- LDP patterns onto existing vocabularies, or to include members not created via the container;
- <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Containers</a>
- meet those kinds of needs. Direct Containers allow membership triples 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 pre-existing domain resource for a person's net worth, as illustrated below:</p>
-
-<em>Request</em> to <code>http://example.org/netWorth/nw1</code>:
-<div class="example"><div class="example-title"><span>Example 3</span></div><pre class="example" id="ldpc-ex-membership-partial-req">GET /netWorth/nw1 HTTP/1.1
-Host: example.org
-Accept: text/turtle</pre></div>
-
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 4</span></div><pre class="example" id="ldpc-ex-membership-partial">HTTP/1.1 200 OK
-Content-Type: text/turtle
-Date: Thu, 12 Jun 2014 18:26:59 GMT
-ETag: "0f6b5bd8dc1f754a1238a53b1da34f6b"
-Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type",
- <http://www.w3.org/ns/ldp#Resource>; rel="type"
-Allow: GET,OPTIONS,HEAD,PUT,DELETE
-Transfer-Encoding: chunked
-
-<!-- @base <http://example.org/netWorth/nw1>. -->
-
-@prefix ldp: <http://www.w3.org/ns/ldp#>.
-@prefix o: <http://example.org/ontology#>.
-
-<http://example.org/netWorth/nw1>
- a o:NetWorth;
- o:netWorthOf <http://example.org/users/JohnZSmith>;
- o:asset
- <assets/a1>,
- <assets/a2>;
- o:liability
- <liabilities/l1>,
- <liabilities/l2>,
- <liabilities/l3>.</pre></div>
- <p>
- In the preceding 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 a <code>o:netWorthOf</code> predicate indicating
- the associated person. There are two sets of same-subject, same-predicate triples; one for assets and
- one for liabilities. Existing domain-specific applications exist that depend on those types and
- predicates, so changing them <em>incompatibly</em> would be frowned upon.
- </p>
-
- <p>
- It would be helpful to be able to use LDP patterns to manage the assets and liabilities-related triples.
- Doing so using a Basic Container would require duplicating much of the information with different types and
- predicates, which would be onerous for large resources. <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">Direct Containers</a>
- provide a middle ground, by giving LDP clients a way to map existing domain-specific resources to LDP's
- types and interaction models.
- In this specific example,
- it would be helpful to be able to manage the assets and liabilities triples consistently, for example
- by using LDP containers.
- One way to do this is to create two containers, one to manage assets and another liabilities,
- as separate HTTP resources. Existing clients have no need to interact with those containers,
- whereas LDP-enabled clients now have container URLs that they can interact with. The existing
- resource remains unchanged so that existing clients continue to function normally.
- This is illustrated in the set of related examples, one example per HTTP resource, starting with
- the <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> example from before:
- </p>
-
-<em>Request</em> to <code>http://example.org/netWorth/nw1</code>:
-<div class="example"><div class="example-title"><span>Example 5</span></div><pre class="example" id="ldpc-ex-membership-full-req">GET /netWorth/nw1 HTTP/1.1
-Host: example.org
-Accept: text/turtle</pre></div>
-
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 6</span></div><pre class="example" id="ldpc-ex-membership-full">HTTP/1.1 200 OK
-Content-Type: text/turtle
-Date: Thu, 12 Jun 2014 18:26:59 GMT
-ETag: "0f6b5bd8dc1f754a1238a53b1da34f6b"
-Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type",
- <http://www.w3.org/ns/ldp#Resource>; rel="type"
-Allow: GET,OPTIONS,HEAD,PUT,DELETE
-Transfer-Encoding: chunked
-
-<!-- @base <http://example.org/netWorth/nw1>. -->
-
-@prefix ldp: <http://www.w3.org/ns/ldp#>.
-@prefix o: <http://example.org/ontology#>.
-
-<http://example.org/netWorth/nw1>
- a o:NetWorth;
- o:netWorthOf <http://example.org/users/JohnZSmith>;
- o:asset
- <assets/a1>,
- <assets/a2>;
- o:liability
- <liabilities/l1>,
- <liabilities/l2>,
- <liabilities/l3>.</pre></div>
-
-
- <p>The structure of the net worth resource is completely unchanged, so any existing
- domain-specific applications continue to work without impact.
- LDP clients, on the other hand, have no way to understand that the asset and
- liability triples correspond in any way to LDP containers. For that, they need the
- next two resources.
- </p>
- <p>The first container is a <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Container</a> to manage assets.
- Direct Containers add the concept of <a title="Membership" href="#dfn-membership" class="internalDFN">membership</a>
- and flexibility on how to specify the <a title="Membership triples" href="#dfn-membership-triples" class="internalDFN">membership triples</a>.
- </p>
-
-<em>Request</em> to <code>http://example.org/netWorth/nw1/assets/</code>:
-<div class="example"><div class="example-title"><span>Example 7</span></div><pre class="example" id="ldpc-ex-membership-subj-req">GET /netWorth/nw1/assets/ HTTP/1.1
-Host: example.org
-Accept: text/turtle</pre></div>
-
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 8</span></div><pre class="example" id="ldpc-ex-membership-subj">HTTP/1.1 200 OK
-Content-Type: text/turtle
-Date: Thu, 12 Jun 2014 18:26:59 GMT
-ETag: "6df36eef2631a1795bfe9ab76760ea75"
-Accept-Post: text/turtle, application/ld+json
-Allow: POST,GET,OPTIONS,HEAD
-Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
- <http://www.w3.org/ns/ldp#Resource>; rel="type"
-Transfer-Encoding: chunked
-
-<!-- @base <http://example.org/netWorth/nw1/assets></http:>. -->
-
-@prefix ldp: <http://www.w3.org/ns/ldp#>.
-@prefix dcterms: <http://purl.org/dc/terms/>.
-@prefix o: <http://example.org/ontology#>.
-
-<http://example.org/netWorth/nw1/assets/>
- 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>
-
- <p>
- In the preceding asset container, 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 the (separate) net worth resource. The
- membership predicate is <code>o:asset</code>,
- from the domain model. A POST of an asset representation to the asset container will create a new
- asset and add it to net-worth's list of assets by adding a new membership triple
- to the resource and a containment triple to the container.
- </p>
-
- <p>The second container is a <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Container</a> to manage liabilities.
- </p>
-<em>Request</em> to <code>http://example.org/netWorth/nw1/liabilities/</code>:
-<div class="example"><div class="example-title"><span>Example 9</span></div><pre class="example" id="ldpc-ex-membership-full-liabcont-req">GET /netWorth/nw1/liabilities/ HTTP/1.1
-Host: example.org
-Accept: text/turtle</pre></div>
-
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 10</span></div><pre class="example" id="ldpc-ex-membership-full-liabcont">HTTP/1.1 200 OK
-Content-Type: text/turtle
-Date: Thu, 12 Jun 2014 18:26:59 GMT
-ETag: "9f50da01f792281ddcfebe9788372d07"
-Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
- <http://www.w3.org/ns/ldp#Resource>; rel="type"
-Accept-Post: text/turtle, application/ld+json
-Allow: POST,GET,OPTIONS,HEAD
-Transfer-Encoding: chunked
-
-<!-- @base <http://example.org/netWorth/nw1/liabilities></http:>. -->
-
-@prefix ldp: <http://www.w3.org/ns/ldp#>.
-@prefix dcterms: <http://purl.org/dc/terms/>.
-@prefix o: <http://example.org/ontology#>.
-
-<http://example.org/netWorth/nw1/liabilities/>
- 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 preceding liability container is completely analogous to the asset container above, simply
- managing liabilities instead of assets and using the <code>o:liability</code> predicate.
- </p>
- <p>
- To add a another liability, a client would POST something like this to the liability container:
- </p>
-
-<em>Request</em> to <code>http://example.org/netWorth/nw1/liabilities/</code>:
-<div class="example"><div class="example-title"><span>Example 11</span></div><pre class="example" id="ldpc-ex-membership-add-new-liability-req">POST /netWorth/nw1/liabilities/ HTTP/1.1
-Host: example.org
-Accept: text/turtle
-Content-Type: text/turtle
-Content-Length: 63
-
-<!-- @base is here only so it's easier to paste into validators for checking -->
-
-@prefix o: <http://example.org/ontology#>.
-
-<>
- a o:Liability.
- # plus any other properties that the domain says liabilities have</pre></div>
-
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 12</span></div><pre class="example" id="ldpc-ex-membership-add-new-liability">HTTP/1.1 201 Created
-Location: http://example.org/netWorth/nw1/liabilities/l4
-Date: Thu, 12 Jun 2014 19:56:13 GMT
-Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
- <http://www.w3.org/ns/ldp#Resource>; rel="type"</pre></div>
-
- <p>
- Assuming the server successfully processes this request and assigns the URI
- <code><http://example.org/netWorth/nw1/liabilities/l4></code> to the
- newly created liability resource, at least two new triples would be added.
- </p>
- <ol>
- <li>In the net worth resource, <code><http://example.org/netWorth/nw1> o:liability <liabilities/l4></code></li>
- <li>In the liability container, <code><http://example.org/netWorth/nw1/liabilities/> ldp:contains <l4></code>.</li>
- </ol>
-
- <p>
- You might wonder why we chose to create two new containers instead of making
- <code>http://example.org/netWorth/nw1</code> itself a container.
- A single net worth container would be a fine design if <code>http://example.org/netWorth/nw1</code>
- had only assets or only liabilities (basically: only a single predicate to manage),
- but since it has separate predicates for assets and liabilities an ambiguity arises:
- it is unspecified whether a client's creation request (POST)
- should add a new <code>o:asset</code> or <code>o:liability</code> triple.
- Having separate <code>http://example.org/netWorth/nw1/assets/</code>
- and <code>http://example.org/netWorth/nw1/liabilities/</code> containers
- allows both assets and liabilities to be created
- and linked to the net-worth resource using the appropriate predicate. Similar ambiguities arise
- if the client wishes to list the members and/or contained resources.
- </p>
-
- <p>Continuing in the multiple containers direction, we will now extend our net worth example to add 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>
-
-<em>Request</em> to <code>http://example.org/netWorth/nw1</code>:
-<div class="example"><div class="example-title"><span>Example 13</span></div><pre class="example" id="ldpc-ex-membership-full-elab-req">GET /netWorth/nw1 HTTP/1.1
-Host: example.org
-Accept: text/turtle</pre></div>
-
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 14</span></div><pre class="example" id="ldpc-ex-membership-full-elab">HTTP/1.1 200 OK
-Content-Type: text/turtle
-Date: Thu, 12 Jun 2014 18:26:59 GMT
-ETag: "e8d129f45ca31848fb56213844a32b49"
-Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
- <http://www.w3.org/ns/ldp#Resource>; rel="type"
-Allow: GET,OPTIONS,HEAD,PUT,DELETE
-Transfer-Encoding: chunked
-
-<!-- @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#>.
-
-<http://example.org/netWorth/nw1>
- a o:NetWorth;
- o:netWorthOf <http://example.org/users/JohnZSmith>;
- o:advisor
- <advisors/bob#me>, # URI of a person
- <advisors/marsha#me>.
-
-<advisors/>
- a ldp:IndirectContainer;
- dcterms:title "The asset advisors of JohnZSmith";
- ldp:membershipResource <>;
- ldp:hasMemberRelation o:advisor;
- ldp:insertedContentRelation foaf:primaryTopic;
- ldp:contains
- <bob>, # URI of a document a.k.a. an information resource
- <marsha>. # describing a person</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 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 a member any resource,
- including a URI representing a real-world object. Create requests to
- <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Containers</a>
- can only add information resources [<cite><a class="bibref" href="#bib-WEBARCH">WEBARCH</a></cite>] - the documents they create - as members.
- </p>
-
- <p>
- To add a another advisor, a client would POST something like this to the advisors container:
- </p>
-<em>Request</em> to <code>http://example.org/netWorth/nw1/advisors/</code>:
-<div class="example"><div class="example-title"><span>Example 15</span></div><pre class="example" id="ldpc-ex-membership-add-new-advisor-req">POST /netWorth/nw1/advisors/ HTTP/1.1
-Host: example.org
-Accept: text/turtle
-Content-Type: text/turtle
-Slug: george
-Content-Length: 72
-
-<!-- @base <http://example.org/netWorth/nw1/advisors/george>. -->
-
-@prefix foaf: <http://xmlns.com/foaf/0.1/>.
-@prefix o: <http://example.org/ontology#>.
-<>
- a o:Advisor;
- foaf:primaryTopic <#me>.
- # plus any other properties that the domain says advisors have</pre></div>
-
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 16</span></div><pre class="example" id="ldpc-ex-membership-add-new-advisor">HTTP/1.1 201 Created
-Location: http://example.org/netWorth/nw1/advisors/george
-Date: Thu, 12 Jun 2014 19:56:13 GMT
-Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type",
- <http://www.w3.org/ns/ldp#Resource>; rel="type"</pre></div>
-
- <p>
- Assuming the server successfully processes this request and assigns the URI
- <code><http://example.org/netWorth/nw1/advisors/george></code> to the
- newly created advisor resource, at least two new triples would be added.
- </p>
- <ol>
- <li>In the net worth resource, <code><http://example.org/netWorth/nw1> o:advisor <advisors/george#me></code></li>
- <li>In the advisors container, <code><http://example.org/netWorth/nw1/advisors/> ldp:contains <george></code></li>
- </ol>
-
- <p>In summary, <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 LDP-defined container types: Basic, Direct, and Indirect, 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 style="background:#FFFFFF;" 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_minimal-container_props" typeof="bibo:Chapter" resource="#ldpc-get_minimal-container_props" rel="bibo:Chapter"><h4 class="normal" aria-level="3" role="heading" id="h4_ldpc-get_minimal-container_props"><span class="secno">5.1.1 </span>Retrieving Only Minimal-Container Triples
- </h4>
-<!-- Was 5.1.1 / #ldpc-get_minimal-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="Minimal-container triples" href="#dfn-minimal-container-triples" class="internalDFN">minimal-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 minimal-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 minimal-container triples of a
- container identified by the URL <code>http://example.org/container1/</code>.
- </p>
-<p id="ldpc-ex-minimal-container"><em>Request</em> to <code>http://example.org/container1/</code>:</p>
-<div class="example"><div class="example-title"><span>Example 17</span></div><pre class="example">GET /container1/ HTTP/1.1
-Host: example.org
-Accept: text/turtle
-Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer"</pre></div>
-<p><em>Response:</em></p>
-<div class="example"><div class="example-title"><span>Example 18</span></div><pre class="example">HTTP/1.1 200 OK
-Content-Type: text/turtle
-ETag: "_87e52ce291112"
-Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
- <http://www.w3.org/ns/ldp#Resource>; rel="type"
-Accept-Post: text/turtle, application/ld+json
-Allow: POST,GET,OPTIONS,HEAD
-Preference-Applied: return=representation
-Transfer-Encoding: chunked
-
-@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_minimal-container_props -->
-
-
-</section>
-
-<section id="ldpc-container" typeof="bibo:Chapter" resource="#ldpc-container" 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="#ldpc-general" 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="#ldpc-isldpr" 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: one
- whose subject is the <a title="Linked Data Platform Container" href="#dfn-linked-data-platform-container" class="internalDFN"><abbr title="Linked Data Platform Container">LDPC</abbr></a>,
- whose predicate is <code>rdf:type</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="#ldpc-typecontainer" 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 a <abbr title="Linked Data Platform Container">LDPC</abbr> <em class="rfc2119" title="MAY">MAY</em> have an <code>rdf:type</code>
- 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="#ldpc-nordfcontainertypes" 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="#ldpc-linktypehdr" 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="#ldpc-prefer" 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 a <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="#ldpc-HTTP_GET" 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="#ldpc-HTTP_POST" 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-RFC7231">RFC7231</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 a 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="#ldpc-post-created201" 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="#ldpc-post-createdmbr-contains" 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 a <abbr title="Linked Data Platform Container">LDPC</abbr> results in the creation of a <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 the <abbr title="Linked Data Platform Container">LDPC</abbr>
- 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>). Other triples may be added as well.
- 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.
- </h5></section>
-
- <section id="ldpc-post-createbins" typeof="bibo:Chapter" resource="#ldpc-post-createbins" 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 a <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="#ldpc-post-createrdf" 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).
- If any requested interaction 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 specifies <a href="#ldpr-gen-linktypehdr">a <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 a <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 specifies <a href="#ldpc-linktypehdr">a <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 a <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="#ldpc-post-turtle" 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="#ldpc-post-contenttype" 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="#ldpc-post-rdfnullrel" 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 identifying 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 result in
- triples in the created resource whose subject is the created
- resource.
- </h5></section>
-<!-- Was 5.4.7 / #ldpc-5_4_7 -->
-
-
-<!-- TODO: add link to "relative URIs on post-create are dangerous" -->
-
-
- <section id="ldpc-post-serverassignuri" typeof="bibo:Chapter" resource="#ldpc-post-serverassignuri" 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="#ldpc-post-mincontraints" 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="#ldpc-post-slug" 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="#ldpc-post-dontreuseuris" 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="#ldpc-post-createbinlinkmetahdr" 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 a LDP 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="#ldpc-post-acceptposthdr" 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 <code>POST</code> request 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 a 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 id="ldpc-post-jsonld" typeof="bibo:Chapter" resource="#ldpc-post-jsonld" rel="bibo:Chapter"><h5 class="normal" aria-level="4" role="heading" id="h5_ldpc-post-jsonld"><span class="secno">5.2.3.14 </span><a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> <em class="rfc2119" title="SHOULD">SHOULD</em> accept a request entity body with a request header
- of <code>Content-Type</code> with value of <code>application/ld+json</code> [<cite><a class="bibref" href="#bib-JSON-LD">JSON-LD</a></cite>].
- </h5></section>
-<!-- new -->
-
-
-</section>
-
-<section id="ldpc-HTTP_PUT" typeof="bibo:Chapter" resource="#ldpc-HTTP_PUT" 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-RFC7231">RFC7231</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 a 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="#ldpc-put-mbrprops" 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 a <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="#ldpc-put-create" 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.
- </h5></section>
-<!-- Was 5.5.4 / #ldpc-5_5_4 -->
-
-
-</section>
-
-<section id="ldpc-HTTP_DELETE" typeof="bibo:Chapter" resource="#ldpc-HTTP_DELETE" 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-RFC7231">RFC7231</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 a 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="#ldpc-del-contremovesconttriple" 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 a <a title="containment" href="#dfn-containment" class="internalDFN">contained <abbr title="Linked Data Platform Resource">LDPR</abbr></a> is deleted, the <abbr title="Linked Data Platform Container">LDPC</abbr> server <em class="rfc2119" title="MUST">MUST</em> also remove
- the corresponding containment triple, which has the effect of removing the deleted <abbr title="Linked Data Platform Resource">LDPR</abbr> from the containing <abbr title="Linked Data Platform Container">LDPC</abbr>.
- </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-RFC7231">RFC7231</a></cite>].
- For example, the server could remove membership triples referring to the deleted <abbr title="Linked Data Platform Resource">LDPR</abbr>,
- perform additional cleanup tasks for resources it knows are no longer referenced or have not
- been accessed for some period of time, and so on.
- </blockquote>
- </section>
-<!-- Was 5.6.1 / #ldpc-5_6_1 -->
-
-
- <section id="ldpc-del-contremovescontres" typeof="bibo:Chapter" resource="#ldpc-del-contremovescontres" 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 a <a title="containment triples" href="#dfn-containment-triples" class="internalDFN">contained <abbr title="Linked Data Platform Resource">LDPR</abbr></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 delete 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="#ldpc-HTTP_HEAD" 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 recommends that
- <code>HEAD</code> responses include the same headers as <code>GET</code> responses.
- <a title="LDP server" href="#dfn-ldp-server" class="internalDFN">LDP servers</a> must also include HTTP headers
- on responses 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="#ldpc-HTTP_PATCH" 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-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 a 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="#ldpc-patch-req" 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 a <abbr title="Linked Data Platform Container">LDPC</abbr>'s <a title="Minimal-container triples" href="#dfn-minimal-container-triples" class="internalDFN">minimal-container triples</a>.
- </h5></section>
-<!-- Was 5.8.1 / #ldpc-5_8_1 -->
-
-</section>
-
-<section id="ldpc-HTTP_OPTIONS" typeof="bibo:Chapter" resource="#ldpc-HTTP_OPTIONS" 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>.
- Note that support for this method is required for <abbr title="Linked Data Platform Containers">LDPCs</abbr>, since <a href="#ldpr-HTTP_OPTIONS">it is required for <abbr title="Linked Data Platform Resources">LDPRs</abbr></a> and
- <a href="#ldpc-isldpr"><abbr title="Linked Data Platform Containers">LDPCs</abbr> adhere to <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr> requirements</a>.
- </p>
-
- <section id="ldpc-options-linkmetahdr" typeof="bibo:Chapter" resource="#ldpc-options-linkmetahdr" 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 responding to requests whose <code>request-URI</code> is a
- <a href="#ldpc-post-createbinlinkmetahdr"><abbr title="Linked Data Platform Non-RDF Source">LDP-NR</abbr> with an associated <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr></a>,
- a <abbr title="Linked Data Platform Container">LDPC</abbr> server <em class="rfc2119" title="MUST">MUST</em> provide the same HTTP <code>Link</code>
- response header as is <a href="#ldpc-post-createbinlinkmetahdr">required in the create response</a>.
- </h5></section>
-<!-- Was 5.9.2 / #ldpc-5_9_2 -->
-
-</section>
-<!-- h2 -->
-
-</section>
-<!-- ldpc-container -->
-
-
-<section id="ldpbc" typeof="bibo:Chapter" resource="#ldpbc" 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="#ldpbc-general" 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="#ldpbc-are-ldpcs" 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 with 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 the <a title="Linked Data Platform Basic Container" href="#dfn-linked-data-platform-basic-container" class="internalDFN">LDP Basic Container</a>,
- whose predicate is <code>rdf:type</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="#ldpdc" 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="#ldpdc-general" 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="#ldpdc-are-ldpcs" 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 the <a title="Linked Data Platform Direct Container" href="#dfn-linked-data-platform-direct-container" class="internalDFN">LDP Direct Container</a>,
- whose predicate is <code>rdf:type</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="#ldpdc-mbrpred" 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 a <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 a <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="#ldpdc-containres" 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="#ldpdc-containtriples" 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="#ldpdc-containtriple-relation" 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="#ldpdc-containtriple-byrelation" 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 <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="#ldpdc-indirectmbr-basic" 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="#ldpdc-HTTP_POST" 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="#ldpdc-post-createdmbr-member" 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 a <abbr title="Linked Data Platform Container">LDPC</abbr> results in the creation of a <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="#ldpdc-HTTP_DELETE" 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="#ldpdc-del-contremovesmbrtriple" 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 a <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="#ldpic" 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="#ldpic-general" 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="#ldpic-are-ldpcs" 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> as described in <a href="#ldpdc" class="sectionRef sec-ref">section <span class="secno">5.4</span> <span class="sec-title">Direct</span></a>, along with 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: one
- whose subject is <a title="Linked Data Platform Indirect Container" href="#dfn-linked-data-platform-indirect-container" class="internalDFN">LDP Indirect Container</a>,
- whose predicate is <code>rdf:type</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="#ldpic-indirectmbr" 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="#ldpic-HTTP_POST" 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="#ldpic-post-indirectmbrrel" 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="#base-specs" 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="#specs-webarch" 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="#ldp-webarch-nonexcl-membership" 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="#ldp-webarch-uri-reuse" 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 a <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="#specs-http" 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-RFC7230">RFC7230</a></cite>], [<cite><a class="bibref" href="#bib-RFC7231">RFC7231</a></cite>], [<cite><a class="bibref" href="#bib-RFC7232">RFC7232</a></cite>]
-
- <section id="ldp-http-other-representations" typeof="bibo:Chapter" resource="#ldp-http-other-representations" 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-RFC7231">RFC7231</a></cite>] Section 3.4 - Content Negotiation) is used to select the format.
- </h4></section>
-
- <section id="ldp-http-other-methods" typeof="bibo:Chapter" resource="#ldp-http-other-methods" 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="#ldp-http-delete-uri-reuse" 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="#ldp-http-method-side-effects" 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-RFC7231">RFC7231</a></cite>] section 4.2.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="#ldp-http-patch-allowed" 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="#ldp-http-content-sniffing" 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-RFC7231">RFC7231</a></cite>] section 3.1.1.5).
- </h4></section>
-
-</section>
-
-<section id="specs-rdf" class="informative" typeof="bibo:Chapter" resource="#specs-rdf" 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="#ldp-rdfconcepts-extra-triples-any" 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 a <abbr title="Linked Data Platform Resource">LDPR</abbr>
- can have triples with any subject(s). The URL used to retrieve the
- representation of a <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="#ldp-rdfconcepts-extra-triples-members" 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 a <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="#ldp-rdfconcepts-extra-triples-types" 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 a <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="#header-accept-post" 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> [<cite><a class="bibref" href="#bib-Accept-Post">Accept-Post</a></cite>]
- 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 status, 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="#header-accept-post-1" 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 1.2 of [<cite><a class="bibref" href="#bib-RFC7231">RFC7231</a></cite>], is:</h4>
- <blockquote><code>Accept-Post = "Accept-Post" ":" # media-range </code>
- <p>
- The <code>Accept-Post</code> header specifies a comma-separated list of media
- ranges (with optional parameters) as defined by [<cite><a class="bibref" href="#bib-RFC7231">RFC7231</a></cite>], Section 5.3.2.
- The <code>Accept-Post</code> header, in effect, uses the same syntax as the
- HTTP <code>Accept</code> header minus the optional <code>accept-params</code> BNF production,
- since the latter does not apply to <code>Accept-Post</code>.
- </p>
- </blockquote>
- </section>
-<!-- Was 6.1.1 / #header-accept-post-1 -->
-
-
- <section id="header-accept-post-2" typeof="bibo:Chapter" resource="#header-accept-post-2" 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="#header-accept-post-iana" 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="#prefer-parameters" 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="#prefer-summary" rel="bibo:Chapter">
-<h4 aria-level="3" role="heading" id="h4_prefer-summary"><span class="secno">7.2.1 </span>Summary</h4>
-
- <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-RFC7240">RFC7240</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-RFC7240">RFC7240</a></cite>].
- </p>
-
- <p>
- Non-normative note: [<cite><a class="bibref" href="#bib-RFC7240">RFC7240</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="#prefer-rules" 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="#prefer-include" 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 a <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-RFC7240">RFC7240</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-RFC7240">RFC7240</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="#prefer-omit" 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 a <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-RFC7240">RFC7240</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="#prefer-conflicts" 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-RFC7240">RFC7240</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="#prefer-uris" 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 rowspan="3"> <a title="Minimal-container triples" href="#dfn-minimal-container-triples" class="internalDFN">Minimal-container triples</a>
- </td>
- <td> <code>http://www.w3.org/ns/ldp#PreferMinimalContainer</code> </td>
- </tr>
- <tr>
- <td> or the equivalent but deprecated term </td>
- </tr>
- <tr>
- <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="#prefer-examples" 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 19</span></div><pre class="example" id="prefer-examples-direct"># The following is the representation of
-# http://example.org/netWorth/nw1/assets/
-
-<!-- @base is here only so it's easier to paste into validators for checking -->
-
-# @base <http://example.org/netWorth/nw1/assets/>.
-@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-minimal-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#PreferMinimalContainer"</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>
-
-<em>Request</em> to <code>http://example.org/netWorth/nw1/assets/</code>:
-<div class="example"><div class="example-title"><span>Example 20</span></div><pre class="example">GET /netWorth/nw1/assets/ HTTP/1.1
-Host: example.org
-Accept: text/turtle
-Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer"</pre></div>
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 21</span></div><pre class="example">HTTP/1.1 200 OK
-Content-Type: text/turtle
-ETag: "_87e52ce291112"
-Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
- <http://www.w3.org/ns/ldp#Resource>; rel="type"
-Accept-Post: text/turtle, application/ld+json
-Allow: POST,GET,OPTIONS,HEAD
-Preference-Applied: return=representation
-Transfer-Encoding: chunked
-
-<!-- @base <http://example.org/netWorth/nw1/assets/>. -->
-
-@prefix dcterms: <http://purl.org/dc/terms/>.
-@prefix ldp: <http://www.w3.org/ns/ldp#>.
-@prefix o: <http://example.org/ontology#>.
-
-<http://example.org/netWorth/nw1/assets/>
- 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-minimal-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="Minimal-container triples" href="#dfn-minimal-container-triples" class="internalDFN">minimal-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>
-
-<em>Request</em> to <code>http://example.org/netWorth/nw1/assets/</code>:
-<div class="example"><div class="example-title"><span>Example 22</span></div><pre class="example">GET /netWorth/nw1/assets/ HTTP/1.1
-Host: example.org
-Accept: text/turtle
-Prefer: return=representation; omit="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferContainment"</pre></div>
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 23</span></div><pre class="example">HTTP/1.1 200 OK
-Content-Type: text/turtle
-ETag: "_87e52ce291112"
-Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
- <http://www.w3.org/ns/ldp#Resource>; rel="type"
-Accept-Post: text/turtle, application/ld+json
-Allow: POST,GET,OPTIONS,HEAD
-Preference-Applied: return=representation
-Transfer-Encoding: chunked
-
-<!-- @base <http://example.org/netWorth/nw1/assets/>. -->
-
-@prefix dcterms: <http://purl.org/dc/terms/>.
-@prefix ldp: <http://www.w3.org/ns/ldp#>.
-@prefix o: <http://example.org/ontology#>.
-
-<http://example.org/netWorth/nw1/assets/>
- 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#PreferMinimalContainer"</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-RFC7231">RFC7231</a></cite>]).
- </p>
-
-<em>Request</em> to <code>http://example.org/netWorth/nw1/assets/</code>:
-<div class="example"><div class="example-title"><span>Example 24</span></div><pre class="example">GET /netWorth/nw1/assets/ HTTP/1.1
-Host: example.org
-Accept: text/turtle
-Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferMinimalContainer"</pre></div>
-<em>Response:</em>
-<div class="example"><div class="example-title"><span>Example 25</span></div><pre class="example">HTTP/1.1 200 OK
-Content-Type: text/turtle
-ETag: "_87e52ce291112"
-Link: <http://www.w3.org/ns/ldp#DirectContainer>; rel="type",
- <http://www.w3.org/ns/ldp#Resource>; rel="type"
-Accept-Post: text/turtle, application/ld+json
-Allow: POST,GET,OPTIONS,HEAD
-Preference-Applied: return=representation
-Transfer-Encoding: chunked
-
-<!-- @base <http://example.org/netWorth/nw1/assets/>. -->
-
-@prefix dcterms: <http://purl.org/dc/terms/>.
-@prefix ldp: <http://www.w3.org/ns/ldp#>.
-@prefix o: <http://example.org/ontology#>.
-
-<http://example.org/netWorth/nw1/assets/>
- 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 [[RFC7231]], [[!RFC2817]]).
- </p>
- <p>
- Value: 209
- </p>
- <p>
- Description: Related Content
- </p>
- <p>
- Reference: this specification
- </p>
- </blockquote>
- </div>
-
-</section>
-</section> -->
-
-
-<section id="link-relations" typeof="bibo:Chapter" resource="#link-relations" rel="bibo:Chapter">
-
-<!--OddPage-->
-<h2 aria-level="1" role="heading" id="h2_link-relations"><span class="secno">8. </span>Link Relations</h2>
-<p>
- The intent is that these link relations will be registered with IANA per [<cite><a class="bibref" href="#bib-RFC5988">RFC5988</a></cite>] section 6.2.1.
-</p>
-<section id="link-relation-describedby" typeof="bibo:Chapter" resource="#link-relation-describedby" rel="bibo:Chapter">
-<h3 aria-level="2" role="heading" id="h3_link-relation-describedby"><span class="secno">8.1 </span>describedby</h3>
-<p>
- The contents of this section were originally taken from [<cite><a class="bibref" href="#bib-POWDER">POWDER</a></cite>] appendix D, and then modified to comply with the current registration template.
- The pre-LDP IANA link relation registry entry for
- <code>describedby</code> refers to a different section of [<cite><a class="bibref" href="#bib-POWDER">POWDER</a></cite>] that was substantively updated in
- <a href="http://www.w3.org/2007/powder/powder-errata#describedby">an erratum</a>, and that section was not
- actually the normative definition of the link relation. Since we expect no update to [<cite><a class="bibref" href="#bib-POWDER">POWDER</a></cite>] that incorporates the erratum
- or fixes the registry link, this superseding registration approach is being taken.
-</p>
-<p>The following Link Relationship will be submitted to IANA for review, approval, and inclusion in the IANA Link Relations registry.</p>
-<dl>
-<dt>Relation Name:</dt>
-<dd><code>describedby</code></dd>
-<dt>Description:</dt>
-<dd>
-The relationship <code>A describedby B</code> asserts that resource B provides a description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource.
-</dd>
-<dt>Reference:</dt>
-<dd>
- The <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/TR/ldp/">Linked Data Platform specification</a>.
-</dd>
-<dt>Notes:</dt>
-<dd>
- Descriptions of resources may be socially sensitive, may require processing to be understood and may or may not not be accurate. Consumers of descriptive resources should be aware of the source and chain of custody of the data. Security considerations for URIs (Section 7 of RFC 3986) and IRIs (Section 8 of RFC 3987) apply to the extent that describing resources may affect consumers' decisions about how or whether to retrieve those resources.
-</dd>
-</dl>
-</section>
-</section>
-
-<section class="informative" id="security" typeof="bibo:Chapter" resource="#security" rel="bibo:Chapter">
-
-<!--OddPage-->
-<h2 aria-level="1" role="heading" id="h2_security"><span class="secno">9. </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="#history" 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>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>
-
-<h2 id="summary">Summary</h2>
-<p>Summary of notable changes from the <a href="http://www.w3.org/TR/2013/WD-ldp-20140311/">previous public working draft</a>.</p>
-<ul>
- <li>Resolved Last Call 2 comments</li>
- <li>Removed references to <abbr title="Resource Description Framework">RDF</abbr> named graphs</li>
- <li>Rename empty-container triples to minimal-container triples</li>
- <li>Duplication (with intent to supersede) of the <code>describedby</code> relation type IANA registration, incorporating POWDER's relevant errata</li>
- <li>Clarify definitions of membership and containment triples to avoid impression that they must be (stored as) part of the <abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>'s state.</li>
- <li>Servers should offer/accept JSON-LD representations of LDP-RSs</li>
- <li>Updated all HTTP and Prefer-draft references to newly assigned RFC numbers, with associated BNF hits</li>
-</ul>
-</section>
-
-
-<section id="references" class="appendix" typeof="bibo:Chapter" resource="#references" 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="#normative-references" 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-JSON-LD">[JSON-LD]</dt><dd rel="dcterms:requires">Manu Sporny; Gregg Kellogg; Markus Lanthaler. <a href="http://www.w3.org/TR/json-ld/"><cite>JSON-LD 1.0</cite></a>. 16 January 2014. W3C Recommendation. URL: <a href="http://www.w3.org/TR/json-ld/">http://www.w3.org/TR/json-ld/</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-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. Best Current Practice. 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. Best Current Practice. 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</cite></a>. January 2005. Internet Standard. 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. Duerst; M. Suignard. <a href="http://www.ietf.org/rfc/rfc3987.txt"><cite>Internationalized Resource Identifiers (IRIs)</cite></a>. January 2005. Proposed Standard. 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, Ed.; B. de hOra, Ed.. <a href="http://www.ietf.org/rfc/rfc5023.txt"><cite>The Atom Publishing Protocol</cite></a>. October 2007. Proposed Standard. 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, Ed.; P. Overell. <a href="http://www.ietf.org/rfc/rfc5234.txt"><cite>Augmented BNF for Syntax Specifications: ABNF</cite></a>. January 2008. Internet Standard. 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://www.ietf.org/rfc/rfc5789.txt"><cite>PATCH Method for HTTP</cite></a>. March 2010. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc5789.txt">http://www.ietf.org/rfc/rfc5789.txt</a>
-</dd><dt id="bib-RFC5988">[RFC5988]</dt><dd rel="dcterms:requires">M. Nottingham. <a href="http://www.ietf.org/rfc/rfc5988.txt"><cite>Web Linking</cite></a>. October 2010. Proposed Standard. 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. Proposed Standard. URL: <a href="http://www.ietf.org/rfc/rfc6585.txt">http://www.ietf.org/rfc/rfc6585.txt</a>
-</dd><dt id="bib-RFC7230">[RFC7230]</dt><dd rel="dcterms:requires">R. Fielding; J. Reschke. <a href="http://tools.ietf.org/html/rfc7230"><cite>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</cite></a>. Proposed Standard. URL: <a href="http://tools.ietf.org/html/rfc7230">http://tools.ietf.org/html/rfc7230</a>
-</dd><dt id="bib-RFC7231">[RFC7231]</dt><dd rel="dcterms:requires">R. Fielding; J. Reschke. <a href="http://tools.ietf.org/html/rfc7231"><cite>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</cite></a>. Proposed Standard. URL: <a href="http://tools.ietf.org/html/rfc7231">http://tools.ietf.org/html/rfc7231</a>
-</dd><dt id="bib-RFC7232">[RFC7232]</dt><dd rel="dcterms:requires">R. Fielding; J. Reschke. <a href="http://tools.ietf.org/html/rfc7232"><cite>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</cite></a>. Proposed Standard. URL: <a href="http://tools.ietf.org/html/rfc7232">http://tools.ietf.org/html/rfc7232</a>
-</dd><dt id="bib-RFC7240">[RFC7240]</dt><dd rel="dcterms:requires">J. Snell. <a href="http://tools.ietf.org/html/rfc7240"><cite>Prefer Header for HTTP</cite></a>. Proposed Standard. URL: <a href="http://tools.ietf.org/html/rfc7240">http://tools.ietf.org/html/rfc7240</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>. 25 February 2014. W3C 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>. 25 February 2014. W3C 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>. 25 February 2014. W3C 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="#informative-references" 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-Accept-Post">[Accept-Post]</dt><dd rel="dcterms:references">J. Arwe; S. Speicher; E. Wilde. <a href="http://tools.ietf.org/html/draft-wilde-accept-post"><cite>The Accept-Post HTTP Header</cite></a>. Internet Draft. URL: <a href="http://tools.ietf.org/html/draft-wilde-accept-post">http:tools.ietf.org/html/draft-wilde-accept-post</a>
-</dd><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-LDP-Tests">[LDP-Tests]</dt><dd rel="dcterms:references">R. Garcia-Castro; F. Serena. <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-testsuite.html"><cite>Linked Data Platform 1.0 Test Cases</cite></a>. Editor's Draft of Working Group Note. URL: <a href="https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-testsuite.html">https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-testsuite.html</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>. 13 March 2014. W3C Note. 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-POWDER">[POWDER]</dt><dd rel="dcterms:references">Phil Archer; Kevin Smith; Andrea Perego. <a href="http://www.w3.org/TR/2009/REC-powder-dr-20090901/"><cite>Protocol for Web Description Resources (POWDER): Description Resources</cite></a>. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2009/REC-powder-dr-20090901/">http://www.w3.org/TR/2009/REC-powder-dr-20090901/</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)</cite></a>. July 2006. Informational. 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-20140619/images/ldpc-basic.png has changed
Binary file TR/WD-ldp-20140619/images/ldpc-hierarchy.png has changed
Binary file TR/WD-ldp-20140619/images/ldpc1.png has changed
Binary file TR/WD-ldp-20140619/images/ldpr1.png has changed
Binary file TR/WD-ldp-20140619/images/ldpr2.png has changed
--- a/TR/WD-ldp-20140619/ldp.ttl Mon Jun 16 13:43:01 2014 -0400
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,174 +0,0 @@
-# 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 "Archaic alias for ldp:PreferMinimalContainer";
- vs:term_status "deprecated";
- rdfs:isDefinedBy :;
- rdfs:sameAs :PreferMinimalContainer;
- rdfs:seeAlso :PreferMinimalContainer;
- rdfs:label "PreferEmptyContainer".
-
-:PreferMinimalContainer
- 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 "PreferMinimalContainer".
-
\ No newline at end of file
--- a/ldp-ucr-wd-snapshot.html Mon Jun 16 13:43:01 2014 -0400
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,1745 +0,0 @@
-<!DOCTYPE html>
-<html lang="en" dir="ltr" typeof="bibo:Document w3p:WD" about="" property="dcterms:language" content="en">
-<head>
- <title>Linked Data Platform Use Cases and Requirements</title>
- <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
- <!--
- === NOTA BENE ===
- For the three scripts below, if your spec resides on dev.w3 you can check them
- out in the same tree and use relative links so that they'll work offline,
- -->
-
-
- <style type="text/css">
- div.rule {padding-top: 1em;}
- div.ldp-issue {
- 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-title {
- color: #E05252;
- padding-right: 1em;
- min-width: 7.5em;
- }
- </style>
- <style>/*****************************************************************
- * ReSpec 3 CSS
- * Robin Berjon - http://berjon.com/
- *****************************************************************/
-
-/* --- INLINES --- */
-em.rfc2119 {
- text-transform: lowercase;
- font-variant: small-caps;
- font-style: normal;
- color: #900;
-}
-
-h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
-h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
- border: none;
-}
-
-dfn {
- font-weight: bold;
-}
-
-a.internalDFN {
- color: inherit;
- border-bottom: 1px solid #99c;
- text-decoration: none;
-}
-
-a.externalDFN {
- color: inherit;
- border-bottom: 1px dotted #ccc;
- text-decoration: none;
-}
-
-a.bibref {
- text-decoration: none;
-}
-
-cite .bibref {
- font-style: normal;
-}
-
-code {
- color: #ff4500;
-}
-
-/* --- TOC --- */
-.toc a, .tof a {
- text-decoration: none;
-}
-
-a .secno, a .figno {
- color: #000;
-}
-
-ul.tof, ol.tof {
- list-style: none outside none;
-}
-
-.caption {
- margin-top: 0.5em;
- font-style: italic;
-}
-
-/* --- TABLE --- */
-table.simple {
- border-spacing: 0;
- border-collapse: collapse;
- border-bottom: 3px solid #005a9c;
-}
-
-.simple th {
- background: #005a9c;
- color: #fff;
- padding: 3px 5px;
- text-align: left;
-}
-
-.simple th[scope="row"] {
- background: inherit;
- color: inherit;
- border-top: 1px solid #ddd;
-}
-
-.simple td {
- padding: 3px 10px;
- border-top: 1px solid #ddd;
-}
-
-.simple tr:nth-child(even) {
- background: #f0f6ff;
-}
-
-/* --- DL --- */
-.section dd > p:first-child {
- margin-top: 0;
-}
-
-.section dd > p:last-child {
- margin-bottom: 0;
-}
-
-.section dd {
- margin-bottom: 1em;
-}
-
-.section dl.attrs dd, .section dl.eldef dd {
- margin-bottom: 0;
-}
-</style><style>/* --- EXAMPLES --- */
-div.example-title {
- min-width: 7.5em;
- color: #b9ab2d;
-}
-div.example-title span {
- text-transform: uppercase;
-}
-aside.example, div.example, div.illegal-example {
- padding: 0.5em;
- margin: 1em 0;
- position: relative;
- clear: both;
-}
-div.illegal-example { color: red }
-div.illegal-example p { color: black }
-aside.example, div.example {
- padding: .5em;
- border-left-width: .5em;
- border-left-style: solid;
- border-color: #e0cb52;
- background: #fcfaee;
-}
-
-aside.example div.example {
- border-left-width: .1em;
- border-color: #999;
- background: #fff;
-}
-aside.example div.example div.example-title {
- color: #999;
-}
-</style><link rel="stylesheet" href="https://www.w3.org/StyleSheets/TR/W3C-WD"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--><script type="text/javascript" charset="utf-8" async="" data-requirecontext="_" data-requiremodule="ui/save-html" src="https://raw.github.com/darobin/respec/gh-pages/js/ui/save-html.js"></script></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="https://www.w3.org/Icons/w3c_home" alt="W3C"></a>
-
- </p>
- <h1 class="title p-name" id="title" property="dcterms:title">Linked Data Platform Use Cases and Requirements</h1>
-
- <h2 property="dcterms:issued" datatype="xsd:dateTime" content="2013-10-31T00:00:00.000Z" id="w3c-working-draft-31-october-2013"><abbr title="World Wide Web Consortium">W3C</abbr> Working Draft <time class="dt-published" datetime="2013-10-31">31 October 2013</time></h2>
- <dl>
-
- <dt>This version:</dt>
- <dd><a class="u-url" href="http://www.w3.org/TR/2013/WD-ldp-ucr-20131031/">http://www.w3.org/TR/2013/WD-ldp-ucr-20131031/</a></dd>
- <dt>Latest published version:</dt>
- <dd><a href="http://www.w3.org/TR/ldp-ucr/">http://www.w3.org/TR/ldp-ucr/</a></dd>
-
-
- <dt>Latest editor's draft:</dt>
- <dd><a href="http://www.w3.org/2012/ldp/hg/ldp-ucr.html">http://www.w3.org/2012/ldp/hg/ldp-ucr.html</a></dd>
-
-
-
-
-
- <dt>Previous version:</dt>
- <dd><a rel="dcterms:replaces" href="http://www.w3.org/TR/2013/WD-ldp-ucr-20130131/">http://www.w3.org/TR/2013/WD-ldp-ucr-20130131/</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 Battle" href="http://stevebattle.me">Steve Battle</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.sysemia.com">Sysemia Limited</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="Steve Speicher" href="http://stevespeicher.me">Steve Speicher</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://ibm.com/">IBM Corporation</a></span>
-</dd>
-
-
-
- </dl>
-
-
-
-
-
- <p class="copyright">
- <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
- 2013
-
- <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
- (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
- <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
- <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>),
-
- All Rights Reserved.
-
- <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
- <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
-
- <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
-
- rules apply.
- </p>
-
-
- <hr>
-</div>
-<section id="abstract" class="introductory" property="dcterms:abstract" datatype="" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter"><h2 aria-level="1" role="heading" id="h2_abstract">Abstract</h2>
-<p>
-To foster the development of the Linked Data Platform specification, this document includes 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.
- The starting point for the development of these use cases is a collection of user stories that provide realistic examples describing how people may use read-write Linked Data. The use cases themselves are captured in a narrative style that describes a
- behavior, or set of behaviors based on, and using scenarios from, these user stories. The aim throughout has been to avoid details of protocol (specifically
- the HTTP protocol), and use of any specific vocabulary that might be introduced by the
- <abbr title="Linked Data Platform">LDP</abbr> specification.
-</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 document was published by the <a href="http://www.w3.org/2012/ldp">Linked Data Platform Working Group</a> as a 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@w3.org">public-ldp@w3.org</a>
- (<a href="mailto:public-ldp-request@w3.org?subject=subscribe">subscribe</a>,
- <a href="http://lists.w3.org/Archives/Public/public-ldp/">archives</a>).
-
-
-
-
- All comments are welcome.</p>
-
-
- <p>
- Publication as a 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 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="#scope-and-motivation" class="tocxref"><span class="secno">1. </span>Scope and Motivation</a></li><li class="tocline"><a href="#organization-of-this-document" class="tocxref"><span class="secno">2. </span>Organization of this Document</a></li><li class="tocline"><a href="#user-stories" class="tocxref"><span class="secno">3. </span>User Stories</a><ul class="toc"><li class="tocline"><a href="#maintaining-social-contact-information" class="tocxref"><span class="secno">3.1 </span><span>Maintaining Social Contact Information</span></a></li><li class="tocline"><a href="#keeping-track-of-personal-and-business-relationships" class="tocxref"><span class="secno">3.2 </span><span>Keeping Track of Personal and Business Relationships</span></a></li><li class="tocline"><a href="#system-and-software-development-tool-integration" class="tocxref"><span class="secno">3.3 </span><span>System and Software Development Tool Integration</span></a></li><li class="tocline"><a href="#library-linked-data" class="tocxref"><span class="secno">3.4 </span><span>Library Linked Data</span></a></li><li class="tocline"><a href="#municipality-operational-monitoring" class="tocxref"><span class="secno">3.5 </span><span>Municipality Operational Monitoring</span></a></li><li class="tocline"><a href="#healthcare" class="tocxref"><span class="secno">3.6 </span><span>Healthcare</span></a></li><li class="tocline"><a href="#metadata-enrichment-in-broadcasting" class="tocxref"><span class="secno">3.7 </span><span>Metadata Enrichment in Broadcasting</span></a></li><li class="tocline"><a href="#aggregation-and-mashups-of-infrastructure-data" class="tocxref"><span class="secno">3.8 </span><span>Aggregation and Mashups of Infrastructure Data</span></a></li><li class="tocline"><a href="#sharing-payload-of-rdf-data-among-low-end-devices" class="tocxref"><span class="secno">3.9 </span><span>Sharing Payload of RDF Data Among Low-End Devices</span></a></li><li class="tocline"><a href="#sharing-binary-resources-and-metadata" class="tocxref"><span class="secno">3.10 </span><span>Sharing Binary Resources and Metadata</span></a></li><li class="tocline"><a href="#data-catalogs" class="tocxref"><span class="secno">3.11 </span><span>Data Catalogs</span></a></li><li class="tocline"><a href="#constrained-devices-and-networks" class="tocxref"><span class="secno">3.12 </span><span>Constrained Devices and Networks</span></a></li><li class="tocline"><a href="#services-supporting-the-process-of-science" class="tocxref"><span class="secno">3.13 </span><span>Services Supporting the Process of Science</span></a></li><li class="tocline"><a href="#project-membership-information" class="tocxref"><span class="secno">3.14 </span><span>Project Membership Information</span></a></li><li class="tocline"><a href="#cloud-infrastructure-management" class="tocxref"><span class="secno">3.15 </span><span>Cloud Infrastructure Management</span></a></li></ul></li><li class="tocline"><a href="#use-cases" class="tocxref"><span class="secno">4. </span>Use Cases</a><ul class="toc"><li class="tocline"><a href="#uc1" class="tocxref"><span class="secno">4.1 </span><span>UC1</span>: Compose resources</a><ul class="toc"><li class="tocline"><a href="#s1.1" class="tocxref"><span class="secno">4.1.1 </span>Primary scenario: create a container</a></li><li class="tocline"><a href="#s1.2" class="tocxref"><span class="secno">4.1.2 </span>Alternative scenario: create a nested container</a></li><li class="tocline"><a href="#s1.3" class="tocxref"><span class="secno">4.1.3 </span>Alternative scenario: Delete a container</a></li></ul></li><li class="tocline"><a href="#uc2" class="tocxref"><span class="secno">4.2 </span><span>UC2</span>: Manage resource lifecycle</a><ul class="toc"><li class="tocline"><a href="#s2.1" class="tocxref"><span class="secno">4.2.1 </span>Primary scenario: create resource</a></li><li class="tocline"><a href="#s2.2" class="tocxref"><span class="secno">4.2.2 </span>Alternative scenario: delete resource</a></li><li class="tocline"><a href="#s2.3" class="tocxref"><span class="secno">4.2.3 </span>Alternative scenario: moving contained resources</a></li></ul></li><li class="tocline"><a href="#uc3" class="tocxref"><span class="secno">4.3 </span><span>UC3</span>: Retrieve resource description</a><ul class="toc"><li class="tocline"><a href="#s3.1" class="tocxref"><span class="secno">4.3.1 </span>Primary scenario: retrieve resource description</a></li><li class="tocline"><a href="#s3.2" class="tocxref"><span class="secno">4.3.2 </span>Alternative scenario: retrieve description of a non-document resource (hash URI)</a></li></ul></li><li class="tocline"><a href="#uc4" class="tocxref"><span class="secno">4.4 </span><span>UC4</span>: Update existing resource</a><ul class="toc"><li class="tocline"><a href="#s4.1" class="tocxref"><span class="secno">4.4.1 </span>Primary scenario: enrichment</a></li><li class="tocline"><a href="#s4.2" class="tocxref"><span class="secno">4.4.2 </span>Alternative scenario: selective update of a resource</a></li></ul></li><li class="tocline"><a href="#uc5" class="tocxref"><span class="secno">4.5 </span><span>UC5</span>: Determine if a resource has changed</a><ul class="toc"><li class="tocline"><a href="#s5.1" class="tocxref"><span class="secno">4.5.1 </span>Primary scenario: determine if a resource has changed</a></li></ul></li><li class="tocline"><a href="#uc6" class="tocxref"><span class="secno">4.6 </span><span>UC6</span>: Aggregate resources</a><ul class="toc"><li class="tocline"><a href="#s6.1" class="tocxref"><span class="secno">4.6.1 </span>Primary scenario: add a resource to a collection</a></li><li class="tocline"><a href="#s6.2" class="tocxref"><span class="secno">4.6.2 </span>Alternative scenario: add a resource to multiple collections</a></li></ul></li><li class="tocline"><a href="#uc7" class="tocxref"><span class="secno">4.7 </span><span>UC7</span>: Filter resource description</a><ul class="toc"><li class="tocline"><a href="#s7.1" class="tocxref"><span class="secno">4.7.1 </span>Primary scenario: retrieve collection-level description</a></li><li class="tocline"><a href="#s7.2" class="tocxref"><span class="secno">4.7.2 </span>Alternative scenario: retrieve item-level description of a collection</a></li></ul></li><li class="tocline"><a href="#uc8" class="tocxref"><span class="secno">4.8 </span><span>UC8</span>: Retrieve a large resource description in multiple parts</a><ul class="toc"><li class="tocline"><a href="#s8.1" class="tocxref"><span class="secno">4.8.1 </span>Primary scenario: Pagination</a></li></ul></li><li class="tocline"><a href="#uc9" class="tocxref"><span class="secno">4.9 </span><span>UC9</span>: Manage binary resources</a><ul class="toc"><li class="tocline"><a href="#s9.1" class="tocxref"><span class="secno">4.9.1 </span>Primary scenario: access binary resources</a></li><li class="tocline"><a href="#s9.2" class="tocxref"><span class="secno">4.9.2 </span>Alternative scenario: media-resource attachments</a></li></ul></li></ul></li><li class="tocline"><a href="#requirements" class="tocxref"><span class="secno">5. </span>Requirements</a><ul class="toc"><li class="tocline"><a href="#functional-requirements" class="tocxref"><span class="secno">5.1 </span>Functional Requirements</a></li><li class="tocline"><a href="#non-functional-requirements" class="tocxref"><span class="secno">5.2 </span>Non-Functional Requirements</a></li></ul></li><li class="tocline"><a href="#acknowledgements-1" class="tocxref"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">B. </span>References</a><ul class="toc"><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">B.1 </span>Informative references</a></li></ul></li></ul></section>
-
-
-
-<section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="scope-and-motivation">
-<!--OddPage--><h2 id="scope" aria-level="1" role="heading"><span class="secno">1. </span>Scope and Motivation</h2>
- <p>
- Linked Data was defined by Tim Berners-Lee with the following
- guidelines [<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 (RDF*, SPARQL)</li>
- <li>Include links to other URIs. so that they can discover
- more things</li>
- </ol>
- <p>These four rules have proven very effective in guiding and
- inspiring people to publish Linked Data on the web. The amount of
- data, especially public data, available on the web has grown
- rapidly, and an impressive number of extremely creative and useful
- “mashups” have been created using this data as result.</p>
-
- <p>The goal for the [<cite><a class="bibref" href="#bib-LINKED-DATA-PLATFORM">LINKED-DATA-PLATFORM</a></cite>] is
- to define a specification required to allow the definition of a
- writable Linked Data API equivalent to the simple application APIs
- that are often written on the web today using the Atom Publishing
- Protocol (APP), which shares some characteristics with Linked Data
- such as the use of HTTP and URLs but relying on a flexible data model based on RDF that allows for
- multiple representations.</p>
-
-</section>
-
-<section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="organization-of-this-document">
-<!--OddPage--><h2 id="org" aria-level="1" role="heading"><span class="secno">2. </span>Organization of this Document</h2>
- <p>This document is organized as follows:</p>
- <ul>
- <li><b><a href="#userstories" title="User Stories">User Stories</a></b>
- capture statements about system requirements written from a user
- or application perspective. They are typically lightweight and
- informal and can run from one line to a paragraph or two
- (sometimes described as an 'epic') [<cite><a class="bibref" href="#bib-COHN-2004">COHN-2004</a></cite>].
- This document redacts a number of user stories around the theme of read/writeable linked data.
- Analysis of each user story reveals a
- number of (functional) use cases and other non-functional
- requirements. See <em>Device API Access Control Use Cases and Requirements</em> [<cite><a class="bibref" href="#bib-DAP-REQS">DAP-REQS</a></cite>] for a good example
- of user stories and their analysis.</li>
- </ul>
- <ul>
- <li><b><a href="#usecases" title="Use Cases">Use Cases</a></b> are
- used to capture and model functional requirements. Use cases
- describe the system’s behavior under various conditions [<cite><a class="bibref" href="#bib-COCKBURN-2000">COCKBURN-2000</a></cite>],
- cataloging who does what with the system, for what purpose, but
- without concern for system design or implementation. Each use case is identified by a
- reference number to aid cross-reference from other documentation;
- use case indexing in this document is based on rdb2rdf
- use cases [<cite><a class="bibref" href="#bib-RDB2RDF-UC">RDB2RDF-UC</a></cite>]. A variety of styles may be used to capture use cases,
- from a simple narrative to a structured description with actors,
- pre/post conditions, step-by-step behaviors (as in <em>POWDER:
- Use Cases and Requirements</em> [<cite><a class="bibref" href="#bib-POWDER-USE-CASES">POWDER-USE-CASES</a></cite>]), and non-functional requirements
- raised by the use case.</li>
- </ul>
- <ul>
- <li><b>Scenarios</b> are used to model the functional requirements of a use case and focus on a use case in action. Scenarios may range from
- lightweight narratives as seen in <em>Use
- cases and requirements for Media Fragments</em> [<cite><a class="bibref" href="#bib-MEDIA-FRAGMENTS-REQS">MEDIA-FRAGMENTS-REQS</a></cite>], to being formally
- modeled as interaction diagrams. Each use case includes at
- least a primary scenario, and possibly other alternative
- scenarios.</li>
- </ul>
- <ul>
- <li><b><a href="#reqs" title="Requirements">Requirements</a></b>
- list functional and non-functional or quality requirements, and the use cases
- they may be derived from. This approach is exemplified in the <em>Use Cases and Requirements for the Data
- Catalog Vocabulary</em> [<cite><a class="bibref" href="#bib-DCAT-UCR">DCAT-UCR</a></cite>].</li>
- </ul>
-</section>
-
-<section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="user-stories">
-<!--OddPage--><h2 id="userstories" aria-level="1" role="heading"><span class="secno">3. </span>User Stories</h2>
-
- <section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="maintaining-social-contact-information">
- <h3 id="story-social" aria-level="2" role="heading"><span class="secno">3.1 </span><dfn id="dfn-maintaining-social-contact-information">Maintaining Social Contact Information</dfn></h3>
- <p>Many of us have multiple email accounts that include
- information about the people and organizations we interact with –
- names, email addresses, telephone numbers, instant messenger
- identities and so on. When someone’s email address or telephone
- number changes (or they acquire a new one), our lives would be
- much simpler if we could update that information in one spot and
- all copies of it would automatically be updated. In other words,
- those copies would all be linked to some definition of “the
- contact.” There might also be good reasons (like off-line email
- addressing) to maintain a local copy of the contact, but ideally
- any copies would still be linked to some central “master.”</p>
- <p>Agreeing on a format for “the contact” is not enough,
- however. Even if all our email providers agreed on the format of a
- contact, we would still need to use each provider’s custom
- interface to update or replace the provider’s copy, or we would
- have to agree on a way for each email provider to link to the
- “master”. If we look outside our own personal interests, it would
- be even more useful if the person or organization exposed their
- own contact information so we could link to it.</p>
- <p>
- What would work in either case is a common understanding of the
- resource, a few formats needed, and access guidance for these
- resources. This would support how to acquire a link to a contact,
- how to use those links to interact with a contact (including <a href="#uc3" title="">reading</a>,
- <a href="#uc4" title="">updating</a>,
- and <a href="#s2.2" title="">deleting</a>
- it), as well as how to easily <a href="#s2.1" title="">create a
- new contact</a>, add it to my contacts, and when deleting a
- contact, how it would be removed from my list of contacts. It
- would also be good to be able to add some application-specific
- data about my contacts that the original design didn’t consider.
- Ideally we’d like to eliminate multiple copies of contacts, there
- would be additional valuable information about my contacts that
- may be stored on separate servers and need a simple way to link
- this information back to the contacts. Regardless of whether a
- contact collection is my own, shared by an organization, or all
- contacts known to an email provider (or to a single email account
- at an email provider), it would be nice if they all worked pretty
- much the same way.
- </p>
- </section>
-
- <section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="keeping-track-of-personal-and-business-relationships">
- <h3 id="story-tracking_relationships" aria-level="2" role="heading"><span class="secno">3.2 </span><dfn id="dfn-keeping-track-of-personal-and-business-relationships">Keeping Track of Personal and Business Relationships</dfn></h3>
- <p>In our daily lives, we deal with many different
- organizations in many different relationships, and they each have
- data about us. However, it is unlikely that any one organization
- has all the information about us. Each of them typically gives us
- access to the information (at least some of it), many through
- websites where we are uniquely identified by some string – an
- account number, user ID, and so on. We have to use their
- applications to interact with the data about us, and we
- have to use their identifier(s) for us.</p>
- <p>
- Would it not be simpler if at least the Web-addressable portion of
- that data could be linked to consistently, so that instead of
- maintaining various identifiers in different formats and instead
- of having to manually supply those identifiers to each one’s
- corresponding custom application, we could essentially build a set
- of bookmarks to it all? When we want to <a href="#uc3" title="">examine</a>
- or <a href="#uc4" title="">change</a>
- their contents, would it not be simpler if there were a single
- consistent application interface that they all supported?
- </p>
- <p>
- The information held by any single organization might be a mix of
- simple data and <a href="#uc6" title="">collections
- of other data</a>, for example, a bank account balance and a
- collection of historical transactions. Our bank might easily have
- <a href="#s1.2" title="">a collection of accounts for each member of its collection
- of customers</a>.
- </p>
- </section>
-
- <section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="system-and-software-development-tool-integration">
- <h3 id="story-oslc" aria-level="2" role="heading"><span class="secno">3.3 </span><dfn id="dfn-system-and-software-development-tool-integration">System and Software Development Tool Integration</dfn></h3>
- <p>System and software development tools typically come from a
- diverse set of vendors and are built on various architectures and
- technologies. These tools are purpose built to meet the needs for
- a specific domain scenario (modeling, design, requirements and so
- on.) Often tool vendors view integrations with other tools as a
- necessary evil rather than providing additional value to their
- end-users. Even more of an afterthought is how these tools’ data
- -- such as people, projects, customer-reported problems and needs
- -- integrate and relate to corporate and external applications
- that manage data such as customers, business priorities and market
- trends. The problem can be isolated by standardizing on a small
- set of tools or a set of tools from a single vendor, but this
- rarely occurs and if does it usually does so only within small
- organizations. As these organizations grow both in size and
- complexity, they have needs to work with outsourced development
- and diverse internal other organizations with their own set of
- tools and processes. There is a need for better support of more
- complete business processes (system and software development
- processes) that span the roles, tasks, and data addressed by
- multiple tools. This demand has existed for many years, and the
- tools vendor industry has tried several different architectural
- approaches to address the problem. Here are a few:</p>
- <ul>
- <li>Implement an API for each application, and then, in each
- application, implement “glue code” that exploits the APIs of
- other applications to link them together.</li>
- <li>Design a single database to store the data of multiple
- applications, and implement each of the applications against this
- database. In the software development tools business, these
- databases are often called “repositories.”</li>
- <li>Implement a central “hub” or “bus” that orchestrates the
- broader business process by exploiting the APIs described
- previously.</li>
- </ul>
- <p>
- It is fair to say that although each of those approaches has its
- adherents and can point to some successes, none of them is wholly
- satisfactory. The use of Linked Data as an application integration
- technology has a strong appeal [<cite><a class="bibref" href="#bib-OSLC">OSLC</a></cite>].
- </p>
- </section>
-
- <section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="library-linked-data">
- <h3 id="story-lld" aria-level="2" role="heading"><span class="secno">3.4 </span><dfn id="dfn-library-linked-data">Library Linked Data</dfn></h3>
- <p>
- The <abbr title="World Wide Web Consortium">W3C</abbr> Library Linked Data Working Group has a number of use
- cases cited in their <em>Use Case Report</em> [<cite><a class="bibref" href="#bib-LLD-UC">LLD-UC</a></cite>]. These referenced use cases focus on the
- need to extract and correlate library data from disparate sources.
- Variants of these use cases that can provide consistent formats,
- as well as ways to improve or update the data, would enable
- simplified methods for both efficiently sharing this data as well
- as producing incremental updates without the need for repeated
- full extractions and import of data.
- </p>
- <p>The 'Digital Objects Cluster' contains a number of relevant
- use cases:</p>
- <ul>
- <li>Grouping: This should "Allow the end-users to define <a href="#uc6" title="">groups of resources</a>
- on the web that for some reason belong together. The relationship
- that exists between the resources is often left unspecified. Some
- of the resources in a group may not be under control of the
- institution that defines the groups."
- </li>
- </ul>
- <ul>
- <li>Enrichment: "Enable end-users to <a href="#uc4" title="">link resources
- together</a>."
- </li>
- </ul>
- <ul>
- <li>Browsing: "<a href="#uc7" title="">Support end-user browsing through groups</a> and
- resources that belong to the groups."
- </li>
- </ul>
- <ul>
- <li>Re-use: "Users should have the capability to re-use all
- or parts of a collection, with all or part of its metadata,
- elsewhere on the linked Web."</li>
- </ul>
- <p>The 'Collections' cluster also contains a number of relevant
- use cases:</p>
- <ul>
- <li>Collection-level description: "Provide <a href="#uc7" title="">metadata
- pertaining to a collection as a whole</a>, in contrast to item-level
- description."
- </li>
- </ul>
- <ul>
- <li>Collections discovery: "Enable innovative collection
- discovery such as identification of nearest location of a
- physical collection where a specific information resource is
- found or mobile device applications ... based on collection-level
- descriptions."</li>
- </ul>
- <ul>
- <li>Community information services: Identify and classify
- collections of special interest to the community.</li>
- </ul>
- </section>
-
- <section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="municipality-operational-monitoring">
- <h3 id="story-meter_monitoring" aria-level="2" role="heading"><span class="secno">3.5 </span><dfn id="dfn-municipality-operational-monitoring">Municipality Operational Monitoring</dfn></h3>
- <p>
- Across various cities, towns, counties, and various municipalities
- there is a growing number of services managed and run by
- municipalities that produce and consume a vast amount of
- information. This information is used to help monitor services,
- predict problems, and handle logistics. In order to effectively
- and efficiently collect, produce, and analyze all this data, a
- fundamental set of loosely coupled standard data sources are
- needed. A simple, low-cost way to <a href="#uc3" title="">expose
- data</a> from the diverse set of monitored services is needed, one
- that can easily integrate into the municipalities of other systems
- that inspect and analyze the data. All these services have links
- and dependencies on other data and services, so having a simple
- and scalable linking model is key.
- </p>
- </section>
-
- <section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="healthcare">
- <h3 id="story-healthcare" aria-level="2" role="heading"><span class="secno">3.6 </span><dfn id="dfn-healthcare">Healthcare</dfn></h3>
- <p>For physicians to analyze, diagnose, and propose treatment
- for patients requires a vast amount of complex, changing and
- growing knowledge. This knowledge needs to come from a number of
- sources, including physicians’ own subject knowledge, consultation
- with their network of other healthcare professionals, public
- health sources, food and drug regulators, and other repositories
- of medical research and recommendations.</p>
- <p>To diagnose a patient’s condition requires current data on
- the patient’s medications and medical history. In addition, recent
- pharmaceutical advisories about these medications are linked into
- the patient’s data. If the patient experiences adverse effects
- from medications, these physicians need to publish information
- about this to an appropriate regulatory source. Other medical
- professionals require access to both validated and emerging
- effects of the medication. Similarly, if there are geographical
- patterns around outbreaks that allow both the awareness of new
- symptoms and treatments, this information needs to quickly reach a
- very distributed and diverse set of medical information systems.
- Also, reporting back to these regulatory agencies regarding new
- occurrences of an outbreak, including additional details of
- symptoms and causes, is critical in producing the most effective
- treatment for future incidents.</p>
- </section>
-
- <section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="metadata-enrichment-in-broadcasting">
- <h3 id="story-media" aria-level="2" role="heading"><span class="secno">3.7 </span><dfn id="dfn-metadata-enrichment-in-broadcasting">Metadata Enrichment in Broadcasting</dfn></h3>
- <p>
- There are many different use cases when broadcasters show interest
- in metadata <a href="#uc4" title="">
- enrichment</a>:
- </p>
- <ul>
- <li>enrich archive or news metadata by linking facts, events,
- locations and personalities</li>
- <li>enrich metadata generated by automatic extraction tools
- such as person identification, etc.</li>
- <li>enrich definitions of terms in classification schemes or
- enumeration lists</li>
- </ul>
- <p>This comes in support of more effective information
- management and data/content mining (if you can't find your
- content, it's like you don't have it and must either recreate or
- acquire it again, which is not financially effective).</p>
- <p>However, there is a need for solutions facilitating linkage
- to other data sources and taking care of the issues such as
- discovery, automation, disambiguation, etc. Other important issues
- that broadcasters would face are the editorial quality of the
- linked data, its persistence, and usage rights.</p>
- </section>
-
- <section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="aggregation-and-mashups-of-infrastructure-data">
- <h3 id="story-mashup" aria-level="2" role="heading"><span class="secno">3.8 </span><dfn id="dfn-aggregation-and-mashups-of-infrastructure-data">Aggregation and Mashups of Infrastructure Data</dfn></h3>
- <p>
- For infrastructure management (such as storage systems, virtual
- machine environments, and similar IaaS and PaaS concepts), it is
- important to provide an environment in which information from
- different sources can be <a href="#uc6" title="">aggregated</a>, <a href="#uc7" title="">filtered</a>,
- and visualized effectively. Specifically, the following use cases
- need to be taken into account:
- </p>
- <ul>
- <li>While some data sources are based on Linked Data, others
- are not, and aggregation and mashups must work across these
- different sources.</li>
- <li>Consumers of the data sources and aggregated/filtered
- data streams are not necessarily implementing Linked Data
- themselves, they may be off-the-shelf components such as
- dashboard frameworks for composing visualizations.</li>
- <li>Simple versions of this scenario are pull-based, where
- the data is requested from data sources. In more advanced
- settings, without a major change in architecture it should be
- possible to move to a push-based interaction model, where data
- sources push notifications to subscribers, and data sources
- provide different services that consumers can subscribe to (such
- as "informational messages" or "critical alerts only").</li>
- </ul>
- <p>In this scenario, the important factors are to have
- abstractions that allow easy aggregation and filtering, are
- independent from the internal data model of the sources that are
- being combined, and can be used for pull-based interactions as
- well as for push-based interactions.</p>
- </section>
-
- <section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="sharing-payload-of-rdf-data-among-low-end-devices">
- <h3 id="story-low-end_devices" aria-level="2" role="heading"><span class="secno">3.9 </span><dfn id="dfn-sharing-payload-of-rdf-data-among-low-end-devices">Sharing Payload of RDF Data Among Low-End Devices</dfn></h3>
- <p>
- Several projects around the idea of <em>downscaling the Semantic Web</em> need to be able to ship payloads of RDF across
- the nodes member of a given network. The transfers are done in a
- constrained context in terms of bandwidth, scope of the local
- semantics employed by the nodes and computing capabilities of the
- nodes. In a P2P style, every node has the capability to act either
- as a data consumer or a data provider, serving its own data or
- acting as a relay to pass other's data along (typically in mesh
- networks).
- </p>
- <p>The transfer of an arbitrary payload of RDF data could be
- implemented through a container mechanism, adding and removing
- sets of RDF triples to it. Currently, the
- SemanticXO [<cite><a class="bibref" href="#bib-XO">XO</a></cite>] project uses named graphs and the graph store protocol to
- create/delete/copy graphs across the nodes but this (almost)
- imposes the usage of a triple store. Unfortunately, triple stores
- are rather demanding pieces of software that are not always usable
- on limited hardware. Some generic REST-like interaction backed up
- with a lightweight column store would be a better approach.</p>
- </section>
-
- <section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="sharing-binary-resources-and-metadata">
- <h3 id="story-binary_and_metadata" aria-level="2" role="heading"><span class="secno">3.10 </span><dfn id="dfn-sharing-binary-resources-and-metadata">Sharing Binary Resources and Metadata</dfn></h3>
- <p>When publishing datasets about stars one may want to publish
- links to the pictures in which those stars appear, and this may
- well require publishing the pictures themselves. Vice versa: when
- publishing a picture of space we need to know which telescope took
- the picture, which part of the sky it was pointing at, what
- filters were used, which identified stars are visible, who can
- read it, who can write to it.</p>
- <p>If Linked Data contains information about resources that are
- most naturally expressed in non-RDF formats (be they binary such
- as pictures or videos, or human readable documents in XML
- formats), those non-RDF formats should be just as easy to publish
- to the LinkedData server as the RDF relations that link those
- resources up. A LinkedData server should therefore allow
- publishing of non-linked data resources too, and make it easy to
- publish and edit metadata about those resources.</p>
- <p>The resource comes in two parts - the image and information
- about the image (which may be in the image file but is better kept external
- to it as it's more general). The information about the image is
- vital. It's a compound item of image data and other data (application
- metadata about the image) that are not distinguished from the
- platform's point-of-view.</p>
- </section>
-
- <section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="data-catalogs">
- <h3 id="story-data_catalogs" aria-level="2" role="heading"><span class="secno">3.11 </span><dfn id="dfn-data-catalogs">Data Catalogs</dfn></h3>
- <p>
- The <em>Asset Description Metadata Schema</em> [<cite><a class="bibref" href="#bib-ADMS">ADMS</a></cite>]
- provides the data model to describe semantic asset repository
- contents, but this leaves many open challenges when building a
- federation of these repositories to serve the need of asset
- reuse. These include accessing and querying individual
- repositories and efficiently retrieving <a href="#uc5" title="">
- updated content</a> without having to retrieve the whole content.
- The Data Warehousing integration approach allows us to cope
- with heterogeneity of sources technologies and to benefit from the
- optimized performance it offers, given that individual
- repositories do not usually change frequently. With Data
- Warehousing, the federation requires one to:
- </p>
- <ul>
- <li>understand the data, i.e. understand their semantic
- descriptions, and other systems.</li>
- <li>seamlessly exchange the semantic assets metadata from
- different repositories</li>
- <li>keep itself up-to-date.</li>
- </ul>
- <p>Repository owners can maintain de-referenceable URIs for
- their repository descriptions and contained assets in a Linked Data
- compatible manner. ADMS provides the necessary data model to
- enable meaningful exchange of data. However, this leaves the
- challenge of efficient access to the data not fully addressed.</p>
- </section>
-
- <section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="constrained-devices-and-networks">
- <h3 id="story-constrained_devices" aria-level="2" role="heading"><span class="secno">3.12 </span><dfn id="dfn-constrained-devices-and-networks">Constrained Devices and Networks</dfn></h3>
- <p>
- Information coming from resource constrained devices in the Web of
- Things [<cite><a class="bibref" href="#bib-WOT">WOT</a></cite>]
- has been identified as a major driver in many domains, from smart
- cities to environmental monitoring to real-time tracking. The
- amount of information produced by these devices is growing
- exponentially and needs to be accessed and integrated in a
- systematic, standardized and cost efficient way. By using the same
- standards as on the Web, integration with applications will be
- simplified and higher-level interactions among resource
- constrained devices, abstracting away heterogeneities, will become
- possible. Up-coming IoT/WoT standards such as '6LowPAN' [<cite><a class="bibref" href="#bib-6LOWPAN">6LOWPAN</a></cite>]
- - IPv6 for resource constrained devices - and the <em>Constrained
- Application Protocol</em> [<cite><a class="bibref" href="#bib-COAP">COAP</a></cite>], which provides a downscaled version of
- HTTP on top of UDP for the use on constrained devices, are already
- at a mature stage. The next step now is to support RESTful
- interfaces also on resource constrained devices, adhering to the
- Linked Data principles. Due to the limited resources available,
- both on the device and in the network (such as bandwidth, energy,
- and memory) a solution based on <em>SPARQL Update</em> [<cite><a class="bibref" href="#bib-RDF-SPARQL-UPDATE">RDF-SPARQL-UPDATE</a></cite>] is at the current point
- in time considered not to be useful and/or feasible. An approach
- based on the HTTP-CoAP Mapping [<cite><a class="bibref" href="#bib-COAP-MAP">COAP-MAP</a></cite>] would enable constrained
- devices to directly participate in a Linked Data-based
- environment.
- </p>
- </section>
-
- <section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="services-supporting-the-process-of-science">
- <h3 id="story-process_of_science" aria-level="2" role="heading"><span class="secno">3.13 </span><dfn id="dfn-services-supporting-the-process-of-science">Services Supporting the Process of Science</dfn></h3>
- <p>Many fields of science now include branches with in silico
- data-intensive methods, e.g. bioinformatics, astronomy. To support
- these new methods we look to move beyond the established platforms
- provided by scientific workflow systems to capture, assist, and
- preserve the complete lifecycle from record of the experiment,
- through local trusted sharing, analysis, dissemination (including
- publishing of experimental data "beyond the PDF"), and re-use.</p>
- <ul>
- <li><a href="#uc6" title="">Aggregations</a>,
- specifically <em>Research Objects (ROs)</em> are exchanged
- between services and clients bringing together workflows, data
- sets, annotations, and provenance.
- </li>
- <li>We need lightweight services that can be simply and easily
- integrated into, and scale across the wide variety of softwares
- and data used in science.
- <ul>
- <li>Foundation services collect and expose ROs for
- storage, modification, exploration, and reuse.</li>
- <li>Services that provide added-value to ROs such as
- seamless import/export from scientific workflow systems,
- automated stability evaluation, or recommendation.</li>
- </ul>
- </li>
- </ul>
- </section>
-
- <section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="project-membership-information">
- <h3 id="story-project_data" aria-level="2" role="heading"><span class="secno">3.14 </span><dfn id="dfn-project-membership-information">Project Membership Information</dfn></h3>
- <p>Information about people and projects changes as roles
- change, as organisations change and as contact details change.
- Finding the current state of a project is important in enabling
- people to contact the right person in the right role. It can also
- be useful to look back and see who was performing what role in the
- past.</p>
- <p>A use of a Linked Data Platform could be to give
- responsibility for managing such information to the project team
- itself, instead of requiring updates to be requested from a centralised
- website administrator.</p>
- <p>This could be achieved with:</p>
- <ul>
- <li>Resource descriptions for each person and project</li>
- <li>A container resource to describe roles/membership in the
- project.</li>
- </ul>
- <p>To retain the history of the project, the old version of a
- resources, including container resources, should be retained so
- there is a need to address both specific items and also have a
- notion of "current".</p>
- <p>Access to information has two aspects:</p>
- <ul>
- <li>Access to the "current" state, regardless of the version
- of the resource description</li>
- <li>Access to historical state, via access to a specific
- version of the resource description</li>
- </ul>
- </section>
-
- <section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="cloud-infrastructure-management">
- <h3 id="story-cloud" aria-level="2" role="heading"><span class="secno">3.15 </span><dfn id="dfn-cloud-infrastructure-management">Cloud Infrastructure Management</dfn></h3>
- <p>Cloud operators offer API support to provide customers with
- remote access for the management of Cloud infrastructure (IaaS).
- Infrastructure consists of Systems, Computers, Networks, Discs,
- etc. The overall structure can be seen as mostly hierarchical,
- (Cloud contains Systems, Systems contain Machines, etc),
- complemented with crossing links (e.g. multiple Machines connected
- to a Network).</p>
- <p>The IaaS scenario makes specific requirements on lifecycle
- management and discovery, handling non-instant changes, history
- capture and query:</p>
- <ul>
- <li>Many aspects of Cloud infrastructure have associated
- lifecycle, e.g. a Computer can be transitioned between Running
- and Shutdown. This should be manageable through the API, which
- should include how a client discovers dynamic lifecycle options
- and thus help steering through an application.</li>
- <li>It is often the case that attaining a new lifecycle state
- is not instantaneous. Clients require a universal mechanism for
- monitoring such changes.</li>
- <li>A facility to retrieve all events in the lifecycle of a
- resource can be useful.</li>
- <li>Query provides the means to interrogate the resources
- behind the API, as well as finding new entry points into the
- application.</li>
- </ul>
- <p>Infrastructure management may be viewed as the manipulation
- of the underlying graph of resources.</p>
- </section>
-
-</section>
-
-<section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="use-cases">
-<!--OddPage--><h2 id="usecases" aria-level="1" role="heading"><span class="secno">4. </span>Use Cases</h2>
-
- <p>The following use cases are each derived from one or more of
- the user stories above. These use cases are explored in detail
- through the development of scenarios, each motivated by some key
- aspect exemplified by a single user story. The examples they
- contain are included purely for illustrative purposes, and should
- not be interpreted normatively.</p>
-
- <section id="uc1" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h3 aria-level="2" role="heading" id="h3_uc1"><span class="secno">4.1 </span><dfn id="dfn-uc1">UC1</dfn>: Compose resources</h3>
- <p>
- A number of user stories introduce the idea of a <em>container</em>
- as a mechanism for composing resources within the
- context of an application. A
- composition would be identified by URI being a linked resource in its own
- right. Its properties may represent the <em>affordances</em>
- of the application, enabling clients to determine what other
- operations they can do. These operations may
- include descriptions of application specific services that can be
- invoked by exchanging RDF documents.
- </p>
- <ul>
- <li><a href="#dfn-nf1.1" class="internalDFN">NF1.1</a>: Provide "access guidance" (affordances) from user story, <a href="#dfn-maintaining-social-contact-information" class="internalDFN">Maintaining Social Contact Information</a>.</li>
- </ul>
-
- <section id="s1.1" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h4 aria-level="3" role="heading" id="h4_s1.1"><span class="secno">4.1.1 </span>Primary scenario: create a container</h4>
- <p>
- Create a new container resource within the <abbr title="Linked Data Platform">LDP</abbr> server. In <a href="#dfn-services-supporting-the-process-of-science" class="internalDFN">Services Supporting the Process of Science</a>,
- <a href="http://www.wf4ever-project.org/" title="http://www.wf4ever-project.org/" rel="nofollow">Research
- Objects</a> are semantically rich aggregations of resources that
- bring together data, methods and people in scientific
- investigations. A basic workflow research object will be created
- to aggregate scientific workflows and their artefacts [<cite><a class="bibref" href="#bib-RESEARCH-OBJECTS">RESEARCH-OBJECTS</a></cite>].
- These artefacts will be added to the research object throughout the project lifecycle of the project.
- </p>
- <p>
- The RDF description below captures the initial state of the research object. For the purposes of the example, we have included the time of creation. It is a linked data resource addressed via URL from which the following RDF can be retrieved. The null-relative URL <code><></code> should be understood as a self-reference to the research object itself.
- </p>
- <div class="example"><div class="example-title"><span>Example 1</span></div><pre class="example"><code>
-@prefix ro: <http://purl.org/wf4ever/ro#> .
-@prefix dct: <http://purl.org/dc/terms/> .
-@prefix ore: <http://www.openarchives.org/ore/> .
-@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
-
-<> a ro:ResearchObject, ore:Aggregation ;
- dct:created "2012-12-01"^^xsd:dateTime .
-</code></pre></div>
- <div>(see functional requirement <a href="#dfn-f1.1" class="internalDFN">F1.1</a>)</div>
- </section>
-
- <section id="s1.2" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h4 aria-level="3" role="heading" id="h4_s1.2"><span class="secno">4.1.2 </span>Alternative scenario: create a nested container</h4>
- <p>
- The motivation for nested containers comes from the <a href="#dfn-system-and-software-development-tool-integration" class="internalDFN">System and Software Development Tool Integration</a> user story. The
- OSLC Change Management vocabulary allows bug reports to have
- attachments referenced by the membership predicate
- <code>oslc_cm:attachment</code>. This may be viewed as nested containment. The <em>top-level-container</em> contains issues, and
- each issue is itself a container of attachments.
- In the example, <code>issue1234</code> is a member of the container <code>top-level-container</code>. In turn, <code>attachment324</code> and <code>attachment251</code> are attachments within <code>issue1234</code>. Treating these as containers makes it easier to manage them as self-contained units.
- </p>
- <div class="example"><div class="example-title"><span>Example 2</span></div><pre class="example"><code>
-@prefix dcterms: <http://purl.org/dc/terms/>.
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
-@prefix oslc_cm: <http://open-services.net/ns/cm#>.
-@prefix : <http://example.org/>.
-
-:top-level-container rdfs:member :issue1234 .
-
-:issue1234 a oslc_cm:ChangeRequest;
- dcterms:identifier "1234";
- dcterms:type "a bug";
- oslc_cm:attachments :attachments.
-
-:attachments a oslc_cm:AttachmentList;
- oslc_cm:attachment :attachment324, :attachment251.
-</code></pre></div>
- <div>(see functional requirement <a href="#dfn-f1.2" class="internalDFN">F1.2</a>)</div>
- </section>
- <section id="s1.3" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h4 aria-level="3" role="heading" id="h4_s1.3"><span class="secno">4.1.3 </span>Alternative scenario: Delete a container</h4>
- If a container can be deleted, it seems natural that any contained resources and nested containers should also be deleted.
- <div>(see functional requirement <a href="#dfn-f1.3" class="internalDFN">F1.3</a>).</div>
- </section>
- </section>
-
- <section id="uc2" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h3 aria-level="2" role="heading" id="h3_uc2"><span class="secno">4.2 </span><dfn id="dfn-uc2">UC2</dfn>: Manage resource lifecycle</h3>
- <p>
- This use case addresses the managed lifecycle of a resource and is
- concerned with resource <em>ownership</em>. The responsibility for
- managing resources belongs to their container. For example, a
- container may accept a request from a client to make a new
- resource. This use case focuses on creation and deletion of
- resources in the context of a container, and the potential for
- transfer of ownership by moving resources between containers. The
- ownership of a resource should always be clear; no resource
- managed in this way should ever be owned by more than one
- container.
- </p>
- <ul>
- <li><a href="#dfn-nf2.1" class="internalDFN">NF2.1</a>: Non-duplication of resources: "Eliminate multiple
- copies", representing resources in a single place from <a href="#dfn-maintaining-social-contact-information" class="internalDFN">Maintaining Social Contact Information</a>.
- </li>
- <li><a href="#dfn-nf2.2" class="internalDFN">NF2.2</a>: Distribution of resources: Linked data "may be stored on
- separate servers" from <a href="#dfn-maintaining-social-contact-information" class="internalDFN">Maintaining Social Contact Information</a>.
- </li>
- <li><a href="#dfn-nf2.3" class="internalDFN">NF2.3</a>: Consistent, global naming: Resources should be "linked to
- consistently, ... instead of maintaining various identifiers in
- different formats" from <a href="#dfn-keeping-track-of-personal-and-business-relationships" class="internalDFN">Keeping Track of Personal and Business Relationships</a>.
- </li>
- </ul>
-
- <section id="s2.1" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h4 aria-level="3" role="heading" id="h4_s2.1"><span class="secno">4.2.1 </span>Primary scenario: create resource</h4>
- <p>
- Resources begin life by being created within a container. From
- user story, <a href="#dfn-maintaining-social-contact-information" class="internalDFN">Maintaining Social Contact Information</a>, It should be
- possible to "easily create a new contact and add it to my
- contacts." This suggests that resource creation is closely linked
- to the application context. The new resource is created in a
- container representing "my contacts." The lifecycle of the
- resource is linked to the lifecycle of it's container. So, for
- example, if "my contacts" is deleted then a user would also
- reasonably expect that all contacts within it would also be
- deleted.
- </p>
- <p>
- Contact details are captured as an RDF description and it's
- properties, including "names, email addresses, telephone numbers,
- instant messenger identities and so on." The description may
- include non-standard RDF; "data about my contacts that the
- original design didn’t consider." The following RDF could be used
- to describe contact information using the FOAF
- vocabulary [<cite><a class="bibref" href="#bib-FOAF">FOAF</a></cite>]. A contact is represented here by a
- <code>foaf:PersonalProfileDocument</code> defining a resource that can be
- created and updated as a single-unit, even though it may describe
- ancillary resources, such as a <code>foaf:Person</code>, below.
- </p>
- <div class="example"><div class="example-title"><span>Example 3</span></div><pre class="example"><code>
-@prefix foaf: <http://xmlns.com/foaf/0.1/> .
-
-<> a foaf:PersonalProfileDocument;
- foaf:PrimaryTopic [
- a foaf:Person;
- foaf:name "Timothy Berners-Lee";
- foaf:title "Sir";
- foaf:firstName "Timothy";
- foaf:surname "Berners-Lee";
- foaf:nick "TimBL", "timbl";
- foaf:homepage <http://www.w3.org/People/Berners-Lee/>;
- foaf:weblog <http://dig.csail.mit.edu/breadcrumbs/blog/4>;
- foaf:mbox <mailto:timbl@w3.org>;
- foaf:workplaceHomepage <http://www.w3.org/>.
- ]
-</code></pre></div>
- <div>(see functional requirement <a href="#dfn-f2.1" class="internalDFN">F2.1</a>)</div>
- </section>
-
- <section id="s2.2" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h4 aria-level="3" role="heading" id="h4_s2.2"><span class="secno">4.2.2 </span>Alternative scenario: delete resource</h4>
- <p>
- Delete a resource and all it's properties. If the resource resides
- within a container it will be removed from that container, however
- other links to the deleted resource may be left as dangling
- references. In the case where the resource is a container, the
- server may also delete any or all contained resources. In normal
- practice, a deleted resource cannot be reinstated. There are
- however, edge-cases where limited undelete may be desirable. Best
- practice states that "Cool URIs don't change" [<cite><a class="bibref" href="#bib-COOLURIS">COOLURIS</a></cite>], which implies that
- deleted URIs shouldn't be recycled.
- </p>
- <div>(see functional requirement <a href="#dfn-f2.2" class="internalDFN">F2.2</a>)</div>
- </section>
-
- <section id="s2.3" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h4 aria-level="3" role="heading" id="h4_s2.3"><span class="secno">4.2.3 </span>Alternative scenario: moving contained resources</h4>
- <p>
- Resources may have value beyond the life of their membership
- in a container. This implies methods to add references to revise
- container membership.
- A change of ownership may or may not imply a change of URI,
- depending upon the naming policy. While assigning a
- new URI to a resource is discouraged [<cite><a class="bibref" href="#bib-WEBARCH">WEBARCH</a></cite>], it is possible to indicate that a
- resource has moved with an appropriate HTTP response.
- </p>
- <div>(see functional requirement <a href="#dfn-f2.3" class="internalDFN">F2.3</a>)</div>
- </section>
- </section>
-
- <section id="uc3" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h3 aria-level="2" role="heading" id="h3_uc3"><span class="secno">4.3 </span><dfn id="dfn-uc3">UC3</dfn>: Retrieve resource description</h3>
- <p>Access the current description of a resource, containing
- properties of that resource and links to related resources. The
- representation may include descriptions of related resources that
- cannot be accessed directly. Depending upon the application, an
- server may enrich the retrieved RDF with additional triples. Examples
- include adding incoming links, <code>owl:sameAs</code> closure and <code>rdf:type</code> closure.
- The HTTP response should also include versioning information (i.e.
- last update or entity tag) so that subsequent updates can ensure
- they are being applied to the correct version.</p>
- <ul>
- <li><a href="#dfn-nf3.1" class="internalDFN">NF3.1</a>: Use standard vocabularies as appropriate to enable a
- "common understanding of the resource" from <a href="#dfn-maintaining-social-contact-information" class="internalDFN">Maintaining Social Contact Information</a>.
- </li>
- <li><a href="#dfn-nf3.2" class="internalDFN">NF3.2</a>: A "scalable linking model is key" from <a href="#dfn-municipality-operational-monitoring" class="internalDFN">Municipality Operational Monitoring</a>.
- </li>
- </ul>
-
- <section id="s3.1" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h4 aria-level="3" role="heading" id="h4_s3.1"><span class="secno">4.3.1 </span>Primary scenario: retrieve resource description</h4>
- <p>
- The user story <a href="#story-project_data" title=""> Project Membership Information</a> discusses the
- representation of information about people and projects. It calls
- for "Resource descriptions for each person and project" allowing
- project teams to review information held about these resources.
- The example below illustrates the kinds of information that might
- be held about organizational structures based on the <a href="http://www.epimorphics.com/web/" title="http://www.epimorphics.com" rel="nofollow">Epimorphics</a>
- organizational ontology [<cite><a class="bibref" href="#bib-ORG-ONT">ORG-ONT</a></cite>].
- </p>
- <p>Examples 4 and 5 below define two resources that would be hosted on an <abbr title="Linked Data Platform">LDP</abbr> server based at
- <http://example.com/>. The representation in Example 4 describes <http://example.com/member1>, while that of Example 5 describes <http://example.com/role>.
- A client reading Example 4 would have to separately retrieve Example 5 in order to get role information such as its descriptive label.
- </p>
- <p>
- Note that the representations of these resources may
- include descriptions of related resources, such as
- <http://www.w3.org/>, that that fall under a completely different authority and
- therefore can't be served directly from the <abbr title="Linked Data Platform">LDP</abbr> server at this location.</p>
- <div>
- <div class="example"><div class="example-title"><span>Example 4</span></div><pre class="example"><code>
-@prefix org: <http://www.w3.org/ns/org#> .
-@prefix owltime: <http://www.w3.org/2006/time> .
-@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
-@base <http://example.com/> .
-
-<member1> a org:Membership ;
- org:member <http://www.w3.org/People/Berners-Lee/card#i> ;
- org:organization http://www.w3.org/> ;
- org:role <director> ;
- org:memberDuring [a owltime:Interval; owltime:hasBeginning [
- owltime:inXSDDateTime "1994-10-01T00:00:00Z"^^xsd:dateTime]] .
-
-<http://www.w3.org/> a org:FormalOrganization ;
- skos:prefLabel "The World Wide Web Consortium"@en ;
- skos:altLabel "W3C" .
-</code></pre></div>
-</div>
-<div>
-<div class="example"><div class="example-title"><span>Example 5</span></div><pre class="example"><code>
-@prefix org: <http://www.w3.org/ns/org#> .
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
-@base <http://example.com/> .
-
-<director> a org:Role ;
- rdfs:label "Director" .
-
-</code></pre></div>
-</div>
- <div>(see functional requirement <a href="#dfn-f3.1" class="internalDFN">F3.1</a>)</div>
- </section>
-
- <section id="s3.2" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h4 aria-level="3" role="heading" id="h4_s3.2"><span class="secno">4.3.2 </span>Alternative scenario: retrieve description of a non-document resource (hash URI)</h4>
- <p>In many cases, the things that are of interest are not
- always the things that are resolvable. The example below
- demonstrates how a FOAF profile may be used to distinguish between
- the person and the profile; the former being the topic of the
- latter. Where the fragment is defined relative to the base, as in this example, the URL including the fragment may be used to access the resource representing the containing document. The HTTP protocol
- requires that the fragment part be stripped off before requesting
- the URI from the server. The client can then read properties of the hash URI <code><#i></code> from the retrieved description.
- </p>
- <div class="example"><div class="example-title"><span>Example 6</span></div><pre class="example"><code>
-@base <http://www.w3.org/People/Berners-Lee/card>
-@prefix foaf: <http://xmlns.com/foaf/0.1/>.
-@prefix dc: <http://purl.org/dc/elements/1.1/>.
-
-<> a foaf:PersonalProfileDocument ;
- dc:title "Tim Berners-Lee's FOAF file" ;
- foaf:homepage <http://www.w3.org/People/Berners-Lee/> ;
- foaf:primaryTopic <#i> .
-</code></pre></div>
- <div>(see functional requirement <a href="#dfn-f3.2" class="internalDFN">F3.2</a>)</div>
- </section>
- </section>
-
- <section id="uc4" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h3 aria-level="2" role="heading" id="h3_uc4"><span class="secno">4.4 </span><dfn id="dfn-uc4">UC4</dfn>: Update existing resource</h3>
- <p>
- Change the RDF description of a <abbr title="Linked Data Platform">LDP</abbr> resource, potentially removing
- or overwriting existing data. This allows applications to <em>enrich</em>
- the representation of a resource by addling additional links to
- other resources.
- </p>
- <ul>
- <li><a href="#dfn-nf4.1" class="internalDFN">NF4.1</a>: Unrestricted vocabulary: It should be possible be "able
- to add ... application-specific data" to resources from <a href="#dfn-maintaining-social-contact-information" class="internalDFN">Maintaining Social Contact Information</a>.
- </li>
- </ul>
-
- <section id="s4.1" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h4 aria-level="3" role="heading" id="h4_s4.1"><span class="secno">4.4.1 </span>Primary scenario: enrichment</h4>
- <p>
- This relates to user story <a href="#dfn-metadata-enrichment-in-broadcasting" class="internalDFN">Metadata Enrichment in Broadcasting</a> and is based on the BBC
- Sports Ontology [<cite><a class="bibref" href="#bib-BBC-SPORT">BBC-SPORT</a></cite>]. The <em>resource-centric</em> view of linked-data
- provides a natural granularity for substituting, or overwriting a
- resource and its data. The simplest kind of update would simply
- replace what is currently known about a resource with a new
- representation.
- </p>
- <p>
- There are two distinct resources in the example
- below; a sporting event and an associated award. The granularity
- of the resource would allow a user to replace the information about the
- award without disturbing the information about the event.
- </p>
- <div class="example"><div class="example-title"><span>Example 7</span></div><pre class="example"><code>
-@prefix : <http://example.com/>.
-@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
-
- :mens_sprint a sport:MultiStageCompetition;
- rdfs:label "Men's Sprint";
- sport:award <#gold_medal> .
-
-<#gold_medal> a sport:Award .
-</code></pre></div>
- <p>The description can be enriched as events unfold, adding a link to
- the winner of the gold medal by substituting the above description
- with the following.</p>
- <div class="example"><div class="example-title"><span>Example 8</span></div><pre class="example"><code>
-@prefix : <http://example.com/>.
-@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
-@prefix foaf: <http://xmlns.com/foaf/0.1/> .
-
- :mens_sprint a sport:MultiStageCompetition;
- rdfs:label "Men's Sprint";
- sport:award <#gold_medal> .
-<#gold_medal> a sport:Award;
- sport:awarded_to [
- a foaf:Agent ;
- foaf:name "Chris Hoy" .
- ] .
-</code></pre></div>
- <div>(see functional requirement <a href="#dfn-f4.1" class="internalDFN">F4.1</a>)</div>
- </section>
-
- <section id="s4.2" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h4 aria-level="3" role="heading" id="h4_s4.2"><span class="secno">4.4.2 </span>Alternative scenario: selective update of a resource</h4>
- <p>
- This relates to user story <a href="#dfn-data-catalogs" class="internalDFN">Data Catalogs</a>. A catalogue is
- described by the following RDF model, based on the Data Catalog Vocabulary [<cite><a class="bibref" href="#bib-vocab-dcat">vocab-dcat</a></cite>] which provides a standard format for representing the metadata held by organizations.
- </p>
- <div class="example"><div class="example-title"><span>Example 9</span></div><pre class="example"><code>
-@prefix : <http://example.com/>.
-@prefix dcat: <http://www.w3.org/ns/dcat#> .
-@prefix dcterms: <http://purl.org/dc/terms/> .
-
- :catalog a dcat:Catalog ;
- dcat:dataset :dataset/001;
- dcterms:issued "2012-12-11"^^xsd:date.
-</code></pre></div>
- <p>
- A catalog may contain multiple datasets, so when linking to new
- datasets it would be simpler and preferable to selectively add
- just the new dataset links. For this example, a Changeset [<cite><a class="bibref" href="#bib-CHANGESET">CHANGESET</a></cite>] might be used to add a new <code>dc:title</code> to the
- dataset. The following update would be directed to the catalogue
- to add an additional dataset.
- </p>
- <div class="example"><div class="example-title"><span>Example 10</span></div><pre class="example"><code>
-@prefix : <http://example.com/>.
-@prefix dcterms: <http://purl.org/dc/terms/> .
-@prefix cs: <http://purl.org/vocab/changeset/schema#> .
-@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
-
-<change1>
- a cs:ChangeSet ;
- cs:subjectOfChange :catalog ;
- cs:createdDate "2012-01-01T00:00:00Z" ;
- cs:changeReason "Update catalog datasets" ;
- cs:addition [
- a rdf:Statement ;
- rdf:subject :catalog ;
- rdf:predicate dcat:dataset ;
- rdf:object :dataset/002 .
- ] .
-</code></pre></div>
- <div>(see functional requirement <a href="#dfn-f4.2" class="internalDFN">F4.2</a>)</div>
- </section>
- </section>
-
- <section id="uc5" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h3 aria-level="2" role="heading" id="h3_uc5"><span class="secno">4.5 </span><dfn id="dfn-uc5">UC5</dfn>: Determine if a resource has changed</h3>
- <p>
- It should be possible to retrieve versioning information about a
- resource (e.g. last modified or entity tag) without having to
- download a representation of the resource. This information can
- then be compared with previous information held about that
- resource to determine if it has changed. This versioning
- information can also be used in subsequent <em>conditional</em>
- requests to ensure they are only applied if the version is
- unchanged.
- </p>
- <ul>
- <li><a href="#dfn-nf5.1" class="internalDFN">NF5.1</a>: Multiple changes to a resource: The <a href="#dfn-project-membership-information" class="internalDFN">Project Membership Information</a> user story is concerned with "access to the 'current' state", as distinct from earlier versions.
- This is particularly relevant to changes which are made with respect to a specific version of the resource description.
- The <abbr title="Linked Data Platform">LDP</abbr> must ensure consistent access in the case of multiple simultaneous attempts to access a resource.
- </li>
- </ul>
-
- <section id="s5.1" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h4 aria-level="3" role="heading" id="h4_s5.1"><span class="secno">4.5.1 </span>Primary scenario: determine if a resource has changed</h4>
- <p>
- Based on the user story, <a href="#dfn-constrained-devices-and-networks" class="internalDFN">Constrained Devices and Networks</a>, an <abbr title="Linked Data Platform">LDP</abbr> server could be configured to
- act as a proxy for a CoAP [<cite><a class="bibref" href="#bib-COAP">COAP</a></cite>] based Web of Things [<cite><a class="bibref" href="#bib-WOT">WOT</a></cite>]. As an observer of CoAP resources, the <abbr title="Linked Data Platform">LDP</abbr> server registers
- its interest so that it will be notified whenever the sensor
- reading changes. Clients of the <abbr title="Linked Data Platform">LDP</abbr> can interrogate the server to
- determine if the state has changed.
- </p>
- <p>
- In this example, the information about a sensor and corresponding
- sensor readings can be represented as RDF resources. The first
- resource below, represents a sensor described using the Semantic
- Sensor Network [<cite><a class="bibref" href="#bib-SSN">SSN</a></cite>] ontology.
- </p>
- <div class="example"><div class="example-title"><span>Example 11</span></div><pre class="example"><code>
-@prefix : <http://example.com/energy-management/>.
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
-@prefix ssn: <http://purl.oclc.org/NET/ssnx/ssn#> .
-
-<> a :MainsFrequencySensor;
- rdfs:comment "Sense grid load based on mains frequency";
- ssn:hasMeasurementCapability [
- a :FrequencyMeasurementCapability;
- ssn:hasMeasurementProperty <#property_1> .
- ] .
-</code></pre></div>
- <p>
- The value of the sensor changes in real-time as measurements are
- taken. The <abbr title="Linked Data Platform">LDP</abbr> client can interrogate the resource below to
- determine if it has changed, <em>without</em> necessarily having to
- download the RDF representation. As different sensor properties
- are represented disjointly (separate RDF representations) they may
- change independently.
- </p>
- <div class="example"><div class="example-title"><span>Example 12</span></div><pre class="example"><code>
-@prefix : <http://example.com/energy-management/> .
-@prefix ssn: <http://purl.oclc.org/NET/ssnx/ssn#> .
-@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
-
-
-<http://example.com/energy-management#property_1> :hasMeasurementPropertyValue <> .
-<> a :FrequencyValue;
- :hasQuantityValue "50"^^xsd:float.
-</code></pre></div>
- <div>(see functional requirement <a href="#dfn-f5.1" class="internalDFN">F5.1</a>)</div>
- </section>
- </section>
-
- <section id="uc6" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h3 aria-level="2" role="heading" id="h3_uc6"><span class="secno">4.6 </span><dfn id="dfn-uc6">UC6</dfn>: Aggregate resources</h3>
- <p>
- There is a requirement to be able to manage <em>collections</em> of
- resources. The concept of a collection overlaps with, but is
- distinct from that of a container. These collections are (weak)
- aggregations, unrelated to the lifecycle management of resources,
- and distinct from the ownership between a resource and its
- container. However, the composition of a container may be
- reflected as a collection to support navigation of the container
- and its contents. There is a need to be able to create collections
- by adding and deleting individual membership properties. Resources
- may belong to multiple collections, or to none.
- </p>
- <ul>
- <li><a href="#dfn-nf6.1" class="internalDFN">NF6.1</a>: Resource descriptions are a "mix of simple data and
- collections" from <a href="#dfn-keeping-track-of-personal-and-business-relationships" class="internalDFN">Keeping Track of Personal and Business Relationships</a>.
- </li>
- <li><a href="#dfn-nf6.2" class="internalDFN">NF6.2</a>: Relative URIs: It should be possible to "ship payloads of
- RDF" for a collection as a whole without breaking internal links
- from <a href="#dfn-constrained-devices-and-networks" class="internalDFN">Constrained Devices and Networks</a>.
- </li>
- </ul>
-
- <section id="s6.1" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h4 aria-level="3" role="heading" id="h4_s6.1"><span class="secno">4.6.1 </span>Primary scenario: add a resource to a collection</h4>
- <p>
- This example is from <a href="#dfn-library-linked-data" class="internalDFN">Library Linked Data</a> and LLD-UC [<cite><a class="bibref" href="#bib-LLD-UC">LLD-UC</a></cite>], specifically <em>Subject Search</em>.
- </p>
- <p>There is an existing collection at
- <http://example.com/concept-scheme/subject-heading> that
- defines a collection of subject headings. This collection is
- defined as a <code>skos:ConceptScheme</code> and the client wishes to insert a
- new concept into the scheme. which will be related to the
- collection via a <code>skos:inScheme</code> link. In the example below, a new subject-heading,
- "outer space exploration" is added to the <code>scheme:subject-heading</code> collection. The following RDF describes the (item-level)
- description of the collection,
- also demonstrating that the relationship between the parent and child resources may run in a seemingly counter-intuitive direction, from child to parent.
- </p>
- <div class="example"><div class="example-title"><span>Example 13</span></div><pre class="example"><code>
-@prefix scheme : <http://example.com/concept-scheme/>.
-@prefix concept : <http://example.com/concept/>.
-@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
-
-scheme:subject-heading a skos:ConceptScheme.
-
-concept:Outer+space+Exploration skos:inScheme scheme:subject-heading.
-</code></pre></div>
- <div>(see functional requirement <a href="#dfn-f6.1" class="internalDFN">F6.1</a>)</div>
- </section>
-
- <section id="s6.2" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h4 aria-level="3" role="heading" id="h4_s6.2"><span class="secno">4.6.2 </span>Alternative scenario: add a resource to multiple collections</h4>
- <p>
- Logically, a resource should not be owned by more than one
- container. However, it may be a member of multiple collections
- which define a weaker form of <em>aggregation</em>. As this is
- simply a manipulation of the RDF description of a collection, it
- should be possible to add the same resource to multiple
- collections.
- </p>
- <p>
- As a machine-readable collection of medical terms, the SNOMED CT ontology [<cite><a class="bibref" href="#bib-SNOMED">SNOMED</a></cite>]
- is of key importance in user story, <a href="#dfn-healthcare" class="internalDFN">Healthcare</a>. SNOMED CT allows concepts with more than one parent. In the example below, SNOMED concepts are treated as
- collections (aggregations) of narrower concepts. We see that the
- concept <code>:TissueSpecimenFromHeart</code> belongs to two parent collections as it is both a <code>:TissueSpecimen</code> and a <code>:SpecimenFromHeart</code>.
- This example also demonstrates how composition and aggregation support different scenarios, as the ability to have multiple parents should not be a possibility with composition.
- </p>
- <div class="example"><div class="example-title"><span>Example 14</span></div><pre class="example"><code>
-@prefix : <http://example.com/snomed/>.
-@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
-
-:TissueSpecimen a skos:Concept ;
- :conceptID "119376003";
- skos:prefLabel "Tissue specimen"
- skos:narrowerTransitive :TissueSpecimenFromHeart.
-
-:SpecimenFromHeart a skos:Concept ;
- :conceptID "127462005";
- skos:prefLabel "Specimen from heart"
- skos:narrowerTransitive :TissueSpecimenFromHeart.
-
-:TissueSpecimenFromHeart a skos:Concept;
- :conceptID "128166000";
- rdfs:label "Tissue specimen from heart".
-</code></pre></div>
- <div>(see functional requirement <a href="#dfn-f6.2" class="internalDFN">F6.2</a>)</div>
- </section>
- </section>
-
- <section id="uc7" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h3 aria-level="2" role="heading" id="h3_uc7"><span class="secno">4.7 </span><dfn id="dfn-uc7">UC7</dfn>: Filter resource description</h3>
- <p>This use case extends the normal behaviour of retrieving an
- RDF description of a resource, by dynamically excluding specific
- (membership) properties. For containers, it is often desirable to
- be able to read a collection, or item-level description that
- excludes the container membership.</p>
-
- <section id="s7.1" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h4 aria-level="3" role="heading" id="h4_s7.1"><span class="secno">4.7.1 </span>Primary scenario: retrieve collection-level description</h4>
- <p>
- This scenario, based on <a href="#dfn-library-linked-data" class="internalDFN">Library Linked Data</a>, uses the Dublin Core Metadata Initiative Collection-Level description [<cite><a class="bibref" href="#bib-DC-COLLECTIONS">DC-COLLECTIONS</a></cite>]. A collection can
- refer to any aggregation of physical or digital items. This
- scenario covers the case whereby a client can request a
- collection-level description as typified by the example below,
- without necessarily having to download a full listing of the items
- within the collection.
- </p>
- <div class="example"><div class="example-title"><span>Example 15</span></div><pre class="example"><code>
-@prefix dc: <http://purl.org/dc/elements/1.1/>.
-@prefix : <http://example.org/bookshelf/>.
-@prefix dcmitype: <http://purl.org/dc/dcmitype/>.
-@prefix cld: <http://purl.org/cld/terms/>.
-@prefix dcterms: <http://purl.org/dc/terms/>.
-
-<> dc:type dcmitype:Collection ;
- dc:title "Directory of organizations working with Linked Data" ;
- dcterms:abstract "This is a directory of organisations specializing in Linked Data."
- cld:isLocatedAt <http://dir.w3.org>
- cld:isAccessedVia <http://dir.w3.org/directory/pages/landing-page.xhtml?view>
-</code></pre></div>
- <div>(see functional requirement <a href="#dfn-f7.1" class="internalDFN">F7.1</a>)</div>
- </section>
-
- <section id="s7.2" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h4 aria-level="3" role="heading" id="h4_s7.2"><span class="secno">4.7.2 </span>Alternative scenario: retrieve item-level description of a collection</h4>
- <p>
- This use case scenario, also based on <a href="#dfn-library-linked-data" class="internalDFN">Library Linked Data</a>,
- focuses on obtaining an item-level description of the resources
- aggregated by a collection. The simplest scenario is where the
- members of a collection are returned within a single
- representation, so that a client can explore the data by following
- these links. Different applications may use different membership
- predicates to capture this aggregation. The example below uses
- <code>rdfs:member</code>, but many different membership predicates are in
- common use, including RDF Lists. Item-level descriptions can be
- captured using the Functional Requirements for Bibliographic
- Records (FRBR) ontology [<cite><a class="bibref" href="#bib-FRBR">FRBR</a></cite>] [<cite><a class="bibref" href="#bib-FRBR-CORE">FRBR-CORE</a></cite>].
- </p>
- <p>
- Based on the example below, the item-level description should include as a minimum all the <code>rdfs:member</code> relationships. It need not include other properties of the collection, and it need not include additional properties of the members.
- </p>
- <div class="example"><div class="example-title"><span>Example 16</span></div><pre class="example"><code>
-@prefix frbr: <http://purl.org/vocab/frbr/core#>.
-@prefix dc: <http://purl.org/dc/elements/1.1/>.
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
-
-<> rdfs:member <#ebooks97>, <#ebooks21279>.
-
-<#work97> a frbr:LiteraryWork;
- dc:title "Flatland: a romance of many dimensions" ;
- frbr:creator <#Abbott_Edwin>;
- frbr:manifestation <ebook97>.
-
-<#work21279> a frbr:LiteraryWork;
- dc:title "2 B R 0 2 B" ;
- frbr:creator <#Vonnegut_Kurt>;
- frbr:manifestation <ebook21279>.
-</code></pre></div>
- <div>(see functional requirement <a href="#dfn-f7.2" class="internalDFN">F7.2</a>)</div>
- </section>
- </section>
-
- <section id="uc8" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h3 aria-level="2" role="heading" id="h3_uc8"><span class="secno">4.8 </span><dfn id="dfn-uc8">UC8</dfn>: Retrieve a large resource description in multiple parts</h3>
-
-<p>This use case addresses a problem with the “resource-centric” approach to interacting with RDF data. The problem is that some resources participate in a very large number of triples, and therefore a “resource-centric” granularity leads to resource descriptions that are too large to be practically processed in a single HTTP request. This use case applies to all resources, not just containers.</p>
-
- <ul>
- <li>It's not really the resource description that's being paginated, but the values of a particular property.</li>
- <li>The server is responsible for pagination, and may decide how large the pages are.</li>
- <li>Pagination should apply symmetrically to both <em>incoming</em> and <em>outgoing</em> properties.</li>
- <li>The next-page URL should be treated as opaque.</li>
- </ul>
-
- <section id="s8.1" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h4 aria-level="3" role="heading" id="h4_s8.1"><span class="secno">4.8.1 </span>Primary scenario: Pagination</h4>
-
-<p>In user story, <a href="#dfn-maintaining-social-contact-information" class="internalDFN">Maintaining Social Contact Information</a>, it is not uncommon for users to have a very large number of contacts.
-This leads to a very large resource description, especially if some basic information about the contacts is included as well. The size of this representation may be so large that retrieval in a single HTTP request is impractical.</p>
-
-<p>In this example the response to the first request includes a reference to the <code>next</code> resource in an ordered collection of resources. For the purposes of the example, we make use of the <code>next</code> property defined by the <a href="http://www.w3.org/1999/xhtml/vocab">XHTML Metainformation Vocabulary</a>. There is no presumption that the <abbr title="Linked Data Platform">LDP</abbr> specification will recommend the use of this vocabulary.</p>
- <div class="example"><div class="example-title"><span>Example 17</span></div><pre class="example"><code>
-@prefix : <http://example.com/people/>.
-@prefix xhv: <http://www.w3.org/1999/xhtml/vocab#>.
-
-:alice a foaf:Person;
- rdfs:label "Alice";
- foaf:mbox <mailto:alice@example.com>.
-
-<> xhv:next <http://example.com/1234567890>.
- </code></pre></div>
-
-<p>When the client requests the resource identified by <code>next</code>, the response includes additional content that can be merged with the earlier data to construct a more complete model of the originally requested resource. It may also contain further <code>next</code> links, which may be requested in turn.</p>
-
-<p>The following representation is the response to the resource identified by <code>next</code>, completing the contacts list.</p>
-
- <div class="example"><div class="example-title"><span>Example 18</span></div><pre class="example"><code>
-@prefix : <http://example.com/people/>.
-
-:bob a foaf:Person;
- rdfs:label "Bob";
- foaf:mbox <mailto:bob@example.com>.
- </code></pre></div>
- <div>(see functional requirement <a href="#dfn-f8.1" class="internalDFN">F8.1</a>)</div>
- </section>
- </section>
-
- <section id="uc9" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h3 aria-level="2" role="heading" id="h3_uc9"><span class="secno">4.9 </span><dfn id="dfn-uc9">UC9</dfn>: Manage binary resources</h3>
- <p>It should be possible to easily add non-RDF binary resources
- to containers that accept them. Binary resources may be updated and
- removed during the lifecycle of the container.</p>
-
- <section id="s9.1" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h4 aria-level="3" role="heading" id="h4_s9.1"><span class="secno">4.9.1 </span>Primary scenario: access binary resources</h4>
- <p>
- From the user story <a href="#dfn-sharing-binary-resources-and-metadata" class="internalDFN">Sharing Binary Resources and Metadata</a> it should be possible to
- easily add non-RDF resources to containers that accept them.
- Clients submit a non-RDF representation to a container in a media
- type accepted by that container. The container creates a URI to
- represent this media resource, and creates a link from the
- container to the new URI. The binary resource may be accompanied by an explicit RDF
- description. It should be possible to find the
- metadata about such a resource and to access and edit it in
- the usual ways.
- </p>
- <p>
- This example uses the Ontology for Media Resources to describe a media resource added to a
- collection [<cite><a class="bibref" href="#bib-MEDIAONT">MEDIAONT</a></cite>].
- </p>
- <div class="example"><div class="example-title"><span>Example 19</span></div><pre class="example"><code>
-@prefix ma: <http://www.w3.org/ns/ma-ont#> .
-
-<dataset> a ma:Collection ;
- ma:hasMember <dataset/image1.jpg>
-
-<dataset/image1.jpg> a ma:MediaResource ;
- ma:hasFormat "image/jpeg" .
-</code></pre></div>
- <div>(see functional requirement <a href="#dfn-f9.1" class="internalDFN">F9.1</a>)</div>
- </section>
-
- <section id="s9.2" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter">
- <h4 aria-level="3" role="heading" id="h4_s9.2"><span class="secno">4.9.2 </span>Alternative scenario: media-resource attachments</h4>
- <p>
- A resource may have multiple <em>renditions</em>. For example, you
- can have a PDF and a JPEG representing the same thing. A user is
- trying to create a work order along with an attached image showing
- a faulty machine part. To the user and to the work order system,
- these two artifacts are managed as a set. A single request may
- create the work order, the attachment, and the relationship
- between them, atomically. When the user retrieves the work order
- later, they expect a single request by default to retrieve the
- work order plus all attachments. When the user updates the work
- order, e.g. to mark it completed, they only want to update the
- work order proper, not its attachments. Users may
- add/remove/replace attachments to the work order during its
- lifetime.
- </p>
- <div>(see functional requirement <a href="#dfn-f9.2" class="internalDFN">F9.2</a>)</div>
- </section>
- </section>
-</section>
-
-<section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="requirements">
-<!--OddPage--><h2 id="reqs" aria-level="1" role="heading"><span class="secno">5. </span>Requirements</h2>
-<p>This section lists the functional and non-functional requirements arising from the use-cases catalogued in this document. Specific requirements that have been de-prioritized or rejected have been left in the document for completeness, but are shown as struck out.</p>
-<section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="functional-requirements">
- <h3 id="reqs-functional" aria-level="2" role="heading"><span class="secno">5.1 </span>Functional Requirements</h3>
- <dl>
- <dt><dfn id="dfn-f1.1">F1.1</dfn>:</dt>
- <dd>The system shall provide the ability to create containers for composing resources, from <a href="#dfn-uc1" class="internalDFN">UC1</a>.
- </dd>
- <dt><dfn id="dfn-f1.2">F1.2</dfn>:</dt>
- <dd>The system shall provide the ability to create nested containers, from <a href="#dfn-uc1" class="internalDFN">UC1</a>.
- </dd>
- <dt><dfn id="dfn-f1.3">F1.3</dfn>:</dt>
- <dd>On deletion of a container, the system shall delete any contained resources and nested containers, from <a href="#dfn-uc1" class="internalDFN">UC1</a>.
- </dd>
- <dt><dfn id="dfn-f2.1">F2.1</dfn>:</dt>
- <dd>The system shall provide the ability to create resources within a container, from <a href="#dfn-uc2" class="internalDFN">UC2</a>.
- </dd>
- <dt><dfn id="dfn-f2.2">F2.2</dfn>:</dt>
- <dd>The system shall provide the ability to delete resources, from <a href="#dfn-uc2" class="internalDFN">UC2</a>.
- </dd>
- <dt><dfn id="dfn-f2.3">F2.3</dfn>:</dt>
- <dd><span style="text-decoration:line-through;">The system shall provide the ability to move resources between containers, from <a href="#dfn-uc2" class="internalDFN">UC2</a></span>.
- </dd>
- <dt><dfn id="dfn-f3.1">F3.1</dfn>:</dt>
- <dd>The system shall provide the ability to retrieve resource descriptions, from <a href="#dfn-uc3" class="internalDFN">UC3</a>.
- </dd>
- <dt><dfn id="dfn-f3.2">F3.2</dfn>:</dt>
- <dd>The system shall enable the client to retrieve the description of a hash URI, from <a href="#dfn-uc3" class="internalDFN">UC3</a>.
- </dd>
- <dt><dfn id="dfn-f4.1">F4.1</dfn>:</dt>
- <dd>The system shall provide the ability to update an existing resource by substitution, from <a href="#dfn-uc4" class="internalDFN">UC4</a>.
- </dd>
- <dt><dfn id="dfn-f4.2">F4.2</dfn>:</dt>
- <dd>The system shall provide the ability to perform a selective update of a resource, from <a href="#dfn-uc4" class="internalDFN">UC4</a>.
- </dd>
- <dt><dfn id="dfn-f5.1">F5.1</dfn>:</dt>
- <dd>The system shall provide the ability to determine if a resource has changed, from <a href="#dfn-uc5" class="internalDFN">UC5</a>.
- </dd>
- <dt><dfn id="dfn-f6.1">F6.1</dfn>:</dt>
- <dd>The system shall provide the ability to aggregate resources, from <a href="#dfn-uc6" class="internalDFN">UC6</a>.
- </dd>
- <dt><dfn id="dfn-f6.2">F6.2</dfn>:</dt>
- <dd>The system shall support the addition of a resource to multiple aggregations, from <a href="#dfn-uc6" class="internalDFN">UC6</a>.
- </dd>
- <dt><dfn id="dfn-f7.1">F7.1</dfn>:</dt>
- <dd>The system shall provide the ability to retrieve a collection-level description of a composition, from <a href="#dfn-uc7" class="internalDFN">UC7</a>.
- </dd>
- <dt><dfn id="dfn-f7.2">F7.2</dfn>:</dt>
- <dd>The system shall provide the ability to retrieve an item-level description of a composition or aggregation, from <a href="#dfn-uc7" class="internalDFN">UC7</a>.
- </dd>
- <dt><dfn id="dfn-f8.1">F8.1</dfn></dt>
- <dd>The system shall provide the ability to retrieve a paginated description of a composition or aggregation, from <a href="#dfn-uc8" class="internalDFN">UC8</a>.
- </dd>
- <dt><dfn id="dfn-f9.1">F9.1</dfn>:</dt>
- <dd>The system shall provide the ability to store and access media resources, from <a href="#dfn-uc9" class="internalDFN">UC9</a>
- </dd>
- <dt><dfn id="dfn-f9.2">F9.2</dfn>:</dt>
- <dd><span style="text-decoration:line-through;">The system shall provide the ability to add media-resource attachments, from <a href="#dfn-uc9" class="internalDFN">UC9</a>.</span>
- </dd>
- </dl>
- </section>
-
- <section typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="non-functional-requirements">
- <h3 id="reqs-non-functional" aria-level="2" role="heading"><span class="secno">5.2 </span>Non-Functional Requirements</h3>
- <dl>
- <dt><dfn id="dfn-nf1.1">NF1.1</dfn>:</dt>
- <dd>The system shall provide access guidance to resources, from <a href="#dfn-uc1" class="internalDFN">UC1</a>.
- </dd>
- <dt><dfn id="dfn-nf2.1">NF2.1</dfn>:</dt>
- <dd>The system shall encourage non-duplication of resources, from <a href="#dfn-uc2" class="internalDFN">UC2</a>.
- </dd>
- <dt><dfn id="dfn-nf2.2">NF2.2</dfn>:</dt>
- <dd>The system shall support distribution of resources, from <a href="#dfn-uc2" class="internalDFN">UC2</a>.
- </dd>
- <dt><dfn id="dfn-nf2.3">NF2.3</dfn>:</dt>
- <dd>The system shall support consistent, global naming, from <a href="#dfn-uc2" class="internalDFN">UC2</a>.
- </dd>
- <dt><dfn id="dfn-nf3.1">NF3.1</dfn>:</dt>
- <dd>The system shall support the use of standard vocabularies where appropriate, from <a href="#dfn-uc3" class="internalDFN">UC3</a>.
- </dd>
- <dt><dfn id="dfn-nf3.2">NF3.2</dfn>:</dt>
- <dd>The system shall provide a scalable linking model, from <a href="#dfn-uc3" class="internalDFN">UC3</a>.
- </dd>
- <dt><dfn id="dfn-nf4.1">NF4.1</dfn>:</dt>
- <dd>The system shall permit unrestricted vocabulary, from <a href="#dfn-uc4" class="internalDFN">UC4</a>.
- </dd>
- <dt><dfn id="dfn-nf5.1">NF5.1</dfn>:</dt>
- <dd>The <abbr title="Linked Data Platform">LDP</abbr> shall ensure consistent access in the case of multiple simultaneous attempts to access a resource, from <a href="#dfn-uc5" class="internalDFN">UC5</a>.
- </dd>
- <dt><dfn id="dfn-nf6.1">NF6.1</dfn>:</dt>
- <dd>The system shall allow resource descriptions that are a "mix of simple data and collections", from <a href="#dfn-uc6" class="internalDFN">UC6</a>.
- </dd>
- <dt><dfn id="dfn-nf6.2">NF6.2</dfn>:</dt>
- <dd>The system shall support relative URIs enabling sharing of collections, from <a href="#dfn-uc6" class="internalDFN">UC6</a>.
- </dd>
- </dl>
- </section>
-</section>
-
-
-<section class="appendix informative" typeof="bibo:Chapter" resource="#ref" rel="bibo:Chapter" id="acknowledgements-1">
-<!--OddPage--><h2 id="acknowledgements" aria-level="1" role="heading"><span class="secno">A. </span>Acknowledgements</h2><p><em>This section is non-normative.</em></p>
-<p>We would like to acknowledge the contributions of user story authors: Christophe Guéret,
-Roger Menday, Eric Prud'hommeaux, Steve Speicher, John Arwe, Kevin Page.</p>
-</section>
-
-<!--section class='appendix informative' id="history">
-<h1>Change History</h1>
-<ul>
- <li>2012-12-14 - Initial ReSpec'ing framework for <a href="http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements">Workgroup working wiki document</a> (SS)</li>
- <li>2012-12-16 - Pulled in and ReSpec'd content from <a href="http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements">Workgroup working wiki document</a> (SS)</li>
- <li>2012-12-16 - Fixed cross section links and initial pass at biblio refs (SS)</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">B. </span>References</h2><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">B.1 </span>Informative references</h3><dl class="bibliography" about=""><dt id="bib-6LOWPAN">[6LOWPAN]</dt><dd rel="dcterms:references"><a href="http://datatracker.ietf.org/wg/6lowpan/"><cite>IPv6 over Low power WPAN</cite></a>. URL: <a href="http://datatracker.ietf.org/wg/6lowpan/">http://datatracker.ietf.org/wg/6lowpan/</a>
-</dd><dt id="bib-ADMS">[ADMS]</dt><dd rel="dcterms:references"><a href="http://joinup.ec.europa.eu/asset/adms/home"><cite>Asset Description Metadata Schema</cite></a>. URL: <a href="http://joinup.ec.europa.eu/asset/adms/home">http://joinup.ec.europa.eu/asset/adms/home</a>
-</dd><dt id="bib-BBC-SPORT">[BBC-SPORT]</dt><dd rel="dcterms:references">J. Rayfield; P. Wilton; S. Oliver. <a href="http://www.bbc.co.uk/ontologies/sport/2011-02-17.shtml"><cite>Sport Ontology</cite></a>. URL: <a href="http://www.bbc.co.uk/ontologies/sport/2011-02-17.shtml">http://www.bbc.co.uk/ontologies/sport/2011-02-17.shtml</a>
-</dd><dt id="bib-CHANGESET">[CHANGESET]</dt><dd rel="dcterms:references">S. Tunnicliffe; I. Davis. <a href="http://vocab.org/changeset/schema.html"><cite>Changeset</cite></a>. URL: <a href="http://vocab.org/changeset/schema.html">http://vocab.org/changeset/schema.html</a>
-</dd><dt id="bib-COAP">[COAP]</dt><dd rel="dcterms:references"><a href="http://tools.ietf.org/html/draft-ietf-core-coap-18"><cite>Constrained Application Protocol</cite></a>. URL: <a href="http://tools.ietf.org/html/draft-ietf-core-coap-18">http://tools.ietf.org/html/draft-ietf-core-coap-18</a>
-</dd><dt id="bib-COAP-MAP">[COAP-MAP]</dt><dd rel="dcterms:references"><a href="http://tools.ietf.org/html/draft-castellani-core-http-mapping-07"><cite>Best Practices for HTTP-CoAP Mapping Implementation</cite></a>. URL: <a href="http://tools.ietf.org/html/draft-castellani-core-http-mapping-07">http://tools.ietf.org/html/draft-castellani-core-http-mapping-07</a>
-</dd><dt id="bib-COCKBURN-2000">[COCKBURN-2000]</dt><dd rel="dcterms:references">Alistair Cockburn. <a href="http://alistair.cockburn.us/get/2465"><cite>Writing Effective Use Cases</cite></a>. 2000. URL: <a href="http://alistair.cockburn.us/get/2465">http://alistair.cockburn.us/get/2465</a>
-</dd><dt id="bib-COHN-2004">[COHN-2004]</dt><dd rel="dcterms:references">Mike Cohn. <a href="http://www.mountaingoatsoftware.com/books/user-stories-applied"><cite>User Stories Applied: For Agile Software Development</cite></a>. 2004. URL: <a href="http://www.mountaingoatsoftware.com/books/user-stories-applied">http://www.mountaingoatsoftware.com/books/user-stories-applied</a>
-</dd><dt id="bib-COOLURIS">[COOLURIS]</dt><dd rel="dcterms:references">Leo Sauermann; Richard Cyganiak. <a href="http://www.w3.org/TR/cooluris"><cite>Cool URIs for the Semantic Web</cite></a>. 3 December 2008. W3C Note. URL: <a href="http://www.w3.org/TR/cooluris">http://www.w3.org/TR/cooluris</a>
-</dd><dt id="bib-DAP-REQS">[DAP-REQS]</dt><dd rel="dcterms:references">Robin Berjon et al. <a href="http://www.w3.org/TR/2009/NOTE-dap-api-reqs-20091015/"><cite>Device API Requirementsml</cite></a>. 15 October 2009. Working Group Note. URL: <a href="http://www.w3.org/TR/2009/NOTE-dap-api-reqs-20091015/">http://www.w3.org/TR/2009/NOTE-dap-api-reqs-20091015/</a>
-</dd><dt id="bib-DC-COLLECTIONS">[DC-COLLECTIONS]</dt><dd rel="dcterms:references"><a href="http://dublincore.org/groups/collections/collection-application-profile/"><cite>Dublin Core Collections Application Profile</cite></a>. URL: <a href="http://dublincore.org/groups/collections/collection-application-profile/">http://dublincore.org/groups/collections/collection-application-profile/</a>
-</dd><dt id="bib-DCAT-UCR">[DCAT-UCR]</dt><dd rel="dcterms:references">R. Cyganiak; F. Maali.. <a href="http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html"><cite>Use Cases and Requirements for the Data Catalog Vocabulary</cite></a>. 16 December 2012. W3C Editor's Draft. URL: <a href="http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html">http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html</a>
-</dd><dt id="bib-FOAF">[FOAF]</dt><dd rel="dcterms:references">Dan Brickley, Libby Miller. <a href="http://xmlns.com/foaf/spec/"><cite>FOAF Vocabulary Specification 0.98.</cite></a> 9 August 2010. URL: <a href="http://xmlns.com/foaf/spec/">http://xmlns.com/foaf/spec/</a>
-</dd><dt id="bib-FRBR">[FRBR]</dt><dd rel="dcterms:references"><a href="http://www.ifla.org/publications/functional-requirements-for-bibliographic-records"><cite>Functional Requirements for Bibliographic Records</cite></a>. URL: <a href="http://www.ifla.org/publications/functional-requirements-for-bibliographic-records">http://www.ifla.org/publications/functional-requirements-for-bibliographic-records</a>
-</dd><dt id="bib-FRBR-CORE">[FRBR-CORE]</dt><dd rel="dcterms:references">I. Davis; R. Newman. <a href="http://vocab.org/frbr/core.html"><cite>Expression of Core FRBR Concepts in RDF</cite></a>. URL: <a href="http://vocab.org/frbr/core.html">http://vocab.org/frbr/core.html</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-LINKED-DATA-PLATFORM">[LINKED-DATA-PLATFORM]</dt><dd rel="dcterms:references">Steve Speicher; John Arwe; Ashok Malhotra. <a href="http://www.w3.org/TR/ldp/"><cite>Linked Data Platform 1.0</cite></a>. 30 July 2013. W3C Last Call Working Draft. URL: <a href="http://www.w3.org/TR/ldp/">http://www.w3.org/TR/ldp/</a>
-</dd><dt id="bib-LLD-UC">[LLD-UC]</dt><dd rel="dcterms:references">D. Vila Suero. <a href="http://www.w3.org/2005/Incubator/lld/XGR-lld-usecase-20111025/"><cite>Library Linked Data Incubartor Group: Use Cases</cite></a>. 25 October 2011. W3C Incubator Group Report. URL: <a href="http://www.w3.org/2005/Incubator/lld/XGR-lld-usecase-20111025/">http://www.w3.org/2005/Incubator/lld/XGR-lld-usecase-20111025/</a>
-</dd><dt id="bib-MEDIA-FRAGMENTS-REQS">[MEDIA-FRAGMENTS-REQS]</dt><dd rel="dcterms:references">Raphaël Troncy; Erik Mannens. <a href="http://www.w3.org/TR/media-frags-reqs"><cite>Use cases and requirements for Media Fragments</cite></a>. 17 December 2009. W3C Working Draft. URL: <a href="http://www.w3.org/TR/media-frags-reqs">http://www.w3.org/TR/media-frags-reqs</a>
-</dd><dt id="bib-MEDIAONT">[MEDIAONT]</dt><dd rel="dcterms:references">WonSuk Lee; Werner Bailer; Tobias Bürger; Pierre-Antoine Champin; Jean-Pierre EVAIN; Véronique Malaisé; Thierry Michel; Felix Sasaki; Joakim Söderberg; Florian Stegmaier; John Strassner. <a href="http://www.w3.org/TR/mediaont-10/"><cite>Ontology for Media Resources 1.0</cite></a>. 9 February 2012. W3C Recommendation. URL: <a href="http://www.w3.org/TR/mediaont-10/">http://www.w3.org/TR/mediaont-10/</a>
-</dd><dt id="bib-ORG-ONT">[ORG-ONT]</dt><dd rel="dcterms:references">D. Reynolds. <a href="http://www.epimorphics.com/public/vocabulary/org.html"><cite>An organization ontology</cite></a>. URL: <a href="http://www.epimorphics.com/public/vocabulary/org.html">http://www.epimorphics.com/public/vocabulary/org.html</a>
-</dd><dt id="bib-OSLC">[OSLC]</dt><dd rel="dcterms:references"><a href="http://open-services.net/"><cite>Open Services for Lifecycle Collaboration</cite></a>. URL: <a href="http://open-services.net/">http://open-services.net/</a>
-</dd><dt id="bib-POWDER-USE-CASES">[POWDER-USE-CASES]</dt><dd rel="dcterms:references">Phil Archer. <a href="http://www.w3.org/TR/powder-use-cases/"><cite>POWDER: Use Cases and Requirements</cite></a>. 31 October 2007. W3C Note. URL: <a href="http://www.w3.org/TR/powder-use-cases/">http://www.w3.org/TR/powder-use-cases/</a>
-</dd><dt id="bib-RDB2RDF-UC">[RDB2RDF-UC]</dt><dd rel="dcterms:references">Eric Prud'hommeaux; Michael Hausenblas. <a href="http://www.w3.org/TR/rdb2rdf-ucr/"><cite>Use Cases and Requirements for Mapping Relational Databases to RDF</cite></a>. 8 June 2010. W3C Working Draft. URL: <a href="http://www.w3.org/TR/rdb2rdf-ucr/">http://www.w3.org/TR/rdb2rdf-ucr/</a>
-</dd><dt id="bib-RDF-SPARQL-UPDATE">[RDF-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-RESEARCH-OBJECTS">[RESEARCH-OBJECTS]</dt><dd rel="dcterms:references">K Belhajjame et al. <a href="http://ceur-ws.org/Vol-903/paper-01.pdf"><cite>Workflow-Centric Research Objects: First Class Citizens in Scholarly Discourse</cite></a>. URL: <a href="http://ceur-ws.org/Vol-903/paper-01.pdf">http://ceur-ws.org/Vol-903/paper-01.pdf</a>
-</dd><dt id="bib-SNOMED">[SNOMED]</dt><dd rel="dcterms:references"><a href="http://www.ihtsdo.org/snomed-ct/"><cite>SNOMED CT</cite></a>. URL: <a href="http://www.ihtsdo.org/snomed-ct/">http://www.ihtsdo.org/snomed-ct/</a>
-</dd><dt id="bib-SSN">[SSN]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/2005/Incubator/ssn/XGR-ssn/"><cite>Semantic Sensor Network XG Final Report</cite></a>. URL: <a href="http://www.w3.org/2005/Incubator/ssn/XGR-ssn/">http://www.w3.org/2005/Incubator/ssn/XGR-ssn/</a>
-</dd><dt id="bib-WEBARCH">[WEBARCH]</dt><dd rel="dcterms:references">Ian Jacobs; Norman Walsh. <a href="http://www.w3.org/TR/webarch/"><cite>Architecture of the World Wide Web, Volume One</cite></a>. 15 December 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/webarch/">http://www.w3.org/TR/webarch/</a>
-</dd><dt id="bib-WOT">[WOT]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/community/wot/"><cite>Web of Things Community Group</cite></a>. URL: <a href="http://www.w3.org/community/wot/">http://www.w3.org/community/wot/</a>
-</dd><dt id="bib-XO">[XO]</dt><dd rel="dcterms:references"><a href="http://worldwidesemanticweb.org/projects/semanticxo/"><cite>SemanticXO</cite></a>. URL: <a href="http://worldwidesemanticweb.org/projects/semanticxo/">http://worldwidesemanticweb.org/projects/semanticxo/</a>
-</dd><dt id="bib-vocab-dcat">[vocab-dcat]</dt><dd rel="dcterms:references">Fadi Maali; John Erickson. <a href="http://www.w3.org/TR/vocab-dcat/"><cite>Data Catalog Vocabulary (DCAT)</cite></a>. 1 August 2013. W3C Last Call Working Draft. URL: <a href="http://www.w3.org/TR/vocab-dcat/">http://www.w3.org/TR/vocab-dcat/</a>
-</dd></dl></section></section></body></html>
\ No newline at end of file
--- a/ldp-ucr-wd.html Mon Jun 16 13:43:01 2014 -0400
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,1631 +0,0 @@
-<!DOCTYPE html>
-<html>
- <head>
- <title>Linked Data Platform Use Cases and Requirements</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: "WD",
-
- // the specification's short name, as in http://www.w3.org/TR/short-name/
- shortName: "ldp-ucr",
- // 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: "2013-10-31",
-
- // 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-01-31",
- previousMaturity: "WD",
- previousURI: "http://www.w3.org/TR/2013/WD-ldp-ucr-20130131/",
-
- // if there a publicly available Editor's Draft, this is the link
- edDraftURI: "http://www.w3.org/2012/ldp/hg/ldp-ucr.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:"Steve Battle", url: "http://stevebattle.me",
- company: "Sysemia Limited", companyURL: "http://www.sysemia.com" },
- { name:"Steve Speicher", url: "http://stevespeicher.me",
- company: "IBM Corporation", companyURL: "http://ibm.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",
-
- // 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: {
- "OSLC": {
- title: "Open Services for Lifecycle Collaboration",
- href: "http://open-services.net/"
- },
- "XO": {
- title: "SemanticXO",
- href: "http://worldwidesemanticweb.org/projects/semanticxo/"
- },
- "ADMS": {
- title: "Asset Description Metadata Schema",
- href: "http://joinup.ec.europa.eu/asset/adms/home",
- publisher: "European Commission"
- },
- "WOT": {
- title: "Web of Things Community Group",
- href: "http://www.w3.org/community/wot/",
- publisher: "W3C"
- },
- "6LOWPAN": {
- title: "IPv6 over Low power WPAN",
- href: "http://datatracker.ietf.org/wg/6lowpan/",
- publisher: "IETF"
- },
- "COAP": {
- title: "Constrained Application Protocol",
- href: "http://tools.ietf.org/html/draft-ietf-core-coap-18",
- publisher: "IETF"
- },
- "COAP-MAP": {
- title: "Best Practices for HTTP-CoAP Mapping Implementation",
- href: "http://tools.ietf.org/html/draft-castellani-core-http-mapping-07",
- publisher: "IETF"
- },
- "CHANGESET": {
- title: "Changeset",
- href: "http://vocab.org/changeset/schema.html",
- "authors": [
- "S. Tunnicliffe",
- "I. Davis"
- ]
- },
- "SSN": {
- title: "Semantic Sensor Network XG Final Report",
- href: "http://www.w3.org/2005/Incubator/ssn/XGR-ssn/",
- publisher: "W3C"
- },
- "SNOMED": {
- title: "SNOMED CT",
- href: "http://www.ihtsdo.org/snomed-ct/",
- publisher: "International Health Terminology Standards Development Organisation (IHTSDO)"
- },
- "DC-COLLECTIONS": {
- title: "Dublin Core Collections Application Profile",
- href: "http://dublincore.org/groups/collections/collection-application-profile/"
- },
- "FRBR": {
- title: "Functional Requirements for Bibliographic Records",
- href: "http://www.ifla.org/publications/functional-requirements-for-bibliographic-records",
- publisher: "International Federation of Library Associations (IFLA)"
- },
- "FRBR-CORE": {
- title: "Expression of Core FRBR Concepts in RDF",
- href: "http://vocab.org/frbr/core.html",
- "authors": [
- "I. Davis",
- "R. Newman"
- ]
- },
- "BBC-SPORT": {
- title: "Sport Ontology",
- href: "http://www.bbc.co.uk/ontologies/sport/2011-02-17.shtml",
- "authors": [
- "J. Rayfield",
- "P. Wilton",
- "S. Oliver"
- ]
- },
- "ORG-ONT": {
- title: "An organization ontology",
- href: "http://www.epimorphics.com/public/vocabulary/org.html",
- "authors": [
- "D. Reynolds"
- ]
- },
- "RESEARCH-OBJECTS": {
- title: "Workflow-Centric Research Objects: First Class Citizens in Scholarly Discourse",
- href: "http://ceur-ws.org/Vol-903/paper-01.pdf",
- "authors": [
- "K Belhajjame et al"
- ]
- }
- }
- };
- </script>
- <style type="text/css">
- div.rule {padding-top: 1em;}
- div.ldp-issue {
- 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-title {
- color: #E05252;
- padding-right: 1em;
- min-width: 7.5em;
- }
- </style>
- </head>
-<body>
-<section id='abstract'>
-<p>
-To foster the development of the Linked Data Platform specification, this document includes 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.
- The starting point for the development of these use cases is a collection of user stories that provide realistic examples describing how people may use read-write Linked Data. The use cases themselves are captured in a narrative style that describes a
- behavior, or set of behaviors based on, and using scenarios from, these user stories. The aim throughout has been to avoid details of protocol (specifically
- the HTTP protocol), and use of any specific vocabulary that might be introduced by the
- <abbr title="Linked Data Platform">LDP</abbr> specification.
-</p>
-</section>
-
-<section id='sotd'>
-</section>
-
-<section>
-<h1 id="scope">Scope and Motivation</h1>
- <p>
- Linked Data was defined by Tim Berners-Lee with the following
- guidelines [[LINKED-DATA]]:
- </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 (RDF*, SPARQL)</li>
- <li>Include links to other URIs. so that they can discover
- more things</li>
- </ol>
- <p>These four rules have proven very effective in guiding and
- inspiring people to publish Linked Data on the web. The amount of
- data, especially public data, available on the web has grown
- rapidly, and an impressive number of extremely creative and useful
- “mashups” have been created using this data as result.</p>
-
- <p>The goal for the [[LINKED-DATA-PLATFORM]] is
- to define a specification required to allow the definition of a
- writable Linked Data API equivalent to the simple application APIs
- that are often written on the web today using the Atom Publishing
- Protocol (APP), which shares some characteristics with Linked Data
- such as the use of HTTP and URLs but relying on a flexible data model based on RDF that allows for
- multiple representations.</p>
-
-</section>
-
-<section>
-<h1 id="org">Organization of this Document</h1>
- <p>This document is organized as follows:</p>
- <ul>
- <li><b><a href="#userstories" title="User Stories">User Stories</a></b>
- capture statements about system requirements written from a user
- or application perspective. They are typically lightweight and
- informal and can run from one line to a paragraph or two
- (sometimes described as an 'epic') [[COHN-2004]].
- This document redacts a number of user stories around the theme of read/writeable linked data.
- Analysis of each user story reveals a
- number of (functional) use cases and other non-functional
- requirements. See <em>Device API Access Control Use Cases and Requirements</em> [[DAP-REQS]] for a good example
- of user stories and their analysis.</li>
- </ul>
- <ul>
- <li><b><a href="#usecases" title="Use Cases">Use Cases</a></b> are
- used to capture and model functional requirements. Use cases
- describe the system’s behavior under various conditions [[COCKBURN-2000]],
- cataloging who does what with the system, for what purpose, but
- without concern for system design or implementation. Each use case is identified by a
- reference number to aid cross-reference from other documentation;
- use case indexing in this document is based on rdb2rdf
- use cases [[RDB2RDF-UC]]. A variety of styles may be used to capture use cases,
- from a simple narrative to a structured description with actors,
- pre/post conditions, step-by-step behaviors (as in <em>POWDER:
- Use Cases and Requirements</em> [[POWDER-USE-CASES]]), and non-functional requirements
- raised by the use case.</li>
- </ul>
- <ul>
- <li><b>Scenarios</b> are used to model the functional requirements of a use case and focus on a use case in action. Scenarios may range from
- lightweight narratives as seen in <em>Use
- cases and requirements for Media Fragments</em> [[MEDIA-FRAGMENTS-REQS]], to being formally
- modeled as interaction diagrams. Each use case includes at
- least a primary scenario, and possibly other alternative
- scenarios.</li>
- </ul>
- <ul>
- <li><b><a href="#reqs" title="Requirements">Requirements</a></b>
- list functional and non-functional or quality requirements, and the use cases
- they may be derived from. This approach is exemplified in the <em>Use Cases and Requirements for the Data
- Catalog Vocabulary</em> [[DCAT-UCR]].</li>
- </ul>
-</section>
-
-<section>
-<h1 id="userstories">User Stories</h1>
-
- <section>
- <h2 id="story-social"><dfn>Maintaining Social Contact Information</dfn></h2>
- <p>Many of us have multiple email accounts that include
- information about the people and organizations we interact with –
- names, email addresses, telephone numbers, instant messenger
- identities and so on. When someone’s email address or telephone
- number changes (or they acquire a new one), our lives would be
- much simpler if we could update that information in one spot and
- all copies of it would automatically be updated. In other words,
- those copies would all be linked to some definition of “the
- contact.” There might also be good reasons (like off-line email
- addressing) to maintain a local copy of the contact, but ideally
- any copies would still be linked to some central “master.”</p>
- <p>Agreeing on a format for “the contact” is not enough,
- however. Even if all our email providers agreed on the format of a
- contact, we would still need to use each provider’s custom
- interface to update or replace the provider’s copy, or we would
- have to agree on a way for each email provider to link to the
- “master”. If we look outside our own personal interests, it would
- be even more useful if the person or organization exposed their
- own contact information so we could link to it.</p>
- <p>
- What would work in either case is a common understanding of the
- resource, a few formats needed, and access guidance for these
- resources. This would support how to acquire a link to a contact,
- how to use those links to interact with a contact (including <a
- href="#uc3" title="">reading</a>,
- <a href="#uc4" title="">updating</a>,
- and <a href="#s2.2" title="">deleting</a>
- it), as well as how to easily <a
- href="#s2.1" title="">create a
- new contact</a>, add it to my contacts, and when deleting a
- contact, how it would be removed from my list of contacts. It
- would also be good to be able to add some application-specific
- data about my contacts that the original design didn’t consider.
- Ideally we’d like to eliminate multiple copies of contacts, there
- would be additional valuable information about my contacts that
- may be stored on separate servers and need a simple way to link
- this information back to the contacts. Regardless of whether a
- contact collection is my own, shared by an organization, or all
- contacts known to an email provider (or to a single email account
- at an email provider), it would be nice if they all worked pretty
- much the same way.
- </p>
- </section>
-
- <section>
- <h2 id="story-tracking_relationships"><dfn>Keeping Track of Personal and Business Relationships</dfn></h2>
- <p>In our daily lives, we deal with many different
- organizations in many different relationships, and they each have
- data about us. However, it is unlikely that any one organization
- has all the information about us. Each of them typically gives us
- access to the information (at least some of it), many through
- websites where we are uniquely identified by some string – an
- account number, user ID, and so on. We have to use their
- applications to interact with the data about us, and we
- have to use their identifier(s) for us.</p>
- <p>
- Would it not be simpler if at least the Web-addressable portion of
- that data could be linked to consistently, so that instead of
- maintaining various identifiers in different formats and instead
- of having to manually supply those identifiers to each one’s
- corresponding custom application, we could essentially build a set
- of bookmarks to it all? When we want to <a
- href="#uc3" title="">examine</a>
- or <a href="#uc4" title="">change</a>
- their contents, would it not be simpler if there were a single
- consistent application interface that they all supported?
- </p>
- <p>
- The information held by any single organization might be a mix of
- simple data and <a href="#uc6" title="">collections
- of other data</a>, for example, a bank account balance and a
- collection of historical transactions. Our bank might easily have
- <a href="#s1.2"
- title="">a collection of accounts for each member of its collection
- of customers</a>.
- </p>
- </section>
-
- <section>
- <h2 id="story-oslc"><dfn>System and Software Development Tool Integration</dfn></h2>
- <p>System and software development tools typically come from a
- diverse set of vendors and are built on various architectures and
- technologies. These tools are purpose built to meet the needs for
- a specific domain scenario (modeling, design, requirements and so
- on.) Often tool vendors view integrations with other tools as a
- necessary evil rather than providing additional value to their
- end-users. Even more of an afterthought is how these tools’ data
- -- such as people, projects, customer-reported problems and needs
- -- integrate and relate to corporate and external applications
- that manage data such as customers, business priorities and market
- trends. The problem can be isolated by standardizing on a small
- set of tools or a set of tools from a single vendor, but this
- rarely occurs and if does it usually does so only within small
- organizations. As these organizations grow both in size and
- complexity, they have needs to work with outsourced development
- and diverse internal other organizations with their own set of
- tools and processes. There is a need for better support of more
- complete business processes (system and software development
- processes) that span the roles, tasks, and data addressed by
- multiple tools. This demand has existed for many years, and the
- tools vendor industry has tried several different architectural
- approaches to address the problem. Here are a few:</p>
- <ul>
- <li>Implement an API for each application, and then, in each
- application, implement “glue code” that exploits the APIs of
- other applications to link them together.</li>
- <li>Design a single database to store the data of multiple
- applications, and implement each of the applications against this
- database. In the software development tools business, these
- databases are often called “repositories.”</li>
- <li>Implement a central “hub” or “bus” that orchestrates the
- broader business process by exploiting the APIs described
- previously.</li>
- </ul>
- <p>
- It is fair to say that although each of those approaches has its
- adherents and can point to some successes, none of them is wholly
- satisfactory. The use of Linked Data as an application integration
- technology has a strong appeal [[OSLC]].
- </p>
- </section>
-
- <section>
- <h2 id="story-lld"><dfn>Library Linked Data</dfn></h2>
- <p>
- The W3C Library Linked Data Working Group has a number of use
- cases cited in their <em>Use Case Report</em> [[LLD-UC]]. These referenced use cases focus on the
- need to extract and correlate library data from disparate sources.
- Variants of these use cases that can provide consistent formats,
- as well as ways to improve or update the data, would enable
- simplified methods for both efficiently sharing this data as well
- as producing incremental updates without the need for repeated
- full extractions and import of data.
- </p>
- <p>The 'Digital Objects Cluster' contains a number of relevant
- use cases:</p>
- <ul>
- <li>Grouping: This should "Allow the end-users to define <a
- href="#uc6" title="">groups of resources</a>
- on the web that for some reason belong together. The relationship
- that exists between the resources is often left unspecified. Some
- of the resources in a group may not be under control of the
- institution that defines the groups."
- </li>
- </ul>
- <ul>
- <li>Enrichment: "Enable end-users to <a
- href="#uc4" title="">link resources
- together</a>."
- </li>
- </ul>
- <ul>
- <li>Browsing: "<a href="#uc7"
- title="">Support end-user browsing through groups</a> and
- resources that belong to the groups."
- </li>
- </ul>
- <ul>
- <li>Re-use: "Users should have the capability to re-use all
- or parts of a collection, with all or part of its metadata,
- elsewhere on the linked Web."</li>
- </ul>
- <p>The 'Collections' cluster also contains a number of relevant
- use cases:</p>
- <ul>
- <li>Collection-level description: "Provide <a
- href="#uc7" title="">metadata
- pertaining to a collection as a whole</a>, in contrast to item-level
- description."
- </li>
- </ul>
- <ul>
- <li>Collections discovery: "Enable innovative collection
- discovery such as identification of nearest location of a
- physical collection where a specific information resource is
- found or mobile device applications ... based on collection-level
- descriptions."</li>
- </ul>
- <ul>
- <li>Community information services: Identify and classify
- collections of special interest to the community.</li>
- </ul>
- </section>
-
- <section>
- <h2 id="story-meter_monitoring"><dfn>Municipality Operational Monitoring</dfn></h2>
- <p>
- Across various cities, towns, counties, and various municipalities
- there is a growing number of services managed and run by
- municipalities that produce and consume a vast amount of
- information. This information is used to help monitor services,
- predict problems, and handle logistics. In order to effectively
- and efficiently collect, produce, and analyze all this data, a
- fundamental set of loosely coupled standard data sources are
- needed. A simple, low-cost way to <a
- href="#uc3" title="">expose
- data</a> from the diverse set of monitored services is needed, one
- that can easily integrate into the municipalities of other systems
- that inspect and analyze the data. All these services have links
- and dependencies on other data and services, so having a simple
- and scalable linking model is key.
- </p>
- </section>
-
- <section>
- <h2 id="story-healthcare"><dfn>Healthcare</dfn></h2>
- <p>For physicians to analyze, diagnose, and propose treatment
- for patients requires a vast amount of complex, changing and
- growing knowledge. This knowledge needs to come from a number of
- sources, including physicians’ own subject knowledge, consultation
- with their network of other healthcare professionals, public
- health sources, food and drug regulators, and other repositories
- of medical research and recommendations.</p>
- <p>To diagnose a patient’s condition requires current data on
- the patient’s medications and medical history. In addition, recent
- pharmaceutical advisories about these medications are linked into
- the patient’s data. If the patient experiences adverse effects
- from medications, these physicians need to publish information
- about this to an appropriate regulatory source. Other medical
- professionals require access to both validated and emerging
- effects of the medication. Similarly, if there are geographical
- patterns around outbreaks that allow both the awareness of new
- symptoms and treatments, this information needs to quickly reach a
- very distributed and diverse set of medical information systems.
- Also, reporting back to these regulatory agencies regarding new
- occurrences of an outbreak, including additional details of
- symptoms and causes, is critical in producing the most effective
- treatment for future incidents.</p>
- </section>
-
- <section>
- <h2 id="story-media"><dfn>Metadata Enrichment in Broadcasting</dfn></h2>
- <p>
- There are many different use cases when broadcasters show interest
- in metadata <a href="#uc4" title="">
- enrichment</a>:
- </p>
- <ul>
- <li>enrich archive or news metadata by linking facts, events,
- locations and personalities</li>
- <li>enrich metadata generated by automatic extraction tools
- such as person identification, etc.</li>
- <li>enrich definitions of terms in classification schemes or
- enumeration lists</li>
- </ul>
- <p>This comes in support of more effective information
- management and data/content mining (if you can't find your
- content, it's like you don't have it and must either recreate or
- acquire it again, which is not financially effective).</p>
- <p>However, there is a need for solutions facilitating linkage
- to other data sources and taking care of the issues such as
- discovery, automation, disambiguation, etc. Other important issues
- that broadcasters would face are the editorial quality of the
- linked data, its persistence, and usage rights.</p>
- </section>
-
- <section>
- <h2 id="story-mashup"><dfn>Aggregation and Mashups of Infrastructure Data</dfn></h2>
- <p>
- For infrastructure management (such as storage systems, virtual
- machine environments, and similar IaaS and PaaS concepts), it is
- important to provide an environment in which information from
- different sources can be <a href="#uc6"
- title="">aggregated</a>, <a
- href="#uc7" title="">filtered</a>,
- and visualized effectively. Specifically, the following use cases
- need to be taken into account:
- </p>
- <ul>
- <li>While some data sources are based on Linked Data, others
- are not, and aggregation and mashups must work across these
- different sources.</li>
- <li>Consumers of the data sources and aggregated/filtered
- data streams are not necessarily implementing Linked Data
- themselves, they may be off-the-shelf components such as
- dashboard frameworks for composing visualizations.</li>
- <li>Simple versions of this scenario are pull-based, where
- the data is requested from data sources. In more advanced
- settings, without a major change in architecture it should be
- possible to move to a push-based interaction model, where data
- sources push notifications to subscribers, and data sources
- provide different services that consumers can subscribe to (such
- as "informational messages" or "critical alerts only").</li>
- </ul>
- <p>In this scenario, the important factors are to have
- abstractions that allow easy aggregation and filtering, are
- independent from the internal data model of the sources that are
- being combined, and can be used for pull-based interactions as
- well as for push-based interactions.</p>
- </section>
-
- <section>
- <h2 id="story-low-end_devices"><dfn>Sharing Payload of RDF Data Among Low-End Devices</dfn></h2>
- <p>
- Several projects around the idea of <em>downscaling the Semantic Web</em> need to be able to ship payloads of RDF across
- the nodes member of a given network. The transfers are done in a
- constrained context in terms of bandwidth, scope of the local
- semantics employed by the nodes and computing capabilities of the
- nodes. In a P2P style, every node has the capability to act either
- as a data consumer or a data provider, serving its own data or
- acting as a relay to pass other's data along (typically in mesh
- networks).
- </p>
- <p>The transfer of an arbitrary payload of RDF data could be
- implemented through a container mechanism, adding and removing
- sets of RDF triples to it. Currently, the
- SemanticXO [[XO]] project uses named graphs and the graph store protocol to
- create/delete/copy graphs across the nodes but this (almost)
- imposes the usage of a triple store. Unfortunately, triple stores
- are rather demanding pieces of software that are not always usable
- on limited hardware. Some generic REST-like interaction backed up
- with a lightweight column store would be a better approach.</p>
- </section>
-
- <section>
- <h2 id="story-binary_and_metadata"><dfn>Sharing Binary Resources and Metadata</dfn></h2>
- <p>When publishing datasets about stars one may want to publish
- links to the pictures in which those stars appear, and this may
- well require publishing the pictures themselves. Vice versa: when
- publishing a picture of space we need to know which telescope took
- the picture, which part of the sky it was pointing at, what
- filters were used, which identified stars are visible, who can
- read it, who can write to it.</p>
- <p>If Linked Data contains information about resources that are
- most naturally expressed in non-RDF formats (be they binary such
- as pictures or videos, or human readable documents in XML
- formats), those non-RDF formats should be just as easy to publish
- to the LinkedData server as the RDF relations that link those
- resources up. A LinkedData server should therefore allow
- publishing of non-linked data resources too, and make it easy to
- publish and edit metadata about those resources.</p>
- <p>The resource comes in two parts - the image and information
- about the image (which may be in the image file but is better kept external
- to it as it's more general). The information about the image is
- vital. It's a compound item of image data and other data (application
- metadata about the image) that are not distinguished from the
- platform's point-of-view.</p>
- </section>
-
- <section>
- <h2 id="story-data_catalogs"><dfn>Data Catalogs</dfn></h2>
- <p>
- The <em>Asset Description Metadata Schema</em> [[ADMS]]
- provides the data model to describe semantic asset repository
- contents, but this leaves many open challenges when building a
- federation of these repositories to serve the need of asset
- reuse. These include accessing and querying individual
- repositories and efficiently retrieving <a
- href="#uc5" title="">
- updated content</a> without having to retrieve the whole content.
- The Data Warehousing integration approach allows us to cope
- with heterogeneity of sources technologies and to benefit from the
- optimized performance it offers, given that individual
- repositories do not usually change frequently. With Data
- Warehousing, the federation requires one to:
- </p>
- <ul>
- <li>understand the data, i.e. understand their semantic
- descriptions, and other systems.</li>
- <li>seamlessly exchange the semantic assets metadata from
- different repositories</li>
- <li>keep itself up-to-date.</li>
- </ul>
- <p>Repository owners can maintain de-referenceable URIs for
- their repository descriptions and contained assets in a Linked Data
- compatible manner. ADMS provides the necessary data model to
- enable meaningful exchange of data. However, this leaves the
- challenge of efficient access to the data not fully addressed.</p>
- </section>
-
- <section>
- <h2 id="story-constrained_devices"><dfn>Constrained Devices and Networks</dfn></h2>
- <p>
- Information coming from resource constrained devices in the Web of
- Things [[WOT]]
- has been identified as a major driver in many domains, from smart
- cities to environmental monitoring to real-time tracking. The
- amount of information produced by these devices is growing
- exponentially and needs to be accessed and integrated in a
- systematic, standardized and cost efficient way. By using the same
- standards as on the Web, integration with applications will be
- simplified and higher-level interactions among resource
- constrained devices, abstracting away heterogeneities, will become
- possible. Up-coming IoT/WoT standards such as '6LowPAN' [[6LOWPAN]]
- - IPv6 for resource constrained devices - and the <em>Constrained
- Application Protocol</em> [[COAP]], which provides a downscaled version of
- HTTP on top of UDP for the use on constrained devices, are already
- at a mature stage. The next step now is to support RESTful
- interfaces also on resource constrained devices, adhering to the
- Linked Data principles. Due to the limited resources available,
- both on the device and in the network (such as bandwidth, energy,
- and memory) a solution based on <em>SPARQL Update</em> [[RDF-SPARQL-UPDATE]] is at the current point
- in time considered not to be useful and/or feasible. An approach
- based on the HTTP-CoAP Mapping [[COAP-MAP]] would enable constrained
- devices to directly participate in a Linked Data-based
- environment.
- </p>
- </section>
-
- <section>
- <h2 id="story-process_of_science"><dfn>Services Supporting the Process of Science</dfn></h2>
- <p>Many fields of science now include branches with in silico
- data-intensive methods, e.g. bioinformatics, astronomy. To support
- these new methods we look to move beyond the established platforms
- provided by scientific workflow systems to capture, assist, and
- preserve the complete lifecycle from record of the experiment,
- through local trusted sharing, analysis, dissemination (including
- publishing of experimental data "beyond the PDF"), and re-use.</p>
- <ul>
- <li><a href="#uc6" title="">Aggregations</a>,
- specifically <em>Research Objects (ROs)</em> are exchanged
- between services and clients bringing together workflows, data
- sets, annotations, and provenance.
- </li>
- <li>We need lightweight services that can be simply and easily
- integrated into, and scale across the wide variety of softwares
- and data used in science.
- <ul>
- <li>Foundation services collect and expose ROs for
- storage, modification, exploration, and reuse.</li>
- <li>Services that provide added-value to ROs such as
- seamless import/export from scientific workflow systems,
- automated stability evaluation, or recommendation.</li>
- </ul>
- </li>
- </ul>
- </section>
-
- <section>
- <h2 id="story-project_data"><dfn>Project Membership Information</dfn></h2>
- <p>Information about people and projects changes as roles
- change, as organisations change and as contact details change.
- Finding the current state of a project is important in enabling
- people to contact the right person in the right role. It can also
- be useful to look back and see who was performing what role in the
- past.</p>
- <p>A use of a Linked Data Platform could be to give
- responsibility for managing such information to the project team
- itself, instead of requiring updates to be requested from a centralised
- website administrator.</p>
- <p>This could be achieved with:</p>
- <ul>
- <li>Resource descriptions for each person and project</li>
- <li>A container resource to describe roles/membership in the
- project.</li>
- </ul>
- <p>To retain the history of the project, the old version of a
- resources, including container resources, should be retained so
- there is a need to address both specific items and also have a
- notion of "current".</p>
- <p>Access to information has two aspects:</p>
- <ul>
- <li>Access to the "current" state, regardless of the version
- of the resource description</li>
- <li>Access to historical state, via access to a specific
- version of the resource description</li>
- </ul>
- </section>
-
- <section>
- <h2 id="story-cloud"><dfn>Cloud Infrastructure Management</dfn></h2>
- <p>Cloud operators offer API support to provide customers with
- remote access for the management of Cloud infrastructure (IaaS).
- Infrastructure consists of Systems, Computers, Networks, Discs,
- etc. The overall structure can be seen as mostly hierarchical,
- (Cloud contains Systems, Systems contain Machines, etc),
- complemented with crossing links (e.g. multiple Machines connected
- to a Network).</p>
- <p>The IaaS scenario makes specific requirements on lifecycle
- management and discovery, handling non-instant changes, history
- capture and query:</p>
- <ul>
- <li>Many aspects of Cloud infrastructure have associated
- lifecycle, e.g. a Computer can be transitioned between Running
- and Shutdown. This should be manageable through the API, which
- should include how a client discovers dynamic lifecycle options
- and thus help steering through an application.</li>
- <li>It is often the case that attaining a new lifecycle state
- is not instantaneous. Clients require a universal mechanism for
- monitoring such changes.</li>
- <li>A facility to retrieve all events in the lifecycle of a
- resource can be useful.</li>
- <li>Query provides the means to interrogate the resources
- behind the API, as well as finding new entry points into the
- application.</li>
- </ul>
- <p>Infrastructure management may be viewed as the manipulation
- of the underlying graph of resources.</p>
- </section>
-
-</section>
-
-<section>
-<h1 id="usecases">Use Cases</h1>
-
- <p>The following use cases are each derived from one or more of
- the user stories above. These use cases are explored in detail
- through the development of scenarios, each motivated by some key
- aspect exemplified by a single user story. The examples they
- contain are included purely for illustrative purposes, and should
- not be interpreted normatively.</p>
-
- <section id="uc1">
- <h2><dfn>UC1</dfn>: Compose resources</h2>
- <p>
- A number of user stories introduce the idea of a <em>container</em>
- as a mechanism for composing resources within the
- context of an application. A
- composition would be identified by URI being a linked resource in its own
- right. Its properties may represent the <em>affordances</em>
- of the application, enabling clients to determine what other
- operations they can do. These operations may
- include descriptions of application specific services that can be
- invoked by exchanging RDF documents.
- </p>
- <ul>
- <li><a>NF1.1</a>: Provide "access guidance" (affordances) from user story, <a>Maintaining Social Contact Information</a>.</li>
- </ul>
-
- <section id="s1.1">
- <h3>Primary scenario: create a container</h3>
- <p>
- Create a new container resource within the LDP server. In <a>Services Supporting the Process of Science</a>,
- <a
- href="http://www.wf4ever-project.org/"
- title="http://www.wf4ever-project.org/" rel="nofollow">Research
- Objects</a> are semantically rich aggregations of resources that
- bring together data, methods and people in scientific
- investigations. A basic workflow research object will be created
- to aggregate scientific workflows and their artefacts [[RESEARCH-OBJECTS]].
- These artefacts will be added to the research object throughout the project lifecycle of the project.
- </p>
- <p>
- The RDF description below captures the initial state of the research object. For the purposes of the example, we have included the time of creation. It is a linked data resource addressed via URL from which the following RDF can be retrieved. The null-relative URL <code><></code> should be understood as a self-reference to the research object itself.
- </p>
- <pre class='example'><code>
-@prefix ro: <http://purl.org/wf4ever/ro#> .
-@prefix dct: <http://purl.org/dc/terms/> .
-@prefix ore: <http://www.openarchives.org/ore/> .
-@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
-
-<> a ro:ResearchObject, ore:Aggregation ;
- dct:created "2012-12-01"^^xsd:dateTime .
-</code></pre>
- <div>(see functional requirement <a>F1.1</a>)</div>
- </section>
-
- <section id="s1.2">
- <h3>Alternative scenario: create a nested container</h3>
- <p>
- The motivation for nested containers comes from the <a>System and Software Development Tool Integration</a> user story. The
- OSLC Change Management vocabulary allows bug reports to have
- attachments referenced by the membership predicate
- <code>oslc_cm:attachment</code>. This may be viewed as nested containment. The <em>top-level-container</em> contains issues, and
- each issue is itself a container of attachments.
- In the example, <code>issue1234</code> is a member of the container <code>top-level-container</code>. In turn, <code>attachment324</code> and <code>attachment251</code> are attachments within <code>issue1234</code>. Treating these as containers makes it easier to manage them as self-contained units.
- </p>
- <pre class='example'><code>
-@prefix dcterms: <http://purl.org/dc/terms/>.
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
-@prefix oslc_cm: <http://open-services.net/ns/cm#>.
-@prefix : <http://example.org/>.
-
-:top-level-container rdfs:member :issue1234 .
-
-:issue1234 a oslc_cm:ChangeRequest;
- dcterms:identifier "1234";
- dcterms:type "a bug";
- oslc_cm:attachments :attachments.
-
-:attachments a oslc_cm:AttachmentList;
- oslc_cm:attachment :attachment324, :attachment251.
-</code></pre>
- <div>(see functional requirement <a>F1.2</a>)</div>
- </section>
- <section id="s1.3">
- <h3>Alternative scenario: Delete a container</h3>
- If a container can be deleted, it seems natural that any contained resources and nested containers should also be deleted.
- <div>(see functional requirement <a>F1.3</a>).</div>
- </section>
- </section>
-
- <section id="uc2">
- <h2><dfn>UC2</dfn>: Manage resource lifecycle</h2>
- <p>
- This use case addresses the managed lifecycle of a resource and is
- concerned with resource <em>ownership</em>. The responsibility for
- managing resources belongs to their container. For example, a
- container may accept a request from a client to make a new
- resource. This use case focuses on creation and deletion of
- resources in the context of a container, and the potential for
- transfer of ownership by moving resources between containers. The
- ownership of a resource should always be clear; no resource
- managed in this way should ever be owned by more than one
- container.
- </p>
- <ul>
- <li><a>NF2.1</a>: Non-duplication of resources: "Eliminate multiple
- copies", representing resources in a single place from <a>Maintaining Social Contact Information</a>.
- </li>
- <li><a>NF2.2</a>: Distribution of resources: Linked data "may be stored on
- separate servers" from <a>Maintaining Social Contact Information</a>.
- </li>
- <li><a>NF2.3</a>: Consistent, global naming: Resources should be "linked to
- consistently, ... instead of maintaining various identifiers in
- different formats" from <a>Keeping Track of Personal and Business Relationships</a>.
- </li>
- </ul>
-
- <section id="s2.1">
- <h3>Primary scenario: create resource</h3>
- <p>
- Resources begin life by being created within a container. From
- user story, <a>Maintaining Social Contact Information</a>, It should be
- possible to "easily create a new contact and add it to my
- contacts." This suggests that resource creation is closely linked
- to the application context. The new resource is created in a
- container representing "my contacts." The lifecycle of the
- resource is linked to the lifecycle of it's container. So, for
- example, if "my contacts" is deleted then a user would also
- reasonably expect that all contacts within it would also be
- deleted.
- </p>
- <p>
- Contact details are captured as an RDF description and it's
- properties, including "names, email addresses, telephone numbers,
- instant messenger identities and so on." The description may
- include non-standard RDF; "data about my contacts that the
- original design didn’t consider." The following RDF could be used
- to describe contact information using the FOAF
- vocabulary [[FOAF]]. A contact is represented here by a
- <code>foaf:PersonalProfileDocument</code> defining a resource that can be
- created and updated as a single-unit, even though it may describe
- ancillary resources, such as a <code>foaf:Person</code>, below.
- </p>
- <pre class='example'><code>
-@prefix foaf: <http://xmlns.com/foaf/0.1/> .
-
-<> a foaf:PersonalProfileDocument;
- foaf:PrimaryTopic [
- a foaf:Person;
- foaf:name "Timothy Berners-Lee";
- foaf:title "Sir";
- foaf:firstName "Timothy";
- foaf:surname "Berners-Lee";
- foaf:nick "TimBL", "timbl";
- foaf:homepage <http://www.w3.org/People/Berners-Lee/>;
- foaf:weblog <http://dig.csail.mit.edu/breadcrumbs/blog/4>;
- foaf:mbox <mailto:timbl@w3.org>;
- foaf:workplaceHomepage <http://www.w3.org/>.
- ]
-</code></pre>
- <div>(see functional requirement <a>F2.1</a>)</div>
- </section>
-
- <section id="s2.2">
- <h3>Alternative scenario: delete resource</h3>
- <p>
- Delete a resource and all it's properties. If the resource resides
- within a container it will be removed from that container, however
- other links to the deleted resource may be left as dangling
- references. In the case where the resource is a container, the
- server may also delete any or all contained resources. In normal
- practice, a deleted resource cannot be reinstated. There are
- however, edge-cases where limited undelete may be desirable. Best
- practice states that "Cool URIs don't change" [[COOLURIS]], which implies that
- deleted URIs shouldn't be recycled.
- </p>
- <div>(see functional requirement <a>F2.2</a>)</div>
- </section>
-
- <section id="s2.3">
- <h3>Alternative scenario: moving contained resources</h3>
- <p>
- Resources may have value beyond the life of their membership
- in a container. This implies methods to add references to revise
- container membership.
- A change of ownership may or may not imply a change of URI,
- depending upon the naming policy. While assigning a
- new URI to a resource is discouraged [[WEBARCH]], it is possible to indicate that a
- resource has moved with an appropriate HTTP response.
- </p>
- <div>(see functional requirement <a>F2.3</a>)</div>
- </section>
- </section>
-
- <section id="uc3">
- <h2><dfn>UC3</dfn>: Retrieve resource description</h2>
- <p>Access the current description of a resource, containing
- properties of that resource and links to related resources. The
- representation may include descriptions of related resources that
- cannot be accessed directly. Depending upon the application, an
- server may enrich the retrieved RDF with additional triples. Examples
- include adding incoming links, <code>owl:sameAs</code> closure and <code>rdf:type</code> closure.
- The HTTP response should also include versioning information (i.e.
- last update or entity tag) so that subsequent updates can ensure
- they are being applied to the correct version.</p>
- <ul>
- <li><a>NF3.1</a>: Use standard vocabularies as appropriate to enable a
- "common understanding of the resource" from <a>Maintaining Social Contact Information</a>.
- </li>
- <li><a>NF3.2</a>: A "scalable linking model is key" from <a>Municipality Operational Monitoring</a>.
- </li>
- </ul>
-
- <section id="s3.1">
- <h3>Primary scenario: retrieve resource description</h3>
- <p>
- The user story <a
- href="#story-project_data"
- title=""> Project Membership Information</a> discusses the
- representation of information about people and projects. It calls
- for "Resource descriptions for each person and project" allowing
- project teams to review information held about these resources.
- The example below illustrates the kinds of information that might
- be held about organizational structures based on the <a
- href="http://www.epimorphics.com/web/"
- title="http://www.epimorphics.com" rel="nofollow">Epimorphics</a>
- organizational ontology [[ORG-ONT]].
- </p>
- <p>Examples 4 and 5 below define two resources that would be hosted on an LDP server based at
- <http://example.com/>. The representation in Example 4 describes <http://example.com/member1>, while that of Example 5 describes <http://example.com/role>.
- A client reading Example 4 would have to separately retrieve Example 5 in order to get role information such as its descriptive label.
- </p>
- <p>
- Note that the representations of these resources may
- include descriptions of related resources, such as
- <http://www.w3.org/>, that that fall under a completely different authority and
- therefore can't be served directly from the LDP server at this location.</p>
- <div>
- <pre class='example'><code>
-@prefix org: <http://www.w3.org/ns/org#> .
-@prefix owltime: <http://www.w3.org/2006/time> .
-@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
-@base <http://example.com/> .
-
-<member1> a org:Membership ;
- org:member <http://www.w3.org/People/Berners-Lee/card#i> ;
- org:organization http://www.w3.org/> ;
- org:role <director> ;
- org:memberDuring [a owltime:Interval; owltime:hasBeginning [
- owltime:inXSDDateTime "1994-10-01T00:00:00Z"^^xsd:dateTime]] .
-
-<http://www.w3.org/> a org:FormalOrganization ;
- skos:prefLabel "The World Wide Web Consortium"@en ;
- skos:altLabel "W3C" .
-</code></pre>
-</div>
-<div>
-<pre class='example'><code>
-@prefix org: <http://www.w3.org/ns/org#> .
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
-@base <http://example.com/> .
-
-<director> a org:Role ;
- rdfs:label "Director" .
-
-</code></pre>
-</div>
- <div>(see functional requirement <a>F3.1</a>)</div>
- </section>
-
- <section id="s3.2">
- <h3>Alternative scenario: retrieve description of a non-document resource (hash URI)</h3>
- <p>In many cases, the things that are of interest are not
- always the things that are resolvable. The example below
- demonstrates how a FOAF profile may be used to distinguish between
- the person and the profile; the former being the topic of the
- latter. Where the fragment is defined relative to the base, as in this example, the URL including the fragment may be used to access the resource representing the containing document. The HTTP protocol
- requires that the fragment part be stripped off before requesting
- the URI from the server. The client can then read properties of the hash URI <code><#i></code> from the retrieved description.
- </p>
- <pre class='example'><code>
-@base <http://www.w3.org/People/Berners-Lee/card>
-@prefix foaf: <http://xmlns.com/foaf/0.1/>.
-@prefix dc: <http://purl.org/dc/elements/1.1/>.
-
-<> a foaf:PersonalProfileDocument ;
- dc:title "Tim Berners-Lee's FOAF file" ;
- foaf:homepage <http://www.w3.org/People/Berners-Lee/> ;
- foaf:primaryTopic <#i> .
-</code></pre>
- <div>(see functional requirement <a>F3.2</a>)</div>
- </section>
- </section>
-
- <section id="uc4">
- <h2><dfn>UC4</dfn>: Update existing resource</h2>
- <p>
- Change the RDF description of a LDP resource, potentially removing
- or overwriting existing data. This allows applications to <em>enrich</em>
- the representation of a resource by addling additional links to
- other resources.
- </p>
- <ul>
- <li><a>NF4.1</a>: Unrestricted vocabulary: It should be possible be "able
- to add ... application-specific data" to resources from <a>Maintaining Social Contact Information</a>.
- </li>
- </ul>
-
- <section id="s4.1">
- <h3>Primary scenario: enrichment</h3>
- <p>
- This relates to user story <a>Metadata Enrichment in Broadcasting</a> and is based on the BBC
- Sports Ontology [[BBC-SPORT]]. The <em>resource-centric</em> view of linked-data
- provides a natural granularity for substituting, or overwriting a
- resource and its data. The simplest kind of update would simply
- replace what is currently known about a resource with a new
- representation.
- </p>
- <p>
- There are two distinct resources in the example
- below; a sporting event and an associated award. The granularity
- of the resource would allow a user to replace the information about the
- award without disturbing the information about the event.
- </p>
- <pre class='example'><code>
-@prefix : <http://example.com/>.
-@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
-
- :mens_sprint a sport:MultiStageCompetition;
- rdfs:label "Men's Sprint";
- sport:award <#gold_medal> .
-
-<#gold_medal> a sport:Award .
-</code></pre>
- <p>The description can be enriched as events unfold, adding a link to
- the winner of the gold medal by substituting the above description
- with the following.</p>
- <pre class='example'><code>
-@prefix : <http://example.com/>.
-@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
-@prefix foaf: <http://xmlns.com/foaf/0.1/> .
-
- :mens_sprint a sport:MultiStageCompetition;
- rdfs:label "Men's Sprint";
- sport:award <#gold_medal> .
-<#gold_medal> a sport:Award;
- sport:awarded_to [
- a foaf:Agent ;
- foaf:name "Chris Hoy" .
- ] .
-</code></pre>
- <div>(see functional requirement <a>F4.1</a>)</div>
- </section>
-
- <section id="s4.2">
- <h3>Alternative scenario: selective update of a resource</h3>
- <p>
- This relates to user story <a>Data Catalogs</a>. A catalogue is
- described by the following RDF model, based on the Data Catalog Vocabulary [[vocab-dcat]] which provides a standard format for representing the metadata held by organizations.
- </p>
- <pre class='example'><code>
-@prefix : <http://example.com/>.
-@prefix dcat: <http://www.w3.org/ns/dcat#> .
-@prefix dcterms: <http://purl.org/dc/terms/> .
-
- :catalog a dcat:Catalog ;
- dcat:dataset :dataset/001;
- dcterms:issued "2012-12-11"^^xsd:date.
-</code></pre>
- <p>
- A catalog may contain multiple datasets, so when linking to new
- datasets it would be simpler and preferable to selectively add
- just the new dataset links. For this example, a Changeset [[CHANGESET]] might be used to add a new <code>dc:title</code> to the
- dataset. The following update would be directed to the catalogue
- to add an additional dataset.
- </p>
- <pre class='example'><code>
-@prefix : <http://example.com/>.
-@prefix dcterms: <http://purl.org/dc/terms/> .
-@prefix cs: <http://purl.org/vocab/changeset/schema#> .
-@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
-
-<change1>
- a cs:ChangeSet ;
- cs:subjectOfChange :catalog ;
- cs:createdDate "2012-01-01T00:00:00Z" ;
- cs:changeReason "Update catalog datasets" ;
- cs:addition [
- a rdf:Statement ;
- rdf:subject :catalog ;
- rdf:predicate dcat:dataset ;
- rdf:object :dataset/002 .
- ] .
-</code></pre>
- <div>(see functional requirement <a>F4.2</a>)</div>
- </section>
- </section>
-
- <section id="uc5">
- <h2><dfn>UC5</dfn>: Determine if a resource has changed</h2>
- <p>
- It should be possible to retrieve versioning information about a
- resource (e.g. last modified or entity tag) without having to
- download a representation of the resource. This information can
- then be compared with previous information held about that
- resource to determine if it has changed. This versioning
- information can also be used in subsequent <em>conditional</em>
- requests to ensure they are only applied if the version is
- unchanged.
- </p>
- <ul>
- <li><a>NF5.1</a>: Multiple changes to a resource: The <a>Project Membership Information</a> user story is concerned with "access to the 'current' state", as distinct from earlier versions.
- This is particularly relevant to changes which are made with respect to a specific version of the resource description.
- The LDP must ensure consistent access in the case of multiple simultaneous attempts to access a resource.
- </li>
- </ul>
-
- <section id="s5.1">
- <h3>Primary scenario: determine if a resource has changed</h3>
- <p>
- Based on the user story, <a>Constrained Devices and Networks</a>, an LDP server could be configured to
- act as a proxy for a CoAP [[COAP]] based Web of Things [[WOT]]. As an observer of CoAP resources, the LDP server registers
- its interest so that it will be notified whenever the sensor
- reading changes. Clients of the LDP can interrogate the server to
- determine if the state has changed.
- </p>
- <p>
- In this example, the information about a sensor and corresponding
- sensor readings can be represented as RDF resources. The first
- resource below, represents a sensor described using the Semantic
- Sensor Network [[SSN]] ontology.
- </p>
- <pre class='example'><code>
-@prefix : <http://example.com/energy-management/>.
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
-@prefix ssn: <http://purl.oclc.org/NET/ssnx/ssn#> .
-
-<> a :MainsFrequencySensor;
- rdfs:comment "Sense grid load based on mains frequency";
- ssn:hasMeasurementCapability [
- a :FrequencyMeasurementCapability;
- ssn:hasMeasurementProperty <#property_1> .
- ] .
-</code></pre>
- <p>
- The value of the sensor changes in real-time as measurements are
- taken. The LDP client can interrogate the resource below to
- determine if it has changed, <em>without</em> necessarily having to
- download the RDF representation. As different sensor properties
- are represented disjointly (separate RDF representations) they may
- change independently.
- </p>
- <pre class='example'><code>
-@prefix : <http://example.com/energy-management/> .
-@prefix ssn: <http://purl.oclc.org/NET/ssnx/ssn#> .
-@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
-
-
-<http://example.com/energy-management#property_1> :hasMeasurementPropertyValue <> .
-<> a :FrequencyValue;
- :hasQuantityValue "50"^^xsd:float.
-</code></pre>
- <div>(see functional requirement <a>F5.1</a>)</div>
- </section>
- </section>
-
- <section id="uc6">
- <h2><dfn>UC6</dfn>: Aggregate resources</h2>
- <p>
- There is a requirement to be able to manage <em>collections</em> of
- resources. The concept of a collection overlaps with, but is
- distinct from that of a container. These collections are (weak)
- aggregations, unrelated to the lifecycle management of resources,
- and distinct from the ownership between a resource and its
- container. However, the composition of a container may be
- reflected as a collection to support navigation of the container
- and its contents. There is a need to be able to create collections
- by adding and deleting individual membership properties. Resources
- may belong to multiple collections, or to none.
- </p>
- <ul>
- <li><a>NF6.1</a>: Resource descriptions are a "mix of simple data and
- collections" from <a>Keeping Track of Personal and Business Relationships</a>.
- </li>
- <li><a>NF6.2</a>: Relative URIs: It should be possible to "ship payloads of
- RDF" for a collection as a whole without breaking internal links
- from <a>Constrained Devices and Networks</a>.
- </li>
- </ul>
-
- <section id="s6.1">
- <h3>Primary scenario: add a resource to a collection</h3>
- <p>
- This example is from <a>Library Linked Data</a> and LLD-UC [[LLD-UC]], specifically <em>Subject Search</em>.
- </p>
- <p>There is an existing collection at
- <http://example.com/concept-scheme/subject-heading> that
- defines a collection of subject headings. This collection is
- defined as a <code>skos:ConceptScheme</code> and the client wishes to insert a
- new concept into the scheme. which will be related to the
- collection via a <code>skos:inScheme</code> link. In the example below, a new subject-heading,
- "outer space exploration" is added to the <code>scheme:subject-heading</code> collection. The following RDF describes the (item-level)
- description of the collection,
- also demonstrating that the relationship between the parent and child resources may run in a seemingly counter-intuitive direction, from child to parent.
- </p>
- <pre class='example'><code>
-@prefix scheme : <http://example.com/concept-scheme/>.
-@prefix concept : <http://example.com/concept/>.
-@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
-
-scheme:subject-heading a skos:ConceptScheme.
-
-concept:Outer+space+Exploration skos:inScheme scheme:subject-heading.
-</code></pre>
- <div>(see functional requirement <a>F6.1</a>)</div>
- </section>
-
- <section id="s6.2">
- <h3>Alternative scenario: add a resource to multiple collections</h3>
- <p>
- Logically, a resource should not be owned by more than one
- container. However, it may be a member of multiple collections
- which define a weaker form of <em>aggregation</em>. As this is
- simply a manipulation of the RDF description of a collection, it
- should be possible to add the same resource to multiple
- collections.
- </p>
- <p>
- As a machine-readable collection of medical terms, the SNOMED CT ontology [[SNOMED]]
- is of key importance in user story, <a>Healthcare</a>. SNOMED CT allows concepts with more than one parent. In the example below, SNOMED concepts are treated as
- collections (aggregations) of narrower concepts. We see that the
- concept <code>:TissueSpecimenFromHeart</code> belongs to two parent collections as it is both a <code>:TissueSpecimen</code> and a <code>:SpecimenFromHeart</code>.
- This example also demonstrates how composition and aggregation support different scenarios, as the ability to have multiple parents should not be a possibility with composition.
- </p>
- <pre class='example'><code>
-@prefix : <http://example.com/snomed/>.
-@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
-
-:TissueSpecimen a skos:Concept ;
- :conceptID "119376003";
- skos:prefLabel "Tissue specimen"
- skos:narrowerTransitive :TissueSpecimenFromHeart.
-
-:SpecimenFromHeart a skos:Concept ;
- :conceptID "127462005";
- skos:prefLabel "Specimen from heart"
- skos:narrowerTransitive :TissueSpecimenFromHeart.
-
-:TissueSpecimenFromHeart a skos:Concept;
- :conceptID "128166000";
- rdfs:label "Tissue specimen from heart".
-</code></pre>
- <div>(see functional requirement <a>F6.2</a>)</div>
- </section>
- </section>
-
- <section id="uc7">
- <h2><dfn>UC7</dfn>: Filter resource description</h2>
- <p>This use case extends the normal behaviour of retrieving an
- RDF description of a resource, by dynamically excluding specific
- (membership) properties. For containers, it is often desirable to
- be able to read a collection, or item-level description that
- excludes the container membership.</p>
-
- <section id="s7.1">
- <h3>Primary scenario: retrieve collection-level description</h3>
- <p>
- This scenario, based on <a>Library Linked Data</a>, uses the Dublin Core Metadata Initiative Collection-Level description [[DC-COLLECTIONS]]. A collection can
- refer to any aggregation of physical or digital items. This
- scenario covers the case whereby a client can request a
- collection-level description as typified by the example below,
- without necessarily having to download a full listing of the items
- within the collection.
- </p>
- <pre class='example'><code>
-@prefix dc: <http://purl.org/dc/elements/1.1/>.
-@prefix : <http://example.org/bookshelf/>.
-@prefix dcmitype: <http://purl.org/dc/dcmitype/>.
-@prefix cld: <http://purl.org/cld/terms/>.
-@prefix dcterms: <http://purl.org/dc/terms/>.
-
-<> dc:type dcmitype:Collection ;
- dc:title "Directory of organizations working with Linked Data" ;
- dcterms:abstract "This is a directory of organisations specializing in Linked Data."
- cld:isLocatedAt <http://dir.w3.org>
- cld:isAccessedVia <http://dir.w3.org/directory/pages/landing-page.xhtml?view>
-</code></pre>
- <div>(see functional requirement <a>F7.1</a>)</div>
- </section>
-
- <section id="s7.2">
- <h3>Alternative scenario: retrieve item-level description of a collection</h3>
- <p>
- This use case scenario, also based on <a>Library Linked Data</a>,
- focuses on obtaining an item-level description of the resources
- aggregated by a collection. The simplest scenario is where the
- members of a collection are returned within a single
- representation, so that a client can explore the data by following
- these links. Different applications may use different membership
- predicates to capture this aggregation. The example below uses
- <code>rdfs:member</code>, but many different membership predicates are in
- common use, including RDF Lists. Item-level descriptions can be
- captured using the Functional Requirements for Bibliographic
- Records (FRBR) ontology [[FRBR]] [[FRBR-CORE]].
- </p>
- <p>
- Based on the example below, the item-level description should include as a minimum all the <code>rdfs:member</code> relationships. It need not include other properties of the collection, and it need not include additional properties of the members.
- </p>
- <pre class='example'><code>
-@prefix frbr: <http://purl.org/vocab/frbr/core#>.
-@prefix dc: <http://purl.org/dc/elements/1.1/>.
-@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
-
-<> rdfs:member <#ebooks97>, <#ebooks21279>.
-
-<#work97> a frbr:LiteraryWork;
- dc:title "Flatland: a romance of many dimensions" ;
- frbr:creator <#Abbott_Edwin>;
- frbr:manifestation <ebook97>.
-
-<#work21279> a frbr:LiteraryWork;
- dc:title "2 B R 0 2 B" ;
- frbr:creator <#Vonnegut_Kurt>;
- frbr:manifestation <ebook21279>.
-</code></pre>
- <div>(see functional requirement <a>F7.2</a>)</div>
- </section>
- </section>
-
- <section id="uc8">
- <h2><dfn>UC8</dfn>: Retrieve a large resource description in multiple parts</h2>
-
-<p>This use case addresses a problem with the “resource-centric” approach to interacting with RDF data. The problem is that some resources participate in a very large number of triples, and therefore a “resource-centric” granularity leads to resource descriptions that are too large to be practically processed in a single HTTP request. This use case applies to all resources, not just containers.</p>
-
- <ul>
- <li>It's not really the resource description that's being paginated, but the values of a particular property.</li>
- <li>The server is responsible for pagination, and may decide how large the pages are.</li>
- <li>Pagination should apply symmetrically to both <em>incoming</em> and <em>outgoing</em> properties.</li>
- <li>The next-page URL should be treated as opaque.</li>
- </ul>
-
- <section id="s8.1">
- <h3>Primary scenario: Pagination</h3>
-
-<p>In user story, <a>Maintaining Social Contact Information</a>, it is not uncommon for users to have a very large number of contacts.
-This leads to a very large resource description, especially if some basic information about the contacts is included as well. The size of this representation may be so large that retrieval in a single HTTP request is impractical.</p>
-
-<p>In this example the response to the first request includes a reference to the <code>next</code> resource in an ordered collection of resources. For the purposes of the example, we make use of the <code>next</code> property defined by the <a href="http://www.w3.org/1999/xhtml/vocab">XHTML Metainformation Vocabulary</a>. There is no presumption that the LDP specification will recommend the use of this vocabulary.</p>
- <pre class='example'><code>
-@prefix : <http://example.com/people/>.
-@prefix xhv: <http://www.w3.org/1999/xhtml/vocab#>.
-
-:alice a foaf:Person;
- rdfs:label "Alice";
- foaf:mbox <mailto:alice@example.com>.
-
-<> xhv:next <http://example.com/1234567890>.
- </code></pre>
-
-<p>When the client requests the resource identified by <code>next</code>, the response includes additional content that can be merged with the earlier data to construct a more complete model of the originally requested resource. It may also contain further <code>next</code> links, which may be requested in turn.</p>
-
-<p>The following representation is the response to the resource identified by <code>next</code>, completing the contacts list.</p>
-
- <pre class='example'><code>
-@prefix : <http://example.com/people/>.
-
-:bob a foaf:Person;
- rdfs:label "Bob";
- foaf:mbox <mailto:bob@example.com>.
- </code></pre>
- <div>(see functional requirement <a>F8.1</a>)</div>
- </section>
- </section>
-
- <section id="uc9">
- <h2><dfn>UC9</dfn>: Manage binary resources</h2>
- <p>It should be possible to easily add non-RDF binary resources
- to containers that accept them. Binary resources may be updated and
- removed during the lifecycle of the container.</p>
-
- <section id="s9.1">
- <h3>Primary scenario: access binary resources</h3>
- <p>
- From the user story <a>Sharing Binary Resources and Metadata</a> it should be possible to
- easily add non-RDF resources to containers that accept them.
- Clients submit a non-RDF representation to a container in a media
- type accepted by that container. The container creates a URI to
- represent this media resource, and creates a link from the
- container to the new URI. The binary resource may be accompanied by an explicit RDF
- description. It should be possible to find the
- metadata about such a resource and to access and edit it in
- the usual ways.
- </p>
- <p>
- This example uses the Ontology for Media Resources to describe a media resource added to a
- collection [[MEDIAONT]].
- </p>
- <pre class='example'><code>
-@prefix ma: <http://www.w3.org/ns/ma-ont#> .
-
-<dataset> a ma:Collection ;
- ma:hasMember <dataset/image1.jpg>
-
-<dataset/image1.jpg> a ma:MediaResource ;
- ma:hasFormat "image/jpeg" .
-</code></pre>
- <div>(see functional requirement <a>F9.1</a>)</div>
- </section>
-
- <section id="s9.2">
- <h3>Alternative scenario: media-resource attachments</h3>
- <p>
- A resource may have multiple <em>renditions</em>. For example, you
- can have a PDF and a JPEG representing the same thing. A user is
- trying to create a work order along with an attached image showing
- a faulty machine part. To the user and to the work order system,
- these two artifacts are managed as a set. A single request may
- create the work order, the attachment, and the relationship
- between them, atomically. When the user retrieves the work order
- later, they expect a single request by default to retrieve the
- work order plus all attachments. When the user updates the work
- order, e.g. to mark it completed, they only want to update the
- work order proper, not its attachments. Users may
- add/remove/replace attachments to the work order during its
- lifetime.
- </p>
- <div>(see functional requirement <a>F9.2</a>)</div>
- </section>
- </section>
-</section>
-
-<section>
-<h1 id="reqs">Requirements</h1>
-<p>This section lists the functional and non-functional requirements arising from the use-cases catalogued in this document. Specific requirements that have been de-prioritized or rejected have been left in the document for completeness, but are shown as struck out.</p>
-<section>
- <h2 id="reqs-functional">Functional Requirements</h2>
- <dl>
- <dt><dfn>F1.1</dfn>:</dt>
- <dd>The system shall provide the ability to create containers for composing resources, from <a>UC1</a>.
- </dd>
- <dt><dfn>F1.2</dfn>:</dt>
- <dd>The system shall provide the ability to create nested containers, from <a>UC1</a>.
- </dd>
- <dt><dfn>F1.3</dfn>:</dt>
- <dd>On deletion of a container, the system shall delete any contained resources and nested containers, from <a>UC1</a>.
- </dd>
- <dt><dfn>F2.1</dfn>:</dt>
- <dd>The system shall provide the ability to create resources within a container, from <a>UC2</a>.
- </dd>
- <dt><dfn>F2.2</dfn>:</dt>
- <dd>The system shall provide the ability to delete resources, from <a>UC2</a>.
- </dd>
- <dt><dfn>F2.3</dfn>:</dt>
- <dd><span style="text-decoration:line-through;">The system shall provide the ability to move resources between containers, from <a>UC2</a></span>.
- </dd>
- <dt><dfn>F3.1</dfn>:</dt>
- <dd>The system shall provide the ability to retrieve resource descriptions, from <a>UC3</a>.
- </dd>
- <dt><dfn>F3.2</dfn>:</dt>
- <dd>The system shall enable the client to retrieve the description of a hash URI, from <a>UC3</a>.
- </dd>
- <dt><dfn>F4.1</dfn>:</dt>
- <dd>The system shall provide the ability to update an existing resource by substitution, from <a>UC4</a>.
- </dd>
- <dt><dfn>F4.2</dfn>:</dt>
- <dd>The system shall provide the ability to perform a selective update of a resource, from <a>UC4</a>.
- </dd>
- <dt><dfn>F5.1</dfn>:</dt>
- <dd>The system shall provide the ability to determine if a resource has changed, from <a>UC5</a>.
- </dd>
- <dt><dfn>F6.1</dfn>:</dt>
- <dd>The system shall provide the ability to aggregate resources, from <a>UC6</a>.
- </dd>
- <dt><dfn>F6.2</dfn>:</dt>
- <dd>The system shall support the addition of a resource to multiple aggregations, from <a>UC6</a>.
- </dd>
- <dt><dfn>F7.1</dfn>:</dt>
- <dd>The system shall provide the ability to retrieve a collection-level description of a composition, from <a>UC7</a>.
- </dd>
- <dt><dfn>F7.2</dfn>:</dt>
- <dd>The system shall provide the ability to retrieve an item-level description of a composition or aggregation, from <a>UC7</a>.
- </dd>
- <dt><dfn>F8.1</dfn></dt>
- <dd>The system shall provide the ability to retrieve a paginated description of a composition or aggregation, from <a>UC8</a>.
- </dd>
- <dt><dfn>F9.1</dfn>:</dt>
- <dd>The system shall provide the ability to store and access media resources, from <a>UC9</a>
- </dd>
- <dt><dfn>F9.2</dfn>:</dt>
- <dd><span style="text-decoration:line-through;">The system shall provide the ability to add media-resource attachments, from <a>UC9</a>.</span>
- </dd>
- </dl>
- </section>
-
- <section>
- <h2 id="reqs-non-functional">Non-Functional Requirements</h2>
- <dl>
- <dt><dfn>NF1.1</dfn>:</dt>
- <dd>The system shall provide access guidance to resources, from <a>UC1</a>.
- </dd>
- <dt><dfn>NF2.1</dfn>:</dt>
- <dd>The system shall encourage non-duplication of resources, from <a>UC2</a>.
- </dd>
- <dt><dfn>NF2.2</dfn>:</dt>
- <dd>The system shall support distribution of resources, from <a>UC2</a>.
- </dd>
- <dt><dfn>NF2.3</dfn>:</dt>
- <dd>The system shall support consistent, global naming, from <a>UC2</a>.
- </dd>
- <dt><dfn>NF3.1</dfn>:</dt>
- <dd>The system shall support the use of standard vocabularies where appropriate, from <a>UC3</a>.
- </dd>
- <dt><dfn>NF3.2</dfn>:</dt>
- <dd>The system shall provide a scalable linking model, from <a>UC3</a>.
- </dd>
- <dt><dfn>NF4.1</dfn>:</dt>
- <dd>The system shall permit unrestricted vocabulary, from <a>UC4</a>.
- </dd>
- <dt><dfn>NF5.1</dfn>:</dt>
- <dd>The LDP shall ensure consistent access in the case of multiple simultaneous attempts to access a resource, from <a>UC5</a>.
- </dd>
- <dt><dfn>NF6.1</dfn>:</dt>
- <dd>The system shall allow resource descriptions that are a "mix of simple data and collections", from <a>UC6</a>.
- </dd>
- <dt><dfn>NF6.2</dfn>:</dt>
- <dd>The system shall support relative URIs enabling sharing of collections, from <a>UC6</a>.
- </dd>
- </dl>
- </section>
-</section>
-
-
-<section class='appendix informative'>
-<h2 id="acknowledgements">Acknowledgements</h2>
-<p>We would like to acknowledge the contributions of user story authors: Christophe Guéret,
-Roger Menday, Eric Prud'hommeaux, Steve Speicher, John Arwe, Kevin Page.</p>
-</section>
-
-<!--section class='appendix informative' id="history">
-<h1>Change History</h1>
-<ul>
- <li>2012-12-14 - Initial ReSpec'ing framework for <a href="http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements">Workgroup working wiki document</a> (SS)</li>
- <li>2012-12-16 - Pulled in and ReSpec'd content from <a href="http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements">Workgroup working wiki document</a> (SS)</li>
- <li>2012-12-16 - Fixed cross section links and initial pass at biblio refs (SS)</li>
-</ul></section-->
-
- </body>
-</html>
