2.1.1. Considered Constraints: Those Not Used For Inferences, Just For Checks

In this article, as in KIF (Knowledge Interchange Format) [Genesereth & Fikes, 1992], a rule is a statement that can be represented – directy or via a loss-less translation – in the form “X =>> Y” where “=>>” is a restricted version of the logical implication ( “X => Y”): it only supports modus ponens, not modus tollens. An inference supporting statement is either a rule or a statement that can be represented in the form “X => Y”.

A rule allowing the derivation of a non-modal statement is a rule that can be represented in the form “X =>> Y” where Y does not include a modality (e.g., must). An example is “if x is a Person then x has a parent”. If this statement and “Tom is a Person” are in a KB, an inference engine can derive the non-modal statement “Tom has a parent”.

[Chein & Mugnier, 2008] defines constraints as positive or negative, respectively expressing statements of the form “if A,  B must be true” and “if A,  B must be false”. Thus, the authors define constraints as rules where the conclusion has a “must” modality. These are the kinds of constraints considered in this article, with the interpretation that in such constraints the “must” entails that the constraints can only be used for checking statements, not deriving statements. Thus, constraints are not rules allowing the derivation of non-modal statements. More formally, this means that such positive or negative constraints can respectively be translated into the forms “A ∧ ¬B =>> false” and “A ∧ B =>> false” where A and B do not contain a “must” modality and A may be empty. As an example, consider the positive constraint “if x is a Person, x must have a parent”. From this constraint and the fact “Tom is a Person”, an inference engine must not derive “Tom has a parent”. It may derive “Tom must have a parent” but, in practice, such derivation is not performed. As a somewhat opposite example, RDFS-aware engines do not exploit relations of type rdfs:domain or rdfs:range as relation signature constraints but as inference supporting statements: when a relation r has a type partially defined with an rdfs:domain (vs. rdfs:range) relation, RDFS-aware engines infer a type for the source (vs. destination) of r.

In this article, constraints that are directly represented in a form ending by “=>> false” – or, equivalently, “=>> ⊥” – are called constraints in inconsistency-implying form. Not all KRLs allow to represent rules (instead of – or in addition to – implications); in those that do, representing negative constraints using the inconsistency-implying form is easy but using this form for representing positive constraints may not possible: the KRL may not permit the representation of the negation in the “¬B” part. This in why in this article i) negative constraints are represented in inconsistency-implying form, and ii) positive constraints are in the form “A =>> B” but have a type that distinguishes them from actual rules. Furthermore, as in most rule-based systems, in the rest of this article the A and B parts share variables. More precisely, these parts are representations of relations from a same object (i.e. from a type or an individual, including a relation or a more complex statement since they are particular kinds of individuals). Thus, checking if a positive constraint is violated by an object in a dataset is checking if the object matches – that is, specializes – the condition of the constraint but not its conclusion. In other words, both the condition and conclusion of a positive constraint should be logically derivable from the object, possibly using various inference supporting statements from the KB.

In the research literature on constraints, these ones are generally not represented – or checked – via modal logic based KRLs but rather using queries, e.g. via SPARQL or the nonmonotonic-epistemic-logic query language EQL-Lite [Calvanese et al.]. In (unidirectional) rule based systems, rules with empty conclusions (or “false” as conclusions) are handled like constraints. However, this is a particularity of these systems. It should not be relied upon for general knowledge representation purpose. For such a purpose, the special semantics of constraints has to be made explicit via special syntactic sugar or special types. Since KRLs rarely propose syntactic sugar for expressing constraints, a more generic approach for expressing that a statement is a constraint, as opposed to an inference supporting statement, is to state that this statement is an instance of a type expressing a particular kind of constraint, as explained in Section 2.1.4. Then, these constraints can be retrieved and exploited by content-independent queries such as those provided below. These constraints can also be directly interpreted and exploited by inference engines designed to take into account the used constraint types. In any case, either i) constraints are not represented in a way they can be exploited as inference supporting statements, or ii) the results of these inferences must not be detrimental, i.e., must not influence the checking of constraints. Both techniques will be illustrated in Section 2.3.1 and Section 3.

2.1.2. Prescriptive (i.e. Not Using All Possible Inferences) vs. Descriptive

As noted in [Assmann & Wagner, 2006], one common distinction between engineering models is whether they are i) descriptive of some reality, like most ontologies are, or ii) prescriptive of what must be in the considered dataset, as with system specifications, meta-models, XML schemas, database schemas, SHACL, etc. Similarly, this article distinguishes two kinds of constraints: descriptive constraints and prescriptive ones. As detailed at the end of this subsection, the notion of prescriptive constraints as defined in this section is original. Before seeing precise definitions, let us first see different purposes of these two kinds of contraints, as well as general (purpose-derived) definitions and examples for these constraints.

• Different purposes. Like a definition or an axiom, a descriptive constraint is a declarative way to ensure that, if certain terms are used (i.e., if a certain condition involving these terms is met), these terms are used in a certain correct way. On the other hand, using a prescriptive constraint is meant to ensure that if a certain condition is met, certain formal terms are i) actually used, and ii) that this use is not due to inferences. However, given that the conclusion of descriptive constraints can often (or, with a sufficiently expressive KRL, always) also be exploited for checking that certain terms are actually used, supporting this goal cannot be used as a distinguishing feature for prescriptive constraints: their main interest comes from this checking that certains uses of certain terms are not due to inferences.
• General definitions and examples. To sum up the previous paragraph and the previous subsection, descriptive and prescriptive constraints are rules only usable for checking statements and, unlike descriptive constraints, prescriptive ones ensure that certain uses of certain terms are not due to inferences. A prescriptive constraint is only about the content of a KB; e.g.: “if x is a Person, x must have a parent in the base of facts (prescriptive-must)”. A descriptive constraint is still a partial representation of a world; e.g.: “if x is a Person, x must have a parent in the represented world (descriptive-must)”. Rules which are not constraints are also representations of a world; e.g.: “according to most laws, if x is a Person, x must not kill another Person (deontic-must)” and “if x is a Person, x has/had a parent (according to observations)”. A prescriptive constraint is meant to ensure that whenever people or software agents create an instance of a certain type, they explicitly associate certain relations to this instance. Here, “explicitly” specifies that these relations must not exist just because they were automatically deduced – e.g. by exploiting type definitions or, in other words, by type definition expansion – but only because these relations were (manually or automatically) set by an agent when creating or modifying the dataset. As an example, assume that a KB includes the non-modal rule “if x is a Person, x has a parent” and that a user enters that “John is a Person” in the base of facts of this KB (this base is the set of relations from/to individuals; for a description-logic based KB, this is its A-box). Even if this KB also includes the descriptive constraint “if x is a Person, x must have a parent in the represented world (descriptive-must)”, an error message should not be given by a KB checking mechanism since this constraint is satisfied (by inferencing) without the user having to represent a parent for John. On the other hand, if the KB includes the prescriptive constraint “if x is a Person, x must have a parent in the base of facts (prescriptive-must)”, the adding of a new person without a relation to a parent must now be rejected.

