Ontologies in engineering: The OntoDB/OntoQL platform

Transcription

1 Soft Computing manuscript The final publication is available at Springer via Ontologies in engineering: The OntoDB/OntoQL platform Yamine Ait-Ameur Mickaël Baron Ladjel Bellatreche Stéphane Jean Eric Sardet Abstract Ontologies have been increasingly used over the past few decades in a wide range of application domains spanning both academic and industrial communities. As ontologies are the cornerstone of the Semantic Web, the technologies developed in this context, including ontology languages, specialized databases and query languages, have become widely used. However, the expressiveness of the proposed ontology languages does not always cover the needs of specific domains. For instance, engineering is a domain for which the LIAS laboratory has proposed dedicated solutions with a worldwide recognition. The underlying assumptions made in the context of the Semantic Web, an open and distributed environment, do not apply to the controlled environments of our projects where the correctness and completeness of modeling can be guaranteed to a certain degree. As a consequence, we have developed over the last decades a specialized standard ontology language named PLIB associated with the OntoDB/OntoQL platform to manage ontological engineering data within a database. The goal of this paper is threefold: (i) to share our experience in manipulating ontologies in the engineering domain by describing their specificities and constraints, (ii) to define a comprehensive classification of ontologies with respect to three main research communities: Artificial Intelli- Yamine Ait-Ameur IRIT/ ENSHEEIHT, Toulouse, France yamine@enseeiht.fr Mickal Baron, Ladjel Bellatreche, Stéphane Jean LIAS/ISAE-ENSMA - University of Poitiers 1, Avenue Clement Ader, Futuroscope Cedex, France {baron,bellatreche,jean}@ensma.fr Eric Sardet CRITT Informatique Futuroscope Cedex, France {sardet}@critt-informatique.fr gence, Databases and Natural Language Processing and (iii) to present a persistent solution, called OntoDB, for managing extremely large semantic data sets associated with an ontological query language, called OntoQL. These objectives are illustrated by several examples that show the effectiveness and interest of our propositions in several industrial projects in different domains including vehicle manufacturing and CO2 storage. 1 Introduction The notion of ontology has initially been defined by Gruber as an explicit specification of a conceptualization (Gruber, 1993). An ontology is composed of a set of shared classes, properties and relationships with reasoning mechanisms. It has the ability to represent formally real-world knowledge in a shared way. These favorable characteristics of ontologies have led academicians and industrials coming from various communities to adopt them: Artificial Intelligence (Matuszek et al, 2006), Natural Language Processing (Estival et al, 2004), Databases/Data Warehouses (Sugumaran and Storey, 2006; Noy, 2004), Information Retrieval (Graupmann et al, 2005), etc. Some researchers have even pushed the idea of having a universal ontology 1. The construction of ontologies is time consuming. As a consequence, several research efforts have been conducted to tackle this problem. These studies may be classified into three main categories: (i) manual construction as is the case of the Cyc Ontology (Matuszek et al, 2006), (ii) community-based construction such as 1 Entity Relationship Conference 2011 Panel on New Directions for Conceptual Modeling.

2 2 Yamine Ait-Ameur et al. Freebase 2 where volunteers are invited to contribute to the ontology definition and (iii) automatic construction in which the ontology is automatically extracted from the Web such as YAGO (Suchanek et al, 2008) and DBpedia (Mendes et al, 2012) or from relational databases (Sequeda et al, 2011). These ontologies can be defined for specific domains, including biology (Apweiler et al, 2004) and engineering (IEC , 1999), but can also be defined for general-purpose applications. The SUMO ontology (Niles and Pease, 2001) and the OWL-FC ontology (Maio et al, 2012) are examples of such upperlevel ontologies. Despite this wide and diverse usage of ontologies, most of them are defined with the same technologies defined in the context of the Semantic Web. These technologies include the RDF-Schema (Brickley and Guha, 2004) and OWL (Bechhofer et al, 2004) languages to define ontologies, specialized databases such as Jena (Wilkinson, 2006) to manage a large amount of Semantic Web data and the SPARQL language (Prud hommeaux and Seaborne, 2008) to query them. Admittedly, these technologies are well adapted in the context of the Semantic Web, but may not cover the majority of domains and applications. This observation is based on our experience in the engineering domain for data integration applications. In this particular setting, we have identified two major drawbacks of Semantic Web technologies concerning the expressiveness of Semantic Web languages and their underlying assumptions. Indeed, data integration projects in the engineering domain require a precise definition of technical information characterizing components (e.g., units of measurement) and an explicit representation of the modeling context of each defined concept (e.g., the point of view taken to characterize a component). Moreover, as the Semantic Web is an open and distributed environment, the corresponding ontology languages adhere to the open world assumption, which means that any statement that is not known can be true, and do not make the unique name assumption, i.e., that if two objects have different identifiers, they are different. As pointed out in (de Bruijn et al, 2005), these assumptions can be misleading for engineers who are used to define constraints for checking the validity of the defined components and not to infer additional knowledge. If these assumptions are natural in the Semantic Web, they are less plausible in controlled environments where standard ontologies exist and where engineers adhere to a protocol which ensures a certain degree of correctness and completeness of modeling. As existing ontology technologies were not adapted to our industrial projects in engineering, we have de- 2 signed over the past two decades a set of technologies to represent and manage ontologies in the engineering domains. These technologies are based on the standard PLIB language (officially ISO 13584) to define ontologies (Pierra, 2003). The design of this language was initiated in the early 90 s to develop an approach with standard models for the automatic exchange and integration of engineering component databases. This ontology language is equipped with a specialized database called OntoDB to store engineering data and their associated ontologies (Dehainsala et al, 2007). As the SQL language was not sufficient to query such a database, the OntoQL exploitation language was designed (Jean et al, 2006). This language follows the design logic of SQL by proposing sub-languages to define, manipulate and query both the data and the ontologies that describe them. The goal of this paper is to present this set of technologies and to describe several projects with large companies in various domains such as the automotive and petroleum industries where these technologies have been successfully put into practice on real-case settings. This paper is structured as follows. Section 2 presents our point of view on the notion of ontology. As this notion has been used by different communities, all ontologies are not alike. Consequently, we propose a taxonomy of ontologies and present the onion model we use to design ontologies. In Section 3 we present the particularities of the engineering domain that have led us to design the PLIB language. This language is presented in Section 4 after showing the limitations of Semantic Web languages to fulfil the requirements previously identified for the engineering domain. As a large quantity of data can be described by ontologies, Section 5 reviews the persistent solutions that have been developed for storing ontologies and Section 6 details the OntoDB database that we have designed. This database is equipped with the OntoQL exploitation language described in Section 7. These technologies have been used in many industrial projects. Section 8 presents several use cases. Finally, Section 9 concludes and introduces future work. 2 A layered view of an ontology From our point of view, an ontology is a formal and consensual dictionary of categories and properties of entities of a domain and the relationships that hold among them (Jean et al, 2007b). This definition highlights three main characteristics of an ontology. 1. Formal. An ontology describes a domain by defining a set of classes and properties using a formal lan-

