Re: [poe] IM: upgrade Short-cut Instances of Classes in Policy Rule Composition to a section

@riannella thanks for following the first suggestion.

re the second: my general suggested change of the narrative is that the IM only talks about short-cuts where they become effective and that's at the Rule level.
In details:
* [2.7.1 Compact Policy](http://w3c.github.io/poe/model/#composition-compact) currently tells "An ODRL Policy MAY also relate to multiple Assets, Parties, and Actions at the Policy level (not just within a specific Rule)." - which is a contradiction to "... must not be considered as property of the Policy Class." 
* The processing model at the bottom of 2.7.1. talks about how to apply properties at the Policy level to Rules of the Policy. I suggest to replace this by a model in which the Permissions and Prohibitions bring together properties at the local level with properties at the Policy level (see my intro above) - simply said: the model should advise a Rule checking "where are the target(s), assigner(s) ... relevant for me".
* I suggest to **replace the first para by the wording below**:
A target or assigner or assigner or action or duty property of a Permission or Prohibition of a Policy may be shared across multiple rules and in this case such properties may be applied formally as property of the Policy, but not semantically. This is a _short-cut_ method to support more **compact** serialisations. 
The processing model for expanding short-cuts used by Permissions or Prohibitions is:
  * For Permissions: a target or assigner or assigner or action or duty property applying to the Permission is a property of the Permission or a formal property of the Policy. Any of these shared formal properties of a Policy is semantically the same as a property of the Permission.
  * For Prohibitions: a target or assigner or assigner or action _or duty (??)_ property applying to the Prohibition is a property of the Prohibition or a formal property of the Policy. Any of these shared formal properties of a Policy is semantically the same as a property of the Prohibition.
* {para 1 continued, unindented}
Further follow the processing model to create _atomic_ Rules in the Policy (defined in the previous section).
It is RECOMMENDED that compact ODRL Policies be expanded to atomic Policies when being processed for conformance or exchanged for interoperability, to reflect the normative ODRL Information Model.
_
The example below shows such shared properties applied to a Policy: (... example 26)
* Note on "or duty (??)" in the Prohibition rule: this will depend on the outcome of the discussion about the use of duty properties at the policy level (#162). By my current overview a Duty at the Policy-level is should be allowed only for the Set subclass. Will this trigger the same processing model as for Permission and Duty?
* {wording above Example 27} The example below shows how these shared properties are expanded to the Permissions of the Policy following the rule above:
* No wording below Example 27



-- 
GitHub Notification of comment by nitmws
Please view or discuss this issue at https://github.com/w3c/poe/issues/202#issuecomment-312199543 using your GitHub account

Received on Friday, 30 June 2017 07:45:44 UTC