In the approach proposed by this article, constraints have types or use particular relation types. These types permit the distinction between the different kinds of constraints and their distinction from non-modal rules: the “must” modalities are represented via these types. These distinctions can thus be exploited by content-independent queries, inference engines or special procedures.

A constraint in inconsistency-implying form (e.g., “A ∧ B =>> false”) is meant to ensure that certain uses of terms are not used in a KB. In this case, “prescriptive” means that the non-existence of these uses is not due to inferences, and hence “descriptive” means that it does not matter whether or not the non-existence of these uses is due to inferences. However, what would be the interest of such prescriptive constraints? Indeed, inferences leading to the existence of unwanted relations need to be caught too. The situation is different from the one for wanted relations where, as above illustrated, it may be interesting to specify whether or not these relations can be inferred. Thus, at least in this article, all constraints in inconsistency-implying form are considered to be “descriptive”. If the used KRL supports negations, a constraint in inconsistency-implying form can specify that the non-existence of a certain use of a term is an inconsistency and thus that this certain use must exist in the KB – e.g. “A ∧ ¬B =>> false” may be used to ensure that B is true when A is true. Such a constraint is descriptive since it allows the existence of this certain use to be due to any inference.

When trying to match an object (in the dataset) to the condition of a constraint, in order to avoid missing a match i) the expressiveness used for the inference regime must be at least equal to the language expressiveness that was necessary for describing the object, and thus ii) there is no reason to restrict the exploitation of certain inference supporting statements. This is also true when trying to match an object to the conclusion of a descriptive constraint. However, when trying to match an object O to the conclusion C of a prescriptive constraint, a certain set of inference supporting statements should not be used since a prescriptive constraint is meant to ensure that certain uses of certain formal terms – i.e. the use of these terms in certain relations – is not due to inferences. In this article, this set is called R. It is the set of all inference supporting statements that could automatically associate relations to an object – and thus, in the above generic case, to the object O – except for type relations (and subtype relations if the object is a type). There are several reasons for that exception. In the following arguments, the expression “type relations” also refers to subtype relations and thus “non-type relations” also exclude subtype relations. One pragmatic reason for the exception is that, for matching O to C, it is necessary to exploit type relations from O as well as from all the objects that are destinations of non-type relations from O. Fortunately, this is not the sole reason: there is also no point for the conclusion of a prescriptive constraint to check if O is of a certain type. Indeed, this does not help ensure that non-inferred genuine knowledge is associated to O since i) without their definitions involving other relations than type relations, types would not constrain any use for their instances and, in that sense, would not have any genuine meaning, and ii) exploiting these definitions for checking whether O has a certain relation would be checking if O has a certain inferred relation, something which a prescriptive constraint is not meant to support. This last point is also a reason of its own for the above cited exception. For a definition of what prescriptive constraints mean with respect to how they are checked, first note that inferencing via forward chaining saturation statically adds relations to objects. On the other hand, with backward chaining, inferred relations are temporarily or virtually added or associated to objects. Second, consider KB0 the version of the KB before the exploitation of R by forward chaining saturation adds the inferred relations. Then, whether or not inferencing involves forward chaining saturation, testing if O matches C is trying to find if O0 permits the derivation of C via inference supporting statements in “KB0 minus R” (KB0\R), i.e. testing if “O0 (KB0\R) ⊢ C”.

In OWL, only a class or an instance of a class can have an automatically associated non-type relation – with “non-type” still also excluding subtype. E.g., a relation type cannot have such an associated relation; associating a property chain to a relation type is no exception since this association is made via a subtype relation. Thus, in OWL, the automatic association of a non-type relation to an object is only supported by class definitions via property restrictions, i.e. instances of owl:Restriction. In other words, this association is only supported by class definitions not restricted to specifying that the class is i) subclass, superclass, intersection or union of other classes, or ii) type or instance of other objects. Thus, in an OWL based KB, R is the set of restrictions, and KB0\R is KB0 where the body or content of each restriction has been removed. In other kinds of KBs, R is different since they offer other ways to express universal quantification and thus other inference-based means to associate non-type relations to objects. In any case, removing inferred non-type relations or not taking them into account can be done automatically, in different ways depending on the features on the used system: general purpose inference engine, ad hoc procedural implementation, etc. The following summary of approaches not only refers to R but also to Tbox, i.e. R plus the types, their subtype relations and their type relations. In a Description Logic based KB, Tbox refers to its T-box while KB\Tbox refers to its A-box, i.e. the individuals, the relations between them, and the type relations from individuals to types.

• When the system can exploit two KBs at the same time. In this case, one KB (KB0') can be initialized with KB0 and the other (KB0\R') with KB0\R, although in both KBs each existentially quantified anonymous object must be given a generated unique identifier – so that from each object in KB0\R', its possibly extended counterpart in KB0' can be retrieved. Then, for each prescriptive constraint C and object O in KB0, C can be checked if the system can i) test if O in KB0' matches the condition of C (in KB0'), and then, if needed, ii) test if O in KB0\R' matches the conclusion of C (in KB0\R'). This method works whether inferences involves forward chaining saturation or just backward chaining. If the constraint checking system is implemented in an ad hoc procedural way, via calls to a function testing if an object matches another one in a given KB, specifying and connecting the two above cited tests is not difficult. In the current standard versions of SPARQL, using “inline data” (and hence the VALUES keyword) or “named graphs” (and hence the FROM keyword), it is possible to perform queries on different KBs and use a same object identifier in the queries to relate them. However, it is not yet possible to use a same variable to relate the results of queries on different KBs. With an extension of SPARQL such as LDScript [Corby, Faron-Zucker & Gandon, 2017], based on the results of one query, it would be possible to generate another query with the results of the first query hardcoded in it, and thus solve the problem. The names of the KBs would also have to be hard-coded. This approach is not explored in this article.

