ldp.html
changeset 548 ab2a3418fb01
parent 547 d34ef0884d9e
child 549 084cb71ce842
--- a/ldp.html	Tue Apr 15 10:09:45 2014 -0400
+++ b/ldp.html	Tue Apr 15 13:28:48 2014 -0400
@@ -259,7 +259,7 @@
 	<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 have a collection of faculty members, each faculty member teaches a collection of courses, and so on. 
+	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>
@@ -314,7 +314,7 @@
 
 	<dt><dfn>Linked Data Platform Non-RDF Source</dfn> (<abbr title="Linked Data Platform Non-RDF Source">LDP-NR</abbr>)</dt>
 	<dd>An <a title="Linked Data Platform Resource">LDPR</a> whose state is <em>not</em> represented in RDF.
-	These are binary or text documents that do not have useful RDF representations.
+	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>
@@ -331,14 +331,14 @@
 	<p></p></dd>
 	
 	<dt><dfn>Linked Data Platform Direct Container</dfn> (<abbr title="Linked Data Platform Direct Container">LDP-DC</abbr>)</dt>
-	<dd>An <a title="Linked Data Platform Container">LDPC</a> adds the concept <a title="Membership">membership</a>, allows the flexibility of choosing what form its 
+	<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> that is similar to a <a title="Linked Data Platform Direct Container">LDP-DC</a>
-	and is capable of having <a title="Membership">members</a> whose URIs are based
+	<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>
 		 
@@ -484,7 +484,7 @@
 	into client consumable chunks called pages. A separate LDP specification outlines the conformance
 	rules around pagination [[LDP-PAGING]].
 	</p>
-	<p>An LDP server manages two kinds of <a title="Linked Data Platform Resources">LDPRs</a>, those resources who whose state 
+	<p>An 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
@@ -512,7 +512,7 @@
 	<section id="ldpr-gen-http"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].
 	</h2></section><!-- Was 4.2.1 / #ldpr-4_2_1 -->
 	
-	<section id="ldpr-gen-binary"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY host a mixture of LDPRs, <a title="Linked Data Platform RDF Source">LDP-RSs</a>
+	<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 -->
@@ -543,7 +543,7 @@
 		</p>
 		<p>
 		Note: 
-		<a href="#ldpr-gen-binary">An LDP server can host a mixture of LDPRs and other resources</a>, and therefore there is no implication
+		<a href="#ldpr-gen-binary">An 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.
@@ -680,10 +680,10 @@
 		Per [[HTTP11]], this HTTP method is optional and 
 		this specification does not require <a title="LDP server">LDP servers</a> to support it.
 		When an LDP server supports this method, 
-		this specification imposes the following new requirements for LDPRs.
+		this specification imposes no new blanket requirements for LDPRs.
 	</p>
 		
-	<p>Additional requirements on HTTP <code>DELETE</code> of LDPRs within containers can be found in
+	<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>
@@ -749,9 +749,9 @@
 <h2>General</h2>
 
 	<section id="ldprs-are-ldpr"><h2 class="normal">Each <a title="Linked Data Platform RDF Source">LDP RDF Source</a> MUST also be 
-		a conforming <a title="Linked Data Platform Resource">LDP Resource</a> in <a href="#ldpr-resource" class="sectionRef"></a> along the
-		following restrictions in this section. <a title="">LDP client</a>s MAY infer the following triple:
-		whose subject is <code>ldp:RDFSource</code>, 
+		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 <a title="Linked Data Platform RDF Source">LDP-RS</a>, 
 		whose predicate is <code>rdfs:subClassOf</code>, 
 		and whose object is <code>ldp:Resource</code>, 
 		but there is no requirement to materialize this triple in the LDP-RS representation.
@@ -763,7 +763,7 @@
 	</h2></section><!-- Was 4.2.5 / #ldpr-4_2_5 -->
 
 	<section id="ldprs-rdftype"><h2 class="normal">The representation of an LDP-RS MAY have an <code>rdf:type</code>