3 Ontologies in engineering: The OntoDB/OntoQL platform 3 guage. This ontology language can be used to check the consistency of an ontology and to perform automatic reasoning on the ontology-defined concepts and instances. 2. Consensual. An ontology is agreed and shared by a community. Thus, contrary to a conceptual model, an ontology is not designed for a particular application. It describes the knowledge of a domain to fulfil the needs of the members of a community. 3. Universal identification. Each concept of an ontology has a universal identifier. Using this identifier, an ontology concept and the semantics it represents can be referenced from any environment. All ontologies are not alike (Cullot et al, 2003; Pierra, 2003). On the one hand, Linguistic Ontologies (LO) represent the meaning of the words used in a particular universe of discourse, in a particular language. On the other hand, Conceptual Ontologies (CO) represent the categories and properties of objects available in some part of the world. The two following types of concepts exist in a CO (Gruber, 1993). Primitive concepts are those concepts for which we are not able to give a complete axiomatic definition ; we must rely on a textual documentation and on a background of knowledge shared with the reader. Defined concepts are those concepts for which the ontology provides a complete axiomatic definition by means of necessary and sufficient conditions expressed in terms of other concepts. We call Canonical Conceptual Ontologies (CCO), the ontologies that only include primitive concepts. They define a canonical vocabulary in which each information in the target domain is captured in a unique way. And we call Non Canonical Conceptual Ontologies (NCCO) the ontologies that also include defined concepts. They introduce new reasoning capabilities and equivalence operators that can be used to define mappings between different ontologies. The three categories of ontologies introduced previously suggest a layered view of ontologies (see Figure 1), we called the onion model of domain ontologies (Jean et al, 2007b). In this view, a kernel CCO provides a formal foundation to represent and exchange efficiently the knowledge of a domain. A NCCO layer extends the canonical vocabulary with concepts equivalence to encompass all concepts broadly used in the domain. The NCCO concepts can be defined with different operators such as class expressions defined in description logic. Finally, a LO layer adds the natural language representation of the CCO and NCCO concepts for personsystem and person-person communication. The onion model is illustrated in Figure 2 with a toy ontology in the mechanics domain. The CCO part of this ontology is composed of the Product, Rolling Bearing, Roller Bearing and Row of Balls classes and properties such as mass or width. Based on this CCO, two NCCO classes and one NCCO property are defined. For instance, the 2 Rows Ball Bearing class is defined as the ball bearings that use two rows of balls. The formal definition of this class is given using a syntax borrowed from description logic. The life length NCCO property is defined as a function of different properties. Finally, the LO part of this ontology consists of the linguistic description of these classes and properties. For instance, the Rolling Bearing class is described with two English names and a French name. In the next section, we detail the specific requirements for representing ontologies in the engineering domain. LO NCCO Others Class expression: Description Logic CCO Property expression: Derivation functions Property expression: F-Logic Operators to define NCCO concepts from CCO or NCCO concepts Operators to define LO concepts from CCO or NCCO concepts Fig. 1 The onion model of domain ontology 3 Ontologies in engineering The engineering domain includes different fields such as aeronautics, transport, mechanics or energy. In most of these engineering fields, products to be designed are essentially assemblies of components. An important part of the engineering knowledge concerns the used components. It includes the criteria used to select a component, the conditions of component usage, the behaviour of components and the pertinent component representation for each specific discipline (Paasiala et al, 1993).

