Usage of `odrl:eq` and `odrl:isA` operators and missing operator for subclasses

[besteves4]

Hi.

I have some questions regarding the use of the odrl:eq and the odrl:isA operators. Currently, if we want to use a constraint such as the odrl:purpose with a string as a right operand (as in the example below) I guess we should use the odrl:eq operator.

ex:constraint a odrl:Constraint ;
        odrl:leftOperand odrl:purpose ;
        odrl:operator odrl:eq ;
        odrl:rightOperand "Research and Development" .

However, if we wish to use a hierarchical taxonomy such as the DPV’s taxonomy of purposes, we start to run into some problems. Constraining a purpose with the "equal" operator has issues -- what if the purpose is an instance - then we could use the "is A" operator I guess. But what if the purpose is a subclass or an instance of a subclass? What if we want the instances and the subclasses?

ex:constraint a odrl:Constraint ;
        odrl:leftOperand odrl:purpose ;
        odrl:operator odrl:isA ;
        odrl:rightOperand dpv:ResearchAndDevelopment .

There should be some consideration on whether ODRL should provide a "subclass" operator and what to do when people want to use more than one operator together, e.g., a purpose constraint for dpv:ResearchAndDevelopment including all its instances and subclasses. More guidance on this topic should also be provided in the Best Practices document.

[coolharsh55]

Thanks for raising this issue. If I had to pick from the existing operators, isPartOf would be the closest one to what is intended, because eq requires equivalence (i.e. same IRI) and isA requires instantiation (i.e. rdf:type).

To reiterate where this would be required: An Offer states permission for purpose ResearchAndDevelopment. What should be the qualifier / operator in this constraint, such that a Request asking permission for purpose HealthResearch which is a subclass of ResearchAndDevelopment and for purpose MedicalScanTypeX which is an instance, should both be satisfied for the given constraint in Offer.

[riannella]

I think you could use the odrl:isAnyOf as it is a set operator and means "that a given value is any of the right operand"

ex:constraint a odrl:Constraint ;
        odrl:leftOperand odrl:purpose ;
        odrl:operator odrl:isAnyOf ;
        odrl:rightOperand dpv:vocab-purpose .

[coolharsh55]

The right operand is not an explicit set in this case. If its checking eq against every element in the set, this will not lead to the behaviour we want.

Another option to not create a new operator: The technical interpretation of isA and isNotA can be clarified to mean semantic type instead of just direct instance so that it can be used for covering both subclass and instance.

This makes sense to me, because if I say something should be of type A, and there's a subclass B of A, then using B does satisfy the constraint since all of its instances will also be instances of A.

Then eq and neq can continue to be used for equivalence as they are currently defined.

[riannella]

The constraint "is any of" does not know about subclass relationships, but an rdf reasoner does.

So if the odrl expression include a constraint "is any of" A, and the ODRL "evaluator" deems the instance to be of type A (either directly or via subclass membership) then a match will occur.

[coolharsh55]

A RDF reasoner also won't know about isAnyOf relationships because the definitions in the ODRL spec do not indicate how the reasoning should work:

isA Definition: A set-based operator indicating that a given value is an instance of the right operand of the Constraint. isAnyOf Definition: A set-based operator indicating that a given value is any of the right operand of the Constraint.

I understand your point. But if we're both writing our ODRL rule interpretation algorithms for the same definitions above with different inconsistent assumptions - IMHO the specification/definition should clarify what is the expected behaviour to the greatest extent possible.

The phrasing for isAnyOf reads to me that I take a set or list of values, and I do something to check if the value is "any of" those from a list. What does "any of" mean over here is ambiguous, but a naive interpretation is to use eq over the set. This seems to be consistent with previous discussions, e.g. #23.

A better method is to have definitions be clear about such implications and where possible to make them utilise other operators as qualifiers over sets. As:

1. isA: A set-based operator indicating that a given value is or can be (i.e. through subclass) an instance of the right operand of the Constraint.
2. isAnyOf: Definition: A set-based operator indicating that a given value satisfies eq or isA for ~is~ any of the right operand of the Constraint.

