2012-12-28 - Fixed Typos. Separated some compound rules like 4.1.5. Rewording for clarity: 4.1.10,
authorJohn Arwe <johnarwe@us.ibm.com>
Fri, 28 Dec 2012 15:18:04 -0500
changeset 33 3c8c101f3f97
parent 32 74f23a8f0137
child 34 e82a925b73b7
2012-12-28 - Fixed Typos. Separated some compound rules like 4.1.5. Rewording for clarity: 4.1.10,
Text being repeated in several places centralized and cross-linked. Made printed code output easier to read
on black & white printers. Exposed terms defined in-line under LDPC as Terminology (tentatively). Removed non-normative
qualifer from section 5.2. Added "several" editors' to-dos. (JA)
ldp.html
--- a/ldp.html	Mon Dec 17 10:30:58 2012 -0500
+++ b/ldp.html	Fri Dec 28 15:18:04 2012 -0500
@@ -52,6 +52,8 @@
                 company: "IBM Corporation", companyURL: "http://ibm.com/" },
               { name: "Michael Hausenblas", url: "http://mhausenblas.info/#i",
 	                company: "DERI, NUI Galway", companyURL: "http://deri.ie/" },
+              { name: "John Arwe", url: "https://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/allcommunities?userid=120000CAW7",
+                company: "IBM Corporation", companyURL: "http://ibm.com/" },
           ],
 
           // authors, add as many as you like. 
@@ -99,11 +101,18 @@
             min-width: 7.5em;
     	}
     </style>
+    <style type="text/css" media="all">
+    	code {
+    	    font-weight:bold;
+    	}
+		 /* 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. */
+    </style>
   </head>
 <body>
 <section id='abstract'>
 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 RDF.
+HTTP access to web resources that describe their state using <abbr title="Resource Description Framework">RDF</abbr>.
 </section>
  
 <section>
@@ -112,12 +121,12 @@
 	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>
+	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*, SPARQL)</p>
+		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
 		discover more things</p>
 	<p>The best practices and
@@ -148,39 +157,56 @@
 <section>
 <h1 id="terms">Terminology</h1>
 
-<p>Terminology is based on W3C's Architecture of the World Wide Web [[WEBARCH]] and Hyper-text Transfer Protocol [[HTTP11]] 
+<p>Terminology is based on W3C's Architecture of the World Wide Web [[WEBARCH]] and Hyper-text Transfer Protocol [[HTTP11]].
 </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]]</dd>
+		of a URI [[WEBARCH]].
+		<p></p></dd>
 							
 	<dt>Linked Data</dt>
-	<dd>As defined by Tim Berners-Lee. [[LINKED-DATA]]</dd>
+	<dd>As defined by Tim Berners-Lee [[LINKED-DATA]].<p></p></dd>
 	
-	<dt>Linked Data Platform Resource (LDPR)</dt>
+	<dt><dfn>Linked Data Platform Resource</dfn> (<dfn><abbr title="Linked Data Platform Resource">LDPR</abbr></dfn>)</dt>
 	<dd>HTTP resource that conforms to the simple lifecycle
-		patterns and conventions in this document.</dd>
+		patterns and conventions in the <a href="#ldpr">LDPRs</a> section.<p></p></dd>
 		
-	<dt>Linked Data Platform Container (LDPC)</dt>
-	<dd>LDP	resource that also conforms to additional patterns and conventions in this
-		document for managing membership.</dd>
+	<dt><dfn>Linked Data Platform Container</dfn> (<dfn><abbr title="Linked Data Platform Container">LDPC</abbr></dfn>)</dt>
+	<dd>LDPR that also conforms to <a href="#ldpc">additional patterns and conventions</a> for managing membership.
+	<p></p></dd>
 		
 	<dt>Client</dt>
-	<dd>A program that establishes connections for the purpose of sending requests. [[HTTP11]]</dd>
+	<dd>A program that establishes connections for the purpose of sending requests [[HTTP11]].<p></p></dd>
 	
 	<dt>Server</dt>
 	<dd>An application
 		program that accepts connections in order to service requests by