• When the system can exploit only one KB but, within this KB, at least KB0\Tbox can be duplicated in a way that does not trigger R (or at least not in a problematic way). The idea here is to distinguish between inferred statements and those in KB0. To do so, a first way is that each inferred object or statement is automatically marked as such, e.g. via a special type or relation associated to it or to at least one of its parts. A second way is that, when initializing the KB with KB0, each object in KB0\Tbox – or the whole KB0 for simplicity purposes – is duplicated into a “saving form” that later permits to regenerate the object as it was in KB0. One such form is a reification of the object, with a special type or special relations for i) distinguishing this “reification for duplication purposes” from other reifications, ii) distinguishing its initial relations from those that might be added to it via inferences, and iii) automatically discarding this saving form from the results of a query when it appears in such results. With both ways, for each prescriptive constraint C and object O that is not a duplication, C can be checked in two steps. The first step is to test if O matches the condition of C. The second step is to test the conclusion, if still needed. With the first way, this second step consists in performing this test without involving the marked inferred objects or statements. Since in the general case a general purpose inference engine cannot be parameterized to support this first way, it is not explored in this article. With the second way, i.e. the saving form based way, the conclusion matching test is performed not with the current O but with a complete or partial copy of O as it was in KB0. In this article, this copy is called a “clone without inferred relations” or simply a clone. This clone is not necessarily a complete copy of the initial O. It is only a partial copy when i) this is not detrimental for the conclusion matching test, and ii) this permits the clone to be directly the “saving form” instead of being regenerated from this form. In practice, “initializing the KB” is simply opening or importing the file containing KB. Creating the saving form can be performed by pre-treating the KB, i.e. modifying the KB as soon as it is initialized and before any potential forward chaining saturation process is triggered. KB treatments or pre-treatments may for example performed via SPARQL update requests. Regenerating clones from saving forms may be performed statically, i.e. via a treatment of the KB before the checking of prescriptive constraints. It may also be performed dynamically, i.e. by temporarily generating certain clones just before checking the conclusion of certain constraints.

• When the system can exploit only one KB but all inferences are performed via backward chaining and either i) R can be temporarily disabled or removed, or ii) KB0\R can be temporarily duplicated. With backward chaining, inferred relations are only temporarily or virtually added or associated to objects. Thus, if all inferences are performed via backward chaining, KB0 is not statically modified and, more importantly, testing whether or not an object O matches the conclusion of a prescriptive constraint C can be performed by i) temporarily removing R or disabling the use of R, just for the time of the test, or ii) testing the match in a temporary copy of the KB where R is absent. Since in the general case a general purpose inference engine does not support specifications for temporary disabling the use of certain inference supporting statements, this method is not explored in this article. The two other cited ways first involve duplicating R into saving forms – before each conclusion matching test or, once and for all, when the KB is initialized. Then, just before testing if an object O matches the conclusion, either i) R is removed before the test and restaured from the saving forms after the test, or ii) a temporary copy of (a relevant part of) the KB except for R is created and the test is performed within this copy. In this last described approach, “relevant” means “all the objects that can be reached from O via a sequence of relations” instead of all the KB.

Section 2.2.2 proposes three methods based on clones and/or saving forms: two methods based on the last described approach in the above second point and one method based the last described approach in the third point. These methods exploit a general purpose inference engine and a SPARQL-like language. Each method has different limitations.

The notion of prescriptive constraints as above defined is original: to our knowledge, in other works on constraints, these ones apply on statements of the KB whether they have been inferred or originally provided. Since these works do not provide ways to make the differences between those two kinds of statements, the constraints they handle are by default descriptive. Yet in other words, since these works do not provide a mechanism for temporary disabling – or ignoring the results of – some inferences only when checking the conclusions of the constraints, the only way to handle these constraints as prescriptive constraints (in its above defined sense) is to disable – or ignore the results of – some inferences not only during the checking of their conclusions but also during the checking of their conditions. Thus, some inferences may be missing for a complete checking of the checking of the conditions.

A constraint, whether descriptive or prescriptive, is intended to check the existence (or absence of existence) of certain objects in a KB. To that end, constraint checking needs to exploit some form of closed world assumption. When SPARQL is used for checking constraints, the closed world assumption related parts can be represented via the operators EXISTS and NOT EXISTS. In this article, SPARQL is used for the content-independent queries (cf. Section 3) and only the operator EXISTS had to be used in these queries. Furthermore, with such queries, there is no need to represent any closed world assumption related part in the constraints themselves. Thus, the inference engines used for matching objects of the KB to the constraints need not use the closed world assumption. Hence, regular inference engines for OWL can for example be reused.

2.1.3. Restriction of Some Constraint Parts to Named or Anonymous Individuals

It is sometimes interesting to create constraints allowing certain relations from individuals to be inferred only if these individuals are named, i.e. only if they are not anonymous individuals (hence, in the RDF terminology, not “blank nodes”). E.g., assume that a user wants to ensure that each instance of Person has a parent relation, inferred or not as long as its destination is named. To do so, using a prescriptive constraint is not possible since, by definition, it would not accept inferred named parents. A solution is to write two constraints: i) an inconsistency implying one stating that an instance of Person without a(n inferred or not) parent relation is an error, and ii) a descriptive constraint specifying that the destination of each of these parent relations must be named.

As long as named individuals are represented in the constraints the same way they are in the rest of the KB, any way can be used and no special content-independent query has to be introduced. One way is to type named individuals with owl:NamedIndividual – this is the way used in one of the examples of Section 2.3.3. Since doing so by hand may be tedious, Section 3.1.2 proposes a SPARQL update request that automatically adds such a type to named individuals.

2.2.1. Using Constraint Types

[Tao et al., 2010] shows that representing and checking certain kinds of integrity constraints that exploit some forms of the Unique Name Assumption or Closed World Assumption can be performed via SPARQL queries. Instead, as explained in the introduction, the goal is here to enable the representation of constraints that i) can be exploited via content-independent queries, ii) can be represented via any KRL that has an expressiveness at least equal to RDF or RDFS, and iii) can be marked as descriptive or prescriptive (this distinction is not made in [Tao et al., 2010]).

To that end, the proposed approach is to introduce a few types for constraints. By setting instanceOf or subtypeOf relations from certain KRs to some of those types, KB authors can state that these KRs are constraints and can indicate which kind of constraints. Thus, these constraints can be exploited by content-independent queries or inference engines that understand the used constraint types. This means that these engines know that these types represent particular “must” modalities and know how to handle such modalities. This approach is similar to the use of OWL types in RDF statements and their exploitation by OWL-aware inference engines. The name of the proposed ontology of constraint types is CSTR. In this ontology, cstr:Constraint is the supertype of all types of constraints. Similarly, the type cstr:Prescriptive_constraint, a subtype of cstr:Constraint, enables one to state that some rules are actually prescriptive constraints or to retrieve all and only such constraints. The prefix “cstr:” in these identifiers is an abbreviation for the namespace http://www.webkb.org/kb/it/CSTR. CSTR also includes types for constraint conditions and types for relations between the condition and condition of a constraint. These types are listed in Section 2.3.2.

2.2.2. Using “Clones Without Inferred Relations” For Bypassing Some Inferences When Checking The Conclusions Of Prescriptive Constraints

For the reasons given in Section 2.1.2, this section proposes three clone based methods supporting the checking of prescriptive constraints for when the system can exploit only one KB at any given time. The methods of the next three subsections exploits a general purpose inference engine and a SPARQL-like language. They are each dependent on different features of the used system but they do not rely on a particular logic, KRL, inference engine or tool. In other words, these methods are KRL independent and tool independent in the sense that they can be used with any KRL and any tool satisfying the listed features. Thus, depending on the domain and application, different inference engines can be reused to check or evaluate ontology completeness.

2.3. Representing Constraints Via Relations Between Classes

   ∀X ∀Y ∀Z (isProject(X, Y, Z) => isMember(Z,X))
      #Every leader of a project is a member of this project
  ∀X ∀Y (Researcher(X) ∧ hasExpertise(X,Y) => ∃Z ∃L (isProject(Z,Y,L) ∧ isMember(X,Z)))
      #Every researcher expert in an area is a member of a project in that area
  ∀X ∀Y ∀Z (isProject(X,Y,Z) ∧ isProject(X,Y,Z´) => Z = Z´)
      #Every project has at most one leader

                    cstr:Constraint              cstr:Constraint_condition
                       /\      /\                         /\
                       |      |                       |
cstr:Descriptive_constraint   |      cstr:SubclassOf-based_constraint_condition
         cstr:Prescriptive_constraint                 /\         /\
                                                      |         |
     cstr:SubclassOf-based_descriptive_constraint_condition     |
                   cstr:SubclassOf-based_prescriptive_constraint_condition

cstr#binary_relation  rdf#type: rdf#Property,
 > exclusion    //cstr#binary_relation has the following 5 exclusive subtypes
   { cstr#id    //  (this exclusion set is not complete: this is not a partition)
     cstr#descriptive_constraint_conclusion    cstr#condition_class
     cstr#prescriptive_constraint_conclusion   cstr#conclusion_class
     (cstr#NonInferredRelation < rdf#Statement)
     (cstr#RelationFromPropertyRestriction < rdf#Statement)
   };

cstr#Constraint  rdf#type: cstr#Type_of_constraint,
 > cstr#Descriptive_constraint  cstr#Prescriptive_constraint;

cstr#Constraint_condition
 > (cstr#SubclassOf-based_constraint_condition
      rdf#type: cstr#Type_of_subclassOf-based_constraint_condition,
      > (cstr#SubclassOf-based_descriptive_constraint_condition
           rdf#type: cstr#Type_of_subclassOf-based_descriptive_constraint_condition)
        (cstr#SubclassOf-based_prescriptive_constraint_condition
           rdf#type: cstr#Type_of_subclassOf-based_prescriptive_constraint_condition)
   );

owl#Class
  > exclusion  //owl#Class has the following 3 exclusive subclasses
    { cstr#Type_of_constraint 
      (cstr#Type_of_constraint_condition
         > (cstr#Type_of_constraint_condition_that_is_a_type
              > (cstr#Type_of_subclassOf-based_constraint_condition
                   > cstr#Type_of_subclassOf-based_descriptive_constraint_condition
                     cstr#Type_of_subclassOf-based_prescriptive_constraint_condition
                ) ) )
    };

  [] rdf:type cstr:Prescriptive_constraint;
     cstr:condition_class :Person;
     cstr:conclusion_class
       [rdf:type owl:Class;
        owl:equivalentClass [rdf:type owl:Restriction;  owl:onProperty :parent;
                             owl:someValuesFrom :Person] ].

  [] rdf:type cstr:Descriptive_constraint;
     cstr:condition_class :Person;
     cstr:conclusion_class
       [rdf:type owl:Class;
        owl:equivalentClass [rdf:type owl:Restriction;  owl:onProperty :parent;
                             owl:someValuesFrom :Named_person] ].
  #with:
  :Named_person owl:equivalentClass 
     [rdf:type owl:Class;
      owl:intersectionOf ( :Person  owl:NamedIndividual )].

  [] rdf:type cstr:Descriptive_constraint;  #this rdf:type relation is optional
     cstr:condition_class                   #  for a negative constraint
        [rdf:type owl:Class; 
         owl:equivalentClass [rdf:type owl:Restriction;  owl:onProperty :parent;
                              owl:maxCardinality  "0"^^xsd:nonNegativeInteger] ];
     cstr:conclusion_class owl:Nothing.

  [] cstr:condition_class    #constraint-based version of an rdfs:domain relation:
       [rdf:type owl:Class;
        owl:intersectionOf ( :Not_a_person
                             [rdf:type owl:Restriction;  owl:onProperty :parent;
                              owl:someValuesFrom owl:Thing ] ) ];
     cstr:conclusion_class owl:Nothing.

  [] cstr:condition_class   #constraint-based version of an rdfs:range relation:
       [rdf:type owl:Restriction;  owl:onProperty :parent;
                                   owl:someValuesFrom :Not_a_person];
     cstr:conclusion_class owl:Nothing.
  #with:
  [] rdf:type owl:AllDisjointClasses;  owl:members (:Person :Not_a_person).

  :Person  #class and constraint condition
     cstr:prescriptive_constraint_conclusion
        [rdf:type owl:Restriction;  owl:onProperty :parent;
         owl:someValuesFrom :Person].

  :Person  #class and constraint condition
     cstr:descriptive_constraint_conclusion
       [rdf:type owl:Restriction;  owl:onProperty :parent;
        owl:someValuesFrom :Named_person]. #as previously defined

  :Person_without_a_parent  #class and constraint condition 
     owl:equivalentClass  #definition and constraint condition
        [rdf:type owl:Restriction;  owl:onProperty :parent;
         owl:maxCardinality  "0"^^xsd:nonNegativeInteger];
     cstr:prescriptive_constraint_conclusion  owl:Nothing.

  :Not-a-person_with_a_parent   #constraint-based version of an rdfs:domain relation:
     owl:equivalentClass  #constraint-based version of an rdfs:domain relation:
        [rdf:type owl:Class; 
         owl:intersectionOf ( :Not_a_person
                              [rdf:type owl:Restriction;  owl:onProperty :parent;
                               owl:someValuesFrom owl:Thing ] ) ];
     cstr:conclusion_class owl:Nothing.

  :Thing_having_for_parent_a_Not-a-parent  #constraint for an rdfs:range relation:
     owl:equivalentClass 
        [rdf:type owl:Restriction;  owl:onProperty :parent;
                                    owl:someValuesFrom :Not_a_person ];
     cstr:prescriptive_constraint_conclusion  owl:Nothing.

  :Person  #class and constraint condition
     rdfs:subClassOf cstr:SubclassOf-based_prescriptive_constraint_condition;
     rdfs:subClassOf  #conclusion (types of relations that must be present):
        [rdf:type owl:Restriction;  owl:onProperty :parent;
         owl:someValuesFrom :Person].

  :Person  #class and constraint condition
     rdfs:subClassOf cstr:SubclassOf-based_descriptive_constraint_condition;
     rdfs:subClassOf  #conclusion (types of relations that must be present):
       [rdf:type owl:Restriction;  owl:onProperty :parent;
        owl:someValuesFrom :Named_person]. #as previously defined

3.1. Examples of KB Pre-treatments With SPARQL

INSERT { ?o rdf:type owl:NamedIndividual } WHERE  
{ ?o rdf:type ?t.  #?o has a type ?t
  ?t rdfs:subClassOf ?superClass.  #?t has a superclass
  FILTER NOT EXISTS { ?o rdf:type rdfs:Class }  #?o is not a class
  FILTER isIRI(?o)  #?o is named with an IRI
  FILTER NOT EXISTS { ?o rdf:type owl:NamedIndividual } #?o not yet typed as owl:NamedIndividual
}

DELETE { ?o rdf:type  ?t .  ?t rdfs:subClassOf ?superClass } 
 INSERT{ ?o cstr:type ?t .  ?t cstr:subClassOf ?superClass }
 WHERE { ?o rdf:type  ?t .  ?t rdfs:subClassOf ?superClass 
         FILTER NOT EXISTS { ?o rdf:type rdfs:Class } 
       } 

3.2. Checking Individual-based Constraints With a SPARQL-like language

SELECT ?objectNotMatchingPosConstr ?posConstr_condition ?posConstr_conclusion 
WHERE                  #"posConstr" abbreviates "positive constraint"
{ ?posConstr rdf:type cstr:Descriptive_constraint;
             cstr:condition_class  ?posConstr_condition;
             cstr:conclusion_class ?posConstr_conclusion. 
  FILTER (?posConstr_conclusion != owl:Nothing)
  ?objectNotMatchingPosConstr rdf:type ?posConstr_condition.  #matches condition
  FILTER NOT EXISTS  #objects satisfying the conclusion must NOT be listed
  { ?objectNotMatchingPosConstr rdf:type ?posConstr_conclusion }
}

SELECT ?objectMatchingNegativeConstr ?negativeConstr_condition WHERE
{ ?negativeConstr cstr:condition_class  ?negativeConstr_condition;
                  cstr:conclusion_class owl:Nothing. 
  ?objectMatchingNegativeConstr rdf:type ?negativeConstr_condition.
}

SELECT ?objectNotMatchingPosConstr ?posConstr_condition ?posConstr_conclusion WHERE
{ ?posConstr rdf:type cstr:Prescriptive_constraint;
             cstr:condition_class  ?posConstr_condition;
             cstr:conclusion_class ?posConstr_conclusion.
  FILTER (?posConstr_conclusion != owl:Nothing)
  ?objectNotMatchingPosConstr rdf:type ?posConstr_condition.  #matches condition
  ?objectNotMatchingPosConstr cstr:cloneWithoutInferredRelation ?clone 
  FILTER NOT EXISTS  #objects with clones satisfying the conclusion must not be listed
  { ?clone rdf:type ?posConstr_conclusion }
}

SELECT ?objectNotMatchingPosConstr ?posConstr_condition ?posConstr_conclusion WHERE
{ ?posConstr rdf:type cstr:Prescriptive_constraint;
             cstr:condition_class  ?posConstr_condition;
             cstr:conclusion_class ?posConstr_conclusion.
  FILTER (?posConstr_conclusion != owl:Nothing)
  ?objectNotMatchingPosConstr rdf:type ?posConstr_condition.  #matches condition
  #the two functions called in the next two lines are defined below
  BIND( cstr:createCloneOf(?objectNotMatchingPosConstr) as ?clone )
  BIND( cstr:createTemporaryGraphContainingTheGivenCloneAndTheWholeKBminusTheGivenObject
             (?clone,?objectNotMatchingPosConstr) as ?g )
  FILTER NOT EXISTS { GRAPH ?g { ?clone rdf:type ?posConstr_conclusion } }
}

FUNCTION cstr:createCloneOf (?object)  #the returned clone does not yet have relations
{ uri(concat(str(?object),"_cloneWithoutInferredRelation")) 
}

FUNCTION cstr:createTemporaryGraphContainingTheGivenCloneAndTheWholeKBminusTheGivenObject
              (?clone, ?objectNotMatchingPosConstr)
{ LET (?g = CONSTRUCT { ?clone ?r ?dest .  ?x ?r2 ?y } WHERE
            { VALUES ?clone { UNDEF }  #the clone is not predefined to be only certain objects
              ?objectNotMatchingPosConstr ?r ?y.  #anything reachable from the object
              ?x ?r2 ?y.  FILTER (?x != ?objectNotMatchingPosConstr) #only indirectly reachable
              ?m rdf:subject ?clone.  ?m rdf:predicate ?r.  ?m rdf:object ?dest.
              ?m rdf:type cstr:NonInferredRelation
            }) 
  { xt:entailment(?g) }  #triggers forward chaining saturation on ?g
}

INSERT  #the next line must be removed if the clones must not also be created 
{ ?o cstr:cloneWithoutInferredRelation ?o2.  ?o2 ?r ?dest. 
  ?m rdf:type cstr:NonInferredRelation. #this last type is subtype of rdf:Statement
  ?m rdf:subject ?o2.  ?m rdf:predicate ?r.  ?m rdf:object ?dest   #reification of ?r by ?m
} 
WHERE
{ ?o rdf:type ?t . FILTER NOT EXISTS { ?o rdf:type rdfs:Class }
              ?t rdfs:subClassOf ?superClass .                    #?o is a typed individual
  FILTER NOT EXISTS { ?o  cstr:cloneWithoutInferredRelation ?c1 } #?o must not have a clone
  FILTER NOT EXISTS { ?c2 cstr:cloneWithoutInferredRelation ?o }  #?o must not be a clone

  { #Case 1: supporting the cloning of each individual ?o having at least 1 relation of type
    #        ?r different from owl:sameAs (the INSERT clause adds the relations "?o2 ?r ?dest"
    #        from the clone and also reifies these relations)
    ?o ?r ?dest.  FILTER(?r!=owl:sameAs)
  }
  UNION #Case 2: preventing the useless cloning of an individual having only 1 relation when 
        #        this relation is of type owl:sameAs
  { ?o ?r ?dest  #?o has at least one relation from it
    FILTER NOT EXISTS {?o ?r2 ?dest2. FILTER(?r2!=owl:sameAs) }
  }

  BIND( uri(concat(str(?o),"_cloneWithoutInferredRelation")) as ?o2 )
  #the identifier of ?m incudes those of ?o2, ?r and ?dest:
  BIND( uri(concat(str(?o2),concat("_",
            concat(str(?r),concat("_",
            concat(str(?dest),"_reification")))))) as ?m )
}

DELETE { ?o2 ?r ?dest } WHERE
{ ?o  cstr:cloneWithoutInferredRelation ?o2 .  ?o2 ?r ?dest. 
  FILTER NOT EXISTS { ?m rdf:subject ?o2.  ?m rdf:predicate ?r.  ?m rdf:object ?dest.
                      ?m rdf:type cstr:NonInferredRelation }
}

INSERT { ?o cstr:cloneWithoutInferredRelation ?o2 . ?o2 ?r ?dest } WHERE
{ ?o rdf:type ?t.  FILTER NOT EXISTS { ?o rdf:type rdfs:Class }
              ?t rdfs:subClassOf ?superClass.                     #?o is a typed individual
  FILTER NOT EXISTS { ?o  cstr:cloneWithoutInferredRelation ?c1 } #?o must not have a clone
  FILTER NOT EXISTS { ?c2 cstr:cloneWithoutInferredRelation ?o }  #?o must not be a clone

  { #Case 1: supporting the cloning of each individual ?o having at least 1 relation of type
    #        ?r different from owl:sameAs and rdf:type (the INSERT clause adds the relations
    #        "?o2 ?r ?dest" from the clone)
    ?o ?r ?dest.  FILTER(?r!=owl:sameAs)  FILTER(?r!=rdf:type)
  }
  UNION #Case 2: preventing the useless cloning of an individual having only 1 relation when 
        #        this relation is of type owl:sameAs or rdf:type
  { ?o ?r ?dest  #there is at least one relation from ?o 
    FILTER NOT EXISTS {?o ?r2 ?dest2.  FILTER(?r2!=owl:sameAs)  FILTER(?r2!=rdf:type)  }
  }

  BIND( uri(concat(str(?o),"_cloneWithoutInferredRelation")) as ?o2 )
}

INSERT{ ?m rdf:subject ?restr.  ?m rdf:predicate ?r.  ?m rdf:object ?dest.  #reification of ?r
        ?m rdf:type cstr:RelationFromPropertyRestriction. #subtype of rdf:Statement
      }
WHERE { ?restr rdf:type owl:Restriction.  ?restr ?r ?dest.  FILTER(?r != owl:equivalentClass)
        #the identifier of ?m incudes those of ?o2, ?r and ?dest:
        BIND( uri(concat(str(?restr),concat("_",
                  concat(str(?r),concat("_",
                  concat(str(?dest),"_reification")))))) as ?m )
      }

SELECT ?objectNotMatchingPosConstr ?posConstr_condition ?posConstr_conclusion WHERE
{ ?posConstr rdf:type cstr:Prescriptive_constraint;
             cstr:condition_class  ?posConstr_condition;
             cstr:conclusion_class ?posConstr_conclusion.
  FILTER (?posConstr_conclusion != owl:Nothing)
  ?objectNotMatchingPosConstr rdf:type ?posConstr_condition.  #matches condition
  #the function called in the next line is defined below
  BIND( cstr:createTemporaryGraphContainingTheKBminusR(?objectNotMatchingPosConstr) as ?g )
  FILTER NOT EXISTS { GRAPH ?g { ?objectNotMatchingPosConstr rdf:type ?posConstr_conclusion } }
}

FUNCTION cstr:createTemporaryGraphContainingTheKBminusR (?objectNotMatchingPosConstr)
{ LET (?g = CONSTRUCT { ?objectNotMatchingPosConstr ?r ?y } WHERE
            { ?objectNotMatchingPosConstr ?r ?y.  #anything reachable from the object
              FILTER NOT EXISTS { ?m rdf:subject ?x.  ?m rdf:predicate ?r.  ?m rdf:object ?y.
                                  ?m rdf:type cstr:RelationFromPropertyRestriction }
            }) 
}

3.3. Checking SubclassOf-analogous Constraints With a SPARQL-like language

The usable content-independent queries here are identical to their counterparts in Section 3.2 except for the initialization of ?posConstr_condition and ?posConstr_conclusion since now they are related by a cstr:descriptive_constraint_conclusion relation or a cstr:prescriptive_constraint_conclusion relation. E.g., here is a query for checking subclassof-analogous positive descriptive constraints. See the line in italics for the new initialization.

SELECT ?objectNotMatchingPosConstr ?posConstr_condition ?posConstr_conclusion WHERE
{ ?posConstr_condition cstr:descriptive_constraint_conclusion ?posConstr_conclusion.
  FILTER (?posConstr_conclusion != owl:Nothing)
  ?objectNotMatchingPosConstr rdf:type ?posConstr_condition.  #matches condition
  FILTER NOT EXISTS  #objects satisfying the conclusion must NOT be listed
  { ?objectNotMatchingPosConstr rdf:type ?posConstr_conclusion }
}

There are other ways to write the queries. For example:

• “FILTER (?posConstr_conclusion != owl:Nothing)” could be replaced by “FILTER NOT EXISTS { ?posConstr_conclusion cstr:prescriptiveConclusion owl:Nothing }”. The first way has the advantage of not being dependent on the chosen representation for constraint and hence this way minimizes the difference between the queries. On the other hand, with this way, owl:Nothing cannot be replaced by equivalent class expressions (in SPARQL).
• In Section 3.2.3.1 and Section 3.2.3.4, the line “?objectNotMatchingPosConstr cstr:cloneWithoutInferredRelation ?cloneWithoutInferredRelation” before “FILTER NOT EXISTS” could be replaced by the line “BIND( uri( concat( str(?objectNotMatchingPosConstr), "_cloneWithoutInferredRelation" ) ) as ?cloneWithoutInferredRelation )” within the “FILTER NOT EXISTS” block.

3.4. Checking SubclassOf-based Constraints With a SPARQL-like language

The previous queries do not rely on inference engines to take into account the special meaning of CSTR classes. Hence, as explained in Section 2.3.1, these queries cannot be adapted for checking subclassOf-based constraints representing positive descriptive constraints. For prescriptive constraints, the queries are the same as their counterparts in Section 3.2 except for the initialization of ?posConstr_condition and ?posConstr_conclusion. E.g., for a positive prescriptive constraint, this initialization now is:

  ?posConstr_condition rdfs:subClassOf cstr:SubclassOf-based_prescriptive_constraint_condition,
                                       ?posConstr_conclusion.

The next query lists every object violating an individual-based inconsistency-implying constraint. Such an object matches – and hence has for type – a class ?negConstr_condition which i) has owl:Nothing as conclusion, and optionally ii) is subclass of the type cstr:SubclassOf-based_constraint_condition. If this previous type is not used in the negative constraints of the KB, this second condition must actually not be used in the query.

SELECT ?objectMatchingNegConstr ?negConstr_condition WHERE
{ ?negConstr_condition rdfs:subClassOf owl:Nothing;
                       rdfs:subClassOf cstr:SubclassOf-based_constraint_condition.  #optional line
  ?objectMatchingNegConstr rdf:type ?negConstr_condition.
}

Except as a module for calculating the completeness degree of a KB, this previous query is useless if, when building the KB, its consistency is already checked by an inference engine that delivers an error message when detecting that an object is instance of a subclass of owl:Nothing. By default, some Description Logic inference engines such as Corese [Corby, Faron-Zucker & Gandon, 2017] do not deliver error messages or warning messages when detecting such objects. Having to make inferences on instances of a subclass of owl:Nothing also makes Corese behaves abnormally. E.g., when an individual violates a subclassOf-based inconsistency-implying constraint – and hence is instance of owl:Nothing – as well as a positive constraint, this object does not appear in the results of the above described queries searching objects violating positive constraints. Thus, as noted in Section 2.3.1, using subclassOf-based constraints is not relevant for general-purpose knowledge sharing.

3.5. Checking Binary Relations Instead of Individuals With a SPARQL-like language

To list binary relations violating constraints – instead of individuals that have some relations violating constraints – it is sufficient to replace rdf:type by the “logical implication relation between statements” in the previous content-independent queries that check positive constraints. For referring to such relations, Tim Berners-Lee uses the type name log:implies [Berners-lee et al., 2008] in his Notation3 KRL. However, for this replacement to work, the used SPARQL engine must exploit an inference engine that can deduce the existence of such a relation when it exists between the matched statements. Description Logic inference engines generally do not do so.

Like queries on individuals, queries on relations can use additional filters. E.g., for the last query (Section 3.4) to operate only on negative facts, one may add at the end of its body:

?objectMatchingNegativeConstr rdf:type owl:NegativePropertyAssertion.

3.6. Evaluating a Constraint-based Completeness With a SPARQL-like language

A simple way to define or calculate a completeness degree for a KB is to divide “the number of relations (in the KB) that do not violate constraints” by “the total number of relations”. Another completeness degree may be obtained by considering only prescriptive constraints. Yet another one may be obtained by dividing “the number of individuals that do not violate prescriptive constraints” by “the total number of individuals”. The next query implements a variant of this last definition: instead of individuals, this query exploits “objects that are source of at least one relation to another object”. Furthermore, this query assumes that the constraints are represented as individual-based constraints. It also considers constraints in inconsistency implying form as (negative) prescriptive constraints. Via the method given in Section 3.5, this query can be adapted to exploit binary relations violating constraints instead of individuals violating constraints.

SELECT ( ((?nbObjs - ?nbAgainstPosCs - ?nbMatchingNegCs) / ?nbObjs)
         AS ?completeness )
{ {SELECT (COUNT(DISTINCT ?o) AS ?nbObjs)
    WHERE { ?o ?r ?o2 } #any object source of a relation to another object
        # For considering only objects that have a type:
        # { {?o rdf:type ?t1} UNION {?o cstr:type ?t2} }
  }
  {SELECT(COUNT(DISTINCT ?objectNotMatchingPosConstr) AS ?nbAgainstPosCs)
    WHERE { ... #the body of a query checking an individual-based positive
                #  prescriptive constraint (see Section 3.2.3.1) must be copied here

            #if ?objectNotMatchingPosConstr also violates a negative constraint
            #  it must not be counted here (otherwise it would be counted twice),
            FILTER NOT EXISTS            # hence this code here
            { ?negativeConstr cstr:condition_class ?negativeConstr_condition;
                              cstr:conclusion_class owl:Nothing.
              ?objectNotMatchingPosConstr rdf:type ?negativeConstr_condition
            }
          }
  }
  {SELECT (COUNT(DISTINCT ?objectMatchingNegativeConstr) AS ?nbMatchingNegCs)
    WHERE { ?negativeConstr cstr:condition_class ?negativeConstr_condition ;
                       cstr:conclusion_class owl:Nothing.
            ?objectMatchingNegativeConstr rdf:type ?negativeConstr_condition
          }
  }
}

3.7. JavaScript Function for Ontology Completeness Evaluation

The next function shows a way to list each constraint violation and calculate the completeness of the ontology wrt. these violations. There are however a few differences with the command given in the previous subsection.

• The completeness is now given i) with respect to each constraint in a particular set, not with respect to all prescriptive constraints of the KB, and ii) for the instances of a particular set of classes, not all individuals.
• Error handling is included.
• The method specializes is called to perform the matching between relations associated to an object and relations in a constraint condition or conclusion, i.e., to test if each relation in the second set of relations has a specialization in the first set (details on such a specialization test can be found in [Chein & Mugnier, 2008] and [Swan, 2016]). This method can ignore the instanceOf relations from the handled object. It does so when the checked constraint is a prescriptive one, i.e., if its parameter is instance of cstr:Prescriptive_constraint. In other words, for such constraints this method is based on the same idea as the one based on “clones without types” but does not need to generate such clones. With such a method, the code below needs not include a temporary removal of instanceOf relations from the objects.

JavaScript is here used instead of pseudo-code since its syntactic sugar is rather well-known or intuitive and is object-oriented. This previous feature is required here to have a code that is short, clear and generic with respect to error handling. The objects in the ontology are assumed to be accessible in the object-oriented way used in the code.

The complexity of the next function is the complexity of the object matching multiplied by the number of given constraints, multiplied by the number of given classes, multiplied by the average number of instances by class.

function checkThatInstancesOfTheseClassesSatisFyTheseConstraints
         (setOfClasses,     //e.g.: {Man, Woman}
          setOfConstraints, //e.g.: {"if x is a Person, x has a parent"}
          errorHandling) //contains a class for generic error handling
{ if (setOfConstraints.length() == 0)
    return errorHandling.returnCodeIfNoPropertyToCheck;
  if (setOfClasses.length() == 0)
    return errorHandling.returnCodeIfNoClassToCheck;
  for co in setOfConstraints  //co may or may not be inconsistency-implying
  { var numberOfObjsSatisfyingCo= 0, numberOfObjsNotSatisfyingCo= 0;
    for cl in setOfClasses
      for obj in cl.instances()
        if (obj.specializes(co.condition))
          if ((co.isPositiveConstr() && obj.specializes(co.conclusion))
            numberOfObjsSatisfyingCo++;
          else { numberOfObjsNotSatisfyingCo++;
                 if (errorHandling.alertAtEachError) 
                   alert("Relations from '" + obj.toString() + 
                         "' do not satisfy:\n  " + co.toString());   
                  //e.g.: Relations from 'Tom' do not satisfy:
                } //        if x is a Person, x has a parent
    var completenessForThatConstraint= numberOfObjsSatisfyingCo /
               (numberOfObjsSatisfyingCo + numberOfObjsNotSatisfyingCo);
    if (completenessForThatConstraint < 1)
    { if (errorHandling.alertAtEachIncompleteness)
        alert("Only " + completenessForThatConstraint + "% of instances"
              + " of the given classes satisfy the constraint:\n  " + 
              + co.toString());
      if (errorHandling.returnCodeIfIncompletenessForSomeConstraint)
        return errorHandling.returnCodeIfIncompletenessForSomeConstraint;
    }
  }
  return errorHandling.returnCodeIfNoError;
}

4.1. Examples of Useful General Descriptive Constraints

sub:subclass    owl:inverseOf rdfs:subClassOf.
sub:subProperty owl:inverseOf rdfs:subPropertyOf.
sub:subclassInExclusionSetOrAlone 
  rdfs:subPropertyOf sub:subclass; 
  sub:subProperty sub:subclassInDisjointUnion  #for a subclass in a subtype partition
                  sub:subclassInSetOfExclusiveSubclasses
                  sub:loneSubclass #for a subclass not in a set of exclusive subtypes
                  sub:nonNaturalSubclass.  #idem but for a non natural type

sub:nonNaturalSubclass rdfs:subPropertyOf sub:subclassInExclusionSetOrAlone;
                       rdfs:domain owl:Class;   rdfs:range sub:NonNaturalClass.

sub:subclassInDisjointUnion
  owl:propertyChainAxiom (owl:equivalentClass  owl:disjointUnionOf  rdfs:member).

sub:subclassInSetOfExclusiveSubclasses  owl:propertyChainAxiom 
    (sub:subclass  owl:equivalentClass  owl:disjointUnionOf  rdfs:member).

sub:subclassInSetOfExclusiveSubclasses  owl:propertyChainAxiom 
    (sub:subclass  owl:equivalentClass  owl:disjointUnionOf  sub:listMember).

[] rdf:type cstr:Descriptive_constraint;
   cstr:condition_class      # if C is a class that has a subclass ...
      [rdf:type owl:Class; 
       owl:equivalentClass [rdf:type owl:Restriction;  #"any class that has a subclass"
                            owl:onProperty sub:subclass;  owl:someValuesFrom rdfs:Class] ];
   cstr:conclusion_class  #... then C has no subclass relation that is not
                          #            of type sub:subclassInExclusionSetOrAlone
      sub:ClassWithNoRelationOfType_subclassButNot-subclassInExclusionSetOrAlone.
           #(=> all subclass relations of type sub:subclassInExclusionSetOrAlone)

#with:
[] rdf:type owl:AllDisjointClasses;
   owl:members  #this relation type is usable even though rdfs:member is not
                #  usable for accessing each member of the destination list!
     (sub:ClassWithNoRelationOfType_subclassButNot-subclassInExclusionSetOrAlone
      sub:ClassWithSomeRelationOfType_subclassButNot-subclassInExclusionSetOrAlone). 

sub:ClassWithSomeRelationOfType_subclassButNot-subclassInExclusionSetOrAlone
   owl:equivalentClass
      [rdf:type owl:Restriction;
       owl:onProperty sub:subclassButNot-subclassInExclusionSetOrAlone;
       owl:someValuesFrom owl:Class].

sub:subclassButNot-subclassInExclusionSetOrAlone
   rdfs:subPropertyOf sub:subclass;
   owl:propertyDisjointWith sub:subclassInExclusionSetOrAlone.

[] rdf:type cstr:Descriptive_constraint;
   cstr:condition_class  # if C is a class that has a subclass relation that is not
                         #               of type sub:subclassInExclusionSetOrAlone
      sub:ClassWithSomeRelationOfType_subclassButNot-subclassInExclusionSetOrAlone];
   cstr:conclusion_class owl:Nothing.  #... then there is a problem

