Sbvr to Owl 2 Mappings: an Automatable and Structural-rooted Approach

The wide applicability of mapping business rules expressions to ontology statements have been recently recognized. Some of the most important applications are: (1) using of on-tology reasoners to prove the consistency of business domain information, (2) generation of an ontology intended to be used in the analysis stage of a software development process, and (3) the possibility of encapsulate the declarative specification of business knowledge into information software systems by means of an implemented ontology. The Semantics of Business Vocabulary and Business Rules (SBVR) supports that approach by providing business people with a linguistic way to semantically describe business concepts and specify business rules in an independent way of any information system design. Although previous work have presented some proposals, an exhaustive and automatable approach for them is still lacking. This work presents a broad and detailed set of transformations that allows the automatable generation of an ontology implemented in OWL 2 from the SBVR specifications of a business domain. Such transformations are rooted on the structural specification of both standards and are depicted through a case study. A real case validation example was performed, approaching the feasibility of the mappings by the quality assessment of the developed ontology.


Introduction
The Semantics of Business Vocabulary and Business Rules (SBVR) provides business people a linguistic way to semantically describe business concepts and specify business rules [1].The linguistic approach adopted by the proposal enables the expression of business knowledge through statements rather than diagrams.That is based in the insight that diagrams are helpful for depicting structural organization of concepts but they are impractical as a primary means of defining vocabularies and expressing business rules.SBVR is rooted in first-order predicate logic with some restricted extensions into higher-order logics and some limited extensions into modal logic.Despite such sound theoretical foundation on formal logic is a key feature in automated reasoning contexts, SBVR has been conceptualized for business people and designed to be used for business purposes independent of information system designs.Several works have already recognized the benefits of having a mean of mapping SBVR expressions to ontology statements.Important applications of such mappings can be mentioned.For example, ontology reasoners could be used to automatically prove the consistency of business models [2][3][4] [5].Ontologies intended to be used in the analysis stage of a software development process could be generated from main business knowledge sources [6].The mappings could also be used to generate ontologies that encapsulate business knowledge into information software systems, enabling unambiguous representation of knowledge and efficient management of highly dynamic environments [7][8] [9].Use of semantic technologies for creating more intelligent and effective enterprise information systems has increased considerably in the last years.Several works have already recognized that having a mean of mapping SBVR expressions to ontology statements will have strong benefits and will gain wide applicability in the future vision of enterprise information systems [2][7] [3][4] [5].
Although previous proposals have presented some SBVR to OWL 2 transformations [2][7] [3][4] [5], an exhaustive and automatable approach for them is still lacking.Some mappings between SVBR and OWL 1 are presented in [2] through an example, but the transformations are not explicitly formalized and -as a consequence -they can not be generalized to other situations.The proposal depicted in [7] presents a set of transformations based on OWL 1, rooted in the insight that SBVR rules have to be mapped into a rule language while OWL is used just for describing the vocabulary which the rules build on.Another set of transformations is presented in [3], but just some primary questions are answered.Meanwhile, [4] and [5] present a set of transformations rooted in the ORM conceptual modelling language, but the proposal follows a formally grounded approach by stating the logical foundations of the translations between the underlying theories of SBVR and OWL 2. This work presents a broad and detailed set of transformations that allows the automatable generation of an OWL 2 ontology from the SBVR specifications of a business domain.Transformations are rooted on the structural specification of both standards and are depicted along the paper through a case study.OWL 2 Web Ontology Language (OWL 2) has been selected as the receipt language of the transformations because it has evolved as a de-facto standard for a broad spectrum of applications [10].The rest of this paper is organized as follow.Section 2 analyses the differences with previous works.Section 3 and Section 4 provides an overview of the SBVR and OWL 2 specifications, respectively.Section 5 presents the SBVR to OWL 2 mappings and illustrate them through a case study.Section 6 depicts a real case validation example performed by a group of undergraduate engineering students.Section 7 presents some discussions about the addressed topics.Finally, some conclusions and future research directions are presented in Section 8.

