Re: [poe] ODRL Ontology: formal definition and design issues

re @riannella 's comments:

re 1a) to narrow down "all terms": the individuals/instances of the classes Action, LeftOperand and Operator defined by ODRL - right?

re 1b, 5a, 5b) the use of SKOS Concept Scheme needs some practical considerations:

- it is a typical container of concepts making them a Controlled Vocabulary, taxonomy ...
- but how to organise it: a/ different containers for different groups of concepts  or b/ a single container for all Concepts defined by ODRL and the grouping of sets of concepts with shared semantics could be done by SKOS Collections - this would fit the needs of the specification script
- ... but this script raises also strange things: to be able to show a list of e.g. Policy Subclasses or Party Functions in the free-text specifications the ODRL ontology needs to have a Concept Collection for both despite the members are no Concepts. This is formally wrong. The minimal action would be to wrap such Collections inside the ontology document with a clear comment that these Collections only exist for the purpose of generating the specification document but in terms of SKOS they are wrong.
- a practical facet of using Concept Scheme is to make all ODRL Concepts accessible: accessing a scheme should be the starting point for retrieving the data of all included concepts.

re 2) sorry again: a policy does NOT have a target asset, only Permission and Prohibition have one and a policy with 10 Permissions could have 10 different target assets. Therefore the current wording is wrong, we must define that at least one of the Permissions/Prohibitions (maybe we can focus the design on Permission, see #187 ) has this asset as target.





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

Received on Wednesday, 7 June 2017 06:58:03 UTC