-		sending back responses. Any given program may be capable of being
+		sending back responses. 
+		<p>Any given program may be capable of being
 		both a client and a server; our use of these terms refers only to
 		the role being performed by the program for a particular
 		connection, rather than to the program's capabilities in general.
 		Likewise, any server may act as an origin server, proxy, gateway,
-		or tunnel, switching behavior based on the nature of each request.
-		[[HTTP11]]</dd>
+		or tunnel, switching behavior based on the nature of each request
+		[[HTTP11]]. </p></dd>
+
+	<dt><dfn>Membership triples</dfn></dt>
+	<dd>A set of triples in an LDPC's state that lists its members.
+		The membership triples of a container all have the same
+		subject and predicate, and the objects of the membership triples define
+		the container's members. 
+	<p></p></dd>
+	
+	<dt><dfn>Membership subject</dfn></dt>
+	<dd>The subject of all an LDPC's <a title="Membership triples">membership triples</a>.
+	<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>
   </dl>
-  
+
 <section>
 <h2 id="conventions">Conventions Used in This Document</h2>
 
@@ -199,15 +225,15 @@
 <section id='conformance'></section>
 
 <section>
-<h1 id="ldpr">Linked Data Platform Resource</h1>
-	<p>Linked Data Platform Resources (LDPRs) are HTTP resources
+<h1 id="ldpr">Linked Data Platform Resources</h1>
+	<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 LDPR servers. 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]],
+		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>
@@ -244,10 +270,13 @@
 			Location header and potentially also in the representation of the
 			LDPR. Clients SHOULD use that canonical URL to identify the LDPR.
 	</div>
-	<div id="ldpr-4_1_5" class="rule">4.1.5 LDPR predicates SHOULD use standard vocabularies such as Dublin Core
+	<div id="ldpr-4_1_5" class="rule">4.1.5 LDPRs 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.
+	</div>
+	<div id="ldpr-4_1_5_1" class="rule">4.1.5.1 LDPR predicates SHOULD use standard vocabularies such as Dublin Core
 		[[!DC-TERMS]], RDF [[!RDF-PRIMER]] and RDF Schema [[!RDF-SCHEMA]], whenever
-		possible. LDPRs SHOULD reuse existing vocabularies instead of creating
-		their own duplicate vocabulary terms.
+		possible.
 	</div>
 	<div id="ldpr-4_1_6" class="rule">4.1.6 LDPR predicates MUST use well-known RDF vocabularies as defined in
 		section <a href="#ldpr-prop">4.8 Common Properties</a> wherever a predicate’s meaning matches
@@ -256,7 +285,8 @@
 	<div id="ldpr-4_1_6_1" class="rule">4.1.6.1 LDPRs MUST use the predicate <code>rdf:type</code> to
 		represent the concept of type. The use of non-standard type
 		predicates, as well as <code>dcterms:type</code>, is
-		discouraged. [[!DC-RDF]]
+		discouraged (see <a href="#ldpr-prop">4.8 Common Properties</a>), as it is not recommended
+		by the Dublin Core Metadata Initiative for use with RDF resources [[!DC-RDF]]. 
 	</div>
 	<div id="ldpr-4_1_7" class="rule">4.1.7 LDPR representations SHOULD have at least one <code>rdf:type</code>
 		set explicitly.  This makes the representations much more useful to
@@ -276,20 +306,23 @@
 	<div id="ldpr-4_1_9" class="rule">4.1.9 LDPRs MUST use at least one RDF triple to represent a link
 		(relationship) to another resource. In other words, having the source
 		resource’s URI as the subject and the target resource’s URI as the
-		object of the triple represent the link (relationship) is enough and
+		object of the triple representing the link (relationship) is enough and
 		does not require the creation of an intermediate link resource to
 		describe the relationship.
 	</div>
-	<div id="ldpr-4_1_10" class="rule">4.1.10 LDPR servers MAY support additional standard representations. These
+	<div id="ldpr-4_1_10" class="rule">4.1.10 LDPR servers MAY support standard 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 be likely be common.
 		
 	<div id="ldpr-4_1_11" class="rule">4.1.11 LDPRs MAY be created, updated and deleted using methods not defined in
 		this document, for example through application-specific means, SPARQL
