ldp.html
author Steve Speicher <sspeiche@gmail.com>
Mon, 20 Oct 2014 13:56:02 -0400
changeset 859 336ac8ce294d
parent 857 1aa5e5968ad3
child 860 2c55a36c754e
permissions -rw-r--r--
Removed at-risk feature that clients should be prepared to handle server-initiated paging
<!DOCTYPE html>
<!-- 
	TODO: Add new "discovery of server capabilities" non-norm section
    TODO: Consider adding Venn diagram for differences of LDPCs
 -->
<html>
  <head>
    <title>Linked Data Platform 1.0</title>
    <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
        <!-- Test coverage: The following allows the spec to be annotated with information
         from the test suite to help with understanding the coverage of each requirement. -->
    <link rel="stylesheet" type="text/css" media="all" href="coverage.css">
    <style type="text/css" media="print">
        .coverage {
            page-break-inside: avoid;
        }
    </style>
    <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js"></script>
    <script src="coverage.js"></script>
    
    <!-- 
      === NOTA BENE ===
      For the three scripts below, if your spec resides on dev.w3 you can check them
      out in the same tree and use relative links so that they'll work offline,
     -->
    <script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script> 
    <script class='remove'>
      var respecConfig = {
          // specification status (e.g. ED, WD, LC, NOTE, etc.). If in doubt use ED.
          specStatus:           "WD",
          
          // the specification's short name, as in http://www.w3.org/TR/short-name/
          shortName:            "ldp",

          // if your specification has a subtitle that goes below the main
          // formal title, define it here
          // subtitle   :  "an excellent document",

          // if you wish the publication date to be other than today, set this
          //publishDate:  "2014-09-16",

          // if the specification's copyright date is a range of years, specify
          // the start date here:
          // copyrightStart: "2005"

          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
          // and its maturity status
          previousPublishDate:  "2014-09-16",
          previousMaturity:  	"LC",
          previousURI: 			"http://www.w3.org/TR/2014/WD-ldp-20140916/",
          
          processVersion: 		2005,

          // if there a publicly available Editor's Draft, this is the link
          edDraftURI:           "http://www.w3.org/2012/ldp/hg/ldp.html",

          // if this is a LCWD, uncomment and set the end of its review period
          //lcEnd: "2014-10-07",
          //crEnd: "2014-07-17",
          
          testSuiteURI: "https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-testsuite.html",
          implementationReportURI: "https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/reports/ldp.html",
          
          // Only include h1 and h2 level
          maxTocLevel: 2,

          // if you want to have extra CSS, append them to this list
          // it is recommended that the respec.css stylesheet be kept
          //extraCSS:             ["https://dvcs.w3.org/hg/ldpwg/css/respec.css"],

          // editors, add as many as you like
          // only "name" is required
          editors:  [
              { name: "Steve Speicher", url: "http://stevespeicher.blogspot.com",
                company: "IBM Corporation", companyURL: "http://ibm.com/" },
              { name: "John Arwe", url: "https://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/allcommunities?userid=120000CAW7",
                company: "IBM Corporation", companyURL: "http://ibm.com/" },
			  {name: "Ashok Malhotra", url: "mailto:ashok.malhotra@oracle.com",
			    company: "Oracle Corporation", companyURL: "http://www.oracle.com" },
          ],

          // authors, add as many as you like. 
          // This is optional, uncomment if you have authors as well as editors.
          // only "name" is required. Same format as editors.

          //authors:  [
          //    { name: "Your Name", url: "http://example.org/",
          //      company: "Your Company", companyURL: "http://example.com/" },
          //],
          
          // name of the WG
          wg:           "Linked Data Platform Working Group",
          
          // URI of the public WG page
          wgURI:        "http://www.w3.org/2012/ldp",
          
          // name (without the @w3c.org) of the public mailing to which comments are due
          wgPublicList: "public-ldp-comments",
          
          // URI of the patent status for this WG, for Rec-track documents
          // !!!! IMPORTANT !!!!
          // This is important for Rec-track documents, do not copy a patent URI from a random
          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
          // Team Contact.
          wgPatentURI:  "http://www.w3.org/2004/01/pp-impl/55082/status",
          doRDFa: "1.1",
			localBiblio:  {
				"RFC2817": {
					title:    "Upgrading to TLS Within HTTP/1.1"
				,   href:     "http://tools.ietf.org/html/rfc2817"
				,   authors:  [
						"R. Khare"
					,   "S. Lawrence"
					]
				,   status:   "Proposed Standard"
				,   publisher:  "IETF"
				},
				"LDP-PAGING": {
					title:    "Linked Data Platform Paging"
				,   href:     "https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-paging.html"
				,   authors:  [
						"S. Speicher", "J. Arwe", "A. Malhotra"
					]
				,   status:   "Editor's Working Draft"
				,   publisher:  "W3C"
				},
				"POWDER": {
					title:    "Protocol for Web Description Resources (POWDER): Description Resources"
				,   href:     "http://www.w3.org/TR/2009/REC-powder-dr-20090901/"
				,   authors:  [
						"Phil Archer", "Kevin Smith", "Andrea Perego"
					]
				,   status:   "W3C Recommendation"
				,   publisher:  "W3C"
				},
				"Accept-Post": {
					title:    "The Accept-Post HTTP Header"
				,   href:     "http://tools.ietf.org/html/draft-wilde-accept-post"
				,   authors:  [
						"J. Arwe", "S. Speicher", "E. Wilde"
					]
				,   status:   "Internet Draft"
				,   publisher:  "IETF"
				},
				"LDP-Tests": {
					title:    "Linked Data Platform 1.0 Test Cases"
				,   href:     "https://dvcs.w3.org/hg/ldpwg/raw-file/tip/tests/ldp-testsuite.html"
				,   authors:  [
						"R. Garcia-Castro", "F. Serena"
					]
				,   status:   "Editor's Draft of Working Group Note"
				,   publisher:  "W3C"
				},
			},
      };
    </script>
    <style type="text/css">
    	div.rule {padding-top: 1em;}
    	div.ldp-issue-open {
	    	border-color: #E05252;
			background: #FBE9E9;
			padding: 0.5em;
			margin: 1em 0;
			position: relative;
			clear: both;
			border-left-width: .5em;
			border-left-style: solid;
    	}
    	div.ldp-issue-pending {
	    	border-color: #FAF602;
			background: #F7F6BC;
			padding: 0.5em;
			margin: 1em 0;
			position: relative;
			clear: both;
			border-left-width: .5em;
			border-left-style: solid;
    	}
    	div.ldp-issue-closed {
	    	border-color: #009900;
			background: #BCF7CF;
			padding: 0.5em;
			margin: 1em 0;
			position: relative;
			clear: both;
			border-left-width: .5em;
			border-left-style: solid;
    	}
    	div.ldp-issue-title {
    	    color: #E05252;
    	    padding-right: 1em;
            min-width: 7.5em;
    	}
		.atrisk {
			padding:    1em;
			margin: 1em 0em 0em;
			border: 1px solid #f00;
			background: #ffc;
		}
		.atrisktext {
			/* content:    "Feature At Risk"; */
			display:    block;
			width:  150px;
			margin: -1.5em 0 0.5em 0;
			font-weight:    bold;
			border: 1px solid #f00;
			background: #fff;
			padding:    3px 1em;
		}
		.normal { 
			font-weight: normal;
			font: normal 100% sans-serif;
		}
		.indented { 
			margin-left: +3em;
		}
		tr:nth-of-type(odd),.oddrow { 
			background:#F2F2F2; /* light grey, just enough to differentiate from white */
		}
		td { 
			padding:0 +1ex 0 +1ex; /* add a bit of space from rule/edge to text */
		}
		
    </style>
    <style type="text/css" media="all">
    	code {
    	    font-weight:bold;
			font-size:larger;
    	}
		 /* ReSpec uses color ff4500 for code elements, which does not print well on some black & white printers
		    and is a little hard to read for some folks even on-line. 
			The default code font size was also somewhat too small/hard to read.
		*/
    </style>
  </head>
<body>
<section id='abstract'>
This document describes a 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.
</section>

 <section id='sotd'>
   <p>
   	 This is the 3rd Last Call working draft where the Working Group has addressed all
   	 raised issues and seeks to gather additional implementation feedback.  
   	 The Working Group has decided to go from Candidate Recommendation to Last Call based on implementation feedback.
   	 This feedback caused the Working Group to refine a conformance requirements for Turtle, JSON-LD and marking 
   	 feature of Indirect Containers At Risk.
   	 For changes since 
   	 last publication, see <a href="#history" class="sectionRef"></a>. 
	 A test suite is available at [[LDP-Tests]].
   </p>
   <p>The following features are At Risk:</p>
   <ol>
   <li>The <a href="#header-accept-post">HTTP Accept-Post header</a>, 
		that allows clients to determine which media types a server accepts on POST requests.
	</li>
   <li>JSON-LD as a required <a href="#atrisk-ldpr-jsonld">response representation</a> and <a href="#atrisk-ldpc-jsonld">new member representation</a>.
	</li>
   <li>Support for <a href="#atrisk-indirect-containers">indirect containers</a>.
	</li>
   </ol>
 </section>
 
<section class="informative" id="intro">
<h1>Introduction</h1>
	<p>This specification describes the use
	of HTTP for accessing, updating, creating and deleting resources from
	servers that expose their resources as Linked Data.  It provides clarifications
	and extensions of the rules of Linked Data [[LINKED-DATA]]:</p>
	<ol>
		<li>Use URIs as names for things</li>
		<li>Use HTTP URIs so that people can look up those names</li>
		<li>When someone looks up a URI, provide useful information, using the standards
			(RDF*, <abbr title="SPARQL Protocol and RDF Query Language">SPARQL</abbr>)
		</li>
		<li>Include links to other URIs, so that they can discover more things</li>
	</ol>
	<p>This specification discusses standard HTTP and RDF techniques  
	used when constructing clients and servers that 
	create, read, and write <a title="Linked Data Platform Resource">Linked Data Platform Resources</a>.
	<a
			href="http://www.w3.org/TR/ldp-primer/"
			class="external"
			title="Linked Data Platform 1.0 Primer"
			rel="nofollow">LDP Primer</a> 
	provides an entry-level introduction with many examples in the context of a fictional application.
	<a
			href="http://www.w3.org/TR/ldp-bp/"
			class="external"
			title="LDP Best Practices and Guidelines"
			rel="nofollow">LDP Best Practices and Guidelines</a> 
			discusses best practices that you 
	should use, and anti-patterns you should avoid, when constructing these clients and servers.
	</p> 
	<p>This specification defines a special type of <a>Linked Data Platform Resource</a>: a 
	<a title="Linked Data Platform Container">Container</a>.  Containers are very useful 
	in building application models involving collections of resources, often homogeneous ones. 
	For example, universities offer a collection of classes 
	and a collection of faculty members, each faculty member teaches a collection of courses, and so on. 
	This specification discusses how to work with containers.  Resources can be added to containers  
	using standard HTTP operations like 
	POST (see <a href="#ldpc-HTTP_POST" class="sectionRef"></a>).</p>
	<p>The intention of this specification is to enable additional rules and layered groupings of rules as 
	additional specifications.  The scope is intentionally narrow to provide a set of key rules for 
	reading and writing Linked Data that most, if not all, other specifications will depend upon and 
	implementations will support.</p>
	<p>This specification provides some approaches to deal with large resources.  An extension to this specification
	provides the ability to break large resource representations into multiple paged responses [[LDP-PAGING]].</p>
	<p>For context and background, it could be useful to read <a href="#bib-LDP-UCR">Linked Data Platform Use Case and Requirements</a> [[LDP-UCR]] 
	and <a href="#base-specs" class="sectionRef"></a>.</p>
</section>
	
<section id="terms">
<h1>Terminology</h1>

<p>Terminology is based on W3C's Architecture of the World Wide Web [[!WEBARCH]] and 
	Hyper-text Transfer Protocol ([[!RFC7230]], [[!RFC7231]], [[!RFC7232]]).
