Consider "inclusive" and "exclusive" variants for hierarchical operators such as subClass and superClass

[renyuneyun]

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:

1. They may be called subClassNI and superClassNI, if not wanting to change the name of subClass and superClass; or
2. Unify both variants as subClassFrom / subClassBelow, and superClassFrom / 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?

[riannella]

A real-world example would be good - is this used in the community now?