Repository navigation
Consider "inclusive" and "exclusive" variants for hierarchical operators such as subClass and superClass #155
Description
This furthers the final caveat remark of #154 , also relating to #28 .
Using the same vocabulary (purpose hierarchy) as in #154, it would be difficult to specify a constraint / rule like below:
anything that is a subclass of ResearchAndDevelopment but not CommercialResearch
The main problem is: superClass is inclusive (like subClass; both should behave the same way), so it's difficult to specify "superclasses of the target concept, non-inclusively"
Introducing the non-inclusive variants of the inclusive subClass and superClass would be a solution to this. I can think of two naming options:
- They may be called
subClassNIandsuperClassNI, if not wanting to change the name ofsubClassandsuperClass; or - Unify both variants as
subClassFrom/subClassBelow, andsuperClassFrom/superClassAbove.
If that's defined, the constraint can be easily and intuitively specified (I'm using Option 1):
odrl:constraint [
a odrl:LogicalConstraint ;
odrl:and (
[
odrl:leftOperand odrl:purpose ;
odrl:operator odrlCV:subClass ;
odrl:rightOperand dpv:ResearchAndDevelopment ;
]
[
odrl:leftOperand odrl:purpose ;
odrl:operator odrlCV:superClassNI ;
odrl:rightOperand dpv:CommercialResearch ;
]
)
]
There is a potentially related issue: CommercialResearch exists in two places, both under ResearchAndDevelopment and CommercialPurpose; thus the solution should be robust to that. I feel the one proposed above satisfies this.
But I'm not entirely sure if it would occasionally be unintuitive if not reasoned (in head) carefully. I can't think of an example yet, but maybe someone else can?
Activity
riannella commentedon Jun 4, 2026
A real-world example would be good - is this used in the community now?
besteves4 commentedon Sep 7, 2026
@renyuneyun in this case, you can just prohibit
dpv:CommercialResearch, right? I don't see a use-case that could not be solved with either a prohibition or with the proposal at #154Daham-Mustaf commentedon Oct 29, 2026
@riannella a use case: data licensed free for R&D but not for commercial research, which needs a paid licence. It is a scenario, not a deployed policy.
From a formal semantics I am working on: inclusive and exclusive variants are easy to define once the taxonomy is read as an order.
subClass Xis X and everything below it, and the exclusive variant drops X; the same holds upwards forsuperClass. But clearer operators alone do not decide this use case. The result depends on facts the vocabulary may not publish.Excluding a branch needs disjointness. To accept a purpose under "R&D but not CommercialResearch", an evaluator must know that the purpose lies outside CommercialResearch. DPV publishes what lies below what, not what lies outside, and it states no disjointness between purposes. Nothing says
dpv:AcademicResearchis outsidedpv:CommercialResearch, and DPV defines a commercial purpose as one "in a commercial setting or with intention to commercialise", so one project can be both.Excluding by name needs distinctness.
isNoneOfandneqcompare names. Whether two names denote different purposes is again a fact DPV does not state.The world assumption decides the rest. A closed-world evaluator reads a missing statement as "not below" or "different" and accepts the use silently. An open-world evaluator can only report it as undecided until the vocabulary publishes the fact or the parties declare it. A prohibition, as @besteves4 suggests, needs the same fact: whether it applies to academic research is exactly what DPV leaves open.
So a new operator should come with a statement of which facts an evaluator may use (published or declared disjointness and distinctness) and how a missing statement is read.
Worked cases with expected results: https://github.com/Daham-Mustaf/odrl-grounded-benchmark/tree/b7ac3c9766102d699b0cdaa55d62a121bbd9166f/cases