Swedish Ontologies for V-Con (D 3.4.2)

V-Con / 1(24)
Lars Wikström / Swedish ontologies for V-Con (D 3.4.2)

Swedish ontologies for V-Con (D 3.4.2)

Table of Contents

Swedish ontologies for V-Con (D 3.4.2)

Change history

Background

Sources for Swedish V-Con ontologies

BSAB including ISO 12006-2

ANDA 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 12006-2

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

Change history

Date / Version / Name / Change
2015-09-21 / 1.0 / Lars Wikström
Olle Bergman / Created document
2016-02-27 / 1.1 / Lars Wikström / The TN ontology was moved into COMMON

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 D3.4.2.

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.

Sources for Swedish V-Con ontologies

BSAB including ISO 12006-2

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 12006-2;2001 and organized in “tables” which represent the specific subclass structure beneath the base classes in ISO 12006-2:2001, e.g. construction elements, spaces, work results, processes etc.

The tables in BSAB 96 we have used are:

Spaces (UT utrymmen)

Spaces are also classified by type of activity they serve. Example:

Figure 1.17: Spaces. / Example:
1 = Spaces for outdoor activities
11 = Spaces for traffic
111 = Spaces for road traffic
111.D = Roadways (undetermined)
111.DB = Lane (undetermined)

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:

Figure 3.18: Building Parts. / Example:
3 = Superstructures and facility additions
31. = Superstructures
31.B = Superstructures for Roads and Plans
31.BB = Mid Road Shoulders

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:

Figure 3.19: Production Results. / Example:
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 12006-2:2015 standard as a basis. In the figure belowan EXPRESS-G schema representation of the standard can be seen.

Figure 1EXPRESS-G representation of ISO 12006-2:2015

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 10303-239) 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 19109 – 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.

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.

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:

Figure 3 - ANDA UML model

The following concepts are especially worth noting:

Class / Description
ChangeHistoryObject / 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.
Resource {@en}
Resurs {@se} / Base class for an ANDA resource. Sub class to ChangeHistoryObject.
Any type of Resource may be organized in sub class structures as well as breakdowns (part of, has part)
Baseline {@en}
Baslinje {@se} / A named collection of versions of objects
FunctionalResource {@en}
FunktionellResurs {@se} / A kind of resource that captures a functional need. This functional need is fulfilled by zero to many PhysicalResource
PhysicalResource {@en}
FysiskResurs {@se} / 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)

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 [ 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, 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 19109 – 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

Figure 5 - Transport network - network structure

Below, the basic structure for referencing various types of locations in the network is illustrated.

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 / Description
NetworkElement {@en}
Nätelement {@se} / An element in a network. Every element in a network provides some function that is of interest in the network. (INSPIRE)
GeneralizedLink {@en}
GeneraliseradLänk {@se} / A linear network element that may be used as a target in linear referencing (INSPIRE).
Node {@en}
Nod {@se} / A point spatial object which is used for connectivity. Nodes are found at either end of the Link. (INSPIRE)
Link {@en}
Länk {@se} / A linear spatial object that describes the geometry and connectivity of a transport network between two points in the network (INSPIRE)
LinkSequence {@en}
Referenslänk {@se} / 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 / Description
Linkreference {@en}
Länkutbredning {@se} / Describes an indirect location along a GeneralisedLink
LineLinkReference {@en}
Sträckutbredning {@se} / 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
LineLinkRoadReference {@en}
Vägutbredning {@se} / A type ofLineLinkReference especially designed to capture the way road numbers are assigned to linear elements in the road network
PointLinkReference {@en}
Punktutbredning {@se} / A LinkReference that describes a point on an along a GeneralisedLink. The point is identified with a position along the GeneralisedLink
NodeReference {@en}
Nodutbredning {@se} / Describes an indirect location on a Node in a network
TurnReference {@en}
Svängutbredning {@se} / Describes a turn through a Node

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

Project id
Project type (e.g. carrying capacity,
General description
County
Road number
Project leader
Contractor
Temporal restrictions
Guarantee
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.

Developing the ontologies - principles and rationale

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.

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

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.