Skip to content
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

Closed
nitmws opened this issue Aug 7, 2017 · 41 comments
Closed

Reviews of ODRL IM - Editor's Draft 3 August 2017 #215

nitmws opened this issue Aug 7, 2017 · 41 comments

Comments

@nitmws
Copy link
Contributor

nitmws commented Aug 7, 2017

Issue (= place for) for posting review comments about this ODRL IM document

@nitmws
Copy link
Contributor Author

nitmws commented Aug 7, 2017

Re Profile

  • re 2.1 Policy Class
    • Now 1: A Policy MAY have none or one profile property ...
      Should be 1: A Policy MAY have none, one or many profile properties ...
    • Now 2: Use an ODRL Profile that declares the supported vocabulary expressed in the Policy.
      Should be 2: Use an ODRL Profile that declares the supported vocabulary used by expressions in the Policy. (Comment: a Policy does not express vocabularies.)
  • re 4. ODRL Profiles
    • Now 1: An ODRL Profile explicitly serves a communities needs by ...
      Should be 1: An ODRL Profile explicitly serves community needs by ...
    • Now 2: These terms may be defined explicitly or may be reused from the ODRL Common Vocabulary.
      Should be 2: These terms may be defined explicitly or may be adopted from the ODRL Common Vocabulary. (Comment: "adopted" clarifies more that a Profile needs an explicit statement to make a term of the Common Vocabulary part of it.)
    • Now 3: Additional Actions for Rules: ... of a Action
      Should be 3: Additional Actions for Rules: ... of an Action
    • open issue re "All new classes ... must also be defined as a skos:Concept": is there a need to create skos:Collection for all instanced of e.g. Actions, Left Operand ... defined by a Profile. (They are defined this way by the Core Vocabulary.)
  • re 4.4 ODRL Core Profile
    Now 1: ... then the following identifier MAY be used: http://www.w3.org/ns/odrl/2/core
    Should be 1: ... then the following identifier MAY be used for the Core Profile: http://www.w3.org/ns/odrl/2/core
    (Comment: currently it is not clear if the IRI applies to the Core Vocabulary of to the Core Profile.)

@nitmws
Copy link
Contributor Author

nitmws commented Aug 7, 2017

