Dutch Ontologies for V-Con

V-Con / 1(10)
Bart Bink / Dutch ontologies for V-Con

Dutch ontologies for V-Con

Table of Contents

Dutch ontologies for V-Con

Change history

Background

Sources for Dutch V-Con ontologies

KernGIS

General

Modeling the ontology of KernGIS

IVON

General

Modeling the ontology of IVON

COINS 2.0

RWS OTL Transport network conceptual model

Developing the ontologies - principles and rationale

Common-NL ontology – Common Dutch 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 / 0.8 / Lars Wikström
Olle Bergman / Created document
2016-01-22 / 0.9 / Bart Bink / Adapted for Dutch ontologies
2016-02-02 / 11 / Bart Bink / Finalised for 2-3-2016 publication

Background

This document describes the work done within the V-Con project in order to create RDF/OWL ontologies to support the business use cases and test cases for Rijkswaterstaat. This document, together with the ontologies, constitutes the Dutch input for the V-Con deliverable for P3.

OWL ontologies have been used before at Rijkswaterstaat. However, the source for the ontologies come in various forms (Excel, SQL manuals, …) 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 so called context- and common ontologies are the result of the work by the V-Con project member. The context ontologies were developed based on reviewed and approved models by the parties responsible for the sources. These models were made in a proprietary application. 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.

To link the context ontologies to the ontologies at the hart of the V-CON solution, Linking Rule Sets are defined. The linking rule sets are defined in OWL. However, OWL does not have the capability to do complex conversions. Where complex conversions are to be made simple pseudo code / English is used to express what is to be done. This is work in progress and will be updated.

This document was developed as part of the updated specification for Phase 2 of the V-Con project and reflects the current state of the development of the Dutch ontologies. The final version of this document will be part of the updated specification for Phase 3. The document will evolve as the work with V-Con ontologies continues during Phase 2.

Sources for Dutch V-Con ontologies

KernGIS

General

KernGIS is an application to manage state road configuration and routes. When maintenance is finished on a road, or when any other change has been made to a road, the contractor is responsible to provide the information about the change. The District exports a part of the road model from the KernGIS database with the Import and Export tool.

There are two flavours: PGDB file or Shape files. The most common are the PGDB files.

The export is sent to the contractor who updates the file with the changes. The updated PGDB file is then sent to RWS and checked and if it is passed, imported by the District in the KernGIS database.

If there are only minor changes, like repavement, a separate PGDB file is sent with only the changes of pavementlayers, lining and sample coordinates.

The objects used in the KernGIS context ontology are:

Dutch ontologies for V-Con_v11.docxVersion 112016-03-02

V-Con / 1(10)
Bart Bink / Dutch ontologies for V-Con
lBedrJuridisch
lGeleideconstructie
lGrens
lGroen
lKabelLeiding
lKunstwerk
lLicht
lMarkering
lOndergrondsObstakel
lWaterafvoer
lWegmeubilair
pBedrJuridisch
pBoorkern
pBpsAnnotatie
pGroen
pHectometerbord
pKabelLeiding
pKunstwerk
pLicht
pMarkering
pOndergrondsObstakel
pVoorziening
pWaterafvoer
pWegmeubilair
vBedrJuridisch
vBeheersituatie
vBpsSelectie
vGebouwInstallatie
vGroen
vKunstwerk
vMarkering
vOndergrondsObstakel
vProject
vTerrein
vVerharding
vWaterafvoer
vWegmeubilair

Dutch ontologies for V-Con_v11.docxVersion 112016-03-02

V-Con / 1(10)
Bart Bink / Dutch ontologies for V-Con

The prefix ‘l’ indicates the object is represented by a line. The prefix ‘p’ indicates the object is represented by a point. The prefix ‘v’ indicates the object is represented by a plane.

The Dutch areloosely translated as follows:

BedrJuridisch
Beheersituatie / Situation to manage
Boorkern / drill core
BpsAnnotatie / BPS annotation
BpsSelectie / BPS selection
GebouwInstallatie / building Installation
Geleideconstructie / Guardrail
Grens / Boarder
Groen / Vegetation
Hectometerbord / Hectometer sign
KabelLeiding / Cable line
Kunstwerk / Civil construction on roads or waterways
Licht / Light
Markering / (road)markings
OndergrondsObstakel / Obstacle below surface
Project / Project
Terrein / Terrain
Voorziening / Appliance
Waterafvoer / Water drainage
Wegmeubilair / Furniture for on and around the road

Modelling the ontology of KernGIS

The source for the KernGIS context ontology is the SQL table schema of the KernGIS application witch was explained and mapped to concepts in the natural language at Rijkswaterstaat. These concepts in the natural language of Rijkswaterstaat formed the base for the forming of the common ontologies. Concepts and properties with international consent are placed in the COMMON_INT ontology. Concepts and properties with a typical Dutch character are placed in the COMMON_NL ontology. Finally, concepts and properties specific to Rijkswaterstaat are placed in the COMMON_RWS ontology.

For the concepts in the KernGIS context ontology an effort is made to be as explicit as possible.

As concepts are derived from SQL tables the concepts have the same names and letter casing as the original table names.

Also all concepts are regarded to be mutually disjoint.

All fields in the table expression referring to other tables are mapped as owl:ObjectProperty. The restrictions as in domain and range, are not defined in the owl:ObjectProperty definition, but in the owl:Class definition as restrictions.

All fields in the table with values not linking to other tables are mapped as owl:DatatypeProperty with no defined domain and a range of xsd:string.

Using this procedure the modeling of the KernGIS context ontology is a straight forward process. And because the use of the context ontology is primarily to relay datasets to the KernGIS application, no KernGIS intelligence or constraints are modeled. That is left to the specialized KernGIS application itself.

IVON

General

IVON is a graphical, computational-intensive application in Visual Basic. For storage of data IVON uses an Access database because the data must be available on the laptop of the consultant. Remember, this is a dated application in software terms.

The input for IVON concerns the road network of a service base and the corresponding measured damage is provided by Winfrabase. The Winfrabase database is not directly accessible but IVON imports ASCII-file extracts according to the SGML-standard. In addition, IVON uses so-called domain datawhich provides parameters for the calculation process of IVON.

IVON calculates a multi-year plan for maintenance cycles of the road network.

The objects used in the IVON context ontology are:

Dutch ontologies for V-Con_v11.docxVersion 112016-03-02

V-Con / 1(10)
Bart Bink / Dutch ontologies for V-Con
DBW_SOORTEN_VERHARDING
DBW_BAANPROFIELEN
DBW_BAANPROFIELSTROKEN
DBW_MEETCOMBINATIES
DBW_MEETCONDITIES
DBW_MEETKENMERKEN
DBW_MEETSOORTEN
DBW_NORMKLASSEN
DBW_ONTWERPSNELHEDEN
DBW_STATUSSEN
DBW_TYPEN_VERHARDING
DBW_BAANVAKKEN_BEHEERDER
DBW_BAANVAKKEN_BPS
DBW_BAANVAKKEN_ONTWERPSNELHEID
DBW_VERBINDINGEN
DBW_VERHARDINGSDELEN
DBW_STROOKVAKKEN_BPS
DBW_HECTOMETERBORDEN
DBW_WEGEN
DBW_HECTOMETERREEKSEN
DBW_BAANAANSLUITINGEN
DBW_KNOPEN
DBW_SPITSSTROKEN
DBW_SPITSSTROOKVAKKEN
DBW_STROKEN
DBW_STROOKVAKKEN_BREEDTE
DBW_METINGEN
DBW_MEETPROJECTEN
DBW_MEETOPMERKINGEN
DBW_MEETRESULTATEN
DBW_REGIONALE_DIRECTIES
DBW_DIENSTKRINGEN
DBW_SOORTEN_VERHARDING
DBW_BAANPROFIELEN
DBW_BAANPROFIELSTROKEN
DBW_MEETCOMBINATIES
DBW_MEETCONDITIES