4 4 Yamine Ait-Ameur et al. Row_of _Balls Product Uses [1-2] 1_Row_Ball_Bearing used_in [0-1] mass Ball_Bearing Rolling_Bearing width n, F rad, F ax life_lengh 2_Rows_Ball_Bearing EN = Rolling Bearing, Rolling-element Bearing FR = Roulement Roller_Bearing CCO Class CCO Property Inheritance NCCO Class NCCO Property LO description the bearing will behave correctly. The value of this property depends on the number of revolutions done by the bearing, and of the load it must support. Mathematically, the bearing life-length is a function of the velocity (i.e., rotational speed), the radical load and the axial load. Requirement 2 (Context of values) When a value of a property depends on a context of evaluation, this evaluation context should be explicitly defined. Fig. 2 Example of the onion model The example presented in the next section illustrates the specificities of this domain. 3.1 Motivating example Conditions of use n: rotation speed F rad : radial load F ax : axial load Figure 3 presents a 2D representation of a ball bearing. But other points of view of this component are used in engineering such as 3D representation or schematic representation (see Figure 4). Each point of view describes a ball bearing with different characteristics. Requirement 3 (Point of view) If several perspectives are needed to describe a component, these perspectives should be explicitly defined in an ontology and the same real-world component should be described according to these different perspectives. depends on Behavior L 10h : life length Characteristics d: internal diameter D: external diameter B: width N min : N max : Ball bearing Fig. 3 Nature of properties of a component Simplified 3D representation 2D - Representation A rolling bearing (or rolling-element bearing) is a mechanical component used to connect and to transmit load between two cylindrical shapes having the same axis but different diameters and rotational movements. The main properties of a rolling bearing are presented in Figure 3. Characteristic properties include width, internal and external diameters. These properties can have different values depending on the units of measure used. This scale should be explicitly represented. Requirement 1 (Units of measure) An ontology in engineering should explicitly define the units of measure of values and more generally it should describe all the technical information of a component. The behaviour of a component is also characterized by properties. For example, the property life length corresponds to the length of the time period during which Calculus... Schematic representation Fig. 4 Different points of view on the same component From our experience acquired from designing ontologies in engineering (described in Section 8), it is not difficult to reach a consensus among several components suppliers on all the major properties of a rolling bearing. But it is impossible to reach a consensus on the properties that should be represented in the database of each supplier. Thus, a class should describe all its major properties. Concerning the properties, as different types of rolling bearings exist such as ball bearings or roller bearings, the diameter property should be defined at the level of circular bearing where it is meaningful.

5 Ontologies in engineering: The OntoDB/OntoQL platform 5 Requirement 4 (Context of concepts) The modeling context in which each class or property is defined should be made explicit and minimized. Each class should define all its major properties, at least in some broad context of a community. Each property should be defined in the context of a class: its domain of application. Suppliers of components often need to extend a shared ontology with classes and properties that are not consensual. Requirement 5 (Locality of interpretation) Importation of resources from one ontology into another one should be possible while controlling the impact of the former over the interpretation of the latter. In addition to these five main ontology modeling requirements, the engineering domain often relies on a set of assumptions described in the next section. 3.2 Underlying Assumptions Open and Close World Assumptions. Under the Close World Assumption (CWA), any statement that is not known to be true is false. On the contrary, under the Open World Assumption (OWA), any statement that is not known can be true. These assumptions play an important role for constraints. Under the CWA, the constraints are checked; under the OWA they are used for inference. In the engineering domain, a lot of constraints are defined to describe precisely the behaviour of a component. Engineers that define these constraints expect that they will be used to check the validity of the registered components. Moreover, the CWA is adapted in the engineering context where a number of reference ontologies are already standardized or are in the standardization process either within IEC or within ISO (Pierra, 2003). These standards are rather stable and the knowledge can be considered complete. In this controlled domain, it is often possible to guarantee a certain degree of correctness of modeling. On the contrary, the OWA is often made in the Semantic Web as correct and complete modeling cannot be guaranteed on the Web. Moreover, an ontology can be intentionally under-specified expecting that others will reuse and extend it. Thus the OWA is adapted in an open context like the Web. Several studies have reported the need to use the CWA in controlled sections of the Semantic Web (de Bruijn et al, 2005; Knorr et al, 2011). Unique Name Assumption. Under the Unique Name Assumption (UNA), if two objects have different identifiers, they are different. This assumption is often made in combination with the CWA in complete and controlled domain. Contrariwise, the UNA is often not made in domains where the OWA is assumed. Indeed, without the UNA assumption, if two instances (or classes, or properties) have different identifiers, we may still derive by inference that they must be the same. From our experience, the UNA is more adapted to many engineering problems that use ontologies as solutions (Pierra, 2003). On the Web, the UNA is often considered less plausible. Typing Assumption. Under the OWA, classification of instances is one of the key reasoning capability. For example, an instance having a value for a property p can be classified in the domain of p. Thus, a Weak Typing Assumption (WTA) is often made in the Semantic Web: (1) an instance may belong to any number of non connected ontology classes, (2) a property can be defined without a domain and (3) an instance can define a value for any property of the ontology. Under the WTA, a diverse set of data, ranging from structured data to unstructured data, can all be represented (Duan et al, 2011). But the cost of this flexibility is that the efficient management of such data is difficult (Aluç et al, 2014). Instances in engineering domains are often components which are fairly structured data (relational-like). In such domain, a Strong Typing Assumption (STA) can be made: (1) each instance belongs to exactly one class called its basis class that is the minimum for the subsumption order of all the belonging classes of this instance, (2) each property is defined in the context of a class that defines its domain of application, and is associated with a range, and (3) only properties that are applicable in the context a class are used for describing its instances. This assumption can be used to define an efficient storage layout of engineering data as we will see in Section 6. We have seen in this section that the engineering domain has specific requirements and assumptions. This observation has led us to define and use a specific ontology language. 4 Ontology languages Several ontology languages have been defined in the last decade. The most well-known ontology languages are RDF-Schema (Brickley and Guha, 2004) and OWL (Bechhofer et al, 2004). These languages have been defined in the context of the Semantic Web and thus they make the OWA assumption and do not make the UNA assumption. We first present these two languages. Then we present the OWL-Flight language, which was defined mainly to eliminate some of the pitfalls in conceptual modeling with OWL induced by these assump-