Related Work
In literature, it can be found that several works have already recognized that having a mean of mapping SBVR expressions to ontology statements will have strong benefits and will gain wide applicability in the future vision of enterprise information systems [2][7][3][4] [5].An approach combining OWL 1 [11] and SWRL expressions [12] is explored in [2].The aim of the approach is to obtain a Platform Independent Model (PIM) [13] from the SBVR business vocabulary and rules expressions.That goal is achieved by performing an intermediate SBVR to OWL/SWRL translation process as a way to check consistency and expand the knowledge by means of inference procedures.The work explores the feasibility of the proposed solution and the main problems arising.Although it illustrates some mappings between SVBR and OWL 1 through an example, the transformations are not explicitly formalized and therefore they can not be generalized to other situations.A model transformation chain is presented in [7] as a way to translate SBVR based vocabularies to OWL 1 and R2ML statements 1 .Conducted by the insight that business rules should be guaranteed by all IT applications of an enterprise, the paper presents the needs for a technology to transform the SBVR expressions into a PIM.The work meets such need by presenting a chain of metamodel-based transformations from a conceptual point of view.The transformations are rooted on an intermediate metamodel of SBVR and the QVT language [13].The proposal use SBVR Vocabulary-to-MOF/XMI Mapping Rule Set to produce a MOF model and XML schema [13], the ODM [14] in order to describe OWL models within the MOF context, and the MOF-based metamodel of R2ML to generate the final version of the rules.The authors highlight the contribution to the model-driven integrity engineering of their approach given that the model transformation chain is completely based on the abstract syntax of the involved languages.Although this proposal shows the usefulness of using SBVR expressions as starting point for ontology devel-opment, it presents two differences with the mappings presented in the present work: (1) the transformations are based on the first version of OWL and (2) it states that SBVR rules have to be mapped into a rule language while OWL is used just for describing the vocabulary which the rules build on.In consequence, the approach involves the using of a rule engine to interpret and execute R2ML rules besides the reasoner used for OWL ontologies.However, the latest version of the OWL Web Ontology Language (OWL 2) provides a set of constructors with the expressive power required for the mapping of most of the concepts of SBVR, which would allow to simplify the transformation process and obtain a single artefact encapsulating the business knowledge.Some differences between the two versions of OWL are sketched in Section 4 of this paper, while a full detail of the new features of OWL 2 can be found in [15].Some basics concepts and problems in transforming SBVR expressions to OWL 2 are introduced in [3].The aim of the work is to allow business users to describe ontologies in a similar way to their everyday business language, which will allow to prove consistency of business vocabulary and rules by means of OWL 2 reasoners.Although this proposal also show the feasibility of using SBVR expressions for the conceptual modeling of an ontology, just answer some primary questions.On the other hand, [4] and [5] propose a set of transformations but following a different approach.These works are rooted in the ORM conceptual modelling language 2 , which is at the core of the SBVR proposal.Definition and application of an integrated method that uses ORM to generate an ontology-based query mechanism is presented in [4].Finally, a set-theoretic semantic for ORM 2 and a formal approach to map a fragment of such language to the ALCQI fragment of Description Logics [16] is introduced in [5].Although the work also depicts a tool which implements the translations of a set of ORM 2 constraints into a OWL 2 ontology, the proposal follows a formally grounded approach by stating the logical foundations of the translations between the underlying theories of SBVR and OWL 2. Different from previous work, the present paper depicts a broad and detailed set of transformations that allows the automatable generation of an OWL 2 ontology from the SBVR specifications of a business domain.Transformations are rooted on the structural specification of both standards rather than theoretic considerations of the language, with the aim to provide a set of mappings readily usable for business people or developers concerned with the implementation of a mapping tool.