-		of only one of <code>ldp:RDFSource</code> for <a title="">Linked Data Platform RDF Source</a>.
+		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>. 
@@ -781,7 +781,7 @@
 	</h2></section><!-- Was 4.2.4.1 / #ldpr-4_2_4_1 -->
 
 	<section id="ldp-cli-multitype"><h2 class="normal">In the absence of special knowledge of the application or domain, 
-		<a title="LDP client">LDP clients</a> MUST assume that any LDP-RS can have multiple values for <code>rdf:type</code>.
+		<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, 
@@ -858,7 +858,7 @@
 
 	<section id="ldpnr-are-ldpr"><h2 class="normal">Each <a title="Linked Data Platform Non-RDF Source">LDP Non-RDF Source</a> MUST also be 
 		a conforming <a title="Linked Data Platform Resource">LDP Resource</a> in <a href="#ldpr-resource" class="sectionRef"></a>.  
-		<a title="Linked Data Platform Non-RDF Source">LDP Non-RDF Source</a> may not be able to fully express their
+		<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>
 
@@ -945,7 +945,7 @@
 	<code>ldp:contains</code> and objects indicating the URIs of the contained resources. 
 	A POST to this container will create a new resource
 	and add it to the list of contained resources by adding a new containment triple
-	to the container.  This type of container is also referred to as
+	to the container.  This type of container is also referred to as a
 	<a title="">Linked Data Platform Basic Container</a>.</p>
 
 	<p>Sometimes it is useful to use a subject
@@ -974,7 +974,7 @@
 	resource represents an instance of a person's net worth and <code>o:netWorthOf</code> predicate indicating 
 	the associated person.  There are two sets of same-subject, same-predicate pairings; one for assets and
 	one for liabilities.  It would be helpful to be able to associate these multi-valued sets using a URL
-	for them to assist with managing these, this is done by associating containers with them as 
+	for them to assist with managing these; this is done by associating containers with them as 
 	illustrated in the set of related examples (one example per HTTP resource) below:
 	</p>
 
@@ -1055,7 +1055,7 @@
 	</p>
 	
 	<p>Alternatively, servers may provide the net worth resource and supporting containers in a single response
-	representations.  When doing this, a preference would be for RDF formats that support multiple named graphs, one
+	representation.  When doing this, a preference would be for RDF formats that support multiple named graphs, one
 	named graph for the net worth resource and then two others for asset and liability containers.  This allows for
 	the membership triples to be represented with the named graph for the net worth resource, while the containment triples
 	would be represented within the liability and asset containers [[rdf11-concepts]].  Generally, the membership triples belong
@@ -1201,7 +1201,7 @@
 		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:
+		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 <code>ldp:Container</code>, 
 	whose predicate is <code>rdfs:subClassOf</code>, 
 	and whose object is <code>ldp:RDFSource</code>, 
@@ -1209,7 +1209,7 @@
 	</h2></section><!-- Was 5.2.1 / #ldpc-5_2_1 -->
 		
 	<section id="ldpc-typecontainer"><h2 class="normal">The representation of an LDPC MAY have an <code>rdf:type</code>
-		of only one of <code>ldp:Container</code> for <a title="">Linked Data Platform Container</a>.
+		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 -->
@@ -1281,11 +1281,11 @@
 
 	<section id="ldpc-post-createdmbr-contains"><h2 class="normal">
 		When a successful HTTP <code>POST</code> request to an LDPC results in the creation of an LDPR, a 
