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