SBVR Overview
SBVR defines the vocabulary and rules for documenting the semantics of business vocabularies, business facts, and business rules; which allows their verbalization in a controlled vocabulary readily understandable by business people.The fact-oriented approach of SBVR stems from the Business Rules Manifesto 3 , stating that rules builds on facts, and facts build on concepts as expressed by terms.Therefore, terms express business concepts, facts make assertions about these concepts, and rules constrain and support these facts.SBVR supports such approach by providing noun concepts and verb concepts respectively corresponding to the notions of terms and facts.Figure 1 shows the structural organization of such components.A noun concept is a concept that is the meaning of a noun or noun phrase, which is specialized by: (1) object types, which are noun concepts classifying things on the basis of their common properties; (2) individual concepts, which are concept corresponding to only one object thing and (3) roles, which are noun concepts corresponding to things based on their playing a part, assuming a function or being used in some situation.Additionally, fact type roles are defined as those roles that specifically characterizes its instances by their involvement in an instance of a given fact type.A verb concept -also named fact type -is a concept that is the meaning of a verb phrase that involves one or more noun concepts.It can be used to represent unary relations -i.e., unary fact type -, binary relations -i.e., binary fact type and even n-ary relations.Another important kind of fact type is the Specialization, which represents a relationship between a more general and a more specific concept.Moreover, a Reference Scheme is the SBVR way of identifying instances of a given concept by means of its characteristics specified by means of one or more unary fact types.Finally, a SBVR rule is an element of guidance that introduces an obligation or necessity and distinguishing two general types: (1) structural rules, which describe the way the business chooses to organize the things it deals with; and (2) operative rules, which govern the conduct of business activity by describing business processes.Both types of rules are built imposing restrictions over fact types by using quantifiers, logical operators, etc. Figure 2 shows the structural organization of quantifications and logical operations.As early stated, SBVR adopts a linguistic approach that allows to define vocabularies and express operative rules.According to this insight, SBVR defines a Controlled Natural Language (CNL) -named SBVR Structured English -and describes the way to mechanically mapping such CNL expressions to SBVR formal concepts.

OWL 2 Overview
The OWL 2 Web Ontology Language (OWL 2) is the latest version of an ontology language proposed by the World Wide Web Consortium (W3C) for the development of the Semantic Web [17], but it has gradually evolved as a de-facto standard for a broad spectrum of applications.documents.An OWL 2 ontology is a formal description of a domain of interest rooted in three syntactic categories that are interpreted under a standardized semantics, which allows useful inferences to be drawn.Figure 3, Figure 4 and Figure 5 depict the structural specification of such categories: • Entities such as classes, properties, and individuals.They are the basic elements of an ontology and are identified by Internationalized Resource Identifiers (IRIs) [18].For example, a class a:Person can be used to represent the set of all people, the object property a:parentOf can be used to represent the parent-child relationship and the individual a:Peter can be used to represent a particular person called "Peter".
Figure 3: Entities in OWL 2 ontologies • Expressions, representing complex notions in the domain being described.For example, a class expression describes a set of individuals in terms of the restrictions on the individuals characteristics.
• Axioms, which are statements asserted to be true in the domain being described.For example, a subclass axiom state that the class a:Student is a subclass of the class a:Person.
OWL 2 ontology language defines several concrete syntaxes that can be used to serialize and exchange ontologies.Among them, the functional style syntax is defined in the OWL 2 structural specification [17] with the aim to state the semantics of OWL 2 constructors and allow a compact writing of ontologies.
Following the structural specification insight, the rest of this paper uses such syntax to state OWL 2 ontology expressions.It is important to highlight that the latest version of OWL present new features although it has a very similar overall structure to OWL 1 and backwards compatibility is complete -i.e., all OWL 1 ontologies remain valid OWL 2 ontologies with identical inferences in all practical cases -.While some of such new features can be seen as syntactic sugar, there is a wide set of added constructors providing more expressive capabilities such as keys, property chains, richer datatypes, data ranges, qualified cardinality restrictions, and asymmetric, reflexive, and disjoint properties.A document detailing the new features can be found in [15].