6 6 Yamine Ait-Ameur et al. tions. As these languages do not fulfil the five requirements introduced in the previous section, we finally present the PLIB ontology language specifically defined for the engineering domain. 4.1 RDF-Schema RDF-Schema or RDFS is based on RDF. RDF is used to defined assertions as a set of triples (subject, predicate, object). The subject is a URI that denotes a resource. The predicate is a property that characterizes the resource. The object is the value of the property, a literal value or a URI of another resource. RDF defines few built-in predicates, mainly the typing relationship (rdf:type) and the property constructor (rdf:property). Thus, it is not considered as an ontology language. RDFS extends RDF with a set of built-in predicates to define an ontology. The main predicates of RDFS are the following. Class definition. rdfs:class and rdfs:subclassof define a hierarchy of classes. Names and descriptions can be assigned to classes using rdfs:label and rdfs:comment. Property definition. rdfs:domain and rdfs:range define the domain and range of an RDF property. A hierarchy of properties can be defined using rdfs:sub- PropertyOf. As classes, properties can be described using rdfs:label and rdfs:comment. Datatype definition. rdfs:datatype defines datatypes of an RDF property. The value of a property can be an instance of a class or a literal (rdfs:literal). A literal can be typed using a set of allowed XML datatypes. Instance definition. Instances are defined in RDF with two kind of triples: (i, rdf:type, C) states that i is an instance of C and (i, p, v) defines v as the value of i for the p property. RDFS defines few restrictions on the usage of these constructors. In particular, it does not separate the different levels of abstraction: instances, ontologies and ontology language. As a consequence, an instance can be a class and thus it can have instances. Likewise, a property can be a class and thus it can be the domain of another property. RDFS does not provide non canonical constructs and thus it is oriented toward the definition of CCO ontologies. But as we have seen, it does not have specific constructors to fulfil the modeling requirements of the engineering domain identified in the previous section. 4.2 OWL OWL extends the expressive power of RDFS. Three versions of this language have been defined : OWL Lite, OWL DL and OWL Full with an increasing expressive power (OWL Lite OWL DL OWL Full). OWL Lite and OWL DL ensure the decidability of reasoning but they are not compatible with RDFS since they restrict the usage of RDFS constructors. In contrast, OWL Full is compatible with RDFS but is not decidable. OWL DL extends RDFS with the following main constructors. Ontology definition. owl:ontology defines an ontology as a set of classes and properties in a namespace. This ontology could be described by many characteristics such as its version (owl:versioninfo) or its compatibility with other ontologies. Class definition. owl:class is the OWL class constructor corresponding to rdfs:class. The owl:equivalentclass class axiom states that two classes have the same instances. On the contrary, two classes that do not share any instances could be defined as disjoints (owl:disjointwith). In addition to the usual class constructor, OWL includes NCCO class constructors. The owl:unionof, owl:intersectionof, owl:complementof boolean operators define respectively a class as a union, intersection or complement of other classes. The owl:allvaluesfrom (respectively, owl:somevaluesfrom) restriction defines a class as all instances for which all values (respectively, at least one value) of a given property are members of a given class. owl:hasvalue defines a class as all instances that have a given value for a given property. Finally, owl:oneof defines a class by enumerating its instances. Property definition. Two types of properties exist: owl:objectproperty and owl:datatypeproperty. They specialize the rdf:property to distinguish properties whose range is a class from properties whose range is a datatype. The owl:equivalentproperty property axiom states that two properties have the same values. OWL introduces property characteristics. A property can be defined as symmetric (owl:symmetricproperty), transitive (owl:transitiveproperty), injective (owl:inversefunctionalproperty), as a function (owl:functionalproperty) or as the inverse of an other property (owl:inverse- Of ). Finally, cardinality of a property can be specified using owl:mincardinality, owl:cardinality and owl:maxcardinality. Instance definition. An instance is defined with a set of RDF triples. The owl:sameas (resp. owl:differentfrom) can be used to assert the equality (resp. inequality) of two instances.