</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 [[WEBARCH]].
		<p></p></dd>
							
	<dt>Linked Data</dt>
	<dd>As defined by Tim Berners-Lee [[LINKED-DATA]].<p></p></dd>
	
	<dt>Client</dt>
	<dd>A program that establishes connections for the purpose of sending one or more HTTP requests [[!RFC7230]].<p></p></dd>
	
	<dt>Server</dt>
	<dd>A program that accepts connections in order to service HTTP requests by sending HTTP responses. 
		<p>
		The terms "client" and "server" refer only to the roles that these programs perform for a particular connection.  
		The same program might act as a client on some connections and a server on others.
		</p>
		<p>
		HTTP enables the use of intermediaries to satisfy requests through a
		chain of connections.  There are three common forms of HTTP
		intermediary: proxy, gateway, and tunnel.  In some cases, a single
		intermediary might act as an origin server, proxy, gateway, or
		tunnel, switching behavior based on the nature of each request.
		[[!RFC7230]]. 
		</p>
	</dd>
	
	<dt><dfn>Linked Data Platform Resource</dfn> (<abbr title="Linked Data Platform Resource">LDPR</abbr>)</dt>
	<dd>A HTTP resource whose state is represented in any way that conforms to the simple lifecycle
		patterns and conventions in <a href="#ldpr" class="sectionRef"></a>.<p></p></dd>
		
	<dt><dfn>Linked Data Platform RDF Source</dfn> (<abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>)</dt>
	<dd>An <a title="Linked Data Platform Resource">LDPR</a> whose state is fully represented in RDF, corresponding to
	an RDF graph. See also the term
	<a href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-source">RDF Source</a> from [[!rdf11-concepts]].
	<p></p></dd>	

	<dt><dfn>Linked Data Platform Non-RDF Source</dfn> (<abbr title="Linked Data Platform Non-RDF Source">LDP-NR</abbr>)</dt>
	<dd>An <a title="Linked Data Platform Resource">LDPR</a> whose state is <em>not</em> represented in RDF.
	For example, these can be binary or text documents that do not have useful RDF representations.
	<p></p></dd>
		
	<dt><dfn>Linked Data Platform Container</dfn> (<abbr title="Linked Data Platform Container">LDPC</abbr>)</dt>
	<dd>A LDP-RS representing a collection of linked
	documents (<a href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-document">RDF Document</a> [[!rdf11-concepts]] or information resources [[!WEBARCH]])
	that responds to client requests for creation, modification, and/or enumeration of its linked members and documents, 
	and that conforms to the simple lifecycle
	patterns and conventions in <a href="#ldpc" class="sectionRef"></a>.
	<p></p></dd>
	
	<dt><dfn>Linked Data Platform Basic Container</dfn> (<abbr title="Linked Data Platform Basic Container">LDP-BC</abbr>)</dt>
	<dd>An <a title="Linked Data Platform Container">LDPC</a> that defines a simple link to
	its <a title="Containment">contained</a> documents (information resources) [[!WEBARCH]].
	<p></p></dd>
	
	<dt><dfn>Linked Data Platform Direct Container</dfn> (<abbr title="Linked Data Platform Direct Container">LDP-DC</abbr>)</dt>
	<dd>An <a title="Linked Data Platform Container">LDPC</a> that adds the concept of <a title="Membership">membership</a>, allowing the flexibility of choosing what form its 
	<a title="Membership triples">membership triples</a> take, and allows <a title="Membership">members</a> to be 
	any resources [[!WEBARCH]], not only documents.
	<p></p></dd>
	
	<dt><dfn>Linked Data Platform Indirect Container</dfn> (<abbr title="Linked Data Platform Indirect Container">LDP-IC</abbr>)</dt>
	<dd>An <a title="Linked Data Platform Container">LDPC</a> similar to a <a title="Linked Data Platform Direct Container">LDP-DC</a>
	that is also capable of having <a title="Membership">members</a> whose URIs are based
	on the content of its <a title="Containment">contained</a> documents rather than the URIs assigned to those documents.
	<p></p></dd>
		 
	<dt><dfn>Membership</dfn></dt>
	<dd>The relationship linking an LDPC and its member LDPRs, 
	which can be different resources than its <a title="Containment">contained</a> documents.  
	The LDPC often assists with managing the membership triples, whether or not the LDPC's
	URI occurs in them.
	<p></p></dd>

	<dt><dfn>Membership triples</dfn></dt>
	<dd>A set of triples that lists an LDPC's members.
		A LDPC's membership triples all have one of the following patterns:
		<table class="indented">
		<tr>
		<td style="background:#DDDDDD"> <var>membership-constant-URI</var> </td>
		<td style="background:#FFFFFF"> <var>membership-predicate</var> </td>
		<td style="background:#CCFFFF"> <var>member-derived-URI</var> </td>
		</tr>
		<tr>
		<td style="background:#CCFFFF"> <var>member-derived-URI</var> </td>
		<td style="background:#FFFFFF"> <var>membership-predicate</var> </td>
		<td style="background:#DDDDDD"> <var>membership-constant-URI</var> </td>
		</tr>
		</table>
		The difference between the two is simply which position member-derived-URI occupies, which is usually
		driven by the choice of <var>membership-predicate</var>.  Most predicates have a natural forward direction
		inherent in their name, and existing vocabularies contain useful examples that read naturally in
		each direction.  <code>ldp:member</code> and <code>dcterms:isPartOf</code> are representative examples.
		<p>
		Each linked container exposes properties (see <a href="#ldpc-general" class="sectionRef"></a>)
		that allow clients to determine which pattern it
		uses, what the actual <var>membership-predicate</var> and <var>membership-constant-URI</var> values are, 
		and (for containers that allow the creation of new members) what value is used
		for the <var>member-derived-URI</var> based on the client's input to the 
		creation process.</p>
	<p></p></dd>
	
	<dt><dfn>Membership predicate</dfn></dt>
	<dd>The predicate of all an LDPC's <a title="Membership triples">membership triples</a>.
	<p></p></dd>
	
	<dt><dfn>Containment</dfn></dt>
	<dd>The relationship binding an LDPC to LDPRs whose lifecycle it controls and is aware of.  The
	lifecycle of the contained LDPR is limited by the lifecycle of the containing LDPC;
	that is, a contained LDPR cannot be created (through LDP-defined means) before its containing LDPC exists.
	<p></p></dd>

	<dt><dfn>Containment triples</dfn></dt>
	<dd>
	A set of triples, maintained by the LDPC, that lists documents created by the LDPC but not yet deleted.
	These triples <strong>always</strong> have the form: <var>( LDPC URI, ldp:contains , document-URI )</var>.
	<p></p></dd>

	<dt><dfn>Minimal-container triples</dfn></dt>
	<dd>
	The portion of an LDPC's triples that would be present when the container is empty.  Currently, this definition
	is equivalent to all the LDPC's triples minus its containment triples, 
	and minus its membership triples (if either are considered part of its state), 
	but if future versions of LDP define additional classes of triples then this definition
	would expand to subtract out those classes as well.
	<p></p></dd>

	<dt><dfn>LDP-server-managed triples</dfn></dt>
	<dd>
	The portion of an LDP's triples whose behavior is constrained directly by this specification; for example,
	membership triples and containment triples.  This portion of resources' content does <em>not</em>
	include constraints imposed outside of LDP, for example by other specifications that the server 
	happens to support, or by <a href="#ldpr-gen-pubclireqs">server implementation decisions</a>.
	<p></p></dd>
  </dl>

<section id="conventions">
<h2>Conventions Used in This Document</h2>
	<p>The namespace for LDP is <code>http://www.w3.org/ns/ldp#</code>.</p>
	<p>Sample resource representations are provided in <code>text/turtle</code>
		format [[turtle]].</p>
	<p>Commonly used namespace prefixes:</p>
	<pre style="word-wrap: break-word; white-space: pre-wrap;">	@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
	@prefix foaf:    &lt;http://xmlns.com/foaf/0.1/&gt;.
	@prefix rdf:     &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
	@prefix ldp:     &lt;http://www.w3.org/ns/ldp#&gt;.
	@prefix xsd:     &lt;http://www.w3.org/2001/XMLSchema#&gt;.</pre>
</section>
</section>
    
<section id='conformance'>

<p>The status of the sections of Linked Data Platform 1.0 (this document) is as follows:</p>
<ul>
  <li>1. Introduction: <b>non-normative</b></li>
  <li>2. Terminology: <b>normative</b></li>
  <li>3. Conformance: <b>normative</b></li>
  <li>4. Linked Data Platform Resources: <b>normative</b></li>
  <li>5. Linked Data Platform Containers: <b>normative</b></li>
  <li>6. Notable information from normative references: <b>non-normative</b></li>
  <li>7. HTTP Header Definitions: <b>normative</b></li>
  <li>8. Security Considerations: <b>non-normative</b></li>
  <li>A. Acknowledgements: <b>non-normative</b></li> 
  <li>B. Change History: <b>non-normative</b></li>
  <li>C.1 Normative references: <b>normative</b></li>
  <li>C.2 Non-normative references: <b>non-normative</b></li>
</ul>

<p>A conforming <b><dfn>LDP client</dfn></b> is a conforming HTTP client [[!RFC7230]] that follows the rules defined by LDP in
<a href="#ldpr" class="sectionRef"></a> and also
<a href="#ldpc" class="sectionRef"></a>.
</p>

<p>A conforming <b><dfn>LDP server</dfn></b> is a conforming HTTP server [[!RFC7230]] that follows the rules defined by LDP in 
<a href="#ldpr" class="sectionRef"></a> when it is serving LDPRs, and also
<a href="#ldpc" class="sectionRef"></a> when it is serving LDPCs.
LDP does not constrain its behavior when serving other HTTP resources.
</p>
</section>

<section id="ldpr">
<h1>Linked Data Platform Resources</h1>

<section class="informative" id="ldpr-informative">
<h2>Introduction</h2>
	<p>Linked Data Platform Resources (<dfn><abbr title="Linked Data Platform Resources">LDPRs</abbr></dfn>) are HTTP resources
		that conform to the simple patterns and conventions in this section.
		HTTP requests to access, modify, create or delete LDPRs are accepted
		and processed by <a title="LDP server">LDP servers</a>. Most LDPRs are domain-specific resources
		that contain data for an entity in some domain, which could be
		commercial, governmental, scientific, religious, or other.</p>
	<p>Some of the rules defined in this document provide
		clarification and refinement of the base Linked Data rules [[LINKED-DATA]];
		others address additional needs.</p>
	<p>The rules for Linked Data Platform Resources address basic
		questions such as:</p>
	<ul>
		<li>What resource representations should be used?</li>
		<li>How is optimistic collision detection handled for updates?</li>
		<li>What should client expectations be for changes to linked-to resources,
				such as type changes?</li>
		<li>How can the server make it easy for the client to create resources?</li>
		<li>How	do I GET the representation of a large resource broken up into pages?</li>
	</ul>
	<p>Additional non-normative guidance is available in the <a
			href="http://www.w3.org/TR/ldp-bp/"
			class="external"
			title="LDP Best Practices and Guidelines"
			rel="nofollow">LDP Best Practices and Guidelines</a> that addresses
		questions such as:</p>
	<ul>
		<li>What literal value types should be used?</li>
		<li>Are there some typical vocabularies that should be reused?</li>
		<li>What guidelines exist when interacting with LDPRs that are common but are not universal enough to specify normatively?</li>
	</ul>
	<p>The following sections define the conformance rules for LDP servers when serving LDPRs.
	</p>
	<p>LDP-RS's representations may be too big, one strategy is to break up the response representation
	into client consumable chunks called pages. A separate LDP specification outlines the conformance
	rules around pagination [[LDP-PAGING]].
	</p>
	<p>A LDP server can manage two kinds of <a title="Linked Data Platform Resources">LDPRs</a>, those resources whose state 
	is represented using RDF (LDP-RS) and those using other formats (LDP-NR).  LDP-RSs have the unique
	quality that their representation is based on RDF, which addresses a number of use cases from web metadata, open data 
	models, machine processable information, and automated processing by software agents [[!rdf11-concepts]].  LDP-NRs are almost anything
	on the Web today: images, HTML pages, word processing documents, spreadsheets, etc. and LDP-RSs hold 
	metadata associated with LDP-NRs in some cases.
	</p>
    <figure id="fig-ldpr-types">
        <img src="images/ldpr1.png" alt="Sample separation of Linked Data Platform Resource" />
        <figcaption>Samples of different types of LDPRs</figcaption>
    </figure>
    <p>The LDP-NRs and LDP-RSs are simply sub-types of LDPRs, as illustrated in <a href="#fig-ldpr-class"></a>.</p>  
    <figure id="fig-ldpr-class">
       <img src="images/ldpr2.png" alt="Class Diagram of Linked Data Platform Resource" />
       <figcaption>Class relationship of types of Linked Data Platform Resources</figcaption>
     </figure>
	
</section>

<section id="ldpr-resource">
<h2>Resource</h2>

<section id="ldpr-general">
<h2>General</h2>
		
	<section id="ldpr-gen-http"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST at least be HTTP/1.1 conformant servers [[!RFC7230]].
	</h2></section><!-- Was 4.2.1 / #ldpr-4_2_1 -->
	
	<section id="ldpr-gen-binary"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY host a mixture of <a title="Linked Data Platform RDF Source">LDP-RSs</a>
	and <a title="Linked Data Platform Non-RDF Source">LDP-NRs</a>. For example, it
		is common for <a title="LDP server">LDP servers</a> to need to host binary or text resources
		that do not have useful RDF representations.</h2></section><!-- Was 4.2.3 / #ldpr-4_2_3 -->

	<section id="ldpr-gen-etags"><h2 class="normal"><a title="LDP server">LDP server</a> responses MUST use entity tags (either 
		weak or strong ones) as response <code>ETag</code> header values, for responses that contain resource representations or
		successful responses to HTTP <code>HEAD</code> requests.
	</h2></section><!-- Was 4.2.8 / #ldpr-4_2_8 -->
	
	<section id="ldpr-gen-linktypehdr"><h2 class="normal"><a title="LDP server">LDP servers</a>
		exposing LDPRs 
		MUST advertise their LDP support by exposing a HTTP <code>Link</code> header
		with a target URI of <code>http://www.w3.org/ns/ldp#Resource</code>, and
		a link relation type of <code>type</code> (that is, <code>rel='type'</code>)
		in all responses to requests made 
		to an LDPR's HTTP <code>Request-URI</code> [[!RFC5988]]. 
	</h2></section><!-- Was 4.2.10 / #ldpr-4_2_10 -->
	<blockquote>
		<p>
		Note: 
		The HTTP <code>Link</code> header is the method by which servers assert their support for the LDP specification 
		on a specific resource in a way that clients can inspect dynamically at run-time.   
		This is <strong>not</strong> equivalent to the
		presence of a <var>(subject-URI, <code>rdf:type</code>, <code>ldp:Resource</code>)</var> triple in an LDP-RS.
		The presence of the header asserts that the server complies with the LDP specification's constraints on 
		HTTP interactions with LDPRs, that is
		it asserts that the resource <a href="#ldpr-gen-etags">has Etags</a>, <a href="#ldpr-options-must">supports OPTIONS</a>, and so on,
		which is not true of all Web resources.
		</p>
		<p>
		Note: 
		<a href="#ldpr-gen-binary">A LDP server can host a mixture of LDP-RSs and LDP-NRs</a>, and therefore there is no implication
		that LDP support advertised on one HTTP <code>Request-URI</code> means that other 
		resources on the same server are also LDPRs.  Each HTTP <code>Request-URI</code> needs to be 
		individually inspected, in the absence of outside information.
		</p>
	</blockquote>

	<section id="ldpr-gen-defbaseuri"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST assign the default 
		base-URI for [[!RFC3987]] relative-URI resolution to be the HTTP 
		<code>Request-URI</code> when the resource already exists, and to the URI of the created resource when the request results 
		in the creation of a new resource.
	</h2></section><!-- Was 4.2.12 / #ldpr-4_2_12 -->
	
	<section id="ldpr-gen-pubclireqs"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST 
		publish any constraints on <a title="LDP client">LDP clients’</a> ability to 
		create or update LDPRs, by adding a Link header with
		an appropriate context URI,
		a link relation of <code>http://www.w3.org/ns/ldp#constrainedBy</code>,
		and a target URI identifying a set of constraints
		[[!RFC5988]], to all responses to requests that fail due to violation of 
		those constraints.  For example, a server that refuses resource creation 
		requests via HTTP PUT, POST, or PATCH would return this <code>Link</code> header on its 
		4xx responses to such requests.
		The same <code>Link</code> header MAY be provided on other responses.  LDP neither 
		defines nor constrains the representation of the link's target resource.  Natural language 
		constraint documents are therefore permitted, 
		although machine-readable ones facilitate better client interactions.
		The appropriate context URI can vary based on the request's semantics and method;
		unless the response is otherwise
		constrained, the default (the effective request URI) SHOULD be used.
	</h2></section><!-- Was 4.2.13 / #ldpr-4_2_13 -->

</section>

<section id="ldpr-HTTP_GET">
<h2>HTTP GET</h2>
	<section id="ldpr-get-must"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST support the HTTP <code>GET</code> method for LDPRs.
	</h2></section><!-- Was 4.3.1 / #ldpr-4_3_1 -->
	
	<section id="ldpr-get-options"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST support the HTTP response headers defined in 
		<a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a> for the HTTP <code>GET</code> method.
	</h2></section><!-- Was 4.3.2 / #ldpr-4_3_2 -->
	
</section>

<section id="ldpr-HTTP_POST">
<h2>HTTP POST</h2>
	<p>
		Per [[!RFC7231]], this HTTP method is optional and 
		this specification does not require <a title="LDP server">LDP servers</a> to support it.
		When a LDP server supports this method, 
		this specification imposes no new requirements for LDPRs.
	</p>

	<p>Clients can create LDPRs via <code>POST</code> (<a href="#ldpc-HTTP_POST" class="sectionRef"></a>) to a LDPC, 
		via <code>PUT</code> (<a href="#ldpr-HTTP_PUT" class="sectionRef"></a>), or any other methods allowed
		for HTTP resources.  Any server-imposed constraints on LDPR creation or update  
		<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.

	</p>
</section>

<section id="ldpr-HTTP_PUT">
<h2>HTTP PUT</h2>
	<p>
		Per [[!RFC7231]], this HTTP method is optional and 
		this specification does not require <a title="LDP server">LDP servers</a> to support it.
		When a LDP server supports this method, 
		this specification imposes the following new requirements for LDPRs.
	</p>
		
	<p>
		Any server-imposed constraints on LDPR creation or update  
		<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
	</p>
		
	<section id="ldpr-put-replaceall"><h2 class="normal">If a HTTP <code>PUT</code> is accepted on an existing resource, 
		<a title="LDP server">LDP servers</a> MUST
		replace the entire persistent state of the identified resource with
		the entity representation in the body of the request. 
		<a title="LDP server">LDP servers</a> MAY ignore <a>LDP-server-managed properties</a>,
		and MAY ignore other properties such as <code>dcterms:modified</code> 
		and <code>dcterms:creator</code> if they are <a href="#ldpr-gen-pubclireqs">handled specially by the server</a>.
		Any <a title="LDP server">LDP servers</a> that wish
		to support a more sophisticated merge of data provided by the client
		with existing state stored on the server for a resource MUST use HTTP
		<code>PATCH</code>, not HTTP <code>PUT</code>.
	</h2></section><!-- Was 4.5.1 / #ldpr-4_5_1 -->
		
	<section id="ldpr-put-simpleupdate"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to update resources without
		requiring detailed knowledge of <a href="#ldpr-gen-pubclireqs">server-specific constraints</a>.  
		This is a consequence of the requirement to enable simple creation and modification of LDPRs.
	</h2></section><!-- Was 4.5.7 / #ldpr-4_5_7 -->	

	<section id="ldprs-put-servermanagedprops"><h2 class="normal">
		If an otherwise valid HTTP <code>PUT</code> request is received 
		that attempts to change properties <a href="#ldpr-gen-pubclireqs">the server does not allow clients to modify</a>, 
		<a title="LDP server">LDP servers</a> MUST 
		fail the request by responding with a 4xx range status code (typically
		409 Conflict). 
		<a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
		information about which properties could not be
		persisted.
		The format of the 4xx response body is not constrained by LDP.
	</h2></section><!-- Was 4.5.1.1 / #ldpr-4_5_1_1 -->
	<blockquote>
		Non-normative note: Clients might provide properties equivalent to those already in the resource's state,
		e.g. as part of a GET/update representation/PUT sequence, and those PUT requests are intended to work as long as the 
		<a title="LDP-server-managed triples">LDP-server-managed properties</a>
		are identical on the GET response and the subsequent PUT request.
		This is in contrast to other cases like 
		<a href="#ldpr-put-replaceall">write-once properties that the server does not allow clients to modify once set</a>; 
		properties like this are under client and/or server control but are not constrained by LDP, 
		so they are not <a>LDP-server-managed triples</a>.  
	</blockquote>
	
	<section id="ldprs-put-failed"><h2 class="normal">
		If an otherwise valid HTTP <code>PUT</code> request is received that contains properties the server 
		chooses not to persist, e.g. unknown content,
		<a title="LDP server">LDP servers</a> MUST respond with an appropriate 4xx range status code
		[[!RFC7231]].  
		<a title="LDP server">LDP servers</a> SHOULD provide a corresponding response body containing
		information about which properties could not be
		persisted.
		The format of the 4xx response body is not constrained by LDP. LDP servers
		expose these application-specific constraints as described in <a href="#ldpr-general" class="sectionRef"></a>.
	</h2></section><!-- Was 4.5.4 / #ldpr-4_5_4 -->
	
	<section id="ldpr-put-precond"><h2 class="normal"><a title="LDP client">LDP clients</a> SHOULD use the HTTP <code>If-Match</code>
		header and HTTP <code>ETags</code> to ensure it isn’t
		modifying a resource that has changed since the client last retrieved
		its representation. <a title="LDP server">LDP servers</a> SHOULD require the HTTP <code>If-Match</code> header and HTTP <code>ETags</code>
		to detect collisions. <a title="LDP server">LDP servers</a> MUST respond with status code 412
		(Condition Failed) if <code>ETag</code>s fail to match when there are no other
		errors with the request [[!RFC7232]].  <a title="LDP server">LDP servers</a> that require conditional requests MUST respond with status code 428
		(Precondition Required) when the absence of a precondition is the only reason for rejecting the request [[!RFC6585]].
	</h2></section><!-- Was 4.5.2 / #ldpr-4_5_2 -->
	
	<section id="ldpr-put-create"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY choose to allow the creation of new resources using HTTP <code>PUT</code>.
	</h2></section><!-- Was 4.5.6 / #ldpr-4_5_6 -->

</section>
		
<section id="ldpr-HTTP_DELETE">
<h2>HTTP DELETE</h2>
	<p>
		Per [[!RFC7231]], this HTTP method is optional and 
		this specification does not require <a title="LDP server">LDP servers</a> to support it.
		When a LDP server supports this method, 
		this specification imposes no new blanket requirements for LDPRs.
	</p>
		
	<p>Additional requirements on HTTP <code>DELETE</code> for LDPRs within containers can be found in
	<a href="#ldpc-HTTP_DELETE" class="sectionRef"></a>.
	</p>
</section>

<section id="ldpr-HTTP_HEAD">
<h2>HTTP HEAD</h2>
	<p>Note that certain LDP mechanisms rely on HTTP headers, and HTTP generally requires that
		<code>HEAD</code> responses include the same headers as <code>GET</code> responses.  
		Thus, implementers should also carefully read sections <a href="#ldpr-HTTP_GET"></a> 
		and <a href="#ldpr-HTTP_OPTIONS"></a>.</p>
	<section id="ldpr-head-must"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST support the HTTP <code>HEAD</code> method.
	</h2></section><!-- Was 4.7.1 / #ldpr-4_7_1 -->
</section>

<section id="ldpr-HTTP_PATCH">
<h2>HTTP PATCH</h2>
	<p>
		Per [[!RFC5789]], this HTTP method is optional and 
		this specification does not require <a title="LDP server">LDP servers</a> to support it.
		When a LDP server supports this method, 
		this specification imposes the following new requirements for LDPRs.
	</p>
		
	<p>
		Any server-imposed constraints on LDPR creation or update  
		<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
	</p>
	
	<section id="ldpr-patch-acceptpatch"><h2 class="normal"><a title="LDP server">LDP servers</a> that support <code>PATCH</code> MUST
		include an <code>Accept-Patch</code> HTTP response header [[!RFC5789]] on HTTP <code>OPTIONS</code>
		requests, listing patch document media type(s) supported by the server.
	</h2></section><!-- Was 4.8.4 / #ldpr-4_8_4 -->

</section>

<section id="ldpr-HTTP_OPTIONS">
<h2>HTTP OPTIONS</h2>
	<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for LDPRs 
		beyond those in [[!RFC7231]].  Other sections of this specification, for example 
		<a href="#ldpr-HTTP_PATCH">PATCH</a>,
		<a href="#header-accept-post">Accept-Post</a>,
		add other requirements on <code>OPTIONS</code> responses.
		</p>

	<section id="ldpr-options-must"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST support the HTTP <code>OPTIONS</code> method.
	</h2></section><!-- Was 4.9.1 / #ldpr-4_9_1 -->
		
	<section id="ldpr-options-allow"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST indicate their support for HTTP Methods by
		responding to a HTTP <code>OPTIONS</code> request on the LDPR’s URL with the HTTP
		Method tokens in the HTTP response header <code>Allow</code>.
	</h2></section><!-- Was 4.9.2 / #ldpr-4_9_2 -->

</section> <!-- h2 -->

</section> <!-- ldpr-resource -->

<section id="ldprs">
<h2>RDF Source</h2>

<p>The following section contains normative clauses for <a title="">Linked Data Platform RDF Source</a>.</p>

<section id="ldprs-general">
<h2>General</h2>

	<section id="ldprs-are-ldpr"><h2 class="normal">Each <a title="Linked Data Platform RDF Source">LDP RDF Source</a> MUST also be 
		a conforming <a title="Linked Data Platform Resource">LDP Resource</a> as defined in <a href="#ldpr-resource" class="sectionRef"></a>, along with the
		restrictions in this section. <a title="">LDP client</a>s MAY infer the following triple: one
		whose subject is the <a title="Linked Data Platform RDF Source">LDP-RS</a>, 
		whose predicate is <code>rdf:type</code>, 
		and whose object is <code>ldp:Resource</code>, 
		but there is no requirement to materialize this triple in the LDP-RS representation.
	</h2></section>
	
	<section id="ldprs-gen-atleast1rdftype"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> representations SHOULD 
		have at least one <code>rdf:type</code>
		set explicitly.  This makes the representations much more useful to
		client applications that don’t support inferencing.
	</h2></section><!-- Was 4.2.5 / #ldpr-4_2_5 -->

	<section id="ldprs-rdftype"><h2 class="normal">The representation of a LDP-RS MAY have an <code>rdf:type</code>
		of <code>ldp:RDFSource</code> for <a title="">Linked Data Platform RDF Source</a>.
	</h2></section><!-- Was 5.2.7 / #ldpc-5_2_7 -->
		
	<section id="ldprs-gen-rdf"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide an RDF representation for <a title="Linked Data Platform RDF Source">LDP-RSs</a>. 
	The HTTP <code>Request-URI</code> of the LDP-RS is typically the subject of most triples in the response.
	</h2></section><!-- Was 4.2.2 / #ldpr-4_2_2 -->
	
	<section id="ldprs-gen-reusevocab"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> SHOULD reuse existing vocabularies instead of creating
		their own duplicate vocabulary terms.  In addition to this general rule, some specific cases are
		covered by other conformance rules.
	</h2></section><!-- Was 4.2.4 / #ldpr-4_2_4 -->
	
	<section id="ldprs-gen-reusevocabsuchas"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> predicates SHOULD use standard vocabularies such as Dublin Core
		[[!DC-TERMS]], RDF [[!rdf11-concepts]] and RDF Schema [[!rdf-schema]], whenever
		possible.
	</h2></section><!-- Was 4.2.4.1 / #ldpr-4_2_4_1 -->

	<section id="ldp-cli-multitype"><h2 class="normal">In the absence of special knowledge of the application or domain, 
		<a title="LDP client">LDP clients</a> MUST assume that any LDP-RS can have multiple <code>rdf:type</code> triples with different objects.
	</h2></section> <!-- Was 4.3.5 / #ldpr-4_3_5 -->
	
	<section id="ldpr-cli-typeschange"><h2 class="normal">In the absence of special knowledge of the application or domain, 
		<a title="LDP client">LDP clients</a> MUST assume that the <code>rdf:type</code> values
		of a given LDP-RS can change over time.
	</h2></section> <!-- Was 4.3.6 / #ldpr-4_3_6 -->
	
	<section id="ldpr-cli-openpreds"><h2 class="normal"><a title="LDP client">LDP clients</a> SHOULD always assume that the set of predicates for a
		LDP-RS of a particular type at an arbitrary server is open, in the
		sense that different resources of the same type may not all have the
		same set of predicates in their triples, and the set of predicates that
		are used in the state of any one LDP-RS is not limited to any pre-defined
		set.
	</h2></section> <!-- Was 4.5.3 / #ldpr-ldpr-4_5_3 -->
		
	<section id="ldprs-gen-noinferencing"><h2 class="normal"><a title="LDP server">LDP servers</a>
		MUST NOT require LDP clients to implement inferencing in order to recognize the subset
		of content defined by LDP.  Other specifications built on top of LDP may require clients
		to implement inferencing [[!rdf11-concepts]].  The practical implication is that all content defined by LDP
		must be explicitly represented, unless noted otherwise within this document.
	</h2></section><!-- Was 4.2.11 / #ldpr-4_2_11 -->
	
	<section id="ldpr-cli-preservetriples"><h2 class="normal">
		A <a title="LDP client">LDP client</a> MUST preserve all triples retrieved from a LDP-RS using HTTP <code>GET</code> that
		it doesn’t change whether it understands the predicates or not, when
		its intent is to perform an update using HTTP <code>PUT</code>.  The use of HTTP
		<code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
		[[!RFC5789]].
	</h2></section> <!-- Was 4.5.5 / #ldpr-ldpr-4_5_5 -->
	
	<section id="ldpr-cli-can-hint"><h2 class="normal">
		<a title="LDP client">LDP clients</a> MAY 
		provide LDP-defined hints that allow servers to optimize the content of responses.
		<a href="#prefer-parameters" class="sectionRef"></a> defines hints that apply to 
		<a title="Linked Data Platform RDF Source">LDP-RSs</a>.
	</h2></section> 
	
	<section id="ldpr-cli-hints-ignorable"><h2 class="normal">
		<a title="LDP client">LDP clients</a> MUST 
		be capable of processing responses formed by a LDP server that ignores hints,
		including LDP-defined hints.
	</h2></section>
	
</section> <!-- ldprs-general -->

<section id="ldprs-HTTP_GET">
<h2>HTTP GET</h2>
	<section id="ldprs-get-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST 
		respond with a Turtle
		representation of the requested <a title="Linked Data Platform RDF Source">LDP-RS</a> when
		the request includes an <code>Accept</code> header specifying <code>text/turtle</code>, 
		unless HTTP content negotiation <em>requires</em> a different outcome 
		[[!turtle]].
		</h2>
		<blockquote>
		<em>Non-normative note: </em>
		In other words, Turtle must be returned by <a title="LDP server">LDP servers</a> 
		in the usual case clients would expect (client requests it) 
		as well as cases where the client requests Turtle or other media type(s), content negotiation results in a tie,
		and Turtle is one of the tying media types.
		For example, if the <code>Accept</code> header lists <code>text/turtle</code> as one of several media types with the
		highest relative quality
		factor (<code>q=</code> value), <a title="LDP server">LDP servers</a> must respond with Turtle.
		HTTP servers in general are not required to resolve ties in this way, or to support Turtle at all, but
		<a title="LDP server">LDP servers</a> are.
		On the other hand, if Turtle is one of several requested media types,
		but another media type the server supports has a higher relative quality factor,
		standard HTTP content negotiation rules apply and the server (LDP or not) would not respond with Turtle.
		</blockquote>
	</section><!-- Was 4.3.3 / #ldpr-4_3_3 -->

	<section id="ldprs-get-conneg"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD
		respond with a <code>text/turtle</code>
		representation of the requested <a title="Linked Data Platform RDF Source">LDP-RS</a> whenever 
		the <code>Accept</code> request header is absent [[!turtle]].  
	</h2></section><!-- new -->

	<div class="atrisk" id="atrisk-ldpr-jsonld"><p class="atrisktext">Feature At Risk</p>
	<p>The LDP Working Group proposes incorporation of the following clause requiring JSON-LD support.</p>
	</div>
	<section id="ldprs-get-jsonld"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST 
		respond with a <code>application/ld+json</code>
		representation of the requested <a title="Linked Data Platform RDF Source">LDP-RS</a>
		when the request includes an <code>Accept</code> header, unless content negotiation 
		or <a href="#ldprs-get-turtle">Turtle support</a>
		<em>requires</em> a different outcome [[!JSON-LD]].
	</h2></section><!-- new -->

</section> <!-- ldprs-HTTP_GET -->

</section> <!-- ldprs RDF Source-->

<section id="ldpnr">
<h2>Non-RDF Source</h2>

<p>The following section contains normative clauses for <a title="">Linked Data Platform Non-RDF Source</a>.</p>

<section id="ldpnr-general">
<h2>General</h2>

	<section id="ldpnr-are-ldpr"><h2 class="normal">Each <a title="Linked Data Platform Non-RDF Source">LDP Non-RDF Source</a> MUST also be 
		a conforming <a title="Linked Data Platform Resource">LDP Resource</a> in <a href="#ldpr-resource" class="sectionRef"></a>.  
		<a title="Linked Data Platform Non-RDF Source">LDP Non-RDF Sources</a> may not be able to fully express their
		state using RDF [[rdf11-concepts]]. 
	</h2></section>
	
	<section id="ldpnr-type"><h2 class="normal"><a title="LDP server">LDP servers</a> exposing an <a title="Linked Data Platform Non-RDF Source">LDP Non-RDF Source</a> 
		MAY advertise this by exposing a HTTP <code>Link</code> header
		with a target URI of <code>http://www.w3.org/ns/ldp#NonRDFSource</code>, and
		a link relation type of <code>type</code> (that is, <code>rel='type'</code>)
		in responses to requests made 
		to the LDP-NR's HTTP <code>Request-URI</code> [[!RFC5988]].  
	</h2></section>

</section> <!-- ldpnr Non-RDF Source-->

</section>

</section> <!-- ldpr h1 -->

<section id="ldpc">
<h1>Linked Data Platform Containers</h1>

<section class="informative" id="ldpc-informative">		
<h2>Introduction</h2>
	<p>Many HTTP applications and sites have organizing
		concepts that partition the overall space of resources into smaller
		containers. Blog posts are grouped into blogs, wiki pages are grouped
		into wikis, and products are grouped into catalogs. Each resource
		created in the application or site is created within an instance of
		one of these container-like entities, and users can list the existing
		artifacts within one. Containers answer some basic questions, which
		are:</p>
	<ol>
		<li>To which URLs can I POST to create new resources?</li>
		<li>Where can I GET a list of existing resources?</li>
		<li>How do I get information about the members along with the container?</li>
		<li>How	can I ensure the resource data is easy to query?</li>
		<li>How	is the order of the container entries expressed? [[LDP-PAGING]]</li>
	</ol>
	<p>
		This document defines the representation and behavior of containers
		that address these issues. There are multiple types of containers defined
		to support a variety of use cases, all that support a base set of capabilities.
		The contents of a container is
		defined by a set of triples in its representation (and state) called
		the <a title="Containment triples">containment triples</a> that follow a fixed pattern.
		Additional types of containers allow for the set of members of a container to be
		defined by a set of triples in its representation called
		the <a title="Membership triples">membership triples</a> that follow a consistent pattern
		(see the linked-to definition for the possible patterns). 
		The membership triples of a container all
		have the same predicate, called the membership predicate, 
		and either the subject or the object is also a consistent value
		– the remaining position of the membership
		triples (the one that varies) define the members of the container. 
		In the simplest cases, the
		consistent value will be the LDPC resource's URI, but it does not
		have to be. The membership predicate is also variable and will often
		be a predicate from the server application vocabulary or the <code>ldp:member</code> predicate.
	</p>
	<p>In LDP 1.0, there exists a way for clients to request responses that contain only
	partial representations of the containers.  Applications may define additional means
	by which the response representations contain a filtered set of data and including (or excluding)
	additional details, those means are application-specific and not defined in this document.</p>
	<p>This document includes a set of guidelines for
		creating new resources and adding them to the list of
		resources linked to a container. It goes on to explain how to learn about a set of related
		resources, regardless of how they were created or added to the container's membership.
		It also defines behavior when resources created using a container are later deleted;
		deleting containers removes membership information and
		possibly performs some cleanup tasks on unreferenced member resources.</p>

	<p>The following illustrates a very simple
		container with only three members and some information about the
		container (the fact that it is a container and a brief title):</p>

<em>Request</em> to <code>http://example.org/c1/</code>:
<pre class="example" id="ldpc-ex-simple-req">GET /c1/ HTTP/1.1
Host: example.org
Accept: text/turtle</pre>

<em>Response:</em>
<pre class="example" id="ldpc-ex-simple">HTTP/1.1 200 OK
Content-Type: text/turtle
Date: Thu, 12 Jun 2014 18:26:59 GMT
ETag: "8caab0784220148bfe98b738d5bb6d13"
Accept-Post: text/turtle, application/ld+json
Allow: POST,GET,OPTIONS,HEAD,PUT
Link: &lt;http://www.w3.org/ns/ldp#BasicContainer&gt;; rel="type",
      &lt;http://www.w3.org/ns/ldp#Resource&gt;; rel="type"
Transfer-Encoding: chunked
<!-- @base <http://example.org/c1/>. -->
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.

&lt;http://example.org/c1/&gt;
   a ldp:BasicContainer;
   dcterms:title "A very simple container";
   ldp:contains &lt;r1&gt;, &lt;r2&gt;, &lt;r3&gt;.</pre>
 
 <!-- TODO: consider if basic container diagram helps, if so...add for other cases too
   	<figure id="fig-ldpc-basic">
        <img src="images/ldpc-basic.png" alt="Sample Linked Data Platform Basic Container" />
        <figcaption>Sample of Linked Data Platform Basic Container</figcaption>
    </figure>
     -->

	<p>The preceding example is very straightforward: there are containment triples
	whose subject is the container, whose predicate is  
	<code>ldp:contains</code>, and whose objects are the URIs of the contained resources,
	and there is no distinction between member resources and contained resources. 
	A POST to this container will create a new resource
	and add it to the list of contained resources by adding a new containment triple
	to the container.  This type of container is called a
	<a title="">Linked Data Platform Basic Container</a>.  </p>

	<p>
	Sometimes you have to build on existing models incrementally, so you have fewer degrees of
	freedom in the resource model.  In these situations, it can be useful to help clients map
	LDP patterns onto existing vocabularies, or to include members not created via the container; 
	<a title="Linked Data Platform Direct Container">LDP Direct Containers</a>
	meet those kinds of needs.  Direct Containers allow membership triples to use a subject
	other than the container itself as the consistent membership value, and/or to use
	a  predicate from an application's domain model as the membership predicate. Let's
	start with a pre-existing domain resource for a person's net worth, as illustrated below:</p>
			
<em>Request</em> to <code>http://example.org/netWorth/nw1/</code>:
<pre class="example" id="ldpc-ex-membership-partial-req">GET /netWorth/nw1/ HTTP/1.1
Host: example.org
Accept: text/turtle</pre>

<em>Response:</em>
<pre class="example" id="ldpc-ex-membership-partial">HTTP/1.1 200 OK
Content-Type: text/turtle
Date: Thu, 12 Jun 2014 18:26:59 GMT
ETag: "0f6b5bd8dc1f754a1238a53b1da34f6b"
Link: &lt;http://www.w3.org/ns/ldp#RDFSource&gt;; rel="type",
      &lt;http://www.w3.org/ns/ldp#Resource&gt;; rel="type"
Allow: GET,OPTIONS,HEAD,PUT,DELETE
Transfer-Encoding: chunked
<!-- @base <http://example.org/netWorth/nw1/>. -->
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology#&gt;.

&lt;http://example.org/netWorth/nw1/&gt;
   a o:NetWorth;
   o:netWorthOf &lt;http://example.org/users/JohnZSmith&gt;;
   o:asset 
      &lt;assets/a1&gt;,
      &lt;assets/a2&gt;;
   o:liability 
      &lt;liabilities/l1&gt;,
      &lt;liabilities/l2&gt;,
      &lt;liabilities/l3&gt;.
</pre>
	<p>
	In the preceding example, there is a <code>rdf:type</code> of <code>o:NetWorth</code> indicating the
	resource represents an instance of a person's net worth and a <code>o:netWorthOf</code> predicate indicating 
	the associated person.  There are two sets of same-subject, same-predicate triples; one for assets and
	one for liabilities.  Existing domain-specific applications exist that depend on those types and 
	predicates, so changing them <em>incompatibly</em> would be frowned upon.
	</p>
	
	<p>
	It would be helpful to be able to use LDP patterns to manage the assets and liabilities-related triples.
	Doing so using a Basic Container would require duplicating much of the information with different types and
	predicates, which would be onerous for large resources.  <a title="Linked Data Platform Direct Container">Direct Containers</a>
	provide a middle ground, by giving LDP clients a way to map existing domain-specific resources to LDP's
	types and interaction models.  
	In this specific example, 
	it would be helpful to be able to manage the assets and liabilities triples consistently, for example
	by using LDP containers.
	One way to do this is to create two containers, one to manage assets and another liabilities, 
	as separate HTTP resources.  Existing clients have no need to interact with those containers,
	whereas LDP-enabled clients now have container URLs that they can interact with.  The existing
	resource remains unchanged so that existing clients continue to function normally.
	This is illustrated in the set of related examples, one example per HTTP resource, starting with
	the LDP-RS example from before:
	</p>
	
<em>Request</em> to <code>http://example.org/netWorth/nw1/</code>:
<pre class="example" id="ldpc-ex-membership-full-req">GET /netWorth/nw1/ HTTP/1.1
Host: example.org
Accept: text/turtle</pre>

<em>Response:</em>
<pre class="example" id="ldpc-ex-membership-full">HTTP/1.1 200 OK
Content-Type: text/turtle
Date: Thu, 12 Jun 2014 18:26:59 GMT
ETag: "0f6b5bd8dc1f754a1238a53b1da34f6b"
Link: &lt;http://www.w3.org/ns/ldp#RDFSource&gt;; rel="type",
      &lt;http://www.w3.org/ns/ldp#Resource&gt;; rel="type"
Allow: GET,OPTIONS,HEAD,PUT,DELETE
Transfer-Encoding: chunked
<!-- @base <http://example.org/netWorth/nw1/>. -->
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology#&gt;.

&lt;http://example.org/netWorth/nw1/&gt;
   a o:NetWorth;
   o:netWorthOf &lt;http://example.org/users/JohnZSmith&gt;;
   o:asset 
      &lt;assets/a1&gt;,
      &lt;assets/a2&gt;;
   o:liability 
      &lt;liabilities/l1&gt;,
      &lt;liabilities/l2&gt;,
      &lt;liabilities/l3&gt;.
</pre>


	<p>The structure of the net worth resource is completely unchanged, so any existing 
	domain-specific applications continue to work without impact.
	LDP clients, on the other hand, have no way to understand that the asset and
	liability triples correspond in any way to LDP containers.  For that, they need the
	next two resources.
	</p>
	<p>The first container is a <a title="Linked Data Platform Direct Container">LDP Direct Container</a> to manage assets.  
	Direct Containers add the concept of <a title="Membership">membership</a>
	and flexibility on how to specify the <a title="Membership triples">membership triples</a>.
	</p>

<em>Request</em> to <code>http://example.org/netWorth/nw1/assets/</code>:
<pre class="example" id="ldpc-ex-membership-subj-req">GET /netWorth/nw1/assets/ HTTP/1.1
Host: example.org
Accept: text/turtle</pre>

<em>Response:</em>
<pre class="example" id="ldpc-ex-membership-subj">HTTP/1.1 200 OK
Content-Type: text/turtle
Date: Thu, 12 Jun 2014 18:26:59 GMT
ETag: "6df36eef2631a1795bfe9ab76760ea75"
Accept-Post: text/turtle, application/ld+json
Allow: POST,GET,OPTIONS,HEAD
Link: &lt;http://www.w3.org/ns/ldp#DirectContainer&gt;; rel="type",
      &lt;http://www.w3.org/ns/ldp#Resource&gt;; rel="type"
Transfer-Encoding: chunked
<!-- @base <http://example.org/netWorth/nw1/assets/>. -->      
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix o: &lt;http://example.org/ontology#&gt;.

&lt;http://example.org/netWorth/nw1/assets/&gt;
   a ldp:DirectContainer;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipResource &lt;http://example.org/netWorth/nw1/&gt;;
   ldp:hasMemberRelation o:asset;
   ldp:contains &lt;a1&gt;, &lt;a2&gt;.
</pre>

	<p>
	In the preceding asset container, the consistent membership value 
	(<a title="Membership triples">membership-constant-URI</a>, still in the subject position) is not the
	container itself – it is the (separate) net worth resource. The
	membership predicate is <code>o:asset</code>,
	from the domain model. A POST of an asset representation to the asset container will create a new
	asset and add it to net-worth's list of	assets by adding a new membership triple
	to the resource and a containment triple to the container. 
	</p>

	<p>The second container is a <a title="Linked Data Platform Direct Container">LDP Direct Container</a> to manage liabilities.  
	</p>
<em>Request</em> to <code>http://example.org/netWorth/nw1/liabilities/</code>:
<pre class="example" id="ldpc-ex-membership-full-liabcont-req">GET /netWorth/nw1/liabilities/ HTTP/1.1
Host: example.org
Accept: text/turtle</pre>

<em>Response:</em>
<pre class="example" id="ldpc-ex-membership-full-liabcont">HTTP/1.1 200 OK
Content-Type: text/turtle
Date: Thu, 12 Jun 2014 18:26:59 GMT
ETag: "9f50da01f792281ddcfebe9788372d07"
Link: &lt;http://www.w3.org/ns/ldp#DirectContainer&gt;; rel="type",
      &lt;http://www.w3.org/ns/ldp#Resource&gt;; rel="type"
Accept-Post: text/turtle, application/ld+json
Allow: POST,GET,OPTIONS,HEAD
Transfer-Encoding: chunked
<!-- @base <http://example.org/netWorth/nw1/liabilities/>. -->
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix o: &lt;http://example.org/ontology#&gt;.

&lt;http://example.org/netWorth/nw1/liabilities/&gt;
   a ldp:DirectContainer;
   dcterms:title "The liabilities of JohnZSmith";
   ldp:membershipResource &lt;http://example.org/netWorth/nw1/&gt;;
   ldp:hasMemberRelation o:liability;
   ldp:contains &lt;l1&gt;, &lt;l2&gt;, &lt;l3&gt;.
</pre>

	<p>
	The preceding liability container is completely analogous to the asset container above, simply
	managing liabilities instead of assets and using the <code>o:liability</code> predicate.
	</p>
	<p>
	To add a another liability, a client would POST something like this to the liability container:
	</p>

<em>Request</em> to <code>http://example.org/netWorth/nw1/liabilities/</code>:
<pre class="example" id="ldpc-ex-membership-add-new-liability-req">POST /netWorth/nw1/liabilities/ HTTP/1.1
Host: example.org
Accept: text/turtle
Content-Type: text/turtle
Content-Length: 63
<!-- @base is here only so it's easier to paste into validators for checking -->
@prefix o: &lt;http://example.org/ontology#&gt;.

&lt;&gt;
   a o:Liability.
   # plus any other properties that the domain says liabilities have
</pre>

<em>Response:</em>
<pre class="example" id="ldpc-ex-membership-add-new-liability">HTTP/1.1 201 Created
Location: http://example.org/netWorth/nw1/liabilities/l4
Date: Thu, 12 Jun 2014 19:56:13 GMT
Link: &lt;http://www.w3.org/ns/ldp#DirectContainer&gt;; rel="type",
      &lt;http://www.w3.org/ns/ldp#Resource&gt;; rel="type"
</pre>

	<p>
	Assuming the server successfully processes this request and assigns the URI
	<code>&lt;http://example.org/netWorth/nw1/liabilities/l4&gt;</code> to the 
	newly created liability resource, at least two new triples would be added.
	</p>
	<ol>
	<li>In the net worth resource, <code>&lt;http://example.org/netWorth/nw1/&gt; o:liability &lt;liabilities/l4&gt;</code></li>
	<li>In the liability container, <code>&lt;http://example.org/netWorth/nw1/liabilities/&gt; ldp:contains &lt;l4&gt;</code>.</li>
	</ol>

	<p>
	You might wonder why we chose to create two new containers instead of making
	<code>http://example.org/netWorth/nw1/</code> itself a container.
	A single net worth container would be a fine design if <code>http://example.org/netWorth/nw1/</code>
	had only assets or only liabilities (basically: only a single predicate to manage), 
	but since it has separate predicates for assets and liabilities an ambiguity arises:
	it is unspecified whether a client's creation request (POST)
	should add a new <code>o:asset</code> or <code>o:liability</code> triple. 
	Having separate <code>http://example.org/netWorth/nw1/assets/</code> 
	and <code>http://example.org/netWorth/nw1/liabilities/</code> containers
	allows both assets and liabilities to be created 
	and linked to the net-worth resource using the appropriate predicate.  Similar ambiguities arise
	if the client wishes to list the members and/or contained resources.
	</p>

	<div class="atrisk" id="atrisk-indir-cont-ex"><p class="atrisktext">Feature At Risk</p>
	<p>The LDP Working Group proposes the REMOVAL of indirect containers, unless more implementation reports arrive shortly.</p>
	</div>
	
	<p>Continuing in the multiple containers direction, we will now extend our net worth example to add a container for
	advisors (people) that have managed the assets and liabilities.  We have decided
	to identify these advisors with URLs that contain a fragment (hash) to represent
	these real-world resources, not the documents that describe them.</p>

<em>Request</em> to <code>http://example.org/netWorth/nw1/</code>:
<pre class="example" id="ldpc-ex-membership-full-elab-req">GET /netWorth/nw1/ HTTP/1.1
Host: example.org
Accept: text/turtle</pre>

<em>Response:</em>
<pre class="example" id="ldpc-ex-membership-full-elab">HTTP/1.1 200 OK
Content-Type: text/turtle
Date: Thu, 12 Jun 2014 18:26:59 GMT
ETag: "e8d129f45ca31848fb56213844a32b49"
Link: &lt;http://www.w3.org/ns/ldp#DirectContainer&gt;; rel="type",
      &lt;http://www.w3.org/ns/ldp#Resource&gt;; rel="type"
Allow: GET,OPTIONS,HEAD,PUT,DELETE
Transfer-Encoding: chunked
<!-- @base <http://example.org/netWorth/nw1/>. -->
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
@prefix o: &lt;http://example.org/ontology#&gt;.

&lt;http://example.org/netWorth/nw1/&gt;
   a o:NetWorth;
   o:netWorthOf &lt;http://example.org/users/JohnZSmith&gt;;
   o:advisor
   	 &lt;advisors/bob#me&gt;,     # URI of a person
   	 &lt;advisors/marsha#me&gt;.
   	 
&lt;advisors/&gt;
   a ldp:IndirectContainer;
   dcterms:title "The asset advisors of JohnZSmith";
   ldp:membershipResource &lt;&gt;;
   ldp:hasMemberRelation o:advisor;
   ldp:insertedContentRelation foaf:primaryTopic;
   ldp:contains
   	 &lt;advisors/bob&gt;,     # URI of a document a.k.a. an information resource
   	 &lt;advisors/marsha&gt;.  # describing a person
</pre>	
	
	<p>To handle this type of indirection, the triple with predicate of <code>ldp:insertedContentRelation</code> and object of 
	<code>foaf:primaryTopic</code> informs clients that when POSTing to this container, they need to include a triple of the
	form <code>(&lt;&gt;, foaf:primaryTopic, topic-URI)</code> to inform the server which URI to use 
	(<code>topic-URI</code>) in the new membership triple.</p>
	
	<p>This type of container is referred to as a <a title="Linked Data Platform Indirect Container">LDP Indirect Container</a>. 
	It is similar to an <a title="Linked Data Platform Direct Container">LDP Direct Container</a> 
	but it provides an indirection to add (via a create request) as a member any resource, 
	including a URI representing a real-world object.  Create requests to 
	<a title="Linked Data Platform Direct Container">LDP Direct Containers</a> 
	can only add information resources [[WEBARCH]] - the documents they create - as members.
	</p>

	<p>
	To add a another advisor, a client would POST something like this to the advisors container:
	</p>
<em>Request</em> to <code>http://example.org/netWorth/nw1/advisors/</code>:
<pre class="example" id="ldpc-ex-membership-add-new-advisor-req">POST /netWorth/nw1/advisors/ HTTP/1.1
Host: example.org
Accept: text/turtle
Content-Type: text/turtle
Slug: george
Content-Length: 72
<!-- @base <http://example.org/netWorth/nw1/advisors/george>. -->
@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
@prefix o: &lt;http://example.org/ontology#&gt;.
&lt;&gt;
   a o:Advisor;
   foaf:primaryTopic &lt;#me&gt;.
   # plus any other properties that the domain says advisors have
</pre>

<em>Response:</em>
<pre class="example" id="ldpc-ex-membership-add-new-advisor">HTTP/1.1 201 Created
Location: http://example.org/netWorth/nw1/advisors/george
Date: Thu, 12 Jun 2014 19:56:13 GMT
Link: &lt;http://www.w3.org/ns/ldp#RDFSource&gt;; rel="type",
      &lt;http://www.w3.org/ns/ldp#Resource&gt;; rel="type"
</pre>

	<p>
	Assuming the server successfully processes this request and assigns the URI
	<code>&lt;http://example.org/netWorth/nw1/advisors/george&gt;</code> to the 
	newly created advisor resource, at least two new triples would be added.
	</p>
	<ol>
	<li>In the net worth resource, <code>&lt;http://example.org/netWorth/nw1/&gt; o:advisor &lt;advisors/george#me&gt;</code></li>
	<li>In the advisors container, <code>&lt;http://example.org/netWorth/nw1/advisors/&gt; ldp:contains &lt;george&gt;</code></li>
	</ol>

	<p>In summary, <a href="#fig-ldpc-types"></a> illustrates the LDP-defined container types: Basic, Direct, and Indirect, along
	with their class relationship to types of LDPRs.</p>
	
	 <figure id="fig-ldpc-types">
        <img src="images/ldpc-hierarchy.png" alt="Types of Linked Data Platform Containers" />
        <figcaption>Class relationship of types of Linked Data Platform Containers</figcaption>
    </figure>

	<p>The following table illustrates some differences between <a title="membership">membership</a> and 
	<a title="containment">containment</a> triples.  For details on the normative behavior, see appropriate sections
	below.
	</p>
	<table style="border: 1px solid gray" id="ldpc-mbrcntdiff">
		<thead><tr><th rowspan="2">Completed Request</th><th style="background:#FFFFFF;" colspan="2">Effects</th></tr>
		       <tr class="oddrow"><th>Membership</th><th>Containment</th></tr></thead>
		<tr><td>LDPR created in LDP-BC</td><td>New triple: (LDPC, ldp:contains, LDPR)</td><td>Same</td></tr>
		<tr><td>LDPR created in LDP-DC</td><td>New triple links LDP-RS to created LDPR. LDP-RS URI may be same as LDP-DC</td>
			<td>New triple: (LDPC, ldp:contains, LDPR)</td></tr>
		<tr><td>LDPR created in LDP-IC</td><td>New triple links LDP-RS to content indicated URI</td>
			<td>New triple: (LDPC, ldp:contains, LDPR)</td></tr>
		<tr><td>LDPR is deleted</td><td>Membership triple may be removed</td><td>(LDPC, ldp:contains, LDPR) triple is removed
			</td></tr>
		<tr><td>LDPC is deleted</td><td>Triples and member resources may be removed</td><td>Triples of form 
			(LDPC, ldp:contains, LDPR) and contained LDPRs may be removed</td></tr>
	</table>

<section id="ldpc-get_minimal-container_props"><h2 class="normal">Retrieving Only Minimal-Container Triples
	</h2><!-- Was 5.1.1 / #ldpc-get_minimal-container_props -->
	<p>The representation of a container
		that has many members will be large. There are several important
		cases where clients need to access only the subset of the container's properties 
		that are unrelated to member resources and unrelated to contained documents, for
		example to determine the membership triple pattern and membership predicate of an 
		LDP-DC.  LDP calls these <a title="Minimal-container triples">minimal-container triples</a>,
		because they are what remains when the container has zero members and zero contained resources.
		Since retrieving the whole container representation to
		get this information may be onerous for clients and cause unnecessary
		overhead on servers, we define a way to retrieve only
		these property values (and more generally, a way to retrieve only the 
		subset of properties used to address other major clusters of use cases).
		LDP adds parameters to the HTTP <code>Prefer</code> header's 
		<code>return=representation</code> preference for this 
		(see <a href="#prefer-parameters" class="sectionRef"></a> for details).
	</p>
	<p>The example listed here only shows
		a simple case where few minimal-container triples are
		retrieved. In real world situations more complex cases are likely, such as those that add other predicates to
		containers, for example providing validation information and
		associating SPARQL endpoints. [[sparql11-query]]</p>
	<p>
		Here is an example requesting the minimal-container triples of a
		container identified by the URL <code>http://example.org/container1/</code>.
	</p>
<p id="ldpc-ex-minimal-container"><em>Request</em> to <code>http://example.org/container1/</code>:</p>
<pre class="example">GET /container1/ HTTP/1.1
Host: example.org
Accept: text/turtle
Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer"
</pre>
<p><em>Response:</em></p>
<pre class="example">HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: "_87e52ce291112"
Link: &lt;http://www.w3.org/ns/ldp#DirectContainer&gt;; rel="type",
      &lt;http://www.w3.org/ns/ldp#Resource&gt;; rel="type"
Accept-Post: text/turtle, application/ld+json
Allow: POST,GET,OPTIONS,HEAD
Preference-Applied: return=representation
Transfer-Encoding: chunked

@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.

&lt;http://example.org/container1/&gt;
   a ldp:DirectContainer;
   dcterms:title "A Linked Data Platform Container of Acme Resources";
   ldp:membershipResource &lt;http://example.org/container1/&gt;;
   ldp:hasMemberRelation ldp:member;
   ldp:insertedContentRelation ldp:MemberSubject;
   dcterms:publisher &lt;http://acme.com/&gt;.</pre>
   
	<p>
		LDP recommends using PATCH to update these properties, if necessary.  It provides no facility
		for updating them via PUT without replacing the entire container's state.
	</p>
	</section><!-- ldpc-get_minimal-container_props -->

</section>

<section id="ldpc-container">
<h2>Container</h2>
<p>The following section contains normative clauses for <a title="">Linked Data Platform Container</a>.</p>

<section id="ldpc-general">
<h2>General</h2>
	<p>The Linked Data Platform does not define how clients
		discover <dfn><abbr title="Linked Data Platform Containers">LDPCs</abbr></dfn>.</p>

	<section id="ldpc-isldpr"><h2 class="normal">Each <a title="">Linked Data Platform Container</a> MUST also be 
		a conforming <a title="">Linked Data Platform RDF Source</a>. <a title="">LDP client</a>s MAY infer the following triple: one
	whose subject is the <a title="Linked Data Platform Container">LDPC</a>, 
	whose predicate is <code>rdf:type</code>, 
	and whose object is <code>ldp:RDFSource</code>, 
	but there is no requirement to materialize this triple in the LDPC representation.
	</h2></section><!-- Was 5.2.1 / #ldpc-5_2_1 -->
		
	<section id="ldpc-typecontainer"><h2 class="normal">The representation of a LDPC MAY have an <code>rdf:type</code>
		of <code>ldp:Container</code> for <a title="">Linked Data Platform Container</a>.
		Non-normative note: <a href="#ldp-rdfconcepts-extra-triples-types">LDPCs
		might have additional types</a>, like any <a title="Linked Data Platform RDF Source">LDP-RS</a>.
	</h2></section><!-- Was 5.2.7 / #ldpc-5_2_7 -->
	
	<section id="ldpc-nordfcontainertypes"><h2 class="normal">LDPC representations SHOULD NOT use RDF container types <code>rdf:Bag</code>,
		<code>rdf:Seq</code> or <code>rdf:List</code>.
	</h2></section><!-- Was 5.2.8 / #ldpc-5_2_8 -->
	
	<div class="atrisk" id="atrisk-indir-cont-ref1"><p class="atrisktext">Feature At Risk</p>
	<p>The LDP Working Group proposes the REMOVAL of indirect containers, unless more implementation reports arrive shortly,
		which would change the contents of the list below.</p>
	</div>
	
	<section id="ldpc-linktypehdr"><h2 class="normal"><a title="LDP server">LDP servers</a>
		exposing LDPCs
		MUST advertise their LDP support by exposing a HTTP <code>Link</code> header
		with a target URI matching the type of container (see below) the
		server supports, and
		a link relation type of <code>type</code> (that is, <code>rel='type'</code>)
		in all responses to requests made 
		to the LDPC's HTTP <code>Request-URI</code>. 
		<a title="LDP server">LDP servers</a> MAY provide additional HTTP <code>Link: rel='type'</code> headers.
		The <a href="#ldpr-gen-linktypehdr">notes on the corresponding LDPR constraint</a> apply
		equally to LDPCs.
	</h2>
	<blockquote>
	<p>Valid container type URIs for <code>rel='type'</code> defined by this document are:
	<ul>
	<li><code>http://www.w3.org/ns/ldp#BasicContainer</code> - for <a href="#ldpbc">LDP Basic Containers</a></li>
	<li><code>http://www.w3.org/ns/ldp#DirectContainer</code> - for <a href="#ldpdc">LDP Direct Containers</a></li>
	<li><code>http://www.w3.org/ns/ldp#IndirectContainer</code> - for <a href="#ldpic">LDP Indirect Containers</a></li>
	</ul>
	</p>
	</blockquote>
	</section><!-- Was 5.2.11 / #ldpc-5_2_11 -->
	
	<section id="ldpc-prefer"><h2 class="normal"><a title="LDP server">LDP servers</a>
		SHOULD respect all of a client's LDP-defined hints, for example 
		<a href="#prefer-parameters">which subsets of LDP-defined state</a>
		the client is interested in processing,
		to influence the set of triples returned in representations of a LDPC, 
		particularly for large LDPCs.  See also [[LDP-PAGING]].
	</h2></section>
	
</section>

<section id="ldpc-HTTP_GET">	
<h2>HTTP GET</h2>
	<p>
		Per <a href="#ldpr-HTTP_GET" class="sectionRef"></a> the HTTP GET method is required and 
		additional requirements can be found in <a href="#ldpc-general" class="sectionRef"></a>.
	</p>
	
</section>

<section id="ldpc-HTTP_POST">
<h2>HTTP POST</h2>
	<p>
		Per [[!RFC7231]], this HTTP method is optional and 
		this specification does not require <a title="LDP server">LDP servers</a> to support it.
		When a LDP server supports this method, 
		this specification imposes the following new requirements for LDPCs.
	</p>
		
	<p>
		Any server-imposed constraints on creation or update  
		<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
	</p>
		
	<section id="ldpc-post-created201"><h2 class="normal">LDP clients SHOULD create member resources by submitting a representation as
		the entity body of the HTTP <code>POST</code> to a known LDPC. If the resource was created successfully, <a title="LDP server">LDP servers</a> MUST
		respond with status code 201 (Created) and the <code>Location</code>
		header set to the new resource’s URL. Clients shall not expect any representation in the response
		entity body on a 201 (Created) response.
	</h2></section><!-- Was 5.4.1 / #ldpc-5_4_1 -->

	<section id="ldpc-post-createdmbr-contains"><h2 class="normal">
		When a successful HTTP <code>POST</code> request to a LDPC results in the creation of a LDPR, a 
		<a title="Containment triples">containment triple</a> MUST be added to the state of the LDPC
		whose subject is the LDPC URI, 
		whose predicate is <code>ldp:contains</code> and whose object is the URI for the newly created document (LDPR).  Other triples may be added as well.
		The newly created LDPR appears as a contained resource of the LDPC until the
		newly created document is deleted or removed by other methods. 
	</h2></section>
	
	<section id="ldpc-post-createbins"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY accept an HTTP <code>POST</code> of non-RDF representations 
	<a title="Linked Data Platform Non-RDF Source">(LDP-NRs)</a> for
		creation of any kind of resource, for example binary resources.  See <a href="#ldpc-post-acceptposthdr">the Accept-Post section</a> for 
		details on how clients can discover whether a LDPC supports this behavior.
	</h2></section><!-- Was 5.4.3 / #ldpc-5_4_3 -->
	
	<section id="ldpc-post-createrdf"><h2 class="normal"><a title="LDP server">LDP servers</a> that successfully create a resource from a
		RDF representation in the request entity body MUST honor the client's requested interaction model(s). 
		If any requested interaction model cannot be honored, the server MUST fail the request.
	</h2><!-- Was 5.4.4 / #ldpc-5_4_4 -->
	<blockquote>
	<ul>
	<li>If the request header specifies <a href="#ldpr-gen-linktypehdr">a LDPR interaction model</a>, then the server MUST handle subsequent 
	requests to the newly created resource's URI as if it is a LDPR.
	When the
	server treats the resource as a LDPR, then clients can only depend upon behaviors defined by LDPRs, 
	even if the content contains an <code>rdf:type</code> triple indicating a type of LDPC.
	That is, if the server's statement conflicts with the content's, the server's statement wins.</li>
	<li>If the request header specifies <a href="#ldpc-linktypehdr">a LDPC interaction model</a>, then the server MUST handle subsequent 
	requests to the newly created resource's URI as if it is a LDPC.
	</li>
	<li>This specification does not constrain the server's behavior in other cases.</li>
	</ul>
	<p>Clients use the same syntax, that is <code>HTTP Link</code> headers, to specify the desired interaction model
		when creating a resource as servers use to advertise it on responses.
	</p>
	<p>Note: A consequence of <a href="#ldpc-post-createrdf">this</a> is that LDPCs can be used to create LDPCs, if the server supports doing so.</p>
	<p>Non-normative note: LDP assumes that the interaction model of a resource is fixed when the resource is created,
	    and this is reflected in the language of the bullets.  If an implementation were to extend LDP by allowing the
		interaction model to vary after creation, that is viewed as a compatible extension to LDP and the statements 
		above would constrain the default interaction model rather than saying that no other behavior is possible.
	</p>
	</blockquote>
	</section>
	
	<section id="ldpc-post-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a> 
		that allow creation of <a title="Linked Data Platform RDF Source">LDP-RSs</a> via POST MUST 
		allow clients to create new members by enclosing a request entity body with a 
	    <code>Content-Type</code> request header whose value is <code>text/turtle</code> [[!turtle]].
	</h2></section><!-- Was 5.4.5 / #ldpc-5_4_5 -->
	
	<section id="ldpc-post-contenttype"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD use the <code>Content-Type</code> request header 
		to determine the request representation's format when the request has an entity body. 
	</h2></section><!-- Was 5.4.6 / #ldpc-5_4_6 -->
	
	<section id="ldpc-post-rdfnullrel"><h2 class="normal"><a title="LDP server">LDP servers</a>  
		creating a <a title="Linked Data Platform RDF Source">LDP-RS</a> via POST MUST 
		interpret the null relative
		URI for the subject of triples in the LDP-RS representation in the
		request entity body as identifying the entity in the request body.
		Commonly, that entity is the model for the "to be created" LDPR, so
		triples whose subject is the null relative URI result in
		triples in the created resource whose subject is the created
		resource.  
	</h2></section><!-- Was 5.4.7 / #ldpc-5_4_7 -->	
	<!-- TODO: add link to "relative URIs on post-create are dangerous" -->	
	
	<section id="ldpc-post-serverassignuri"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD assign the URI for the resource to be
		created using server application specific rules in the absence of a <a href="#ldpc-post-slug">client hint</a>.
	</h2></section><!-- Was 5.4.8 / #ldpc-5_4_8 -->
	
	<section id="ldpc-post-mincontraints"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to create new resources without
		requiring detailed knowledge of application-specific constraints.
		This is a consequence of the requirement to enable simple creation and modification of LDPRs. LDP servers
		expose these application-specific constraints as described in <a href="#ldpr-general" class="sectionRef"></a>.
	</h2></section><!-- Was 5.4.9 / #ldpc-5_4_9 -->
	
	<section id="ldpc-post-slug"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY allow clients to suggest the URI for a resource
		created through <code>POST</code>, using the HTTP <code>Slug</code> header as defined in [[!RFC5023]].  LDP adds
		no new requirements to this usage, so its presence functions as a client hint to the server 
		providing a desired string to be incorporated into the server's final choice of resource URI.
	</h2></section><!-- Was 5.4.10 / #ldpc-5_4_10 -->
	
	<section id="ldpc-post-dontreuseuris"><h2 class="normal"><a title="LDP server">LDP servers</a> that allow member creation via <code>POST</code> 
		SHOULD NOT re-use URIs.
	</h2></section><!-- Was 5.4.11 / #ldpc-5_4_11 -->
	
	<section id="ldpc-post-createbinlinkmetahdr"><h2 class="normal">Upon successful creation of an  
	<a title="Linked Data Platform Non-RDF Source">LDP-NR</a> (HTTP status code of 
	201-Created and URI indicated by <code>Location</code> response header), <a title="LDP server">LDP servers</a> MAY create an associated 
	<a title="Linked Data Platform RDF Source">LDP-RS</a>
	to contain data about the newly created LDP-NR.  
	If a LDP server creates this associated <a title="Linked Data Platform RDF Source">LDP-RS</a>, it MUST indicate
	its location in the response by adding a HTTP <code>Link</code> header with 
	a context URI identifying the newly created <a title="Linked Data Platform Non-RDF Source">LDP-NR</a> (instead of the effective request URI),
	a link relation value of <code>describedby</code>,
	and a target URI identifying the associated LDP-RS resource [[!RFC5988]].
	</h2></section><!-- Was 5.4.12 / #ldpc-5_4_12 -->
	
	<section id="ldpc-post-acceptposthdr"><h2 class="normal"><a title="LDP server">LDP servers</a> that support <code>POST</code> MUST
		include an <a href="#header-accept-post"><code>Accept-Post</code> response header</a> on HTTP <code>OPTIONS</code>
		responses, listing <code>POST</code> request media type(s) supported by the server.
		LDP only specifies the use of <code>POST</code> for the purpose of creating new resources, but a server
		can accept <code>POST</code> requests with other semantics.  
		While "POST to create" is a common interaction pattern, LDP clients are not guaranteed, even when 
		making requests to a LDP server, that every successful <code>POST</code> request will result in the 
		creation of a new resource; they must rely on out of band information for knowledge of which <code>POST</code> requests,
		if any, will have the "create new resource" semantics.
		This requirement on LDP servers is intentionally stronger than the one levied in the
		<a href="#header-accept-post">header registration</a>; it is unrealistic to expect all existing resources
		that support <code>POST</code> to suddenly return a new header or for all new specifications constraining
		<code>POST</code> to be aware of its existence and require it, but it is a reasonable requirement for new
		specifications such as LDP.
	</h2></section><!-- Was 5.4.13 / #ldpc-5_4_13 -->
	
	<div class="atrisk" id="atrisk-ldpc-jsonld"><p class="atrisktext">Feature At Risk</p>
	<p>The LDP Working Group proposes incorporation of the following clause requiring JSON-LD support.</p>
	</div>
	<section id="ldpc-post-jsonld"><h2 class="normal"><a title="LDP server">LDP servers</a> 
		that allow creation of <a title="Linked Data Platform RDF Source">LDP-RSs</a> via POST MUST 
		allow clients to create new members by enclosing a request entity body with a 
	    <code>Content-Type</code> request header whose value is <code>application/ld+json</code> [[!JSON-LD]].
	</h2></section><!-- new -->
	
</section>

<section id="ldpc-HTTP_PUT">
<h2>HTTP PUT</h2>
	<p>
		Per [[!RFC7231]], this HTTP method is optional and 
		this specification does not require <a title="LDP server">LDP servers</a> to support it.
		When a LDP server supports this method, 
		this specification imposes the following new requirements for LDPCs.
	</p>
		
	<p>
		Any server-imposed constraints on creation or update  
		<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
	</p>
		
	<section id="ldpc-put-mbrprops"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD NOT allow HTTP <code>PUT</code> to update a LDPC’s <a>containment triples</a>; 
		if the server receives such a request, it SHOULD respond with a 409
		(Conflict) status code.
	</h2></section><!-- Was 5.5.1 / #ldpc-5_5_1 -->
	
	<section id="ldpc-put-create"><h2 class="normal"><a title="LDP server">LDP servers</a> that allow LDPR creation via <code>PUT</code> 
		SHOULD NOT re-use URIs.  
	</h2></section><!-- Was 5.5.4 / #ldpc-5_5_4 -->
	
</section>

<section id="ldpc-HTTP_DELETE">
<h2>HTTP DELETE</h2>
	<p>
		Per [[!RFC7231]], this HTTP method is optional and 
		this specification does not require <a title="LDP server">LDP servers</a> to support it.
		When a LDP server supports this method, 
		this specification imposes the following new requirements for LDPCs.
	</p>
		
	<section id="ldpc-del-contremovesconttriple"><h2 class="normal">
		When a <a title="containment">contained LDPR</a> is deleted, the LDPC server MUST also remove 
		the corresponding containment triple, which has the effect of removing the deleted LDPR from the containing LDPC.
	</h2>
	<blockquote>
		Non-normative note: The <a>LDP server</a> might perform additional actions, 
		as described in the <a href="#ldp-http-method-side-effects">normative references</a> like [[!RFC7231]]. 
		For example, the server could remove membership triples referring to the deleted LDPR, 
		perform additional cleanup tasks for resources it knows are no longer referenced or have not
		been accessed for some period of time, and so on.
	</blockquote>
	</section><!-- Was 5.6.1 / #ldpc-5_6_1 -->
	
	<section id="ldpc-del-contremovescontres"><h2 class="normal">
	When a <a title="containment triples">contained LDPR</a> is deleted, and the LDPC server 
	created an associated LDP-RS (see the <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>), the LDPC server MUST also delete the associated LDP-RS it created.
	</h2></section><!-- Was 5.6.4 / #ldpc-5_6_4 -->
	
</section>

<section id="ldpc-HTTP_HEAD">
<h2>HTTP HEAD</h2>
	<p>Note that certain LDP mechanisms  
		rely on HTTP headers, and HTTP recommends that
		<code>HEAD</code> responses include the same headers as <code>GET</code> responses. 
		<a title="LDP server">LDP servers</a> must also include HTTP headers
		on responses 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"></a> and <a href="#ldpc-HTTP_OPTIONS" class="sectionRef"></a>.</p>
</section>

<section id="ldpc-HTTP_PATCH">
<h2>HTTP PATCH</h2>
	<p>
		Per [[!RFC5789]], this HTTP method is optional and 
		this specification does not require <a title="LDP server">LDP servers</a> to support it.
		When a LDP server supports this method, 
		this specification imposes the following new requirements for LDPCs.
	</p>
		
	<p>
		Any server-imposed constraints on LDPR creation or update  
		<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
	</p>
		
	<section id="ldpc-patch-req"><h2 class="normal">
		<a title="LDP server">LDP servers</a> are RECOMMENDED 
		to support HTTP <code>PATCH</code> as the preferred method for 
		updating a LDPC's <a title="Minimal-container triples">minimal-container triples</a>.
	</h2></section><!-- Was 5.8.1 / #ldpc-5_8_1 -->
</section>

<section id="ldpc-HTTP_OPTIONS">
<h2>HTTP OPTIONS</h2>
	<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for LDPCs.
		Note that support for this method is required for LDPCs, since <a href="#ldpr-HTTP_OPTIONS">it is required for LDPRs</a> and 
		<a href="#ldpc-isldpr">LDPCs adhere to LDP-RS requirements</a>.
		</p>

	<section id="ldpc-options-linkmetahdr"><h2 class="normal">
	When responding to requests whose <code>request-URI</code> is a 
	<a href="#ldpc-post-createbinlinkmetahdr">LDP-NR with an associated LDP-RS</a>, 
	a LDPC server MUST provide the same HTTP <code>Link</code>
	response header as is <a href="#ldpc-post-createbinlinkmetahdr">required in the create response</a>.
	</h2></section><!-- Was 5.9.2 / #ldpc-5_9_2 -->
</section> <!-- h2 -->
</section> <!-- ldpc-container -->

<section id="ldpbc">
<h2>Basic</h2>

<p>The following section contains normative clauses for <a title="">Linked Data Platform Basic Container</a>.</p>


<section id="ldpbc-general">
<h2>General</h2>

<section id="ldpbc-are-ldpcs"><h2 class="normal">Each <a title="Linked Data Platform Basic Container">LDP Basic Container</a> MUST also be 
	a conforming <a title="Linked Data Platform Container">LDP Container</a> in <a href="#ldpc-container" class="sectionRef"></a> along with the
	following restrictions in this section. <a title="">LDP client</a>s MAY infer the following triple:
	whose subject is the <a title="Linked Data Platform Basic Container">LDP Basic Container</a>, 
	whose predicate is <code>rdf:type</code>, 
	and whose object is <code>ldp:Container</code>, 
	but there is no requirement to materialize this triple in the LDP-BC representation.
</h2></section>

</section> <!-- ldpbc General -->

</section> <!-- ldpbc Basic -->


<section id="ldpdc">
<h2>Direct</h2>

<p>The following section contains normative clauses for <a title="">Linked Data Platform Direct Container</a>.</p>
	
<section id="ldpdc-general">
<h2>General</h2>

<section id="ldpdc-are-ldpcs"><h2 class="normal">Each <a title="Linked Data Platform Direct Container">LDP Direct Container</a> MUST also be 
	a conforming <a title="Linked Data Platform Container">LDP Container</a> in <a href="#ldpc-container" class="sectionRef"></a> along the following
	restrictions.  <a title="">LDP client</a>s MAY infer the following triple:
	whose subject is the <a title="Linked Data Platform Direct Container">LDP Direct Container</a>, 
	whose predicate is <code>rdf:type</code>, 
	and whose object is <code>ldp:Container</code>, 
	but there is no requirement to materialize this triple in the LDP-DC representation.
</h2></section>

<section id="ldpdc-mbrpred"><h2 class="normal">
	<a title="Linked Data Platform Direct Container">LDP Direct Containers</a>
	SHOULD use the <code>ldp:member</code> predicate as a LDPC's <a title="Membership predicate">membership predicate</a>
	if there is no obvious predicate from an application vocabulary to use.
	The state of a LDPC includes information about which
	resources are its members, in the form of <a title="Membership triples">membership triples</a> that
	follow a consistent pattern.  The LDPC's state contains enough information for clients to discern
	the <a title="Membership predicate">membership predicate</a>, the other consistent membership
	value used in the container's membership triples (<var>membership-constant-URI</var>), 
	and the position (subject or object) where those URIs
	occurs in the <a title="Membership triples">membership triples</a>.
	Member resources can be
	any kind of resource identified by a URI, LDPR or otherwise.
</h2></section><!-- Was 5.2.3 / #ldpc-5_2_3 -->

<section id="ldpdc-containres"><h2 class="normal">Each <a title="Linked Data Platform Direct Container">LDP Direct Container</a>
	representation MUST contain exactly one triple 
	whose subject is the LDPC URI, 
	whose predicate is the <code>ldp:membershipResource</code>, 
	and whose object is the LDPC's <var>membership-constant-URI</var>.
	Commonly the LDPC's URI is the <var>membership-constant-URI</var>, but LDP does not require this.
</h2>
</section><!-- Was 5.2.4 / #ldpc-5_2_4 -->

<section id="ldpdc-containtriples"><h2 class="normal">Each <a title="Linked Data Platform Direct Container">LDP Direct Container</a>
	representation MUST contain exactly one triple 
	whose subject is the LDPC URI, 
	and whose predicate is either <code>ldp:hasMemberRelation</code> or <code>ldp:isMemberOfRelation</code>. 
	The object of the triple is constrained by other sections, such as
	<a href="#ldpdc-containtriple-relation" class="sectionRef">ldp:hasMemberRelation</a> or 
	<a href="#ldpdc-containtriple-byrelation" class="sectionRef">ldp:isMemberOfRelation</a>, based on the 
	<a title="Membership triples">membership triple</a> 
	pattern used by the container.
</h2><!-- Was 5.2.5 / #ldpc-5_2_5 -->
	
<section id="ldpdc-containtriple-relation"><h2 class="normal"><a title="Linked Data Platform Direct Container">LDP Direct Containers</a>
	whose <a title="Membership triples">membership triple</a> 
	pattern is <var>( membership-constant-URI , membership-predicate , member-derived-URI )</var> MUST
	contain exactly one triple
	whose subject is the LDPC URI, 
	whose predicate is <code>ldp:hasMemberRelation</code>, 
	and whose object is the URI of <var>membership-predicate</var>.
</h2>
</section><!-- Was 5.2.5.1 / #ldpc-5_2_5_1 -->
	
<section id="ldpdc-containtriple-byrelation"><h2 class="normal"><a title="Linked Data Platform Direct Container">LDP Direct Containers</a>
	whose <a title="Membership triples">membership triple</a> 
	pattern is <var>( member-derived-URI , membership-predicate , membership-constant-URI )</var> MUST
	contain exactly one triple
	whose subject is the LDPC URI, 
	whose predicate is <code>ldp:isMemberOfRelation</code>, 
	and whose object is the URI of <var>membership-predicate</var>.
</h2></section><!-- Was 5.2.5.2 / #ldpc-5_2_5_2 -->
</section>

	<div class="atrisk" id="atrisk-indir-cont-ref2"><p class="atrisktext">Feature At Risk</p>
	<p>The LDP Working Group proposes the REMOVAL of indirect containers, unless more implementation reports arrive shortly.</p>
	<p>If it is removed, ldp:insertedContentRelation will be removed as well; its only function currently is to distinguish
	   creation behavior between direct and indirect containers.</p>
	</div>
	
<section id="ldpdc-indirectmbr-basic"><h2 class="normal">
	<a title="Linked Data Platform Direct Container">LDP Direct Containers</a>  
	MUST behave as if they
	have a <var>( LDPC URI, <code>ldp:insertedContentRelation</code> , <code>ldp:MemberSubject</code> )</var>
	triple, but LDP imposes no requirement to materialize such a triple in the LDP-DC representation.
	The value <code>ldp:MemberSubject</code> means that the 
	<var>member-derived-URI</var> is the URI assigned by the server to a 
	document it creates; for example, if the client POSTs content to a container
	that causes the container to create a new LDPR, <code>ldp:MemberSubject</code> says
	that the <var>member-derived-URI</var> is the URI assigned to the newly created LDPR.
</h2></section>

</section> <!-- ldpdc-general -->

<section id="ldpdc-HTTP_POST">
<h2>HTTP POST</h2>
	<section id="ldpdc-post-createdmbr-member"><h2 class="normal">
		When a successful HTTP <code>POST</code> request to a LDPC results in the creation of a LDPR, 
		the LDPC MUST update its membership triples to reflect that addition, and the resulting 
		membership triple MUST be consistent with any LDP-defined predicates it exposes.
		A <a title="Linked Data Platform Direct Container">LDP Direct Container</a>'s membership triples MAY also be modified via 
		through other means. 
	</h2></section><!-- Was 5.4.2 / #ldpc-5_4_2 -->
</section> <!-- ldpdc-HTTP_POST -->

<section id="ldpdc-HTTP_DELETE">
<h2>HTTP DELETE</h2>

	<section id="ldpdc-del-contremovesmbrtriple"><h2 class="normal">
		When a LDPR identified by the object of a <a title="membership triples">membership triple</a> which was
		originally created by the LDP-DC is deleted, the LDPC server MUST also remove 
		the corresponding membership triple.
	</h2>
	</section><!-- Was 5.6.1 / #ldpc-5_6_1 -->

</section> <!-- ldpdc-HTTP_DELETE -->

</section> <!-- ldpdc Direct -->

<section id="ldpic">
<h2>Indirect</h2>

	<div class="atrisk" id="atrisk-indirect-containers"><p class="atrisktext">Feature At Risk</p>
	<p>The LDP Working Group proposes the REMOVAL of indirect containers, unless more implementation reports arrive shortly.</p>
	</div>
	
<p>The following section contains normative clauses for <a title="">Linked Data Platform Indirect Container</a>.</p>

<section id="ldpic-general">
<h2>General</h2>

<section id="ldpic-are-ldpcs"><h2 class="normal">Each <a title="Linked Data Platform Indirect Container">LDP Indirect Container</a> MUST also be 
	a conforming <a title="Linked Data Platform Direct Container">LDP Direct Container</a> as described in <a href="#ldpdc" class="sectionRef"></a>, along with the following
	restrictions.  <a title="">LDP client</a>s MAY infer the following triple: one 
	whose subject is <a title="Linked Data Platform Indirect Container">LDP Indirect Container</a>, 
	whose predicate is <code>rdf:type</code>, 
	and whose object is <code>ldp:Container</code>, 
	but there is no requirement to materialize this triple in the LDP-IC representation.
</h2></section>

<section id="ldpic-indirectmbr"><h2 class="normal">
	<a title="Linked Data Platform Indirect Container">LDP Indirect Containers</a>
	MUST contain exactly one triple whose
    subject is the LDPC URI, 
	whose predicate is <code>ldp:insertedContentRelation</code>, and 
	whose object <var>ICR</var> describes how the <var>member-derived-URI</var> in 
	the container's <a title="Membership triples">membership triples</a> is chosen.
	The <var>member-derived-URI</var> is taken from some triple 
	<var>( S, P, O )</var> in the document supplied by the client as input to the create request;
	if <var>ICR</var>'s value is <var>P</var>, then the <var>member-derived-URI</var> is
	<var>O</var>.  LDP does not define the behavior when more than one triple containing 
	the predicate <var>P</var> is present in the client's input.
	For example, if the client POSTs RDF content to a container
	that causes the container to create a new LDP-RS, and that content contains the triple 
	<var>( &lt;&gt; , foaf:primaryTopic , bob#me )</var>
	<code>foaf:primaryTopic</code> says
	that the <var>member-derived-URI</var> is <var>bob#me</var>.  
	One consequence of this definition is that indirect container member creation is only 
	well-defined by LDP when the document supplied by the client as input to the create request
	has an RDF media type.
	</h2>
</section><!-- Was 5.2.10 / #ldpc-5_2_10 -->
</section> <!-- ldpic General -->

<section id="ldpic-HTTP_POST">
<h2>HTTP POST</h2>
	<section id="ldpic-post-indirectmbrrel"><h2 class="normal">LDPCs 
		whose <code>ldp:insertedContentRelation</code> triple has an object
		<strong>other than</strong> <code>ldp:MemberSubject</code> 
		and that create new resources 
		MUST add a triple to the container
		whose subject is the container's URI, 
		whose predicate is <code>ldp:contains</code>, and
		whose object is the newly created resource's URI (which will be different from
		the <var><a href="#ldpic-indirectmbr">member-derived URI</a></var> in this case).
		This <code>ldp:contains</code> triple can be the only link from the container to the newly created
		resource in certain cases.
	</h2></section><!-- Was 5.4.15 / #ldpc-5_4_15 -->
</section> <!-- ldpic HTTP_POST -->

</section> <!-- ldpic Indirect -->

</section> <!-- h1 LDPC -->


<section id="base-specs" class="informative">
<h1>Notable information from normative references</h1>
<p>
While readers, and especially implementers, of LDP are assumed to understand the information in its normative 
references, the working group has found that certain points are particularly important to understand.
For those thoroughly familiar with the referenced specifications, these points might seem obvious, yet
experience has shown that few non-experts find all of them obvious.  This section enumerates these topics; 
it is simply re-stating (non-normatively) information locatable via the normative references.
</p>

<section id="specs-webarch" class="informative">
<h2>Architecture of the World Wide Web</h2>
Reference: [[!WEBARCH]]

	<section id="ldp-webarch-nonexcl-membership" ><h2 class="normal">LDPC membership is not exclusive; this means that the same resource
	(LDPR or not) can be a member of more than one LDPC.
	</h2></section>
	
	<section id="ldp-webarch-uri-reuse"><h2 class="normal"><a title="LDP server">LDP servers</a> should not re-use URIs, 
		regardless of the mechanism by which members are created (<code>POST</code>, <code>PUT</code>, etc.).
		Certain specific cases exist where a LDPC server might delete a resource and then later re-use the
		URI when it identifies the same resource, but only when consistent with Web architecture.
		While it is difficult to provide absolute implementation guarantees of non-reuse in all failure
		scenarios, re-using URIs creates ambiguities for clients that are best avoided.
	</h2></section>

</section> 

<section id="specs-http" class="informative">
<h2>HTTP 1.1</h2>
Reference: [[!RFC7230]], [[!RFC7231]], [[!RFC7232]]

	<section id="ldp-http-other-representations"><h2 class="normal"><a title="LDP server">LDP servers</a> can support representations beyond those
		necessary to conform to this specification. These
		could be other RDF formats, like N3 or NTriples, but non-RDF formats
		like HTML [[HTML401]] and JSON [[RFC4627]] would likely be common.  
		HTTP content negotiation ([[RFC7231]] Section 3.4 - Content Negotiation) is used to select the format.
	</h2></section>
	
	<section id="ldp-http-other-methods"><h2 class="normal">LDPRs can be created, updated and deleted using methods not defined in
		this document, for example through application-specific means, SPARQL
		UPDATE, etc. [[SPARQL-UPDATE]], as long as those methods do not conflict with this specification's 
		normative requirements.
	</h2></section>	
	
	<section id="ldp-http-delete-uri-reuse"><h2 class="normal"><a title="LDP server">LDP servers</a> 
		remove the resource identified by the <code>Request-URI</code> in response to a successful HTTP <code>DELETE</code> request.
		After such a request, a subsequent HTTP <code>GET</code> on the same
		<code>Request-URI</code> usually results in a 404 (Not found) or 410 (Gone) status
		code, although HTTP allows others.
	</h2></section>	
	
	<section id="ldp-http-method-side-effects"><h2 class="normal"><a title="LDP server">LDP servers</a> can alter the state of other resources 
		as a result of any HTTP request, especially when non-safe methods are used ([[RFC7231]] section 4.2.1). 
		For example, it is acceptable for the server to
		remove triples from other resources whose subject or object is the
		deleted resource as the result of a successful HTTP <code>DELETE</code> request. 
		It is also acceptable and common for <a title="LDP server">LDP servers</a> to
		not do this – the server's behavior can vary, so LDP clients cannot depend on it.
	</h2></section>
	
	<section id="ldp-http-patch-allowed"><h2 class="normal"><a title="LDP server">LDP servers</a> can implement HTTP <code>PATCH</code> 
		to allow modifications,
		especially partial replacement, of their resources. No
		minimal set of patch document formats is mandated by this document or by the definition of <code>PATCH</code> [[RFC5789]].
	</h2></section>
	
	<section id="ldp-http-content-sniffing"><h2 class="normal"> 
		When the <code>Content-Type</code> request header is absent from a request, 
		<a title="LDP server">LDP servers</a> might infer the content type by inspecting the entity body contents ([[RFC7231]] section 3.1.1.5).
	</h2></section>

</section> 

<section id="specs-rdf" class="informative">
<h2>RDF</h2>
Reference: [[rdf11-concepts]]

	<section id="ldp-rdfconcepts-extra-triples-any"><h2 class="normal">The state of a LDPR 
		can have triples with any subject(s).  The URL used to retrieve the
		representation of a LDPR need not be the subject of any of its triples.
	</h2></section>
	
	<section id="ldp-rdfconcepts-extra-triples-members"><h2 class="normal">The representation of a LDPC
		can include an arbitrary number of
		additional triples whose subjects are the members of the container,
		or that are from the representations of the members (if they have RDF
		representations). This allows an <a>LDP server</a> to provide clients with
		information about the members without the client having to do a <code>GET</code>
		on each member individually.
	</h2></section>
	
	<section id="ldp-rdfconcepts-extra-triples-types"><h2 class="normal">The state of a LDPR can have more than one
		triple with an <code>rdf:type</code> predicate.
	</h2></section>

</section> 

</section> <!-- Base specs -->

<section>
<h1>HTTP Header Definitions</h1>
     
<section id="header-accept-post">
<h2>The Accept-Post Response Header</h2>

	<div class="atrisk"><p class="atrisktext">Feature At Risk</p>
		<p>The LDP Working Group proposes incorporation of the features described in this section.</p>
		<ul>
		<li>The addition of <code>Accept-Post</code> in this specification is pending 
		advancement of an <a href="https://datatracker.ietf.org/doc/draft-wilde-accept-post/">IETF draft</a> [[Accept-Post]]
		that would fully include it, based on the Accept-Patch header's design from [[!RFC5789]].  Once LDP is in
		Candidate Recommendation status, the LDP WG will make an assessment based on the status at IETF
		working with the W3C Director.</li>
		</ul>
	</div>
		
	<p>This specification introduces a new HTTP response header <code>Accept-Post</code> used
		to specify the document formats accepted by the server on HTTP <code>POST</code> requests.
		It is modelled after the <code>Accept-Patch</code> header defined in [[!RFC5789]].
	</p>
   
	<section id="header-accept-post-1"><h2 class="normal">The syntax for <code>Accept-Post</code>, using
		the ABNF syntax defined in Section 1.2 of [[!RFC7231]], is:</h2>
		<blockquote><code>Accept-Post = "Accept-Post" ":" # media-range </code>
		<p>
		The <code>Accept-Post</code> header specifies a comma-separated list of media 
		ranges (with optional parameters) as defined by [[!RFC7231]], Section 5.3.2.  
		The <code>Accept-Post</code> header, in effect, uses the same syntax as the 
		HTTP <code>Accept</code> header minus the optional <code>accept-params</code> BNF production,
		since the latter does not apply to <code>Accept-Post</code>.
		</p>
		</blockquote>
	</section><!-- Was 6.1.1 / #header-accept-post-1 -->

	<section id="header-accept-post-2"><h2 class="normal">
		The <code>Accept-Post</code> HTTP header SHOULD appear in the <code>OPTIONS</code> response for any resource
		that supports the use of the <code>POST</code> method.  The presence of the
		<code>Accept-Post</code> header in response to any method is an implicit
		indication that <code>POST</code> is allowed on the resource identified by the
		<code>Request-URI</code>.  The presence of a specific document format in
		this header indicates that that specific format is allowed on <code>POST</code> requests to the
		resource identified by the <code>Request-URI</code>.
	</h2></section><!-- Was 6.1.2 / #header-accept-post-2 -->
	
	<section id="header-accept-post-iana"><h2 class="normal">IANA Registration Template</h2>
	<div>
	<blockquote>
	<p>
	The Accept-Post response header must be added to the permanent registry (see [[!RFC3864]]).
	</p>
	<p>
	Header field name:  Accept-Post
	</p>
	<p>
	Applicable Protocol:  HTTP
	</p>
	<p>
	Author/Change controller:  W3C
	</p>
	<p>
	Specification document:  this specification
	</p>
	</blockquote>
	</div>
	</section><!-- Was 6.1.3 / #header-accept-post-iana -->

</section>
     
<section id="prefer-parameters">
<h2>Preferences on the Prefer Request Header</h2>

<section id="prefer-summary">
<h3>Summary</h3>
	
	<p>This specification introduces new parameters on the HTTP <code>Prefer</code> request header's
	<code>return=representation</code> preference [[!RFC7240]], used optionally by clients to 
	supply a hint to help the server form a response that is most appropriate to 
	the client's needs.  The LDP-defined parameters suggest the portion(s) of a resource's state that the 
	client application is interested in and, if received, is likely to be 
	processed.  LDP Containers with large numbers of associated documents 
	and/or members will have large representations, and many client 
	applications may be interested in processing only a subset of the LDPC's 
	information (for example, only membership triples or only containment triples), 
	resulting in a potentially large savings in server, client, 
	and network processing.  
	</p>
	
	<p>
	Non-normative note: LDP server implementers should carefully consider the effects of these
	preferences on caching, as described in section 2 of [[!RFC7240]].
	</p>

	<p>
	Non-normative note: [[!RFC7240]] recommends that server implementers include a 
	<code>Preference-Applied</code> response header when the client cannot otherwise determine the server's
	behavior with respect to honoring hints from the response content.
	<a href="#prefer-examples">Examples</a> illustrate some cases where the header is unnecessary.
	</p>

</section> <!-- Prefer summary -->

<section id="prefer-rules">
<h3>Specification</h3>

	<section id="prefer-include"><h2 class="normal">
		The <code>include</code> hint defines a subset of a LDPR's content that a client
		would like included in a representation.
		The syntax for the <code>include</code> parameter of the 
		HTTP <code>Prefer</code> request header's
		<code>return=representation</code> preference [[!RFC7240]] is:</h2>
		<blockquote>
		<code>include-parameter = "include" *WSP "=" *WSP ldp-uri-list</code>
		<p>
		Where <code>WSP</code> is whitespace [[!RFC5234]], and
		<code>ldp-uri-list</code> is a double-quoted blank-delimited unordered set of URIs whose ABNF is given below.
		The generic preference BNF [[!RFC7240]] allows either a quoted string or a token as the value of a 
		preference parameter; LDP assigns a meaning to the value only when it is a quoted string of
		the form:
		</p>
		<code>ldp-uri-list = DQUOTE *WSP URI *[ 1*WSP URI ] *WSP DQUOTE</code>
		<p>
		where <code>DQUOTE</code> is a double quote [[!RFC5234]], and <code>URI</code> is an absolute URI with an optional
		fragment component [[!RFC3986]].
		</p>
		</blockquote>
	</section>

	<section id="prefer-omit"><h2 class="normal">
		The <code>omit</code> hint defines a subset of a LDPR's content that a client
		would like omitted from a representation.
		The syntax for the <code>omit</code> parameter of the 
		HTTP <code>Prefer</code> request header's
		<code>return=representation</code> preference [[!RFC7240]] is:</h2>
		<blockquote>
		<code>omit-parameter = "omit" *WSP "=" *WSP ldp-uri-list</code>
		<p>
		Where <code>WSP</code> and <code>ldp-uri-list</code> are defined as above for <a href="#prefer-include">include</a>.
		</p>
		</blockquote>
	</section>

	<section id="prefer-conflicts"><h2 class="normal">
		When LDP servers receive a request with conflicting hints, this specification imposes
		no requirements on their behavior.  They are free to reject the request, process it
		applying some subset of the hints, or anything else appropriate to the server.
		[[!RFC7240]] suggests treating similar requests as though none of the conflicting
		preferences were specified.
		</h2>
	</section>

	<section id="prefer-uris"><h2 class="normal">
		This specification defines the following URIs for clients to use with <code>include</code>
		and <code>omit</code> parameters.  It assigns no meaning to other URIs, although
		other specifications MAY do so.</h2>
		<table class="indented">
		<tr>
		<td> <a title="Containment triples">Containment triples </a></td>
		<td> <code>http://www.w3.org/ns/ldp#PreferContainment</code> </td>
		</tr>
		<tr>
		<td> <a title="Membership triples">Membership triples </a></td>
		<td> <code>http://www.w3.org/ns/ldp#PreferMembership</code> </td>
		</tr>
		<tr>
		<td rowspan="3"> <a title="Minimal-container triples">Minimal-container triples</a>
		</td>
		<td> <code>http://www.w3.org/ns/ldp#PreferMinimalContainer</code> </td>
		</tr>
		<tr>
		<td>&nbsp;&nbsp;&nbsp;&nbsp; or the equivalent but deprecated term </td>
		</tr>
		<tr>
		<td> 
		<code>http://www.w3.org/ns/ldp#PreferEmptyContainer</code> </td>
		</tr>
		</table>
		<blockquote>
		<p>
		Non-normative note: all currently defined URIs are only coherent for LDP-RSs, 
		and in fact only for LDPCs, however in
		the future it is possible that additional URIs with other scopes of applicability
		could be defined.
		</p>
		</blockquote>
	</section>

</section> <!-- Prefer specification -->
<section id="prefer-examples" class="informative">
<h3>Examples</h3>
	<p>
	If we assume a container like
	the one below:
	</p>
<pre class="example" id="prefer-examples-direct"># The following is the representation of
#   http://example.org/netWorth/nw1/assets/
<!-- @base is here only so it's easier to paste into validators for checking -->
# @base &lt;http://example.org/netWorth/nw1/assets/&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology#&gt;.

&lt;&gt;
   a ldp:DirectContainer;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipResource &lt;http://example.org/netWorth/nw1/&gt;;
   ldp:hasMemberRelation o:asset;
   ldp:insertedContentRelation ldp:MemberSubject.

&lt;http://example.org/netWorth/nw1/&gt;
   a o:NetWorth;
   o:asset &lt;a1&gt;, &lt;a3&gt;, &lt;a2&gt;.

&lt;a1&gt;
   a o:Stock;
   o:marketValue 100.00 .
&lt;a2&gt;
   a o:Cash;
   o:marketValue 50.00 .
&lt;a3&gt;
   a o:RealEstateHolding;
   o:marketValue 300000 .</pre>

	<p id="prefer-examples-direct-minimal-container-only1">
	Clients interested only in information about the container 
	(for example, which membership predicate it uses) might use this hint on a <code>GET</code> request:
	<code>Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer"</code>
	</p>
	<p>
	A server that honors this hint would return a following response containing the HTTP header 
	<code>Preference-Applied: return=representation</code> 
	and this representation:
	</p>
	
<em>Request</em> to <code>http://example.org/netWorth/nw1/assets/</code>:
<pre class="example">GET /netWorth/nw1/assets/ HTTP/1.1
Host: example.org
Accept: text/turtle
Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMinimalContainer"
</pre>
<em>Response:</em>
<pre class="example">HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: "_87e52ce291112"
Link: &lt;http://www.w3.org/ns/ldp#DirectContainer&gt;; rel="type",
      &lt;http://www.w3.org/ns/ldp#Resource&gt;; rel="type"
Accept-Post: text/turtle, application/ld+json
Allow: POST,GET,OPTIONS,HEAD
Preference-Applied: return=representation
Transfer-Encoding: chunked
<!-- @base &lt;http://example.org/netWorth/nw1/assets/&gt;. -->
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology#&gt;.

&lt;http://example.org/netWorth/nw1/assets/&gt;
   a ldp:DirectContainer;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipResource &lt;http://example.org/netWorth/nw1/&gt;;
   ldp:hasMemberRelation o:asset;
   ldp:insertedContentRelation ldp:MemberSubject.</pre>

	<p id="prefer-examples-direct-minimal-container-only2">
	Clients interested only in information about the container 
	(same as before) might use this hint instead:
	<code>Prefer: return=representation; omit="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferContainment"</code>.  Note: <strong>Treating the two as equivalent is not recommended.</strong> While today this 
	<code>omit</code> parameter value is equivalent to the preceding <code>include</code> parameter value, 
	they may not be equivalent in the future 
	due to the definition of <a title="Minimal-container triples">minimal-container triples</a>.
	Clients should preferentially use the <code>include</code> parameter, as it more precisely communicates their needs.
	</p>
	<p>
	A <strong>LDP 1.0</strong> server that honors this hint would return the following response.  Servers
	implementing later versions of LDP might return substantively different responses.
	</p>
	
<em>Request</em> to <code>http://example.org/netWorth/nw1/assets/</code>:
<pre class="example">GET /netWorth/nw1/assets/ HTTP/1.1
Host: example.org
Accept: text/turtle
Prefer: return=representation; omit="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferContainment"
</pre>
<em>Response:</em>
<pre class="example">HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: "_87e52ce291112"
Link: &lt;http://www.w3.org/ns/ldp#DirectContainer&gt;; rel="type",
      &lt;http://www.w3.org/ns/ldp#Resource&gt;; rel="type"
Accept-Post: text/turtle, application/ld+json
Allow: POST,GET,OPTIONS,HEAD
Preference-Applied: return=representation 
Transfer-Encoding: chunked
<!-- @base &lt;http://example.org/netWorth/nw1/assets/&gt;. -->
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology#&gt;.

&lt;http://example.org/netWorth/nw1/assets/&gt;
   a ldp:DirectContainer;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipResource &lt;http://example.org/netWorth/nw1/&gt;;
   ldp:hasMemberRelation o:asset;
   ldp:insertedContentRelation ldp:MemberSubject.</pre>

	<p id="prefer-examples-direct-membershiponly">
	Clients interested only in information about the container 
	(for example, which membership predicate it uses) and its membership might use this hint on a <code>GET</code> request:
	<code>Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferMinimalContainer"</code>.
	</p>
	<p>
	A server that honors this hint would return 
	(at least) the following response, and perhaps only this (it might
	well omit containment triples if they are not specifically requested).  
	In cases like this example, where a client can detect from the content that its hints were honored
	(the presence of the predicates <code>dcterms:title</code> and <code>o:asset</code> demonstrate this in the representation below), 
	there is no need for the server to include a <code>Preference-Applied</code> response header 
	in many common cases like a <code>200 (OK)</code> response.  In other cases, like status code <code>303</code>,
	the header would still be required for the client to know that the <code>303</code> response entity
	is a representation of the resource identified by the <code>Location</code> URI 
	instead of a short hypertext note (one with a hyperlink to
	the same URI reference provided in the <code>Location</code> header field [[RFC7231]]).
	</p>
	
<em>Request</em> to <code>http://example.org/netWorth/nw1/assets/</code>:
<pre class="example">GET /netWorth/nw1/assets/ HTTP/1.1
Host: example.org
Accept: text/turtle
Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferMembership http://www.w3.org/ns/ldp#PreferMinimalContainer"
</pre>
<em>Response:</em>
<pre class="example">HTTP/1.1 200 OK
Content-Type: text/turtle
ETag: "_87e52ce291112"
Link: &lt;http://www.w3.org/ns/ldp#DirectContainer&gt;; rel="type",
      &lt;http://www.w3.org/ns/ldp#Resource&gt;; rel="type"
Accept-Post: text/turtle, application/ld+json
Allow: POST,GET,OPTIONS,HEAD
Preference-Applied: return=representation
Transfer-Encoding: chunked
<!-- @base &lt;http://example.org/netWorth/nw1/assets/&gt;. -->
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology#&gt;.

&lt;http://example.org/netWorth/nw1/assets/&gt;
   a ldp:DirectContainer;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipResource &lt;http://example.org/netWorth/nw1/&gt;;
   ldp:hasMemberRelation o:asset;
   ldp:insertedContentRelation ldp:MemberSubject.

&lt;http://example.org/netWorth/nw1/&gt;
   a o:NetWorth;
   o:asset &lt;a1&gt;, &lt;a3&gt;, &lt;a2&gt;.</pre>

	</section> <!-- Prefer examples -->

</section> <!-- Prefer defns -->
</section> <!-- Header defns -->
    
<!-- Removed for action-113
<section>
<h1>HTTP Status Code Definitions</h1>
     
<section id="status-code-related-content">
<h2>209 Related Content</h2>

	<div class="atrisk"><p class="atrisktext">Feature At Risk</p>
		<p>The LDP Working Group proposes incorporation of the features described in this section.</p>
		<ul>
		<li>The addition of <a>209 Related Content</a> in this specification is pending 
		advancement of an <a href="https://datatracker.ietf.org/doc/draft-wilde-related-content/">IETF draft</a>
		that would fully include it, patterned after the codes defined by [[RFC6585]].  Once LDP is in
		Candidate Recommendation status, the LDP WG will make an assessment based on the status at IETF
		working with the W3C Director.</li>
		</ul>
	</div>
		
	<p>The <code>209 Related Content</code> status code indicates that the origin server 
		is supplying the representation of a different resource than the target resource,
		and the origin server believes that the supplied representation 
		is likely to satisfy the user agent's original request.
		The resource whose representation is supplied is descriptive of the target resource, in
		the same way that the <code>Location</code> header in a <code>303 See Other</code>
		response is descriptive of the target resource.
	</p>
	<p><code>209 Related Content</code> is intended to be used in situations where 
		<code>303 See Other</code> could have been used and would most likely result in a
		user agent retrieving the other resource, but saves the user agent from
		the latency penalty of having to perform a separate retrieval request.
	</p>
   
	<p>	LDP uses <code>209 Related Content</code> to provide clients with the 
		<a href="#ldpr-Paging">first page of a large resource</a>, but it can also be used in
		other common situations.  Linked Data clients could benefit by avoiding the latency
		of additional requests when the target resource is a concept resource (one without any
		representation capable of transmission over HTTP), and general HTTP clients would
		benefit in many of the more general cases where <code>303 See Other</code> responses
		are currently used.
	</p>
   
	<div id="status-code-related-content-1" class="rule">7.1.1 A <code>209</code> response to a
		<code>GET</code> request MUST contain a <code>Location</code> header with the same
		<code>Location</code> field value as a <code>303 See Other</code> response would use [[!HTTP11]].
	</div>

	<div id="status-code-related-content-2" class="rule">7.1.2 A <code>209</code> response to a
		<code>GET</code> request MUST contain a representation of the resource identified
		by the response's <code>Location</code> header.
	</div>

	<div id="status-code-related-content-iana" class="rule">7.1.3 IANA Considerations</div>
	<div>
	<blockquote>
	<p>
	The <code>209 Related Content</code> must be added to the permanent status code registry 
	maintained at <a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>
	(see [[RFC7231]], [[!RFC2817]]).
	</p>
	<p>
	Value:  209
	</p>
	<p>
	Description:  Related Content
	</p>
	<p>
	Reference:  this specification
	</p>
	</blockquote>
	</div>

</section>
</section> -->

<section id='link-relations'>
<h1>Link Relations</h1>
<p>
	The intent is that these link relations will be registered with IANA per [[RFC5988]] section 6.2.1.
</p>
<section id='link-relation-describedby'>
<h2>describedby</h2>
<p>
	The contents of this section were originally taken from [[POWDER]] appendix D, and then modified to comply with the current registration template.
	The pre-LDP IANA link relation registry entry for 
	<code>describedby</code> refers to a different section of [[POWDER]] that was substantively updated in 
	<a href="http://www.w3.org/2007/powder/powder-errata#describedby">an erratum</a>, and that section was not
	actually the normative definition of the link relation.  Since we expect no update to [[POWDER]] that incorporates the erratum 
	or fixes the registry link, this superseding registration approach is being taken.
</p>
<p>The following Link Relationship will be submitted to IANA for review, approval, and inclusion in the IANA Link Relations registry.</p>
<dl>
<dt>Relation Name:</dt>
<dd><code>describedby</code></dd>
<dt>Description:</dt>
<dd>
The relationship <code>A describedby B</code> asserts that resource B provides a description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource. 
</dd>
<dt>Reference:</dt>
<dd>
	The W3C <a href="http://www.w3.org/TR/ldp/">Linked Data Platform specification</a>.
</dd>
<dt>Notes:</dt>
<dd>
    Descriptions of resources may be socially sensitive, may require processing to be understood and may or may not not be accurate. Consumers of descriptive resources should be aware of the source and chain of custody of the data. Security considerations for URIs (Section 7 of RFC 3986) and IRIs (Section 8 of RFC 3987) apply to the extent that describing resources may affect consumers' decisions about how or whether to retrieve those resources.
</dd>
</dl>
</section>
</section>

<section class='informative' id='security'>
<h1>Security Considerations</h1>
<p>As with any protocol that is implemented leveraging HTTP, implementations should take advantage of the many 
security-related facilities associated with it and are not required to carry out LDP operations 
that may be in contradistinction to a particular security policy in place. For example, when faced with an 
unauthenticated request to replace system critical RDF statements in a graph through the PUT method, applications may
consider responding with the 401 status code (Unauthorized), indicating that the appropriate authorization 
is required. In cases where authentication is provided fails to meet the requirements of a particular access control 
policy, the 403 status code (Forbidden) can be sent back to the client to indicate this failure to meet the
access control policy.</p>
</section>

<section class='appendix informative'>
<h2>Acknowledgements</h2>
     
  <p>The following people have been instrumental in providing thoughts, feedback,
reviews, content, criticism and input in the creation of this specification:</p>

  <p style="margin-left: 3em;">
  Alexandre Bertails, Andrei Sambra, Andy Seaborne, Antonis Loizou,  Arnaud Le Hors, Ashok Malhotra, 
  Bart van Leeuwen, Cody Burleson, David Wood, Eric Prud'hommeaux, Erik Wilde, Henry Story, John Arwe, 
  Kevin Page, Kingsley Idehen, Mark Baker, Martin P. Nally, Miel Vander Sande, Miguel Esteban Gutiérrez, 
  Nandana Mihindukulasooriya, Olivier Berger, Pierre-Antoine Champin, Raúl García Castro, Reza B'Far, 
  Richard Cyganiak, Rob Sanderson, Roger Menday, Ruben Verborgh, Sandro Hawke, Serena Villata, Sergio Fernandez, 
  Steve Battle, Steve Speicher, Ted Thibodeau, Tim Berners-Lee, Yves Lafon
  </p>

</section>

<section class='appendix informative' id="history">
<h1>Change History</h1>
<p>The change history is up to the editors to insert a brief summary of
changes, ordered by most recent changes first and with heading from which
public draft it has been changed from.
</p>

<!-- 
<h2>Summary</h2>
<p>Summary of notable changes from the <a href="http://www.w3.org/TR/2014/CR-ldp-20140619/">previous public working draft</a>.</p>
<ul>
	<li>Indirect containers are AT RISK for removal</li>
	<li>Turtle is no longer required for an LDP-RS when the Accept header is absent</li>
	<li>JSON-LD is required for an LDP-RS and LDPC create via POST, AT RISK</li>
	<li>Changed the link relation used to articulate request constraints that a client has likely violated</li>
</ul> 
 -->


<h2>Detailed history</h2>
<!-- <blockquote><em><a href="http://www.w3.org/TR/2014/CR-ldp-20140619/">Candidate Recommendation Draft</a></em></blockquote> -->

<ul>
	<li>2014-10-20 - Removed at-risk feature that clients should be prepared to handle server-initiated paging (SS)</li>
	<li>2014-10-20 - Define LDP-server-managed for Robert Sanderson thread (JA)</li>
	<li>2014-10-20 - Update LDPC-Post adding non-normative note for Miguel thread (JA)</li>
	<li>2014-10-20 - Update LDPC-Post bullet 1 with non-normative text for James Leigh thread (JA)</li>
	<li>2014-09-25 - Included non-norm content to container intro to add clarity on application-specific extensions (SS)</li>
</ul>
<blockquote><em><a href="http://www.w3.org/TR/2014/WD-ldp-20140916">Last Call Working Draft 3</a></em></blockquote>
<ul>
	<li>2014-09-12 - Fix example 14 relative URIs per Rob Sanderson's email ... add advisors/ to contained documents (JA) </li>
	<li>2014-09-10 - Fix examples per Rob Sanderson's email ... /nw1 &gt; /nw1/ (JA) </li>
	<li>2014-09-10 - Wafer thin change to Turtle-required words, lest the chair fetchez la vache (JA) </li>
	<li>2014-09-09 - Re-factor Turtle/JSON-LD required words for readability and completeness (JA) </li>
	<li>2014-09-08 - Add link to Best Practices now that it has been published (JA) </li>
	<li>2014-09-08 - Indirect containers (at risk) (JA) </li>
	<li>2014-09-08 - Should return Turtle if Accept is absent, JSON-LD required (at risk), clarify creates  (JA) </li>
	<li>2014-09-08 - Changed the constraints link relation to ldp#constrainedBy, per today's mtg resolution  (JA) </li>
	<li>2014-09-08 - Clarify that Turtle/JSON-LD on LDPC POST are required only when the semantic is "create new member" (JA) </li>
	<li>2014-09-08 - Constraints 4xx responses remind them to choose context URI consciously (JA) </li>
	<li>2014-09-08 - LDP-NR creation clarify context URI needed is not the default, per today's mtg resolution (JA) </li>
	<li>2014-08-04 - Fuss with o:value in examples for Sandro to remain consistent with Paging spec (JA) </li>
	<li>2014-07-20 - Added test coverage utility to annotate spec with test cases covering them, to be removed before publishing (SS)</li>
</ul>

<blockquote><em><a href="http://www.w3.org/TR/2014/CR-ldp-20140619">Candidate Recommendation Draft</a></em></blockquote>
<ul>
	<li>2014-07-28 - Clarified syntax used by clients to request specific interaction model (JA) </li>
	<li>2014-06-16 - Updated examples in Prefer section to be in request/response format (SS) </li>
	<li>2014-06-16 - Updated examples in container sections to be in request/response format (SS) </li>
	<li>2014-06-10 - Use http-bis and Prefer RFC numbers, adjust BNF to match bis changes (JA) </li>
	<li>2014-06-05 - Fixed LC1 date in change history pseudo-heading, was 2014 (JA) </li>
	<li>2014-05-19 - Revert membership definition to be about LDPCs, not LDP-RS's (JA) </li>
	<li>2014-05-09 - Respond to Joe Ross's LC2 comments (JA) </li>
	<li>2014-04-28 - Added usage for ldp:NonLDPSource (SS) </li>
	<li>2014-04-28 - Clarify MUST etags on responses with representations and HEAD (SS) </li>
	<li>2014-04-17 - Add should for json-ld per today's WG resolution (JA) </li>
	<li>2014-04-16 - Update narrative on net worth example (#s 2-5, section 5.1, at time of writing) (JA) </li>
	<li>2014-04-16 - Clarify language of 5.2.5.1/2 (JA) </li>
	<li>2014-04-16 - Clarify definitions of membership and containment triples (JA) </li>
	<li>2014-04-15 - Rename empty-container triples to minimal-container triples (JA) </li>
	<li>2014-04-15 - Add describedby chapter (JA) </li>
	<li>2014-04-15 - Removal of named graph references (JA) </li>
	<li>2014-04-15 - Fixed typos (JA) </li>
	<li>2014-04-15 - Fixed LC-2840 clarity on "burden of constraint" (SS) </li>
	<li>2014-03-30 - Updated references to RFC5988 to first time Link header is used (SS) </li>
	<li>2014-03-29 - Fixed error in Example 8 (SS) </li>
	<li>2014-03-28 - Fixed copy-paste error in 5.4.1.1 (SS) </li>
	<li>2014-03-28 - Set publication status and history for post 2nd LC edits (SS) </li>
</ul>

<blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20140311/">Last Call Draft (2014-03-11)</a></em></blockquote>
<ul>
	<li>2014-03-03 - Must use LDPC subtypes for rel='type', per 20140303 resln (SS) </li>
	<li>2014-03-03 - Removed LDP-BC clauses that introduce membership (SS) </li>
	<li>2014-03-03 - Tweaked LDPR PUT clauses to better match new defn of LDPR (SS) </li>
	<li>2014-03-03 - Folded #ldpclients section into #ldprs (SS) </li>
	<li>2014-03-01 - Split out different kinds of LDPRs into their own subsection (SS)</li>
	<li>2014-02-28 - Combined rules for container triples (SS) </li>
	<li>2014-02-28 - Split out different kinds of LDPCs into their own subsection (SS)</li>
	<li>2014-02-24 - Corrected rel=meta to be rel=describedby (SS) </li>
	<li>2014-02-24 - Adjusted term membership triples and membership predicate (SS) </li>
	<li>2014-02-24 - Removed 6.3.1 LDPC GET requirement and put in general clause (SS) </li>
	<li>2014-02-20 - Changed LDPC SHOULD NOT put (6.5.1) to be about containment (SS) </li>
	<li>2014-02-20 - Removed rule on PATCH create, as it doesn't add any substantive over RFC5789 (SS) </li>
	<li>2014-02-18 - Factored out paging and sorting into separate spec LDP-Paging (SS) </li>
	<li>2014-02-18 - Reference cleanup and tweak LDP-RS term (SS) </li>
	<li>2014-02-17 - Reference to RDF Document into terms (SS) </li>
	<li>2014-02-17 - Adopted container hierarchy and merged Indirect Container into Container (SS) </li>
	<li>2014-02-17 - Adopted new resource types: LDP RDF Source (LDP-RS) (was LDP RDF Resource) and LDP Non-RDF Source (LDP-NR) (was LDP Binary Resource) (SS)</li>
	<li>2014-02-17 - Adopted new predicate names: ldp:membershipResource, ldp:hasMemberRelation and ldp:isMemberOfRelation (SS) </li>
	<li>2014-02-12 - Updated LDPR Post reference to Put, which had implied that clients could PUT (to an LDPC) to create an LDPR (JA)</li>
	<li>2014-02-12 - Updated containerResource on examples 6 and 7, section 6.1, in resp to public-ldp email (JA)</li>
	<li>2014-02-12 - Updated LDP-IC definition per email thread (JA)</li>
	<li>2014-02-11 - Updated LDPC create ldp:contains (errant MAY to MUST, resolving conflicting statements) (JA)</li>
	<li>2014-02-10 - Removed LDPR Paging HTTP OPTIONS section (no longer needed) and more cleanup of todos (SS)</li>
	<li>2014-02-10 - Updated LDPC DELETE language and cleanup todos (SS)</li>
	<li>2014-02-10 - Resolved a few editoral TODO's (JA)</li>
	<li>2014-02-08 - Put final stake in heart of 'informative' (waves to Sandro), update boilerplate for readability per Arnaud (JA)</li>
	<li>2014-02-08 - ACTION-132: Use Prefer in place of non-member properties resource (JA)</li>
	<li>2014-02-08 - Add Prefer header examples, define new URIs from -126 in ttl, tweak acks per Arnaud email (JA)</li>
	<li>2014-02-07 - ACTION-126: Add Prefer header (JA)</li>
	<li>2014-02-07 - LDP-BCs use ldp:contains not ldp:member (JA)</li>
	<li>2014-02-07 - Simplified some of the container examples (SS)</li>
	<li>2014-02-06 - partial first pass at arnaud's email comments (JA)</li>
	<li>2014-02-06 - fixing containment def, adding containment triples to terminology (JA)</li>
	<li>2014-02-06 - fixing POST to create containment/membership triples, which was mangled (JA)</li>
	<li>2014-02-06 - fully aligning SS changes with http://www.w3.org/2012/ldp/wiki/Containers for basic containers, allowing them to omit the standard predicates in representations despite requiring behavior consistent with the presence of those triples (JA)</li>
	<li>2014-02-06 - editorial fixes (JA)</li>
	<li>2014-02-06 - ACTION-127 (complete) use the TAG's new [23]xx code; if that code is not sufficiently through IETF process by CR, we will use a 303 (JA)</li>
	<li>2014-02-05 - ACTION-133 Get rid of ldp:created which is subsumed by ldp:contains (SS)</li>
	<li>2014-02-04 - ACTION-124 LDPR-RR as named graphs  (SS)</li>
	<li>2014-02-04 - ACTION-120 (complete) Updated LDPC general, GET and POST sections (SS)</li>
	<li>2014-02-04 - ACTION-120 (Part 3) Added ldp:member (SS)</li>
	<li>2014-02-04 - ACTION-120 (Part 2) Added concepts of containers (basic, direct and indirect) to LDPC intro (SS)</li>
	<li>2014-01-30 - ACTION-120 (Part 1) Added concepts of containers (basic, direct and indirect) (SS)</li>
	<li>2014-01-30 - ACTION-123 Added concepts of LDP-RDF-Resource and LDP-Binary-Resource (SS)</li>
	<li>2014-01-29 - Fix up conformance section to use new LDP client section (SS)</li>
	<li>2014-01-21 - Updated reference to LDP BP&amp;G editor's draft and added ref to LDP-UCR (SS)</li>
	<li>2014-01-21 - Removed redudant reqs that have been moved to #ldpclient (SS)</li>
	<li>2014-01-21 - Fixed formating with &gt;h2 formatting (SS)</li>
	<li>2014-01-21 - Put reference to <a href="#base-specs">base-specs</a> into intro section (SS)</li>
	<li>2014-01-17 - First attempt at correcting section ordering and anchors (SS)</li>
	<li>2014-01-02 - ACTION-122 Updated 4.2.10, 5.4.4, example 8 + added 5.2.11 requiring rel=type for interaction model (JA)</li>
	<li>2014-01-02 - ACTION-119 Added 5.4.15 requiring ldp:created for indirect containers (JA)</li>
	<li>2013-11-27 - ACTION-101 Added informative security section (SS)</li>
	<li>2013-11-27 - ACTION-100 Added informative note to Ordering section that containers can be nested (SS)</li>
	<li>2013-11-18 - Various editorial and validation fixes (SS)</li>
    <li>2013-11-12 - Clean up some remnants of inlining (JA)</li>
    <li>2013-11-12 - Clean up some overly specific language (implications that POST is the only way to create members, etc) (JA)</li>
    <li>2013-11-12 - Resolve ACTION-112 Update spec to reflect 10/28 resolution for Issue-81 part 1: new predicate names (JA)</li>
    <li>2013-11-12 - Fix respec messages that only show up on remote server, hit paging examples to remove appearance of inlining (JA)</li>
    <li>2013-11-11 - Resolve ACTION-113 Update spec to reflect 11/04 resolution to remove 303 and have client use first/next links to detect paging (JA)</li>
    <li>2013-10-25 - Resolve ACTION-105 Update spec to reflect 9/30 resolution moving Paging links to HTTP headers (JA)</li>
    <li>2013-10-25 - Resolve ACTION-110 Update spec to reflect 10/21 resolution for normative changes to align vanilla/chocolate (JA)</li>
    <li>2013-10-22 - Resolve ACTION-109 Update spec to reflect 10/21 resolution for ignoring triples on PUT (JA)</li>
    <li>2013-10-22 - Resolve ACTION-107 Update spec to reflect 10/07 resolution on 5.6.2 LDPC deletion (JA)</li>
    <li>2013-10-22 - Resolve ACTION-102 Make 4.6.2 informative, clarify that it re-states what http allows, and in fact it applies to all methods not just delete. (JA)</li>
    <li>2013-10-22 - Resolve ACTION-103 Change SHOULD to MUST in 4.10.2.3 "LDPR servers that initiate paging SHOULD respond to request ..." (JA)</li>
    <li>2013-10-22 - Resolve ACTION-108 move restatements of HTTP et al. out of normative sections (JA)</li>
    <li>2013-10-22 - Resolve ACTION-106 5.3.5 MUST -&gt; SHOULD (JA)</li>
    <li>2013-10-21 - Mock up status code 209 Related Content (JA)</li>
    <li>2013-10-01 - Mock up new section for rules declared to be non-normative restatements of info from other specs (JA)</li>
    <li>2013-10-01 - Revising terminology - membership triples and friends (JA)</li>
    <li>2013-10-01 - Revising introduction (JA)</li>
    <li>2013-10-01 - Conformance section drafting + mock up "LDP Clients" section as part of that (JA)</li>
    <li>2013-09-23 - Remove client/server-initiated paging terms (JA)</li>
    <li>2013-09-17 - Change must to MUST in 5.6.4 (SS)</li>
	<li>2013-09-17 - Removed "at-risk" inlining feature from spec, <a href="https://www.w3.org/2012/ldp/track/actions/98">ACTION-98</a> (SS)</li>
	<li>2013-09-17 - Fixed vanishing section ref problem (SS)</li>
	<li>2013-08-19 - Basic preparation for edits unto LC draft (SS)</li>
</ul>

<blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130730/">Last Call Draft (2013-07-30)</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-&gt;4.10.2.4.3,4.10.2.6-&gt;4.10.2.4.1,4.10.2.7-&gt;4.10.2.4.2 and added samples (SS)</li>
	<li>2013-07-24 - Changed ldp:ascending-&gt;ldp:Ascending, ldp:descending-&gt;ldp:Descending, ldp:non-member-resource -&gt;ldp:nonMemberResource (SS)</li>
	<li>2013-07-24 - Added term &quot;Page resource&quot; (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-&gt;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:insertedContentRelation into examples (SS)</li>
	<li>2013-07-15 - ISSUE-79 ldp:contains =&gt; ldp:created  (JA)</li>
	<li>2013-07-11 - Improving working in #ldpr-Paging to remove container references (SS)</li>
	<li>2013-07-11 - Removed 4.1.5, section number fixup:4.1.8-13-&gt;6-11, 4.9.2.* fixup, 5.3.7-10-&gt;\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 an LDPR can show which LDPC is it in (SS)</li>
	<li>2013-07-10 - Removed closed issues that required no new spec changes: 18, 35, 20 (SS)</li>
	<li>2013-07-10 - ISSUE-44 move section 4.1.7 (relationships are simple RDF links) to guidance (SS)</li>
	<li>2013-07-10 - ISSUE-72 take 2 - added ldp:MemberSubject to handle default case (SS)</li>
	<li>2013-07-10 - ISSUE-72 adding 5.2.10 for ldp:insertedContentRelation (SS)</li>
	<li>2013-07-09 - ISSUE-58 inlining - actions 87-89 inclusive  (JA)</li>
	<li>2013-07-08 - Moved 5.7.* sections out of HEAD and into OPTIONS as 5.9.*, added 4.6.2 (SS)</li>
	<li>2013-07-08 - ISSUE-15 Inserted 5.4.12, 5.6.4, 5.7.2 to describe link-relation meta usage (SS)</li>
	<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 an LDPC and inserted 5.5.3 on rejecting member data on PUT to LDPC (SS)</li>
	<li>2013-05-17 - Tweaks to Terminology section for LDPR and LDPC (SS)</li>
	<li>2013-05-17 - ISSUE-9 Moved section 4.1.7 out of spec to the <a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Servers_should_serve_up_canonical_URLs">deployment guide</a> (SS)</li>
	<li>2013-05-15 - Updated wording for 5.2.2 from to be more clear (SS)</li>
	<li>2013-05-13 - ISSUE-49 Moved section 4.1.4 out of spec to the <a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Predicate_URIs_SHOULD_be_HTTP_URLs">deployment guide</a>. (SS)</li>
	<li>2013-05-08 - Removed closed issues 5, 7, 55 and 38 as the don't require edits. Added 64 and 65. (SS)</li>
	<li>2013-05-08 - ISSUE-59 5.3.2 limited rdf:type of ldp:Container, removed 5.6.3, reworded 5.6.2, updated 1. (SS)</li>
	<li>2013-04-15 - ISSUE-21 Added ldp:containedByRelation to 5.2.5 &amp; 5.5.2, created 5.2.5.1 &amp; 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&amp;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 &amp; 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 &amp; 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 &amp; 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 &amp; 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>

  <div class="removeOnSave showCoverage">
    <input type="checkbox" id="showCoverage"><label for="showCoverage">Show test coverage</label></input>
  </div>
    
  </body>
</html>