International ontologies for V-Con (D 3.4.2a) V-Con D 3.4.2a: International ontologies for V-Con

Transcription

1 V-Con D 3.4.2a: International ontologies for V-Con Version April 2016

2 Content 1 BACKGROUND INTRODUCTION THE CONTEXT ONTOLOGIES IFC AND GIS ONTOLOGIES THE INTERNATIONAL ONTOLOGY PRESENTATION THE NOTION OF UPPER ONTOLOGY IDENTIFICATION OF POTENTIAL SHARED CONCEPTS BETWEEN DUL AND COMMON_INT V DEVELOPING THE LINKING RULE SETS - PRINCIPLES AND RATIONALE ONTOLOGY EDITING ONTOLOGY ALIGNMENT TESTING THE ONTOLOGIES RESULTING STRUCTURE RECOMMENDATIONS FOR FUTURE WORK Version April 2016

3 1 Background This document describes the work done within the V-Con project in order to create ttl ontologies to support the business use cases and test cases developed in the frame of the project. This document also, together with the ontologies COMMON_INT.ttl, IFCALIGNMENT.ttl, CITYGML--COMMON_INT.ttl, IFCALIGNMENT--COMMON_INT.ttl constitute the international input for P3 (the V-Con deliverable D3.4.2). The need to propose a so called international ontology came from the project itself. Two different countries have defined their own use-cases and their corresponding ontologies in order to support the formal description of these use cases. Namely, Sweden and the Netherland have produced their V-CON national ontologies to cover each of their use cases. The reason for having a common part is multiple: - It provides an upper ontology where national (supposedly more specific) ontologies can be attached. This can be seen also as a bootstrapping structure that can be further developed (by addition of more specialised entities) to reflect specific needs. - It provides a neutral place were to gather and factorize the common entities used in both places. - It provides a neutral and common place to make international linking of information possible with no particular and nation dependant translation. This document reflects the latest developments for these ontologies. 2 Introduction The Common international ontology has been developed taking into account the work done in the Swedish (SE) & Dutch (NL) ontologies. Therefore, it contains those concepts (classes, properties and relation types) that the Swedish and Dutch Common Ontologies for road authorities have in common and are worth sharing. This Common Ontology International has been developed also taking into account it has to contain high level entities covering the 5 following key notions: - System Engineering - Process - Alignment - Infrastructure - Pavement Version April 2016

4 This ontology should also be connected to some context ontologies (IFC4 Road, InfraGML, CityGML,...) that are presented more in details later in this document. Figure 1: The international context ontologies 3 The context ontologies 3.1 IFC and GIS ontologies As mentioned in the P3 document when describing the Hybrid approach of V-Con solution (P3 Fig 4), there a different so-called context ontologies that need to be connected to the international ontology. Namely, the IFC ontology and the GIS ontology have been identified as context ontologies to the international ontology. - IFC (Industry Foundation Classes): The IFC specification is developed and maintained by buildingsmart International as its Data standard. Since IFC4 it is accepted as ISO standard. The IFC model is natively written in EXPRESS but recently an OWL version has also been published by buildingsmart. - GIS: two models have been identified has relevant in the frame of V-CON: o o InfraGML 1 : It is an evolution of LandXML 2. InfraGML is a modular conceptual model correcting LandXML weakness and easing to setup gateways with other languages (including other OGC standards, buildingsmart standards, etc ). CityGML 3 : It is a common information model and XML-based encoding for the representation, storage, and exchange of virtual 3D city and landscape models. There is an already existing ontology for CityGML 2.0. This ontology is the result 1 See : Collaboration between OGC &Buildingsmart for InfraGML, a new standard for land and infrastructure information. 2 See 3 See CityGML 2.0 : Version April 2016

5 of a work done by the a research group from the Institute for Information Service Science (ISS) within the Center for Computing (CUI) at the University of Geneva. It corresponds to a direct translation of the CityGML XMLSchema to OWL and is available online. The corresponding file is available in owl and available at Figure 2 Structure similarities between IFC and LandINFRA Thanks to the common approach followed by OGC and BSi resulting in a common data model, it is obvious to identify what are in both domains (IFC and InfraGML) the entities corresponding to the common notions. This parallel is illustrated by the figure above. In V-CON, it has been decided to integrate in the COMMON_INT.ttl the latest elements (Positioning Element & Alignment). It will be enough to then establish the needed correspondences with the context ontologies. The notion of Alignment covers: - Ability to exchange alignment information from planning to design, to construction, and finally to asset management phase - Ability to link alignment information to other project information such as cross sections and full 3D geometry of construction elements (realized by upcoming IFC-Bridge and IFC-Road projects) - Ability to query alignment information providing data such as linear referencing for positioning - Ability to allow open data access of alignment information from asset management databases Version April 2016

6 Alignment horizontal alignment vertical alignment associated requirement definitions horizontal alignment segment vertical alignment segment 3D Alignment Figure 3: General decomposition of alignment information The following principles have governed the development of the conceptual schema: Alignment is seen as a reference system associated to linear constructions, such as roads, rails, bridges, used to position elements, such as road, rail or bridge elements or other feature elements, positioned along an alignment ; A single alignment is defined as a non-branching, continuous, single alternative, single location alignment. Multiple alternatives of one alignment are multiple alignments with a different label. A single linear construction facility may have zero, one or more alignment with discriminating labels (for purposes, alternative, others); A single alignment can be represented as: A horizontal, a vertical and a resulting 3D alignment, A horizontal and a vertical alignment, Only a horizontal alignment, Only a 3D alignment (e.g. from surveying). Multiple vertical alignments can be defined using the same horizontal alignment. Future versions of the alignment conceptual schema will add support for offsets and other relationships between horizontal and vertical alignments; Alignment segment geometry includes curve types used for road constructions and a generic template for additional spirals for alignment segments used in rail constructions; Tangential continuity between alignment segments is not enforced per se by the alignment conceptual schema. It can be enforced individually by a Boolean setting. This allows using the alignment definition also for other infrastructure works, such a power lines. Version April 2016

7 The corresponding files are: - IFCALIGNMENT.TLL - IFC4_ADD1.ttl The imported IFC4_ADD1.ttl file is a recommended version of an ifcowl ontology equivalent to the IFC EXPRESS schema. This OWL version is proposed and maintained by the buildingsmart Linked Data Working Group. The ontology file can be downloaded from The IFCALIGNMENT.TLL file is available at the V-Con model server ( - /V-Con/ReleaseP3/Ontologies/INT/). The IFCALIGNMENT.TLL is importing the IFC4_ADD1.ttl file as represented by the figure below. Figure 4: IfcAlignment ontology imports the Ifc4Add1 ontology It has been decided to import the IFC4_ADD1.ttl from the web site. This site contains the various recommended OWL versions of the IFCs. The recommended version means that the translation from the EXPRESS to OWL has been done according to an explicit the set of rules that are clearly defined in a document called LDWG proposals 4. It is important at this stage to mention that there is no unique and universal translation from EXPRESS to OWL and several proposals have been made in the past. Recently an active working group (Linked data Working Group) has made a set of proposals (the LDWG 4 See : Version April 2016

8 proposals mentioned above) and the corresponding IFCOWL ontologies have been published. The TTL file that is used in the frame of V-Con is the result of the work done by this group. As a quick introduction, these translation issues (translating IFC from EXPRESS to OWL) can be presented as follow (The first two problems are in direct relationship with the work of De Farias et al. 5 ): 1- Give a real semantics to lists. In IFC EXPRESS specification, a Cartesian point uses an ordered list of real values to provide the abscissa X, the ordinate y and the height Z of a point in space. But the use of lists, the preceding or the next element of an item in the list, is not common in the Semantic Web ontologies. There, people use foremost meaningful properties to describe classes. For instance, one can define three object properties (coordinate, coordinatey, coordinatez) to represent the three coordinates of a Cartesian point. 2- Re-structure the IfcRelationship and its subtypes. IfcRelationship and its subtypes stand as bridges for n to n relationship. Instead of using detours via these bridges, it might be worthwhile to use direct properties i.e. pointing directly from n class instances to n other class instances. De Farias and colleagues provide some illustrations of this suggestion (see below), part of their IfcWod extension, and how it eases the querying of the resulting schema. Q1: SELECT?wall WHERE {?wall rdf:type ifcowl:ifcwall.?wall ifcowl:isdefinedby_of_ifcobject?rel.?rel ifcowl:relatingpropertydefinition?pset.?pset ifcowl:hasproperties_of_ifcpropertyset?p.?p rdf:type ifcowl:ifcpropertysinglevalue.?p ifcowl:name_of_ifcproperty?name.?name ifcowl:has_string "IsExternal"^^xsd:string.?p ifcowl:nominalvalue?val.?val ifcowl:has_boolean "true"^^xsd:boolean. } Q1 : SELECT?wall WHERE {?wall rdf:type ifcowl:ifcwall.?wall ifcwod:isdefinedby_ifcobject?pset.?pset pset_wallcommon:isexternal?val.?val ifcowl:has_boolean "true"^^xsd:boolean.} Here we have straightforwardly the common property set associated with IfcWall 3- Same name entities It concerns many entities in the original IFC EXPRESS specification. For example, ALUMINIUM is both member of the IfcWindowStyleConstructionEnum and the IfcDoorStyleConstructionEnum enumerations; we find the predefinedtype property in hundreds of entities. We argue that distinguishing all these entities in OWL is not always required. Indeed, in practice, is there a 5 T. de Farias, A. Roxin, C. Nicolle, IfcWoD, semantically adapting IFC model relations into OWL properties, 3 rd LDAC, Eindhoven, Netherlands, Version April 2016

