Review for W3C POE Deliverables - Vocabulary & Expression

Dear all,

And here is my last piece of feedback for this round.
I must say I had to stop my writing of comments at some level in the POE Vocabulary (after section 4.12). I have more, but this was taking me too much time. And I don’t know what you’ll make of all the comments made so far... But if you’re interested, I have more and keep it for a slightly later time.


General comments:

- I think it is not really helpful to have two different Actions vocabularies (one for P/O and the other one for Duties). This sort of ontological commitment can even be dangerous. Why can’t an action now earmarked for P/Os, say Distribute, be used as a Duty? One could imagine that a Party gets the permission to do things with an Asset, on the basis that this party takes care of distributing it. A bit like the copyright agreement between researchers and journal publishers, where the latter commit to employ their distribution network to promote the publish papers.
In fact, while the wording of Action definitions is very much focused on this division (e.g. “The Assigner permits/prohibits the Assignees to distribute the Asset.” at https://www.w3.org/TR/odrl-vocab/#term-distribute) it is not enforced in the vocabulary by creating two distinct OWL ontologies or SKOS concept schemes. It is also not motivated (and maybe not even mentioned?) in the Information Model at https://w3c.github.io/poe/model/#action. My recommendation would be to remove any hint of this distinction from the Vocabulary document (structure of sections, wording of definitions, and separate Action boxes in figure 1)

- often, the relation between POE and SKOS, wrt. the notions of ‘concepts’ and ‘vocabularies’, was not clear to me. Section 4 present a number of ‘vocabularies of applicable terms’. Some of them consist of instances of skos:Concept, some of them of instances of owl:Thing, some of them extend/refine existing POE classes by sub-classing (e.g., the Policy Types). Also, others are mentioned as concepts (Rule at https://www.w3.org/TR/odrl-vocab/#term-Rule) but they’re not defined as such. Are all these different ways necessary? Is typing anything as an owl:Thing any helpful actually?
Further, when looking at the ODRL Turtle serialization, I see instances of skos:Concept (:use), instances of skos:ConceptScheme (:actions), but no skos:inScheme statement to relate them. Some groupings of concepts are defined as skos:Collection, while there could be defined as (small) ConceptScheme, like http://www.w3.org/ns/odrl/2/#policyTypes .
Perhaps a general examination of all this is desirable. Especially if concept schemes could play a bigger role in the future (see my comment about adapting for POE the approach of Web Annotation for extending its default sets of concepts, in https://lists.w3.org/Archives/Public/public-poe-comments/2017Apr/0007.html). NB: the extension pattern used by WA is applicable to OWL classes like Policy type, so I think keeping ‘vocabularies’ of subclasses of existing POE classes is ok, it’s just that they should probably be flagged as different kind of vocabularies to clarify the situation.
Finally the Turtle serialization uses skos:broaderTransitive for cases where skos:broader should probably be used. See https://www.w3.org/TR/skos-primer/#sectransitivebroader “one can interpret skos:broader statements as explicitly asserted direct parent links, while skos:broaderTransitive is used to reflect more-general (and possibly indirect) ancestor relationships.”

- 4.1.1 target, assigner, assignee aren’t among the properties for Policy? And (as one example), in 4.8.1 odrl:target is mentioned to have only Rule as domain? The POE information model mentions that these can appear at the Policy level (https://www.w3.org/TR/odrl-model/#composition, for example, example 6)

- about odrl:relation: in the end, is it worth having an abstract property when it has only two concrete sub-properties (odrl:output and odrl:target)? And when it has such an abstract name - and which conflicts with many general properties with similar names but an actually more generic meaning, like rdfs:property and dc:relation.

- 4.9.3 All, All2ndConnections, AllConnections and AllGroups are not defined in the information model. Then I realized that the information model itself in 3.3.2 (https://www.w3.org/TR/odrl-model/#party-scope) is quite strange. It says “The scope attribute SHOULD take one of the following values: [individual and group]” and then “Other URI values for the scope attribute SHOULD be defined in the ODRL vocabulary [vocab-odrl] and ODRL Profiles.”, which is a bit contradictory.

- what’s the difference between odrl:All and odrl:Group?

- it seems that the various types of scopes could be arranged as a SKOS concept scheme, with skos:broader links between e.g. odrl:All2ndConnections and odrl:Group. This would better reflect your notices ‘Note that “group” scope is also assumed’.


Remarks on the naming of POE elements:

- it’s really confusing to have classes and properties that have the same identifier, the only difference being capitalization, e.g. ‘Permission’ and ‘permissions’. I know you may inherit this from earlier ODRL work, but as POE is not yet a Recommendation, it would be useful to question that. Having the property identifier for “Has Permission” be ‘hasPermission’, ‘hasPermissions’ or ‘permissions’ would already be way clearer for implementers.

- for the possible values of odrl:conflict attribute, why is one abbreviated (‘perm’) but not the others (‘prohibit’, ‘invalid’)? Homogenising the way they are identified would be good.

- the name of odrl:inheritRelation is quite confusing. It sounds as if it denotes the inheritance relation between policies. But this is the role played by odrl:inheritFrom. If the role of odrl:inheritRelation is to link to some “context of inheritance” (https://www.w3.org/TR/odrl-model/#inhertiance), why not naming it odrl:inheritanceContext?

- some sub-classes of Policy have strange names, like Privacy. This name is shorter than PrivacyPolicy, indeed, but it’s quite confusing as the bare word ‘privacy’ means something completely different from a policy. Compare with Agreement and Offer, which sound much better as direct sub-class of Policy: ’agreement’ and ‘offer’ are what the policy really is; ‘privacy’ is rather the object of the policy. See how ‘privacy’ could also be used in new ‘privacy agreement’ or ‘privacy offer’ kind of policies.

- ‘set’ is also strange. It’s not wrong, but the definition shows a problem: “Policy expression that consists of entities from the complete model.” This can be said of any POE Policy, no? ‘Open Set’ or ‘Open Policy’ would reflect better what is in the note in 4.2.6. Or maybe ‘Policy prototype’ or ‘Abstract Policy’?

- why using something as vague as ‘term’ for ‘ConflictTerm’ while the definition and note in 4.3.1 suggest that ConflictStrategy would be both more precise and fit to the semantics?

- one would expect that odrl:conflict relates a Policy to some sort of conflict (4.3.2). But the definition mentions ‘conflict-resolution mechanism’ which is not the same thing. The label (‘Handle Policy Conflicts’) sounds like a different thing altogether. Still it seems like using the definition term or the label for minting a new identifier would help implementers.
Same for odrl:undefined (4.4.2). At this point I must say that I’m not nitpicking for the fun of it. The fact that POE contains so many of these identifiers that very approximately represent the meaning of the class/property (one could even call them ‘false friends’) caused me to lose a lot of time figuring out the POE model itself.

- is there any reason that ‘inheritFrom’ is not ‘inheritsFrom’?

- why do identifiers of scopes (which are instances of classes) start with upper-case, that is, they use the usual convention for naming classes?

- why isn’t odrl:AllConnections named odrl:AllFirstLevelConnection, just the way odrl:All2ndConnections is named... (and then why isn’t it odrl:All2ndLevelConnections?). Why odrl:AllGroups and not odrl:AllGroupConnections? A bit of homogenisation here would be really good.


Editorial:

- about Figure 1
-- why does it include two ’is’ and ‘has’ arrows? These are not elements of the POE vocabulary, nor of RDFS/OWL.
-- it’s confusing to seek to represent both sub-class and part-of relation between Rule and its specialization as one arrow.
-- Profiles are not in the figure

- using the word ‘concept’ for section titles like ‘Policy concepts’ or ‘Asset concepts’ doesn’t help the reader, when there are resources in the POE model that are truly of type (SKOS) Concept and are distinct from the classes and properties listed in these ‘concepts section’.

- I think the document should present all broader/narrower relationship between SKOS concepts (e.g. Actions) in both directions. This would help readers handle sentences like in the Model’s 3.1.3 “the print Action is a subset of the use Action” (https://www.w3.org/TR/odrl-model/#conflict) that is not reflected at https://www.w3.org/TR/odrl-vocab/#term-print. I mean, the broader action of odrl:print (odrl:present) that has odrl:use as its own broader action is not even presented for odrl:print’s section.

- “Instances of UndefinedTerm describe policies for processing unsupported actions.” (https://www.w3.org/TR/odrl-vocab/#undefinedConcepts). Is ‘policies’ the right word here?

- in 4.1.2 and others, some sub-properties are not mentioned as possible properties (for 4.1.2, odrl:assigner and odrl:assignee; for 4.9.1, the specializations of odrl:function). According to POE’s formal semantics, it is ok to mention only odrl:relation, as done now in 4.1.2. But for helping implementers and better reflect the information model, I think it would be useful to mention the specializations (especially the specializations of abstract properties)

- it would be better if the order of inherited properties (e.g. in 4.2.1, Agreement) would match the order in which they are given in the super-class (4.1.1, Policy)

- why is 4.7.2 (Relation) specifically in Asset concepts? Its subjects are not instances of odrl:Asset.

- in 4.10.1. Why is there a ‘must be supported’ in note? It’s not very informative. In fact it could apply to many other POE constructs, no? Also sometimes it’s ‘must’ and other times “MUST”.

Received on Sunday, 30 April 2017 00:22:16 UTC