INSERT 
{ [] rdf:type cstr:Descriptive_constraint;
     cstr:condition_class  #class for the source of a transitive relation
        [?TrRelTypeDomain  owl:equivalentClass 
            [rdf:type owl:Restriction;   #class source of a transitive relation
             owl:onProperty ?trRelType;  #e.g., a sub:part relation
             owl:someValuesFrom owl:Thing] ]; #any thing (type or individual)
     cstr:conclusion_class
        [?conclusion_class owl:equivalentClass  
            [rdf:type owl:Restriction;
             owl:onProperty ?aloneOrInPartitionTrRelType; #e.g., sub:partInPartition
             owl:someValuesFrom owl:Thing] ]
}
WHERE{ ?trRelType rdf:type owl:TransitiveProperty;
                  sub:aloneOrInPartitionTrRelType ?aloneOrInPartitionTrRelType;
                  rdfs:domain ?TrRelTypeDomain  #e.g., owl:Thing (see below)
     }

sub:subclass rdf:type owl:TransitiveProperty;   rdfs:domain rdfs:Class;
             sub:aloneOrInPartitionTrRelType sub:subclassInExclusionSetOrAlone.

sub:part rdf:type owl:TransitiveProperty;   sub:trRelDomain owl:Thing;
         sub:aloneOrInPartitionTrRelType sub:partInPartition.

