New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reviews of ODRL IM - Editor's Draft 3 August 2017 #215
Comments
Re Profile
|
Re Constraints
|
Re 2.7 Policy Rule Composition
Re 2.7.1 Compact Policy
|
RE: Profile 2.1:
4:
4.4:
|
RE: Constraints 2.6 Constraints:
2.6.1: Constraint Class:
2.6.2. Logical Constraint Class:
|
@riannella thanks for all the changes. re cardinality of property values
My suggestion:
|
Re 2.7 Policy Rule Composition: Now 1: Semantic issue 1a/1b: - removed that sentence (left over from before it was made into two sections) Re 2.7.1 Compact Policy Now 1: If you leave them there - then that creates duplicates, and may mean that your repeat the same process over again, And it does not help when you create atomic policies. Now2: we don't say why or where you should use compact policies, only that they should be transformed into atomic for conformance/exchange (Recommended=Should="may exist valid reasons in particular circumstances to ignore a particular item") |
re cardinality of property values We do use "one or may have many" everywhere - we addressed this in #200 I don't think there is any part of the IM that is dependent on syntax.. if there are any, then please point them out ;-) |
re 2.7.1 Compact Policy - Now2: transforming into atomic rules for checking the conformance sounds reasonable. But I don't understand the reason behind "... exchanged for interoperability ..." - is it ok to remove it? |
re cardinality of property values: ok, I checked the definition of the cardinality of properties for all the classes.
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
Set Class
Offer Class
Agreement Class
Asset Class:
Party Class
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
Rule Class:
Permission Class:
Prohibition Class:
Duty Class:
Examples in sections numbered 2.5.3.x Constraint Class
Logical Constraint Class
Compact Policy Policy Metadata
Policy Inheritance
Policy Conflict Strategy **Typos** 2.5 Rule Class, last para: Thst is, all of it's Constraints |
We use the the RFC terms (MAY, MUST) in these expressions. So, it is "MUST have one and MAY have many..." which means that the property must appear at least once. I assume we must keep using the RFC terms as a W3C spec. |
But there is only one profile property (with many values)? |
I added a general note to all the section about this |
Was not sure what I was supposed to do with this? |
Thanks for your detailed feedback @nitmws ! I have made all the changes (with notes above) |
re @riannella 's changes in the IM document of 10 August 2017 - thank's for all what has been done: cardinality wording Policy Class - profile
As shown in my previous posting this is an example for a predicate/property with a "... or more" cardinality. A Policy has also in e.g. JSON only one "permission" property but an array of values and the permission has the cardinality "one or more". Exactly the same applies to profile. extended cardinality due to Policy Rule Composition rules re Policy Conflict Strategy |
Updated with above changes. |
@riannella all changes look good 👍 |
re Action Class / implies sub-section Now: "The implies property can be used for Action instances which have no includedIn relationship." This can be concluded from this sentence: "an implies property can be applied to any Action instance which does not have an includedIn relationship (= property) - but that instance is invalid as includedIn is mandatory ?!?!". Should be: "The implies property can establish such an assertion between two Action instances if they don't have an includedIn relationship." |
re Obligation and Duty
|
I have made these updates. But I have left "valid" in the 2.10 Policy Conflict Strategy section (as this is not looking for effective policy rules...) |
2.1 Policy Class
2.5.3 Duty Class
|
2.5.4 Obligation property with a Policy
No. The obligation is a completely independent Rule from the permission Rule. |
2.5.5 Duty property with Permission
2.5.6 Consequence property with a Permission(delete 's!) Duty
2.5.7 Remedy property with a Prohibition
But this is exactly what the remedy property does do (..not the seriously bit...) But making it clear that when there is no remedy, then we really really mean you can't do this! |
given they all have the same subject. by changing the wording to Line 667 in 5b95e43
serializations like the following are now invalid <http://example.com/agreement:01>
a odrl:Agreement ;
odrl:permission [
a odrl:Permission ;
odrl:target <http://example.com/asset:9898> ;
odrl:action odrl:reproduce ;
odrl:assigner ex:Bob, ex:Chris ;
odrl:assignee ex:Alice ;
] . |
The Policy Rule Composition does allow this: And when it is processed into an atomic Policy, it has two permission Rules (one for each assigner), and fits the normative model. |
Coming back to the definition of an obligation in IM version 17 August. The wording now in 2.5.4 Obligation property with a Policy: re @riannella above:
These statements make the use of an obligation at the policy level unclear:
This must be defined else the obligation Duty is useless. |
None. All (policy-level) Rules are independent.
If you wanted to model this policy, then the |
If not fulfilling an obligation Duty has no impact on anything: why should one fulfill it? |
Follow up after the POE call on 21 August and reading the parts about Duty in #211 and the issue about modelling Duty/obligation #191:
Considerations:
Footnote on this issue raised at the call: "the constraint defining the amount to be paid" and "the constraint when the payment has to be made" are different. Sorry, but I can't see a significant difference between these constraints. Maybe we have to create sub-Actions of "compensate": pre-compensate if a time constraint has to be satisfied prior to performing the permitted action or post-compensate if the time constraint can be satisfied after the permitted action has been performed. But this is more an issue of well defined actions and constraints and not an IM design issue. |
That is a business case that we have no say over :-) In reality (eg regulations), obligations will have consequences. |
@nitmws, I am confused by this statement:
I assume you are talking about the Action class? This is not a subclass of any other class. It is referenced (via action) by the Rule class. |
I think ODRL must define the semantics of having one to many obligation properties in a Policy. Currently we don't say anything about this "style" of a Policy.
No, "the Class" = the class used for obligation, duty, consequence and remedy, currently called Duty Class. As this class and its use is discussed in the bullet points above I didn't use the full name. |
@nitmws I don't understand why you would want to define Duty as a standalone class. Isn't the lis of properties you have above are the same as what Duty has now, as a subclass of Rule? (note: remedy is a property of Prohibition) |
@riannella while writing #211 (comment) I noticed that the problem is inside the Duty Class: some properties of type Duty may have a consequence, others not. My conclusion after having had a deeper look into https://github.com/w3c/poe/files/1240662/states.pdf is:
|
"duty" keeps us compatible with the past community group work (and is not broken ;-) Look at the W3C ORG ontology: 10 properties all pointing to "Organisation" and one called "organisation" ;-) |
I did not suggest to change the name of the property "duty" but the name of the Duty Class - exactly for this historical reasons, changing a property name in instances of Policy is definitely a problem, to change the name of the underlying class less. Re the ORG ontology: as there are many properties named ....Organization it would not have been a problem to suffix the "organization" with a clarifying term. |
Issue (= place for) for posting review comments about this ODRL IM document
The text was updated successfully, but these errors were encountered: