Constraints and requirements modeling and verification

Databases and data exchange messages may contain specifications of constraints and specifications of requirements for information. Those constraints and requirements specifications may also be used to verify whether the same or other databases and data exchange messages satisfy those constraints and requirements. This article introduces the modeling and verification of various kinds of them.

Constraints on roles and role players

Relations relate objects that play roles of different kinds in the relations. Those roles may exclude each other. There are different categories of these constraints. For example:

A) Conflicting roles in the same relation (Irreflexivity constraints): For many kinds of binary relations it is specified that in a relation of such a kind the two role players may not be the same thing. In other words, something may not play both roles in a relation of such a kind. This is also called the irreflexivity constraint. The applicable kinds of relations are therefore specified as being a subtype of the kind ‘irreflexive relation’. For example, a person may not have a role as father and a role as son in the same father-son relation; although those two roles may be played by the same person in different relations of that kind.

B) Conflicting roles in the different relations (Disjunction constraints): It may be explicitly specified that two kinds of roles in different relations may not be played by one role player at the same time, thus for one role player it holds that playing a role of one kind <is incompatible with> playing a role of the other kind. Note that this constraint can be universal (it is knowledge that holds for possibilities) or it can be a local constraint that only holds within a particular validity context.

Mutually excluding kinds (disjoint constraints)

Individual things may be classified multiple times. This implies that one of the classifying kinds should not exclude that its members are also members of the other kind(s). Such non-excluding kinds are said to overlap each other. For example, an individual thing can be classified as a centrifugal pump and at the same time as a vertical pump. This implies that there may exist vertical centrifugal pumps. However, there are also kinds that mutually exclude each other. For example, being a man excludes being at the same time a woman. Thus a man <is by definition excluded from being a> woman. Such exclusion relations between kinds usually represent trivial knowledge and constraints for people, but they may be added to an ontology or database definition in order to enable semantic consistency verification.
Note: constraints this kind are often said to be constraints on subtype-supertype relations, because in such a case the supertypes has mutually excluding subtypes. However, it is a constraint on the classification of individual things, which is independent on the question whether the classifying kinds are subtypes of the same (direct) supertype or not.

Simultaneous cardinality constraints (frequency constraints)

The number of statement relations of a particular kind between a thing and other things shall always remain within the specified minimum and maximum number of relations at some point in time (within the validity context). This means that when an allowed relation is deleted or terminated, then another new relation may be added, provided that there are no life time cardinality constraints.
Note that cardinality constraints on possibilities are supposed to have an universal validity, whereas cardinality constraints on requirements have a validity context within which the requirement and the constraints hold.

Requirements verification

Requirements express that relations of a particular kind shall exist between things of particular kinds, whereas those requirements only hold in a particular business or government context. The semantics of a requirements relation differs from the semantics of a realized relation. For example, a kind of requirements relation such as <shall have as part a> is a relation between kinds of things that has a different meaning that a <has as part> relation, which is a factual relation between individual things. Because of these differences it is required that a formalized language defining ontology shall include an explicit specification of which kinds of expressions satisfy requirements and which kinds of expressions violates them. For example, in Formal English it is specified that a composition relation between individual things, expressed by the phrase <has as part> can satisfy (can be a realization of) a required composition relation between kinds of things, expressed by the phrase <shall have as part a>.
Those realization relations forms the basis of a search for the statement(s) that satisfy the requirements.

Expressions of requirements can be distinguished in quasi-unconditional expressions and conditional expressions.
Conditional expressions of requirements have the form of if-then(-else) clauses.
An example of a quasi-unconditional expression of a requirement is: a centrifugal pump <shall have as part an> impeller; or a car color <shall be one of a> collection of car colors-1, which condition is accompanied by an explicit specification of the elements in the collection.
Such expressions are quasi-unconditional because they are interpreted as conditional. For example, the first one is interpreted in the following way: if an individual thing <is classified as a> centrifugal pump, then it <shall have as part an> individual thing that <is classified as an> impeller.
Note that such a requirement is inherited by all the subtypes of the concept for which the requirement holds (centrifugal pump) and thus for all individual things that are classified by one of those subtypes. For example it also hold for individual things that are classified as a ”line shaft pump” (which according to the dictionary-taxonomy is defined as a subtype of centrifugal pump).