-		UPDATE, etc. [[!SPARQL-UPDATE]]
+		UPDATE, etc. [[!SPARQL-UPDATE]], as long as those methods do not conflict with this specification's 
+		normative requirements.
 	</div>
 	<div id="ldpr-4_1_12" class="rule">4.1.12 LDPR server responses MUST contain accurate response <code>ETag</code>
 		header values.
+	</div>
 		
 	<div class="ldp-issue">
 	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/10">ISSUE-10</a></div>
@@ -313,31 +346,44 @@
 	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/19">ISSUE-19</a></div>
 	Adressing more error cases
 	</div>	
+
+	<div id="ldpr-4_1_13" class="rule">4.1.13 LDPR
+		servers SHOULD enable simple creation and modification of LDPRs.
+		It is
+		common for LDPR servers to put restrictions on representations – for
+		example, the range of <code>rdf:type</code> predicates, datatypes of
+		the objects of predicates, and the number of occurrences of predicates in an LDPR, but
+		servers SHOULD minimize those restrictions.  Enforcement of
+		more complex constraints will greatly restrict the set of clients
+		that can modify resources. For some server applications, excessive
+		constraints on modification of resources may be required.
+	</div>
 </section>
 
 <section>
 <h2 id="ldpr-HTTP_GET">HTTP GET</h2>
 	<div id="ldpr-4_2_1" class="rule">4.2.1 LDPR servers MUST support the HTTP GET Method for LDPRs.
 	</div>
-	<div id="ldpr-4_2_2" class="rule">4.2.2 LDPR servers MUST provide an <code>text/turtle</code>
-		representation of the requested LDPR.[[!TURTLE]]
+	<div id="ldpr-4_2_2" class="rule">4.2.2 LDPR servers MUST provide a <code>text/turtle</code>
+		representation of the requested LDPR [[!TURTLE]].
 	</div>
-	<div id="ldpr-4_2_3" class="rule">4.2.3 LDPR servers MAY provide other
-		representation of the requested LDPR using standard HTTP content negotiation. 
+	<div id="ldpr-4_2_3" class="rule">4.2.3 LDPR servers MAY provide 
+		representations of the requested LDPR beyond those
+		necessary to conform to this specification, using standard HTTP content negotiation. 
 		If the client does not indicate a preference, <code>text/turtle</code> MUST be returned.
 		
 	<div id="ldpr-4_2_4" class="rule">4.2.4 In the absence of special knowledge of the application or domain, LDPR
-		clients MUST assume that any LDPR may have multiple values for <code>rdf:type</code>.
+		clients MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
 	</div>
 	<div id="ldpr-4_2_5" class="rule">4.2.5 In the absence of special knowledge of the application or domain, LDPR
 		clients MUST assume that the <code>rdf:type</code> values
-		of a given LDPR may change over time.
+		of a given LDPR can change over time.
 	</div>
 </section>
 
 <section>
 <h2 id="ldpr-HTTP_POST">HTTP POST</h2>
-	<p>There are no additional requirements on HTTP POST for LDPRs.</p>
+	<p>This specification adds no new requirements on HTTP POST for LDPRs.</p>
 </section>
 
 <section>
@@ -368,10 +414,10 @@
 		errors with the request. [[!HTTP11]]
 	</div>
 	<div id="ldpr-4_4_3" class="rule">4.4.3 LDPR clients SHOULD always assume that the set of predicates for a
-		resource of a particular type at an arbitrary server is open in the
+		resource of a particular type at an arbitrary server is open, in the
 		sense that different resources of the same type may not all have the
-		same set of predicates in its triples, and the set of predicates that
-		are used in the state of a resource is not limited to any pre-defined
+		same set of predicates in their triples, and the set of predicates that
+		are used in the state of any one resource is not limited to any pre-defined
 		set.
 	</div>
 	<div id="ldpr-4_4_4" class="rule">4.4.4 LDPR clients SHOULD assume that a LDPR server could discard triples