Re Constraints

  • re 2.6 Constraints
    • Now 1: Constraints are boolean/logical expressions that refines ...
      Should be 1: Constraints are boolean/logical expressions that refine ...
    • Now 2: The evaluation of a Constraint is treated as a black box from an external system ...
      Could be 2: The evaluation of a Constraint is treated as a black box outside the ODRL Processor ...
      (Comment: "external system" - external to what? Does Thomson Reuters has to use a Bloomberg system? ;-)
    • Now 3: ODRL Processors MUST check if a Constraint is satisfied at the time of processing the relevant Action, or Party/Asset Collection.
      Should be 3: ODRL Processors MUST check if a Constraint is satisfied at the time of processing the relevant Rule, or Party/Asset Collection.
    • Now 4: ... then the (individual) Asset or Party member(s) - a subset of the Collection - becomes effective for the enclosing Rule.
      Could be 4: then the individual Asset or Party member or multiple of them - a subset of the Collection - becomes effective for the enclosing Rule.
  • re 2.6.1 Constraint Class
    • Now 1: A Constraint class is used for expressions which compare two operands by one operator.
      Semantic issue 1: based on that wording the only difference of a Logical Constraint Class is that it may compare more than 2 operands - but that's not the key difference.
      Could be 1: A Constraint class is used for expressions which compare two operands which are not constraints by one relational operator.
    • Now 2: The Constraint class can express these contexts ...
      Semantic issue 2: what are "these contexts" ? (In the Constraint section the term context is usually used with Party/Asset collection.)
    • "The Constraint class has the following properties:"
      Now 3: the properties leftOperand, operator and rightsOperand have a mandatory single occurrence but their ranges use plural terms: Left Operands, Operators, right operand values
      Should be 3: singular terms (as used for the other properties with (none or) one occurrence.)
    • Now 4: The leftOperand MUST clearly be semantically defined ... and may show how ...
      Should be 4: The leftOperand MUST clearly be semantically defined ... and may declare how ...
      (Comment: the "how to" is a definition and not a presentation issue.)
  • re 2.6.2. Logical Constraint Class
    • Now 1: A Logical Constraint class are expressions for logically comparing two or more operand values - with the operand values being a list of existing Constraints.
      Could be 1 (based on the suggestion above): A Logical Constraint class is used for expressions which compare two or more operands which are existing constraints by one logical operator.
    • Now 2: A Logical Constraint MUST have one operand sub-property indicating the logical relationship.
      Should be 2: A Logical Constraint MUST have one operand sub-property indicating the logical relationship of the compared existing constraints.
    • Now 3: xone - only one of the Constraints MUST be satisfied
      Should be 3: xone - only one and not more of the Constraints MUST be satisfied
      (Comment: the currents definition covers this case: 1 Constraint is satisfied - and 3 others too.)
    • Now 4: Additional operand sub-properties MAY be defined in the ODRL Common Vocabulary [odrl-vocab] or defined by ODRL Profiles.
      Should be 4: Additional operand sub-properties MAY be defined by ODRL Profiles.
      (Comment: sub-properties have to be defined by a Profile, by the Common Vocab is not sufficient.)
      Follow up 4: the Common Vocab should also be removed from the processing model, item 1.
    • Now 5: The processing model ... 3. The Constraint instances
      Could be 5: 3. These Constraint instances (Comment: as readers may ask "which Constraint instances")
    • Now 6: NOTE - When Constraints appear ...
      Formal issue 6: such "policy-level properties not for the Policy" for Compact Policy are clearly defined there. (See "Properties that MAY be shared include:) Such a clear definition must be added to Logical Constraint Class, using a NOTE is too lightweight.

@nitmws
Copy link
Contributor Author

nitmws commented Aug 7, 2017

Re 2.7 Policy Rule Composition

  • Now 1: A Policy MAY also be related to Assets, Parties, and Actions at the Policy level, and these relationships apply to all of the enclosing Rules in the Policy.
    Semantic issue 1a: the first part of the sentence sounds like the policy-level properties used for the Compact Policy - but then comes "enclosing Rules": what Rules are meant by that? E.g. all the related Rules of a Policy? This wording needs clarification.
    Semantic issue 1b: if "A Policy MAY also be related to Assets, Parties, and Actions at the Policy level, " covers the Compact Policy case this is a contradiction to 2.7.1 as it states "... These shared properties MUST NOT be interpreted as Policy-level properties ...". If the text states that a Policy relates to an Asset at the policy-level this establishes a relationship between the Policy and the Asset and makes the Asset a property of the Policy.
    This needs to be fixed.
  • Now 2: In order to create the atomic Rules in a Policy, the processing model for policies with multiple Assets, Parties, and Actions includes:
    Semantic issue 2: this sounds like Assets, Parties and Actions at the policy-level are meant - but as the examples and the processing model shows multiple Assets, Parties and Actions inside a Rule are meant.
  • Now 3: the processing model wording using " ... then create new Rules ..."
    Should be 3: "... then replace the existing Rule by newly created Rules ..."
    (Comment: currently the existing Rule would stay.)

Re 2.7.1 Compact Policy

  • Now 1: processing model, item 2: Remove the shared properties declared at the Policy-level
    Issue 1: why is this action required? 2.7.1 has already defined that any policy-level property should not be interpreted as policy property. And how to remove such properties ...
    Could be 1: 2. Ignore the shared properties declared at the Policy-level for any further policy processing.
  • Now 2: It is RECOMMENDED that compact ODRL Policies be expanded to atomic Policies when being processed for conformance or exchanged for interoperability, to reflect the normative ODRL Information Model.
    Issue 2a: does that mean a Compact Policy SHOULD only be used inside the company/system of the publisher of the Policy? (... else it is an exchanged policy ...)
    Issue 2b: does that mean a Compact Policy does not reflect the normative ODRL IM?
    This needs clarification.

@riannella riannella added the Model label Aug 8, 2017
@riannella riannella added this to Under Current Discussion in ODRL Deliverables Review Aug 8, 2017
riannella added a commit that referenced this issue Aug 8, 2017
@riannella
Copy link
Contributor

RE: Profile

2.1:

  1. The idea is that we have one profile property that includes the URIs of one or more Profiles.
    So, we don't have 10 profile properties, but one profile property that includes 10 URIs?

  2. ok, fixed

4:

  1. ok, fixed

  2. ok, fixed

  3. ok, fixed

  4. We only use skos:collection for the generation of the vocab document. We don't add any semantics to ODRL by using skos:collection.

4.4:

  1. ok, fixed.

riannella added a commit that referenced this issue Aug 8, 2017
@riannella
Copy link
Contributor

RE: Constraints

2.6 Constraints:

  1. ok, fixed
  2. ok, fixed
  3. ok, fixed
  4. ok, fixed with "..or multiple members.."

2.6.1: Constraint Class:

  1. ok, fixed
  2. ok, fixed
  3. ok, fixed
  4. ok, fixed

2.6.2. Logical Constraint Class:

  1. ok, fixed
  2. ok, fixed
  3. ok, fixed
  4. ok, fixed
  5. ok, fixed
  6. ok, moved to narrative text

@nitmws
Copy link
Contributor Author

nitmws commented Aug 8, 2017

@riannella thanks for all the changes.

re cardinality of property values
See 2.1 Profile - a single profile property may hold one to many profile ids:
Checking this feature for other properties I agree that currently by the specification also e.g. the action property of the Rule Class must occur one time (and not more) but may hold multiple actions ids.
BUT:

  • may the uid property of Policy Class hold multiple identifiers? It must not!
  • for the permission, prohibition and obligation the current specification says "A Policy MUST have one and MAY have many permission, prohibition, or obligation properties for Rules." ... and in fact the same serialisation syntax is used for multiple e.g. permissions like for multiple profiles.
  • My conclusion: to provide an unambiguous definition of properties the cardinality of their values must be written down in the IM. Footnote: as JSON-LD supports using a single value and an array of values for the same property the Examples don't help to find out the cardinality.

My suggestion:

  • The IM should express explicitly the cardinality of property values = if multiple values are ok then "... one or may have many ..." should be used - everywhere.
  • The IM should ignore the syntactic sugar of Turtle or JSON which allows to wrap multiple values by a single formal property - that's a serialisation issue, not a model issue.

riannella added a commit that referenced this issue Aug 9, 2017
@riannella
Copy link
Contributor

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)
Now 2: fixed
Now 3: fixed

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.
They are just "removed" by an ODRL processor.

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")
A compact policy, with an assigner property at the policy-level, for example, does not reflect the IM model (only a Rule can have an assigner).

@riannella
Copy link
Contributor

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 ;-)

@riannella riannella moved this from Under Current Discussion to Proposed Solution in ODRL Deliverables Review Aug 9, 2017
@nitmws
Copy link
Contributor Author

nitmws commented Aug 9, 2017

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?

@nitmws
Copy link
Contributor Author

nitmws commented Aug 9, 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: occurrence = 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>  .  

# is a short form of:
<http://example.org/subject1> odrl:action <http://www.w3.org/ns/odrl/2/aggregate> .  
<http://example.org/subject1> odrl:action <http://www.w3.org/ns/odrl/2/digitize>  .  

# above: occurrence = 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.


**Typos**

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

@riannella
Copy link
Contributor

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".

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.

@riannella
Copy link
Contributor

profile: is defined as "none or one" - must be none, one, or more

But there is only one profile property (with many values)?

@riannella
Copy link
Contributor

target: see relation sub-property issue in Rule Class

I added a general note to all the section about this

@riannella
Copy link
Contributor

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

Was not sure what I was supposed to do with this?

riannella added a commit that referenced this issue Aug 10, 2017
@riannella
Copy link
Contributor

Thanks for your detailed feedback @nitmws !

I have made all the changes (with notes above)

@nitmws
Copy link
Contributor Author

nitmws commented Aug 10, 2017

re @riannella 's changes in the IM document of 10 August 2017 - thank's for all what has been done:

cardinality wording
I personally see no real difference between "MUST have one and MAY have more" and "MUST have one or more".
BUT let's use a common wording: all the Policy sub-classes define now "MUST have one or more permission ..." while the Policy Class still defines "MUST have one and MAY have many permission ..."

