UC3: fixes and add story for privacy

proposals/evaluation/uc-3-inheritance.md

@@ -83,11 +83,11 @@ If that actor makes a `GET` request to `<report.acp>` it will receive a graph is
 # Resource: </weekly-status/2021-04-28/report.acp>
 <#ac1>
   a acp:AccessControl ;
-  acp:apply </acp/research#p1> ;
-  acp:applyMembers </acp/research#p1> .
+  acp:apply </acp/research#p1> .
 ```
 
-Note that `</weekly-status/2021-04-28/report.acp>` is basically a copy of `</weekly-status/.acp>`. In the current proposal, all resources in ACP have their own associated effective Access Control Resource.
+Note that the triples in `</weekly-status/2021-04-28/report.acp>` are generated from the statements in `</weekly-status/.acp>`. 
+All resources in ACP have their own associated effective Access Control Resource.
 
 The same logic thus applies here as for access to the container. To know which credentials to present, a digital actor will need to know the contents of `</acp/research>`. But access to that is only granted to members of that research organization.
 
@@ -130,11 +130,11 @@ A unauthenticated client actor making a GET request to  `</weekly-status/2021-04
 1) `Link: </weekly-status/.acl>; rel=acl`. 
 2) `Link: </weekly-status/2021-04-28/report.acl>; rel=acl`
 
-As pointed out previously, only the controller and the resource guard can read those, all other actors (eg. Alice or Bob) need undefined out-of-band knowledge to know how to authenticate. So we are limited to the controller actor.
+As pointed out previously, only the controller and the resource guard can read those; all other actors (e.g., Alice or Bob) need undefined out-of-band knowledge to know how to authenticate. We are therefore limited to the controller actor.
 
-In (1) the actor whose Principal is the Controller, will be able to determine using inheritance what credentials it can use. 
+In (1), the actor whose Principal is the Controller, will be able to determine from the `acl:default` rules what credentials it can use. 
 
-In (2) the resource may either be created already, in which case the default rule of `</weekly-status/.acl>` does not apply, or it is not created yet, and the default applies but the client cannot know what the default acl is.
+In (2), the `acl` resource may either already be created, in which case the default rule of `</weekly-status/.acl>` does not apply, or it has not yet been created, so the default applies, but the client cannot know what the default `acl` is.
 
 ### WAC+ acls on acls or extension to modes
 
@@ -213,7 +213,7 @@ Given that out of band knowledge, the actor wanting to give access permissions t
 
 As soon as this ACL is created, the old ACL will no longer be authoritative. 
 
-The problem here is that we need to copy many of the statements from `</weekly-status/.acl>` in the new acl, which means that changes to the root acl do not get propagated, and the more changes there are, the more places will need to be edited to make any future changes.
+The problem here is that we need to copy many of the statements from `</weekly-status/.acl>` into the new acl; this means that subsequent changes to the root acl will not get automatically propagated, and the more resources there are, the more places will need to be edited to carry through any future changes made to the root acl.
 
 ### WAC+ relaxing acl:default
 
@@ -240,7 +240,7 @@ However, if WAC's use of `acl:default` were to be relaxed as described in [issue
 
 See also: https://github.com/solid/authorization-panel/pull/216#discussion_r665230245
 
-As a result the acl's for all the resources could be pointing to the root acl. But doing that will tend to place all the ACLs on a Pod together, giving anyone with access to that acl, visibility on all the access control rules of the Pod.
+As a result the ACLs for all the resources could be pointing to the root ACL. But doing that will tend to place all the ACLs on a Pod together, giving anyone with access to that ACL, visibility on all the access control rules of the Pod.
 
 ### WAC+ ac:imports +acr 
 
@@ -250,7 +250,7 @@ This makes it easy for a client to find out where the effective ACR is.
 We keep `wac:default` working as currently specified. Note, that this proposal is also compatible with more flexible acl:defaults, and indeed with the use of general `wac:accessToClass` descriptions, such as classes of resources with a specific tag.
 
 An unauthenticated client that makes a `GET` on `</weekly-status/2021-04-28/>` will receives a `401` with a `Link` to `</weekly-status/2021-04-28/.acl>`. 
-The  container when newly created would contain the following triple 
+The  container when newly created would contain the following triple:
 
 ```Turtle
 # Resource: </weekly-status/2021-04-28/.ac>
@@ -260,7 +260,7 @@ The  container when newly created would contain the following triple
 
 This allows any client (including the controller's client) to find the default rule by following their nose.
 
-The current WAC inheritance algorithm, states that the inheritance no longer works for a resource that has an ACL. But that does not stop inherticance from from being explicitly defined using `ac:imports`.
+The current WAC inheritance algorithm states that the automatic inheritance no longer has effect for a resource that has an ACL, but that does not stop inheritance from from being explicitly defined using `ac:imports`.
 
 The Actor for the Principal in control of the container can then  `PUT` the following rules to allow Carol to read and write to those containers: