b Swedish ontologies for V-Con (D 3.4.2b) V-Con D 3.4.2b: Swedish ontologies for V- Con

Transcription

1 V-Con D 3.4.2b: Swedish ontologies for V- Con Version March 2016

2 Content 1 BACKGROUND SOURCES FOR SWEDISH V-CON ONTOLOGIES BSAB INCLUDING ISO Spaces (UT utrymmen) Building Element (BD byggdelar) Production Results (PR produktionsresultat) ANDA CONCEPTUAL MODEL Overview Conceptual model TRANSPORT NETWORK CONCEPTUAL MODEL TRAFIKVERKET REPORTING TEMPLATE FOR REPAVEMENT ACTIVITIES DEVELOPING THE ONTOLOGIES - PRINCIPLES AND RATIONALE UML SOURCED ONTOLOGIES (ANDA AND TN) UML to OWL translation ANDA ontology TN ontology (Transport network) BSAB INCLUDING ISO Principles applied on BSAB Sources used General TRV-IDM ONTOLOGY ADDITIONAL CONCEPTS TO SUPPORT THE V-CON USE CASES COMMON-SE ONTOLOGY COMMON SWEDISH CONCEPTS DEVELOPING THE LINKING RULE SETS - PRINCIPLES AND RATIONALE TOOLS USED TESTING THE ONTOLOGIES RESULTING STRUCTURE RECOMMENDATIONS FOR FUTURE WORK Version March 2016