7 Ontologies in engineering: The OntoDB/OntoQL platform 7 Contrary to OWL Full which is fully compatible with RDFS, OWL DL imposes constraints on RDFS constructors to ensure decidability of reasoning (e.g., a constructor cannot be applied to another constructor). The last version of OWL, OWL Lite, imposes more restrictions than OWL DL to simplify the reasoning process. It forbids the usage of owl:unionof, owl:complementof, owl:oneof and owl:hasvalue. Moreover, owl:mincardinality, owl:cardinality and owl:maxcardinality could only be used with the 0 or 1 values. Thus, OWL extends RDFS with mainly non canonical constructors to enhance the reasoning possibilities. But it does not introduce constructors to fulfil our requirements and it does not make the assumptions often made in the engineering domain. 4.3 OWL Flight OWL Flight (de Bruijn et al, 2005) was designed to overcome some pitfalls in the OWL language for modeling specific domains. These pitfalls are mainly the result of the assumptions made in OWL: the OWA without the UNA (see Section 3). As a consequence of these assumptions, the semantics of OWL may seem counterintuitive for database and software engineers who are used to the CWA and UNA assumptions. For example, if a 2 Rows Ball Bearing has more than two Row Of Balls, instead of raising an error, this knowledge can be used to infer an equality between the Row Of Balls. As a consequence, OWL Flight is a variant of OWL based on Logic Programming that extends it with cardinality and value constraints, meta-modeling and powerful datatype support. Compared to OWL DL the constructors not included are enumerated classes, individual (in)equality assertions, complements and property restrictions in complete class definitions. Contrary to OWL DL, OWL Flight adopts the UNA and constraints are interpreted under the CWA i.e, they are used to check the data instead of being used to infer additional knowledge. The PLIB ontology language presented in the next section was designed in the same spirit as OWL Flight. This language adopts the CWA and UNA which are more intuitive for engineers who work in domains such as mechanics or aeronautics. Moreover, this language adds important features (e.g., units of measure or points of view) which are missing in OWL for modeling precisely such domains. 4.4 PLIB The PLIB ontology language (Pierra, 2003) is an international standard (ISO 13584) originally defined for exchanging and integrating automatically electronic catalogues of industrial components. Primitive concepts of a technical domain being rather broad and complex, the aim of this ontology model is to define precisely such concepts. PLIB can be used to define ontologies using the main following constructors. Class definition. PLIB classes are defined using the item class constructor. Classes as other ontology elements are identified by a universal identifier named BSU (Basic Semantic Unit). They are described by a textual description (name, synonymous names, definition, note, remark) that may be given in different natural languages. This description can be completed with documents. PLIB classes can be organized into a hierarchy using two operators: is a and case of. is a is the usual simple inheritance operator; case of is a multiple subsumption relationship that does not imply inheritance of properties: the subsuming class should explicitly import the useful properties. This last operator is particularly useful for semantic integration (requirement 5). It could also be used to introduce multiple inheritance relationships in a PLIB ontology. In addition to definition classes, PLIB has two other types of classes: representation and view classes. Representation classes represent the additional properties that result from a particular point of view (requirement 3). A representation class must be associated with a definition class. Each instance of a representation class is a view of an instance of a definition class. This relationship is called is-view-of. View classes represent the point of view corresponding to each representation class: each representation class shall reference a view class as its modeling context. Property definition. The main property constructor of PLIB is non dependent pdet. As classes, properties are identified by a BSU and characterized by textual and/or graphical descriptions. Each PLIB property must be associated to a class that represents its domain with the scope constructor (requirement 4). PLIB has another property constructor named dependent P DET for defining properties that depend upon a context parameter defined by the condition DET constructor (requirement 2). For example, the length of an axis depends upon its temperature. This context can also be defined as a function.

8 8 Yamine Ait-Ameur et al. Datatype definition. Primitive datatypes such are integer or string are available in PLIB. They can be associated with a unit of measure or a currency (requirement 1). Technical datatypes are available such as level type used to qualify a numeric value. A class can also be used as a datatype with the class instance type constructor. Finally, PLIB supports collections and enumerated datatype. Instance definition. A PLIB instance is defined by a basis class and a set of property values. Thus, PLIB does not support multi-instanciation (i.e., that an instance belongs to different classes not linked by subsumption relationships). Instead, PLIB supports the instance aggregate mechanism: an instance may also be associated with any number of discipline-specific classes that represent points of view of a particular basis class. Table 1 summarizes our comparison of the studied ontology languages. As this table illustrates, RDFS focuses on defining CCOs with the assumptions of the Semantic Web domain. OWL extends this language with NCCO constructors borrowed from Description Logics. OWL-Flight is a variant of OWL that interprets constraints under the CWA. Finally, the PLIB ontology language focuses on defining precisely ontologies in the engineering domain by providing specific constructors for this domain. As we will see in Section 8, PLIB has been used to define several standard ontologies in this domain. With the development of these ontologies, a large quantity of data described by ontologies has been produced. In the next section, we describe the persistent solutions that have been developed in the last decade to manage such a large volume of ontological data. 5 Persistent solutions for ontologies With the availability of standard ontology languages, several large ontologies have been designed. One can cite YAGO (Suchanek et al, 2008) and DBPedia (Mendes et al, 2012) in the Semantic Web and standard ontologies for Electronic Components (IEC ) or Laboratory Measuring Instruments (ISO ) in the engineering domain. As a consequence, the need to manage efficiently ontologies and their instances has appeared. Several research efforts have been proposed in the last decade to address this challenge. Two main approaches have been followed. The first one consists in natively representing the graph structure of RDF data (e.g., gstore (Zou et al, 2011)). The second approach, on which we focus in our work, uses relational database management systems (RDBMSs) to store RDF data. We call Ontology-Based Databases (OBDBs) these specialized databases. Examples of such systems are Oracle Spatial and Graph (Das et al, 2004), OntoDB (Dehainsala et al, 2007), Jena SDB (Wilkinson, 2006), Sesame (Broekstra et al, 2002), DLDB (Pan and Heflin, 2003), 3store (Harris and Gibbins, 2003), RStar (Ma et al, 2004), SW-Store (Abadi et al, 2007) or OntoMS (Park et al, 2007). Systems such as RDF-3X (Neumann and Weikum, 2008) or TripleBit (Yuan et al, 2013) can be considered hybrid approaches as they use native storage structures which are not graphs. Despite being studied for more than a decade, the efficient management of ontologies and their instances is still an active research topic (Aluç et al, 2014). In this section, we present the diversity of OBDBs using two orthogonal criteria: the storage layout and architecture used by OBDBs. 5.1 Storage layouts Three main storage layouts are used for representing ontologies and/or instances in an RDBMS (Sakr and Al-Naymat, 2009): the vertical, binary and horizontal storage layouts. These storage layouts are detailed below and illustrated on a subset of our example of ontology (Figure 5). Triples subject predicate object ID1 type Ball_Bearing ID1 mass 7,8 ID1 width 6,9 ID1 used_in ID2 ID2 type Product ID2 desc Bicycle (a) Vertical Storage Layout Ball_Bearing subject mass width used_in ID1 7,8 6,9 ID2 subject ID1 ID2 subject ID2 Type object Ball_Bearing Desc subject ID2 Product object Bicycle Product (c) Horizontal Storage Layout Fig. 5 Example of the used storage layouts (b) Binary Storage Layout desc Bicycle subject subject ID1 Mass Used_In object ID1 7,8 subject Width object ID1 6,9 object The vertical storage layout. This storage layout is a direct translation of the RDF data model. It consists of a single triples table with three columns (subject, predicate, object) (Harris and Gibbins, 2003). Since URIs are long strings, additional tables may be used to store only integer identifiers in the triples table. Three B+tree indexes are usually used (Abadi et al, 2007; Sidirourgos et al, 2008): one clustered on (subject, property, object) and two unclustered on (property, object, subject) and (object, subject, property). As this storage layout is a ID2