SBVR to OWL 2 Mappings
Mappings presented in this section allow the automatable generation of an OWL 2 ontology from the SBVR specifications of a business domain.Transformations are rooted on the structural specification of both standards and are depicted in subsections below by grouping and sequencing them according to the inherent logical order of the subject matter itself.In addition to their theoretical expression, the mappings are illustrated by building an ontology that reflects the business knowledge exposed by a case study 4 .
The case study has been drawn from the Annex E of the SBVR specification 5 , depicting the business service of a fictitious car rental company with branches in several countries.This case study has been introduced by the OMG as a common real world model of business enterprise that researchers and system developers can use to illustrate the capabilities of their proposals.In this case study, the ontological conceptualization of the business knowledge provide a way to automatically prove the consistency of the business model [2][3][4] [5].
Although just a fragment of the case study is presented, it is complete enough in order to depict the usefulness of the proposed mappings.Figure 6 exposes the movements of cars among branches used to illustrate the mappings.EU-Rent rents cars to its customers.Different models of car are offered, organized into groups.All cars in a group are charged at the same rates.A rental booking specifies the car group required, the start and end dates/times of the rental and the EU-Rent branch from which the rental is to start.Optionally, the reservation may specify a one way rental -in which the car is returned to a branch different from the pick up branch -and may request a specific car model within the required group.Furthermore, the rentals are classified based on whether it crosses local area or international boundaries. 5.Each fact type role ftr is mapped by using the SubObjectPropertyOf and ObjectPropertyChain OWL 2 axioms, as proposed in [3].
The core of the ontology reflecting the business knowledge exposed by the EU-Rent example is built by applying the translations before depicted.As first step, the mappings of the main object types of the case study are shown in Table 1, Table 2 and Table 3.
car movement Table 1: SBVR specification of "car movement" concept Concept Type: object type Definition: Planned movement of a rental car of a specified car group from a sending branch to a receiving branch.Description: A car movement meets the business requirement that a car of a given group has to be moved between branches.A specific car will be assigned to it at some time, not necessarily when the requirement is first identified.branch Table 2: SBVR specification of "branch" concept Concept Type: object type Definition: Rental organization unit that has rental responsibility.In the case study, Branch object type adopts two roles by assuming the function of sending or receiving branch of a car movement.Expressions below (Table 8 and Table 9) show the mapping of the sending role -the other one is made in the same way -.sending branch Branch that is the origin of a car movement.Where is role of is an OWL 2 object property whose domain and range are the Sending Branch and the Branch classes, respectively.Finally, although this portion of the case study does not consider the modelling of individuals, to the aim of illustrate the translations it is possible to suppose the existence of a Branch named LAX Airport Agencyas shown in Table 10 and Table 11.ClassAssertion(eurent:Branch eurent:LAX Airport Agency)

Quantifications Mappings
Quantifications are defined by SBVR as logical formulations introducing a variable and having either the meaning: all referents of the variable satisfy a scope formulation; or a bounded number of referents of the variable exist and satisfy a scope formulation, if there is one.According to such definition and the previous translations, the mappings of the SBVR quantifications are presented depending on the arity of the fact type they ranges over:

Universal quantification
If the logical formulation scopes over a unary fact type, the expression is mapped to: DataAllValuesFrom(a:DataPropertyOne a:DataRangeOne) If the logical formulation scopes over a binary fact type, the expression is mapped to: ObjectAllValuesFrom(a:ObjectPropertyOne a:ClassOne)

