--- a/ldp-primer/ldp-primer.html	Mon Jun 02 09:12:44 2014 +0200
+++ b/ldp-primer/ldp-primer.html	Mon Jun 02 10:16:42 2014 +0200
@@ -664,13 +664,13 @@
    </pre>
    
    <p class="issue">Does a delete need to show the type of the deleted resource? Or the etag?</p>
-     <p> Once the document is deleted, the containment triple will be removed from the container.
- For example, after the deleting the resource the container representation will be as the following.
+     <p>As well as deleting the resource, the server removes the containment triple from the container.
+ So a GET request on the container will return a graph isomorphic to the one described in the following representation:
  </p>
      
      <pre title="Container representation after resource deletion" class="example" data-include='bc_after_del.txt' data-oninclude='fixCode'></pre> 
      
-     <p> For any subsequent request on the resource after the deletion, the server will respond with the appropriate HTTP response code.
+     <p> For any subsequent request on the deleted resource, the server will respond with the appropriate HTTP response code.
  </p>
       <pre title="Request - after deletion" class="example">
     GET /alice/avatar HTTP/1.1
@@ -686,7 +686,7 @@
     <section>
       <h3 id="meta-structure">Structural Manipulation (Child Containers)</h3>
       <p>In order for the client to introduce hierachy to the management of documents, the document store allows creation of documents which are containers.
- That enables Alice can to create a container hierarchy to organise her documents.
+ That enables Alice to create a container hierarchy to organise her documents.
  This can be done by POSTing (a child) container representation to a (parent) container.
  This enables Alice to create a child container which she intends to use for image storage.
       </p>
@@ -720,7 +720,7 @@
     <p>The previous section provided practical examples of basic LDP interactions using LDP Basic Containers.
  One of the limitations of LDP Basic Containers is that a fixed LDP vocabulary is used to assert the relations between a container and its contained resources.
  However, some scenarios require domain specific vocabulary to be used to list the members of a container.
- For example, an application which already used Linked Data and its own vocabulary may like continue using the same vocabulary when migrating to LDP protocol.
+ For example, an application which already used Linked Data and its own vocabulary may like to continue using the same vocabulary when migrating to LDP protocol.
  LDP Direct containers introduce the concept of membership triples allowing the flexibility to define the form of the membership.
  One of these flexibility points is the ability to select the predicate of the membership triple which can be from the the domain-specific vocabulary.
  This is done using the ldp:hasMemberRelation or ldp:isMemberOfRelation predicate of the Direct Containers.</p>
@@ -729,7 +729,7 @@
  This allows to define relationship between any other information resource or non-information resource (real world thing) by defining the membership constant subject or the object URI of the membership triples using ldp:membershipResource predicate of the Direct Container.
  The usage of the ldp:hasMemberRelation predicate as well as the ldp:membershipResource will be explained in the following examples.
  </p>
-
+ <p class="issue">Explain why this can't be done by PATCHing the other resource when needed.</p>
     <p class="note">For more information on information resources (documents) vs real world entities (things) separation please refer to <a href="http://www.w3.org/TR/webarch/#id-resources">Web Arch (Section 2.2. URI/Resource Relationships) </a>, , <a href="http://www.w3.org/TR/cooluris/#semweb">Cool URIs (Section 3. URIs for Real-World Objects)</a>, <a href="http://www.w3.org/TR/urls-in-data/#landing-pages">URLs in Data (Section 3. Landing Pages and Records)</a>.</p>
 
     <p>
@@ -737,7 +737,6 @@
  Bug Tracker application records the bugs of several products allowing reporting, updating and deleting bugs and products.
  In contrast to the online document store example, the bug tracker wants to use a simple domain vocabulary, e.g. has_bug, to express membership relationships in the containers. 
 LDP provides the additional interaction capability in the protocol to add the domain specific triples based on the properties defined in the LDP Direct Container.
-
     </p>
 
     <p>A RESTful API for a simple Bug Tracker system might be described as follows.</p>
@@ -830,12 +829,12 @@
       </tbody>
     </table>
     
-    <p> In the examples in this section, we will only focus on the container representation, creation and deletion of resources because that is where the Basic Containers, Direct Containers, and Indirect Containers have their differences.
+    <p> In the examples in this section, we will only focus on the container representation, creation and deletion of resources because that is where the Basic Containers, Direct Containers, and Indirect Containers differ.
  Other operations such as updating a resource will be similar to what was illustrated in the previous example.
 </p>
 
     <section id="navandret">
-      <h2>Navigation and Retreival (GET on an LDP-DC)</h2>
+      <h2>Navigation and Retrieval (GET on an LDP-DC)</h2>
 
       <p>One of the main use cases of the example bug tracker is to list of the bugs of a given product.
  Assuming that a user got a URL of a product by out of band means, she can look it up to get more information including the bugs associated with it.
@@ -946,7 +945,7 @@
  </p>
 
     <section id="navandretext">
-      <h2>Navigation and Retreival (GET on an LDP-IC) </h2>
+      <h2>Navigation and Retrieval (GET on an LDP-IC) </h2>
       
       <p> Similar to the previous LDP-DC example, first we will retrieve the representation of the LDP Indirect Container.
 </p>