ldp.html
changeset 215 da72115eb40b
parent 213 a3bbdfcee70e
child 216 c2913c5cf917
--- a/ldp.html	Wed Jul 17 12:55:01 2013 -0500
+++ b/ldp.html	Wed Jul 17 17:01:32 2013 -0400
@@ -1,7 +1,17 @@
 <!DOCTYPE html>
 <!-- 
  Editor TODO:
-   - none
+   - The word "canonical" is used twice in the document. Since we do not deal with URI 
+     canonicalization in the specification, I would remove the word and the meaning of 
+     the sentences is the same.
+   - section 4.6...respec is adding extra spaces to the sectionRefs
+	  carefully read section 4.2 .
+	  ->
+	  carefully read section 4.2.
+	
+	  defined in section 4.8 .
+	  ->
+	  defined in section 4.8.
  -->
 <html>
   <head>
@@ -154,7 +164,7 @@
   </head>
 <body>
 <section id='abstract'>
-A set of best practices and simple approach for a read-write Linked Data architecture, based on
+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>
@@ -163,28 +173,28 @@
 <h1 id="intro">Introduction</h1>
 	<p>This document describes the use
 	of HTTP for accessing, updating, creating and deleting resources from
-	servers that expose their resources as Linked Data.  It provides some
-	new rules as well as clarifications and extensions of the four rules
-	of Linked Data [[LINKED-DATA]]:</p>
+	servers that expose their resources as Linked Data.  It provides clarifications
+	and extensions of the four rules of Linked Data [[LINKED-DATA]]:</p>
 	<p>1. Use URIs as names for things</p>
 	<p>2. Use HTTP URIs so that people can look up those
 		names</p>
 	<p>3. When someone looks up a URI, provide useful
 		information, using the standards (RDF*, <abbr title="SPARQL Protocol and RDF Query Language">SPARQL</abbr>)</p>
-	<p>4. Include links to other URIs. so that they can
+	<p>4. Include links to other URIs, so that they can
 		discover more things</p>
 	<p>This specification discusses standard HTTP and RDF techniques and best practices that you 
 	should use, and anti-patterns you should avoid, when constructing clients and servers that 
-	read and write Linked Data.</p> 
-	<p>A special type of Linked Data Platform Resource is a Container.  Containers are very useful 
+	read and write Linked Data resources.</p> 
+	<p>A special type of <a title="Linked Data Platform Resource">Linked Data Platform Resource</a> is a 
+	<a title="Linked Data Platform Container">Container</a>.  Containers are very useful 
 	in building application models.  For example, universities offer a collection of classes 
-	and have a collection of faculty members.  Each faculty member teaches a collection of courses, etc.  
+	and have a collection of faculty members, each faculty member teaches a collection of courses, etc.  
 	This specification discusses how to work with containers.  Resources can be added to containers in 
 	several ways. As a special case, members can both be created and added to a container by overloading 
-	the POST operation.  See <a href="#ldpc-HTTP_POST" class="sectionRef"></a>.</p>
+	the POST operation (see <a href="#ldpc-HTTP_POST" class="sectionRef"></a>).</p>
 	<p>Another contribution of this specification is how to deal with large amounts of data.  
 	Depending on the server’s capabilities, a GET request on a Linked Data Platform Resource 
-	returns a set of pages and uses a convention to access any subsequent page. See <a href="#ldpr-Paging" class="sectionRef"></a>. </p>
+	returns a set of pages and uses a convention to access any subsequent page (see <a href="#ldpr-Paging" class="sectionRef"></a>). </p>
 	<p>The intention of this document is to enable additional rules and layered groupings of rules as 
 	additional specifications.  The scope is intentionally narrow to provide a set of key rules for 
 	reading and writing Linked Data that most, if not all, other specifications will depend upon and 
@@ -207,7 +217,7 @@
 	
 	<dt><dfn>Linked Data Platform Resource</dfn> (<dfn><abbr title="Linked Data Platform Resource">LDPR</abbr></dfn>)</dt>
 	<dd>HTTP resource whose state is represented in RDF that conforms to the simple lifecycle