-		<a title="Containment triples">containment triple</a> MUST be added to the state of LDPC.  The
-		<a title="Containment triples">containment triple</a> whose subject is the LDPC URI, 
-		whose predicate is <code>ldp:contains</code> and whose object is the URI for the newly created document (LDPR).
+		<a title="Containment triples">containment triple</a> MUST be added to the state of 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. Other triples may be added as well.
+		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 
@@ -1297,13 +1297,13 @@
 	<section id="ldpc-post-createrdf"><h2 class="normal"><a title="LDP server">LDP servers</a> that successfully create a resource from a
 		RDF representation in the request entity body MUST honor the client's requested interaction model(s). The created resource
 		can be thought of as an RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[!rdf11-concepts]].
-		If any model cannot be honored, the server MUST fail the request.
+		If any requested model cannot be honored, the server MUST fail the request.
 	</h2><!-- Was 5.4.4 / #ldpc-5_4_4 -->
 	<ul>
-	<li>If the request header <a href="#ldpr-gen-linktypehdr">specifies an LDPR interaction model</a>, then the server MUST handle subsequent 
+	<li>If the request header specifies <a href="#ldpr-gen-linktypehdr">an LDPR interaction model</a>, then the server MUST handle subsequent 
 	requests to the newly created resource's URI as if it is an LDPR.
 	(even if the content contains an <code>rdf:type</code> triple indicating a type of LDPC).</li>
-	<li>If the request header <a href="#ldpc-linktypehdr">specifies an LDPC interaction model</a>, then the server MUST handle subsequent 
+	<li>If the request header specifies <a href="#ldpc-linktypehdr">an LDPC interaction model</a>, then the server MUST handle subsequent 
 	requests to the newly created resource's URI as if it is an LDPC.
 	</li>
 	<li>This specification does not constrain the server's behavior in other cases.</li>
@@ -1321,12 +1321,13 @@
 	
 	<section id="ldpc-post-rdfnullrel"><h2 class="normal">In RDF representations, <a title="LDP server">LDP servers</a> MUST interpret the null relative
 		URI for the subject of triples in the LDPR representation in the
-		request entity body as referring to the entity in the request body.
+		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 will usually result in
+		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>.
@@ -1359,7 +1360,7 @@
 	
 	<section id="ldpc-post-acceptposthdr"><h2 class="normal"><a title="LDP server">LDP servers</a> that support <code>POST</code> MUST
 		include an <a href="#header-accept-post"><code>Accept-Post</code> response header</a> on HTTP <code>OPTIONS</code>
-		responses, listing post document media type(s) supported by the server.
+		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 
@@ -1432,9 +1433,10 @@
 <section id="ldpc-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. Also <a title="LDP server">LDP servers</a> must also include HTTP headers
-		on response to <code>OPTIONS</code>, see <a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
+		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>
@@ -1487,7 +1489,7 @@
 <h2>General</h2>
 
 <section id="ldpbc-are-ldpcs"><h2 class="normal">Each <a title="Linked Data Platform Basic Container">LDP Basic Container</a> MUST also be 
-	a conforming <a title="Linked Data Platform Container">LDP Container</a> in <a href="#ldpc-container" class="sectionRef"></a> along the
+	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 <code>ldp:BasicContainer</code>, 
 	whose predicate is <code>rdfs:subClassOf</code>, 
@@ -1520,7 +1522,7 @@
 <section id="ldpdc-mbrpred"><h2 class="normal">
 	<a title="Linked Data Platform Direct Container">LDP Direct Containers</a>
 	SHOULD use the <code>ldp:member</code> predicate as an LDPC's <a title="Membership predicate">membership predicate</a>
-	if there is no obvious predicate from an application vocabulary to use..
+	if there is no obvious predicate from an application vocabulary to use.
 	The state of an LDPC includes information about which
 	resources are its members, in the form of <a title="Membership triples">membership triples</a> that
 	follow a consistent pattern.  The LDPC's state contains enough information for clients to discern
@@ -1567,7 +1569,7 @@
 	pattern is <var>( member-derived-URI , membership-predicate , membership-constant-URI )</var> MUST
 	contain exactly one triple
 	whose subject is the LDPC URI, 