9 Ontologies in engineering: The OntoDB/OntoQL platform 9 RDFS OWL OWL Flight PLIB Universal identifier URI URI URI BSU Subsumption subclassof subclassof subclassof is a SubPropertyOf SubPropertyOf SubPropertyOf case of NCCO constructors - Restriction Restriction Derivation function - Boolean operators Boolean operators Linguistic information label/comment label/comment label/comment name/synonym/definition (multilingual) (multilingual) (multilingual) note/remark (multilingual) Technical information specific datatypes (units, level type) point of view (is-view-of) evaluation context Assumptions OWA OWA Local CWA/UNA CWA/UNA WTA WTA WTA STA Table 1 Comparison of the main ontology languages direct translation of the RDF data model, RDF queries can be directly and easily translated into SQL queries. But these queries often require a lot of self-join operations on the triples table. RDF3X (Neumann and Weikum, 2008) and Hexastore (Weiss et al, 2008) have shown that this approach can still be employed with good performance if the triples table is replaced by a set of indexes. The binary storage layout. This storage layout consists in decomposing the triples table into a set of 2- columns tables (subject, object), one for each predicate (Abadi et al, 2007). In some implementations, the inheritance of classes and class membership are represented in a different way (e.g., by using the table inheritance mechanism of PostgreSQL (Broekstra et al, 2002)). Two indexes are usually used: a clustered B+ tree index on subject to locate them quickly and an unclustered B+ tree index on object. Abadi et al. have shown that this approach can be very efficient if it is implemented on a column-store DBMS (Abadi et al, 2007). By using different benchmarks, the performance of this storage layout has been analysed in several studies (Schmidt et al, 2009; Sidirourgos et al, 2008; Dehainsala et al, 2007). Two drawbacks have been identified: (1) when queries involve many properties, this storage layout requires many joins (Dehainsala et al, 2007) and (2) when properties do not appear as bound variables in queries, this storage layout requires a lot of union clauses and joins (Sidirourgos et al, 2008; Weiss et al, 2008). The horizontal storage layout. This storage layout consists in denormalizing the triples table by storing them in a representation more similar to traditional relational schemas (Wilkinson, 2006; Dehainsala et al, 2007). This relational representation can be obtained either by grouping the properties that are defined together (Wilkinson, 2006) or by making some typing assumptions (Dehainsala et al, 2007). In the latter case, a table C(p 1,..., p n ) is created for each class C where p 1,..., p n are the set of single-valued properties used by at least one instance of the class. Multivalued properties are represented by two-column tables as in the binary representation or by using the array datatype available in relational-object DBMSs. Since all instances do not necessarily have a value for all properties of the table, this representation can be sparse which can impose performance overhead. Moreover, as the binary storage layout, this storage layout does not scale well when properties do not appear as bound variables in queries. As we can see and as several benchmarking studies have shown (Schmidt et al, 2009), each storage layout is suitable for a different type of queries and there is not a storage layout that gives the best performance for all query workloads. As a consequence, Aluç et al. have recently raised the challenge to define a workloadaware storage layout for managing ontologies and their instances (Aluç et al, 2014). 5.2 Architecture Three main architectures called type I, type II and type III architectures are used by OBDBs. The type I and II architectures are illustrated in Figure 6 and an example of type III architecture is presented in Figure 7: type I architecture: as in traditional databases, this architecture uses two parts: the data part and the system catalog. The data part stores the ontology instances and the ontology schema (classes, properties, etc.). Thus, this architecture implies that the same storage layout is used for ontologies and their instances. Oracle Graph and 3store use this architecture and store ontologies and instances in a triples table (with specific indexes for Oracle Graph);

10 10 Yamine Ait-Ameur et al. System Catalog meta_table ID name Id3 triples Data Triples 1 subj pred obj Id1 type Ball_Bearing Id2 type Product Type I architecture 2 Ontology 3 ID Id3 Id4 Class meta_table ID name Id5 class Id6 triples name Ball_Bearing Product System Catalog Data 1 Triples Type II architecture 2 subj pred obj Id1 type Ball_Bearing Id2 type Product Fig. 6 Type I and type II architectures of OBDBs efficient storage layout for such data. As we have seen in the previous section, other solutions to store ontologies do not fulfil these objectives. As a consequence, we have designed the OntoDB architecture presented in the next section. 6.1 The OntoDB architecture OntoDB is implemented on top of the PostgreSQL DB- MS. It has a four-parts architecture depicted in Figure 7. type II architecture: in this architecture, ontologies and their instances are stored in two different schemas. Thus, this architecture decomposes the database in three parts: the system catalog, the ontology part and the data part. RStar (Ma et al, 2004) or Sesame DB (Broekstra et al, 2002) are examples of OBDBs that use this architecture. In this architecture the used ontology language is hard encoded by the schema defined in the ontology part. Thus, this architecture is not adapted if the used ontology language changes regularly or if constructors from other ontology languages need to be used; type III architecture: this architecture has been proposed in OntoDB (Dehainsala et al, 2007) to be able to extend the used ontology language in the OBDB and to support different ontology languages in the same database. This need is fulfilled by proposing an architecture similar to the MOF architecture (OMG, 2002) defined for managing different metamodels. Thus this architecture is composed of 4 parts: the system catalog, the ontology part, the data part and the metaschema part. This latter part plays the same role for ontologies than the one played by the system catalog for the data. This part is used to store the used ontology language so that it can be extended. More details are given in the next section. 6 The OntoDB ontology-based database The OntoDB architecture has been initially designed for storing PLIB ontologies and their instances. As the PLIB ontology language regularly evolves and because several other ontology languages exist, the first objective of this architecture was to support evolutions of the used ontology language. As we have seen in Section 3, instances in engineering domains are fairly structured and respect the strong typing assumption. Thus, the second objective of this architecture was to design an (4) (3) Metaschema part Entity ID name 11 class Attribute ID name 12 name Ontology part Class rid name 1111 Ball_Bearing Property rid name 1121 width System catalog Meta_table ID name 1 E1111 Meta_column ID name 2 P1121 Data part E1111 rid P E1112 rid P1122 P Fig. 7 Example of type III architecture: OntoDB (1) (2) 1. The system catalog (1) is a traditional part of any DBMS. It contains system tables used to manage all the data contained in the database. In OntoDB, it contains specifically the description of all the tables and columns defined in the three other parts of this architecture. 2. The data part (2) stores the ontology instances. An instance belongs to an ontology class and is described by a set of property values. 3. The ontology part (3) stores the ontologies that define the concepts of the domain covered by the database. OntoDB initially supports the PLIB ontology language. 4. The metaschema part (4) stores the ontology language used. For the ontology part, the metaschema part plays the same role as the one played by the system catalog in traditional DBMSs. It can be in particular used to extend the ontology part and thus to modify the used ontology language. In the following we detail the three main parts of OntoDB.