Existential quantification
If the logical formulation scopes over a unary fact type, the expression is mapped to: DataSomeValuesFrom(a:DataPropertyOne a:DataRangeOne) If the logical formulation scopes over a binary fact type, the expression is mapped to: ObjectSomeValuesFrom(a:ObjectPropertyOne a:ClassOne) 3. at-most-n quantification, where "n" is a non-negative integer If the logical formulation scopes over a unary fact type, the expression is mapped to: DataMaxCardinality(n a:DataPropertyOne a:DataRangeOne) If the logical formulation scopes over a binary fact type, the expression is mapped to: ObjectMaxCardinality(n a:ObjectPropertyOne a:ClassOne) 4. at-least-n quantification, where "n" is a non-negative integer If the logical formulation scopes over a unary fact type, the expression is mapped to: DataMinCardinality(n a:DataPropertyOne a:DataRangeOne) If the logical formulation scopes over a binary fact type, the expression is mapped to: ObjectMinCardinality(n a:ObjectPropertyOne a:ClassOne) 5. exactly-n Quantification, where "n" is a non-negative integer If the logical formulation scopes over a unary fact type, the expression is mapped to: DataExactCardinality(n a:DataPropertyOne a:DataRangeOne) If the logical formulation scopes over a binary fact type, the expression is mapped to: ObjectExactCardinality(n a:ObjectPropertyOne a:ClassOne) Remaining SBVR quantifications -at-most-one, exactly-one, and numeric-range quantifications -are easily translatable in terms of the above presented mappings.Two exactly-n quantification mapping (where n = 1) are shown in Table 12, Table 13, Table 14 and Table 15.However, the last one is stated as a numeric-range quantification with the aim of demonstrate such mapping.In this way, the exactly-1 quantification is expressed as a numeric-range quantification with upper and lower limit fixed at the value 1.
Table 12: SBVR specification of "car movement has receiving branch" fact type car movement has receiving branch Concept Type: binary fact type Necessity: Each car movement has exactly one receiving branch.
Table 13: SBVR specification of "car movement has sending branch" fact type car movement has sending branch Concept Type: binary fact type Necessity: Each car movement has exactly one sending branch.

Logical Operations Mappings
SBVR defines logical operations as those formulations of meaning based on only the truth or falseness of the meanings of its logical operands.In correspondence with the previous translations, the mappings of the SBVR logical operations are presented depending on the types of the involved logical operands:

Logical Negation
If the logical operand is an object type, then the expression is mapped to: ObjectComplementOf(a:operand) If the logical operand is a literal, then the expression is mapped to: DataComplementOf(a:operand)

Conjunction
If both logical operands are object types, then the expression is mapped to: ObjectIntersectionOf(a:operand1 a:operand2) If both logical operands are literals, then the expression is mapped to: DataIntersectionOf(a:operand1 a:operand2)

Disjunction
If both logical operands are object types, then the expression is mapped to: ObjectUnionOf(a:operand1 a:operand2) If both logical operands are literals, then the expression is mapped to: DataUnionOf(a:operand1 a:operand2)

Equivalence
If both logical operands are object types, then the expression is mapped to: EquivalentClasses(a:operand1 a:operand2) If both logical operands are individual concepts, then the expression is mapped to: SameIndividual(a:operand1 a:operand2) If both logical operands are unary fact types, then the expression is mapped to: EquivalentDataProperties(a:logicaloperand1 a:logicaloperand2) If both logical operands are binary fact types, then the expression is mapped to: EquivalentObjectProperties(a:operand1 a:operand2) Remaining SBVR logical operations -exclusive disjunction, nand-formulation, nor formulation, and whetheror-not formulation -are translatable by the logical combination of the above presented mappings.As an example, the mapping shown in Table 16 depicts a disjunction expression stating that a rental in which the car is returned to a branch different from the pick up branch can crosses local area or international boundaries.5.4 Identifiers, Specializations and Classification Mappings 1. Reference Scheme, is the SBVR way of identifying instances of a given concept.However, SBVR considers only characteristics to be used as reference schemes, so the expression is mapped to: HasKey(a:ClassExpression a:DataPropertyExpressionOne) In the case study, the has Movement-ID characteristic is used as the identifier of the individuals belonging to the Car Movement object type.The corresponding translation is: HasKey(eurent:Car Movement () (eurent:has MovementID)) 2. Specialization, is a fact type representing relationships between a more general and a more specific concept.
If both concepts are object types, then the expression is mapped to: SubClassOf(a:concept1 a:concept2) If both concepts are unary fact types, then the expression is mapped to: SubDataPropertyOf(a:concept1 a:concept2) If both concepts are binary fact types, then the expression is mapped to: SubObjectPropertyOf(a:concept1 a:concept2) If concept1 is an object type and concept2 is an individual concept, the expression is mapped to: ClassAssertion(a:concept1 a:concept2) An application of the specialization mapping over the case study has been shown in the disjunction expression stated in the previous subsection.

