Re: [poe] Reviews of ODRL IM - Editor's Draft 3 August 2017

re cardinality of property values: ok, I checked the definition of the cardinality of properties for all the classes.
To clarify what the cardinality expresses in RDF terms: how many times a predicate plus object using the same subject may occur - see this in Turtle:
```
<http://example.org/subject1>
    odrl:action <http://www.w3.org/ns/odrl/2/aggregate> . 

# above: occurence = 1
# covered by the cardinality variants of odrl:action 
#     "one", "none or one", "none, one, or more", "one, or more"

<http://example.org/subject1>
    odrl:action <http://www.w3.org/ns/odrl/2/aggregate>, <http://www.w3.org/ns/odrl/2/digitize>  .  

# above: occurence = 2
# covered by the cardinality variants of odrl:action "none, one, or more", "one, or more"
```
Wording note: some definitions use for a cardinality including "..unbounded" the words "have none, one, or more" others " have one and MAY have many". I see no difference in the formal expression, could the wording be harmonised to "have none, one, or more" and "have one, or more".

Policy Class
* uid: ok
* permission, prohibition, obligation: ok
* **profile**: is defined as "none or one" - must be none, one, or more
* conflict: ok

Set Class
* _relationship sub-properties_: cardinality ok - BUT: why does it use the abstract "relationships to a Rule" while the super class Policy list them explicitly as permission, prohibition and obligation? Why not "A Set Policy MUST have one, or more permission, prohibition, or obligation properties for Rules." 

Offer Class
* _permission and prohibition_: cardinality ok. BUT as above: why not "An Offer Policy MUST have one, or more permission or prohibition properties for Rules."
* assigner: ok

Agreement Class
* _permission and prohibition_: cardinality ok. BUT as above: why not "An Offer Policy MUST have one, or more permission or prohibition properties for Rules."
* assigner: ok
* assignee: ok

Asset Class:
* uid: ok
* relation sub-properties: ok
* partOf: ok
* constraint: ok

Party Class
* uid: ok
* function sub-properties: ok
* partOf: ok
* constraint: ok

Note on 2.3.1 Function Property: this is the section defining the sub-properties assigner and assignee - these properties were already defined for the Offer and Agreement classes. I suggest to add there a link to 2.3.1.

Action Class
* **includedIn**: "must have one" - but the actions use and transfer don't have it. (That's like requiring that all concepts in a hierarchical scheme/taxonomy MUST have a broader relationship - this won't work too for the top level concepts)
Suggested solutions: 
a) explicitly excerpt the actions use and transfer
b) the ontology workaround: includedIn="owl:Thing" added to use and transfer
* **implies (?)**: sounds ok - but is it bullet proved that an action cannot imply more than 1 other action?

Rule Class:
* **action**: defined as (1) - but Examples 31..33 show multiple. The issue is: for the atomic level only 1 action is possible, but the compact design allow more. I suggest to express this explicitly: "A Rule MUST have one action property for Action at the atomic level. Only for the purpose of a Compact Policy [...link...] more than one may be used."
* **relation sub-properties**: same issue as above, Example 26 shows multiple
* function sub-properties: ok
* constraint: ok
* uid: ok

Permission Class:
* **target**: see relation sub-property issue in Rule Class
* assigner / assignee: ok
* duty: ok

Prohibition Class:
* **target**: see relation sub-property issue in Rule Class
* assigner / assignee: ok
* remedy: ok

Duty Class:
* **target**: see relation sub-property issue in Rule Class
* assigner / assignee: ok
* consequence: ok

Examples in sections numbered 2.5.3.x
These examples cover more than the Duty Class (section 2.5.3) - a new 2.5.4 Examples super-section should be created.

Constraint Class
* leftOperand: ok
* operator: ok
* rightOperand(Reference): ok
* dataType: ok
* unit: ok
* status: ok

Logical Constraint Class
* **operand sub-property**: the cardinality is ok, but the definition not. The problem is that as this thing is a very special kind of property; in fact it is not the predicate of an RDF triple: the property sets the operator of a comparison and its many (pseudo-)values are operands which should be compared. Therefore the generic rule "the cardinality defines the number of occurrences of a predicate plus object" does not match - so we must make the value a singularity, a single "list" - this works formally.
I suggest: A Logical Constraint MUST have one operand sub-property indicating the logical relationship  of compared existing constraints; its value is a list of the existing constraints to be compared."
(Footnote: this is an undefined type of list, doesn't have to be considered as ordered - except for andSequence)

Compact Policy
It lists **the "shared" properties** action, relation sub-properties, function sub-properties - but it doesn't define a cardinality. I suggest to use "none, one, or many" as even this use of properties out of the strict structure of the IM needs a guideline for their cardinality.

Policy Metadata
This section defines multiple **DC properties** - but no cardinality. 
I suggest 
* "none, one, or many" for dc:creator, dc:description, dc:coverage
* "none or one" for dc: issued, dc:modified, dc:replaces, dc:isReplacedBy

Policy Inheritance
* _inheritFrom_: has no explicit cardinality, from the first sentence I infer: "none, one, or many"
(I think this property must be defined already in the Policy Class as this is a "true" property of the class and not a short cut etc! A link for more details may point to this section - as it is done with the conflict property!)

Policy Conflict Strategy
The conflict property is already defined in the Policy Class section.

<hr>
**Typos**

2.5 Rule Class, last para: **Thst** is, all of it's Constraints


 




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

Received on Wednesday, 9 August 2017 10:41:27 UTC