-	whose predicate is either <code>ldp:isMemberOfRelation</code>, 
+	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>
@@ -1603,7 +1605,7 @@
 	<section id="ldpdc-del-contremovesmbrtriple"><h2 class="normal">
 		When an LDPR identified by the object of a <a title="membership triples">membership triple</a> which was
 		originally created by the LDP-DC is deleted, the LDPC server MUST also remove 
-		the corresponding membership triple..
+		the corresponding membership triple.
 	</h2>
 	</section><!-- Was 5.6.1 / #ldpc-5_6_1 -->
 
@@ -1620,8 +1622,8 @@
 <h2>General</h2>
 
 <section id="ldpic-are-ldpcs"><h2 class="normal">Each <a title="Linked Data Platform Indirect Container">LDP Indirect Container</a> MUST also be 
-	a conforming <a title="Linked Data Platform Direct Container">LDP Direct Container</a> in <a href="#ldpdc" class="sectionRef"></a> along the following
-	restrictions.  <a title="">LDP client</a>s MAY infer the following triple:
+	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 <code>ldp:IndirectContainer</code>, 
 	whose predicate is <code>rdfs:subClassOf</code>, 
 	and whose object is <code>ldp:Container</code>, 
@@ -1782,7 +1784,7 @@
 		<li>The addition of <code>Accept-Post</code> in this specification is pending 
 		advancement of an <a href="https://datatracker.ietf.org/doc/draft-wilde-accept-post/">IETF draft</a>
 		that would fully include it, based on the Accept-Patch header's design from [[!RFC5789]].  Once LDP is in
-		Candidate Recommendation, the LDP WG will make an assessment based on the status at IETF
+		Candidate Recommendation status, the LDP WG will make an assessment based on the status at IETF
 		working with the W3C Director.</li>
 		</ul>
 	</div>
@@ -2002,7 +2004,7 @@
 	</p>
 	
 	<pre class="example">
-	# The following is the ordered representation of
+	# The following is the representation of
 	#   http://example.org/netWorth/nw1/assetContainer/
 	<!-- @base is here only so it's easier to paste into validators for checking -->
 	# @base &lt;http://example.org/netWorth/nw1/assetContainer/&gt;.
@@ -2033,7 +2035,7 @@
 	</p>
 	
 	<pre class="example">
-	# The following is the ordered representation of
+	# The following is the representation of
 	#   http://example.org/netWorth/nw1/assetContainer/
 	<!-- @base is here only so it's easier to paste into validators for checking -->
 	# @base &lt;http://example.org/netWorth/nw1/assetContainer/&gt;.
@@ -2200,18 +2202,10 @@
 </p>
 
 <h2>Summary</h2>
-<p>Summary of notable changes from <a href="http://www.w3.org/TR/2013/WD-ldp-20140311/">previous public working draft</a>.</p>
+<p>Summary of notable changes from the <a href="http://www.w3.org/TR/2013/WD-ldp-20140311/">previous public working draft</a>.</p>
 <ul>
-	<li>Changed a number of the should/may clauses to must</li>
-	<li>Introduced separate concepts for memerbship and containment</li>
-	<li>Defined sub-types of ldp:Container : Basic, Direct and Indirect</li>
-	<li>Defined sub-types of ldp:Resource : RDF Source and non-RDF Source</li>
-	<li>Improved membership predicate names, changed vocabulary terms</li>
-	<li>Reorganized conformance clauses based on type of resource</li>
-	<li>Moved paging and sorting capability into a separate document [[LDP-PAGING]]</li>
-	<li>Removed non-member property mechanism and replaced with usage of Prefer header</li>
-	<li>Added support for client requested interaction models on containers</li>
-    <li>Move restatements of HTTP et al. out of normative sections</li>
+	<li>Resolved Last Call 2 comments</li>
+	<li>Removed references to RDF named graphs</li>
 </ul>
 
 <h2>Detailed history</h2>