3 1 Background This document describes the work done within the V-Con project in order to create OWL ontologies to support the business use cases and test cases for Trafikverket. This document also, together with the ontologies, constitutes the Swedish input for the V-Con deliverable D OWL ontologies has not been used before at Trafikverket. The source ontologies come in various forms (UML, Excel, Text, ) with more or less obvious semantics. Therefore there is a need to explain the decisions made and the rationale behind the creation of OWL ontologies for these sources. One very positive outcome of this work is that all input ontologies are collected under a common metadata umbrella, in our case OWL, which makes the ontologies machine readable, exchangeable, comparable, linkable and very explicit. The resulting ontologies are the result of the work by the V-Con project members (Olle Bergman & Lars Wikström). These ontologies have not yet been reviewed and commented by the parties responsible for the sources. This will occur during the continuing course of this project. In parallel to V-Con, the source ontologies are being developed further and it is not clear if all the results of this work will be reflected in V-Con. This document is a first draft version that will be developed further as work progresses. There is therefore no guarantee that it is complete or even correct on all aspects. 2 Sources for Swedish V-Con ontologies 2.1 BSAB including ISO BSAB-96 is a classification system (a taxonomy) used in Sweden in the communication between construction companies and clients when Specifying requirements Agreeing on processes and compensation Describing the work done and the results of that work, i.e. the built environment The BSAB system is owned and maintained by Svensk Byggtjänst ( and the system was originally not designed for use in digital information systems but has become more so over time. Nowadays it may be used as basis for example when code:ifying CAD layers. It is based on ISO ;2001 and organized in tables which represent the specific subclass structure beneath the base classes in ISO :2001, e.g. construction elements, spaces, work results, processes etc. The tables in BSAB 96 we have used are: Version March 2016

4 2.1.1 Spaces (UT utrymmen) Spaces are also classified by type of activity they serve. Example: Example: 1 = Spaces for outdoor activities 11 = Spaces for traffic 111 = Spaces for road traffic 111.D = Roadways (undetermined) 111.DB = Lane (undetermined) Figure 1.17: Spaces Building Element (BD byggdelar) Building Elements (functional parts) describes the main features in the construction works, without regard to technical solutions, material content or production. Example: Example: 3 = Superstructures and facility additions 31. = Superstructures 31.B = Superstructures for Roads and Plans 31.BB = Mid Road Shoulders Figure 3.18: Building Parts Production Results (PR produktionsresultat) Production results are the result of an activity on the construction site for the production of part or whole construction works. A production results, is decided with the regard to materials and construction method, but not regarding function. Example: Version March 2016

5 Example: Figure 3.19: Production Results. D = Land Superstructures and facility additions etc. DC = Land Superstructures etc. DCC = Bitumen-bound superstructure layers for roads, surfaces etc. DCC1 = Bitumen-bound superstructure layers category A, for roads, surfaces etc. DCC14 = Bitumen-bound wearing course category A DCC141 = wearing course category A of asphalt mass DCC1412 = wearing course category A rich in stone bituminous concrete (ABS) DCC14122 = wearing course category A rich in stone bituminous concrete for maintenance The BSAB system has currently no representation available that uses a meta-model and notation that has been agreed outside the BSAB community. For our ontology we have decided, in accordance with the current work with BSAB 2.0, to use ISO :2015 standard as a basis. In the figure below an EXPRESS-G schema representation of the standard can be seen. Version March 2016

6 uses Organization model.user activity Construction space Construction complex defined by part of aggregate of Construction result Construction entity part of Construction element results in part of characterises Construction process Pre-design process Construction process lifecycle Design process Production process uses Maintenance process Construction product part of controls Management Construction aid Construction resource Construction agent has Construction property Construction information Figure 1 EXPRESS-G representation of ISO :2015 Version March 2016

7 2.2 ANDA conceptual model Overview The ANDA conceptual model was developed primarily to support the maintenance processes of Trafikverket. As such, it uses ideas and concepts from the PLCS standard (ISO ) as a basis. The scope for the ontology covers the entire lifecycle of infrastructure (road and railway) assets by separating information into three different but related views: A functional view which is fulfilled by A physical view which is realized by An individual asset view which records the way state changes over time All views may be subdivided, both by using subclassing and hierarchical breakdowns in parts. The physical view may describe how physical parts are physically put together in order to provide the desired function. Finally separating individuals from physical parts (specifications) enables recording information from the maintenance processes where individual assets may be maintained or replaced, still meeting functional and physical requirements. An important part of the ANDA ontology concerns positioning, both absolute in relation to the surface of the earth and relative. Relative may be either with regards to the road or railway networks when regarded as linear referencing systems (LRS) or with regards to other assets in the infrastructure. For absolute geographic positions and for LRS positions, GIS standardization within ISO/TC211 and OGC has been used. The conceptual model for ANDA in its basic form is represented using UML and developed much according to the ISO Rules for application schemas. The ANDA structure shall primary be viewed as a set of information requirements. In an implementation situation, there might be efficient data structures solving the exact problem as ANDA but in a slightly different manner. This should not be a problem as long as the information content in a data exchange is the same. The ontology contains concepts that are useful for all three business use cases of V-Con since it contains: Systems engineering concepts Alignment concepts according to the conceptual model for alignment as defined by IFC and OGC together Pavement concepts The scope for ANDA does not include concepts like projects and activities. Furthermore, the available model for ANDA has not specialized the class hierarchy to a level that is concrete enough for V-Con. Therefore, the work within V-Con also includes providing plausible specializations to a level that is useful for the V-Con use cases. Version March 2016

8 2.2.2 Conceptual model As earlier stated, the ANDA model tries to apply PLCS concepts and intentions for infrastructure asset management. The figure below gives an overview idea about the overall concept. Functional resource Function Physical resource Physical spec. Individual resource Fulfiller Realization Figure 2 - ANDA concepts Basically, assets are described through three basic and related views: - As functional resources which captures the functional view. A functional resource may have several possible fulfillers - As physical resources which fulfill the functions. The physical resources captures physical properties such as shape, position and material. Ultimately a physical resource may be implemented by several possible products. - As individual resources which represent the physical thing in the real world which has state, performance etc. The individual resource may be repaired, replaced etc without changing the physical or functional specifications From these basic concepts a UML model has been developed which is illustrated below: Version March 2016

9 Figure 3 - ANDA UML model The following concepts are especially worth noting: Class ChangeHistoryObject Resource {@en} Description Base class that requires all resources to record versions, i.e. the states of the data representations. These states may include both changes due to real world changes and corrections of errors in the data itself. This class is defined outside ANDA and reused. Base class for an ANDA resource. Sub class to ChangeHistoryObject. Version March 2016

10 Class Resurs Baseline Description Any type of Resource may be organized in sub class structures as well as breakdowns (part of, has part) A named collection of versions of objects Baslinje {@se} FunctionalResource {@en} FunktionellResurs {@se} PhysicalResource {@en} FysiskResurs {@se} A kind of resource that captures a functional need. This functional need is fulfilled by zero to many PhysicalResource A kind of resource that captures the physical characteristics of something that fulfills a functional need and/or the physical characteristics of something that has a functional need. A PhysicalResource may specify its physical relationship (position) to other physical resources or to external resources, such as the surface of the earth. One PhysicalResource may be reused in many positions. A PhysicalResource is realized by zero to many IndividualResource IndividualResource {@en} IndividResurs {@se} An individual resource represents one planned or real thing that realize one or more PhysicalResource. An IndividualResource may record state changes over time (such as observations, or the result of maintenance activities) 2.3 Transport network conceptual model At Trafikverket, all roads (state, municipal, private, ) are described geometrically, topologically and temporally as a collection of links and nodes in the NVDB (National Road Database). The NVDB is a common and shared resource and not unique for ANDA. The network data describes how the roads are topologically connected (how it is possible to navigate the network), the geometric location and shape for the roads and also the temporal aspects (when the roads exist and are open for traffic). Furthermore, the network model is used as a reference system (or a gazetteer) for locating other data such as assets, events (e.g. accidents), traffic regulations, administrative data (e.g. road name, number, owner etc.) and more. To achieve this in an efficient manner, higher order network elements are also introduced (such as LinkSequence as in INSPIRE DS TN [ 0.pdf]) which to their nature are stable enough over time to be suitable for offering linear referencing mechanisms for positioning data along the network. For ANDA, the NVDB is essential to give a harmonized way for positioning assets (in addition to geodetic reference systems) and it gives straightforward and flexible ways of joining different kinds of data (also data from other applications) covering overlapping locations. To achieve this, the NVDB offers, Version March 2016

11 in addition to the network itself, a number of classes (mechanisms) that shall be used to locate things along the network in a standardized manner INSPIRE DS TN and the standards from ISO/TC211 and OGC upon which INSPIRE is based heavily influence the transport network schema at Trafikverket. The conceptual model for the Transport Network in its basic form is represented using UML and developed much according to the ISO Rules for application schemas. The Transport Network structure shall primary be viewed as a set of information requirements. In an implementation situation, there might be efficient data structures solving the exact problem as the Transport Network model but in a slightly different manner. This should not be a problem as long as the information content in a data exchange is the same. Furthermore, the Transport network model captures the requirements from INSPIRE, which is European law. These requirements are mandatory. The two diagrams below illustrates the basic structure for transport networks in the NVDB. Figure 4 - Transport network - root structure Version March 2016

12 Figure 5 - Transport network - network structure Below, the basic structure for referencing various types of locations in the network is illustrated. Version March 2016

13 Figure 6 - Location referencing vs the network model In the table below, the classes used for the V-Con ontology for transport networks are described. Class NetworkElement {@en} Nätelement {@se} GeneralizedLink {@en} GeneraliseradLänk {@se} Description An element in a network. Every element in a network provides some function that is of interest in the network. (INSPIRE) A linear network element that may be used as a target in linear referencing (INSPIRE). Version March 2016

14 Class Node Nod Link Länk LinkSequence Referenslänk Description A point spatial object which is used for connectivity. Nodes are found at either end of the Link. (INSPIRE) A linear spatial object that describes the geometry and connectivity of a transport network between two points in the network (INSPIRE) A linear spatial object, composed of an ordered collection of transport links, which represents a continuous path in the transport network without any branches. The element has a defined beginning and end and every position on the transport link sequence is identifiable with one single parameter such as length. It describes an element of the transport network, characterized by one or more thematical identifiers and/or properties. (INSPIRE) In the table below, the classes used for the V-Con ontology for mechanisms to relate other information to transport networks are described. Class Linkreference {@en} Description Describes an indirect location along a GeneralisedLink Länkutbredning {@se} LineLinkReference {@en} Sträckutbredning {@se} LineLinkRoadReference {@en} Vägutbredning {@se} PointLinkReference {@en} Punktutbredning {@se} NodeReference {@en} A LinkReference that describes a subset of a GeneralisedLink with a length greater than 0. The subset is bounded by two positions along the GeneralisedLink which are not equal A type of LineLinkReference especially designed to capture the way road numbers are assigned to linear elements in the road network A LinkReference that describes a point on an along a GeneralisedLink. The point is identified with a position along the GeneralisedLink Describes an indirect location on a Node in a network Nodutbredning {@se} TurnReference {@en} Describes a turn through a Node Svängutbredning {@se} Version March 2016

15 2.4 Trafikverket reporting template for repavement activities Trafikverket has a large number of templates for reporting activities of various kinds. For V-Con, since there is a repavement use case, we have selected to use a reporting template for repavement activities. The selected template is implemented using MS Word and contains mandatory and optional fields and includes concepts which are not included in the other sources used. The template describes a hierarchical structure with the following principal structure: - A project which consists of o Project id o Project type (e.g. carrying capacity, o General description o County o Road number o Project leader o Contractor o Temporal restrictions o Guarantee o Activities, where each activity describes Activity type (for example patch wise or complete repavement) Activity date A Location specified by road number, from and to geodetic positions or lengths and also which lanes are affected A Layer which specifies Material (a number of parameters for binder, additive etc) Thickness Area and volume Cost/unit From the layer level, the descriptions start to align with other available ontologies. 3 Developing the ontologies - principles and rationale 3.1 UML sourced ontologies (ANDA and TN) UML to OWL translation Both the ANDA and the Transport Network schema use UML. We used a number of principles at a generic level to translate UML schemas to OWL. These principles are described in the table below. Version March 2016

16 UML concept OWL concept Comment Class Class Relationship (association) Class Relationship (aggregation) Class Relationship (composition) Class Relationship (inheritance) Attribute Multiplicity (cardinality restrictions) for attributes and Enumeration class or <<CodeList>> Class ObjectProperty per named role. Normally both roles (if both have names/restrictions) are translated to owl and specified as inverse. ObjectProperty per named role. Normally both roles (if both have names/restrictions) are translated to owl and specified as inverse. ObjectProperty per role. Normally both roles (if both have names/restrictions) are translated to owl and specified as inverse. SubClass ObjectProperty or DatatypeProperty depending on the range of the property (class or value). Subclass restriction Class + individuals Subproperty to cmo:hasaspect Range and Domain are set based on assumptions regarding the genericness of the property. If very generic only subclass restrictions are used. Range and Domain are set based on assumptions regarding the genericness of the property. If very generic only subclass restrictions are used. Depending on the genericness of the property: - Subproperty of cmo:haspart with domain and/or range specified - Subproperty of cmo:haspart and subclass restriction - Subclass restriction on cmo:haspart Range and Domain are set based on assumptions regarding the genericness of the property. If very generic only subclass restrictions are used. A class that corresponds to the enumeration/codelist class and individuals for each enumerated value Version March 2016

17 3.1.2 ANDA ontology Translation of the ANDA UML model into OWL was mostly a straightforward activity. Most questions were raised when dealing with very generic concepts such as concepts for positioning where consideration has to be made with regards to the relationship with the common ontologies. An important part of the ANDA ontology concerns positioning, both absolute in relation to the surface of the earth and relative. Relative may be either with regards to the road or railway networks when regarded as linear referencing systems (LRS) or with regards to other assets in the infrastructure. For absolute geographic positions and for LRS positions, GIS standardization within ISO/TC211 and OGC has been used in ANDA. For the time being, the OGC GeoSPARQL ontology was used to capture these geographic aspects in the ontology. The ANDA UML schema contains ideas for solutions regarding very generic concepts like identification, versioning, baselines etc where the identification and versioning scheme is developed to support an optimistic concurrency approach. These parts of the ontology was translated very much 1:1 but the ontology structure might be reconsidered if there are other available and perhaps standardized schemes solving the same problem TN ontology (Transport network) We started by developing a separate TN ontology and included the parts of the transport network ontology necessary to fulfill the requirements from the V-Con use cases. Since there is a corresponding INSPIRE ontology (draft) at european level, we decided to include the generic network concepts in the common international ontology. Therefore, the separate TN ontology for Swedish use cases was dropped. Still, we describe here the basic network concepts that is the basis for the other Swedish ontologies: - NetworkElement base class. The set of all elements with a function in the network - GeneralisedLink subclass to NetworkElement and base class for the set of elements in the network which are linear - Link Subclass to GeneralisedLink representing a link between two neighbouring and connected nodes - LinkSequence - Subclass to GeneralisedLink representing a linear element as a sequence of Links - Node Subclass to NetworkElement which represents the start or end of one or more links Version March 2016

18 Figure 7 - Links, nodes and LinkSequence The above figure illustrates a small subset of the NVDB network with links, nodes and a highlighted LinkSequence. The necessary geometry is at the moment defined using the GeoSparql property geo:hasgeometry, restricting the range to either LineString (for linear elements) or Point (for nodes). In order to be able to describe the location of things along the network, the following classes where included: - LineLinkReference Define a linear location along a linear element (a subset of the linear element with a length > 0) - PointLinkReference Define a point location along a linear element (an infinitely short subset of the linear element) - LineLinkRoadReference A special case of location for defining road numbers according to the principles in the NVDB - NodeReference Define a location at a node - TurnReference Define the location of a turn through a node Within the work with V-Con ontologies, a number of really basic concepts related classes was created in the common international ontology as well. These are: - LocationInstance Reused from the ISO standard and represents a member in a gazetteer, i.e. something which can be referenced in an indirect location referencing context - LinearElement Reused from ISO and represents and element which may be referenced in a linear referencing context Version March 2016

19 3.2 BSAB including ISO So far, the Swedish names for concepts has not been translated to English. It is our belief that the V-Con solution should work without actually understanding the symbols that represents the various concepts and therefore is really ontology driven. At the moment, there is ongoing work in Sweden with BSAB 2.0 which will be based on ISO :2015 and to a larger extent consider the BIM business and support digital solutions to a greater extent. As much as possible, we tried to consider this work when designing the BSAB ontology. As is the case with ANDA, some concepts necessary for a complete data exchange in the context of V-Con are missing. Furthermore, currently BSAB lacks a classification for data properties which are necessary to cover the information requirements in the V-Con use cases. To cover these needs, the TRV-IDM ontology below was developed. The option to use object and data properties instead of further subclassing also made it possible to create a slightly shallower subclass hierarchy for V-Con than BSAB use today Principles applied on BSAB For V-Con, an OWL representation has been created of both the latest version of ISO i.e. ISO :2015 and BSAB, where BSAB imports and subclasses ISO In V-con we have included concepts in the ontology defined in ISO :2015 but not visualized in figure 1 like; a top class iso12006:object defined as <any part of the perceivable or conceivable world. Note 1 to entry: An object is something abstract or physical toward which thought, feeling, or action is directed> iso12006:constructionobject defined as <object of interest in the context of a construction process> subclass of iso12006:object and superclass of iso12006:constructionprocess, iso12006:constructionresult, iso12006:constructionresource and iso12006:space iso12006:constructionsystem defined as <interacting construction objects organized to achieve one or more stated purposes [ISO/IEC 15288:2008, modified] > subclass of iso12006:object Iso12006:NaturalEnvironment defined as < the non-artificial environment of any concrete construction object> subclass of iso12006:object Iso12006:UserActivity defined as < desired functions and user activities enabled by Construction entities> subclass of iso12006:object We have also been influenced by the Principles for information systematics within building and asset management basis for a new BSAB. According to these principles basis for classification of ConstructionElement are function, shape and placement. Members of the same class of ConstructionElement may differ concerning e.g. material, application method etc. These characteristics can be defined by references to classes in the ProductionResult hierarchy as properties. ProductionResult in BSAB are parts in a construction defined by e.g. material, application method etc. The ProductionResult hierarchy consist of classes corresponding to classes in ConstructionElement hierarchy. An example is wearing layer being a (single) subclass of ConstructionElement with the ability to specialization by referencing different sets of properties Version March 2016

20 defined within the ProductionResult hierarchy corresponding to different types of wearing layers (today approximately 50 different types of wearing layers). We have decided not to classify/subclass 50 different types of wearing layers. Instead differing types of wearing layers is done by material properties. These material properties (classes) are not considered to be specific for BSAB so they are defined in the Common-SE ontology. In the BSAB ontology we have decided to define BSAB:ConstructionProperty as a subclass of iso12006:object and enable any subclass of iso12006:constructionobject to include property restrictions from the range BSAB:ConstructionProperty. The decision to treat properties as classes is also based on V-Con modelling guide. We have also decided to consider BSAB:WorkResult, defined in ISO as < a view of construction result for the purpose of procurement >, as a subclass of (view of) BSAB:ConstructionProperty. We have defined BSAB:ProductionResult as a subclass of BSAB:WorkResult. According to ISO a production result can be a construction entity part or an enabling result. In the current BSAB model we have only included concepts related to entity part as subclasses to BSAB:ProductionResult. In the BSAB ontology we have also introduced BSAB:ConstructionSpace, subclass of iso12006:constructionresult, as the concept of space defined as < Space occupied by construction element>. This is a realization of the statement <Spaces occupied by construction elements are known as construction spaces, and are handled as properties of construction elements themselves> in ISO This gives the ability to relate spaces e.g. lane (with optional properties) to construction element e.g. wearing layer further specialized by production result. In the principles for the new BSAB it s intended to introduce TechnicalSystem (TeknisktSystem) as a subclass of iso12006:constructionelement. The intention with this is to provide the ability to specify (normally predefined) specialized systems (aggregates) of ConstructionElement organized to achieve one or more stated purposes. Example of a TechnicalSystem could be the superstructure of a road defined as a class RoadSuperstucture. The discriminator for this class is that it can only have SuperstuctureLayerRoad as parts (properties). The individual (named) TechnicalSytem s of interest are defined by their specific composition of layers. We have chosen to enable this specialization by instantiation, rather than sub classing, thus providing named specifications (templates) for the technical systems of interest. We believe this approach gives a more flexible and dynamic solution. TechnicalSystem is also implemented in the subsystem BSAB:ConstructionSpace in a similar way as in the subsystem iso12006:constructionelement Sources used The sources we have used for ontologies are three parts of the current BSAB system extended with specializations for TRV (infrastructure). One part BSAB 96 building element essentially covers Construction element. The second part BSAB 96 Space covers Construction space in ISO There are some ambiguousness between space and building element so we have done our own interpretation. The third part production results essentially covers a view of Construction result defined in ISO as Work result. Version March 2016

21 We have selected parts of the current content of the sources, especially parts related to V-Con use cases, and modified it according to the principles. In BSAB the concept of alignment is missing. We have decided not to introduce alignment in BSAB instead alignment is covered in the other ontologies. Other concepts of interest in information exchange are concepts related to process. As these concepts to a large extent are specific for an organization we have decided not to elaborate them within BSAB or iso12006 but instead define TRV specific concepts/aspects in TRV-IDM General The current version of the ontology is not consistent regarding the principles described above. The reason for this is that the starting point for the development of the BSAB ontology was to fill it with a raw translation of essentially road specific concepts from the current BSAB 96 TRV versions. Applying the principles is so far only done on parts of the ontology related to the use cases in V-Con. In the work with BSAB we have used an early version of the ISO :2015 ontology and there are some issues as can be seen above that might result in a new version of the ISO :2015 ontology. 3.3 TRV-IDM ontology Additional concepts to support the V-Con use cases As described earlier there are numerous reporting templates in use within TRV. Generic concepts for projects and activities exist in the common-int ontology. Project also by nature introduces concepts related to e.g. organizations, roles, persons which also have general definitions in the common-int ontology. Specific properties and sub classes for these are expressed in the TRV-IDM ontology. Other concepts in TRV-IDM are related to localization and the use of different kind of gazetteers i.e. county and road number. 3.4 Common-SE ontology Common Swedish concepts The Common-SE ontology was developed within V-Con since no such ontology (like CB-NL in the NL) exists. The basic principle is that this ontology shall consist of concepts of the following categories: - Harmonized definitions of overlapping concepts from several context ontologies, i.e. the intersection of these ontologies and not the union - Concepts (properties) needed to discriminate the concepts according to the above - Otherwise generic and reusable concepts where there are requirements and agreements that these concepts shall be used and no competing concepts are allowed Since Common-SE did not exist to begin with, it is developed using a simultaneous top-down and bottom-up approach: Version March 2016

22 - Top-down since it shall comply with the top model which was agreed within V-Con - Bottom-up since the concepts shall cover some need in one or more contexts. No nice-to-have concepts shall be added to this ontology The Common-SE ontology has during phase 2 of V-Con been harmonized and negotiated with the corresponding ontology from RWS to populate the common-int ontology. The aim is that as many concepts as possible shall exist at the international level. Some work at this level still remains at the time this document, and the Swedish ontologies, are published as drafts during phase 2 of V-Con. 3.5 Developing the linking rule sets - principles and rationale When moving and generalizing concepts to the common-int/-se ontologies we create the necessary linking rule sets between the context ontologies and the corresponding common concepts. The figure below explains the principle for creating linking rule sets:: Context Ontology 1 Context Ontology 1 Linking rule set 1 Linking rule set 2 Common Ontology Figure 8 - Linking rule sets The linking rule sets are separate datasets containing linking statements that explicitly links concepts together, thereby enabling data conversion. Keeping the linking rule sets is based on a decision in V-Con (see V-Con Linking Guide) with the primary reason to keep the original ontologies clean. The linking rule sets contains standard OWL assertions together with additional information when OWL is not enough. OWL assertions are primarily based on: - EquivalentClass - EquivalentProperty - subclassof - subpropertyof Version March 2016

23 - disjointwith - propertydisjointwith - Subclass restriction Situations that cannot be defined this way will need additional ways of expression which still has to be defined. A simple example of such a case is a derived attribute such as pavedarea = roadsegmentlength * lanewidth * nrofpavedlanes. As earlier explained, the workflow starts in the context ontologies. When comparing different context ontologies, common concepts and linkings may be defined. The aim is that all concepts in context ontologies shall have links to a common ontology giving a machine interpretable definition. In other words, each context concepts shall have a definition in terms of existing and defined common concepts. Based on the existence of ontologies, the following linking rule sets have been created for Sweden: - BSAB--COMMON_SE (links BSAB to COMMON) - ANDA--COMMON_SE (links ANDA to COMMON) - TRV-IDM COMMON_SE (links TRV-IDM to COMMON) 4 Tools used For developing ontologies, several tools are possible. One advantage of OWL compared to e.g. UML is that OWL is defined lexically which enables portability between tools. It would be possible to use any text editing tool in principle such as Notepad. However, since OWL syntax is not fluent (yet) for us, we needed a more advanced tool We started by using Protegé which worked fine. Since the dutch side of V-Con already were using TopBraid Composer, we selected to switch tool after a while. For V-Con purposes, it is possible to use the free edition. After using the tool a while we upgraded to a standard edition license to have better possibilities for graphics end re-engineering the ontologies (e.g. moving concepts between ontologies). We are also using TopBraid Composer to test ontologies by creating separate datasets (of individuals), instantiating selected scenarios from our V-Con use cases. In TopBraid we created a project on a shared disk with the following structure: - V-Con(project) o ANDA (folder) ANDA.ttl o ANDA COMMON_SE (folder) ANDA COMMON_SE.ttl o BSAB (folder) BSAB.ttl o BSAB COMMON_SE (folder) Version March 2016

24 BSAB COMMON_SE.ttl o COMMON_SE (folder) COMMON_SE.ttl o Data (folder for test data) ANDA1.ttl (ANDA data - alignment) Repavement1.ttl (Repavement data) o TRV-IDM (folder) TRV-IDM.ttl o TRV-IDM COMMON_SE (folder) TRV-IDM COMMON_SE.ttl o ISO (folder) iso ttl Different users may import the project to different TopBraid (eclipse) workspaces, enabling parallel work with something that resembles optimistic concurrency on file level. 5 Testing the ontologies Regarding test data and testing the ontologies. TopBraid composer gives quite good possibilities since it is ontology aware and provides editing forms for individuals were it is possible to test that the ontology structure with classes, properties, subclass restrictions etc. are in the correct place with the correct definition. We have not tested data validation but would like a good method to do this even if it means closing the open world. Version March 2016

25 Figure 9 - Example of testing ontologies by creating individuals The above screenshot shows an example on an ontology aware registration form for an individual of a certain class. The forms will contain links which enables traversing hierarchical structures and also navigation into the ontologies. Another good tool is the diagram view which displays an overview diagram for a certain class. An example below with a context diagram for a network Link. Version March 2016

26 Figure 10- Context diagram 6 Resulting structure Reference design of the Ontologies can be found in Con/ReleaseP3/Ontologies/ Version March 2016

27 7 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 March 2016