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.