@@ -389,15 +435,8 @@
 	<div id="ldpr-4_4_6" class="rule">4.4.6 LDPR servers MAY choose to allow the creation of new resources using HTTP PUT.
 	</div>
 	<div id="ldpr-4_4_7" class="rule">4.4.7 LDPR servers SHOULD allow clients to update resources without
-		requiring detailed knowledge of server-specific constraints.  It is
-		common for LDPR servers to put restrictions on representations – for
-		example, the range of <code>rdf:type</code>, datatypes of
-		predicates and number of occurrences of predicates in triples, but
-		servers SHOULD minimize those restrictions.  In other words, LDPR
-		servers need to enable simple modification of LDPRs. Enforcement of
-		more complex constraints will greatly restrict the types of clients
-		that can modify resources. For some server applications, excessive
-		constraints on modification of resources may be required.
+		requiring detailed knowledge of server-specific constraints.  
+		This is a consequence of the requirement to <a href="#ldpr-4_1_13">enable simple creation and modification</a> of LPDRs.
 	</div>		
 </section>
 		
@@ -406,7 +445,7 @@
 	<div id="ldpr-4_5_1" class="rule">4.5.1 LDPR servers MUST remove the resource identified by the Request-URI.
 		After a successful HTTP DELETE, a subsequent HTTP GET on the same
 		Request-URI MUST result in a 404 (Not found) or 410 (Gone) status
-		code. Clients SHOULD note that severs MAY reuse a URI under some circumstances.
+		code. Clients SHOULD note that servers MAY reuse a URI under some circumstances.
 	</div>
 	
 	<div id="ldpr-4_5_2" class="rule">4.5.2 LDPR servers MAY alter the state of other resources as a result of an
@@ -433,17 +472,17 @@
 		minimal set of patch document formats is mandated by this document.
 	</div>
 	<div id="ldpr-4_7_2" class="rule">4.7.2 LDPR servers SHOULD allow clients to update resources without
-		requiring detailed knowledge of server-specific constraints.  It is
-		common for LDPR servers to put restrictions on representations – for
-		example, the range of <code>rdf:type</code>, datatypes of
-		predicates and number of occurrences of predicates in triples – but
-		server enforcement of detailed, domain-specific constraints will
-		greatly restrict the types of clients who can update resources.
+		requiring detailed knowledge of server-specific constraints.  
+		This is a consequence of the requirement to <a href="#ldpr-4_1_13">enable simple creation and modification</a> of LPDRs.
+	</div>
+	<div id="ldpr-4_7_3" class="rule">4.7.3 LDPR servers SHOULD NOT allow clients to create new resources using PATCH.
+		<a href="#ldpr-5_4">POST (to a LDPC)</a> and/or <a href="#ldpr-4_4">PUT</a> should be used as the standard way to create new LDPRs.
 	</div>
 	
 	<div class="ldp-issue">
 	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/12">ISSUE-12</a></div>
 	Can HTTP PATCH be used for resource creation?
+	2012-12-17 WG mtg: resolved as Discouraged - 4.7.3 added for review.
 	</div>
 	<div class="ldp-issue">
 	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/17">ISSUE-17</a></div>
@@ -456,14 +495,14 @@
 	<p>
 		This section summarizes some well-known RDF vocabularies that MUST be
 		used in Linked Data Platform Resources wherever a resource needs to use a
-		predicate whose meaning matches one of these. For example, if a BP
-		resource has a <em>description</em>, and the application semantic of that
+		predicate whose meaning matches one of these. For example, if an LDPR
+		 has a <em>description</em>, and the application semantic of that
 		<em>description</em> is compatible with <code>dcterms:description</code>,
 		then <code>dcterms:description</code> MUST be used. If
 		needed, additional application-specific predicates MAY be used. A
-		specification for a domain that is based on BP may require one or
+		specification based on <abbr title="Linked Data Platform">LDP</abbr> may require one or
 		more of these properties for a particular resource type. The Range
-		column in the tables below identify the RECOMMENDED <code>rdfs:range</code>
+		column in the tables below identifies the RECOMMENDED <code>rdfs:range</code>
 		for the properties.
 	</p>
 	<div id="ldpr-4_8_1" class="rule">4.8.1 From Dublin Core</div>