-		patterns and conventions in the <a href="#ldpr" class="sectionRef"></a>.<p></p></dd>
+		patterns and conventions in <a href="#ldpr" class="sectionRef"></a>.<p></p></dd>
 		
 	<dt><dfn>Linked Data Platform Container</dfn> (<dfn><abbr title="Linked Data Platform Container">LDPC</abbr></dfn>)</dt>
 	<dd>An LDPR representing a collection of same-subject, same-predicate triples which is uniquely identified by a URI
@@ -430,7 +440,7 @@
 
 	<div id="ldpr-4_1_11" class="rule">4.1.11 LDPR servers
 		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
+		of content defined by LDP.  Other specifications built on top of LDP may require clients
 		to implement inferencing [[!RDF-CONCEPTS]].  The practical implication is that all content defined by LDP
 		must be explicitly represented. 
 	</div>
@@ -462,9 +472,9 @@
 <h2 id="ldpr-HTTP_POST">HTTP POST</h2>
 	<p>This specification adds no new requirements on HTTP <code>POST</code> for LDPRs 
 		even when the LDPR supports that method.  This specification does not impose any
-		new requirement to support that method, and [[!HTTP11]] makes it optional</p>
-	<p>Creation of LDPRs can be done via <a href="#ldpc-HTTP_POST" class="sectionRef"></a> or
-		<a href="#ldpc-HTTP_PUT" class="sectionRef"></a> to a LDPC, see those 
+		new requirement to support that method, and [[!HTTP11]] makes it optional.</p>
+	<p>Creation of LDPRs can be done via <code>POST</code> (<a href="#ldpc-HTTP_POST" class="sectionRef"></a>) or
+		<code>PUT</code> (<a href="#ldpc-HTTP_PUT" class="sectionRef"></a>) to a LDPC, see those 
 		sections for more details.</p>
 </section>
 
@@ -547,8 +557,7 @@
 <h2 id="ldpr-HTTP_HEAD">HTTP HEAD</h2>
 	<p>Note that certain LDP mechanisms, such as paging, rely on HTTP headers, and HTTP generally requires that
 		<code>HEAD</code> responses include the same headers as <code>GET</code> responses.  
-		Thus, implementers should also carefully read 
-		<a href="#ldpr-HTTP_GET" class="sectionRef"></a>.</p>
+		Thus, implementers should also carefully read <a href="#ldpr-HTTP_GET" class="sectionRef"></a>.</p>
 	<div id="ldpr-4_6_1" class="rule">4.6.1 LDPR servers MUST support the HTTP <code>HEAD</code> method.</div>
 	<div id="ldpr-4_6_2" class="rule">4.6.2 LDPR servers MUST support the HTTP response headers defined in <a href="#ldpr-HTTP_OPTIONS" class="sectionRef"></a>.
 	</div>
@@ -648,7 +657,7 @@
 		header with <code>rel="first"</code>; the target URI in the header is the URL
 		of the first page resource.
 		The client then 
-		requests the first page as <code>ttp://example.org/customer-relations?firstPage</code>:
+		requests the first page as <code>http://example.org/customer-relations?firstPage</code>:
 	</p>
 
 <pre class="example"># The following is the representation of
@@ -713,7 +722,7 @@
    o:status o:ActiveCustomer, o:BronzeCustomer;
    foaf:name "Alfred E. Smith".</pre>
 	<p>
-		In this example, there is only two customers provided in the
+		In this example, there are only two customers provided in the
 		final page.  To indicate this is the last page, a value of <code>rdf:nil</code> is used for the <code>ldp:nextPage</code>
 		predicate of the page resource.
 	</p>
@@ -721,7 +730,7 @@
 
 <section>
 <h3 id="ldpr-PagingGET">HTTP GET</h3>