Categorization and Segmentation
A possible situation is the need of categorizing the individuals belonging to certain entity according to a set of different criteria.Such situation is presented in the case study, where the car movements are classified based on whether the car is returned to a branch different from the pick up branchdirectional categorization criteria -and on whether the car crosses local area or international boundaries -geographical categorization criteria -.Moreover, the categories belonging to each criteria are disjoint between them.In the SBVR context, such modelling are called categorization and segmentation, respectively.While OWL 2 ObjectUnionOf is the way to map a SBVR categorization, OWL 2 DisjointUnion are used to translate SBVR segmentations.Multiple categorization criteria have been presented in the case study description through the rentals classifications based on directional or geographical aspects.The translations of such business issue are presented in Table 17.

A Real Case Validation Example
The real case validation example depicted in this section was performed with the aim of evaluating the feasibility of the proposed mappings.Such feasibility study is based on the quality assessment of the developed ontology.The example was performed by a three-member group composed by engineering students, in the context of the "Ontology-based Information Systems Development" course at the last year of the Information System Engineering program on the Argentinian Technological University in the province of Santa Fe.The goal of the developed ontologies were to encapsulate business knowledge into information software systems as a mean of achieve an unambiguous representation of knowledge and an efficient management of the dynamic nature of the business domain.By taking part in the experiment, participants earned educational credits.The development of the example involved the ontological specification of the policies governing the student fellowship program of the university.Such policies are stated in a natural language written document 6 .Table 18 depicts a excerpt of the fellowship program policies.Table 19, Table 21, Table 23, Table 25, and Table 27 show the SBVR specification of the main domain concepts.Table 20, Table 22, Table 24, Table 26, and Table 28 present the OWL 2 mappings of the SBVR policies expressions.Figure 7 shows a excerpt of the ontological specification of the main domain concepts.The students made use of text editors to model the business domain according to the followed approach.The ontology implementation was performed by means of Prot´eg´e, a free and open source ontology editor 7 .
Table 18: An excerpt of the policies governing the student fellowship program The profile of the students involve the following basic information: full name, birthday, genre, postal address, email and telephone number.The students have an identification number assigned by the administration of the university.The students should follow at least one engineering student program.The students who have been approved in two tests will be considered regular students.Students who have started an engineering student program in the current school year will be considered starter students.Starter students will be considered regular students.The candidates to a scholarship should follow an engineering study program.The candidates should be regular students.The candidates should register to a scholarship program in the corresponding registration period.The university offers two kinds of scholarships programs: the research and service and the economic assistance programs.The scholarships programs are defined in the context of an unique school year.The scholarships programs define a fixed registration period.student Table 19: SBVR specification of "student" concept Concept Type: object type Necessity: Each student has exactly one full name.
Each student has exactly one identification number.
Each student has exactly one birthday.
Each student has exactly one genre.Each student is enrolled on at least one engineering student program.Each studentship is a research and service studentship or an economic assistance studentship but not both.Necessity: Each studentship belongs to exactly one school year.
Each studentship has exactly one registration period.The ontology quality evaluation task was performed by means of OQuaRE [19], a framework conceived for that purpose and based on the SQuaRE standard for software quality evaluation [20].OQuaRE considers ontologies as artifacts obtained by means of a building process and evaluates them independently of any particular development process.It provides an automatable approach which enables the objective assessment of ontology quality and makes quality evaluation reproducible.OQuaRe defines a quality model and quality metrics for ontology evaluation.Quality model is divided into a series of dimensions -or characteristics -organized into subdimensions -or subcharacteristics -which are evaluated by applying a set of automatable metrics.OQuaRE defines the criteria to transform the quantitative scores of each metric into a 1-5 range and establishes that 1 means not acceptable, 3 is minimally acceptable and 5 exceeds the requirements.After such transformation, the score for each subcharacteristic is the mean of its associated metrics while the score of each characteristic is the mean of its subcharacteristics.The set of characteristics scores is the quality assessment result, enabling the identification of strengths and flaws of an ontology.Characteristics evaluated in the example are defined as follows: • Structural dimension involves formal and semantic properties that are important when evaluating ontologies since it accounts for quality factors such as consistency, formalisation, redundancy or tangledness.
• Functional adequacy dimension refers to the appropriateness of the ontology for its intended purpose, according to the categories identified by [21].
• Maintainability dimension is related to the capability of the ontologies to be modified for changes in the environment, in requirements or in functional specifications.
• Compatibility dimension refers to the ability of two or more ontologies to exchange information and/or to perform their required functions while sharing the same hardware or software environments.The compatibility dimension can be evaluated over a single ontology -although intuitively it involves properties about more than one ontology -given that it is quantitatively assessed by means of a set of metrics applied to each ontology separately.
• Transferability dimension is the degree to which the ontology can be transferred from one environment (e.g., operating system) to another.
• Operability dimension refers to the effort needed for use the ontology, and on the individual assessment of such use, by a stated or implied set of users.
• Reliability dimension is the capability of the ontology to maintain its level of performance under stated conditions for a given period of time.
Three metrics were left out of consideration at the assessment of the aforementioned quality dimensions.Annotation richness -i.e., mean number of annotations per class -and class richness -i.e., mean number of instances per class -were not assessed since the annotation and instantiation of ontologies were not a part of the task of the experiment.Attribute richness metric -i.e., mean number of attributes per class -was not assessed because "attributes" are not a part of the structural specification of the implementation language of the assessed ontologies [17].OQuaRE also defines performance efficiency and quality in use dimensions.Performance efficiency exposes the relationship between the level of performance of the ontology and the amount of used resources, under stated conditions, taking into account elements such as time of response or memory consumption.Quality in use refers to the degree to which the ontology used by specific users meets their needs to achieve specific goals.However, such dimensions were left out of consideration because there was a lack of metrics for their subcharacteristics 8 .Figure 8 shows the quality scores for the ontology developed in the context of the validation example.A quickly recognizable outcome is the level of quality shown by the ontology: according to the meaning assigned for OQuaRE to the values of the 1-5 ranking system, it largely outperform the minimally acceptable quality in all considered dimensions.Moreover, the global quality score -which is equal to 4.60 and it is calculated as the mean of all the scores -is very close to the maximal quality value.These results provide a first insight about the feasibility of the proposed mappings, by presenting a real case example where the quality of the developed ontology overcome the acceptable level -as stated by an assessment framework rooted in a widely recognized standard for software quality evaluation.

