editorial changes - "an" to "a" etc
authorJohn Arwe
Tue, 15 Apr 2014 15:38:48 -0400
changeset 552 4d99968383f2
parent 551 962b81033167
child 553 3d27d1a1d553
editorial changes - "an" to "a" etc
ldp.html
--- a/ldp.html	Tue Apr 15 15:11:02 2014 -0400
+++ b/ldp.html	Tue Apr 15 15:38:48 2014 -0400
@@ -327,7 +327,7 @@
 	<p></p></dd>
 		
 	<dt><dfn>Linked Data Platform Container</dfn> (<abbr title="Linked Data Platform Container">LDPC</abbr>)</dt>
-	<dd>An LDP-RS representing a collection of linked
+	<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
@@ -352,12 +352,13 @@
 	<p></p></dd>
 		 
 	<dt><dfn>Membership</dfn></dt>
-	<dd>The relationship linking an LDP-RS (LDPCs are also LDP-RSs) and its member LDPRs.  
+	<dd>The relationship linking an LDP-RS (LDPCs are also LDP-RSs) and its member LDPRs, 
+	which can be different resources than its <a title="Containment">contained</a> documents.  
 	There often is a linked LDPC that assists with managing the member LDPRs.<p></p></dd>
 
 	<dt><dfn>Membership triples</dfn></dt>
 	<dd>A set of triples in an LDP-RS's state that lists its members.
-		An LDP-RS's membership triples all have one of the following patterns:
+		A LDP-RS's membership triples all have one of the following patterns:
 		<table class="indented">
 		<tr>
 		<td style="background:#DDDDDD"> <var>membership-constant-URI</var> </td>
@@ -493,7 +494,7 @@
 	into client consumable chunks called pages. A separate LDP specification outlines the conformance
 	rules around pagination [[LDP-PAGING]].
 	</p>
-	<p>An LDP server can manage two kinds of <a title="Linked Data Platform Resources">LDPRs</a>, those resources whose state 
+	<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
@@ -552,7 +553,7 @@
 		</p>
 		<p>
 		Note: 
-		<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
+		<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.
@@ -596,11 +597,11 @@
 	<p>
 		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, 
+		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 an LDPC, 
+	<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.
@@ -613,7 +614,7 @@
 	<p>
 		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, 
+		When a LDP server supports this method, 
 		this specification imposes the following new requirements for LDPRs.
 	</p>
 		
@@ -688,7 +689,7 @@
 	<p>
 		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, 
+		When a LDP server supports this method, 
 		this specification imposes no new blanket requirements for LDPRs.
 	</p>
 		
@@ -712,7 +713,7 @@
 	<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 an LDP server supports this method, 
+		When a LDP server supports this method, 
 		this specification imposes the following new requirements for LDPRs.
 	</p>
 		
@@ -771,7 +772,7 @@
 		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 an LDP-RS MAY have an <code>rdf:type</code>
+	<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 -->
 		
@@ -814,7 +815,7 @@
 	</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 an LDP-RS using HTTP <code>GET</code> that
+		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
@@ -830,7 +831,7 @@
 	
 	<section id="ldpr-cli-hints-ignorable"><h2 class="normal">
 		<a title="LDP client">LDP clients</a> MUST 
-		be capable of processing responses formed by an LDP server that ignores hints,
+		be capable of processing responses formed by a LDP server that ignores hints,
 		including LDP-defined hints.
 	</h2></section>
 	
@@ -838,7 +839,7 @@
 	<p>The LDP Working Group proposes incorporation of the following clause to make LDP clients paging aware:</p>
 	<section id="ldpr-cli-paging"><h2 class="normal">
 		<a title="LDP client">LDP clients</a> SHOULD 
-		be capable of processing successful HTTP <code>GET</code> responses formed by an LDP server
+		be capable of processing successful HTTP <code>GET</code> responses formed by a LDP server
 		that independently initiated paging, returning a page of representation instead of full resource
 		representation [[!LDP-PAGING]].
 	</h2>
@@ -1209,7 +1210,7 @@
 	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 an LDPC MAY have an <code>rdf:type</code>
+	<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>.
@@ -1244,7 +1245,7 @@
 		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 an LDPC, 
+		to influence the set of triples returned in representations of a LDPC, 
 		particularly for large LDPCs.  See also [[LDP-PAGING]].
 	</h2></section>
 	
@@ -1264,7 +1265,7 @@
 	<p>
 		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, 
+		When a LDP server supports this method, 
 		this specification imposes the following new requirements for LDPCs.
 	</p>
 		
@@ -1281,7 +1282,7 @@
 	</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 an LDPC results in the creation of an LDPR, a 
+		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 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.
@@ -1292,7 +1293,7 @@
 	<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 an LDPC supports this behavior.
+		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
@@ -1300,11 +1301,11 @@
 		If any requested interaction 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 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.
+	<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.
 	(even if the content contains an <code>rdf:type</code> triple indicating a type of LDPC).</li>
-	<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>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>
@@ -1353,7 +1354,7 @@
 	<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 an LDPC server creates this associated <a title="Linked Data Platform RDF Source">LDP-RS</a> it MUST indicate
