## 5 Modeling of the Verification Process of Regulatory Constraints  
### Process Model  
We proceeded with interviewing our experts, who are responsible for managing ATec in order to capture their knowledge and then to propose a process model representing the way they work. Our model enables building an RDF description of the sequence of constraint verifications performed to control a given TD.  
Figure 8: RDF annotation of the SBVR (Example 1)  
Figure 7: SPARQL query of the consequent (Example 1).  
The RDFS schema of our model comprises four properties: body, if, then and or else, and eight classes: Pipeline, Pipe, Load, Query, Rule, RuleBase, Test and And, among which the class Pipeline models a process definition and the class Pipe models a call for a process. The execution of queries (Query) or rules (Rule, RuleBase) can be conditional (Test) and a process description can recursively call for other processes (Pipe), including itself. This recursive feature is used in the modeling of complex processes calling for one or several elementary processes.  
The abstract syntax of a process is defined by the following grammar:  
\[\begin{array}{ll}\text{Pipeline}&::=\text{EXP}+\\ \text{EXP}&::=\text{Load(Name)}\mid\text{Query(Name)}\\ &\mid\text{Test(Query(Name), Exp, Exp)}\\ &\mid\text{Rule(Name)}\mid\text{RuleBase(Name)}\\ &\mid\text{And(Exp}+\mid\text{Pipe(Name)}\end{array}\]  
We have developed a process engine based on the KGRAM semantic engine [9] with the following principle: it analyses a process definition represented in our model and dynamically constructs and executes a sequence of SPARQL queries or rules. It thus enables supervision, coordination and sequential execution a set of queries and rules. The process management relies on a set of predefined SPARQL queries such as the one presented in (Figure 9), dedicated to the management of the body of a process, which enables listing all the components of a process and their types:  
For instance, let us consider the validation process which RDF representation is presented in (Figure 10). Once this RDF data is loaded, our process engine executes the above query template (Figure 9) the resource of class Pipeline is identified and the resources denoting sub-processes involved in its definition are listed. Each of these sub-processes is recursively handled in order to identify the operations to be performed. Note that we do not use the whole process model since our process representations do not involve rules: in our case, the only basic operations are queries.  
Figure 9: A SPARQL query template to interpret a process RDF representation.  
Let us detail the handling of such a RDF description. The process engine interprets a resource of type Load (line 4) by loading the RDF description of a TD (located at the URI in argument) whose validity is to be checked. It interprets a resource of type Query (line 7) by loading the SPARQL query located at the URI and executing it on the loaded RDF description of a TD.  
A resource of type Test (line 5) calls for the instantiation and execution of the query template presented in (Figure 11) which enables identifying the value of the \"if, then\" and \"or else\" properties and their types. The process engine then first executes the ASK query denoted by the value of the \"if\" property and, depending on a TRUE or a FALSE answer, it recursively interprets the RDF description of the process denoted by the value of the \"then\" property or by the value of the \"or else\" property, if any.