Policy Class - profile
The RDF for a policy with 2 profiles is:

<http://example.org/policy:1010>
    odrl:profile <http://www.example.org/odrlprofile:4711>, <http://iptc.org/std/RightsML/>  .  

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
The added para "Note: The above property cardinalities reflect the normative ODRL Information Model. " looks good.
BUT: the referenced section "Policy Rule Composition" doesn't make a clear statement about that syntactic sugar. The section starts with the sentence "A Policy MAY be related to multiple Rules, and each Rule MAY be related to multiple Assets, Parties, Actions, Constraints, and Duties." The first part "A Policy ... multiple Rules" reflects the formal cardinality, the second part widens the formal cardinality of Action and Asset function target without any further notice.
This needs to be clearly indicated: ... multiple Rules, and the Policy Rules Composition permits each Rule MAY be related to multiple Assets, Parties, Actions, Constraints, and Duties. This extends the cardinality of the action and the target property.

re Policy Conflict Strategy
My note was only a verbose "ok".

@riannella
Copy link
Contributor

Updated with above changes.
Revamped the examples in Compositions section

@nitmws
Copy link
Contributor Author

nitmws commented Aug 11, 2017

@riannella all changes look good 👍

@nitmws
Copy link
Contributor Author

nitmws commented Aug 11, 2017

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 ?!?!".
But I guess that's not the intention behind the sentence above ...

Should be: "The implies property can establish such an assertion between two Action instances if they don't have an includedIn relationship."

@nitmws
Copy link
Contributor Author

nitmws commented Aug 12, 2017

re Obligation and Duty

  • Generic terminology issue: I see there mixes of two different terminologies which should be consistent
    • for Duty classes: they should be "(not) fulfilled" and not "(not) satisfied"
    • for Permission/Prohibition classes: they should be "(not) in effect" and not "(not) valid"
  • 2.1 Policy Class
    The second bullet of the list of properties includes the obligation property. The "See ..." below points at Duty - replace that by pointing at 2.5.4 Obligation property with Policy.
  • 2.5.3 Duty Class
    The current specification of the consequence property ("The consequence property is utilised ...") does not work:
    • Prerequisite, by my understanding: "a Duty is in effect" = the action of the Duty has to be taken, "a Duty has been fulfilled" = the action of the Duty has been taken successfully.
    • therefore "... meaning that both Duties are now effective and MUST be fulfilled." is wrong: that both are in effect is true, but as the consequence Duty only becomes effective if the "parenting" Duty has NOT been fulfilled this requirement "both ... MUST be fulfilled" can't ever be met.
    • Should be: "... meaning that both Duties are now effective and now the consequence Duty MUST be fulfilled. If the consequence Duty has been fulfilled the whole Duty has been fulfilled."
    • I suggest to merge the case "obligation" and "permission": "... the repercussions of not fulfilling a required obligation Duty of a Policy or duty of a Permission." and remove the sentence "Similarly if a Permission ..."
  • 2.5.4 Obligation property with a Policy
    Sorry, but I can't get the current definition of an obligation:
    • Fulfilling a duty of a Permission is required to let the Permission be in effect. But a Policy doesn't have a status "in effect" (see also ODRL Evaluator review - IM of 11 August 2017 #217). What is the impact of fulfilling or not fulfilling an obligation of a Policy?
    • I recall from the discussions about this feature: such an obligation is a duty with applies to all permissions of a Policy in a shared way = an obligation Duty at the Policy level is the same a using the same Duty as duty of each of the permissions, the only difference is: this duty has to be fulfilled only once for all permissions and not for each permission individually.
    • If I'm right the definition should be: A Policy may include an obligation Duty. In this case only if this obligation has been fulfilled the Permission(s) of this Policy may be in effect. If multiple obligations are included all of them have to be fulfilled.
    • re "Note that if there is no consequence property for an obligation Duty, then the obligation MUST be fulfilled." This is unclear and even violating the definitions of obligations in 2.5.3 - I suggest to remove it.
    • (above Example 16) " ... a consequence is that the assigner MUST also compensate the nominated charity ...": what does this "also" mean? The assignee has NOT deleted the asset = the required action has NOT been taken, therefore the compensation action cannot "also" be taken. Remove this "also".
  • 2.5.5 Duty property with Permission
    • Now 1: "In this case the Permission is valid ... if and only if the Duty has been fulfilled."
    • By the terminology used elsewhere a permission Rule can only be "in effect" or "not in effect". Therefore "In this case the Permission is in effect .... "
    • Now 2: "If a Permission has several Duties then all of the Duties MUST be agreed to be satisfied for the Permission to be valid. "
    • Should be 2: "If a Permission has several Duties then all of the Duties MUST be fulfilled for the Permission to be in effect."
    • " If several Permissions refer to a single Duty, then the Duty only has to be satisfied once for all the Permissions to be valid." - how is the syntax for this case? The ODRL IM and even the Compact Policy syntax has no duty property at the Policy-level! Or is this a hidden reference to the obligation? This needs clarification!
  • 2.5.6 Consequence property with a Permission(delete 's!) Duty
    This section covers things which are already defined by the Duty class:
    • Should be (simply): A duty of a Permission may include a consequence of not fulfilling that duty. A consequence is also a Duty. See Duty Class for more about the consequence.
    • re "Note that if there is no consequence property for a Duty, then the Duty MUST be fulfilled before the Permission can be exercised.": this does not fit into this section as it covers the case of not having a consequence property and "2.5.5 Duty property with Permission" has already a similar statement - therefore: remove this Note
  • 2.5.7 Remedy property with a Prohibition
    • re "Note that if there is no remedy property for a Prohibition, then the Prohibition MUST NOT be exercised." This is unclear: "prohibition" means that an action must not/should not be exercised. And a remedy covers the case that this rule is not met - and it does not open the options "I may take the prohibition seriously or not, if not then I have to do the remedy". I suggest to remove this note.
    • re "... and such transgressions should not be considered as negative actions by the assignee." What does that tell, what is "a negative action by the assignee"? Is the consequence to apply no "like"s anymore to the facebook entity of the assignee anymore ;-)? I suggest to remove at least this "and such transgression ..." part.