Dutch ontologies for V-Con_v11.docxVersion 112016-03-02

V-Con / 1(10)
Bart Bink / Dutch ontologies for V-Con

The prefix ‘DBW_’ is a naming protocol of the underlying database.

The Dutch are loosely translated as follows:

BAANAANSLUITINGEN / CARRIAGEWAY CONNECTION
BAANPROFIELEN / CARRIAGEWAY PROFILES
BAANPROFIELSTROKEN / CARRIAGEWAY PROFILE STRIPS
BAANVAKKEN BEHEERDER / CARRIAGEWAY SECTION ADMINISTRATOR
BAANVAKKEN BPS / SECTION BPS
BAANVAKKEN ONTWERPSNELHEID / SECTION DESIGN SPEED
DIENSTKRINGEN / SERVICE DISTRICTS
HECTOMETERBORDEN / HECTOMETER SIGN
HECTOMETERREEKSEN / HECTOMETER SERIES
KNOPEN / NODES
MEETCOMBINATIES / MEASUREMENT COMBINATIONS
MEETCONDITIES / MEASUREMENT CONDITIONS
MEETKENMERKEN / MEASUREMENT FEATURES
MEETOPMERKINGEN / MEASUREMENT NOTES
MEETPROJECTEN / MEASUREMENT PROJECTS
MEETRESULTATEN / TEST RESULTS
MEETSOORTEN / TEST TYPES
METINGEN / MEASUREMENTS
NORMKLASSEN / STANDARDS
ONTWERPSNELHEDEN / DESIGN SPEED
REGIONALE DIRECTIES / DISTRICTS
SOORTEN VERHARDING / TYPES ROAD SURFACE
SPITSSTROKEN / RUSH HOUR LANES
SPITSSTROOKVAKKEN / RUSH HOUR LANE SECTIONS
STATUSSEN / STATUS
STROKEN / LANES
STROOKVAKKEN BPS / LANE SECTIONS BPS
STROOKVAKKEN BREEDTE / LANE SECTION WIDTH
TYPEN VERHARDING / ROAD SURFACE CLASSIFICATION
VERBINDINGEN / CONNECTIONS
VERHARDINGSDELEN / ROAD SURFACE PARTS
WEGEN / ROADS

Modelling the ontology of IVON

The source for the IVON context ontology is the SQL table schema of the IVON application witch was explained and mapped to concepts in the natural language at Rijkswaterstaat. These concepts in the natural language of Rijkswaterstaat formed the base for the forming of the common ontologies. Concepts and properties with international consent are placed in the COMMON_INT ontology. Concepts and properties with a typical Dutch character are placed in the COMMON_NL ontology. Finally, concepts and properties specific to Rijkswaterstaat are placed in the COMMON_RWS ontology.

For the concepts in the IVON context ontology an effort is made to be as explicit as possible.

As concepts are derived from SQL tables the concepts have the same names and letter casing as the original table names.

Also all concepts derived from SQL tables are regarded to be mutually disjoint.

All fields in the table with values not linking to other tables are mapped as owl:DatatypeProperty with no defined domain and a range of xsd:string, xsd:float, etc. if the range is defined in the source.

Using this procedure, the modeling of the IVON context ontology is a straight forward process. And because the use of the context ontology is primarily to relay datasets to the IVON application, no IVON intelligence or constraints are modeled. That is left to the specialized IVON application itself.

COINS 2.0

COINS 2.0 is the new standard for exchanging information on projects in the Dutch civil industry. COINS (Constructive Objects and the Integration of Processes and Systems) supports the exchange of digital information between different IT platforms and environments of the parties involved in construction projects. COINS include the exchange of information in the context of Systems Engineering. The standard ensures that different types of information can be stored in one database. Information such as features, and objects of demands trees, GIS data, 2D drawings, 3D models, IFC models, and object type library.

COINS complements standards that are released by building mart such as IFC, IFD Library and IDM. The core is formed by a neutral, software - independent data model, from which data can be transmitted in a neutral format and 'translated' into the software of different project partners. This has the standard large impact on BIM processes.

More on COINS is to be found in Appendix F of the TS.

RWS OTLTransport network conceptual model

The RWS OTL is the Dutch Road Authority’s Object Type Library on witch all exchanged instances are based. The OTL is an extension on the COINS ontology. The OTL is modelled in a particular way. All propertiesare modelled as objects (classes). This is to ensure metadata can be modelled on the properties them selves. The translation from this principal to OWL has led to al normally modelled properties Object Properties or Data Type Properties (OWL terms), are now Classes!

OTL properties are indirectly defined. The linking of properties from the OWL CLASS to OWL Object Properties or Data Type Properties is not straight forward and not to be described in OWL terms. For the translation from COINS to the COMMON ontology of objects and properties a challenge is defined.

Developing the ontologies - principles and rationale

The current version of the ontology is based on the CMO guideline. The COMMON_INT ontology is extended with the COMMON-NL and the COMMON-RWS ontology. It is the aim to define all concepts in the COMMON_INT ontology. Only the concepts that are used differently are defined in the COMMON_NL. The concepts that are specific to RWS are defined in COMMON_RWS.

Common-NLontology – Common Dutch concepts

The Common-NLontology was developed within V-Con based on existing ontologies (like CB-NL and the Rijkswaterstaat OTL) and inspired by standards like ISO 15926 and ISO 12006. 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-NLdid not exist to begin with, it is developed using a simultaneous top-down and bottom-up approach:

-Top-down since it shall comply with the top model which was agreed within V-Con

-Bottom-up since the concepts were derived from context models from systems like KernGIS and IVON2.

Developing the linking rule sets - principles and rationale

At the time of writing this version of the document, we have just begun with explicitly linking concepts. Also, all links have been defined in the context ontology linking towards the common ontology (Common-RWS).

In the next version of the ontologies, we will create linking rule sets according to the following principle:

Figure 8 - Linking rule sets

The linking rule sets will in practice be 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 are defined in OWL. However, OWL does not have the capability to do complex conversions. Where complex conversions are to be made simple pseudo code / English is used to express what is to be done. This is work in progress and will be updated.

The linking rule sets will contain standard OWL assertions together with additional information when OWL is not enough. OWL assertions will primarily be based on:

-EquivalentClass

-EquivalentProperty

-subClassOf

-subPropertyOf

-disjointWith

-propertyDisjointWith

-Restriction

Situations that cannot be defined this way will need additional ways of expression which still have to be defined.

As earlier explained, the workflow will start in the context ontologies. When comparing different context ontologies, common concepts and links 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.

Tools used

We are using TopBraid Composer to develop and 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)

COINS2-OTL
COINS-CORE.ttl
COINS-RWS-OTL.ttl
RWS-OTL.ttl
COMMON
CMO.ttl
COMMON_INT.ttl
COMMON_NL.ttl
COMMON_RWS.ttl
RWS-OTL—COMMON_RWS.ttl
IVON2
IVON.ttl
IVON--COMMON_RWS.ttl
KernGIS
KERNGIS.ttl
KERNGIS--COMMON_RWS.ttl
NL Dataset
ALIGNMENT.ttl
REPAVEMENT.ttl

Different users may import the project to different TopBraid (eclipse) workspaces, enabling parallel work with something that resembles optimistic concurrency on file level.

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.

Resulting structure

The resulting ontologies may be downloaded from

The exact structure, regarding ontologies and versions is still to be determined.

Recommendations for future work

This chapter will be added to as work progresses. At the moment the following upcoming activities are known:

-Verify the ontologies and principles within V-Con (with regards to the modelling guide and linking guide) and also within Rijkswaterstaat and Svensk Byggtjänst

-If necessary, 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

Dutch ontologies for V-Con_v11.docxVersion 112016-03-02