Vocab Editorial

[riannella]

@aisaac

• 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”.

[riannella]

1 - The figure has now been updated (based on the changes to the IM figure)

2 - Removed "Concepts" from section headings

3 - Updated script to also add "broader terms"

4 - Fixed

5 - Have added domain of Rule to assignee, assigner

6 - We can't change that easily (unless we start hacking http://librdf.org/raptor/rapper.html)
Suggest we leave it.

7 - True, but relation's range is Asset (in this case) Like function and Party

8 - Removed the "must be support" skos:notes. (Will be reflected in normative Vocab.)

Commited 079dbf8

[simonstey]

7 - True, but relation's range is Asset (in this case) Like function and Party

and its domain is Rule:

4.3.2 Relation
Definition: Relation is an abstract property which creates an explicit link between an Action and an Asset.
Range: Asset
Domain: Rule

so.. how?

[aisaac]

1. OK 2. OK 3. Great! 4. OK (though I guess it doesn't even appear, if unspecified is deprecated) 5. I have not checked all of them, but it like there's great improvement already. 6. It was a mere cosmetic suggestion, so if it's too complex, no problem. 7. @simonstey pointed the issue. 8. OK

…

On 12/05/17 11:59, simon wrote: 7 - True, but relation's range is Asset (in this case) Like function and Party and its domain is Rule: 4.3.2 Relation Definition: Relation is an abstract property *which creates an explicit link between an Action and an Asset*. Range: Asset Domain: Rule so.. how? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#166 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnprVzL4giU6Rk1foPUdgfCvedAaWf1ks5r5C2RgaJpZM4NNsKg>.

[riannella]

7. In fact it's domain is Rule and Policy.
   Listing relation in Asset is not wrong, is it?

[aisaac]

7. It's not formally wrong, indeed. But I think what @simonstey and I would prefer is that the property is presented in the section dedicated to the class that is its domain. I.e. through odrl:relation, one 'reaches' an Asset from a Policy, not the other way round. This would be the same for hasPolicy, by the way. It is applied 'on' assets, not policies. So it would make sense to present it in the section on assets.

[riannella]

ok, so:
1 - Move relation and function to Rule
2 - Move hasPolicy to Asset

ok?

[riannella]

Done.

commit ac44dfa

[aisaac]

OK!

…

On 02/06/17 07:48, Renato Iannella wrote: Done. commit ac44dfa <ac44dfa> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#166 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAnprf_kyRLmbip2Obx1btyM5ZcL8yaEks5r_6IfgaJpZM4NNsKg>.

[aisaac]

I was asked to check issues in which I was involved. I think this one can be closed now.