Consider changing `AccessNeed` and related concepts with `Purpose`

Hi. I realise this is a big ask and its probably quite late given the implementation progress, but IMHO this is an important consideration.

The term AccessNeed, describe through AccessNeedDescription, as "specific explanation of why that data type is being requested" should be replaced with Purpose for the following reasons:

1. AccessNeed is non-normative, does not align with legal or social terminology, and is not expressive enough to represent what it is intended to exhibit (more on this part later).
2. Purpose is normative, well defined and understood both legally and socially, and is IMHO more intuitive for everybody.
3. Access only refers to one form of action or processing over data i.e. to access, which can be stretched in definition to mean at most 'use'. It does not represent other possible actions and their nuances and differences, such as collect, use, aggregate, obtain (from elsewhere), share, retain, store (on pod), store (outside pod), erase. For any of these actions, the intended term should be a description of the 'purpose' explaining why they are being performed. For example, "I want to do X with your Y" is a description of action X over data Y, but does not explain its purpose, which can be to "provide you the Projectron service".
4. Need is typically interpreted to refer to the necessity - most commonly as an obligation. For exampe, I need water vs I want water have two subtle but important nuances - and even if we might not care about them in daily langauge, they have important considerations in semantics and law, where the interpretation may not mean the same thing as we want to. Purpose presents a better abstraction of explaining the purpose of needs and wants over some data.
5. Necessity may be associated with more than Access - for example, some data may be optional (e.g. name is optional while providing email), or some action may be optional (e.g. storing a copy on your pod for generated analytics), or some purpose may be optional (e.g. we can optionally use the location data to personalise your language interface).
6. Access related terms such as Grant and Receipt can be misinterpreted (whether intentional or unintentionally) as only referring to 'access' or 'use' as it relates to the first action. For example, a Company F 'needs' to 'access' the data to provide a service X. After the provision of that service X, it wants to perform some profiling using the data collected, but doesn't tell you because it does not need to 'access' that data from the pod - it already has it. The term Purpose does not have any scope for such shenanigans.
7. Purpose is well known and allows taking advantage of legal obligations such as what consitutes a valid 'purpose' as well as requiring separate permissions for separate purposes, which creates legal certainty in how to interpret use of data by apps and avoids any ambiguity associated with terminology. For example, GDPR uses Purpose predominantly, and so do all other laws around the world, including the recently proposed federal American Data Privacy and Protection Act.

Start by reviewing the specification's current definitions and uses of AccessNeed, AccessNeedDescription, Grant, and Receipt. Compare those concepts with the proposed Purpose terminology and clarify the intended scope before changing anything; done requires a decided terminology model and corresponding specification updates.