Add "superClassOf" into Community Vocabulary?

[renyuneyun]

The discussion of issue #28 led to the introduction of seq and subClass[Of] in the Community Vocabulary. As a useful flipside of subClass, is it appropriate to also introduce superClass[Of] into the Community Vocabulary?

Intuition: superClassOf shall be used to restrict the lower bound of the range / possibilities within a class/concept hierarchy, usually used together with subClassOf to restrict also the upper bound.

Alternative solution: use a logical NOT together with subClass and eq -- that's quite complicated, to be fair.

For example, assume we use the purpose hierarchy below (from DPV Purposes):

Purpose
|- CommercialPurpose
    |- CommercialResearch
|- Personalisation
    |- PersonalisedAdvertising
        |- TargetedAdvertising
            |- RecruitmentTargetedAdvertising
|- ResearchAndDevelopment
    |- AcademicResearch
    |- CommercialResearch
    |- NonCommercialResearch
    |- ScientificResearch

Case:

Any concept between Personalisation and TargetedAdvertising -- not including any other subconcepts of Personalisation, nor RecruitmentTargetedAdvertising (and its subconcepts)

odrl:constraint [
    a odrl:LogicalConstraint ;
    odrl:and (
        [
            odrl:leftOperand odrl:purpose ;
            odrl:operator odrlCV:subClass ;
            odrl:rightOperand dpv:Personalisation ;
        ]
        [
            odrl:leftOperand odrl:purpose ;
            odrl:operator odrlCV:supClass ;
            odrl:rightOperand dpv:TargetedAdvertising ;
        ]
    )
]

---

Caveat: the "inclusion of the target concept" can be a tricky point, as that may block certain use cases. E.g. it's not easy to specify to allow ResearchAndDevelopment but not CommercialResearch. This applies to both subClass and superClass. I created #155 for this discussion.

[riannella]

(Note: we plan to update subClassOf to typeOf in next update...)

I think this is better done using the ODRL Information Model.
That is, if you are not allowed to do something, then that should be explicit.

So, that would mean we have a Permission that includes the purpose constraint with dpv:Personalisation.
And a Prohibition that includes the purpose constraint with dpv:TargetedAdvertising
And we set the policy "conflict" property to "prohibit" - meaning these will override the Permissions (full hierarchy list).

[renyuneyun]

My apology for the wrong expression of "permission of xxx" in the initial version of the issue -- having updated that in later edits on github webpage, but probably email stayed the same.
(And thanks for reminding typeOf... I just meant to make the relation between words more obvious, so continued to use subclass... Happy with whatever appropriate words.)

Basically, I have changed how the case was phrased: it's "a constraint of purposes between ...", which could be either in a Permission, a Prohibition, or Duty / obligation.

The workaround you suggested is valid for Permissions (and Prohibitions, probably), but not for Duties / obligations, if I understand it correctly -- you cannot set an "obligation override".
To help illustrating, we may have this policy:

The assignee needs to send an automated email to the assigner for their usages of the target, if the purpose is between dpv:Personalisation and dpv:TargetedAdvertising. (There may be other obligations, e.g. to directly call the assigner, if other constraints satisfy.)