9 difference between ALUMINIUM for IfcDoor and IfcWindow? If the goal of the ontology is to mention the material of an object, such distinction is probably useless. 4- Disguised data types and data properties There are many custom types in EXPRESS, which are certainly useless in OWL and whose usage is not common in the SW community. It is the case of Classes like NUMBER, REAL, STRING, etc. and their subclasses (IfcCountMeasure, IfcInteger, IfcLabel, etc.). These classes could be standard XSD datatypes and object properties whose range is one of these classes may become data properties (CountValue, LengthValue, Height_of_IfcPixelTexture, etc.). It may improve the reading and the understanding of IFCOWL files and ease the writing of SPARQL queries against an IFCOWL file. In IFC4 the IfcProxy element is mentioned in the documentation as Deprecated. It is still there just to ensure the backward compatibility but must not be used anymore. The reason for the existence of the IfcProxy comes from the earlier version of Ifc (this entity was introduced in IFC1.5) when the expressiveness of the Ifc was perhaps not enough. It was then an easy mechanism to allow user defined entities. There are some cases of CAD systems that are based on a very simplified models and thus having a poor semantic (especially with respect to the construction domain). In case of an Ifc export, these software solutions are doing a massive use of IfcProxy. The deprecation of this IfcProxy entity means that now BuildingSmart is considering the IFC model as mature enough and expresses a wish to reinforce the semantic of the Ifc files. For instance, when looking at the IfcProxy, it can be typified by the IfcObjectTypeEnum which contains the following list of possible values: PRODUCT, PROCESS, CONTROL, RESOURCE, ACTOR, GROUP, PROJECT, NOTDEFINED. Today in IFC4 all these domains are well covered. The IfcProxy is anyway linked to a corresponding entity in the COMMON_INT.ttl (via the linking ontology IFCALIGNMENT--COMMON_INT.ttl ) but we recommend not using it anymore but use instead the entities defined in the Alignment extension. 4 The International ontology 4.1 Presentation The elaboration of this ontology has followed a mix between a bottom up approach (by mixing in the COMMON_INT.ttl the entities coming from the two national ontologies) and a top-down approach (by identifying existing generic structure and entities under which our entities could be related. This second approach is related to link established with one upper ontology. Therefore, the basic principles and the underlying standards that were used to develop the national ontologies apply here also (i.e. ISO and ISO 12006). Version April 2016

10 This activity has been carried out during the last period and has led to produce the current version of the international ontology (version 0.5) which can be described by the following figures: - Composed of 159 different concepts - Sharing o o 30 concepts with Common_SE 75 concepts with Common_NL - Containing 66 concepts that are not reused either by COMMON_NL or COMMON_SE One of the difficulties encountered by proceeding in that way was to mix different approaches (as both national ontologies were also based on the compilation / multi import of parts of existing specialized ontologies). The resulting structure was containing some inconsistences that were identified during internal meetings and solved by manual edition or identified by using reasoning tools (see section Testing the ontology later in the document). At this point, it has been decided to introduce an upper ontology playing the role of a neutral high level backbone where to attach our more specialized concepts. DUL has been used in that way and the resulting alignments between the V-Con international entities and some DUL concepts are illustrated in the table below. 4.2 The notion of upper ontology As the role of the COMMON_INT.ttl is to provide the upper & common entities in the V-CON environment, one approach in the elaboration methodology has been to consider existing socalled upper ontologies as a proposal providing a neutral structure where it will be then possible to develop/refine some parts in order to support all the V-CON notions. The International ontology is the result of multiple activities that will be presented later on in chapter 4. One activity was the extraction from the two sets on national ontologies (SE & NL) of common and /or high level concepts. The NL ontology is using CMO (Concept Modelling Ontology) developed by TNO and naturally CMO concepts moved to the COMMON_INT.ttl. The CMO is presented in details in the V-Con Modelling Guide. In the literature there are a lot of debates around the notion of Upper Ontology. The Wikipedia page dedicated to the topic offers a good abstract about the difficulty to reach such paradigm and cites the most known candidates to play this role of Upper Ontology. It is define in this page that an upper ontology is an ontology which describes very general concepts that are the same across all knowledge domains. An important function of an upper ontology is to support broad semantic interoperability among a large number of domain-specific ontologies which are accessible ranking "under" this upper ontology. Version April 2016

11 There have been many upper ontologies proposed and some of them are listed on this web page. Among others, the DOLCE ontology 6 and more specifically the DUL 7 ontology have been considered. DOLCE (for Descriptive Ontology for Linguistic and Cognitive Engineering) is an upper ontology aiming at capturing the ontological categories underlying natural language and human common sense. DOLCE intents to have just descriptive (vs. prescriptive) notions. There has been some extensions of DOLCE and DnS (for Descriptions and Situations) is one of them. Both DOLCE and DnS are particularly devoted to the treatment of social entities, such as e.g. organizations, collectives, plans, norms, and information objects. A lighter version of DOLCE and DnS, with extensive inline comments is available and known as DOLCE+DnS-Ultralite (abbreviated: DUL). Figure 5: The DUL top structure 4.3 Identification of potential shared concepts between DUL and COMMON_INT V entities have been identified as belonging to this category. They are listed along with their respective definitions in the table below. 6 Ref: Gangemi, A., Guarino, N., Masolo, C., Oltramari, A., & Schneider, L. (2002). Sweetening ontologies with DOLCE. In Knowledge engineering and knowledge management: Ontologies and the semantic Web (pp ). Springer Berlin Heidelberg. 7 See the corresponding overview at : Version April 2016

12 Shared Concepts Amount Collection Contract Descriptio n Event Informatio nobject DUL Ontology Concept definition (rdfs:comment) A quantity, independently from how it is measured, computed, etc. Any container for entities that share one or more common properties. E.g. "stone objects", "the nurses", "the Louvre Aegyptian collection", all the elections for the Italian President of the Republic. A collection is not a logical class: a collection is a first-order entity, while a class is second-order. (The content of) an agreement between at least two agents that play a Party Role, about some contract object (a Task to be executed). A Description is a SocialObject that represents a conceptualization. It can be thought also as a 'descriptive context' that uses or defines concepts in order to create a view on a 'relational context' (cf. Situation) out of a set of data or observations. For example, a Plan is a Description of some actions to be executed by agents in a certain way, with certain parameters; a Diagnosis is a Description that provides an interpretation for a set of observed entities, etc. Any physical, social, or mental process, event, or state... (Very long description see online the whole text) A piece of information, such as a musical composition, a text, a word, a picture, independently from how it is concretely realized. COMMON_INT V0.3 ontology Concept definition -None- is a concept which members have a plurality that is not by definition one. Typically the plurality of the members is bigger than one. It is a number of things. Those things may be individuals, classes, relations or combinations of them.a grouping of some variable number of objects that have some shared significance. The binding document or agreement to create one or more legal obligations. is an information representation that describes a thing. a thing that happens or takes place and marks the beginning or ending of an activity. is an object that is an individual set of data with its own identity. For example: document, database data, message (with attachments), (case) file, Internet site (or any part thereof), photo / image, sound recording, wiki, blog etc. Version April 2016

13 Shared Concepts Person PhysicalO bject Process Project DUL Ontology Concept definition (rdfs:comment) Persons in common sense intuition, which does not apparently distinguish between either natural or social persons. Any Object that has a proper space region. The prototypical physical object has also an associated mass, but the nature of its mass can greatly vary based on the epistemological status of the object (scientifically measured, subjectively possible, imaginary). This is a placeholder for events that are considered in their evolution, or anyway not strictly dependent on agents, tasks, and plans. See Event class for some thoughts on classifying events. See also 'Transition'. A Plan that defines Role(s), Task(s), and a specific structure for tasks to be executed in relation to goals to be achieved, in order to achieve the main goal of the project. In other words, a project is a plan with a subgoal structure and multiple roles and tasks. COMMON_INT V0.3 ontology Concept definition -None - Thing that exists in space and time. is one or more activities that deliver a changed state to objects that are used as input. is a temporary organization that is created for the purpose of delivering one or more business products according to an agreed Business Case. Role A Concept that classifies an Object is a function assumed by a thing in a particular situation. Task An EventStructure that classifies an Action to be executed A task is typically used to describe an activity for the construction or installation of products, but is not limited to these types. Version April 2016

14 5 Developing the linking rule sets - principles and rationale The need for the definition of Linking Rule Sets (LRS) is to define explicitly mappings between concepts belonging to different ontologies. In the international context, the following LRS have been defined between the Common_int ontology and: - The IFCAlignement ontology; - The CityGML ontology; The linking rule sets are containing rules expressed via standard OWL assertions. It contains information like: - Equivalence between two classes (EquivalentClass) - Equivalence between two properties(equivalentproperty) - Subsumption relationship between two classes (subclassof) - Subsumption relationship between two properties (subpropertyof) - Disjunction between two classes (disjointwith) - Disjunction between two properties propertydisjointwith - Restriction of possible values (Restriction) Situations that cannot be defined this way will need additional ways of expression which still have to be defined. This point has been also partially mentioned earlier about the open issues in translating Express into OWL. The LRS have been defined and checked against the datasets available in order to ensure that the addressed concepts were properly linked via the corresponding LRS. These LRS are OWL files and were named as follow of the international ontology: - IFCALIGNMENT--COMMON_INT.ttl (V0.2) (linking IfcAlignment and Common_int ontologies) - CITYGML--COMMON_INT.ttl (V0.2) (linking CityGML and Common_int ontologies). 6 Ontology editing For developing this ontology, the Protégé (version béta 17) editor has been used. It is worth noticing that the Swedish and the Dutch ontologies were developed in parallel using TopBraid Composer. The file format chosen among us was Turtle (producing *.ttl files). Version April 2016

15 6.1 Ontology alignment There are various tools available online to compare ontologies. In order to establish links between the two national ontologies and between Common_Int and DUL, the alignment server 8 from INRIA has been used. This tool is based on different algorithms to identify potential similarities between to ontologies and propose some semantic alignment between them. Figure 6: The (semantic) Alignment tool used to identify similarities between ontologies. 7 Testing the ontologies The Protégé editor comes along with reasoners. It is then possible to launch some reasoning process on the existing ontologies. This has been used during the development of the ontologies to check potential inconsistencies. The default Protégé reasoner (HermiT ) has been used. This reasoned is able to generated an inferred version of the declared ontology and thus identify misuse of OWL / inconsistencies of class statements, etc. This has been helpful particularly when adapting the Common_int structure with the DUL ontology as this later is defined in a different way and contains explicit disjunctions. It is a reason why only 12 concepts were made equivalent between these two ontologies. The ontologies were also tested against data sets to check if all the entities needs in these datasets were represented in the ontologies. This test has been mainly done manually. 8 See : Version April 2016

16 8 Resulting structure Reference design of the Ontologies can be found in Con/ReleaseP3/Ontologies/ 9 Recommendations for future work At the moment the following upcoming activities are foreseen to be needed during Phase 3 of the V-Con project: - Add concepts and properties to cover the V-Con test cases - Adapt ontologies according to good advice, taking into account usability aspects in an implementation environment Version April 2016