@riannella
Copy link
Contributor

for Duty classes: they should be "(not) fulfilled" and not "(not) satisfied"
for Permission/Prohibition classes: they should be "(not) in effect" and not "(not) valid"

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...)

riannella added a commit that referenced this issue Aug 14, 2017
@riannella
Copy link
Contributor

2.1 Policy Class

  • Fixed

2.5.3 Duty Class

  • Fixed (should not have used the term effective...)

@riannella
Copy link
Contributor

2.5.4 Obligation property with a Policy

If I'm right the definition should be: A Policy may include an obligation Duty. In this case only if this obligation has been fulfilled the Permission(s) of this Policy may be in effect. If multiple obligations are included all of them have to be fulfilled.

No. The obligation is a completely independent Rule from the permission Rule.
The obligation Rule is simply - you must do this.

riannella added a commit that referenced this issue Aug 14, 2017
@riannella
Copy link
Contributor

2.5.5 Duty property with Permission

  • fixed

2.5.6 Consequence property with a Permission(delete 's!) Duty

  • fixed

2.5.7 Remedy property with a Prohibition

...and it does not open the options "I may take the prohibition seriously or not, if not then I have to do the remedy

But this is exactly what the remedy property does do (..not the seriously bit...)
It basically says you can't do this action, but if you do (you decide why) then you must do this other action.

But making it clear that when there is no remedy, then we really really mean you can't do this!

@riannella riannella moved this from Under Current Discussion to Proposed Solution in ODRL Deliverables Review Aug 14, 2017
@simonstey
Copy link
Contributor

simonstey commented Aug 14, 2017

@nitmws

The IM should ignore the syntactic sugar of Turtle or JSON which allows to wrap multiple values by a single formal property - that's a serialisation issue, not a model issue.

given they all have the same subject.

by changing the wording to

<li>A Permission MAY have none or one <code>assigner</code> and/or <code>assignee</code> property function roles for Parties. (Other <code><i>function</i></code> sub-properties for Party MAY be used.)</li>

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 ; 
    ] .