11 Ontologies in engineering: The OntoDB/OntoQL platform The data part The data part uses the horizontal storage layout. In this storage layout, a table is associated to each concrete class. Each one of these tables has a column named rid to identify class instances. In addition, this table has one column for each property used by at least one instance of this class. To define the link between an instance and its belonging class, the name of a table (resp. of a column) is the concatenation of E (resp. P ) with the identifier of the corresponding class (resp. property). Since properties are represented by columns, each PLIB datatype has a specific representation in PostgreSQL: primitive datatypes have equivalent datatypes in PostgreSQL (e.g, the PLIB int type is coded as INT8 in PotgreSQL); the reference type (class instance type) is used to link two instances. Because of the polymorphism, two columns are used to represent this dataype. The name of the first one is suffixed by rid and provides the identifier of the referenced instance. The second one, suffixed by tablename stores the name of the table in which the referenced instance is stored; the collection datatype (aggregate type) is represented by the ARRAY type of PostgreSQL. The properties whose values are collections of instances are represented by two columns of type ARRAY. The first one, suffixed by rids, stores the identifiers of the referenced instances. The second one, suffixed by tablenames, stores the names of the tables in which these instances are stored. An example of the data part of OntoDB for our example of ontology is depicted in Figure 8. Three tables are created for the three classes Product, Ball Bearing and Row Of Balls. The name of a table is defined as the identifier of a class prefixed with E. For example, since the identifier of Product is 1111, the name of the corresponding table is E1111. Each table has a column rid and columns for the used properties. Properties such as width, name or length are represented by a single column whose name is the identifier of the property prefixed with P. The used in property corresponds to an association between the Ball Bearing and Product classes. It is represented by two columns P1124 rid to store the identifier of the corresponding product and P1124 tablename to know the table in which this instance is stored (a sub-class of Product could be used). The same representation is used for the uses property. The only difference is that this property has a collection dataype and thus the ARRAY datatype of PostgreSQL is used. E1111 (Product) rid P1121 (name) 1 Bicycle E1112 (Row_Of_Balls) rid P1122 (length) E1113 (Ball_Bearing) P1123 P1124_rid P1124_table P1125_rids P1125_tables rid (width) (used_in) name (used_in) (uses) names (uses) E1111 [2,3] [E1112, E1112] Fig. 8 Example of the data part of OntoDB 6.3 The ontology part The ontology part is initially defined to store PLIB ontologies. The PLIB language is defined in the EX- PRESS formalism (Schenk and Wilson, 1994), which is similar to the UML language. It defines an objectoriented model by a set of entities with inheritance relationships and attributes. The model of the PLIB language is composed of hundred of entities and attributes. Thus, instead of manually defining the storage layout for this part, a program takes as input the object-oriented representation of the PLIB language in EXPRESS and generates the set of tables of this part by applying a set of rules. Each entity of the PLIB language is translated into a table. The name of this table is the one of the corresponding entity suffixed by e. If an entity inherits from another entity, its table inherits from the table corresponding to the other entity thanks to the table inheritance mechanism available in PostgreSQL. The associations one-to-many or many-to-many are represented by association tables. For an entity A linked to an entity B by an association named a2b, an association table named A 2 a2b is created. This table has the five following columns: rid identifies the association; rid s and tablename s contain respectively the identifier of an instance of the A entity and the table in which this instance is stored (it can be a sub-entity of A); rid d and tablename d play the same role as rid s and tablename s for the entity B. Moreover, to optimize the access to an association, the table A e has a column a2b that is a foreign key (association one-to-many) or a collection of foreign keys (association many-to-many) pointing to the primary key of the association table. Example. Figure 9 presents a simplified ontology language and the corresponding tables in the ontology part of OntoDB. The ontology language is composed of three entities. The Class and Property entity has an attribute name. Class and Property is the super-entity

12 12 Yamine Ait-Ameur et al. of the entities Class and Property which represent respectively ontology classes and properties. These two entities are linked by the scope association that represents the domain of a property. Each entity is translated into a table in the ontology part of OntoDB (suffixed by e). Each one of these tables has a column named rid to identify the corresponding ontology elements. The hierarchy of tables is conformed to the hierarchy of entities: the tables Class e and Property e inherit from the Class and Property e table. Finally, the scope association is represented by the Property 2 scope association table. This table makes the link between a property and a class. The scope column of the Property e table is used to join this table with the association table. the model of the EXPRESS language. The rows of these tables correspond to the constructors of the ontology language used (e.g., class, property, etc.). An extract of the metaschema part of OntoDB for the simplified ontology language presented in Figure 9 is depicted in Figure 10. The tables Entity and Attribute store the corresponding elements of the ontology language. Entity rid name super 1 Class_and_Property NULL 2 Class 1 3 Property 1 Attribute rid name scope range 11 name 1 String 12 scope 3 2 Fig. 10 Example of the metaschema part of OntoDB STRING name Class_and_Property Class scope Property 6.5 Performance evaluation of OntoDB label label Entity Primitive Datatype Class_e rid name 1 Ball_Bearing Inheritance Association Ontology language Class_and_Property_e rid name Property_e rid name scope 10 width 100 Property_2_scope rid rid_s tablename_s rid_d tablename_d Property 1 Class Storage layout of the ontology part Fig. 9 Example of the ontology part of OntoDB 6.4 The metaschema part In a database, the system catalog is used to record the tables and columns of the data part. Thanks to this part, a SQL query can be checked and the data part can be extended with new tables and columns. The same idea is applied on the ontology part in OntoDB. As a consequence, OntoDB has a new part called the metaschema. This part stores the ontology language used to define the ontologies. The query language of OntoDB (presented in the next section) leverages it to extend dynamically the ontology language used. The tables of this part correspond to the formalism used to define the ontology language. In the case of OntoDB, these tables correspond to the EXPRESS language. These tables are automatically generated from We have presented in (Dehainsala et al, 2007) a series of performance experiments to compare the storage layout proposed by OntoDB with the vertical and binary storage layouts used by other OBDBs (see Section 5). As our work targets a specific application domain (engineering), we have developed a benchmark based on the IEC ontology (IEC , 1999), which reflects the needs of this domain. The results of these experiments show that OntoDB outperforms other storage layouts for queries in which the user specifies the class to be queried. Moreover, the difference of performance between OntoDB and the vertical and binary storage layouts increases with the number of properties used in the query. The only case where the performance of OntoDB is worse than other storage layouts is for queries in which the class to be queried is not specified and which only use a small number of properties. The interested reader can refer to (Dehainsala et al, 2006) for a complete description of these experiments. In this section, we have presented the OntoDB architecture that we have designed for storing ontologies and their instances. The SQL language could be used to write queries on OntoDB. However, one needs to have a deep knowledge of the storage layout used by OntoDB to write such queries. As a consequence, we have defined a specific language named OntoQL to query ontologies and their instances. 7 The OntoQL exploitation language In the last decade, a lot of Semantic Web query languages have been defined. The interested reader can