-<p>In addition to the requirements set forth in section (HTTP <code>GET</code>), LDPR servers that support paging must also follow the requirements in this section</p>
+<p>In addition to the requirements set forth in <a href="#ldpr-HTTP_GET" class="sectionRef"></a> on HTTP <code>GET</code>, LDPR servers that support paging must also follow the requirements in this section</p>
 
 	<div id="ldpr-pagingGET-1" class="rule">4.9.2.1 LDPR servers SHOULD allow clients to retrieve large LDPRs in
 		pages. In responses to <code>GET</code> requests with an LDPR as the <code>Request-URI</code>, 
@@ -1112,7 +1121,6 @@
 
 	<div id="ldpc-get_non-member_props" class="rule">5.1.2 Retrieving Only Non-member Properties
 	</div>
-	<em>This section is non-normative</em>
 	<p>The representation of a container
 		that has many members will be large. There are several important
 		cases where clients need to access only the non-member properties of
@@ -1159,8 +1167,7 @@
 	<p>While the same non-member resource could be used to update the non-member properties via PUT,
 		LDP recommends using PATCH for this purpose.</p>
 
-	<div id="ldpc-ordering" class="rule">5.1.4 Ordering</div>
-	<em>This section is non-normative</em>
+	<div id="ldpc-ordering" class="rule">5.1.3 Ordering</div>
 	<p>
 		There are many cases where an ordering of the members of the
 		container is important. LDPC does not provide any particular support
@@ -1264,13 +1271,13 @@
 		any kind of resource identified by its URI, LDPR or otherwise.
 	</div>
 	
-	<div id="ldpc-5_2_4" class="rule">5.2.4 An LDPC MUST contain one triple 
+	<div id="ldpc-5_2_4" class="rule">5.2.4 An LDPC representation MUST contain one triple 
 		whose subject is the LDPC URI, 
 		whose predicate is the <code>ldp:membershipSubject</code>, 
 		and whose object is the LDPC's membership subject URI.
 	</div>
 	
-	<div id="ldpc-5_2_5" class="rule">5.2.5 An LDPC MUST contain one triple 
+	<div id="ldpc-5_2_5" class="rule">5.2.5 An LDPC representation MUST contain one triple 
 		whose subject is the LDPC URI, 
 		and whose predicate is either <code>ldp:membershipPredicate</code> or <code>ldp:membershipPredicateInverse</code>. 
 		The object of the triple is constrained by other sections, such as
@@ -1316,7 +1323,7 @@
 		of <code>ldp:Container</code>, but it MAY have additional
 		<code>rdf:type</code>s.
 	</div>
-	<div id="ldpc-5_2_8" class="rule">5.2.8 LDPCs SHOULD NOT use RDF container types <code>rdf:Bag</code>,
+	<div id="ldpc-5_2_8" class="rule">5.2.8 LDPC representations SHOULD NOT use RDF container types <code>rdf:Bag</code>,
 		<code>rdf:Seq</code> or <code>rdf:List</code>.
 	</div>
 
@@ -1492,8 +1499,8 @@
 		details.
 	</div>
 	<div id="ldpc-5_4_4" class="rule">5.4.4 For servers that support create, LDPC servers MUST create an LDPR from a
-		RDF representation in the request entity body.  The newly created LDPR could also be a LDPC, therefore servers may
-		allow the creations of LDPCs within a LDPC. 
+		RDF representation in the request entity body.  The newly created LDPR could also be a LDPC, therefore servers MAY
+		allow the creation of LDPCs within a LDPC. 
 	</div>
 	
 	<div id="ldpc-5_4_5" class="rule">5.4.5 LDPC servers MUST accept a request entity body with a request header
@@ -1879,6 +1886,7 @@
 <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130701/">Third Public Working Draft</a></em></blockquote>
 -->
 <ul>
+	<li>2013-07-17 - Various updates from suggests from <a href="http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0067.html">Raúl</a> (SS)</li>
 	<li>2013-07-15 - Inserted ldp:membershipObject into examples (SS)</li>
 	<li>2013-07-15 - ISSUE-79 ldp:contains => ldp:created  (JA)</li>
 	<li>2013-07-11 - Improving working in <a href="#ldpr-Paging" class="sectionRef"></a> to remove container references (SS)</li>