Discussion
The mappings proposed in this work are rooted on the structural specification of the source and target languages.With the aim of obtaining empirical evidence about the feasibility of the approach an experiment has been performed [22].The exploratory experiment designed has allowed to compare the performance and attitudes of some groups of students building an ontology based on SBVR business rules expressions with another set of groups building an ontology based on traditional glossaries describing domain entities.Such comparison has been rooted in the quality assessment of the ontologies developed by 10 equally sized groups randomly conformed by 30 undergraduate engineering students and applying such techniques.As a result it was found that the developed ontologies largely outperformed the minimally acceptable quality, according to the OQuaRE quality assessment framework.Moreover, there was no statistical significant difference between the quality scores of the ontologies developed by means of rules-based and glossary-based techniques, in any of the assessed quality dimensions.Such results not only highlight the feasibility of the approach but also provide some feedback about rightness of the mappings.These findings highlight the potential of SBVR to OWL 2 transformations as an ontology development technique worthy of further study.From a formally grounded point of view, ensuring semantic equivalence between the ontology and the original set of SBVR statements would require, for example, the definition of a comorphism between the logics underlying both languages.Such issue is an interesting starting point for a future work.

Conclusions and Future Work
In this work, an exhaustive and automatable approach for SBVR to OWL 2 transformations has been presented.The mappings were depicted through a case study and empirically evaluated by means of a real example.The empirical evaluation supports a first insight about the feasibility of the proposal: the quality of the developed ontology largely outperform the minimally acceptable quality, as stated by an assessment framework rooted in a widely recognized standard for software quality evaluation.The development of a case study and a real example has allowed to recognize the lack of expressive power of OWL 2 for modeling all the possible semantics of business vocabularies.As an example, it can be taken the rule of the case study imposing that the sending and receiving branch of a round-trip car movement must be the same.Such restriction can not be expressed by OWL 2 statements.According to that, future theoretic works involve three main issues.The first one is focused on the validation and formalization of the mappings.Both goals will be achieved by generating an ontological metamodel of SBVR specification by following a similar approach to that adopted in the building of the Ontology Definition Metamodel (ODM) [14].The second one is related to the definition of mappings from SBVR to Horn Rules expressed in the SWRL language, with the aim to filling the gap between SBVR and OWL 2 expressive power.Such new set of mappings will take advantage of the mappings formalization explained in this paper.The third one is about the analysis of the benefits of integrating the mappings approach to EDON [9], an evolutionary method for building ontologies intended to be used as a structural conceptual model of an information system.In a early stage, translations can be useful in a method that make use of ontologies to encapsulate business rules as a mean to raise the flexibility, extensibility and ease of maintenance of enterprise software systems.Finally, practical objectives of the research will be directed towards the implementation of a prototype intended to provide automatable translations from SBVR business domain specifications to OWL 2 ontologies.

