--- a/ldp-bp/ldp-bp.html	Tue Jul 16 10:32:11 2013 -0400
+++ b/ldp-bp/ldp-bp.html	Wed Jul 17 12:55:01 2013 -0500
@@ -191,7 +191,7 @@
 	
 				<h3>Prerequisites and Assumptions</h3>
 	
-				<p class="note">TO DO: Consider inserting some prereqs and
+				<p class="note">TO DO: Consider inserting some prerequisites and
 					assumptions here that help to clarify the audience, level of
 					understanding expected from that audience. Perhaps, provide an
 					example learning path for the uninitiated.</p>
@@ -342,13 +342,13 @@
 
 						<dt>Relative URIs can make resources more portable.</dt>
 						<dd>When information which is already known from the context of the base 
-							resource's retrieval is ommited, there can be less information to modify when that 
+							resource's retrieval is omitted, there can be less information to modify when that 
 							information changes. This can make moving resources to new servers or to a new position in a containment hierarchy easier.</dd>
 
 						<dt>Relative URIs are convenient during development.</dt>
-						<dd>During development the scheme and network location information in a URI may either be unkown or likely to change. The commonly used 'localhost' for example, is better 
+						<dd>During development the scheme and network location information in a URI may either be unknown or likely to change. The commonly used 'localhost' for example, is better 
 							expressed by the server name or a domain name. Developers often experience less 
-							hassle by ommiting this information. Additionally, the hierarchy implied by a relative URI may be mimicked in a server file system, which can help developers 
+							hassle by omitting this information. Additionally, the hierarchy implied by a relative URI may be mimicked in a server file system, which can help developers 
 							find and work with information, even the server isn't running.</dd>
 
 						<dt>Relative URIs support arbitrary, machine-generated URIs.</dt>
@@ -359,11 +359,63 @@
 				</section>
 	
 				<section>
+					
 					<h3>Represent container membership with hierarchical URIs</h3>
-					<p>Hierarchical URIs are good for containers because they enable
-						relativizing.</p>
-					<p>Don't forget the corrorlary to this, which Henry noted and that should probably go in this guide: <a href="http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0071.html">http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0071.html</a></p>
+
+					<p>Hierarchical URIs are good for containers because they enable the use of relative URIs. They also promote easy interaction with resources that are modeled to represent parent-child relationships where the child logically belongs 
+						to the parent.</p>
+
+					<p>One example of such a model can be found in the case of the <code>oslc_cm:attachment</code> container from the vocabularies defined by the <a href="http://open-services.net/">Open Service for Lifecycle Management (OSLC)</a> community. The OSLC defines specifications and vocabularies that are well-aligned to the LDP. A resource in an OSLC compliant change management system such as an issue or bug tracker may have attachments represented by the <code>oslc_cm:attachment</code> 
+					container. The URI for such a container might be represented as follows:</p>
+
+					<p><code>http://example.com/bugs/2314/attachments/</code></p>
+
+					<p>From this URI, you can easily discern the URI of the parent resource, which holds the attachments. You can also discern the base container for other sibling resources by moving up the hierarchy, which is implied by the URI. You might also go down the hierarchy to fetch meta-data or binary content using a URI such as the following:</p>
+
+					<p><code>http://example.com/bugs/2314/attachments/1</code></p>
+
+					<p>As you can see, in addition to making the use of relative URIs possible, hierarchical URIs make interacting with resources easier because they represent the actual structure of the underlying graph.</p>
+
 				</section>
+
+
+				<section>
+
+					<!-- http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0071.html -->
+
+					<h4>Include a trailing slash in container URIs</h4>
+
+					<p>When representing container membership with hierarchical URLs, there is an advantage to including the trailing 
+						slash in the URI of a given container. Take the following container URI for example:</p>
+
+					<p><code>http://example.org/container1</code></p>
+
+					<p>It is more advantageous to use the following instead:</p>
+
+					<p><code>http://example.org/container1/</code></p>
+
+					<p>To illustrate the advantage, let's start with the following container expressed in Turtle RDF using absolute URIs:</p>
+
+					<pre title="A simple container" class='example' data-include='trailing-slash-1.ttl' data-oninclude='fixCode'></pre>
+
+					<p>Suppose now that we wish to reflect the same resource using relative URIs. If the URI of the container includes 
+						the trailing slash, we end up with a very elegant representation, as shown below.</p>
+
+					<pre title="Container URI is http://example.org/container1/" class='example' data-include='trailing-slash-2.ttl' data-oninclude='fixCode'></pre>
+
+					<p>But suppose that we ommit the trailing slash, issued an HTTP GET, and the container returned the representation 
+						shown above. This could produce a graph that is isomorphic to the following:</p>
+
+					<pre title="Container URI is http://example.org/container1" class='example' data-include='trailing-slash-3.ttl' data-oninclude='fixCode'></pre>
+
+					<p>That is not what was intended. The returned document would have to be more verbose:</p>
+
+					<pre title="Container URI is http://example.org/container1" class='example' data-include='trailing-slash-4.ttl' data-oninclude='fixCode'></pre>
+
+					<p>So, clearly, the better solution is to ensure that container URIs end with the trailing slash.</p>
+
+				</section>
+
 	
 				<section>
 					<h3>Use fragments as entity identifiers</h3>

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp-bp/trailing-slash-1.ttl	Wed Jul 17 12:55:01 2013 -0500
@@ -0,0 +1,12 @@
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<http://example.org/container1>
+   a ldp:Container;
+   dcterms:title "A very simple container";
+   rdfs:member
+      <http://example.org/container1/member1>,
+      <http://example.org/container1/member2>,
+      <http://example.org/container1/member3>.
+]]
\ No newline at end of file

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp-bp/trailing-slash-2.ttl	Wed Jul 17 12:55:01 2013 -0500
@@ -0,0 +1,7 @@
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<> a ldp:Container;
+ dcterms:title "A very simple container";
+ rdfs:member <member1>, <member2>, <member3> .
\ No newline at end of file

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp-bp/trailing-slash-3.ttl	Wed Jul 17 12:55:01 2013 -0500
@@ -0,0 +1,11 @@
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<http://example.org/container1>
+   a ldp:Container;
+   dcterms:title "A very simple container";
+   rdfs:member
+      <http://example.org/member1>,
+      <http://example.org/member2>,
+      <http://example.org/member3>.
\ No newline at end of file

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp-bp/trailing-slash-4.ttl	Wed Jul 17 12:55:01 2013 -0500
@@ -0,0 +1,7 @@
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix ldp: <http://www.w3.org/ns/ldp#>.
+
+<> a ldp:Container;
+ dcterms:title "A very simple container";
+ rdfs:member <container1/member1>, <container1/member2>, <container1/member3> .
\ No newline at end of file