@riannella
Copy link
Contributor

The Policy Rule Composition does allow this:
file:///Users/renato/users/odrl/W3C-POE/GIT-POE/model/index.html#composition

And when it is processed into an atomic Policy, it has two permission Rules (one for each assigner), and fits the normative model.

@nitmws
Copy link
Contributor Author

nitmws commented Aug 18, 2017

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:
A Policy may include an obligation to fulfill a Duty. If the Duty rule has been fulfilled (that is, all its Constraints are satisfied), then the Duty rule is in effect. That is, the obligation has been meet.

re @riannella above:

No. The obligation is a completely independent Rule from the permission Rule.
The obligation Rule is simply - you must do this.

These statements make the use of an obligation at the policy level unclear:

  • ODRL has no requirement that all Rules of a Policy must be in effect, else the Policy must not be used (= is not in effect).
  • If a Policy has three Permissions the evaluation at a point in time may result in: 2 Permissions are in effect, 1 Permission is not in effect - and this is ok!
  • The same may apply for a Policy with these three Permissions plus an obligation Duty. The evaluation results could be: 2 Permissions are in effect, 1 Permission and the obligation Duty are not in effect - and this is ok by the current IM definitions!
  • The open issue is: what is the impact on the Policy as a whole, including all Permissions and Prohibitions, if a obligation Duty is not in effect?
  • Could the definition be (added to 2.5.4): If any obligation Duty of a Policy is not in effect then all Permissions and Prohibitions of the Policy are not in effect.

This must be defined else the obligation Duty is useless.

@riannella
Copy link
Contributor

The open issue is: what is the impact on the Policy as a whole, including all Permissions and Prohibitions, if a obligation Duty is not in effect?

None. All (policy-level) Rules are independent.
That is, you can have 3 permissions in effect, 2 prohibitions in violation, and 1 obligation not in effect in a Policy.

Could the definition be (added to 2.5.4): If any obligation Duty of a Policy is not in effect then all Permissions and Prohibitions of the Policy are not in effect.

If you wanted to model this policy, then the obligation should be represented as a duty between the Perms/Prohib and the Duty.

@nitmws
Copy link
Contributor Author

nitmws commented Aug 21, 2017

None. All (policy-level) Rules are independent.
That is, you can have 3 permissions in effect, 2 prohibitions in violation, and 1 obligation not in effect in a Policy

If not fulfilling an obligation Duty has no impact on anything: why should one fulfill it?

@nitmws
Copy link
Contributor Author