@@ -532,10 +571,13 @@
 		</tr>
 	</table>
 
+	<div id="ldpr-4_8_1_1" class="rule">4.8.1.1 From Dublin Core
 	<p>
 		The predicate <code>dcterms:type</code> SHOULD NOT be
-		used, instead use <code>rdf:type</code>. [[!DC-RDF]].
+		used in LDPRs, instead use <code>rdf:type</code> [[!DC-RDF]].
+		See also <a href="#ldpr-4_1_6_1">4.1.6.1 LDPRs MUST use <code>rdf:type</code></a>.
 	</p>
+	</div>
 	
 	<div id="ldpr-4_8_2" class="rule">4.8.2 From RDF</div>
 	<p>
@@ -582,7 +624,7 @@
 </section>
 
 <section>
-<h1 id="ldpc">Linked Data Platform Container</h1>
+<h1 id="ldpc">Linked Data Platform Containers</h1>
 
 <section class="informative">		
 <h2 id="ldpc-informative">Informative</h2>
@@ -649,7 +691,7 @@
 			a predicate other than <code>rdfs:member</code> as the membership predicate, as illustrated
 			below.</p>
 
-<pre class="example">
+<pre class="example" id="ldpc-ex-membership-subj">
 # The following is the representation of
 #   http://example.org/netWorth/nw1/assetContainer
 @prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
@@ -957,22 +999,19 @@
 		</p>
 </section>
 
-<section class="informative">
+<section>
 <h2 id="ldpc-general">General</h2>
+	<p>The Linked Data Platform does not define how clients
+		discover <dfn><abbr title="Linked Data Platform Containers">LDPCs</abbr></dfn>.</p>
+
 	<div id="ldpc-5_2_1" class="rule">5.2.1 LDPC servers MUST also be conformant LDPR servers. A Linked Data Platform
 		Container is a resource that is a Linked Data Platform Resource.
 	</div>
 	<div id="ldpc-5_2_2" class="rule">5.2.2 The same resource MAY be a member of multiple LDPCs. This happens
 		commonly if one container is a view onto a larger container.
 	</div>
-	<div id="ldpc-5_2_3" class="rule">5.2.3 The representation of a LDPC includes information about which
-		resources are its members. The set of members of a container is a set
-		of triples in its representation (and state) called the membership
-		triples. The membership triples of a container all have the same
-		subject and predicate – the objects of the membership triples define
-		the members of the container. The subject of the membership triples
-		is called the membership subject and the predicate is called the
-		membership predicate. In the simplest cases, the membership subject
+	<div id="ldpc-5_2_3" class="rule">5.2.3 The state of a LDPC includes information about which
+		resources are its members. In the simplest cases, the membership subject
 		will be the LDPC resource itself, but it does not have to be. The
 		membership predicate is also variable and will often be a predicate
 		from the server application vocabulary. If there is no obvious
@@ -984,12 +1023,14 @@
 	container affordances
 	</div>	
 	</div>
-	<div id="ldpc-5_2_4" class="rule">5.2.4 A LDPC MUST contain one triple for the <code>ldp:membershipSubject</code>
-		predicate that indicates the subject of the membership triples when container subject is not the LDPC itself.
+	<div id="ldpc-5_2_4" class="rule">5.2.4 A LDPC MUST contain one triple containing the <code>ldp:membershipSubject</code>
+		predicate when the membership subject is not the LDPC itself.  
+		This triple's object provides clients with the LDPC's membership subject URI.
 	</div>
-	<div id="ldpc-5_2_5" class="rule">5.2.5 A LDPC MUST contain one triple for the <code>ldp:membershipPredicate</code>
-		predicate that indicates the predicate of the membership triple when
+	<div id="ldpc-5_2_5" class="rule">5.2.5 A LDPC MUST contain one triple containing the <code>ldp:membershipPredicate</code>
+		predicate when
 		the container predicate is not <code>rdfs:member</code>.
+		This triple's object provides clients with the LDPC's membership predicate URI.
 	</div>
 	<div id="ldpc-5_2_6" class="rule">5.2.6 The representation of a LDPC MAY include an arbitrary number of
 		additional triples whose subjects are the members of the container,
@@ -1009,7 +1050,7 @@
 		<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>,
-		<code>rdf:Seq</code> and <code>rdf:List</code>.
+		<code>rdf:Seq</code> or <code>rdf:List</code>.
 	</div>
 	
 	<div class="ldp-issue">
@@ -1023,7 +1064,7 @@
 	<div id="ldpc-5_3_1" class="rule">5.3.1 The representation of a LDPC MUST contain a set of triples with a
 		consistent subject and predicate whose objects indicate members of
 		the container. The subject of the triples MAY be the container itself
-		or MAY be another resource (as in the example above).  See also
+		or MAY be another resource (as in the <a href="#ldpc-ex-membership-subj">example</a>).  See also
 		<a href="#ldpc-5_2_3">5.2.3</a>.
 	</div>
 	<div id="ldpc-5_3_2" class="rule">5.3.2 LDPC servers SHOULD support requests for information about a known LDPC
@@ -1093,19 +1134,17 @@
 	Include clarifications about ordering in LDPC representations
 	</div>
 	</div>
-	<div id="ldpc-5_3_7_1" class="rule">5.3.7.1 The object of <code>ldp:containerSortPredicates</code>’,
+	<div id="ldpc-5_3_7_1" class="rule">5.3.7.1 The object of <code>ldp:containerSortPredicates</code>,
 		the predicate used to indicate ordering, MUST NOT change between
 		subsequent pages. If it does, ordering among members of a container
 		across pages is undefined. See section <a href="#ldpc-ordering">5.1.4 Ordering</a> for
 		additional details.
 	</div>
-	<p>The Linked Data Platform does not define how clients
-		discover LDPCs.</p>
 </section>
 
 <section>
 <h2 id="ldpc-HTTP_POST">HTTP POST</h2>
-	<div id="ldpc-5_4_1" class="rule">5.4.1 LDPC clients SHOULD create resources by submitting a representation as
+	<div id="ldpc-5_4_1" class="rule">5.4.1 LDPC clients SHOULD create member resources by submitting a representation as
 		the entity body of the HTTP POST to a known LDPC. LDPC servers MUST
 		respond with status code 201 (Created) and the <code>Location</code>
 		header set to the new resource’s URL.
@@ -1127,14 +1166,14 @@
 		words, clients should not expect any representation in the response
 		entity body on a 201 (Created) response.
 	</div>
-	<div id="ldpc-5_4_6" class="rule">5.4.6 For LDPCs, servers MUST accept a request entity body with a request header
+	<div id="ldpc-5_4_6" class="rule">5.4.6 LDPC servers MUST accept a request entity body with a request header
 	    of <code>Content-Type</code> with value of <code>text/turtle</code> [[!TURTLE]].
 	</div>
-	<div id="ldpc-5_4_7" class="rule">5.4.7 For LDPCs, LDPR servers SHOULD accept a request with an entity body
-		representations as indicated by request header <code>Content-Type</code> when present, otherwise it MAY be
-		derived by inspecting the entity body contents [[!HTTP11]].
+	<div id="ldpc-5_4_7" class="rule">5.4.7 LDPC servers SHOULD use the <code>Content-Type</code> request header 
+		to determine the representation format when the request has an entity body.  When the header is absent, 
+		LDPC servers MAY infer the content type by inspecting the entity body contents [[!HTTP11]].
 	</div>
-	<div id="ldpc-5_4_8" class="rule">5.4.8 For RDF representations, LDPC servers MUST interpret the null relative
+	<div id="ldpc-5_4_8" class="rule">5.4.8 In RDF representations, LDPC servers 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.
 		Commonly, that entity is the model for the “to be created” LDPR, so
@@ -1152,12 +1191,8 @@
 	</div>
 	<div id="ldpc-5_4_10" class="rule">5.4.10 LDPC servers SHOULD allow clients to create new resources without
 		requiring detailed knowledge of application-specific constraints.
-		 Some LDPC servers put restrictions on representations – for example,
-		the range of <code>rdf:type</code>, datatypes of
-		predicates and number of occurrences of predicates in triples - but
-		server enforcement of detailed, domain-specific constraints will
-		greatly restrict the types of clients that can create resources and
-		therefore discouraged.
+		This is a consequence of the requirement to 
+		<a href="#ldpr-4_1_13">enable simple creation and modification</a> of LPDRs.
 	</div>
 </section>
 
@@ -1169,7 +1204,7 @@
 	</div>
 	<div id="ldpc-5_5_2" class="rule">5.5.2 LDPC servers MAY allow updating LDPC non-membership properties using
 		HTTP PUT on <code>&lt;containerURL&gt;?non-member-properties</code>, which
-		MAY exclude server managed properties such as <code>ldp:membershipSubject</code> and <code>ldp:membershipPredicate</code>.
+		MAY exclude server-managed properties such as <code>ldp:membershipSubject</code> and <code>ldp:membershipPredicate</code>.
 	</div>
 </section>
 
@@ -1201,7 +1236,7 @@
 
 	<div class="ldp-issue">
 	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/7">ISSUE-7</a></div>
-	What operations are permittered on containers and how do they get invoked?
+	What operations are permitted on containers and how do they get invoked?
 	</div>
 </section>
 
@@ -1234,9 +1269,13 @@
 	<li>2012-11-01 - Fixed minor typo and added some notes (SS)</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 severs may reuse a Request-URI under some circumstances."</li>
+	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-05 - minor rewording from ISSUE-24</li>
+	<li>2012-12-28 - Fixed Typos.  Separated some compound rules like 4.1.5.  Rewording for clarity: 4.1.10, 
+	Text being repeated in several places centralized and cross-linked.  Made printed code output easier to read
+	on black & white printers.  Exposed terms defined in-line under LDPC as Terminology (tentatively).  Removed non-normative
+	qualifer from section 5.2.  Added "several" editors' to-dos.(JA)</li>
 </ul></section>
 
 <section class='appendix informative' id="todos">
@@ -1247,11 +1286,42 @@
 	<li>Insert some additional examples</li>
 	<li>Expand on status code usages</li>
 	<li>Editor(Steve) to consider structure based on feedback from tbl and others</li>
+	<li>4.1.2: "the" subject ?= Request-URI  ... not always (hash URIs)
+	</li>
+	<li>4.1.4: Location or Content-Location?
+	</li>
+	<li>4.1.5: refers to RDF *Primer* - is that intentful?
+	</li>
+	<li>4.1.6.1: why does it have the extra .1, to avoid renumbering?  should we divide General into subsections
+	for vocab/client/server constraints?  Do we need to define "LDPR server"? ...think about role vs artifact.  If
+	"an LDPR server" hosts both LDPRs and non-LDPR HTTP resources, 4.1.2 (if "the code" == LDPR server) could be
+	read to say that in order to conform to spec it must serve up RDF for non-LDPRs.  Hits 5.2.1 too.
+	</li>
+	<li>4.1.7: define "explicitly"?
+	</li>
+	<li>4.4.1: specifically calls out 2 props; issue-11 note talks about "server-managed props" which is not defined.
+	</li>
+	<li>4.4.4/4.4.5 could be read to overlap/dup one another
+	</li>
+	<li>4.8 talks about rdfs:Range which implies inferencing.  4.1.7 spec says want to avoid putting that reqt on clients.
+	</li>
+	<li>5.2.1: 4.1.6.1 issue linked to this text
+	</li>
+	<li>5.2.2: I think we mean "resource" == any HTTP resource, not just LDPR.  If so, perhaps we should be more explicit.
+	5.2.1 might be the place.
+	</li>
+	<li>5.2.3-5.2.5: don't we need to tell clients to fetch LDPC's non-member properties, introspect for these predicates,
+	and (if either not found) supply the defaults?  that is the net effect of what's here.
+	</li>
+	<li>5.4.5: in light of the existence of server-managed properties, why not allow response body from create?
+	</li>
+	<li>
+	</li>
 </ul>
 
 	<div class="ldp-issue">
 	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/5">ISSUE-5</a></div>
-	Add a section explaining how LDBP is related to Graph Store Protocol
+	Add a section explaining how LDP is related to Graph Store Protocol
 	</div>
 </section>