+	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 on the HTTP response using the HTTP <code>Link</code> response header with link relation <code>describedby</code>
 	and <code>href</code> to be the URI of the associated LDP-RS resource [[!RFC5988]].
 	</h2></section><!-- Was 5.4.12 / #ldpc-5_4_12 -->
@@ -1364,7 +1365,7 @@
 		LDP only specifies the use of <code>POST</code> for the purpose of creating new resources, but a server
 		can accept <code>POST</code> requests with other semantics.  
 		While "POST to create" is a common interaction pattern, LDP clients are not guaranteed, even when 
-		making requests to an LDP server, that every successful <code>POST</code> request will result in the 
+		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
@@ -1381,7 +1382,7 @@
 	<p>
 		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, 
+		When a LDP server supports this method, 
 		this specification imposes the following new requirements for LDPCs.
 	</p>
 		
@@ -1390,7 +1391,7 @@
 		<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 an LDPC’s <a>containment triples</a>; 
+	<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 -->
@@ -1406,12 +1407,12 @@
 	<p>
 		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, 
+		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 an LDPR identified by the object of a <a title="containment triples">containment triple</a> is deleted, the LDPC server MUST also remove 
+		When a LDPR identified by the object of a <a title="containment triples">containment triple</a> is deleted, the LDPC server MUST also remove 
 		the LDPR from the containing LDPC by removing the corresponding containment triple.
 	</h2>
 	<blockquote>
@@ -1423,7 +1424,7 @@
 	</section><!-- Was 5.6.1 / #ldpc-5_6_1 -->
 	
 	<section id="ldpc-del-contremovescontres"><h2 class="normal">
-	When an LDPR identified by the object of a <a title="containment triples">containment triple</a> is deleted, and the LDPC server 
+	When a LDPR identified by the object of a <a title="containment triples">containment triple</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 remove the associated LDP-RS it created.
 	</h2></section><!-- Was 5.6.4 / #ldpc-5_6_4 -->
 	
@@ -1445,7 +1446,7 @@
 	<p>
 		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, 
+		When a LDP server supports this method, 
 		this specification imposes the following new requirements for LDPCs.
 	</p>
 		
@@ -1457,7 +1458,7 @@
 	<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 an LDPC's <a title="Empty-container triples">empty-container triples</a>.
+		updating a LDPC's <a title="Empty-container triples">empty-container triples</a>.
 	</h2></section><!-- Was 5.8.1 / #ldpc-5_8_1 -->
 </section>
 
@@ -1466,12 +1467,12 @@
 	<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for LDPCs.
 		</p>
 
-	<section id="ldpc-options-linkmetahdr"><h2 class="normal">When an LDPC server creates an 
+	<section id="ldpc-options-linkmetahdr"><h2 class="normal">When a LDPC server creates an 
 	<a title="Linked Data Platform Non-RDF Source">LDP-NR</a> (for example, one whose 
 	representation was HTTP <code>POST</code>ed to the LDPC) 
 	the LDP server might create an associated <a title="Linked Data Platform RDF Source">LDP-RS</a> 
 	to contain data about the non-LDPR (see <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>).  
-	For LDP-NRs that have this associated LDP-RS, an LDPC server MUST provide an HTTP <code>Link</code>
+	For LDP-NRs that have this associated LDP-RS, a LDPC server MUST provide an HTTP <code>Link</code>
 	header whose target URI is the associated LDP-RS, and whose link relation type is 
 	<code>describedby</code> [[!RFC5988]].
 	</h2></section><!-- Was 5.9.2 / #ldpc-5_9_2 -->
@@ -1520,9 +1521,9 @@
 
 <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>
+	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 an LDPC includes information about which
+	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
@@ -1590,7 +1591,7 @@
 <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 an LDPC results in the creation of an LDPR, 
+		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 
@@ -1602,7 +1603,7 @@
 <h2>HTTP DELETE</h2>
 
 	<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
+		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>
@@ -1691,7 +1692,7 @@
 	
 	<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 an LDPC server might delete a resource and then later re-use the
+		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.
@@ -1749,12 +1750,12 @@
 <h2>RDF</h2>
 Reference: [[rdf11-concepts]]
 
-	<section id="ldp-rdfconcepts-extra-triples-any"><h2 class="normal">The state of an LDPR 
+	<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 an LDPR need not be the subject of any of its triples.
+		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 an LDPC
+	<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
@@ -1763,7 +1764,7 @@
 		on each member individually.
 	</h2></section>
 	
-	<section id="ldp-rdfconcepts-extra-triples-types"><h2 class="normal">The state of an LDPR can have more than one
+	<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>
 
@@ -1879,7 +1880,7 @@
 <h3>Specification</h3>
 
 	<section id="prefer-include"><h2 class="normal">
-		The <code>include</code> hint defines a subset of an LDPR's content that a client
+		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
@@ -1902,7 +1903,7 @@
 	</section>
 
 	<section id="prefer-omit"><h2 class="normal">
-		The <code>omit</code> hint defines a subset of an LDPR's content that a client
+		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