nitmws commented Aug 21, 2017

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:

  • I got at the call that an obligation Duty is a different kind of Duty compared to a duty Duty: it has no impact on a permission ...
  • ... but I raise: this needs an explicit definition of this "other kind of Duty", currently we only have use cases outlining this other use:
    • At this call Sabrina said: the obligations of a Policy define what needs to be fulfilled to claim the Policy is fulfilled and this could make an action legal. And she pointed at regulations like the GDPR (http://www.eugdpr.org), they could be expressed this way.
      In my words: obligations of a Policy define what needs to be done to meet a regulation being the target Asset of the obligations. But this is only a guideline, not a rule.
    • ... and @simonstey said: if he and Sabrina agree that he pays Sabrina 5 EUR this could be expressed by an obligation Duty.
      In my words: this is a documentation of an agreement, fulfilling or not fulfilling this obligation has no role in the Policy.

Considerations:

  • The Duty Class is defined as "A Duty is the obligation to perform an Action." It claims that "agreed actions must be fulfilled" but a/ what is an agreed action and b/ what does it mean to fulfil an action - the IM uses fulfilled primarily as the result of a Duty Class instance.
  • Let's have a look at how the Duty Class is used by different properties:
    • In a Permission a fulfilled duty is required to put it "in effect" = the duty has a strong role in the scope of the Permission.
    • In a Prohibition a remedy is an action which must be taken if the Prohibition has been violated = this is a follow up of taking the action of violating the Prohibition. If the remedy has been fulfilled or not is outside the scope of the Prohibition.
    • In a Duty a consequence is an action which must be taken if the duty has not been fulfilled and the action of the parenting Permission has been taken = this is a follow up of taking the Permission-action without the fulfilled duty. If the consequence has been fulfilled or not is outside the scope of the Permission.
    • In a Policy a obligation is "the obligation to perform an Action". Currently the IM does not define any context for that. So the ODRL user does not know if fulfilling an obligation or not has any kind of resulting impact (an obligation must not use consequence or remedy!).
  • In Modelling duty/obligation #191 @riannella raises the question "What is the difference between an Obligation and a Duty ?"
    My answer: currently only the structure of the Class is common, the reasons for executing "the obligation to perform an Action" are quite different and also the use of the result status of "the Action has (not) been executed successfully" is quite different.
  • A solution for that could be:
  • A basic action is: make the Class a standalone class and not a sub-class of Rule. This way we would get rid of all what's inherited from the Rule Class.
  • Second: re-define the Class:
    • name: Required Action Class (to move the name of the class far away from properties using it, the use of Duty and duty in documents about ODRL is confusing.)
    • definition: A Required Action is the obligation to perform an Action. The Required Action is to be considered as taken if all constraints have been satisfied and if the action of this class has been performed.
    • properties:
      • MUST have one action property value of type Action
      • MAY have none or one target property values (of type Asset) to indicate the Asset that is the primary subject to which the Required Action directly relates. (Other relation sub-properties MAY be used.)
      • MAY have none or one assigner and/or assignee property values (of type Party) as functional roles. (Other function sub-properties MAY be used.)
      • MAY have none, one or many constraint property values of type Constraint/LogicalConstraint.
      • MAY have none or one uid property values (of type IRI [rfc3987]) to identify the Required Action so it MAY be referenced by other Required Actions or Rules.
      • MAY have none, one or many consequence property values of type Required Action if used with the property permission.
      • MAY have none, one or many remedy property values of type Required Action if used with the property prohibition.
  • Third option: each property of type Required Action Class must define how it is used = what an impact "the Required Action (not) been taken" has on the context of this property.

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.

@riannella riannella moved this from Proposed Solution to Under Current Discussion in ODRL Deliverables Review Aug 22, 2017
@riannella
Copy link
Contributor

If not fulfilling an obligation Duty has no impact on anything: why should one fulfill it?

That is a business case that we have no say over :-)

In reality (eg regulations), obligations will have consequences.

@riannella
Copy link
Contributor

@nitmws, I am confused by this statement:

A basic action is: make the Class a standalone class and not a sub-class of Rule

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.

@nitmws
Copy link
Contributor Author

nitmws commented Aug 22, 2017

That is a business case that we have no say over :-)

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.


I assume you are talking about the Action class?

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.

@riannella
Copy link
Contributor

@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)

@nitmws
Copy link
Contributor Author

nitmws commented Aug 23, 2017

@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.
And the remedy property slipped in inadvertently, sorry.

My conclusion after having had a deeper look into https://github.com/w3c/poe/files/1240662/states.pdf is:

  • The Rule Class should have only a minimal processing model, only what is shared across Permission, Prohibition and Duty
  • We need a detailed processing model for these three sub-classes of Rule as they are quite different.
  • I'm still not happy with having a class named "Duty" and a property of other classes named "duty". A wrong case of the first character can cause confusion in the documentation and in the communication about ODRL. (I'm aware of the history: in ODRL 2.0/.1 the Duty Class was only the type of the duty property of the Permission Class, nothing else. Now 4 properties are of this type and one of them is named "duty".)

@riannella
Copy link
Contributor

"duty" keeps us compatible with the past community group work (and is not broken ;-)

Look at the W3C ORG ontology:
https://www.w3.org/TR/vocab-org/img/OrgOntology20130502.png

10 properties all pointing to "Organisation" and one called "organisation" ;-)

@nitmws
Copy link
Contributor Author

nitmws commented Aug 24, 2017

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.

@riannella riannella moved this from Under Current Discussion to Proposed Solution in ODRL Deliverables Review Aug 29, 2017
@riannella riannella moved this from Proposed Solution to Completed (Last Call) in ODRL Deliverables Review Sep 1, 2017
@riannella riannella removed this from Completed (Last Call) in ODRL Deliverables Review Sep 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants