Correctness of the transformation: transformation of ontology axioms in formal rules *

. In this paper, authors emphasise on the correctness of the transformation. Therefore, types of correctness are analysed here. As a context of transformation, the transformation of PAL constraints in SQL rules is chosen for more details.Formal rules for the transformationof PAL constraintsin SQL rules are presented in this paper also. And ﬁnally,the analysisof the proposed transformationis checked.


Introduction
In recent years, model-based software development processes have evolved. In this area, models are used for the generation of other models, for code generation, analysis, and simulation as well. The possibility to perform correct and automatic model transformation during reasonable short time is vital in the development of software applications. The Object Management Group (OMG) [1] is accomplishing this goal through the introduction of the Model Driven Architecture (MDA) with supporting detailed specifications.
In our research, we apply transformation to develop a rule model from the ontology (for more details see [2]). The knowledge-based information systems development using the domain ontology is the hot topic nowadays, since the semantic content expressed by ontology can be transformed in information systems artefacts, thereby reducing the costs of conceptual modelling [3]. In this context, researches are targeted on transformation of ontology in conceptual data model because they have some common aspects, i.e., both include concepts, relationships between concepts and rules (in ontology -axioms). However, a rule model, which is an important and integral part of each conceptual data model, is often neglected.
In this paper, authors emphasise on the correctness of the transformation. Therefore, the objective of this paper is to investigate is the proposed transformation correct.

Related work and background
According to [4], the correctness of model transformation is an important issue. This includes syntactical correctness, functional behaviour, and semantical correctness [4], [5]. It is hard to establish a single notion of correctness for model transformations. The most elementary requirements of a model transformation are syntactic.
• The minimal requirement is to assure syntactic correctness -is to guarantee that the generated model is a syntactically well-formed instance of the target model. • An additional requirement is to assure syntactic completeness -is to completely cover the source model by transformation rules, i.e., to prove that there exists a corresponding element in the target model for each construct in the source model. According to [6] to ensure the syntactical correctness of the output of a transformation it would be necessary to define a separate transformation language for every pair of source and target language. Such a transformation language would consist of the syntax definitions of the source and the target language and some language elements needed to be able to define the mapping. The synthesis of such a transformation language is always the same process and could therefore be automated.
Syntactic correctness and completeness was attacked in [7] by planner algorithms, and in [8] by graph transformation.
However, in order to assure a higher quality of model transformations, at least the following semantic requirements should also be addressed [5].
• Termination: The first thing we must also guarantee is that a model transformation will terminate. See also [9]. • Uniqueness (Confluence, functionality): As non-determinism is frequently used in the specification of model transformations (as in the case of graph transformation based approaches) we must also guarantee that the transformation yields a unique result. This is a language independent criterion. See also [9]. • Semantic correctness (Dynamic consistency): In theory, a straightforward correctness criterion would require to prove the semantic equivalence of source and target models. However, as model transformations may also define a projection from the source to the target (with deliberate loss of information), semantic equivalence between models cannot always be proved. Instead we define correctness properties (which are typically transformation specific) that should be preserved by the transformation. According to [10] the topic about correctness is assigned to the category of formal methods. Owing to the formal foundation, the correctness of model transformations can be checked [4].
As stated in [11], transformation rules are correct in the sense that the target model is equivalent with the original (the proof of theorems can be find in [11]). The correctness of transformation of models can be checked by comparing the probability masses of target and source models. If they are equal, then transformation of models is correct.
A model transformation for translating a model from a source language in a target language can be defined by a set of compound rules [12]. Each such compound rule r: (r s , r t ) consists of two individual rules: The source transformation rule r s : L S ::= R S describes the transformation of the source model (with L S representing the left hand side and R S representing the right hand side), the target transformation rule r t : L T ::= R T specifies the transformation of the target model. Typically, source transformation rules will be identical transformations leaving the source model unchanged, represented as r s : L S only.
Source and target rules are coupled by the ability to use shared variables. Such variables are denoted by <variable> [12]. Authors of [12] also briefly describe how a compound rule is applied, assuming that L S = R S and that X = {x 1 , .., x n } is the set of variables of L S .
1. An occurrence of the left side L S of the source transformation rule is searched within the source model, such an occurrence is called source match. 2. Having found a source match, the variables are given concrete values, leading to a variable instantiation denoted X I . 3. The left side L T of the target transformation rule is instantiated with the values of the variables, denoted also by L T (X I ). 4. An occurrence of the instantiated left side of the target transformation rule is searched within the target model. Such an occurrence is called target match. 5. The right side R T of the target transformation rule is instantiated with the values of the variables. 6. The occurrence of the instantiated left side is replaced with the instantiated right side R T of the target transformation rule. To ensure the syntactic correctness of a transformation unit consisting of compound rules, we have to deal with the following problems [12]: • With regards to a rule, both the source part as well as the target part must be syntactically correct. • The variables used in the target part must also occur in the source part.
• With regards to a transformation unit, non-terminals created must also be deleted by later rule applications because otherwise the target model might contain these non-terminals. • It must be ensured that all rules of a transformation unit are reachable, i.e., there are derivations that can make use of the rule. According [13] functional behaviour of the model transformation based on graph transformation [12], [14] means that there are local confluence and termination of graph transformation which implies that model transformation defines a function from a source to a target. The model transformation is locally confluent, if the model transformation source language is restricted by the syntax grammar.

The context of transformation
As was said in Introduction, in our research, we apply transformation to develop a rule model from the ontology (for more details see [2]). Therefore, the formal expression of ontology axioms (and ontology as a whole) and formal rules is presented in this chapter.
Protégé Axiom Language (PAL) [15] constraints and Structured Query Language (SQL) triggers were chosen for the detailed study of transformation.
From [15] it was determined that axioms (A P i ) expressed using PAL can be expressed as follows:

A P i =< P AL-name i , P AL-documentation i , P AL-RANGE i , P AL-statement i >, where:
• PAL-name holds a label for the constraint.
• PAL-documentation holds a natural language description of the constraint.
• P AL-RANGE = {P AL-range 0 , P AL-range 1 , . . . , P AL-range k } holds definitions of local and global variables that appear in the statement. It is a class or a set of classes, defining the main concepts of domain in ontology. • PAL-statement holds the sentence of the constraint. where: • if − part is a statement or a set of statements, denoted by symbol '=>', which holds possible conditions of the state, • then − part is a statement or a set of statements, which comes after if-part and holds possible state or sometimes action in the domain. If − part is optional. The analysis of possible axioms, which can be defined using EZPal Tab plug-in [16], shows that P AL − statement matches a possible state of a domain. There is no action if a new state of the domain does not violate the conditions defined in the axioms. Action is 'forbid change' if a new state of the domain violates the conditions defined in the axioms.
A statement holds on a certain number of variables, which each range over a particular set of values. Therefore, a constraint in PAL consists of a set of variable range definitions and a logical statement that must hold on those variables. The language of PAL is a limited predicate logic extension of Protégé-2000 that supports the definition of such ranges and statements. The syntax of PAL is a variant of the Knowledge Interchange Format (KIF) [17]: It supports KIF connectives but not all of KIF constants and predicates (e.g., the theory of arithmetic is much smaller).
Variables begin either with '?' to indicate a local variable or with '%' to indicate a global variable. Variables can be a class, which define the main concepts of domain in ontology, or a slot, which presents some properties of classes or their relationships with other classes.
SQL triggers (SQL-RULE = {sql-rule 0 , sql-rule 1 , . . . , sql-rule n4 }) can be expressed as follows: sql-rule i =< sql-comment i , sql-trigger-name i , sql-table i , sql-event i , where sql-comment holds documentation of a rule, sql-trigger-name holds the name of a rule, sql-table holds the name of a table or a view to which the rule is attached, sql-event holds an event (INSERT, DELETE, UPDATE or SELECT), which triggers the rule, if -sql is a SQL statement, which holds the condition of the rule, then-sql is a SQL statement, which holds the action of the rule. For more about SQL statements see Microsoft Visual Studio Documentation.
The following PAL constraints transformation in SQL rules is developed:

Correctness of PAL constraints transformation in SQL rules
In this section authors check the correctness of PAL constraints transformation in SQL rules according to related work and background. The goal of checking a rule is to ensure that there are no correctness errors in the source and no correctness errors in the target.
As we can state, from the related work presented in this paper, correctness is of three forms -syntactic, semantic and functional behaviour.

Syntactic correctness of transformation of PAL constraints in SQL rules.
Checking the PAL constraint is rather straightforward as it involves simply the decision of whether the left side conforms to the PAL syntax. The syntax correctness of PAL constraints was checked by executing those constraints. Since there was no syntactical errors during the execution, we can state, that our PAL constraints are syntactically correct. Since KIF syntax is strictly formal (see [17], PAL is also well-formed.
Checking SQL rules requires the checking if rules match SQL triggers. Since we use the structure of SQL triggers fore the transformation, we can state that the structure and syntax of SQL rules is correct and is the same as syntax and structure of SQL triggers.
All variables used in SQL rules must also be used in PAL constraints. If a variable is used in the SQL rule, but not declared, then a variable mismatch occurs. Such variable mismatches can easily be found by comparing the set of variables of SQL rules and PAL constraints.
The variable correctness criteria can be easily verified by a simple algorithm that computes the set of variables of the left and right-hand sides.

Semantic correctness of transformation of PAL constraints in SQL rules.
As stated in the section of related work and background, we should prove the semantic equivalence of PAL constraints and SQL rules. From the developed formulas 1,

Functional behaviour of transformation of PAL constraints in SQL rules.
As stated in the section of related work and background, functional behaviour includes local confluence and termination of transformation, e.g., the existence of a unique result of the transformation for every valid input.
In our case transformation defines a function from PAL constraints to SQL rules, since variables used in PAL constraints are used in SQL rules. Transformation changes only the representation of those variables, the meaning leaves the same. Moreover, the source language is restricted by the syntax grammar. For each valid input (PAL constraint) a unique result (SQL rule) is produced (the results of transformation of PAL constraints in SQL rules are presented in [2].

Conclusions and future works
The analysis of the related works on model transformation shows that correctness of transformation is one of the main topics should be analysed in model transformation. It includes syntactic and semantic correctness and functional behaviour.
A transformation of PAL constraints in SQL rules is defined in formal way to check the correctness of proposed transformation. A process of checking the correctness of PAL constraints transformation in SQL rules shows that this transformation is possible and correct. Still this checking should be extended for all ontology and strictly formalised.