[poe] Issue: Model clarifications marked as Needs WG Decision

riannella has just labeled an issue for https://github.com/w3c/poe as "Needs WG Decision":

== Model clarifications ==
@aisaac

3. I have some remarks/questions about the explanation of what POE elements are, which may be a bit more than editorial comments. It could be that the model is not clear, or it could be that my understanding of relationships between POE elements was hindered by editorial choices. Here’s the list of what I noticed:

- Permission, Prohibition and Duty are defined in 1.4 as ‘A set of Actions that are allowed/forbidden/obligatory’. This is easy to read, but it hides the fact that The POE ontology actually defines these classes as subclass of Rule, not Action. And in fact it just conflicts with the definition of Action in the same section: “An operation that can be allowed by Permissions, disallowed by Prohibitions, or made obligatory by Duties.” An Action is allowed by actions? No, in the model an Action is allowed by a Rule. So it would be more exact to change the definition and maybe change the identifiers and labels of these classes, to “PermissionRule”, “ProhibitionRule” and “DutyRule”.

- section 3.1 (and probably others afterward, like the bullet list for the Constraint entity in 3.8) use the notion of reference in a way that is quite confusing wrt. what happens concretely in POE. A resource doesn’t really ‘refer to a UID’ when this ID is the basic identifier of the resource. If I’m right, then the wording could be more direct simpler, e.g. ‘have a UID identifier’ instead of ‘refer to the uid identification of the Policy entity’. And ‘have an X attribute’ instead of ‘refer to the X attribute’.

- in fig 1, “Relation”, “Inheritance” and “Role” are represented by boxes, which lets one think they are ‘reified’ (following the n-ary relationship pattern at https://www.w3.org/TR/swbp-n-aryRelations/). Which is not the case: these are simple binary relationships represented with RDF properties. Section 3.2.1 says that “The Relation entity is an association class” but this is contradicted in the same section by the note that mentions “a sub-property of the relation property”. Which of these characterisations is the right one? Can’t the Information Model reuse the simple wording of 4.7.2 in the POE vocabulary (“Relation is an abstract property” https://www.w3.org/TR/odrl-vocab/#term-relation)?
The same remark applies when Role is defined as “an association class” or an “entity” (in 3.3.1).

- ‘Policy Composition” in 3.1.1 is misleading. This is not about composition of policies, it’s about composition of elements within a policy.

- in 3.1.3 it is said that conflicts may arise between Permissions and Prohibitions. Not with Duties? One could easily imagine duty-related conflicts.

- in 3.1.5, what is ‘state information’ for policies?

- The Scopes remain mysterious to me after reading section 3.2.2 and 3.3.2.
In example 17 JPEG is given as an example of scope, but what exactly is intended here? When one says that a catalogue mentioned as Asset has the JPEG format as scope, does it mean that the catalogue is already made of JPEG files, or is it that the policy should target only the sub-set of JPEG files in the catalogue?
In 3.3.2 the examples of scope again are ambiguous on whether it’s about ‘additional metadata for an asset/party’ (i.e. knowing that a Party is a group) or ‘modifying what is meant by the asset/party’ (selecting the “18+” in a group).
Maybe more concrete use cases would help. The only occurrence of ‘scope’ in the POE Use Cases (https://www.w3.org/TR/2017/WD-poe-ucr-20170223/#POE.UC.21) doesn’t say much to me.
Finally, if scopes can be about changing what is meant by the Asset or the Party, this seems quite dangerous to to it while keeping the original identifier for the Party/Asset. When gathering all the facts for that URI across different policies, this may lead to unwanted side-effects. Why not create new URIs for the Asset/Party with altered scope? Using the faculty example, that would mint minting a URI for the faculty staff among users, rather than hijacking the URI for all users. Same for selecting adult among friends in example 19. Why not minting http://example.com/user44/friends/Over18 or using a blank node?
When POE wants to alter a Policy, it does recommends the creation of a new one, probably with an odrl:inheritFrom between them, doesn’t it? The new URI for the altered Asset/Party (or blank node) could still refer to the original one (via something like odrl:inheritFrom) and to the scope itself (“18+” can still be an attribute of the new URI). This would mean moving to adopting the pattern of ‘selector’ as used in Web Annotation (https://www.w3.org/TR/annotation-model/#selectors).

- in 3.3 I don’t understand why a lot of the wording refer to function being a reference “from the Party” (“The Party entity MUST refer to the function”). “The Role entity has the following attributes” is also misleading (see previous comments on associations)...
It’s not the Party that specifies the function. It is the Policy/Rule that involves the Party that defines its function. In other terms, the function is not essential to the Party itself. So it makes quite some sense to find the function represented as it is in example 18, i.e. as attributes of the permission (assigner, assignee). But why all the confusing wording before? Am I missing anything?

- in 3.4. The wording with “The Permission entity”, especially in “The Permission entity specifies the Actions”, hints that there is only one permission per policy, which refers to all the actions allowed. Is it really the case in the abstract Information Model? In the same section one can read “An ODRL policy MAY contain at least one permission”, and indeed in the RDF serialization there can be several instances of the Permission class attached to a policy. So if there can be several permissions then nearly all occurrences of “The permission” should be changed into “a permission”. And “The Permission entity specifies the Actions” into “A Permission entity specifies Actions”.
A similar comment applies to section 3.5 on Prohibition and 3.6 on Action. Basically to all the wording that hints at the existence of cardinality constraints, which are not true in reality.

- in 3.6 “Other role function values for Party MAY be used.” Which ones? A couple of examples could be useful.

- in 3.8 there is no rational given for rightOperandReference. One may think it’s perfectly fine to use rightOperand both for literal values and URIs, directly. Why wasn’t it the case? And why do example of right operand with URIs not using rightOperandReference, like https://www.iso.org/obp/ui/#iso:code:3166:IT in example 25?

- for examples 12, 13 and 14, is it possible to have a bit more motivation (or a use case) for the inheritance of target assets for policies? The idea that policy inheritance would be used to ‘stack’ targets seems a bit strange. The case for stacking permissions, obligation and duties, or assignees, seem much stronger. I’m definitely not an expert, so I may miss something obvious. I thought I’d flag this remark, in case.


See https://github.com/w3c/poe/issues/162

Received on Wednesday, 28 June 2017 02:53:33 UTC