Once these clarifications (as above, or in different form) are made over what the existing operators mean in terms of implementation, it can be better understood whether they satisfy the requirements stated here, or a new operator is needed.

[joshcornejo]

So dpv:ResearchAndDevelopment is part of the dpv:vocab-purpose taxonomy.

As per my answer on the email exchange, the 3 scenarios I can foresee:

Option 1:

        odrl:leftOperand odrl:purpose ;
        odrl:operator odrl:eq ;
        odrl:rightOperand "Research and Development" .

Option 2:

        odrl:leftOperand odrl:purpose ;
        odrl:operator odrl:eq ;
        odrl:rightOperand dpv:ResearchAndDevelopment .

Option 3:

        odrl:leftOperand odrl:purpose ;
        odrl:operator odrl:isA ;
        odrl:rightOperand dpv:vocab-purpose .

The way I have specified things:

Option 1: LeftOperand is not from a taxonomy, and it is just "comparing strings" (If anyone wants to implement a taxonomy -> string comparison, that can be an interesting project, but I doubt of use in practical scenarios). Option 2: I implement this one for policies I generate. I have several taxonomies, so it works. Option 3: this one is a possibility to figure if the :LeftOperand is actually "in the shape of the :RightOperand - but I am not sure it conveys the most usual meaning of "is what you are trying to do equal to this element in the taxonomy", since ANY element in the taxonomy will match the odrl:isA.

IMHO odrl:isA is (maybe) useful in cases where importing policies that have been generated elsewhere (as there is a need to "validate", as per the diagram I sent a few months ago), or if you implement a theoretical evaluator that "fetches from the web the :LeftOperand, so first will have to check for its shape in a :LogicalConstraint sequence, but practically in ACL (as these trips and evaluations will add maybe hundreds of milliseconds and can't be cached), this operand is unlikely to be "broadly used" against an odrl:Agreement. It is implemented for the completeness of the standard.

I expect that in practice, odrl:isAnyOf is one of the "most popular" operators after the "fabulous 6", followed by odrl:isPartOf which would equate OpenFGA or any other graph ACL functionality.

In the case of odrl:isAnyOf there is an implicit assumption that the "shapes match", and you can compare anything, from "is this number in this set" to "is this item in this taxonomy".

[riannella]

The semantics (subclass) overlaps those of "2.3.3 Subclass of" Hence this one should only be about " equal to an instance " If that is the case, cannot we just use "Equal To" ?

[riannella]

For 2.3.3 Subclass, does this fit the current definition of "isA": "A set-based operator indicating that a given value is an instance of the right operand of the Constraint." ?

[coolharsh55]

The issue is that we want a comprehensive way to express a requirement at a broad level without requiring that things be modelled only as instances or sub-classes. For example, a policy that gives permission for R&D in a way that the policy is satisfied if any of these is true:

1. ex:A rdf:type dpv:R&D
2. ex:A rdfs:subClassOf dpv:R&D
3. ex:A skos:broader dpv:R&D
4. ex:A owl:sameAs dpv:R&D
5. ex:A skos:exactMatch dpv:R&D

Without such a property, each implementation might interpret and implement the property differently, and the only way to communicate this comprehensively is to have a compound permission with each of these conditions represented explicitly. The existing ODRL operators do not have a clear enough meaning for us to rely on their use:

• odrl:eq a given value equals the right operand -- "equal" means what? Does it mean exact IRI or owl:sameAs or skos:exactMatch?
• odrl:isA set-based operator indicating that a given value is an instance of the right operand -- is clear that this only works for instances, and not for subclasses or SKOS relations
• odrl:isPartOf set-based operator indicating that a given value is contained by the right operand of the Constraint -- "contains" means what? (as above with equals) Can this be a list and then the value is exact IRI within it, or a subclass, etc.

So to use the same phrases, what I want is something like odrl:equivalentTo where the value of the right operand is equal, instance, or subclass of it such that the right operand is semantically equivalent or contained within the left operand. Without this, if I use odrl:eq and write a policy checking script, I have no way of specifying to the implementer whether I'm expecting IRI match or something else. So the implementation meaning of these constraints/operands should also be clear rather than just their abstract notion.