Figure 1 :
Figure 1: Noun and verb concepts in SBVR

Figure 2 :
Figure 2: Quantifications and logical operations in SBVR OWL 2 ontologies provide classes, properties, individuals, and data values, and are stored as Semantic Webdocuments.An OWL 2 ontology is a formal description of a domain of interest rooted in three syntactic categories that are interpreted under a standardized semantics, which allows useful inferences to be drawn.Figure3, Figure4and Figure5depict the structural specification of such categories:

Figure 6 :
Figure 6: EU-Rent car movement among branches

Figure 7 :
Figure 7: Ontological specification of the main domain concepts

Figure 8 :
Figure 8: Dimensions quality scores of the developed ontology

Table 3 :
Mapping of main object typesCharacteristics of object types are expressed.In this case, just the Car Movement class have such kind of attribute (Table4 and Table 5):

Table 4 :
SBVR specification of "has movement ID" fact type car movement has movement-id

Table 5 :
Mapping of unary fact type Declaration(DataProperty(eurent:has Movement-ID)) DataPropertyDomain(eurent:has Movement-ID eurent:Car Movement) DataPropertyRange(eurent:has Movement-ID xsd:string) Binary fact types are expressed as properties of classes as shown following.A binary fact type translation is presented below (Table6 and Table 7), and the rest of them share the same structure.

Table 6 :
SBVR specification of "specifies car group" fact type car movement specifies car group

Table 10 :
SBVR specification of "LAX Airport Agency" individual concept LAX Airport Agency

Table 14 :
Mapping of exact quantification

Table 25 :
SBVR specification of "research and service studentship" concept research and service studentship

Table 26 :
OWL 2 specification of "research and service studentship" concept Declaration(Class(policies:Research and Service Studentship)) SubClassOf(policies:Research and Service Studentship policies:Studentship)