--- a/ldp-ucr.html	Thu Aug 22 12:42:34 2013 +0100
+++ b/ldp-ucr.html	Thu Aug 22 15:24:25 2013 +0100
@@ -769,7 +769,7 @@
 		attachments referenced by the membership predicate
 		<tt>oslc_cm:attachment</tt>. This may be viewed as nested containment. The <tt>top-level-container</tt> contains issues, and
 		each issue is itself a container of attachments.
-		In the example, <tt>issue1234</tt> is a member of the container <tt>top-level-container</tt>. In turn, <tt>attachment324</tt> and <tt>attachment251</tt> are attachments within <tt>issue1234</tt>. Thinking of these as containers makes it easier to manage them as self-contained units.
+		In the example, <tt>issue1234</tt> is a member of the container <tt>top-level-container</tt>. In turn, <tt>attachment324</tt> and <tt>attachment251</tt> are attachments within <tt>issue1234</tt>. Treating these as containers makes it easier to manage them as self-contained units.
 	</p>
 	<pre class='example'>
 @prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@@ -788,6 +788,10 @@
       oslc_cm:attachment :attachment324, :attachment251.
 </pre>
 	</section>
+	<section>
+	<h3>Alternative scenario: Delete a container</h3>
+		If a container can be deleted, it seems natural that any contained resources and nested containers should also be deleted.
+	</section>
 	</section>
 	
 	<section>
@@ -805,22 +809,15 @@
 		container.
 	</p>
 	<ul>
-		<li>Non-duplication of resources: "Eliminate multiple
-			copies", representing resources in a single place (from <a
-			href="#story-social" title="Story Social Informatinon">#Maintaining
-				Social Contact Information</a>).
+		<li><a>NF2</a>: Non-duplication of resources: "Eliminate multiple
+			copies", representing resources in a single place (from <a>Maintaining Social Contact Information</a>).
 		</li>
-		<li>Distribution of resources: Linked data "may be stored on
-			separate servers" (from <a
-			href="#story-social" title="Story Social Informatinon">#Maintaining
-				Social Contact Information</a>).
+		<li><a>NF3</a>: Distribution of resources: Linked data "may be stored on
+			separate servers" (from <a>Maintaining Social Contact Information</a>).
 		</li>
-		<li>Consistent, global naming: Resources should be "linked to
+		<li><a>NF4</a>: Consistent, global naming: Resources should be "linked to
 			consistently, ... instead of maintaining various identifiers in
-			different formats" (from <a
-			href="#story-tracking_relationships"
-			title="Story Tracking Relationships">#Keeping Track of Personal and Business
-				Relationships</a>).
+			different formats" (from <a>Keeping Track of Personal and Business Relationships</a>).
 		</li>
 	</ul>
 	
@@ -828,8 +825,7 @@
 	<h3 id="scen-create_resource">Primary scenario: create resource</h3>
 	<p>
 		Resources begin life by being created within a container. From
-		user story, <a href="#story-social" title="Story Social Informatinon">
-		Maintaining Social Contact Information</a>, It should be
+		user story, <a>Maintaining Social Contact Information</a>, It should be
 		possible to "easily create a new contact and add it to my
 		contacts." This suggests that resource creation is closely linked
 		to the application context. The new resource is created in a
@@ -847,9 +843,9 @@
 		original design didn’t consider." The following RDF could be used
 		to describe contact information using the FOAF
 		vocabulary [[FOAF]]. A contact is represented here by a
-		foaf:PersonalProfileDocument defining a resource that can be
+		<tt>foaf:PersonalProfileDocument</tt> defining a resource that can be
 		created and updated as a single-unit, even though it may describe
-		ancillary resources, such as a foaf:Person, below.
+		ancillary resources, such as a <tt>foaf:Person</tt>, below.
 	</p>
 	<pre class='example'>
 @prefix foaf:  &lt;http://xmlns.com/foaf/0.1/&gt; .
@@ -890,14 +886,11 @@
 	<h3 id="scen-moving_contained_resources">Alternative scenario: moving
 			contained resources</h3>
 	<p>
-		Many resources may have value beyond the life of their membership
+		Resources may have value beyond the life of their membership
 		in a container. This implies methods to add references to revise
-		container membership. Cloning container members for use in other
-		containers results in duplication of information and maintenance
-		problems; web practice is to encourage the creation of one
-		resource, which may be referenced as many places as necessary. A
-		change of ownership may - or may not - imply a change of URI,
-		depending upon the specific server naming policy. While assigning a
+		container membership. 
+		A change of ownership may or may not imply a change of URI,
+		depending upon the naming policy. While assigning a
 		new URI to a resource is discouraged [[WEBARCH]], it is possible to indicate that a
 		resource has moved with an appropriate HTTP response.
 	</p>