From the perspective of the current conceptual data model, the use of the powers assigned to mandatees (or mandators with delegated powers) may be constrained (not the power in itself). As constraints are linked to Mandator and Mandatee, and these to Power, there are two 3-nary relations between: 1) Power - Mandator - Constraints; and 2) Power - Mandatee - Constraints. This should be
enough to discriminate which constrains apply to which mandatee and for which mandatees's power.
The constraints cannot totally be agnostic of the power, though: there is the need of validating
whether the constraint makes sense in relation with the power used by the mandatee. Thus,
having a mandate saying that the mandatee has the power to request a residence in a EU MS and,
simultaneously, a mandatee's constraint `MaxContractValue seems senseless. Hence the
'ccev:type' (defined by the Core Criterion and Evidence Vocabulary) is proposed in RPaM to anchor the constraint to the narrowest related concept (category) of the EU Power Taxonomy. The fact that the constraint could not be anchored would imply that either the
EU Power Taxonomy has an opportunity to grow o that the constraint is not well defined.
NOTE for evolution: using the property "type" of the criterion is not very smart, as it should
be reserved for other purposes (i.e. to clarify the "nature" of the criterion). A nicer solution
could be to extend the ccev:Criterion vocabulary with a rpam:Constraint class and, in this latter,
to define an ObjectProperty powerType subclassing (subClassOf) the ccev:type property.
From the perspective of the current conceptual data model, the use of the powers assigned to mandatees (or mandators with delegated powers) may be constrained (not the power in itself). As constraints are linked to Mandator and Mandatee, and these to Power, there are two 3-nary relations between: 1) Power - Mandator - Constraints; and 2) Power - Mandatee - Constraints. This should be enough to discriminate which constrains apply to which mandatee and for which mandatees's power.
The constraints cannot totally be agnostic of the power, though: there is the need of validating whether the constraint makes sense in relation with the power used by the mandatee. Thus,
having a mandate saying that the mandatee has the power to request a residence in a EU MS and, simultaneously, a mandatee's constraint `MaxContractValue seems senseless. Hence the 'ccev:type' (defined by the Core Criterion and Evidence Vocabulary) is proposed in RPaM to anchor the constraint to the narrowest related concept (category) of the EU Power Taxonomy. The fact that the constraint could not be anchored would imply that either the EU Power Taxonomy has an opportunity to grow o that the constraint is not well defined.
NOTE for evolution: using the property "type" of the criterion is not very smart, as it should be reserved for other purposes (i.e. to clarify the "nature" of the criterion). A nicer solution could be to extend the ccev:Criterion vocabulary with a rpam:Constraint class and, in this latter, to define an ObjectProperty
powerType
subclassing (subClassOf) theccev:type
property.