4.2. Examples of Useful General Prescriptive Constraints

sub:part rdf:type sub:MandatoryOutRelationType;  rdfs:domain sub:DividableThing;
         sub:leafObjectType sub:PartDestLeaf;

sub:subclass rdf:type sub:MandatoryOutRelationType;   rdfs:domain owl:Class.
             sub:leafObjectType  sub:SubclassDestLeaf;

INSERT
{ [] rdf:type sub:Prescriptive_constraint;
     cstr:condition_class  #source class of mandatory "out relation"
        [?MandatoryOutRelTypeDomain  owl:equivalentClass 
            [rdf:type owl:Class; #?MandatoryOutRelTypeDomain minus ?OutRelLeafDestType
             owl:intersectionOf ( ?MandatoryOutRelTypeDomain
                                  [rdf:type owl:Class;
                                   owl:complementOf ?OutRelLeafDestType] ) ] ];
     cstr:conclusion_class
        [?conclusion_class owl:equivalentClass  
            [rdf:type owl:Restriction;  #there must be a relation of type ?outRelType
             owl:onProperty ?outRelType;   all:someValuesFrom owl:Thing] ]
}
WHERE { ?outRelType rdf:type sub:MandatoryOutRelationType;
        sub:leafObjectType ?OutRelLeafDestType;
        rdfs:domain ?MandatoryOutRelTypeDomain
      }

sub:partOf rdf:type sub:MandatoryOutRelationType; 
           rdfs:domain sub:Component;  rdfs:range sub:DividableThing.