Review for W3C POE Deliverables - Information Model

Hi everyone,

And here's a new set of comments after https://lists.w3.org/Archives/Public/public-poe-comments/2017Apr/0005.html and https://lists.w3.org/Archives/Public/public-poe-comments/2017Apr/0006.html.
This time it's only on the POE Information Model at https://www.w3.org/TR/2017/WD-odrl-model-20170223/
And I'm not representing RightsStatements.org nor W3C DQV here.

I hope I've not misunderstood too many things while doing this. It's been quite a long work of reading and commenting... Note also that while I've tried to review my own comments before sending, I didn't have too much time. And I won't have more time for this in the coming days.

Best,

Antoine


1. I'd like to make a suggestion regarding possible extensions of the (SKOS) concept schemes defined in POE, such as the Actions one.
The POE model foresees that there can be new actions, which from the perspective of POE are not supported, and thus captured as ‘undefined’. This is apparently being debated, as reflected in https://github.com/w3c/poe/issues/105. But can’t a simpler, more flexible approach be taken, which would avoid the awkwardness of this ‘undefined’? I’m thinking of the Web Annotation mechanism to represent annotation motivations: https://www.w3.org/TR/annotation-vocab/#extending-motivations .
The rule there is that WA introduces a set of basic Motivations (like POE introduced a set of basic Actions) and WA recommends to extend this set by defining new Motivations as specializations of existing ones, using skos:broader.
The actions already present in POE seem to cover a wide ground already, it seems that such approach of “extension-by-specialization” would be possible.


2. I was a bit surprised the detail of the mechanism for specifying constraints (in section 3.8 and others). There are many, many hidden semantics beyond the use of simple resource from that mechanisms. For example, when odrl:event is used in a constraint, the value that should actually be checked is the end time of that event. And this sort of interpretation varies from one resource/operand to the other. E.g. for odrl:purpose, there’s no such implicit indirection. I think I can personally live with it, but that’s maybe because I don’t have to implement a constraint processor for now ;-) I’m really wondering whether this mechanism would be considered good, compared to other mechanisms such as SWRL or perhaps SHACL. Is there any POE constraint processing systems implemented, or being implemented? If not, then I would suggest to put constraints in their own separate POE ‘module’ (a separate document and vocabulary), so that they don’t stand in the path of moving the basic POE model towa
rds Recommendation status.


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.


4. Simple editorial suggestions:

- in 3.1 it would be good if the list of attributes could refer to the various sections that follow. And that these sections would be given in the order of the list! Otherwise the list’s explanations read quite rough.

- the order of subsections in 3(.1) seems quite unnatural. I don’t understand why I had to read about the intricacies of policy composition, conflict strategy or undefined actions before reading about the basics of rules and assets. This would for example caused me to ponder why ‘permission’ is used as a property in the JSON listings of example 1 and below, while it had been only refered to as a Class in the text so far.
Going through the model via a ‘depth-first’ approach for each class has some advantages, but it does really prevent a newcomer to get the basics right. Maybe a first section could explain the basic classes and relationships between them, and a second question would tackle the rest of complex issues, class by class. Such organization would also allow to put some debated constructs (Undefined Actions in 3.1.4) more towards at the end of the document.

- in 3.1.1 the sentence with ’irreducible’ could mention that the notion is exemplified afterwards. Since it’s in italics without explanation, it made me feel that I should understand it, while it had not been defined. And ‘unambiguous’ could be removed, as it’s not defined or exemplified anywhere, as far as I can tell.

- why is dct:isReplacedBy in bold in “If a Policy contains the dc:isReplacedBy property” in 3.1.2? It’s not in bold in the bullet list above.

- in 3.1.3 “the print Action is a subset of the use Action”. This is confusing when one thinks of RDF/OWL class/sub-class relationships with set semantics. print and use are not classes. It would be more exact to write “the print Action is a specialization of the use Action”

- identifiers of sections in the HTML document structure should be checked. E.g. 3.1.5 has ‘inhertiance’ as id.

- in 3.3.1 “additiion” -> “addition”

- in 3.4 “An ODRL policy expression MAY contain at least one Permission.” is not really informative from a semantic perspective. Except for correcting the wrong understanding that can be caused by the sentence just before it (see comment above). But if that sentence is fixed, then this one could be removed.

- in 3.6 “this is used to refer the same Duty to multiple Permission entities.” -> “this is used to refer from a Duty to multiple Permission entities.” ?

- in 3.8 “EU dollars”???

Received on Saturday, 29 April 2017 23:48:11 UTC