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