[joshcornejo]

My thoughts,

• odrl:eq is part of the set (:lt, :gt, :lteq, :gteq, :neq) across some linear values that can be instance evaluated and can be in order; you should interpret it as a functional operator, not semantic. Hence why I proposed option 1 and option 2 (one is a string, the other is an instance in a set that 'could be' ordered).
• odrl:isA (option 3) allows you to have "purpose instances" inside some vocabulary (or hierarchical taxonomy if you want to make it richer) and fine-tune on your specific policy.
• You can implement your own dpv:equivalentTo to achieve your desired outcome in your profile; it doesn't need to be part of the core vocabulary.
• Finally IMHO, in policy, you are trying to sieve through with precision, "equivalencies" and "conversions" should be discouraged. Similar to how legal contracts promote the use of the word "must" to narrow interpretation, and "should, could, would" are discouraged as they do the opposite.

[riannella]

So, the one ODRL property "Semantic equivalence" would cover the semantics of these 5 predicates: rdf:type rdfs:subClassOf skos:broader owl:sameAs skos:exactMatch

What about OWL equivalences (for class and properties) and RDFS sub properties?

Why not use these predicates directly?

That is explicit and clearer semantics ....(otherwise an evaluator will have to check up to 8 different predicates to ensure completeness?)

[coolharsh55]

Hopefully a simpler example. Contract says I MUST NOT do any Advertising. My data graph says I am doing Advertising. How do I represent this in ODRL?

The policy can have two checks: 1) odrl:eq dpv:Advertising for matching concept IRI is exactly Advertising and 2) odrl:isA dpv:Advertising for matching an instance of Advertising.

If I only include the odrl:isA constraint, then for the data graph to indicate you are doing Advertising, there MUST be a blank node [ a dpv:Advertising ] in order to trigger the second rule, which is a terrible ask because blank nodes like this are bad practice and represent an unknown instance of advertising rather than advertising itself, which means I cannot compare two blank nodes as being the same concept of advertising.

dpv:Process dpv:hasPurpose dpv:Advertising . # unmatched
dpv:Process dpv:hasPurpose [ a dpv:Advertising ] . # matched

If I only include the odr:eq constraint, then for the data graph to indicate you are doing Advertising, there MUST be the concept Advertising, as any instance of it won't trigger the rule.

dpv:Process dpv:hasPurpose dpv:Advertising . # matched
dpv:Process dpv:hasPurpose [ a dpv:Advertising ] . # unmatched
ex:DirectAdvertising rdf:type dpv:Advertising .
dpv:Process dpv:hasPurpose ex:DirectAdvertising . # unmatched

Writing both for each constraint makes the policy long and verbose.

So my point is that there is no ODRL property that actually matches what such a contract is trying to communicate i.e. "anything which is this concept" for permissions, and "anything which is not this concept" for prohibitions. I would have accepted odrl:eq as communicating this, but as has already been pointed out in the thread, the meaning if eq is mathematical/functional and not semantic. And odrl:isA is bound to RDF instantiation due to its definition text. So there is a gap in specifying what written language says and its implementation in RDF.

*edit added example RDF

[riannella]

Ok...so (just so I am clear...) we are all happy with:

The policy can have two checks: 1) odrl:eq dpv:Advertising for matching concept IRI is exactly Advertising and 2) odrl:isA dpv:Advertising for matching an instance of Advertising.

...that is, odrl:eq asserts equality to the URI and odrl:isA assert instance relation to the URI

Hence, what you are after is a single way to do both at the same time?

[coolharsh55]

Yes (but since semantic equivalence depends on the method used, implementations may also want to use subclassof, skos relations, etc. -- this can be a note so as to not restrict the usefulness)

[joshcornejo]

Hopefully a simpler example. How do I represent this in ODRL?

This is a prohibition: Contract says I MUST NOT do any Advertising.

Data graph says I am doing Advertising.

If your graph says you are "doing" advertising, that means that the evaluator is not working correctly and your enforcement/decision points need to be fixed.

It is like saying "contract says MUST NOT allow door to open without key" ... but you see evidence that the door can be opened - the problem is in the lock, not in the policies.