pdeng final reportspecification of the range of allowable cardinalities that a set may assume [iso...

PDEng – Final report

Modelling utilities by developing a domain ontology

PDEng Candidate Date Version

Ramon ter Huurne 11-01-2019 2.0

PDEng – Final Report I

Colophon

PDEng Candidate

Name

Email

Ir. R.B.A. (Ramon) Huurne

[email protected]

Organization

Name

Faculty

Department

Contact details

University of Twente

Engineering Technology (ET)

Construction Management & Engineering

P.O. Box 217

7500 AE Enschede

Client

Name

Contact details

Campus and Facility Management University of Twente

Dienstweg 5

7522 ND Enschede

Graduation Committee

Dr. drs. J.T. (Hans) Voordijk

Prof. dr. ir. A.G. (André) Dorée

Dr. ir. L.L. (Léon) olde Scholtenhuis

Ing. R. (Ray) Klumpert

H.J.M. (André) de Brouwer

Dr. C.P.L. (Carl) Schultz

C. (Caroline) Groot




Campus & Facility Management

Campus & Facility Management

Aarhus University

Kadaster

PDEng Programme Director

Thesis Supervisor

Daily Supervisor

Company Supervisor

Company Supervisor

External Examiner

External Examiner

PDEng – Final Report II

Document characteristics

Title

ID

Author

Date

Subject

Publisher

Type

Format

Language

Version

PDEng – Final report

PDEng_Final_Report.pdf

Ramon ter Huurne

Date of last adjustment – 11-01-2019



Text

Portable Document Format (PDF)

English

2.0

Changelog

Version Date Changes

made by

Sections

changed

Change(s) made

2.0 11-01-2019 Ramon ter

Huurne

All

Chapter 6

Chapter 7

Appendix VI

Textual changes throughout the whole report

Added section about the gradual development of the

ontology

Added proof of concept

Added possible BSC / MSc research subjects

1.0 05-12-2018 Ramon ter

Huurne

All First complete version of the report

List of figures

Figure 1 – Engineering cycle by Wieringa (2014) applied to the project context and its objectives 9

Figure 2 – Stakeholder mapping following Alexander’s (2005) onion model 16

Figure 3 – Distribution of attribute types within elicited realities 19

Figure 4 – The place of a domain ontology within the industry (left as-is, right with a domain ontology included) 25

Figure 5 – UML notation (ISO 19103:2015 Geographic Information – Conceptual Schema Language) 33

Figure 6 – Example of a UML class model (from ‘Operations and Maintenance – Data specification’) 35

Figure 7 – Network components UML class model (from ‘Operations and Maintenance – Data Specification’) 38

Figure 8 – Utility data modelled according to the domain ontology’s format in QGIS 46

PDEng – Final Report III

List of tables

Table 1 – Project characteristics 1

Table 2 – Stakeholders within the project 15

Table 3 – Snap of empirical analysed utility data from the telecom domain 18

Table 4 – Snap of empirical analysed utility data from the gas domain 18

Table 5 – Comparison between and overview of utility digital modelling standards 22

Table 6 – Goals, needs and requirements following the INCOSE method 31

Table 7 – UML stereotypes applied in the domain ontology 34

Table 8 – UML values types applied in the ontology 34

Table 9 – Reporting style applied within Feature Catalogue for feature types and data types 39

Table 10 – Reporting style applied within Feature Catalogue for codelist and enumerations 39

Table 11 – Changelog of ontology development process 42

List of publications

All publications can be found in Appendix VII of this report. Publications included are the following:

ter Huurne, R.B.A. (2018). Digitization for integration: fragmented realities in the utility sector. 92-100.

Paper presented at ARCOM 2018, Belfast, United Kingdom.

ter Huurne, R.B.A. (2018). Introductie van een uniform objectmodel voor het beheer en onderhoud van

ondergrondse infrastructuur. 1-9. Paper presented at CRWO Infradagen 2018, Arnhem, Netherlands.

PDEng – Final Report IV

Foreword and acknowledgements

In front of you lies the report of my PDEng project. A project I have been working on for the past two

years. A project that gave me lots of new insights and knowledge, but also brought me new friendships and

good memories. A project that not could have been accomplished without the help of many people.

Therefore, I want to take the opportunity here in the report to thank all of those.

First of all, I have to thank all of my supervisors for their time, enthusiasm, and thoughtful advices and

recommendations. In specific, I want to thank prof. dr. ir. André Dorée and dr. ir. Léon olde Scholtenhuis

as my supervisors from the University of Twente and ing. Ray Klumpert and André de Brouwer as my

supervisors from the Campus and Facility Management of the University of Twente.

Second, I want to thank the experts being part of my expert panel for their feedback and useful advice,

allowing me to shape the ontology in the way it is presented in this report. In specific, I want to thank the

representative(s) from CityGML UtilityNetwork ADE, Siers Infraconsultancy, Geonovum, and the

Kadaster.

Third, I am very grateful to all my colleagues and friends from the department of Construction

Management and Engineering I have been working with for the past two years. Even though the workload

was quite high several times, it never felt as a burden for me to work, due to the amazing atmosphere at

our office. Even more, I learned a lot from all of your projects and work, and I want to thank you for the

support and encouragement you gave me.

Fourth, but definitely not last, I wish to extent a huge thank to my girlfriend Evelien, my family, and my

friends who all supported me throughout these two years. I cannot thank you all enough for your

encouragement and understanding.

PDEng – Final Report V

Terms and definitions

[1.] Aggregation

Special form of association (3) that specifies a whole-part relationship (24) between the aggregate (whole)

and a component (7) part [UML 1]

[2.] Application

Manipulation and processing of data in support of user requirements [ISO 19101-1:2014]

[3.] Association

Semantic relationship (24) that can occur between classes [UML 2]

[4.] Association role

Explanation of how a class participates in the association.

[5.] Attribute

Feature (14) within a classifier that describes a range of values that instances of the classifier may hold

[UML 1]

[6.] Class

Description of a set of objects (21) that share the same attributes (5), operations, methods, relationships

(24), and semantics [UML 1]

[7.] Component

Representation of a modular part of a system that encapsulates its contents and whose manifestation is

replaceable within its environment [UML 2]

[8.] Composition

Aggregation (1) where the composite object (21) (whole) has responsibility for the existence and the storage

of the composed objects (parts) [UML 2]

[9.] Conceptual model

Model that defines concepts of a universe of discourse [ISO 19101-1:2014]

[10.] Conceptual schema

Formal description of a conceptual model [ISO 19101-1:2014]

[11.] Data specification

Detailed description of a data set or data set series together with additional information that will enable it

to be created, supplied to and used by another party [ISO 19131:2007]

[12.] Data type

Specification of a value domain with operations allowed on values in this domain [ISO 19103:2015]

[13.] Depth

Distance of a point from a chosen reference surface measured downward along a line perpendicular to

that surface [ISO 19111:2007]

PDEng – Final Report VI

[14.] Feature

Abstraction of a real world phenomenon [ISO 19101-1:2014] In UML also defined as the property of a

classifier [UML 2]

[15.] Feature catalogue

Catalogue containing definitions and descriptions of the feature (14) types, feature attributes, and feature

relationships occurring in one or more spatial data sets, together with any feature operations that may be

applied [ISO 19101-1:2014]

[16.] Feature type

Class of features (14) having common characteristics [ISO 19156:2011]

[17.] Generalization (inheritance)

Taxonomic relationship (24) between a more general element and a more specific element of the same

element type [UML 2]

[18.] Infrastructure asset management

Set of activities performed and strategies implemented with the goal to preserve and extend the service life

of the utilities

[19.] Interoperability

Capability to communicate, execute programs, or transfer data among various functional units in a manner

that requires the user to have little or no knowledge of the unique characteristics of those units [ISO/IEC

2382:2009, 212317]

[20.] Multiplicity

Specification of the range of allowable cardinalities that a set may assume [ISO 19103:2015]

[21.] Object

Entity with a well-defined boundary and identity that encapsulates state and behavior [UML 1]

[22.] Ontology

Formal and explicit specifications of shared conceptualizations. In the report also defined as a digital

modelling standard

[23.] Operations and maintenance

See ‘Infrastructure asset management’ (18)

[24.] Relationship

Semantic connection among model elements [UML 1]

[25.] Stereotype

Extension of an existing metaclass that enables the use of platform or domain specific terminology or

notation in place of, or in addition to, the ones used for the extended metaclass [UML 2]

[26.] Utility infrastructure

Infrastructure with the purpose of transporting commodities.

PDEng – Final Report VII

Abbreviations

AEC

Architecture, Engineering and Construction

ADE

Application Domain Extension

BIM

Building Information Modeling

CFM

Campus and Facility Management

GIS

Geographic Information System

GML

Geography Markup Language

IFC

Industry Foundation Classes

IMKL

Informatiemodel Kabels en Leidingen (ENG – Information model Cables and Pipes)

INSPIRE

Infrastructure for Spatial Information in Europe

ISO

International Organization for Standardization

OGC

Open Geospatial Consortium

UML

Unified Modelling Language

XML

Extensible Markup Language

PDEng – Final Report VIII

Graphical summary

PDEng – Final Report IX

Executive summary

The utility sector is shifting more towards a life cycle oriented management approach. This means utility

owners increasingly want to have a comprehensive set of digital information about their utilities. This need

is also recognized at the Campus and Facility Management (CFM) of the University of Twente. The CFM

– client within the PDEng project – is responsible for the installation, operations and maintenance of their

utilities. Consequently, the CFM wants to be able to rely on uniform and consistent digital information

about these utilities.

However, the problem, and thereby the starting point of the PDEng project, is that the utility sector

currently lacks a digital modelling standard with the emphasis on lifecycle management, i.e. operations

and maintenance. The lack of a standard leads to confusion and misunderstandings while exchanging data

during the preparation and execution of utility works. Therefore, it is necessary to develop a sector-wide

digital modelling standard that covers the main concepts and relations for utilities’ operations and

maintenance. Digital modelling standards are also called ‘ontologies’ in information science. An ontology

can be seen as a formal and explicit model of shared conceptualizations about reality. Once adopted and

shared amongst end-users, they represent knowledge in a unified, simplified, and consistent way. If

ontologies are focusing on the conceptualization of knowledge in a specific domain – such as operations

and maintenance of utilities – they are called domain ontologies.

Main goal during the two-year course of the PDEng project has been the development of a domain

ontology that does include those concepts and relations required within operations and maintenance

related activities. The domain ontology was designed while keeping the PDEng assessment criteria in

mind. These criteria elaborate on the design process (construction, realisiblity, functionality, impact and

presentation) and design process (organization and planning, problem analysis and solution,

communication and social skills).

To structure the ontology development process, I applied the engineering cycle of Wieringa (2014),

including the following four phases: (1) problem investigation, (2) treatment design, (3) treatment

validation, and (4) treatment implementation. Since ontology development is necessarily an iterative

process, I used the concept of concurrent design from systems engineering. This meant treatment design

and validation were iterated multiple times, sometimes even leading to a situation in which a next iteration

was already started while the previous iteration one was still running. Ultimately, this iterative and

concurrent fashion resulted in the creation of eight versions of the domain ontology, becoming increasingly

sophisticated every iteration, up till the current version.

The problem within the PDEng project was investigated through the means of a stakeholder analysis,

qualitative case study, a literature review, a document study and input of an expert panel. I found evidence

that for utilities’ operations and maintenance, the main concepts and relations are not covered within a

digital modelling standard. Consequently, organizations create and use their own organizational standards

to model their utility information. Ultimately, this leads to the current widespread of utility modelling

practices in the utility sector, and consequently, confusion and miscommunication when exchanging utility

information. The problem, thereby, justifies the development of the domain ontology.

In order to design the ontology, I first established an ontology design method through an in-depth study

of literature and existing ontology design methods. This method followed the steps of defining competency

PDEng – Final Report X

questions, defining the ontology’s requirements, choosing an ontology development tool and ontology

language, and building the ontology. I executed these steps within the treatment design phase of the

engineering cycle. The main principle I followed during the ontology development process was active end-

user engagement. End-users, in specific the CFM, actively participated in the development of the ontology.

An overview of all meetings conducted during the two-year course of the PDEng can be found in Appendix

II. Through the active involvement of end-users, it was ensured that the real information need for

operations and maintenance on utilities was captured within the ontology.

To validate that the developed ontology did cover the concepts and relations of the domain of operations

and maintenance, I applied four validation techniques: (1) assessment against a source of domain data, (2)

check against class modelling rules, (3) assessment against expert panel input and (4) assessment against

competency questions. As a result of the validation, the final version of the ontology was proven capable

of delivering the utility information as required by the end-user, in specific, the CFM. In addition,

validation proved the ontology to be ready for implementation in (spatial) asset management and GIS

(Geographic Information System) software.

Implementation of the ontology was limited to a proof of concept. I was able to model utility data within

a GIS environment following the ontology’s format. However, this proof of concept only covered a small

piece of the ontology. As a consequence, the ontology has not been evaluated. Therefore, full

implementation of the entire ontology in (spatial) asset management and GIS software is still required. To

ease this process, a brief guideline was written on how to implement the ontology. Moreover, the ontology

and all documentation and data have been made available through an online repository. Via this

repository, potential users have open access to all materials required for implementation and use of the

ontology.

In order to achieve full-scale implementation within the utility sector as a whole, adoption is necessary.

Whereas the purpose of the ontology is to improve the system interoperability of utility data in the sector,

main prerequisite is then that the ontology is also used within the sector. Whereas the PDEng project did

not focus on widespread adoption of the model, is it recommended for future work to make this one of

the main drivers, since once adopted, the domain ontology does provide the following potential:

To the client – the CFM – the domain ontology provides a comprehensive structure alongside

utility data can be stored. The domain ontology is a vast improvement over the existing utility

modelling practice. The domain ontology provides the CFM a more detailed insight in its utilities

and can support visualization, up to the creation of 3D utility models. In addition, the ontology

can facilitate the uptake towards digital maintenance practices.

To the utility sector as a whole, the ontology provides a domain concept overview that is useful to

bridge the various organizational standards within the domain. This may facilitate the transfer

between formats and shape standardized object descriptions improving system interoperability of

utility data.

To software developers the domain ontology provides the support of smarter reasoning within

utility models. This may lead to the digital maintenance practices, and possibly even the creation

of cyber-physical systems.

Altogether, the PDEng project delivers a domain ontology that can be used to model utilities in a uniform

and consistent manner. To this end, the domain ontology does fulfil to the requirements of the CFM and

stakeholders in general, while making the first step towards improved system interoperability utility data.

PDEng – Final Report XI

Product summary

Within the PDEng project, I developed a domain ontology, i.e. a digital modelling standard. The domain

covered by the ontology is the domain of operations and maintenance of utilities. The name given to this

ontology is the ‘Operations and Maintenance conceptual schema’. A conceptual schema is a formal

description of a model that defines a universe of discourse.

The Operations and Maintenance conceptual schema is empirically grounded and provides an overview

of those concepts and relations relevant for operations and maintenance of utilities. Use of the conceptual

schema allows consistent processing and exchange of operations and maintenance related utility data,

thereby improving system interoperability of utility data. The Operations and Maintenance conceptual

schema is developed with support of the developers of the internationally recognized CityGML

UtilityNetwork ADE (Application Domain Extension). As a result, the schema builds upon the CityGML

UtilityNetwork ADE conceptual schema (CityGML, 2016) and adds those concepts and relations relevant

for the domain of operations and maintenance.

The Operations and Maintenance conceptual schema is developed within the system Enterprise Architect.

The schema consist of classes formatted in the Unified Modelling Language (UML). UML is an often

applied language in class modelling due to its graphical notation, and moreover, also applied by the

developers of CityGML UtilityNetwork ADE. In total the whole conceptual schema consist of eight UML

class models. These class models describe the following domains of interest:

[1.] Core and geometry

[2.] Functional characteristics

[3.] Network properties

[4.] Network components

[5.] Component properties

[6.] Operations and maintenance properties

[7.] Performance properties

[8.] Hollow space

The targeted use of the conceptual schema lies in asset management related applications, covering the

domain of operations and maintenance of utilities. The Operations and Maintenance conceptual schema

is applicable to the following utility disciplines: (1) electricity, (2) oil, (3) gas, (4) chemicals, (5) sewage, (6)

water, (7) thermal and (8) telecommunication. The use of the schema has no geographic boundary, but is

based on utility networks of developed countries.

The documentation of the Operations and Maintenance conceptual schema contains three documents:

(1) a data specification, (2) a feature catalogue, and (3) an overview of the class models in UML. The data

specification is the main document, which includes all eight class models together with a detailed

description for each of these and the conceptual schema as a whole. The feature catalogue contains the

complete vocabulary as applied within the ontology, and provides a definition and explanation for all used

terms and names. The overview of UML class models contains solely the class models of the domain

ontology in UML.

PDEng – Final Report XII

In summary, the documentation includes the following documents:

[1.] Operations and Maintenance – Data Specification version 4.1

o OM_Data_Specification.pdf

[2.] Operations and Maintenance – Feature Catalogue 2.1

o OM_Feature_Catalogue.pdf

[3.] Operations and Maintenance – Overview of class models in UML version 4.1

o OM_UML_Overview_pdf

To implement the conceptual schema in (spatial) asset management and GIS (Geographic Information

System) software, it has first been converted to an Extensive Markup Language (XML) schema file. XML

is a widely adopted standard language for exchanging information. The XML schema file allows mapping

of the utility data according to the Operations and Maintenance conceptual schema. However, before the

XML schema can be utilized, it has to be programmed within the software FME, which still has to be

done. Besides programming in FME, all preparation in order to use the domain ontology in (spatial) asset

management and GIS software is finished. An online GitHub repository is created to make all the

documentation and data on the Operations and Maintenance conceptual schema available:

https://github.com/RamonTerHuurne/UtilityNetwork-OperationsAndMaintenance

A list of the main features of Operations and Maintenance conceptual schema are:

Geospatial data model for operations and maintenance on utilities

Based on the CityGML UtilityNetwork ADE conceptual schema

Representation of utilities in both 2D and 3D

Representation of a subnetwork and superordinate network

Representation of supply areas

Representation of detailed utility objects, including:

o Spatial attributes

o Material attributes

o Dimensional attributes

o Shape attributes

o Cost attributes

o Performance attributes

o Impact attributes

o Use attributes

o Surrounding soil attributes

o Status attributes

Integration of the utility domain with CityGML models:

o Buildings (CityGML Building module)

o City furniture (CityGML CityFurniture module)

o Land use (CityGML LandUse module)

o Vegetation (CityGML Vegetation module)

o Water objects (CityGML WaterBody module)

o Transportation (CityGML Transportation module)

o Tunnels (CityGML Tunnel module)

o Bridges (CityGML Bridge module


PDEng – Final Report XIII

Table of contents

1 Introduction 1

1.1 Project description 1

1.2 ReDUCE 2

1.3 PDEng criteria 2

1.4 Role of document 3

1.5 Reading guide 3

2 Project goal, scope, questions and objectives 5

2.1 Project goal and scope 5

2.2 Project questions 6

2.3 Project objectives 7

3 Project design and methodology 8

3.1 Problem investigation 10

3.2 Treatment design 11

3.3 Treatment validation 13

3.4 Treatment implementation 14

4 Problem investigation and analysis 15

4.1 Stakeholder analysis 15

4.2 Phenomena 17

4.3 Problem statement and opportunities 24

5 Treatment design 27

5.1 Methodological steps 27

5.2 Requirements engineering 28

5.3 Ontology design 30

6 Treatment validation 40

6.1 Validation techniques 40

6.2 Development of ontology 42

7 Treatment implementation 44

7.1 Proof of concept 44

7.2 Online repository 46

8 Discussion 47

9 Conclusions and recommendations 49

9.1 Conclusions 49

PDEng – Final Report XIV

9.2 Recommendations 52

10 Bibliography 53

Appendix I – Overview of educational activities 56

Appendix II – Overview of meetings 58

Appendix III – Collected empirical data 66

Appendix IV – Overview of existing standards 71

Appendix V – Expert panel sessions handouts (Dutch) 73

Appendix VI – Possible BSc / MSc research subjects 82

Appendix VII – Publications 83

Section 1 – Project initiation 1

1 Introduction

This chapter introduces the PDEng project, starting with a project description and explanation of the

programme in which the project was executed. Thereafter, a list of PDEng criteria is presented, followed

by an explanation about the role of this document. The chapter concludes with a reading guide for this

PDEng report as a whole.

1.1 Project description

A PDEng (Professional Doctorate in Engineering) programme is a two years post-Master design

programme focussing on the direct needs of the industry. Part of the PDEng programme is a tailor-made

design project in close collaboration with an industry partner. The ‘industry’ partner within the project is

the Campus and Facility Management (CFM) of the University of Twente. An overview of the main project

characteristics are included in Table 1.

Table 1 – Project characteristics

Project title

Project type

Project client

Project period


Professional Doctorate in Engineering (PDEng)

Campus and Facility Management University of Twente

October 2016 – January 2019

The CFM has a unique role as the manager of the campus of the University of Twente. She is one of the

few park and terrain managers in the Netherlands with full ownership rights over her utilities.

Consequently, the CFM is responsible for the installation, operations and maintenance of – amongst

others – cables and pipes. Being part of her maintenance duty, the CFM collects and registers all sorts of

information about her utilities. This information covers, for example, location, material and status related

properties. In addition to being an asset manager, the CFM is also client of works on the campus. During

these works she wants to be able to rely on uniform and consistent information about the as-built situation

of their utilities. However, how registration of the as-built information occurs often depends on personal

preferences of utility owners and operators, with as a result, inconsistency in how the information is stored.

In the process of modelling as-built information, construction assets are often digitized by defining their

concepts and relations (El-Diraby & Osman, 2011). Digitized asset information is, consequently, stored in

digital databases and information models. The use of such digital databases and information models in

the Architecture, Engineering and Construction (AEC) industry to manage asset information is a much-

discussed topic in literature (e.g. Bradley et al., 2016; Lu et al., 2015; Pauwels et al., 2016). For example,

within the design of buildings Building Information Modeling (BIM) software in combination with digital

modelling standards such as the Industry Foundation Classes (IFC) is used.

Digital modelling standards are also called an ‘ontology’ in information science. Ontologies describe the

world as seen by a group of people at a certain time according to a school of thought that is based on a set


of fundamental propositions or world views (El-Diraby & Osman, 2011). An ontology can be defined as

formal and explicit specifications of shared conceptualizations (Studer, Benjamins, & Fensel, 1998).

Conceptualization refers to the universe of discourse (El-Diraby & Osman, 2011). Shared refers to the

multiple views an ontology should be able to represent. Formal and explicit refers to the fact that the

concepts within the ontology should be described in a clear computer-interpretable format (Olde

Scholtenhuis & Hartmann, 2015).

Ontologies promise a shared and common understanding of a particular domain that can be

communicated across people and computers. In other words, ontologies model ‘realities’. They form the

knowledge base of information systems and allow sharing and reuse of knowledge. Once adopted and

shared amongst end-users, they represent domain knowledge in a unified, simplified, and consistent way.

An ontology offers the CFM – and utility owners, utility operators and contractors in general – a structure

alongside they can store the utility asset information to utilize it for installation, operations and

maintenance purposes. Moreover, in the context of asset management, an ontology can enable digital

maintenance practices, and even the creation of cyber-physical systems. However, an ontology covering

the domain of operations and maintenance of utilities has not yet been developed. Therefore, to support

operations and maintenance of utilities, there is need for an ontology covering those operations and

maintenance related concepts and relations.

1.2 ReDUCE

The PDEng project is part of the ReDUCE (Reduction of Damage to Utilities & Careful Excavation)

programme. ReDUCE is a collaboration between Dutch utility operator KPN (previously Reggefiber) and

the University of Twente. The aim of ReDUCE is to improve design, construction, installation, and

maintenance of (buried) utilities. ReDUCE wants to promote the awareness within the excavation supply-

chain regarding reduction of damages and careful excavation through the development of new methods

and techniques for excavation (ZoARG, 2018).

An important step towards reduction of damages to utilities and careful excavation is to have a uniform

and consistent view about the information of utilities. However, as previously explained, a standard for the

classification of utilities’ concepts and relations in the domain of operations and maintenance is missing.

Consequently, owners and operators of utilities classify and name similar concepts in different ways. This

leads to confusion and misunderstandings at the preparation and execution of utility works. Therefore,

the development of an ontology describing how concepts are classified and which data elements are used

to describe them is necessary. With a good and useful ontology the installation, operations and

maintenance of works in the future can be arranged more precise, making the relevance of the project to

ReDUCE explicit.

1.3 PDEng criteria

The PDEng project is assessed on criteria for its design process and design product. To fulfil to these

criteria, I decided to make them explicit for myself right from the start of the project. These criteria follow

from the ‘Study Guide PDEng programme in Civil Engineering University of Twente’ and are presented

below. I refer back to the PDEng criteria in the conclusion of this report, chapter 9, to assess how I did

fulfil to these.


Design product:

Construction – Structuring, inventivity, convincingness.

Realisability – Technical and economic realisability.

Functionality – Satisfaction, ease of use, reusability.

Impact – Societal impact, risk.

Presentation – Completeness, correctness.

Design process:

Organization and planning – Project planning, plan realization, structure and consistency,

conducting meetings.

Problem analysis and solution – Analysis, understanding of impact, creativity, genericity.

Communication and social skills – Reporting, knowledge management, stakeholder motivation,

social skills, independency, reflection and critical attitude.

Structure and attitude – Structure and consistency, reflection and critical attitude, independency.

In addition to the design process and product, educational activities were conducted to fulfil the required

ECTS within a PDEng project. An overview of the educational activities is provided in Appendix I.

1.4 Role of document

Aim of this document is to explain the complete ontology development process I conducted within the

PDEng project. The rationale behind the ontology development process, as well as all the choices I made

within this process are explained. This document, however, does not include the actual domain ontology

itself. It was chosen to create a separate document – a data specification – in which the domain ontology

itself is provided. This data specification contains a detailed description of the domain ontology, and does

not elaborate on the design process. In addition to the data specification, also a feature catalogue is

developed. This document contains the complete vocabulary as applied within the ontology, and provides

a definition and explanation for all used terms and names. Having these separate documents for the

domain ontology eases external publication of the product. The third document provides a sole overview

of the ontology’s class models, for those not requiring all additional explanation and information. Besides

this report, the complete documentation of my PDEng project therefore includes the following three

documents:

[1.] Operations and Maintenance – Data Specification version 4.1

OM_Data_Specification.pdf

[2.] Operations and Maintenance – Feature Catalogue version 2.1

OM_Feature_Catalogue_pdf

[3.] Operations and Maintenance – Overview of class models in UML version 4.1

OM_UML_Overview_pdf

1.5 Reading guide

This document is structured in nine chapters – of which this being the first – divided over three sections.

The first section involves the project initiation. This section exists of three chapters, of which this being

the first, and elaborates on the kick-off of the PDEng project. This chapter involves the introduction on


the project. Chapter 2 clarifies the project goal, questions, scope and objectives. The first section ends with

the project methodology in chapter 3.

The second section involves the engineering cycle. The engineering cycle is a rational problem-solving

process proposed by Wieringa (2014). The engineering cycle starts in chapter 4 with the problem

investigation assessing which phenomenon should be improved and why. Chapter 5 includes the treatment

design, describing how the product at hand – the domain ontology – is designed and thereby could treat

the problem. After the design, the engineering cycle continues with the treatment validation in chapter 6.

Validation assesses whether the designed ontology actually treats the problem as it should. Last part of the

engineering cycle is the treatment implementation, discussed in chapter 7.

The third section involves concluding words. Chapter 8 elaborates on various points of discussion.

Chapter 9 concludes the report with conclusions and recommendations.


2 Project goal, scope, questions and objectives

This chapter elaborates on the project goal, scope, questions and objectives, as is presented in the following

three sections.

2.1 Project goal and scope

This section elaborates on the project goal and scope of the PDEng project.

2.1.1 Goal

Having uniform and consistent information about utilities is essential to (1) effectively utilize it for

installation, operations and maintenance purposes, (2) carefully excavate, and (3) thereby reducing

damages to utilities. As explained in the project description the lack of a digital modelling standard of

utilities leads to confusion and misunderstandings at the preparation and execution of works. Therefore,

the main goal within the PDEng project is to develop an ontology that offers a structure alongside utility

information can be stored in a uniform and consistent manner. The goal is formulated as follows:

Development of a domain ontology that includes the relevant concepts and relations for the operations

and maintenance of utilities.

2.1.2 Scope

In the context of the PDEng project, utilities are defined as buried utility infrastructure in shallow

subsurface, together with the utility infrastructure at the surface itself. With shallow, a depth of maximum

two meters is meant. Goal of the project is to develop an ontology relevant for the domain of operations

and maintenance. Operations and maintenance refers here to the set of activities performed and strategies

implemented with the goal to preserve and extend the service life of the utilities. The meaning of

operations and maintenance in the context of this report is, thereby, comparable with what is known as

distinct phases in infrastructure asset management.

The utility sector is a multi-disciplinary domain in which various utility disciplines are present. To ensure

proper coverage of the complete (physical) domain of utilities, the developed domain ontology includes

the following utility disciplines:

[1.] Electricity

[2.] Oil

[3.] Gas

[4.] Chemicals

[5.] Sewage

[6.] Water

[7.] Thermal

[8.] Telecommunication

The coverage of these utility disciplines is based on utility networks from developed countries, and

moreover, draws upon the European INSPIRE (Infrastructure for Spatial Information in Europe)

directive (European Commission, s.d.). INSPIRE aims to provide an integrated infrastructure in which

interoperability and exchangeability of the spatial data of the Member States of the European Union is

guaranteed. The decision to keep the utility disciplines relatively abstract was made to allow modelling of


every kind of utility network. Further detailing of the utility disciplines, for example towards a high-voltage

electricity network, is thereby possible through the addition of attributes to each discipline.

The domain ontology is developed in close collaboration with the client, the CFM. Consequently, the

domain ontology is specifically developed for a Dutch utility owner. However, the ontology was built in

such a way that it allows global coverage of utility networks, as long as the utilities are within the subsurface

or at the surface. The outreach of the ontology is, therefore, likely to be greater than just the Netherlands.

To create support of the ontology, connection was sought with the developers of the internationally

recognized CityGML UtilityNetwork ADE. CityGML UtilityNetwork ADE is an application domain

extension (ADE) on the CityGML city model standard. The UtilityNetwork ADE adds heterogeneous

modelling of utility networks to the 3D city models of CityGML (CityGML, 2016). Both CityGML and

CityGML UtilityNetwork ADE are part of the Open Geospatial Consortium (OGC). The developed

domain ontology in the PDEng report builds upon the existing conceptual schema of the UtilityNetwork

ADE. The domain ontology adds the concepts and relations relevant to the domain of operations and

maintenance and, therefore, is called the ‘Operations and Maintenance conceptual schema’. By building

on an already known and OGC approved standard, the potential for greater support is there.

Implementation of the ontology is limited to a proof of concept. The proof of concept is performed to

demonstrate how the ontology can be implemented in (spatial) asset management and GIS (Geographic

Information System) software.

2.2 Project questions

In order to achieve the project goal, within the boundaries of the project scope, various questions had to

be asked. In total, four questions were formulated:

[1.] What are the methodological steps required to develop a domain ontology?

A domain ontology is built on multiple principles. Key is to develop an ontology that ensures system

interoperability, the linkage across domains, and logical inferences and proofs (Pauwels, Zhang, & Lee,

2017).

[2.] Which (international) digital modelling standards for utilities exist and how do these relate to the

domain of operations and maintenance?

The utility sector knows digital modelling standards as the Dutch IMKL (Informatiemodel Kabels en

Leidingen) and European INSPIRE. Interesting is to analyze how operations and maintenance – i.e.

infrastructure asset management – is covered within these existing standards. It is analysed which concepts

and relations are covered within their conceptual schemas, possibly providing leads for the development

of the domain ontology.

[3.] How do end-users within the utility sector classify and register their utility data?

Classification and registration of utility data by end-users – such as utility owners, utility operators and

contractors – can greatly differ comparing theory and practice. Whereas the existing digital modelling

standards may not be able to suffice to the end-users’ information need, end-users use their own way of

classifying their concepts and relations. This results in a widespread of utility modelling practices.


[4.] Which concepts and relations relevant to the domain of operations and maintenance must the

domain ontology cover?

Coverage of the right concepts and relations by the ontology is crucial for it being widely accepted and

adopted. End-users in the utility sector all have specific information uses and needs concerning the

operations and management of their utilities. These uses and needs are direct input for the concepts and

relations of the domain ontology. Compared to the third question, which analyzes what in practice is

registered, this fourth question analyzes what the information uses and needs of the utility sector are and

how these can be translated to the concepts and relations to be covered by the domain ontology.

2.3 Project objectives

To answer the project questions and progress towards the project goal within the boundary of its scope,

five project objectives have been defined.

[1.] Define the methodological steps and structural requirements for the design of the domain

ontology.

In order to develop a domain ontology that ensures system interoperability, linkage across domains, and

logical inferences and proofs (Pauwels, Zhang, & Lee, 2017) the definition of structural requirement to be

met is a necessity. Within this objective it is (1) decided which ontology design method will be used for

the development of the ontology to and (2) defined what the domain ontology’s structural requirements

are. The first project objective, thereby, aligns to the first project question.

[2.] Define the functional requirements for the design of the domain ontology.

Functional requirements define the required functionality by the domain ontology. Functional

requirements are elicited from (1) the end-users, i.e. the end-user and (2) from existing digital modelling

standards. Since current practices show confusion and misunderstandings at the preparation and execution

of works in the utility sector, the ontology must be based on a shared set of conceptualizations. Engagement

of the end-user is necessary to capture these conceptualizations, and therefore crucial to make the ontology

functionally sound. The second project objective aligns with the second, third and fourth project questions.

[3.] Design the domain ontology.

After making the requirements for the domain ontology explicit in the first two objectives, the third

objective involves the design and modelling of the domain ontology. Design of the domain ontology

includes modelling following the methodological steps and structural requirements of the first objective,

while ensuring the functional requirements from the second objective are covered.

[4.] Validate the domain ontology.

The fourth objective is to validate the domain ontology on its structural and functional soundness. Aim of

the objective is to justify that the designed ontology does meet the requirements from the first and second

objective.

[5.] Implement the domain ontology.

Implementation in the context of this PDEng project is restricted to a proof of concept. Although not

directly related to the project questions nor the project goal, implementation, in a sense, acts as a final

evaluation measure.


3 Project design and methodology

An ontology – i.e. digital modelling standard – related to the domain of operations and maintenance for

utilities missing. The ontology to be designed should comprehend those concepts and relations relevant

to the particular domain of operations and maintenance. In order to design the ontology, the engineering

cycle as proposed by Wieringa (2014) was taken as a basis for the overall design process. Within product

engineering - in the context of this project ontology engineering – the engineering cycle is a well-known

approach to follow and was, therefore, considered as most appropriate. The engineering cycle is a rational

problem-solving process consisting of five phases being (1) problem investigation, (2) treatment design, (3)

treatment validation, (4) treatment implementation, and (5) implementation evaluation.

Within the scope of the project the fifth phase is not performed. The domain ontology is only partially

implemented. Evaluation of the implemented domain ontology requires full implementation within

multiple organizations and presumably the sector as a whole. To this end, the remaining four engineering

cycle phases are coupled to the project context and its objectives, resulting in the following structure:

[1.] Problem investigation –which phenomena must be improved and why?

[2.] Treatment design – design of ontology to treat the problem.

Define the methodological steps and structural requirements for the domain ontology.

Define the functional requirements for the domain ontology.

Design the domain ontology.

[3.] Treatment validation – assessment whether the ontology treats the problem.

Validate the domain ontology.

[4.] Treatment implementation – actual treatment of the problem with the ontology.

Implement the domain ontology.

For each of the four phases of the engineering cycle – including the project objectives – the following

sections assess (1) what the goal within the phase is, (2) what methods and strategies are followed to reach

that goal and (3) what the outcome of the phase is. As part of the methods and strategies, it is also explained

how data was collected and analysed.

The engineering cycle does not prescribe a rigid sequence of the phases. However, ontology development

is necessarily an iterative process (Noy & McGuinnes, 2001). Therefore, I made use of systems engineering

and its concept of concurrent design (Blanchard & Fabrycky, 2014). Before implementation, the steps of

treatment design and validation are iterated multiple times, until the project goal is fully met. This also

means that a next iteration may be started when the previous iteration is still running, i.e. concurrent design

of the engineering cycle. This, according to Wieringa (2014), leads to “increasingly sophisticated versions

of the artefact, all aimed at treating the same complex problem”.

Figure 1 shows how the engineering cycle and the principle of concurrent design were applied to the

project context and its objectives.


Design

Validation

Requirements

engineering

[2.] Treatment design

[3.] Treatment validation

Sufficient requirements?

Implementation

[1.] Problem investigation

Meets requirements?

Implementation?

Problem statement

[4.] Treatment implementation

Domain ontologyPerform stake-

holder analysis

Assess

expert input

Asess against source of

domain data

Perform literature

review

Methodological

steps

Validation

techniques

Structural and

functional requirements

Perform document

study

Perform document

study

Perform qualitative

case study

Perform qualitative

case study

Activity

Project objective

Phase in engineering cycle

Outcome

Assess against

competency questions

Check against class

modelling rules

Assess expert input

Perform document

study

Define competency

questions

Perform literature

review

Figure 1 – Engineering cycle by Wieringa (2014) applied to the project context and its objectives

Section 2 – The engineering cycle 10

3.1 Problem investigation

Goal:

Identifying, describing, explaining and analysing the problem to be treated, before design of the treatment

and identification of the requirements.

Methods and strategies:

In order to investigate the problem to be treated, multiple methods and strategies are applied, as is

explained below:

First a stakeholder analysis was conducted, in which the stakeholders and their goals were mapped.

Mapping occurs following the onion model of Alexander (2005). This model focuses on the relations of

the stakeholders to the final product, rather than on power and interest. The stakeholder mapping

provides immediate value in identifying and validating stakeholder roles in the requirements elicitation.

Second the phenomena were investigated. Phenomena of interest are (1) existing utility modelling

practices and (2) standardization efforts. It was analysed what the mechanism behind these phenomena

were to occur. I conducted a qualitative case study to gain insights in existing utility modelling practices

(Yin, 1989). In specific, the utility modelling practices within a Dutch utility engineering consultancy firm

were studied. This company registers and processes the data of twelve major utility owners. The twelve

utility owners cover the disciplines of water, gas, electricity, telecommunication and thermal. It was studied

how standards and data protocols were used by these utility owners. The data collection approaches

followed within the case study include observations of works practices and study of asset management

guidelines. To this end, seven information managers were observed whose daily task was to model utility

networks. During the observations, the information managers showed and explained how utility owners

model their utility networks in digital environments. While keeping notes on this, there were dialogues in

which the information managers explained their asset management work routines. Within the case study

also six asset management guidelines were collected, used by utility owners as a guideline to verify the

utility data modelled within the digital environments. More asset management guidelines were either not

available or made accessible due to privacy reasons. The collected data were analysed in a two-staged

process: (1) qualitative coding to abstract and compare the utility modelling practices, and (2) identification

of similarities and differences between the practices. Within the qualitative coding (Saldaña, 2015), the

typology of infrastructure objects of El-Diraby and Osman (2011) was applied. This typology distinguishes

between component level, subsystem level, and system level objects and captures, for example, spatial,

dimensional and material attributes. To justify the development of the domain ontology, I also identified

similarities and differences between the utility modelling practices, following the typology of Gasevic et al.

(2009). This typology essentially describes three elements of an ontology, being: (1) taxonomy and

hierarchy, (2) vocabulary, terms and names, and (3) semantics, the linguistic meaning of the representation.

The taxonomy and hierarchy refer to the hierarchical categorization of the concepts within the ontology.

The vocabulary refers to the set of terms and names that are used in the subject area captured by the

ontology. Semantics refers to the linguistic meaning of the applied terms and names, often prone to

ambiguity and multi-interpretability.

Assessment of existing standardization efforts concerning utility modelling happened through a document

study. The INSPIRE, IMKL, and CityGML UtilityNetwork ADE standard were studied in depth, whilst

also other standards such as the Utility Survey Standard, PAS 128 and ASCE 38-02 were taken into

account. Insights were retrieved in how existing standards are capable of modelling operations and


maintenance related utility information, providing leads for the development of the domain ontology. The

infrastructure typology from El-Diraby and Osman (2011) was applied to qualitatively analyze covered

infrastructure objects and attributes.

Third the phenomena were reflected upon the stakeholder goals assessing whether the phenomena do

contribute or extract from the goals. This led to the problem statement.

Outcome:

Problem statement based on phenomena investigation and assessment of stakeholder goals.

3.2 Treatment design

Objective 1: Define the methodological steps and the structural requirements for design of the domain

ontology

Goal:

Identifying and describing the methodological steps and structural requirements for the design of the

domain ontology.


In order to elicit the methodological steps and structural requirements for the domain ontology, both a

literature review and document study were conducted, as is explained below:

Through a literature review, both the methodological steps and structural requirements were identified.

Various search engines were used to gain access to appropriate literature: (1) FindUT (search engine of

the University of Twente, (2) Scopus, (3) Google Scholar, and (4) ScienceDirect. I searched for the

following keywords, either individually or combined: ontology, domain ontology, classification, taxonomy,

class-modelling, representation, methodology, requirements and criteria. To this end, I analysed the

following literature on ontology design methods and principles:

Corcho et al. (2002) – Methodologies, tools and languages for building ontologies.

Fernández-López et al. (1999) – Building a chemical ontology using Methondology and the

Ontology Design Environment.

Gasevic et al. (2009) – Model Driven Engineering and Ontology Development.

Jakus et al. (2013) – Concepts, Ontologies, and Knowledge Representation.

Noy and McGuinness (2001) – Ontology Development 101: A Guide to Creating Your First

Ontology.

Pinto et al. (2009) – Ontology Engineering and Evolution in a Distributed World using

DILIGENT.

Sure and Studer (2002) – On-To-Knowledge – Final Version.

Sure et al. (2009) – Ontology Engineering Methodology.

Tempich (2006) – Ontology Engineering and Routing in Distributed Knowledge Management

Applications.

Elicited methodological steps and structural requirements were assessed on the applicability within the

project context. The methodological steps act as a framework for the ontology design, and are discussed

in chapter 5. In addition, I documented the acquired knowledge from the literature review in a separate


report called Designing and ontology. A proposed framework. This report includes a thorough assessment

on ontology design methods and can be made available on request.

The document study included analysis of existing standardization efforts, performed simultaneously with

the document study of the problem investigation. Whereas in the problem investigation it was assessed

how the domain of operations and maintenance is captured within the standards, within this step it was

analysed how the standards were actually designed. This involves analysis of the class-modelling techniques

applied within the standardization efforts. I documented the acquired knowledge from the document study

in a separate report called Utility modeling. This report provides an overview of utility modelling methods

and standardizations practices and can be made available on request.

The structural requirements are written down following the method proposed by INCOSE (International

Council of Systems Engineering) (2015). They distinguish requirements from five different viewpoints,

being: (1) enterprise, (2) business management, (3) business operations, (4) system and (5) system element.

In accordance with these five viewpoints, the structural requirements of the domain ontology were

established.

Outcome:

Methodological steps and list of structural requirements for the design of the domain ontology.

Objective 2: Define the functional requirements for design of the domain ontology

Goal:

Identifying and describing the functional requirements to design the domain ontology.


In order to elicit the functional requirements, multiple methods and strategies were applied, as is explained

below.

First, I applied the principle of end-user engagement. Crucial for the ontology to be successful is to create

a shared set of conceptualizations about the domain. As such, the principle of end-user engagement was

one followed throughout the whole project, but first and foremost within the functional requirements

elicitation. Through active end-user engagement I was able to elicit tacit knowledge. End-user engagement

was realized through (1) a qualitative case study, (2) an expert panel and (3) regular contact with the client,

the CFM, being an end-user herself. The qualitative case study is the study referred to within the problem

investigation, and allowed insights in the actual information need of the end-user. The expert panel is a

multi-disciplinary panel consisting of the CFM, information managers, the cadastre and standardization

establishments. Two plenary sessions were held with the panel, of which the first session provided most

input concerning requirements engineering. In the first session, the use cases of the ontology were defined.

In addition to the plenary sessions, I had up to ten sessions with experts individually. The regular talks

with the CFM – ranging weekly to monthly – were held to guarantee proper coverage of the domain of

operations and maintenance within the ontology. Being an end-user herself, the CFM provided lots of

useful insights in the actual information need for operations and maintenance on utilities. Moreover, the

regular talks kept the expectations from me as a designer and the CFM as a client aligned.

Second, the stakeholders’ goals as defined earlier on during the problem investigation were translated

towards requirements. Capturing these goals through requirements within the ontology’s design, allows

justification to the stakeholders’ goals.


Third, competency questions were defined. Competency questions describe questions that the domain

ontology should be able to answer. Two types of competency questions can be distinguished, being (1)

informal and (2) formal (Obrst, Ceusters, Mani, Ray, & Smith, 2008). To elicit the functional requirements

informal competency questions are used. Informal competency questions are not yet expressed in the

formal computer-interpretable ontology language. Therefore, informal questions act as a qualitative

assessment of the requirements in terms of the ontology’s expressiveness (Grüninger & Fox, 1995).

Formal competency questions are expressed in a computer-interpretable format, and are also referred to

as queries. These only can be asked once the ontology is fully implemented. However, this is not part of

the PDEng project, and therefore, not executed.

Similar to the structural requirements, the functional requirements are written down following the method

proposed by INCOSE (2015).

Outcome:

List of functional requirements for the design of the domain ontology.

Objective 3: Design the domain ontology

Goal:

Design of the domain ontology.


To ensure the domain ontology’s structural and functional soundness, the methodological steps and

requirements as defined within the first and second objective are taken into account during the design. In

addition, a mix between a bottom-up and top-down approach is applied to model the ontology’s concepts

and relations. The top-down approach is an often applied approach used within ontology development,

and well-known for its delivery of high-quality ontologies (Sure, Staab, & Studer, 2009). Within the top-

down approach the more generic and abstract concepts are defined first and related to each other. This

assures coverage of the broader context of the ontology. However, to assure that the ontology really

delivers the information as required by the end-user, the bottom-up approach is applied as well. Through

the involvement of end-users within the ontology development process, as explained in the previous

section, is it ensured that the real information need for operations and maintenance on utilities is captured.

Outcome:

Designed domain ontology. The design of the ontology has been redesigned multiple times after

validation, characterizing the iterative design process followed.

3.3 Treatment validation

Objective 4: Validate the domain ontology

Goal:

Justifying that the developed domain ontology does contribute to the stakeholder goals while meeting the

structural and functional requirements.


In order to validate the domain ontology on its structural and functional requirements, four validation

techniques were applied, as is explained below:


First, I compared the ontology against sources of domain data. The sources of domain data were retrieved

during the qualitative case study as well as the document study of existing digital modelling standards. I

compared the domain ontology with the elicited utility modelling practices and digital modelling standards

by following the ontology typology of Gasevic et al. (2009). To this end, I could validate whether the

ontology was capable of reproducing the utility concepts and relations as seen within these data sources.

Second, I checked the ontology on its class modelling rules. In the project context, the domain ontology

was modelled within the Unified Modelling Language (UML). By applying UML rules, I could validate

the domain ontology on its structural soundness from a modelling perspective.

Third, I used input from an expert panel to validate the ontology. The expert panel sessions held for

validation, both the plenary and individual ones, are the same sessions as were held to define the

requirements during the design phase. This illustrates the concurrent design process followed during the

project. To this end, two plenary expert panel sessions were held of which the second provided most input

concerning validation. In this session, it was validated whether the information need belonging to the use

cases and competency questions could actually be modelled by the domain ontology. The individual

sessions with the experts were in general more in-depth, discussing, for example, the use of a single concept

within the ontology.

Fourth, I assessed the ontology against the (informal) competency questions defined during the design

phase. Even though the ontology was already evaluated within the second plenary expert panel session on

its use cases and competency questions, not all of them were validated because of a limited amount of

time. Therefore, I once more validated the ontology against the competency questions.

Outcome:

Validated domain ontology.

3.4 Treatment implementation

Objective 5: Implement the domain ontology

Goal:

Partial implementation of the domain ontology in asset management related GIS software.


The designed domain ontology cannot directly be implemented in (spatial) asset management and GIS

related software. UML is a graphically oriented ontology language, and consequently, not directly

interpretable by (spatial) asset management and GIS software. Therefore, I converted the domain ontology

in UML to an XML (Extensive Markup Language) schema file. XML is a widely adopted standard

language for exchanging information. Through the XML schema file, I was able to write existing utility

data towards a GML (Geography Markup Language) file, which is a format widely supported by GIS

related software. To this end, the domain ontology can be applied in GIS software.

Outcome:

Partially implemented domain ontology.


4 Problem investigation and analysis

This chapter elaborates on phase one of the engineering cycle, the problem investigation. To investigate

the problem, first a stakeholder analysis is conducted. Second, the phenomena of interest are investigated,

including an investigation of existing utility modelling practices and standardization efforts. The chapter

concludes with the problem statement and opportunities.

4.1 Stakeholder analysis

This section includes the stakeholder analysis. First, the stakeholders of interest to the PDEng project are

identified. Second, the identified stakeholders are mapped according to the onion model of Alexander

(2005).

4.1.1 Stakeholder identification

A stakeholder is a person, group of persons or an institution affected by the to be treated problem. They

are the source of goals and constraints within the project context, which in their turn are the source for the

requirements (Wieringa, 2014). Therefore, identification of stakeholders is regarded highly relevant to

ensure all requirements are taken into account. The stakeholders of interest to this PDEng project are

described within Table 2, together with their goals and constraints.

Table 2 – Stakeholders within the project

# Stakeholder Description Goal(s) Constraint(s)

1 Designer PDEng trainee of the

University of Twente,

responsible for development


Acquiring PDEng certificate. Project duration of two years.

2 Client (CFM) Industry partner within the

PDEng project. Park and

terrain manager of the

campus of the University of

Twente with full ownership

over her utilities.

Real-time insight in the as-built

information of their utilities.

Easy utilization of ontology.

Improving effectiveness and

efficiency of operations and

maintenance related activities.

As-built information currently

CAD based.

Limited extensiveness of as-

built information.

3 Utility owners Organizations with

ownership over utilities.

This includes public domain

authorities as well.

Real-time insight in the as-built

information of their utilities.


Organizational (utility

modelling) routines.

Privacy of utilities information.

4 Utility

operators

Organizations responsible

for operations and

maintenance related

activities on utilities.

Improving effectiveness and

efficiency of operations and

maintenance related activities.


Organizational (utility

modelling) routines.

Privacy of utilities information.

5 Excavation

contractors

Organizations responsible

for excavation works.

Reducing excavation damages to

utilities.


-

6 Authorities Organizations concerned

with class-modelling of

utilities (such as the

cadastre).

Improving system

interoperability of utility data.

Conformance with existing

class-modelling standards.


7 Software

developers

Organizations developing

the (spatial) asset

management related (GIS)

software.

Development of sector-wide

(spatial) asset management

related (GIS) software.

Application within existing

(spatial) asset management

related (GIS) software.

8 Utility users End-user of utilities. Reliable use of the services by

utilities.

-

9 Investors Organizations funding the

project.

Project accomplishment within

budget.

Project budget.

4.1.2 Stakeholder mapping

Mapping of the stakeholders follows the onion model of Alexander (2005). This model focuses on the

stakeholders’ relationship to the final product rather than on the stakeholders’ power and interest. The

onion model builds a stakeholder taxonomy and provides insights in the relevance of the stakeholders

towards the domain ontology. Mapping of the stakeholders according to the onion model is shown in

Figure 2.

Figure 2 shows the onion model

including the stakeholders within

the project. The inner circle

comprises ‘The Product’, which is

the product of design, in this project

the domain ontology for utilities.

The next circle, ‘The System’ circle,

involves the stakeholders that do

have an influence on the design of

this domain ontology and / or

eventually will be the end-user of the

product. Following the earlier

explained principle of end-user

engagement, this circle includes the

client, utility operators and utility

owners, in addition to the designer.

Creating a shared set of

conceptualizations amongst these

stakeholders is of great importance.

The next circle, ‘The Containing

System’, involves beneficiaries and

others, who are not directly involved in the design of the product. This circle includes the excavation

contractors, software developers, investors and authorities. Albeit they do have an influence on the design,

their influence is indirect, whilst they don’t have a direct say in the design choices to be made. In the last

circle, ‘The Wider Environment’, all other stakeholders that are recognized within the project are

included. This circle includes the utility user, which might benefit from less down-time of utilities, due to

more effective and efficient operations and maintenance of utilities.

Figure 2 – Stakeholder mapping following Alexander’s (2005) onion model


4.2 Phenomena

This second elaborates on the phenomena of interest to the PDEng project. To this end, first utility

modelling practices are explored. Second, international and national utility modelling standardization

efforts are analysed.

4.2.1 Utility modelling practices

A notable shift within the utility sector – following the general trend within the construction industry – is

the increasing attention to life cycle management (Bradley, Li, Lark, & Dunn, 2016). Therefore, utility

owners and operators increasingly want to have an uniform and consistent set of digital information about

their utility objects. Uniform and consistent information about utility objects is essential to (1) effectively

utilize it for installation, operations and maintenance purposes, (2) carefully excavate and (3) thereby

reducing damages to utilities. Since operations and maintenance of the utility objects requires more

attribute data than only the location, dimensions and materials – nowadays mainly registered – other

attribute types become relevant, such as shape, costs, performance, surrounding, dependency,

redundancy, state of operation and impact (El-Diraby & Osman, 2011).

The shift to life cycle management ideally assumes that domain knowledge is captured in a uniform and

consistent set of concepts and relations. However, in practice this overview is missing whereas

organizations (utility owners, utility operators, contractors) describe concepts/objects using different (1)

attributes, formats, relationships and (2) semantic terms. Altogether, these may result in misunderstanding

(hypernyms (different subordinates), homonyms (pronounced the same, different meaning), synonyms

(different words, equal meaning)) when utility data is communicated.

To explore how utilities are modelled in practice, a qualitative case study was conducted. As explained in

chapter 3, I studied the utility modelling practices within a Dutch utility engineering company. Findings of

the case show that the elicited digital models include a comprehensive set of utility asset data. To this end,

around twenty to forty infrastructure objects within a digital model were found, depending on the type of

utility discipline. For the telecommunication discipline, for example, around twenty utility infrastructure

objects were found, whereas the gas discipline covered up to even forty objects. Following the typology of

utility infrastructure objects of El-Diraby and Osman (2011) – which distinguishes between component

level, subsystem level and system level top-level objects – most of the utility infrastructure objects found

belong to the component level. Below the typology of utility infrastructure objects is briefly explained:

Component level – Lowest level of utility infrastructure objects. Objects that in essence cannot be

decomposed any further.

Subsystem level – Intermediate level of utility infrastructure objects. Objects that can be

decomposed, but also are composed of objects themselves.

System level – Top level of utility infrastructure objects. Objects that are on top of the hierarchy.

To illustrate how this typology applies to practice, Table 3 provides the found system, sub-system and

component level objects for the telecom domain. The objects as presented are already analysed, meaning

that similar objects from multiple digital models (and multiple utility owners) are grouped together.


Table 3 – Snap of empirical analysed utility data from the telecom domain

System level object Subsystem level object Component level object

Telecom distribution system Fiber line system

Coax line system

Cable

Connection

Station/center

Patch box

Handhole

Point of Presence

Tube

Transition

Cable

Connection

Station/center

Sleeve

Amplifier

Splitter

Moreover, I found extensive lists of attribute information for the infrastructure objects at hand. Within

elicited digital models from the gas discipline, for example, up to eighteen attributes for the component

level object ‘pipe’ were found as illustrated in Table 4. A comparable number of attributes were found for

other infrastructure objects. The attributes as presented are already analysed, meaning that similar

attributes from multiple digital models (and multiple utility owners) are grouped together.

Table 4 – Snap of empirical analysed utility data from the gas domain

System level

object

Subsystem level

object

Component

level objects

Attributes

Gas distribution

system

Gas low

pressure

network

Pipe Location, sub net, date of installation, pressure level,

material, implementation, coating, connection type, cathodic

protection, tensile resistance, length, date of rehabilitation,

accuracy, owner, operator, financial characteristic,

controlled drilling

To classify the infrastructure attributes, I used the typology of El-Diraby and Osman (2011) which

distinguishes the following twelve attribute types: (1) dimensional attributes, (2) spatial attributes, (3)

material attributes, (4) shape attributes, (5) cost attributes, (6) performance attributes, (7) surrounding soil

attributes, (8) dependency attributes, (9 redundancy attributes, (10) state of operation attributes, (11)

impact attributes and (12) use attributes. The attribute types are briefly explained below:

[1.] Dimensional – Describing measurable dimensions of a component, for example, the interior width

or exterior diameter.

[2.] Spatial – Describing a location-related attribute of the component, for example, the x- or y-

coordinate.

[3.] Material – Describing one or more attributes of the component material, for example, the type or

ductility.

[4.] Shape – Describing the shape of a component, for example, circular or rectangular.

[5.] Cost – Describing a monetary value associated with the component, for example, capital or

maintenance costs.


[6.] Performance – Describing the performance of a component, for example, the engineering or

serviceability performance.

[7.] Surrounding soil – Describing the soil-related properties surrounding the component, for example,

the type and permeability.

[8.] Dependency – Describing the interdependencies between components, for example, physical or

geographical.

[9.] Redundancy – Describing the need of a particular component within the greater network in case

of a breakdown of that component.

[10.] State of operation – Describing the state of operation of a component at a particular state in time,

for example, functional or under construction.

[11.] Impact – Describing the impact of a component, for example, environmental or economic.

[12.] Use – Describing use related properties of a component, for example, the function or use of a

component.

Within the elicited digital models mostly use attributes (12) were found. Use attributes for example cover

information about its function or use, but also about the date of installation or related party. Attributes

concerning material (3), performance (6) and state of operation (10) follow with a fairly comparable

distribution. The number of

attributes found per attribute type is

presented in Figure 3. Reflected

upon the domain of operations and

maintenance the lack of cost (5),

impact (11), shape (4) and

surrounding soil (7) attributes is

important to acknowledge. Even

though these attribute types

provide necessary information to

effectively utilize operations and

maintenance related activities, they

are (almost) not represented in the elicited realities. For a complete overview of the found infrastructure

object and attributes within the elicited digital models I refer to Appendix III.

A comparison between the elicited digital models showed that in general similar objects and attributes

were captured by the utility owners. The digital models include comparable system, subsystem and

component level objects. This finding also applies to the type of attributes captured. However, a more

detailed comparison between the digital models shows subtle differences. For each of the three elements

of the typology of Gasevic et al. (2009), one difference is presented in detail, while some other examples

are briefly noted. Since the data has been collected in Dutch, for both differences in vocabulary and

semantics, the original Dutch term is given in addition to the English translation to secure its intended

meaning. I elaborate this below:

[1.] Taxonomy and hierarchy

An example of a taxonomical difference is visible within the telecom discipline. Within the discipline,

subsystem level and system level objects to model a telecom network are applied in the following two ways.

First, two digital models use subsystem level objects to model both coaxial and fiber networks as individual

subsystems. The main telecom network, including both the coaxial and telecom network, is modelled on

Figure 3 – Distribution of attribute types within elicited realities

20

9 9 8

5 5

2 2 1 1 0 0


top of the taxonomy at the system level. Second, another digital model does not distinguish subsystems

level objects for the coaxial and fiber network. Here, the particular network type is specified as an attribute

of the subsystem object, i.e. the main network.

Another taxonomical difference, for example, is visible within the modelling of the object 'station' (station)

when comparing three digital models within the gas discipline. Where two digital models model a station

as one single component level object and define its type (internal, external) at the attribute level, one other

digital model defines the type of station already at the component level object.

[2.] Vocabulary, terms and names

An example of a difference in vocabulary is the similar use of the words 'meting' (measurement) and

'nauwkeurigheid' (accuracy) when comparing two digital models within the electricity discipline. Both

digital models use these words to describe the type of measurement of coordinates (either analogous or

digital) in order to estimate how accurate the coordinates of component level objects are.

Another notable difference in use of vocabulary, for example, is the similar use of the words 'ligging' (area)

and 'locatie' (location) to describe the x and y coordinates of a component level object.

[3.] Semantics

A semantic difference in the elicited digital models is the ambiguous meaning of the word 'uitvoering'

(implementation). The word is used to describe various characteristics of objects on mainly the component

level. Six digital models across the telecom, gas and electricity discipline, show the use of the word to

describe divergent characteristics such as diameter, manufacturer, material type, and installation type. This

difference was even found in individual digital models of the gas discipline. In addition, in three digital

models of the electricity discipline, the word is used to describe multiple characteristics at once, including

manufacturer, material and diameter.

Other examples of semantic differences, for example, include the ambiguous meaning of both the words

'sort' (soort) and 'type' (type). Similar to 'uitvoering' (implementation), these words are used to describe

various characteristics of objects, being mainly the installation type and material type.

Main reason of the existence of these differences is the existence of ‘organizational’ standards. The findings

of the case study showed that the modelled digital models were represented in: (1) international, (2)

national and (3) organizational standards. Both through observations of the work practices and study of

asset management guidelines, it was revealed that, for example, each of the utility owners prescribed their

own asset data registration standard, based on their own work practices. According to one of the

information managers spoken with during the case study, these ‘organizational’ standards were used more

frequently that the international and national standards. The illustrated examples also follow from these

organizational standards. In conclusion, one can argue that practice shows a widespread of ‘digital realities’.

Based on a set of fundamental propositions or world views, utility owners develop their own perceived

view on the reality, and model utility networks accordingly.

The findings from the qualitative case study were also taken as a basis for the conference paper

‘Digitization for integration: fragmented realities in the utility sector’ (ter Huurne & olde Scholtenhuis,

2018). I presented this paper at the 34th

ARCOM conference in Belfast, September 2018. The premise

tackled in the paper is the general belief that digitization leads to integration, by arguing the existence of

fragmented realities in the utility sector. The paper is enclosed to this report and can be found in Appendix

VII.


4.2.2 Standardization efforts

The limited use of international and national standards by utility owners raises the question whether

existing international and international standards are capable of representing the comprehensiveness of

utility information as required by their users. This question was answered through a document study

covering multiple existing utility modelling standards. A complete overview of the standards examined is

provided is Appendix IV.

Before a standard, also utility modelling standards, emerges, it goes through the process of standardization.

The aim of standardization, in general, is to capture realities and construct uniformities across cultures,

time and geography on the basis of agreed-upon rules (Timmermans & Epstein, 2010). These agreed-

upon rules are thereby captured in standards (Bowker & Star, 1999; Timmermans & Epstein, 2010). The

types of standards relevant to the project context are digital modelling standards. Standardized data formats

and structures help to achieve integration under the condition that these are accepted and represent end-

users’ shared conceptualizations.

Drawing upon Howard and Björk (2008) standardization is critical to facilitate communication between

stakeholders in a fragmented industry – like the AEC industry and in specific the utility sector. Where

standards for representing construction data and geospatial data, such as the Industry Foundation Classes

(IFC) and CityGML are gradually accepted and used as the predominant way to exchange data between

engineering software, common data formats for other types of infrastructure such as utilities are less

developed (Bradley, Li, Lark, & Dunn, 2016).

Well-known digital modelling standards for utilizes that do exist – from an international and national

perspective – are, for example, INSPIRE (European Union) and IMKL (the Netherlands). By reflecting

these and other standards upon the project context – i.e. operations and maintenance of utilities – and the

domain data collected within the case study, insights were retrieved in how capable these standards are in

modelling operations and maintenance related utility information. Standards analysed include INSPIRE,

IMKL, CityGML UtilityNetwork ADE, Utility Survey Standard, PAS 128 and ASCE 38-02. More

standards were analysed, but due to brevity reasons not included in this chapter. For more information on

these standards, I refer to Appendix IV or the report Utility modeling. The latter can be made available

on request.

A systematic comparison between the analysed digital modelling standards is provided in Table 5 (page

22). I analysed the six standards on six areas:

[1.] Focus – Focus (purpose) of the digital modelling standard.

[2.] Scope – Scope of the digital modelling standard.

[3.] Users – Targeted end-users of the digital modelling standard.

[4.] Data – Coverage of operations and maintenance related utility data within digital modelling

standard.

[5.] Origin – Origin of digital modelling standard.

[6.] Reference – Reference to digital modelling standard.


Table 5 – Comparison between and overview of utility digital modelling standards

INS

PIR

E

IMK

L

Cit

yGM

L

Utility

Netw

ork

AD

E

Utility

Su

rvey

Sta

nd

ard

PA

S 1

28

AS

CE

38-0

2

1 Focus Create an integrated

European infrastructure to

provide cross-border

interoperability and

exchangeability of spatial

data.

Improve interoperability

and exchangeability of

utility data to prevent

excavation damages.

Develop a homogenized

3D network model for

multi-utility simulation

including the relevant

thematic attribution.

Create a common

understanding of the

acquisition and production

of utility data within utility

surveying through

guidelines.

Set out clear and

unambiguous provisions to

those engaged in

the detection, verification

and location of active,

abandoned, redundant or

unknown utilities.

Develop a consensus

standard for classifying the

quality of utility location

and attribute information

that is placed on plans,

allowing users to

developed strategies to

reduce risk by improving

the reliability of utility

information in a defined

manner.

2 Scope Applies to the utility

disciplines of electricity,

oil, gas, chemicals, sewage,

telecommunication and

water. Provides basic

information on a wide

range of administrative

and social services of

public interest.

Applies to the utility

disciplines of interest to

the Netherlands and

Belgium. Specifically

aimed at preventing

damages during excavation

activities.

No predefined utility

disciplines. Disciplines are

modelled through

properties set. Specifically

modelled as an extension

to CityGML for failure

simulation of utility

networks.


disciplines of electricity,

gas, sewage,

telecommunication, water

and drainage. Specifically

developed for utility

surveying.


disciplines of drainage,

gas, water, electricity and

telecommunication.

Specifies requirements for

detection, verification and

location of existing and

new underground utilities.

Applies to existing utilities

of the disciplines

electricity, gas, oil, crude,

water, thermal,

telecommunication,

sewage or any similar

commodity. Specifies

guidelines on how utility

information can be

obtained, what

technologies are available

to obtain the information,

and how that information

can be conveyed to the

users.

3 Users Targeted end-users are

map requesters, utility

owners, and public

domain authorities.

Targeted end-users are

map requesters, utility

owners, and public

domain authorities.


(mainly) utility owners and

public domain authorities.

Targeted end-users are all

involved in utility

surveying (can be a map


practitioners (surveyor,

geophysicist or utility

engineer) but also clients


contractors, project

owners, utility owners and

engineers. Therefore,


requestor, utility owner or

public domain authority).

(such as engineers,

contractors, project

owners and utility owners).

Therefore, users involve

both map requestors and

utility owners.

users involve both map

requestors and utility

owners.

4 Data Application schema

(UML) that contains

system, subsystem and

component level objects.

Material, performance and

use attributes are partially

covered, whereas cost,

surrounding soil, and

impact attributes are

lacking.

Application schema

(UML) that contains








lacking.

Application schema

(UML) that contains





covered, whereas cost



lacking.

Guidelines and templates

prescribing which utility

data to be collected and

how. No taxonomy or

modelling of relations

between objects. Standard

is not object-based but

does describe subsystem

and component level

objects. Material and use

attributes are partially


performance, surrounding

soil, dependency,

redundancy, and impact

attributes are lacking.

Requirements for the


location of existing and

new activities. Standard

does not provide a

taxonomy nor vocabulary.

Standard is not object-

based but does describe




covered, whereas shape,

cost, surrounding soil,

dependency, redundancy,

state of operation and


lacking.

Guidelines on collection

and depiction of utility

information on four

quality levels. Each level

prescribes what utility

information must be

collected and how this

must be conveyed to the

users. The guidelines do

not provide a taxonomy

nor vocabulary. Standard

is not object-based but

describes component level

objects. Attributes are en-

closed in (CAD) drawings

through labelling, symbols,

colour coding, line types

or text. Dimensional and


covered, whereas material,

shape, cost, performance,

surrounding soil,

dependency, redundancy

and impact attributes are

lacking.

5 Origin European Union The Netherlands /

Belgium

Global Singapore United Kingdom United States

6 Reference D2.8.III.6 INSPIRE Data

Specification on Utility

and Government Services

– Technical Guidelines

(INSPIRE, 2013)

IMKL 2015 –

Dataspecificatie

Utiliteitsnetten version 1.2

(Geonovum, 2017)

CityGML UtilityNetwork

ADE version 0.9.2

(CityGML, 2016)

Standard and

Specifications for Utility

Survey in Singapore

version 1.0 (Singapore

Land Authority, 2017)

PAS 128:2014

Specification for utility


location (British Standards

Institution, 2014)

ASCE 38-02 Standard

Guideline for the

Collection and Depiction

of Existing Subsurface

Utility Data (American

Society of Civil Engineers,

2002)


4.3 Problem statement and opportunities

This section elaborates on the problem statement and opportunities, based on the aforementioned

stakeholder analysis and phenomena investigation. First, the problem statement is defined. Second, the

opportunities are explored, whilst also keeping possible challenges in mind.

4.3.1 Problem statement

The problem investigation and analysis, in essence, showed the following problems in the registration and

processing of utility information:

[1.] Plethora of utility modelling practices to model domain knowledge, all describing utility

concepts/object using different (1) attributes, formats, relations and (2) semantic terms.

[2.] Lack of coverage of operations and maintenance required utility information in existing standards.

The utility modelling practices of twelve utility owners observed in the qualitative case study showed a

plethora of ways to register and process utility information. This this end, I found differences in utility

information registration on (1) taxonomy and hierarchy, (2) vocabulary, terms and names, and (3)

semantics. Even though the differences are sometimes very subtle, they prevent proper integration and

system interoperability of utility data. Moreover, these differences can result in the aforementioned

confusion and miscommunication during the preparation and execution of utility works.

Concerning existing standardization efforts, analysis of six standards showed the absence of required

operations and maintenance utility information. Assessment of the standards on the infrastructure typology

of El-Diraby and Osman (2011) shows that none of the standards is capable of describing utility networks

and their domain knowledge in the consistent and complete manner required for operations and

maintenance – i.e. for life cycle management. Attributes related to material, performance and use are often

only partially covered, whereas attributes related to costs, surrounding soil, impact, and even state of

operations are sometimes completely lacking. Presumably, this is because none of the analysed standards

were explicitly developed for the purpose of operations and maintenance on utilities.

The absence of a digital modelling standard developed specifically for operations and maintenance

ultimately is the main reason to the plethora of ways utility information is registered and processed as seen

in practice. More specific, the findings within the qualitative case study showed the presence of

‘organizational’ standards being preferred by organizations over the existing international and national

standards. To summarize, I define the problem statement as follows:

For utilities’ operations and maintenance, the main concepts and relations are not covered within an

accepted and shared digital modelling standard. As a consequence, organizations create and use their own

organizational standards to model their comprehensive set of domain knowledge. Ultimately, this leads to

the presence of fragmented digital models in the utility sector, making the preparation and execution of

utility works prone to confusion and miscommunication of utility information.

4.3.2 Opportunities and challenges

The problem investigation and analysis – and, therefore, the problem statement – legitimates the project

goal as defined in section 2.1.1:

Development of a domain ontology that includes the relevant concepts and relations for the operations

and maintenance of utilities.


The lack of an operations and maintenance focused digital modelling standard for utilities provides room

for the development of one – i.e. the goal of this PDEng project. The contribution that the domain

ontology can deliver to the utility sector is:

[1.] to provide a domain concept overview that is useful to bridge the various organizational standards

within the domain. This may facilitate the transfer between formats and shape standardized object

descriptions;

[2.] the integration of utility domain information with other domains (such as BIM and GIS

information);

[3.] the support of smarter reasoning within utility models, and accordingly, digital maintenance

practices.

The place of a domain ontology within the existing utility sector is illustrated in

Figure 4. The figure shows the as-is situation on the left, and the future situation including the domain

ontology on the right. The figure starts at the bottom with the organizations involved within the utility

sector. Each of these organizations has a certain information use and need. Throughout the years these

information uses and needs have been translated into specific digital modelling standards, who can be of

an international, national or organizational kind. These distinctive standards are taken as a basis for utility

modelling, resulting in a certain ‘modelled reality’ applied in digital environments, such as asset

management software.

Figure 4 – The place of a domain ontology within the industry (left as-is, right with a domain ontology included)

The inclusion of the domain ontology, as illustrated on the right side of the figure, provides a consistent

and uniform layer between the existing standards and modelled realities. To this end, I propose the

domain ontology not as a replacement for existing standards, but either as a fundament on which these

standards can be based. This means organizations can still use their own organizational standards.

Modelled realities, however, now are all based upon the domain ontology, and therefore, interoperable

with one another.

One great challenge to be considered is the adoption of the domain ontology once developed. Drawing

upon Geels (2004), one must take the existing socio-technical system into account in which the domain

ontology will be introduced as a new innovation. A socio-technical system is a cluster of elements including

Information use / need

Standards

(International, national, organizational)

Domain ontology

Organization

(map requestor, network authority, public

domain authority)

Information use / need

Standards

(International, national, organizational)

Organization

(map requestor, network authority, public

domain authority)

Modelled

reality

Modelled

reality

Modelled

reality

Modelled

reality

Tooling Tooling Tooling Tooling

Modelled

reality

Modelled

reality

Modelled

reality

Modelled

reality

Tooling Tooling Tooling Tooling

used in used inused in used in used in used in used in used in

has has

translated intotranslated into

translated into

forms

forms

tran

slat

ed

into


technology, regulations, user practices, markets, cultural meaning, infrastructure, maintenance networks

and supply networks. Within a socio-technical system three elements play a role: (1) the socio-technical

system, (2) the social groups, and (3) the rules (also understood as regimes). Therefore, a socio-technical

system is a stable regime carried by the three elements mentioned.

Introducing a new innovation – in this case the domain ontology – in an existing socio-technical system

may induce resistance and hesitation through a certain level of stabilization of the established regime.

Geels (2004) mentions that niche innovations, which I consider the domain ontology, are rather difficult

to introduce in such existing regimes. Therefore, for niche innovations, new socio-technical regimes are

created, acting as ‘incubators’ for the innovation to nurture. The whole process of becoming the new socio-

technical regime, and thereby, the shared and accepted standard in the utility sector takes time and

requires momentum before it breaks through. Such momentum may be realized through the

establishment of a higher focus on collaboration, for example, in the utility sector. In addition, the greater

attention to lifecycle management may also be beneficiary for the adoption of the domain ontology as the

new regime.

The next chapter continues with the design of the ontology, phase two within the engineering cycle. The

chapter elaborates on:

the methodological steps for the design of the domain ontology.

the structural requirements for the design of the domain ontology.

the functional requirements for the design of the domain ontology.

the actual design steps taken to design the domain ontology.


5 Treatment design

This chapter elaborates on phase two of the engineering cycle, the treatment design. Within this chapter,

the project objectives 1, 2 and 3 are covered. To this end, this chapter starts with defining the

methodological steps of ontology development. Thereafter, both structural and functional requirements

are defined. Based on the methodological steps and requirements, this chapter concludes with the

ontology design.

5.1 Methodological steps

Based on a literature review and assessment of ontology development methodologies, I created a list of

methodological steps required for successful development of a domain ontology. Within this PDEng

project, I defined the following seven ontology development steps, still adhering to the engineering cycle

of Wieringa (2014):

[1.] Define competency questions

Discussed in section 5.2.1 ‘Competency questions’.

o Definition of informal competency questions.

[2.] Define requirements

Discussed in section 5.2.2 ‘List of requirements’.

o Definition of structural requirements.

o Definition of functional requirements.

[3.] Choose ontology development tool

Discussed in section 5.3.1 ‘Ontology development tool’.

[4.] Choose ontology language

Discussed in section 5.3.2 ‘Ontology language’.

[5.] Build ontology

Discussed in section 5.3.3 ‘Build ontology’.

o Definition of informal ontology description.

o Building of the formal domain ontology.

[6.] Validate and refine ontology

Discussed in chapter 6 ‘Treatment Validation’.

[7.] Implement ontology

Discussed in chapter 7 ‘Treatment Implementation’.

This chapter elaborates on the first five ontology development steps, with as a result the design of the

ontology. Both the definition of the competency questions (step 1) and requirements (step 2) are discussed

in the next section. The chapter concludes with the design of the ontology. Within this section, the

ontology development tool (step 3) and language (step 4) are chosen, followed by the build of the ontology

(step 5).


5.2 Requirements engineering

This section presents the list of requirements for design of the domain ontology. In order to elicit the

requirement, multiple methods and strategies were applied: (1) defining competency questions, (2)

translating stakeholder goals towards requirements, and (3) applying the principle of end-user engagement.

5.2.1 Competency questions

The definition of competency questions is the first step in the actual development process of the domain

ontology. As explained before in section 3.2, competency questions are questions that the ontology should

be able to answer (Obrst, Ceusters, Mani, Ray, & Smith, 2008). In other words, the ontology should be

able to provide the information required to answer the asked for questions. Therefore, the competency

questions directly relate to the main goal of the client in the PDEng project, the CFM, which is having

real-time insight in the as-built information of their utilities. To ensure the ontology could live up to this

goal, the informal competency questions were together with the CFM defined in multiple meetings.

Definition of the (informal) competency questions is closely related to the use cases of the ontology.

Therefore, during the meetings with the CFM, first the use cases were defined collaboratively. Within the

context of this PDEng project, a use case is seen as an intended utilization of the domain ontology. These

use cases supported the structuring and defining of the (informal) competency questions. In accordance

with the PDEng’s project goal, scope and objectives, in total seven use cases in the context of operations

and maintenance were defined. Altogether, these use cases are grounded as being a prerequisite of proper

life cycle management and operations and maintenance on utilities. Subsequently, competency questions

were defined and categorized within a particular use case. To this end, in collaboration with the CFM, I

specified the following list of use cases and their accompanying competency questions as a basis for the

domain ontology:

[1.] Assessment of the functioning and usage of a utility network and / or its individual components.

What kind of commodity does the utility network distribute?

What is the function of the utility network and / or its components?

What is the actual usage of the utility network and / or its components?

What is the state of operation of a utility network and / or its components?

[2.] Identification of a utility network and / or its individual components.

What is the location of a utility network and / or its components in the (1) x-, (2) y-, and

/ or (3) z-coordinate?

What is the spatial accuracy of the utility network and / or its components?

What are the interior and exterior dimensions of the utility component?

What is the shape of the utility component?

What is the (main) colour of the utility component?

What exterior, interior and filling material does the utility component exist of?

What is the unique ID of the utility network and / or its components?

[3.] Assessment of dependencies and redundancies between (1) utility networks, (2) a utility network

and its components, and (3) components.

How are utility networks related to each other?

How are utility networks and their components related to each other?

How are utility components within a single network related to each other?

How are utility components within distinctive networks related each other?


[4.] Mapping the impact of a utility network and / or its individual components.

What is the social impact of the utility network and / or its components?

What is the environmental impact of the utility network and / or its components?

What is the economic impact of the utility network and / or its components?

[5.] Mapping the risks involved within a network and its individual components.

What is the risk to damages due to excavation?

What is the risk to damages due to vegetation?

What is the risk to damages due to settlement of the subsurface?

What is the risk to function loss due to deterioration or any other reason?

[6.] Assessment of the performance of a utility network or its individual components.

Which performance requirements are set for the utility network and its components?

What is the nominal flow of a commodity through a distribution line?

What is the operational flow of a commodity through a distribution line?

What is the maximum flow of a commodity through a distribution line?

What is the age of the utility component?

For how long has the utility component been in use?

What is the expected lifespan of the utility component?

[7.] Planning of operations and maintenance related activities.

Who is the owner of the utility network and / or its components?

Who is the operator of the utility network and / or its components?

When was the last maintenance activity performed?

What has been done during the last maintenance activity?

How many utility components are enclosed within a particular protective component?

The above defined use cases and questions were taken as a first basis for the requirements of the ontology

and its initial design. Later on in the development process – i.e. validation of the domain ontology – the

use cases, competency questions, requirements and consequently the domain ontology were refined in an

iterative process.

5.2.2 List of requirements

Wieringa (2014) distinguishes both functional and non-functional requirements (in this report mentioned

as ‘structural requirements’). A functional requirement can be defined as a requirement for desired

functioning of the treatment. Examples are the function to map risks or assess the performance of a utility

network. A structural requirement on the other hand is any requirement with a non-functional property.

Examples are accuracy of output or interoperability with other systems (2014).

An ontology is only successful if it is capable of creating a shared set of conceptualization about the to-be

modelled domain. Therefore, to elicit the functional requirements, I particularly focused on end-user

engagement. This was realized through (1) the qualitative case study, (2) the expert panel sessions and (3)

regular contact with the CFM. The source of domain data retrieved from the qualitative case study allowed

direct insight in the information need of the end-user. The expert panel provided a multi-disciplinary

perspective of the utility sector. The CFM ultimately provided insight in the actual operations and

maintenance related activities and were the main contributor to the competency questions. These

competency questions defined the utility information to be covered by the ontology, thereby related to the

goal of the CFM to have real-time insight in the as-built information of their utilities. Altogether, these

sources of information were reflected upon – and subsequently coupled to – the stakeholder goals.


In addition to functional requirements, structural requirements were defined as well. These were elicited

from a literature review and document study. To this end, I studied five papers describing (structural)

principles for a good ontology (Gruber, 1995; Grüninger & Fox, 1995; Gómez-Pérez, 2004; Gangemi,

Catenacci, Ciaramita, & Lehmann, 2005; Obrst, Ceusters, Mani, Ray, & Smith, 2008). Eight criteria could

be defined being: (1) accuracy, (2) adaptability, (3) clarity, (4) completeness, (5) computational efficiency,

(6) conciseness, (7) consistency, and (8) organizational fitness.

The requirements were written down following the method proposed by INCOSE (2015). This method,

as explained before, distinguishes requirements from the five standpoints of (1) enterprise, (2) business

management, (3) business operations, (4) system and (5) system element. The complete list of

requirements for the domain ontology is presented in Table 6. In the second-last column of this table it is

mentioned whether I took responsibility for the requirement or not. A check mark illustrates the

requirement is taken care of within the PDEng project; a cross does mean the contrary. In the last column

of the table it is mentioned whether I could validate the requirement or not (discussed in chapter 6). Again,

a check mark illustrates the requirement is validated; a cross does mean the contrary.

5.3 Ontology design

This section elaborates on the chosen ontology development tool, chosen ontology development language

and rationale behind the ontology development process.

5.3.1 Ontology development tool

In order to develop an ontology, one requires an ontology development tool. Ontology development tools

are aimed at providing support for the development process of an ontology (Corcho, Fernández-López,

& Gómez-Pérez, 2002). Within this PDEng project I made use of a so-called ‘ontology editor’. These

tools help in organizing the overall structure of an ontology by modelling concepts, properties, relations

and constrains. In addition, these editors are often capable of reconciling syntactic, logical and semantic

inconsistencies among the elements of the ontology (Gasevic, Djuric, & Devedzic, 2009).

Many ontology editors, and moreover, ontology tools and environments for building ontologies, exist. The

broad range of tools may make it difficult to choose the right one for the ontology development process.

To make a grounded choice, I analysed multiple ontology development tools – including Protégé,

OntoloLingua, Enterprise Architect and WebODE – on four aspects:

[1.] Interoperability – Interoperability with ontology development languages.

[2.] Knowledge representation – Capability to model concepts, relations, classes, attributes and

instances.

[3.] Inference services – Services concerning constraints and consistency checking, automatic

classifications and exception handling.

[4.] Usability – Support of the user by a graphical taxonomy, graphical views, zooms and libraries.

Based on the analysis of the ontology development tools, I chose Enterprise Architect. This tool is

interoperable with many ontology development languages including UML, is capable of modelling a full

knowledge representation, is able to perform inference services, provides a graphical environment in

which the ontology is build, and moreover, is also used to model CityGML UtilityNetwork ADE. More

information about the assessment of ontology development tools is included in the report Designing an

ontology. A proposed framework. This report can be made available on request.


Table 6 – Goals, needs and requirements following the INCOSE method

# View Goals Needs Requirements Scope Validated

1.1 Enterprise Enterprise

strategy

Improved operations and maintenance of

utilities

Reduce costs Improved efficiency and effectiveness of operations and maintenance of

utilities.

1.2 Reduce errors and damages Reduction of work delays through real-time insight in status and

performance of utilities.

1.3 Reduction of deterioration and damages through real-time insight in

status and performance utilities.

2.1 Improved system interoperability of utility

data

Reduce miscommunication and

misinterpretation

Unified and uniform set of concepts and relations based on shared

conceptualizations of the end-user.

3.1 Business

Management

Business

Needs

Ontology is future-proof Modular Must allow new modules or elements to be added without changing its

already existing core.

3.2 Adaptable Must be easy to adapt (and extent) in case of changes in the information

need of users.

3.3 Must allow modelling of every kind of utility discipline.

4.1 Use of ontology is financially attractive Efficient Must lower life cycle costs of utilities through efficient operations and

maintenance.

4.2 Effective Must extend the lifespan of utilities through effective operations and

maintenance.

4.3 Affordable Must be open-source and free of use.

5.1 Business

Operations

Stakeholder

Needs

Real-time insight in the as-built information

of their utilities.

Accurate Must cover the expertise of its users in the correct fashion.

5.2 Complete Must cover all relevant concepts and relations within the domain of

operations and maintenance.

5.3 Concise Must not include redundant or irrelevant concepts and relations

regarding the domain of operations and maintenance.

5.4 Consistent Concepts and relations must be consistent without any contradictions.

6.1 Easy utilization of ontology Computational efficient Must allow an easy and successful reasoning process to the reasoners

(users)

6.2 Clear Must include a defined, explained and documented taxonomy and

hierarchy.

6.3 Must include a defined, explained and documented vocabulary of terms

and names.

6.4 Instructions Must provide instructions on how to apply the ontology which are easy

to read, learn and apply.

6.5 Organizational fitness Must comply with (spatial) asset management and GIS software.


6.6 Transparent Ontology and accompanying documentation must be made available

through an online repository.

6.7 User-friendly Components and relations must be easily traceable by the user.

7.1 System System

Needs

Supported by user and environment Support by (spatial) asset

management and GIS

Must comply with existing (spatial) asset management and GIS software

currently used in the utility sector.

7.2 Support by ontology modelling

languages

Must comply with existing ontology modelling languages (i.e. UML) to

be compatible with ontology modelling tools.

7.3 Support by digital modelling

standards

Must comply with utility data as modelled in existing digital modelling

standards (i.e. INSPIRE and CityGML UtilityNetwork ADE).

7.4

Supported by utility sector Must be supported by the utility sector through reaching consensus in

which concepts and relations to be covered in the ontology.

8.1 System

element

System

Element

Needs

Process utility data Data analysis Must allow analysis of data through a queries structure.

9.1 Support user Optionality Must allow partial use of its model in case that covers the information

use of its users.

9.2 Standardization Must acquire a certain level of standardization within the utility sector to

be effectively utilized


5.3.2 Ontology language

In order to allow the sharing, reuse and utilization of knowledge, ontologies are based upon ontology

languages. Ontology languages are defined as the formal languages that are used to encode an ontology

(Jakus, Milutinovic, Omerovic, & Tomazic, 2013). Ontology languages differ in the way they represent

knowledge (Corcho, Fernández-López, & Gómez-Pérez, 2002). Differences occur, for example, in the

way languages present attributes, taxonomies, relations, functions and axioms.

The Unified Modelling Language (UML) is the ontology language applied within this PDEng project. The

reason why this particular language was chosen, is because of its graphical notations for class modelling.

These graphical notations make the development of the ontology much more transparent and allows easier

communication of its content. It therefore, in literature (e.g. Cranefield, 2001), is often proposed as the

solution to bridge between software engineering and the semantic web and technologies.

A second reason to choose UML is the fact that is it also applied in similar digital utility modelling

standards. For example, both INSPIRE and CityGML UtilityNetwork ADE model their ontology in

UML. Developing the ontology within this PDEng project in UML, therefore, eases integration with and

/ or reuse of existing ontologies, i.e. digital modelling standards. More information about the assessment

of ontology languages is included in the report Designing an ontology. A proposed framework. This report

can be made available on request.

Figure 5 presents the UML notations as applied within the ontology development process following ISO

19103:2015. The figure presents the types of relations (association, aggregation, composition and

inheritance), the association cardinality (also called multiplicity) and its classes. A definition of these terms

can be found at the start of this report in ‘Terms and Definitions’, starting page V.

Figure 5 – UML notation (ISO 19103:2015 Geographic Information – Conceptual Schema Language)


UML knows multiple stereotypes. A stereotype can be defined as a metaclass that enables the modelling

of domain specific terminology or notation. In other words, stereotypes provides a categorization of UML

notations. Table 7 presents the stereotypes as applied within the domain ontology following the style used

in ISO 19103 and ISO 19109 for models of geographic information.

Table 7 – UML stereotypes applied in the domain ontology

Stereotype Model Element Explanation

ApplicationSchema Package Conceptual schema required by applications.

CodeList Class Value domain including a code for each permissible value.

DataType DataType Represent a set of properties without identity.

Enumeration Enumeration Data type whose numbers are enumeration literals.

FeatureType Class Represent a spatial object.

In addition to the stereotypes, attributes of the stereotypes are either described through other complex

types (i.e. other stereotypes) or through the values types as described in Table 8. The ‘date’ values follow

the Gregorian calendar with UTC as temporal reference system, following ISO 8601:2000. All units of

measure are expressed using the SI systems of unit, following ISO 1000:1992.

Table 8 – UML values types applied in the ontology

Value type Explanation

boolean Used for logical expression, consisting of the predefined values true and false.

date Describing the date in YYYY-MM-DD .

integer Integer values.

characterString Sequence of characters in set to display information.

measure Declared or measured quantity.

quantityExtent A range of integer values.

URI Uniform Resource Identifier used for identification.

To make all the above more explicit, an example of a (small) UML class model is provided in Figure 6.

This model is derived from the developed domain ontology. Four (FeatureType) classes, being ‘Network’,

RelatedParty’, ‘AbstractCommodity’, and ‘AbstractCommodityClassifier’ are shown, each at least

associated to one other class. For each association also its role is included, as well as its multiplicity. In this

example, a party is associated with a network, through the role ‘associatedNetwork’ and multiplicity of one

or many. This means a party is at least associated with one network, but may be associated to more. For

the ‘Network’ class also an aggregation is seen. In this example, an aggregation is used since a (sub)network

may exist of a network itself.

In addition to the relations, the stereotype and name are always shown at the top row of the class. The

middle row is used to describe the class’ attributes. Although not shown in the figure, a third row is

sometimes applied to model a constraint. The three colours as seen in Figure 6 are used for colour coding,

discussed in the next section.


Figure 6 – Example of a UML class model (from ‘Operations and Maintenance – Data specification’)

5.3.3 Build of the domain ontology

Even though the actual design of the domain ontology itself is not elaborated in this document, as

explained in section 1.4, I still would like to explain the rationale behind the choices made within the

ontology’s development process.

An ontology is a complex and multi-layered information source (Vrandecic, 2009). The following

components of an ontology exist:

Stereotypes (ApplicationSchema, Codelist, DataType, Enumeration, FeatureType)

Attributes

Attribute values (boolean, date, integer, characterString, measure, quantityExtent, URI)

Relations (association, aggregation, composition, inheritance)

Together, these components form the ontology’s (1) taxonomy and hierarchy, and (2) vocabulary, terms

and names (Gasevic, Djuric, & Devedzic, 2009). To prevent ambiguity and multi-interpretability of the

applied vocabulary, terms and names – i.e. semantic issues – definitions and explanations for all terms

and names were defined in a catalogue.

The build of the ontology revolves about the development of the three ontology elements within the

typology of Gasevic et al. (2009). To build the ontology, I distinguished its development process in two

phases: (1) development of the informal description and (2) development of the formal ontology. Both

these phases are explained below.

[1.] Informal description

The informal description of the ontology contains the model of the domain ontology in a textual and

descriptive manner. This means the ontology is not yet computer-interpretable. The informal description

forms the conceptual framework for the to-be formalized domain ontology and includes a textual

description of the outline of its taxonomy and vocabulary. In other words, the informal description of the

ontology describes the (information) domains covered within the ontology.


The before defined use cases and accompanying informal competency questions played a crucial role in

the development of the informal description. In order to answer these questions, I defined eight domains

that the ontology should cover. These domains were partially adapted from the CityGML UtilityNetwork

ADE digital modelling standard, whereas new domains were added to cover the domain of operations and

maintenance.

The informal description of the ontology includes the following eight domains and their main

characteristics:

[1.] Core and geometry

Defines the topographic model of the utility network

Defines the topological and functional model of the utility network

[2.] Functional characteristics

Defines the functional role of objects in the utility network

Defines the area the commodity is supplied to by the network

[3.] Network properties

Defines the commodity transported by the network as well as its characteristics

Defines the related organizations to the utility network

[4.] Network components

Defines the distribution components for transport and distribution of a commodity

Defines the functional components within the network

Defines the protective components relevant for the security of the network

[5.] Component properties

Defines the dimensional properties of utility network components

Defines the surrounding soil and groundwater properties of utility network components

Defines the material properties of utility network components

Defines the related organization to the utility network components

Provides extra information concerning identification of utility network components

[6.] Maintenance and operations properties

Defines the maintenance properties of utility network components

Defines the costs properties of utility network components

Defines the date properties of utility network components

[7.] Performance properties

Defines the performance properties of utility network components

Defines the environmental, social and economic impact of utility networks and their

components

[8.] Hollow space

Defines the free and occupied space of distribution and protective components

The eight domains do not include domains specifically oriented towards a single utility discipline.

Although debated, reason to not structure the domain ontology towards utility specific domains, is that

with the inclusion of the eight domains, still the discipline specific information can be modelled.

Therefore, more models would make the domain ontology unnecessarily complicated.

In addition to CityGML UtilityNetwork ADE conceptual schema, many new concepts and relations were

added within the context of operations and maintenance. Since the focus of the CityGML UtilityNetwork


ADE schema is different to that of the domain ontology in the PDEng report, it lacks information required

for operations and maintenance. For example, newly added concepts and relations to the CityGML

UtilityNetwork ADE are amongst others related to (1) related party, (2) performance, (3) dimensional, (4)

surrounding soil, (5) cost and (6) maintenance properties. Main addition to CityGML UtilityNetwork ADE

are the domains of ‘Maintenance and operations properties’ and ‘Performance properties’.

[2.] Formal description

The formal description of the domain ontology is the computer-interpretable translation of the informal

description. The domain ontology is developed in UML within the ontology development tool Enterprise

Architect. For each of the eight domains as defined within the informal description, a UML class model

was developed. These UML class models are included within the ‘Operations and Maintenance – Data

Specification’. In addition to the UML class models, this document does also contain an elaborate

explanation for each of the class models.

Reason to not model all eight domains within a single class model, is to keep the class model

understandable. Instead of having one big model, I found it to be more logic, understandable and clear to

have eight class models each covering a specific topic. This follows the approach of other digital modelling

standards such as INSPIRE, IMKL and the CityGML UtilityNetwork ADE. However, the eight class

models are still connected to each other. Therefore, it can be seen that within the ontology, the same class

is used within various of the eight models.

A design choice I made during the development of the ontology in UML, was to have abstract classes at

the top of the taxonomy, and detailed classes at the bottom. Since one of the requirements is to have a

modular and adaptable ontology, it should be relatively easy to alter the ontology in the future. Due to the

abstract classes at top of the taxonomy, the ontology allows removal and addition of classes without

changing the core of the class model.

Since the UML class models follow the eight domains as explained within the informal description, they

also are partially adapted from CityGML UtilityNetwork ADE. To make explicit what was copied from,

copied with alterations from or newly added to the CityGML UtilityNetwork ADE schema, I applied

colour coding as seen before in Figure 6 in the follow way:

Purple : copied from CityGML UtilityNetwork ADE version 0.9.2

Orange : copied with alterations from CityGML UtilityNetwork ADE version 0.9.2

White : newly added to CityGML UtilityNetwork ADE version 0.9.2

Alterations to the CityGML UtilityNetwork ADE classes include changes in the naming of the classes and

attributes, the addition of new attributes, and the removal of existing attributes. These alterations were

made to better fit the classes to the domain of operations and maintenance of utilities.

To illustrate both the use of the colour coding, as well as how the ontology looks like, the UML class

model for ‘Network Components’ is provided in Figure 7. Within this class model, it is, for example, seen

that the class ‘Bedding’ is copied, the class ‘AbstractDistributionComponent’ is copied with alterations,

and the class ‘WaterPipe’ is newly added. Figure 7 also shows the use of so called ‘Abstract’ classes. These

classes are used to provide some implementation, but do not allow instantiation. In other words, abstract

classes provide some basic implementation that is inherited by its subclasses. The abstract class is, thereby,

not considered as an instance, whereas its subclasses are.


Figure 7 – Network components UML class model (from ‘Operations and Maintenance – Data Specification’)


Figure 7 provides a good overview of how the ontology as a whole is modelled. In addition, the figure also

shows all stereotypes as applied within the ontology as a whole: data types, feature types, enumerations

and codelists. All types of relations can be recognized as well: association, aggregation, composition and

inheritance. For a complete overview of the domain ontology – including all eight class models and their

explanation – I refer to the ‘Operations and Maintenance – Data Specification’ document.

To explain all the terms and names as applied within the ontology and its UML class models, I developed

a feature catalogue. This catalogue contains the complete vocabulary of the ontology, providing a definition

and explanation for each term and name. More specific, I applied the reporting style for data types and

feature types as presented in Table 9. The applied reporting style for codelist and enumerations is

presented in Table 10.

Table 9 – Reporting style applied within Feature Catalogue for feature types and data types

Name

Name

Definition

Description

Stereotype

Name of spatial object type

Definition of spatial object type

Additional description of spatial object type

Stereotype of spatial object types (for example FeatureType)

Attribute:

Name

Value type

Definition

Multiplicity

Name of attribute

Value type of attribute (for example boolean)

Definition of attribute

Multiplicity of attribute (for example 0…1)

Association role:

Name

Class

Definition

Multiplicity

Name of association role

Associated class

Definition of association role

Multiplicity of association role (for example 0…1)

Table 10 – Reporting style applied within Feature Catalogue for codelist and enumerations

Name

Name

Definition

Description

Extensibility

Stereotype

Values

Name of codelist or enumeration

Definition of codelist or enumeration

Additional description for codelist or enumeration

Extensibility of codelist or enumeration by the user

<< Codelist >> or << Enumeration >>

Values within codelist or enumeration

The addition of the feature catalogue is necessary to cover the third element of an ontology: the semantics.

Without the feature catalogue, the linguistic meaning of the terms and names applied in the ontology can

be interpret differently by each individual user. The feature catalogues reduces this from happening, and

therefore, improves the system interoperability of utility data once modelled according to the domain

ontology. For a complete overview of the feature catalogue I refer to the ‘Operations and Maintenance –

Feature Catalogue’ document.


6 Treatment validation

This chapter elaborates on phase three of the engineering cycle, the treatment validation. Validation

assesses whether the ontology does contribute to the stakeholders goals, while meeting the requirements.

In other words, validation is done to assess whether the ontology is ready for implementation or still

requires refinement in its design (2014). Within this chapter, project objective 4 is covered.

To validate the domain ontology, I applied four validation techniques, being: (1) assessment against a

source of domain data, (2) check against class modelling rules, (3) assessment against expert panel input

and (4) assessment against competency questions. Within the following sections, I explain how each of

these techniques were applied in the PDEng project. By applying the four techniques, I was able to validate

all requirements within scope of the project, as shown before in Table 6 (page 31). This chapter concludes

with an overview of the gradual development of the ontology.

In addition to validation as described within this chapter, many (informal) meetings held during the entire

PDEng project supported the ontology development process. For an overview of these meetings as well

as their influence on the design of the ontology, I refer to Appendix II.

6.1 Validation techniques

This section elaborates on the validation techniques I applied within the PDEng project. For each of the

techniques, their purpose and outcome are explained. In addition, the number of iterations of, and

requirements treated by the technique are provided. I only refer to the requirements by their number,

following Table 6.

6.1.1 Assessment against source of domain data

Ontologies can be compared and evaluated with respect to other ontologies, knowledge bases and

classification models representing the same domain. Assessment of the domain ontology against a

comparable source of domain data can provide useful information about the relative quality of the

ontology (Obrst, Ceusters, Mani, Ray, & Smith, 2008). In the validation of the domain ontology, I

compared the domain ontology with (1) the domain data from practice (elicited from the qualitative case

study) and (2) comparable digital modelling standards.

Within the qualitative case study utility data was obtained from twelve utility owners, covering the

disciplines of water, gas, electricity, telecommunication and thermal. I received additional data for the

disciplines of water, gas and electricity – from the same Dutch engineering company as visited during the

qualitative case study – later on in the ontology development process. I compared the ontology’s concepts

and relations in a qualitative manner with those I recognized within the utility data from practice. As a

result, I was able to refine the ontology to the extent that it was capable of modelling the utility information

stored in the digital models from practice. The ontology was validated twice against the data from practice:

the first time against the original data from the case study, the second time against the newly acquired utility

data. Treated requirements mainly involved 3.3, 5.1 to 5.4, 7.1 and 7.4.

I also validated the ontology against comparable digital modelling standards, including INSPIRE,

CityGML UtilityNetwork ADE and IMKL. Since these standards are all modelled in UML, I could

compare the concepts and relations captured within those UML class models, with the ones of the domain


ontology. In addition, I analysed their vocabulary and accompanying glossary of terms and names. To this

end, it was validated whether the ontology could model utility data as modelled within comparable digital

modelling standards. The ontology was evaluated twice against the aforementioned standards: first time

for the first version of the ontology, the second time for the final version of the ontology. Treated

requirements mainly involved 3.3, 5.1 to 5.4, 7.3 and 7.4.

6.1.2 Check against class modelling rules

Class modelling rules are applied to perform a structural check on the domain ontology from a modelling

perspective. Within Enterprise Architect the domain ontology is evaluated on its hierarchy i.e. its

taxonomy, based on multiple UML class modelling rules. Enterprise Architect allows validation of the

UML class models based on the following four rules (Sparx Systems, 2017):

[1.] Well-formedness – Rules to check whether or not an element, relationship, feature or diagram is

well-formed, for example, whether the object is a valid UML item or whether a diagram contains

valid elements within it.

[2.] Element composition – Rules to check whether or not the UML element contains valid children,

whether it contains the right number of valid children, and whether or not the element is missing

any required children.

[3.] Property validity – Rules to check whether or not the element, relationship or feature has the

correct UML properties defined, and whether the properties contain incorrect of conflicting

values.

[4.] Custom properties – Rules to check an element, relationship or feature against any defined

constraint in OCL.

The ontology was validated after each new version against the class modelling rules, adding up to a total

of eight iterations. The final version of the ontology (version 4.1) did not show any errors when checked

on the UML class modelling rules. Treated requirement mainly involved 7.2.

6.1.3 Assessment against expert panel input

An expert panel was formed as a support group during the entire ontology development process. The

expert panel is a multi-disciplinary panel consisting of the CFM, information managers, the cadastre and

standardization establishments. In total two plenary expert panel sessions were held, complemented by

multiple individual sessions with experts. Both are explained in the subsequent paragraphs. Appendix V

provides the handouts developed for each of the plenary expert panel sessions.

Two plenary panel sessions were held. Whereas the first plenary session provided mainly input for

requirements engineering, purpose of the second session was explicitly to validate the ontology on its use

cases and accompanying competency questions. The session provided useful insights in which domain

knowledge – i.e. concepts and relations – was still missing within the domain ontology. In addition, the

representative from a standardization establishment gave useful advice regarding the use of association

roles and abstract classes in the UML class model. Based on the outcome of the second plenary session,

the ontology was refined accordingly. Treated requirements mainly involved 2.1, 3.1 to 3.3, 5.1 to 5.4,

6.2, 6.7 and 7.2 to 7.4.

Individual sessions were held with two standardization establishments (amongst others CityGML

UtilityNetwork ADE), an information manager and the client, the CFM. Aim of the individual expert

validation sessions was to validate the ontology more in-depth, by for example, validating a single UML


class model in detail. Excluding the sessions with the CFM, up to ten individual sessions were held, and

thereby, validation iterations. Outcomes of the individual sessions mainly involved small revisions on the

ontology’s concepts, relations, or vocabulary. To this end, the individual sessions provided a continuous

input during the entire ontology development process. Treated requirements mainly involved 2.1, 3.1 to

3.3, 5.1 to 5.4, 6.2, 6.3, 6.7, 7.1 to 7.4 and 9.1.

6.1.4 Assessment against competency questions

Competency questions are applied to validate whether the ontology can model the information that is

asked for. The ontology was validated three times against its competency questions. The first iteration took

place right after the establishment of the first version of the ontology. The second iteration was performed

during the second plenary expert panel session. Due to the fact that the ontology could not be validated

against all of its use cases and competency questions within that session, I validated the ontology once

more against the competency questions, i.e. the third iteration.

Outcomes of this validation measure mainly provided input on the coverage of the ontology’s concepts

and relations. In case a question could not be answered by the ontology, the ontology was refined

accordingly. Since competency questions were also used as a basis for the design, refinements as a result

of these validations were subtle. Treated requirements mainly involve 5.1 to 5.4.

Requirements missing in the aforementioned sections include number 4.3 (open-source and free of use),

6.5 (compliance with (spatial) asset management and GIS software) and 6.6 (visibility within online

repository). Concerning 4.3 and 6.6, the ontology has been made available an online repository (GitHub)

and is open source and free of use for everyone. Concerning 6.5, the next chapter shows a small proof of

concept of the ontology being modelled in GIS software.

6.2 Development of ontology

During the entire ontology development process, in total eight versions of the ontology were developed.

These versions were the result of the validation outcomes and subsequent refinements of the ontology.

To illustrate how the ontology evolved during its development process, I kept a changelog in which the

most important changes to the ontology were documented. Table 11 presents this changelog.

The changelog shows changes made within the ontology from the first version of the ontology, version 1.0,

to ultimately the final version of the ontology, version 4.1. All versions of the ontology can be made

available if requested. It should be acknowledged that this changelog only makes the most important

changes explicit. Subtle changes, such as rephrasing of a class name, are grouped together under one

header in the changelog.

Table 11 – Changelog of ontology development process

Version Change(s) made

4.1 - ‘MaterialValue’ values rephrased

- ‘Pipe’ and ‘Cable’ changed to ‘AbstractPipe’ and ‘AbstractCable added

- New subclasses for ‘AbstractPipe’ and ‘AbstractCable’

- Class names and attribute names rephrased

4.0 - ‘AbstractFunctionalComponent’ and its subclasses reframed

- Extra type values added for controller, storage, connection, measurement, terminal, other and complex

components

- ‘MaintenanceProperties’ reframed


- ‘ProtectiveShell’ and its subclasses reframed

- RelatedParty’ and its data types reframed

- Geometric primitives reframed

- Extra type values added for electrical, solid, liquid and gaseous commodities


3.2 - Attributes added to subclasses of ‘AbstractFunctionalComponent’

- ‘AbstractExtraInformation’ and its subclasses reframed


3.1 - Separate ‘Performance properties’ UML class model developed

- Separate ‘Maintenance and Operations’ UML class model developed


3.0 - ‘MaintenanceProperties’ reframed

- ‘NetworkClassValue’ values rephrased

- ‘StatusValue’ values rephrased

- New association roles added


2.1 - ‘PerformanceProperties’ and its subclasses reframed

- ‘MaintenanceProperties’ reframed


2.0 - ‘AbstractFunctionalComponent’ and its subclasses reframed

- ‘Depth’ class added

- ‘GroundWaterProperties’ class added


- Colour coding added

1.1 - Class names and attribute names rephrased

1.0 First version of the domain ontology

In addition to the changes made to the ontology itself, I also kept a changelog for the data specification

and feature catalogue as a whole. These changelogs can be found in the corresponding documents referred

to in section 1.4.


7 Treatment implementation

This chapter elaborates on phase four of the engineering cycle, the treatment implementation. Treatment

implementation is defined as the application of the treatment to the original problem context (Wieringa,

2014). Therefore, within the context of this project, implementation means the actual utilization of the

domain ontology in (spatial) asset management and GIS software. Within this chapter, project objective 5

is covered.

Within the PDEng project, implementation is limited to a small proof of concept. Full scale

implementation has not been part of the PDEng project, and therefore, has not been conducted. In the

first section, I provide a brief outline on how the domain ontology was implemented. In the second section,

I refer to the online repository where all documentation and files of the ontology can be found.

7.1 Proof of concept

This section provides an outline on how the domain ontology was implemented within the PDEng project.

First, I explain the application domain of the ontology. Second, I elaborate on the preparations I

performed to make the domain ontology interpretable by (spatial) asset management software and GIS.

Third, I explain how the ontology can be implemented by elaborating on a small proof of concept.

7.1.1 Application domain

The targeted use of the domain ontology lies in (spatial) asset management and GIS software. The domain

ontology is applicable on multiple utility disciplines, being: (1) electricity, (2) oil, (3) gas, (4) chemicals, (5)

sewage, (6) water, (7) thermal and (8) telecommunication. The use of the domain ontology has no

geographic boundary, but is based on utility networks of developed countries.

Asset management software and GIS can also be referred to as an application. Following ISO 19101-

1:2014, an application is defined as software used to manipulate and process data in support of user

requirements. Use and implementation of the domain ontology within such applications has the potential

to:

facilitate the transfer between format and shape standardized formats within utility models.

support smarter reasoning within utility models.

Support of smarter reasoning is especially beneficiary to the end-user, recognized as utility owners, utility

operators and contractors. Once accepted and shared, a domain ontology – i.e. a digital modelling

standard – allows optimization of an application that is fully compatible with this standard. To this end,

the ontology can enable digital maintenance practices, and even the creation of cyber-physical systems.

7.1.2 Preparation

The domain ontology is developed within the software Enterprise Architect as a UML class model.

However, a UML class model is not directly interpretable by (spatial) asset management and GIS software.

Therefore, I converted the class models to an XML (Extensive Markup Language) schema file. XML is a

widely adopted standard language for exchanging information (Bray, Paoli, Sperberg-McQueen, & Maler,

2008). In order to translate the UML class models of the domain ontology towards the XML schema file,

I executed the following steps:


[1.] Defining configuration file:

The XML schema file can be automatically generated from Enterprise Architect through

the software ShapeChange. However, in order to generate the XML file, ShapeChange

had to be configured first through a configuration file written in Java. This configuration

file was available from the CityGML UtilityNetwork ADE online repository (Kutzner,

2018). Through a few modifications, I was able to make the configuration file work with

the UML class models of the domain ontology.

[2.] Generation of XML file from UML of Enterprise Architect:

By running the configuration file, an XML schema file of the UML class models within

Enterprise Architect was generated. In addition, an XML file for each of the codelist of

the domain ontology was created. Having the codelists in human interpretable code,

allows manual adjustment of its values.

Whereas the XML schema file contains the domain ontology in code, it does not contain any utility data

yet. To store utility data in the domain ontology’s format, I mapped utility data to the XML schema file

within the software FME. This required the following step to be executed:

[1.] Mapping utility data to XML schema file:

In order to map utility data to the XML schema file, first the feature types of the domain

ontology were imported in the FME workspace. This allows mapping of the utility data

towards the feature types as depicted in the domain ontology. The feature types were

imported via an XML definition file I developed, including all feature types of the domain

ontology. I used an FME workspace from the CityGML UtilityNetwork ADE (den Duijn,

2018) as a basis, and adjusted it accordingly to make it work with the XML schema file.

7.1.3 Implementation and use

The created workspace in FME allows mapping of utility data according to the domain ontology’s format.

Once the mapping in FME was done, I ran the workspace to write a set of sewage data towards a

Geography Markup Language (GML) file. The GML format is introduced by the OGC and capable of

representing spatial information. In addition, GML is widely supported by GIS software.

To this end, I read the GML file in the open source GIS software QGIS. Figure 8 shows a snapshot of

QGIS in which the modelled sewer pipes are highlighted. On the right side of the figure, QGIS provides

a table including the attributes of the object at hand, i.e. the sewer pipe. In the figure, the attributes

‘cathodic protection’ and ‘pressure grade’ are seen, which are also attributes of a sewer pipe within the

domain ontology.

Ultimately, this small test shows that the domain ontology can be incorporated in (spatial) asset

management and GIS software. Therefore, the created GML file acts as a proof of concept. It shows that

the code derived from the domain ontology – the XML schema file – is structurally sound.


Figure 8 – Utility data modelled according to the domain ontology’s format in QGIS

However, further implementation of the domain ontology requires the mapping of the remaining feature

types in the FME workspace. The feature types can be imported through the feature type definition file,

available at the online repository of the domain ontology (as shown in next section). Once all feature types

are mapped, one can map utility data towards a GML file following the domain ontology’s format.

7.2 Online repository

For the developed domain ontology to be successful, it has to be accepted and shared within the utility

sector. A first step to acquire this is to make the domain ontology available. To this end, an online GitHub

repository is created to make all the documentation and data of the domain ontology available:


The documentation includes the data specification and feature Catalogue of the domain ontology. In

addition to the documentation, the repository includes the following:

[1.] The UML class model of the domain ontology created within Enterprise Architect:

The .eap file (Enterprise Architect file) containing the UML class model.

The UML class models in in PDF.

[2.] The XML schema file of the domain ontology directly derived from the UML class model using

the software ShapeChange:

The file containing the XML schema file.

Codelist dictionary in .xml accessible for alterations.

[3.] The ShapeChange configuration file to derive the XML schema file and code lists dictionaries:

For further use of the software it is referred to http://shapechange.net/.

[4.] The FME feature types definition file.


http://shapechange.net/

Section 3 – Concluding words 47

8 Discussion

The utility sector is characterized by its widespread in utility modelling practices. Utility owners apply

standards from the international, national and organizational level to model their utility data for operations

and maintenance related activities. As a consequence, the modelled domain knowledge differs on its

regional coverage and its ontological aspects taxonomy, vocabulary and semantics. Experiencing the lack

of a standard for operations and maintenance related activities herself, the client within the PDEng project,

the CFM, opted for the development of a shared and accepted digital modelling standard. To this end, I

developed a domain ontology for the domain of operations and maintenance.

An ontology is a complex and multi-layered information source making its development process rather

difficult. Within the project, I acknowledged that perceptions of human beings – including the modellers

of the ontology – are incomplete and bounded by rationality, resulting in various viewpoints (Olde

Scholtenhuis & Hartmann, 2015). As a consequence, an ontology is always at best a partial understanding

of the world (Turk, 2001). Therefore, for the ontology to be successful it is crucial to create a shared and

accepted set of conceptualization about the domain of utilities’ operations and maintenance. Acquiring

this shared and accepted set of conceptualizations was accomplished through active end-user engagement.

Whereas in the development of comparable standards often a top-down approach is applied to formulate

the concepts and relations, within the PDEng project a mixed approach of both a bottom-up and a top-

down approach was applied. I perceive active end-user engagement as a key driver for the establishment

of a shared and accepted set of conceptualizations about the domain.

One of the means applied to incorporate this principle of end-user engagement, involved the qualitative

case study on utility modelling practices. However, this qualitative case study also had its limitations. The

source of domain data acquired was relatively small and only focused on the Dutch utility sector.

Therefore, the data may not be fully representative for the full utilities’ industry world-wide, although it

still managed to cover utility data from a very high level of detail. Detailed information from water, gas,

electricity, telecommunication and thermal utility networks was acquired and in-depth and tacit knowledge

about the domain of operations and maintenance was retrieved.

Reflecting upon the engineering cycle, the domain ontology has not been fully implemented within the

application domain. Reason is mainly that implementation is a very time-consuming process and did not

fit within the time available for the PDEng project. As a consequence, the last part of the engineering

cycle - treatment evaluation – has not been assessed within the PDEng project. The use of formal

competency questions as a means of validation was, therefore, also not applied within the project. For

proper validation of the domain ontology’s structural soundness, validation based on these formal

measures is important to conduct within future studies.

Continuing on validation, various requirements could not be measured and, therefore, validated during

the PDEng project. These requirements include the required improved effectivity and efficiency of

operations and maintenance, reduced deterioration and damages to utilities, reduced life-cycle costs of

utilities, computational efficiency, ability to run queries, and effective utilization of the ontology throughout

the utility sector. Reason is that these requirements mainly require the ontology to be implemented,

whereas, as explained, full-scale implementation of the ontology in its application domain did not take

place within the PDEng project. Further studies should elaborate on the treatment validation of the

ontology and its assessment against aforementioned requirements.

A final point of discussion concerns the actual adoption of the ontology within the utility sector.

Momentarily the domain ontology is developed in a rather small environment. Drawing upon

Timmermans and Epstein (2010), a standard is only successful once it is shared and accepted within its

community. Otherwise, a standard may end up in the already existing ‘world of standards, but not a

standard world’. However, adoption of the domain ontology may be a rather difficult process. Hesitation


and resistance to use the model may occur. Utility owners and other end-user are presumable not willing

to alter their complete routine of utility modelling practices. Drawing upon Geels (2004), the existing socio-

technical regime prevents the domain ontology as an innovation to be directly introduced.

To break this existing regime, time is required. Because of its low initial adoption, the ontology will not

directly be capable of prevailing over existing digital modelling standards. A gradual development of its

social network, in the form of end-users, software developers and possibly other standardization

establishments, is important in its adoption process. This adoption process could be sped up in case a

particular window of opportunity appears to break the socio-technical regime. Such a window of

opportunity may come from new mandatory legislation, but also from new ideas on the assessment of

lifecycle management on subsurface utilities.


9 Conclusions and recommendations

This chapter elaborates on the conclusions and recommendations. In the conclusions, I also refer back

to the PDEng assessment criteria. Within the recommendations, I specify recommendations for both

further development and further adoption of the domain ontology.

9.1 Conclusions

As a utility owner and operator, the CFM – client within the PDEng project – is responsible for the

installation, operations and maintenance of her utilities. Consequently, the CFM wants to be able to rely

on uniform and consistent digital information about these utilities. This is also recognized within the utility

sector as a whole. Due to the sector shifting towards a more lifecycle oriented management approach,

utility owners increasingly want to have a comprehensive set of digital information about their utilities.

Problem however, and thereby the starting point of the PDEng project, is that the utility sector currently

lacks a digital modelling standard with the emphasis on lifecycle management, i.e. operations and

maintenance. Therefore, it was found that within the utility sector a plethora of utility modelling practices

to model domain knowledge exists. The modelling practices describe utility concepts using different (1)

attributes, formats, relations and (2) semantic terms. Altogether, the lack of a digital modelling standard –

i.e. domain ontology – leads to confusion and misunderstandings when exchanging data during the

preparation and execution of utility works.

Main goal during the two-year course of the PDEng project has been the development of a domain

ontology that does include those concepts and relations required within operations and maintenance

related activities. This domain ontology offers the CFM – and utility owners, utility operators and

contractors in general – a structure alongside they can store their utility asset information to utilize it for

installation, operations and maintenance purposes. The ontology can enable digital maintenance practices,

and possibly even the creation of cyber-physical systems. The ontology has been documented in three

documents:

[1.] Operations and Maintenance – Data Specification

[2.] Operations and Maintenance – Feature Catalogue

[3.] Operations and Maintenance – Overview of class models in UML

The data specification provides the UML class models of the domain ontology, together with a detailed

description of the class models and domain ontology as a whole. The feature catalogue provides the

complete overview of all the terms and names included in the vocabulary, with for each of these a definition

and explanation. This overcomes semantic issues such as ambiguity and multi-interpretability of terms and

names. The overview of class models in UML is for those only requiring the sole class models of the

domain ontology.

Within this conclusion I would also like to refer back to the criteria of interest to the PDEng design

product and design process, starting with the design product:

Construction: Concerning the structure of the ontology itself as well as the structure of the documentation,

it follows the structure as applied in comparable digital modelling standards, in specific CityGML


UtilityNetwork ADE. Therefore, the structure is easily recognizable by it users. In addition, the ontology

is split up in eight models with clear and explained interfaces between them. The decision to have separate

documents for both the product and the process also supports the clarity and clear structure of the work.

The inventivity of the ontology in the utility sector is relatively high. No other digital modelling standard

within the domain of operations and maintenance of utilities exists. This also justifies the development of

the domain ontology within the PDEng project. Concerning convincingness, it was proven in the validation

of the ontology that it is capable of fulfilling to the information need of its users – in specific, the CFM –

by, for example, answering to an extensive list of competency questions.

Realisability: Although the ontology may at this point in time be relatively hard to model into asset

management software, I was able to do a small proof of concept. In addition, it is explained in this

document how the ontology can be implemented. For future adoption, it is recommended that software

developers build the ontology as a data layer within existing (spatial) asset management and GIS software.

However, before this to happen, the utility sector should start adopting the model. The more organizations

that use the domain ontology, the more likely that software developers will consider integration of the

ontology in their software. In section 9.2, I provide recommendations to facilitate the uptake of the

ontology in the utility sector. The economic realisability, on the other hand, is very high, since the ontology

is open source and, therefore, economic feasible to everyone interested.

Functionality: The domain ontology is able to model the information need of its end-users – in specific

the CFM –, satisfying the ontology’s main requirement. Through active end-user engagement, the ontology

was developed based on a shared and accepted set of conceptualizations about the domain of operations

and maintenance. However, eight requirements could not be met, since these required full-scale

implementation of the ontology, being out of the project scope. Working routines in asset management

and GIS related software can still remain the same, since the ontology can be modelled as the layer existing

standards are linked to. Concerning its reusability, the ontology is applicable to utility networks of

developed countries and does allow modelling of extensive sets of utility data. In addition, the ontology is

based on a modular design, thereby allowing future developments and adaptations – such as the emerge

of a new utility infrastructure type – without having to change its core structure.

Impact: The ontology does support lifecycle management of utilities. Due to having a more uniform and

consistent overview of their utilities, users may more effectively and efficiently operate and maintain their

utilities. Risks to the user by using the ontology do not exist, although the conversion from existing and

applied utility modelling standards to the use of the domain ontology may require manual labour. This

may make this conversion process prone to faults and errors.

Presentation: In total four reports were written, including this PDEng report, the data specification, the

feature catalogue, and the sole overview of the eight class models of the domain ontology. The correctness

of the information as described within these documents is validated by various measures as reported in

this document.

The following conclusions can be made regarding the criteria concerning the design process:

Organization and planning: For the qualifier of the PDEng a proposal was made including a detailed

planning, containing of milestones, specifications and activities during the project. Due to changes and

new insight within the project environments, the planning was slightly altered during the course of the

PDEng project. Especially since development of an ontology is necessarily and iterative process, it was


decided to have a deadline for its final version. In addition, meetings were planned in a weekly to monthly

fashion with the CFM and supervisors of the University of Twente. The meetings were, above all,

conducted when necessary. During the meetings, I always took care of the preparations and agenda.

Problem analysis and solution: The design strategy I applied within the PDEng project is the engineering

cycle of Wieringa (2014). Following the engineering cycle, I executed the phases of problem investigation,

treatment design, treatment validation and treatment implementation. I investigated the problem through

the means of a stakeholder analysis, a qualitative case study, a literature review, a document study and the

inclusion of an expert panel. In order to design the ontology, I first established an ontology design method

through an in-depth study of the ontology development process. Various ontology development methods,

tools and languages were considered. Ultimately, the ontology development method was coupled to the

engineering cycle of Wieringa to make the entire design process clear and consistent. Principles applied

to develop the ontology include active end-user engagement in combination with a mix of a bottom-up

and top-down approach. Eventually, the domain ontology was validated. Thereby, it was shown that the

ontology met its requirements (except for those related to implementation). Even more, a small proof of

concept of the ontology within its application domain was performed. In terms of impact of the solution,

the impact of the ontology, especially in socio-technical terms, is high. Within the utility sector, utility

owners, operators and contracts are digitizing utility data according to their own utility modelling practices

(organizational standards). A change in the utility modelling regime may be seen as a radical innovation,

though in the end will reduce interoperability issues. In addition, smarter reasoning in utility models

through analysis software is made possible. Even more, all IT used in the field can be based upon the

domain ontology, improving interoperability even on a higher scale.

Communication and social skills: In total four reports were written, being (1) the PDEng report, (2) the

data specification of the domain ontology, (3) the feature catalogue for the domain ontology, (4) and the

overview of UML class models. The documents are split up to have publishable documents for the

ontology. The data specification, feature catalogue and overview of class models specifically focus on the

product. The PDEng report specifically focuses on the process. In addition to the reports written, I also

actively communicated with the CFM, but also the experts involved, to keep them updated but also to

discuss about the progress within the project. All meetings were written down in a logbook, enclosed to

this report in Appendix II. To extent the outreach of the project, various presentations were given, for

example at the ARCOM conference and the ZoARG symposium.

Structure and attitude: Concerning structure, multiple documents were developed, as explained before,

Whereas the publishable documents – the data specification, feature catalogue, and overview of UML

class models – are for external use, the PDEng report itself is for internal use. Concerning my own attitude,

which is possibly rather subjective, I have been rather critical and self-reflective at my work, but also other’s.

With other work, for example, comparable digital modelling standards but also feedback from experts is

meant. I tried to keep my personal opinion throughout the whole development process, though I also

accepted that experts are generally more knowledgeable in the field. Therefore, a healthy balance between

one the one hand accepting other’s opinions and feedback and on the other hand my own opinion was

maintained.

I have to acknowledge that I perceived these criteria from my point of view. Other opinions may exist.


9.2 Recommendations

Several recommendations can be made according to the developed domain ontology. Recommendations

are, thereby, divided into recommendations for further (1) development of the domain ontology and (2)

adoption of the domain ontology:

[1.] Further development:

Implementation (evaluation): The ontology has not been fully implemented in (spatial) asset management

and GIS software. The proof of concept should be extended towards a complete workspace in FME,

capable of mapping utility data to the whole domain ontology. Implementation also allows evaluation of

the ontology through formal competency questions (queries). These queries can perform sophisticated

geospatial analysis of the utility networks to validate the ontology against its use cases.

[2.] Further adoption:

Sector-wide coverage: The domain ontology may also be applied to IT used in the field, such as the ground

penetrating radar (GPR) and sensors. Once all IT stores and registers utility data according to the same

format, one can, for example, start to automate digital maintenance practices This could even lead to the

creation of cyber-physical systems. Future studies should elaborate on how IT can be directly integrated

with the domain ontology. Overall, this will improve system interoperability of utility data on a sector-wide

scale.

Integration within applications: Integration of the domain ontology within applications allows for easier

utilization of the ontology. This is similar to the use of IFC in applications such as AutoDesk Revit.

Possibly, the domain ontology could then be integrated as a foundational layer, which is linked to the

utility owner’s data set through the principle of linked data. However, as mentioned within the conclusions,

first the utility sector should start adopting the domain ontology. The more organizations that use the

domain ontology, the more likely that software developers will consider integration of the ontology in their

software.

Speed up adoption: Adoption requires time. To speed up adoption, extending the outreach of the domain

ontology is recommended. This can be realized through pitching the ontology’s potential by, for example,

distributing flyers, presenting at congresses, symposia, or conferences, and writing an article in magazine.

In addition, one can directly inform the end-user, such as utility owners and operators, by simply

contacting them. Especially once the domain ontology is successfully implemented in (spatial) asset

management and GIS software (referring to the recommendation about further development), it is

recommended to show by a demo how the ontology works and what its capabilities are.

In addition to the aforementioned recommendations, I also wrote two brief research assignments for either

a Bachelor or Master thesis. These research assignments touch upon the recommendations for further

development and adoption and can be found in Appendix VI.

Lastly, continuing on adoption of the ontology, I was invited by the developers of CityGML UtilityNetwork

ADE to present the domain ontology at their workshop. Unfortunately, no date has been set yet for this

workshop to take place. However, presenting the ontology at such an international stage may possibly

facilitate the uptake of the ontology.

PDEng – Final Report 53

10 Bibliography

Alexander, I. F. (2005). A Taxonomy of Stakeholders. International Journal of Technology and Human

Interaction, 1(1), 23-59.

American Society of Civil Engineers. (2002). Standard guideline for the collection and depiction of

existing subsurface utility data (38-02). American Society of Civil Engineers.

Blanchard, B., & Fabrycky, W. (2014). Systems Engineering and Analysis (5th ed.). Harlow (UK):

Pearson Education Limited.

Bowker, G., & Star, S. (1999). Sorting Things Out. Cambridge: MA: MIT Press.

Bradley, A., Li, H., Lark, R., & Dunn, S. (2016). BIM for infrastructure: An overall review and

constructor perspective. Automation in Construction, 71, 139-152.

Bray, T., Paoli, J., Sperberg-McQueen, C., & Maler, E. (2008). Extensible Markup Language (XML) 1.0

(Fifth ed.). W3C Recommendation. Retrieved from https://www.w3.org/TR/REC-xml/

British Standards Institution. (2014). PAS 128:2014 Specification for underground utility detection,

verification and location. BSI Standards Limited.

CityGML. (2016). CityGML UtilityNetwork ADE. Retrieved from

http://www.citygmlwiki.org/index.php/CityGML_UtilityNetworkADE

Corcho, O., Fernández-López, M., & Gómez-Pérez, A. (2002). Methodologies, tools and languages for

building ontologies. Where is their meeting point? Data and Knowledge Engineering, 46(1), 41-

64.

den Duijn, X. (2018). CityGML-UtiltiyNetwork-ADE. Retrieved from GitHub:

https://github.com/XanderdenDuijn/CityGML-Utility-Network-ADE

El-Diraby, T. E., & Osman, H. (2011). A domain ontology for construction concepts in urban

infrastructure products. Automation in Construction, 20(2011), 1120-1132.

European Commission. (s.d.). INSPIRE DIRECTIVE. Retrieved May 20, 2017, from INSPIRE:

http://inspire.ec.europa.eu/webarchive/

Fernández-López, M., Gómez-Pérez, A., Sierra, J., & Sierra, A. (1999). Building a chemical ontology

using Methondology and the Ontology Design Environment. IEEE Intelligent Systems, 14(1),

37-46.

Gangemi, A., Catenacci, C., Ciaramita, M., & Lehmann, J. (2005). Ontology evaluation and validation:

An integrated formal model for the quality diagnostic task. Rome, Italy: Laboratory of Applied

Ontologies - CNR.

Gasevic, D., Djuric, D., & Devedzic, V. (2009). Model Driven Engineering and Ontology Development.

New York: Springer.


Geels, F. W. (2004). From sectoral systems of innovation to socio-technical systems: insights about

dynamics and change from sociology and institutional theory. Research Policy, 33(6), 897-920.

Geonovum. (2017). IMKL2015 - Dataspecificatie Utiliteitsnetten version 1.2.

Gómez-Pérez, A. (2004). In S. Staab, & R. Studer, Handbook on Ontologies in Information Systems,

First Edition (pp. 251-274). Berlin, Germany: Springer.

Gruber, T. R. (1995). Towards principles for the design of ontologies used for knowledge sharing.

International Journal of Human-Computer Studies, 43(5), 907-928.

Grüninger, M., & Fox, M. S. (1995). Methodology for the design and evaluation of ontologies. Montreal.

Howard, R., & Björk, B. (2008). Building Information Modelling - Experts views on standardisation and

industry deployment. Advanced Engineering Informatics, 22(2), 271-280.

INCOSE. (2015). Guide for writing requirements: summary sheet. San Diego (CA), USA.

INSPIRE. (2013). D2.8.III.6 Data Specification on Utility and Government Services - Technical

Guidelines. European Commission Joint Research Centre.

Jakus, G., Milutinovic, V., Omerovic, S., & Tomazic, S. (2013). Concepts, Ontologies, and Knowledge

Representation. New York: Springer.

Kutzner, T. (2018). CityGML-UtilityNetwork-ADE. Retrieved from GitHub:

https://github.com/TatjanaKutzner/CityGML-UtilityNetwork-ADE

Noy, N., & McGuinnes, D. (2001). Ontology Development 101: A Guide to Creating Your First

Ontology. Stanford University, Knowledge Systems Laboratory, Stanford, CA.

Obrst, L., Ceusters, W., Mani, I., Ray, S., & Smith, B. (2008). The evaluation of ontologies. In C. J.

Baker, & K. Cheung, Revolutionizing Knowledge Discovery in the Life Sciences (pp. 139-158).

Berlin: Springer.

Olde Scholtenhuis, L. L., & Hartmann, T. (2015). Fieldwork-Based Method for End-User Engagement

in Domain Ontology Development. In R. Issa, & I. Mutis (Eds.), Ontology in the AEC industry:

Decade of Research and Development in Architecture, Engineering and Construction. Reston,

Virginia, USA: American Society of Civil Engineers (ASCE). doi:ISBN: 978-0-7844-1390-6

Pauwels, P., Zhang, S., & Lee, Y. (2017). Semantic web technologies in AEC industry: A literature

overview. Automation in Construction, 73(2017), 145-165.

Pinto, H., Tempich, C., & Staab, S. (2009). Ontology Engineering and Evolution in a Distributed World

Using DILIGENT. In S. Staab, & R. Studer, Handbook on Ontologies (pp. 153-176). Berlin:

Springer.

Saldaña, J. (2015). The Coding Manual for Qualitative Researchers. London: Sage.

Singapore Land Authority. (2017). Standard and Speficiations for Utility Survey in Singapore. Singapore

Land Authority.

Sparx Systems. (2017). Model Validation.


Staab, S., & Studer, R. (2009). Handbook on Ontologies (2nd edition ed.). Berlin: Springer.

Studer, R., Benjamins, R., & Fensel, D. (1998). Knowledge Engineering: Principles and methods. Data

& Knowledge Engineering, 25(1), 161-197.

Sure, Y., & Studer, R. (2002). On-To-Knowledge Methodology - Final version. Institue AIFB.

Karlsruhe: University of Karlsruhe.

Sure, Y., Staab, S., & Studer, R. (2009). Ontology Engineering Methodology. In S. Staab, & R. Studer,

Handbook on Ontologies (pp. 135-152). Berlin: Springer.

Tempich, C. (2006). Ontology Engineering and Routing in Distributed Knowledge Management

Applications. Karlsruhe: Karlsruhe University.

ter Huurne, R., & olde Scholtenhuis, L. (2018). Digitization for integration: fragmented realities in the

utility sector. ARCOM, (pp. 93-100). Belfast, UK.

Timmermans, S., & Epstein, S. (2010). A world of standards, but not a standard world: Toward a

sociology of standards and standardization. Annual Review of Sociology, 36, 69-89.

Turk, Z. (2001). Phenomenologial foundations of conceptual product modelling in architecture,

engineering and construction. Artificial Intelligence in Engineering, 2(15), 83-92.

Vrandecic, D. (2009). Ontology Evaluation. In S. Staab, & R. Studer, Handbook on Ontologies (pp.

293-313). Berlin: Springer.

Wieringa, R. J. (2014). Design Science Methodology. Springer.

Yin, R. K. (1989). Case study research, design and methods (Vol. 5). SAGE Publications.

ZoARG. (2018). ZoARG | ReDUCE. Retrieved from ZoARG: http://www.zoarg.com/zoarg-reduce-eng/


Appendix I – Overview of educational activities

Professional development courses

Course type Course name Course code ECTS Period/date followed Finished Grade

Professional development

course

Creative Thinking - 0,5 18-05-2017 Yes V


course

Professional Effectiveness - 2 01-10-2018 – 11-12-2018 Yes V


course

Storytelling and Media

Training

- 0,5 01-12-2017 Yes V


course

Technical Writing and

Editing

- 2 08-05-2017 – 12-05-2017 Yes V


course

Write to Publicize - 1 14-11-2016 – 19-12-2016 Yes V

Total 6

Compulsory courses


Compulsory course Building Information

Modelling and 5D

Planning

201400012 7,5 Quartile 2A 2016-2017 Yes 9

Compulsory course CS Construction

Management and

Engineering

200900128 7,5 Quartile 1A 2018-2019 Yes 8

Compulsory course Design Methodology 201400412 7,5 Quartile 2A 2017-2018 Yes 8

Compulsory course System Engineering for

PDEng

201400313 7,5 Quartile 1A 2017-2018 Yes 8

Total 30


Elective courses


Elective course Brand Management 201700019 5 Quartile 1A 2017-2018 Yes 8

Elective course Design for Maintenance

Operations

201500235 5 Quartile 2A 2017-2018 Yes 8

Elective course Product Life Cycle

Management

192850750 5 Quartile 2A 2016-2017 Yes 9

Total 15

Additional courses


Additional course Conference 201600191 5 Quartile 1A 2018-2019 Yes 8


Appendix II – Overview of meetings

Person/organization Function Date/period Activity Goal Result Influence on design

Campus and Facility

Management University

of Twente

Ray Klumpert

Alexander van

Duursen

André de Brouwer

All three are involved in

the management of the

utilities on the campus of

the university.

Oct 2016 – now Progress meeting. Align expectations from

the Campus and Facility

Management with project

progress.

Wishes from and

possibilities for the

Campus and Facility

Management have

become clearer.

Contiguous

improvements on the

design. Great

contribution to the

functional requirements.


Léon Olde Scholtenhuis

André Dorée

Supervisors from the

University of Twente.

Oct 2016 – now Progress meeting. Align expectations from

the University of Twente

with project progress.

Alignment to project

goals as expected by the


Continuous

improvements on the

design. Ensured

alignment to the PDEng

design process and

design product criteria.

Nationaal Kabel- en

Leidingcongres

Congress to discuss the

latest developments

within the excavation

scene.

2 November 2016 Attending congress. Getting familiar with the

latest developments in

the excavation scene, and

see how these can help

me in my own PDEng

project.

New insights in especially

rules and legislation was

obtained. Both the new

IMKL2015 and

CROW500 were

presented.

Familiarity with the

IMKL2015 and

concepts, relations and

attributes of interest to

the domain ontology.

Cadaster

Fuat Akdeniz

Product and process

manager, frontrunner

KLIC-WIN.

20 January 2017 Progress meeting. Becoming familiar with

new IMKL, identifying

importance of

IMKL2015 for the

project.

Access granted to the

IMKL2015 data

repository, Cadaster

acquainted with the

project.

Familiarity with the

IMKL2015 and


attributes of interest to

the domain ontology.

Recognize

Tom Knol

Daniel Khiati

Software developers. Jan – March 2017 Developing shapefiles

for the app ‘Spying The

Underground’ for the


Have a Spying the

Underground version for

the University of Twente.

A beta version of the

Spying the Underground

app is currently available.

No influence on the

design. Project was not

connected with the

PDEng project.


Siers Infraconsult

Harry Moek (director)

Jochen Tulp

Multiple employees

Involved in the

management and

registration of utility data

of multiple utility owners.

March – April 2017 Observation of the utility

data registration in

practice.

Identify how utility data

currently is registered in

practice.

A report has been written

in which the observations

and their findings are

provided, providing

direct input for the

project.

High influence on the

design. Provided insight

in the information need

from the end-user.

Directly influence on the


attributes captured in the

ontology. Uses as a basis

for the taxonomy and

vocabulary.

Delft University of

Technology

Xander den Duijn

Master graduate at the

Delft University of

Technology involved in

utility data modelling for

the municipality of

Rotterdam.

25 April 2017 First meeting. Identify how each other’s

project could contribute

to the other.

An overlap in utility

modelling was seen.

Eventually only little

influence on the design.

Work what directly

based on CityGML

UtilityNetwork ADE and

did not add anything

new.

Technical University of

Munich

Tatjana Kürzer

Member of the group

developing the CityGML

UtilityNetworkADE,

specialized in modelling

within FME.

22 May – 24 May 2017 Workshop followed on

how to model CityGML

UtilityNetworkADE in

the program FME.

Become familiar with

CityGML

UtilityNetworkADE and

the software FME.

Being able to model

utility data according to

the CityGML

UtilityNetworkADE

framework.

Moderate influence on

the design. Workshop

gave insights in how to

model XML schema files

and shapefiles through

FME.

Delft University of

Technology

Sisi Zlatanova

Associate professor at the

Delft University of

Technology, specialized

in 3D Geoinformation.

11 September 2017 First meeting. Discuss the aim of the

comparison between

state-of-the-art standards

from literature and data

structures used in

practice.

Goal and structure of the

report that is worked on

became more clear.

Possible interfaces with

other projects/persons

were identified.

High influence.

Assessment of utility

modelling practices and

standards helped in

getting a clear view on

how the domain ontology

should be structured. In

addition, it was made

explicit wat was still

missing in existing

practices and

standardization.


Siers Infraconsult

Harry Moek (director)

Jochen Tulp

Multiple employees

Involved in the

management and

registration of utility data

of multiple utility owners.

28 September 2017 Presentation of result

obtained during the study

performed at Siers

Infraconsultancy.

Inform about the

conclusions that were

made based on the data

obtained during the study

performed at Siers

Infraconsultancy.

Discuss possible future

steps to be made.

Contacts obtained from

several utility owners, to

extent the dataset.

Meeting only moderate

influence, but the

research itself had a high

influence as explained

before.


Munich

Tatjana Kürzer

Member of the group


UtilityNetworkADE,


within FME.

4 October 2017 Follow up from

workshop followed in

Munich.

Discuss the possible

collaboration between

my project and the work

of the CityGML Group.

My project can help

CityGML Utility

Network ADE by

providing data from the

end-user. Even more, it

can extent the Utility

Network ADE. A first

draft idea/model will be

discussed in a next

meeting.

High influence on

design. First proposal to

connect the domain

ontology to CityGML

UtilityNetwork ADE and

how they could enforce

each other.

ZoARG Symposium ZoARG (or ReDUCE) is

an initiative that aims to

improve design,

construction, installation,

and maintenance of

buried infrastructure in

shallow subsurface.

19 October 2017 Symposium organized by

the ZoARG group of the


Inform the attendees

about the current project

within the ZoARG

group, as well as giving a

more general awareness

of all that has to do with

the utilities.

Several people interested

in following the project.

A mail will be send

around to ask people if

they want to participate in

the expert panel.

Moderate influence. A

small workshop was

organized in which the

participants wrote down

what must be included in

the ontology in terms of

information. Types of

information collected

was very widespread

though and fairly generic.

Landmeetdienst

Krinkels

Landmeetdienst

Campus and Facility

Management

All three parties are

involved in the

digitization of the

campus of the University

of Twente, both

underground as above

ground.

9 November 2017 First discussion about

how to align and what to

include concerning the

subsurface and surface in

a digital environment.

Clarity about mainly what

to include in the digital

environment.

New insights in how the

campus should be

digitized.

Moderate to low

influence. No direct

influence on the domain

ontology itself, but it

showed how the domain

ontology could be

integrated with a digital


environment of the

surface elements.

Cadaster

Laris Noordegraaf

Fuat Akdeniz

Caroline Groot

All three involved in the

new IMKL 2015. The

transition to this model

by the industry is a core

aspect of their current

work.

22 November 2017 First meeting. Discussion about the

possibilities to visualize

the risks by making use

of the enriched and

recently updated IMKL

(IMKL 2015). Outcome

should be a showcase to

illustrate the possibilities

of such.

The question whether or

not the University of

Twente has the capacity

at the moment to assess

this problem. Follow up

required.

Low influence. The

project was a side-project

and not part of the

PDEng project.


Munich

Tatjana Kürzer

Member of the group


UtilityNetworkADE,


within FME.

28 November 2017 First discussion about the

ontology and relation of

the ontology with

CityGML Utility

Network ADE.

Gaps in CityGML Utility

Network ADE and how

the domain ontology may

fill these.

Positive attitude towards

contribution of the

domain ontology within

CityGML Utility

Network ADE.

High influence.

Advantages of modelling

the domain ontology

according to CityGML

UtilityNetwork ADE

were discussed. It was

agreed upon that my

PDEng project could

support the CityGML

project and vice versa.

Bouwend Nederland

Scholingsdag

Educational training day

at Bouwend Nederland

for vocational education.

2 February 2018 Presenting the latest

developments within the

ZoARG programme.

Creating affinity between

vocational education with

our the latest

developments within our

ZoARG programme,

without scaring them

technology might

possible replace them in

the future.

Most attendants were

quite positive about our

technologies, and did see

the potential of these in

their work. Overall

people were enthusiastic

and enjoyed the

presentation.

Low influence.

Presentation was fairly

general and not

specifically for my

PDEng project only.

Presentation was not

held to discuss the

technologies in detail.

Landmeetdienst

BAM

Landmeetdienst

Campus and Facility

Management

All three parties are

involved in the

digitization of the

campus of the University

of Twente, both

15 February 2018 Second discussion about

progress made in the

digitization of the

campus.

Proper alignment of

subsurface and surface,

and clarity about the

implementation.

Possible implementation

solutions were discussed,

and one is now further

developed.

Moderate to low

influence. No direct

influence on the domain

ontology itself, but it

showed how the domain


underground as above

ground.

ontology could be

integrated with a digital

environment of the

surface elements.


Munich

Tatjana Kürzer

Member of the group


UtilityNetworkADE,


within FME.

23 April 2018 Meeting to discuss the

progress of CityGML

Utility Network ADE

and the domain

ontology.

Learning from new

insights retrieved from

the CityGML Utility

Network ADE model.

Alignment of the domain

ontology.

New information on

CityGML Utility

Network ADE

development. Invitation

to present work at

workshop in September /

October.

High influence. New



ADE were applied to the

domain ontology to keep

these aligned to each

other. Concerned mainly

the network components

class model.

Expert panel


Campus and Facility

Management

Kadaster

Siers

CityGML (not

present)

Group of experts from

various disciplines with

knowhow on utility data

processing and

structuring.

3 May 2018 First expert meeting. Refine the ontology’s

alignment with practice.

A list of use cases was

individually defined and

collaboratively discussed.

Feedback was received

on the main functions

and use cases of the

ontology.

High influence. Existing

list of use cases was

complemented with the

newly added ones. New

competency questions

were, thereby, developed

as well. This led to newly

added concepts, relations

and attributes in the

domain ontology.

Cadastre

Caroline Groot

Fuat Akdeniz

Bart Maessen

Magdalena Gus

All involved in the

development and

adoption of the new

IMKL2.1.

May 2018 – September

2018

External project Development of

showcases for the new

IMKL2.1 model of the

Cadastre assessing risk

analysis and visualization

during utility works.

Published report

explaining the

possibilities within the

new IMKL2.1 to analyze

and visualize risks,

supported by four

showcases.

Low influence. The

project was a side-project

and not part of the

PDEng project.


Munich

Tatjana Kürzer

Member of the group


UtilityNetworkADE,


within FME.

22 June 2018 Meeting to discuss the

progress of CityGML

Utility Network ADE

and the domain

ontology.

Validating the newly

added ideas in addition

to the CityGML

UtilityNetwork ADE.

New insights in how the

domain ontology can be

better aligned to


ADE and vice versa.

High influence. New



ADE were applied to the

domain ontology to keep


these aligned to each

other. Concerned mainly

the network components

class model.

CROW Infradagen Congress where road

managers, contractors

and consultancies share

state-of-the-art

infrastructure

developments, both

technical and governance

related.

27 June 2018 Attending congress and

presenting paper.

Increasing outreach of

the PDEng project by

presenting the paper and

possibly making new

contacts.

Utilities were relatively

underexposed at the

congress. Still several

people showed interest in

the research.

Moderate to low

influence. Congress was a

good place to find

exposure for the domain

ontology. However, no

real new input was

gathered afterwards to be

included within the

domain ontology.

Expert panel


Campus and Facility

Management

Kadaster

Siers

CityGML (not

present)

Group of experts from

various disciplines with

knowhow on utility data

processing and

structuring.

28 June 2018 Second expert meeting. Assessing the

applicability of the

ontology by validating

whether the previous

established use cases can

be performed based on

data provided by the

ontology.

Missing information for

specific uses cases was

obtained. General

remarks and feedback on

the modelling of the

ontology.

High influence. Use

cases defined within the

first expert panel sessions

were validated against the

domain ontology.

Missing concepts,

relations and attributes

were collaboratively

defined. In addition,

general comments about

the class modelling of the

ontology were given.

Delft University of

Technology

Sisi Zlatanova

Associate professor at the

Delft University of

Technology, specialized

in 3D geo-information.

29 August 2018 Meeting to discuss the

utility modelling report.

Discuss the utility

modelling report written

as part of a capita selecta.

Positive feedback as well

as extra information on

standardization.

Meeting only moderate

influence, but the

research on existing

utility modelling

standards and practices

had a high influence as

explained before.

ARCOM Conference Conference by the

Association of Research

in Construction

3 Sept – 5 Sept 2018 Attending conference

and presenting paper.

Gaining feedback on my

paper, and making new

contacts within the

The paper was relatively

well received and some

insightful questions were

Moderate influence. No

new information was

provided that could be


Management, bringing

together all those

interested in construction

management research.

construction

management domain.

asked and comments

were given.

applied within the

PDEng project.

However, some useful

advices were given on

how to make the paper in

general stronger.


Munich

Tatjana Kürzer

Member of the group


UtilityNetworkADE,


within FME.

31 October 2018 Feedback meeting to

discuss the prototype of

the Operations and

Maintenance domain

ontology.

Receiving feedback on

the prototype of the

Operations and

Maintenance domain

ontology, to work

towards a final version.

Detailed feedback on the

data specification and the

feature catalogue.

High influence. Had a

thorough discussion on

each of the eight models


Within each model

minor adjustments were

made, for example on

the 3D modelling of

utilities within the core

model. In addition,

network components

were changed once again

and consequently

adapted in the domain

ontology.


Munich

Tatjana Kürzer

Member of the group


UtilityNetworkADE,


within FME.

7 November 2018 Follow-up feedback

meeting to discuss the

prototype of the

Operations and

Maintenance domain

ontology.



Operations and

Maintenance domain

ontology, to work


Detailed feedback on the

data specification and the

feature catalogue.

High influence. In

addition to the meeting

before, within this

meeting the final models

were discussed. Small

adjustments were made

in terms and definitions,

as well as in the

explanation of the hollow

space model.

Geonovum

Paul Janssen

8 November 2018 Feedback meeting to

discuss the prototype of

the Operations and



Operations and

Maintenance domain

Detailed feedback on

especially the data

specification. Feature

High influence. Data

specification was

especially reviewed from

a data modelling


Maintenance domain

ontology.

ontology, to work


catalogue was studied in

less detail.

perspective. Several

associations had to be

corrected and association

roles were added to the

feature catalogue. Other

remarks concerned

definitions to be not

specific enough yet and

the fact that abstract

classes had to be in italic.


Appendix III – Collected empirical data

Discipline n System level

objects

Subsystem level

objects

Component level objects Attributes

Gas 3 Gas distribution

system

Gas low pressure

network

Pipe

Station

Connection

Shut off valve

Blowhole

Saddle

Flange

Transition

T-piece

Bend

Mantle tube

Location, status, sub net, date of installation, pressure level, material, implementation,

coating, connection type, cathodic protection, tensile resistance, length, date of

rehabilitation, accuracy, owner, operator, financial characteristic, controlled drilling

Location, sub net, name, identifier no., status, address (street, house no., postal code,

place, municipal), owner, operator, financial characteristic, date in use, date of

expiration, date of installation, type of construction, type of foundation, type of lock,

internal attributes, etc.

Location, sub net, type of appendage, date of installation, installation company,

pressure level, implementation, material, coating, connection type, status, EAN code,

manufacturer, owner, operator

Location, sub net, type of appendage, date of installation, installation company, status,

material, pressure level, implementation, diameter, brand, coating, function, no.,

preferred mode, direction of rotation, number or rotations, station no., owner, operator


pressure level, diameter, implementation, construction type


pressure level


pressure level, implementation


pressure level, material, implementation, manufacturer, coating, no. of transitions




pressure level, degree

Location, sub net, type of appendage, date of installation, pressure level,

implementation


Gas high pressure

network

Duct

Pipe

Station

Connection

Shut off valve

Blowhole

Saddle

Cabinet

Flange

Transition

T-piece

Bend

Mantle tube

Insulation

piece


pressure level, owner, operator, cathodic protection, status, implementation,

connection type, accuracy

Location, status, sub net, date of installation, pressure level, material, implementation,

coating, connection type, cathodic protection, tensile resistance, length, date of

rehabilitation, accuracy, owner, operator, financial characteristic, controlled drilling

Location, sub net, name, identifier no., status, address (street, house no., postal code,

place, municipal), owner, operator, financial characteristic, date in use, date of

expiration, date of installation, type of construction, type of foundation, type of lock,

internal attributes, etc.


pressure level, implementation, material, coating, connection type, status, EAN code,

manufacturer, owner, operator

Location, sub net, type of appendage, date of installation, installation company, status,

material, pressure level, implementation, diameter, brand, coating, function, no.,

preferred mode, direction of rotation, number or rotations, station no., owner, operator


pressure level, diameter, implementation, construction type


pressure level

-




pressure level, material, implementation, manufacturer, coating, no. of transitions




pressure level, degree



-


Water 3 Water distribution

system

Water line Pipe

Flange

Fire hydrant

Bend

Shut off valve

Transition

Mantle tube

Location, status, sub net, function, material, external diameter, internal diameter,

nominal diameter, date of installation, status, length, water type, interior protection,

exterior protection, decommissioning, measurement type, pressure level, location

quality, owner

Location, sub net, function, status

Location, identifier no., municipality, sub net, implementation, function, rotational

direction, date of installation, status, secured, type of measurement, owner

Location, sub net, function, status, implementation, material

Location, sub net, function, implementation, identifier no., municipality, material pipe,

material, diameter, rotational direction, date of installation, status, preferred mode,

actual mode, date since actual mode, operator, measurement type, owner

Location, sub net, function, status

Location, material, diameter, length

Electricity 3 Electricity

distribution system

Low voltage line

system

Cable

Station

Connection

Street

furniture

Earthing

Charging pole

Mantle tube

Transition

Location, status, sub net, length, identifier no., status, nominal voltage, material core,

material isolation, implementation, date of manufacturing, date of installation,

installation company, accuracy, phase type, financial characteristic, owner, operator,

manufacturer

Location, name, code, area, measurements, status, date of installation, installation

company, function, implementation, owner, operator, circuit diagram, voltage

Location, address, status, function, pass through value, connection type, measurement

type, public priority, earthing checked, date of installation, installation company, level

of building, region, EAN code, owner, phase, earthing type, safety type, safety value,

safety characteristic, take off point, earthing remarks, no. of voltage errors

measurement, impedance measurement, general remarks, main cable, length of cable,

main cable type, cable sub group

Location, address, status, earthing, switch, EAN code, owner, function, date of

installation, installation company, mast no., identifier no., main cable, cable sub net

Location, sub net, type of appendage, date of installation, installation company

implementation


implementation


implementation


implementation, function, status, phase


Middle voltage line

system

PL cabinet

Cable

Station

Connection

Earthing

Mantle tube

Cross bonding

cabinet

TC coil

TC cabinet


implementation

Location, status, sub net, length, cable number, status, nominal voltage, material core,

material isolation, implementation, date of manufacturing, date of installation,

installation company, accuracy, phase type, financial characteristic, owner, operator,

manufacturer

Location, name, code, area, measurements, status, date of installation, installation

company, function, implementation, owner, operator, circuit diagram, voltage

Location, address, status, function, pass through value, connection type, measurement

type, public priority, earthing checked, date of installation, installation company, level

of building, region, EAN code, owner, phase, earthing type, safety type, safety value,

safety characteristic, take off point, earthing remarks, no. of voltage errors

measurement, impedance measurement, general remarks, main cable, length of cable,

main cable type, cable sub group


implementation


implementation

-

-

-

District

heating

3 District heating

distribution system

District heating

line

Pipe (supply

Pipe (return)

Mantle tube

Shut off valve

Transition

Data cable

T-piece

Weld

Reducer

Location, material, status, diameter, length, coordinates

Location, material, status, diameter, length, coordinates

-

-

-

-

-

-

-


Condensator

Measuring

cabinet

-

-

Telecom 3 Telecom

distribution system

Fiber line system

Coax line system

Cable

Connection

Station/center

Patch box

Handhole

PoP

Tube

Transition

Cable

Connection

Station/center

Mantle tube

Amplifier

Splitter

Location, type, status, system link, length, owner, accuracy, date of installation, date of

manufacturing, manufacturer, operator

Location, function, status, owner, date of installation, installation company

Location, function, status, address, identifier no., connector type, date of installation

Location, identifier no., function, status, date of installation, owner, operator

Location, area, function, status, data of installation, owner, operator

Location, area, function, status, data of installation, owner, operator

Location, system link, cable link, status, accuracy, owner, operator, type of cable, date

of installation, date of manufacturing, manufacturer, operator, depth

Location, function, type, date of installation

Location, type, status, system link, length, owner, accuracy, date of installation, date of

manufacturing, manufacturer, operator

Location, function, status, owner, date of installation, installation company

Location, function, status, address, identifier type, connector type, date of installation

Location, function, status, sleeve type, date of installation, supply point

-

-


Appendix IV – Overview of existing standards

# Standard Domain of application Domain Explanation

1 ArcGIS Utility

Networks

Global Utility sector Specific component users of ArcGIS use when managing utility and telecom networks.

Covers electric, gas, water, storm water, wastewater, and telecommunication

Designed to model all components that make up the network, such as wires, pipes, valves,

zones, devices, circuits

Real world behavior in a model

2 ASCE 38-02 United States Utility sector Primarily focuses on classifying the quality of existing utility data.

Collection and depiction of existing subsurface utility data

Classifying quality of existing subsurface utility data

Applies to the disciplines of electricity, gas, oil, crude, water, thermal, telecommunication,

sewage or any other similar commodity.

Provides project owner, engineer and construction information to develop risk reduction

strategies

3 AS 5488 Australia Utility sector Standard providing a framework for the classification of subsurface utility location and attributes information

in terms of specified quality levels. The standard does not apply to above ground infrastructure, such as

overhead wires.

Involves the utilities and associated subsurface features that facilitate location and identification

of the subsurface utility infrastructure.

4 CityGML

UtilityNetworkADE

Global Utility sector Develops a homogenized 3D network model for multi-utility failure simulation including the relevant

thematic attribution.

Application independent geospatial information model

Comprises different thematic areas such as buildings, vegetation, water, terrain, tunnels and

bridges.

Extension of CityGML providing the possibility to represent supply and disposal networks in

3D city models

5 IEC CIM Global Power utilities Global standard for power utilities, covering substation, transmission and distribution.

Extended to gas and water

Defines system architecture, API, data models, security protocols, meter reading and functional

safety

6 IMKL The Netherlands /

Belgium

Utility sector A standardized data specification on a national level intended to communicate utility data in case of

excavation works. Used through a central platform.

Provides a taxonomy and vocabulary for utility data

Is coupled with the INSPIRE model

7 INSPIRE EU Including utilities Developing a common information model for spatial data throughout Europe.

Covers electric, oil, gas, chemicals, sewage, telecommunications and water


Has a specific Utility Network application schema

8 LandInfra/InfraGML Global Land and infrastructure OGC approved standard (OGC 15-111r1) that captures the land and the infrastructure facilities build upon

the land.

Its encoding standard, InfraGML marks a significant, pragmatic realization in the often idealized

integration of GIS/CAD/BIM

Builds upon and extends GML3.2 and GML3.3

Provides framework for addressing the full facility life cycle

9 PAS128 UK Utility sector Primarily focuses on classifying the quality of existing utility data. Set out clear and unambiguous provisions

to those engaged in the detection, verification and location of active, abandoned, redundant or unknown

utilities.

Not object-based

Applies to disciplines of drainage, gas, water, electricity and telecommunication.

10 PAS256 UK Utility sector Developed to improve the quality, accuracy and reliability of asset owner’s records.

Drives towards improved accuracy of data and facilitates electronic sharing

Linkage between critical infrastructure assets and other initiatives for digital built Britain (e.g.

Smart Cities, BIM)

Includes rules for information exchange, locational accuracy, number of days to make

information reliable, unidentified buried objects, wrongly marked objects, and safety and

protection

11 Pipeline ML Global Oil and gas (midstream)

pipelines

An open industry data standard designed to help midstream pipeline operators to share information about

their assets and the various construction and maintenance activities performed on them.

Ongoing OGC standards development initiative

The need for Traceable, Verifiable and Complete (TVC) asset management data.

Open and vendor-neutral data interchange standard to enable the interoperable interchange of

pipeline data between parties, disparate systems and software applications

Limit loss of accuracy, density or data resolution; without ambiguity, without need for

conversion

12 SEDRIS Global Environment Offers a data representation model to articulate environmental data. Put simply, it is an infrastructure

technology providing the foundation for IT applications to express, understand, share and reuse

environmental data.

Represents environmental data

Facilitates the exchange of environmental data sets

Data representation aspects is about capturing and communication meaning and semantics

Representation aspect much like a language to unambiguously describe the environment

13 Utility Survey Standard Singapore Utility sector Standard providing guidelines on data capturing to improve reliability of utility data.

Aim to create a common understanding of the acquisition and production process of utility data

Provides a survey template


Appendix V – Expert panel sessions handouts (Dutch)

Handout expert meeting – May

Doel van vandaag

Vandaag staat in het teken van het evalueren van

versie 1.0.

De huidige versie van de ontologie is ontwikkeld

samen met het Facilitair bedrijf van de

Universiteit van Twente.

Doel van vandaag is om deze versie een breder

draagvlak te geven, door overeenstemming te

bereiken over (1) de inhoud en (2) de structuur

van de ontologie.

De evaluatie vindt vandaag plaats in drie rondes.

Elke van deze rondes adresseert een specifiek

thema, hierna nader besproken.

Agenda

13:00

16:30

15:30

14:20

14:35

15:45

Opening

Afsluiting

Voorstelronde

Tweede evaluatieronde

Presentatie

Derde evaluatieronde

Doornemen agenda

Resumé

13:05

13:10

13:15

Pauze

Pauze

16:15

Eerste evaluatieronde13:35


Eerste evaluatieronde – Aansluiting op de praktijk

Overzicht eerste evaluatieronde

Omschrijving

Doel Het bepalen van de use cases en hoofdfuncties van de ontologie.

Activiteit 1 Brainstormen over de use cases.

Activiteit 2 Brainstormen over de functies.

Resultaat (1) Een lijst van use cases, en (2) een set van (hoofd)functies die de ontologie moet omvatten.

Tweede evaluatieronde –Structuur en het level van detail

Overzicht derde evaluatieronde

Omschrijving

Doel Het bepalen van het de structuur en level van detail van de ontologie.

Activiteit 1 Brainstormen over de structuur.

Activiteit 2 Brainstormen over het level van detail.

Resultaat Set van eisen aan de ontologie betreffende (1) de structuur en (2) het level van detail.

Derde evaluatieronde – Integratie met bestaande modellen

Overzicht tweede evaluatieronde

Omschrijving

Doel Het afstemmen van de structuur van de ontologie met die van bestaande modellen, zijnde het IMKL en

INSPIRE.

Activiteit 1 Brainstormen over de integratie met het IMKL.

Activiteit 2 Brainstormen over integratie met INSPIRE.

Resultaat Set van eisen aan de ontologie betreffende integratie met (1) het IMKL en (2) INSPIRE.

Resultaat van vandaag

Lijst van use cases voor de ontologie;

Set van hoofdfuncties die de ontologie moet omvatten;

Set van eisen aan de structuur van de ontologie;

Set van eisen aan het level van detail van de ontologie;

Set van eisen aan de ontologie betreffende integratie met het IMKL;

Set van eisen aan de ontologie betreffende integratie met INSPIRE.

Volgende expert meetings

Overzicht aankomende expert meetings

Datum Tijd Locatie

Meeting 2 Juni 28, 2018 13:00 – 16:30 Universiteit Twente

Paviljoen, kamer 9

Meeting 3 September 13, 2018 13:00 – 16:30 Universiteit Twente

Paviljoen, kamer 9


Handout expert meeting – June

Doel van vandaag


de domein ontologie.

De huidige versie is verder ontwikkeld aan de

hand van de verkregen feedback uit de eerste

expert meeting (25 mei jl.), in samenwerking met

het Facilitair Bedrijf van de Universiteit van

Twente.

Doel van vandaag is allereerst om te bespreken

in hoeverre de ontologie aan de hand van de

feedback van de vorige meeting is aangepast.

Vervolgens zal in twee evaluatierondes, hierna

nader besproken, de content en structuur van de

ontologie geëvalueerd worden, aan de hand van

enkele use cases.

Agenda

13:00

16:30

15:00

13:45

14:00

15:15

Opening

Afsluiting

Voorstelronde

Eerste evaluatieronde

Terugkoppeling

Tweede evaluatieronde

Doornemen agenda

Resumé

13:05

13:10

13:15

Pauze

Pauze

16:15

jan

feb

mrt

apr

mei

jun

jul

aug

sept

okt


Eerste evaluatieronde – Objecten en attributen

Tabel 1 – Overzicht eerste evaluatieronde

Omschrijving

Doel Het bepalen van de nodige objecten en attributen die de ontologie moet omvatten.

Activiteit 1 Het opstellen van een eigen ontologie.

Activiteit 2 Analyseren van type objecten en attributen genoemd binnen de ontologie.

Resultaat Een groslijst van (1) objecten, met daaraan gekoppeld (2) een set van attributen.

Tweede evaluatieronde –Toepasbaarheid

Tabel 2 – Overzicht derde evaluatieronde

Omschrijving

Doel Het bepalen van de toepasbaarheid van de ontologie aan de hand van use cases.

Activiteit 1 Lijst van aansprekende use cases, waaraan de ontologie getoetst wordt, opstellen.

Activiteit 2 Analyseren van de ontologie op haar toepasbaarheid, met inachtneming van de volgende aspecten:

Content – objecten en attributen

Structuur – logica

Resultaat Lijst van tips / aandachtspunten betreffende (1) de content en structuur, en (2) de toepasbaarheid.


Lijst van algemene objecten die de ontologie moet omvatten;

Lijst van algemene attributen die de ontologie, voor de betreffende objecten, moet omvatten;

Lijst van tips / aandachtspunten aan de ontologie betreffende content en structuur;

Lijst van tips / aandachtspunten aan de ontologie betreffende toepasbaarheid.

Volgende expert meeting

Tabel 3 – Overzicht aankomende expert meeting

Datum Tijd Locatie

Meeting 3 September 13, 2018 13:00 – 16:30 Universiteit Twente

Paviljoen, kamer 9


Handout expert meeting – September (plenary session cancelled)

Doel van vandaag


versie 3.0. Aan de hand van de verkregen

feedback uit deze meeting zal de definitieve

versie worden opgesteld.

De huidige versie is verder ontwikkeld aan de

hand van de verkregen feedback uit de tweede

expert meeting, in samenwerking met het

Facilitair Bedrijf van de Universiteit van Twente.

Doel van vandaag is allereerst om te evalueren of

de aangebracht wijzigingen voldoen. Vervolgens

vind een evaluatieronde plaats, hierna nader

uitgelegd.

Tot slot wordt de adoptie en implementatie van

de ontologie kort besproken.

Agenda

13:00

16:30

15:15

14:00

14:15

15:30

Opening

Afsluiting

Voorstelronde

Evaluatie

Terugkoppeling

Implementatie en adoptie

Doornemen agenda

Resumé

13:05

13:10

13:15

Pauze

Pauze

16:15

jan

feb

mrt

apr

mei

jun

jul

aug

sept

okt


Eerste evaluatieronde – Knelpunten

Tabel 2 – Overzicht eerste evaluatieronde

Omschrijving

Doel Het bepalen van de nog aanwezige knelpunten in de ontologie, zowel in de content als in de structuur.

Activiteit 1 Brainstormen over de knelpunten in de content.

Activiteit 2 Brainstormen over de knelpunten in de structuur.

Resultaat Set van knelpunten aan de ontologie betreffende (1) content en (2) structuur.

Tweede evaluatieronde –Implementatie en adoptie

Tabel 2 – Overzicht derde evaluatieronde

Omschrijving

Doel Het bepalen van de nodige vervolgstappen om implementatie en adoptie van de ontologie te stimuleren.

Activiteit 1 Brainstormen over de mogelijke bottlenecks omwille implementatie.

Activiteit 2 Brainstormen over de mogelijke bottlenecks omwille adoptie.

Resultaat Set van eisen aan de ontologie betreffende (1) implementatie en (2) adoptie.


Set van knelpunten aan de ontologie betreffende content;

Set van knelpunten aan de ontologie betreffende structuur;

Set van eisen aan de ontologie betreffende implementatie;

Set van eisen aan de ontologie betreffende adoptie.

Vooruitblik

Aan de hand van de feedback verkregen uit deze derde en laatste expert meeting, zal de definitieve

ontologie gevormd worden. Na de vorming van de ontologie, staan er twee belangrijke aspecten te

wachten, zijnde implementatie en adoptie.

Implementatie

De definitieve ontologie wordt geïmplementeerd bij het Facilitair Bedrijf van de Universiteit van Twente.

Er zal getest worden met het inladen van verscheidene datasets voor een tal van disciplines. Tevens zal er

getest worden met het importeren en exporteren van de data.

Adoptie

Het creëren van draagvlak is essentieel voor het voortbestaan van de ontologie. Aansluiting van de

ontologie met de datamodellen binnen het IMKL en INSPIRE draagt daar aan bij. Verder vergroot de

connectie met CityGML UtilityNetwork ADE, maar ook met ZoARG, de bekendheid van het model.


Handout expert meeting – September (template individual sessions)

Introductie

Dit document dient als hand-out voor de derde expert sessie ten behoeve van de evaluatie van de domein

ontologie voor ondergrondse infrastructuur. Deze ontologie wordt opgesteld vanuit een initiatief aan de

Universiteit van Twente. In onderstaande paragrafen wordt de hand-out van deze sessie uiteengezet.

Uitleg bij documenten

Voor deze derde expert sessie zijn in totaal drie documenten van belang. Elk van deze wordt hieronder

kort toegelicht.

[1] Hand-out expert sessie

De hand-out voor de expert sessie ligt voor u. Dit document dient als doel het evalueren van de domein

ontologie voor ondergrondse infrastructuur. In hoofdstuk 2 van dit document wordt uiteengezet op welke

criteria geëvalueerd wordt. De documenten die geëvalueerd worden betreffen de volgende twee.

[2] Operations and Maintenance ADE – Data Specification

De ‘Operations and Maintenance ADE – Data Specification’ is het hoofd-document en beschrijft en

presenteert de ontologie aan de hand van verscheidene class-modelling (UML) diagrammen. Deze

diagrammen zijn ook in de voorgaande expert sessie met u besproken. Op basis van de toen verkregen

feedback zijn de UML diagrammen aangepast en is het aangevuld met een rapportage, resulterende in de

data specificatie. De ontologie wordt middels een achttal modellen en de bijbehorende UML diagrammen

beschreven in de data specificatie. Voor elk van de modellen is een uitleg aanwezig in de data specificatie.

[3] Operations and Maintenance ADE – Feature Catalogue

De ‘Operations and Maintenance ADE – Feature Catalogue’ is de catalogus behorende bij de data

specificatie. In deze catalogus zijn alle concepten en relaties opgenomen die deel uitmaken van de UML

diagrammen. De catalogus biedt daarmee ondersteuning in het geval van onduidelijkheid van gebruikte

termen en definities in de UML diagrammen. De catalogus volgt de volgorde van de acht modellen en

bijbehorende UML diagrammen beschreven in de data specificatie.

Doel

Het doel van deze derde en laatste expert sessie is het evalueren van de ontologie op basis van criteria

beschreven in hoofdstuk 2. De evaluatie binnen deze sessie is met name gericht op de functionaliteit en

bruikbaarheid van de ontologie. Evaluatie richt zicht daarbij met name op de vocabulaire (gebruikte

termen en definities binnen de ontologie) en de taxonomie (toegepaste structuur en opbouw binnen de

ontologie) van de ontologie. De ontologie is reeds geëvalueerd op logica (aangaande de UML modelleer

taal) binnen het softwarepakket waarin hij is opgesteld.


Beoogd resultaat

Op basis van de verkregen feedback uit deze sessie zal de definitieve versie van de ontologie opgesteld

worden. Het beoogde resultaat is daarmee het verkrijgen van feedback op de beide documenten van de

‘Operations and Maintenance ADE’. Hierbij draait het met name om feedback op de acht UML

diagrammen en bijbehorende catalogus. Feedback op de rapportage in het algemeen wordt gewaardeerd

en meegenomen, maar dient niet het hoofddoel van deze expert sessie.

Vooruitblik

De definitieve versie die volgt uit de feedback uit deze derde expert sessie zal (deels) worden

geïmplementeerd bij het Facilitaire Bedrijf van de Universiteit van Twente. Er zal getest worden met het

inladen van bestaande netinformatie in een GIS georiënteerde omgeving. Mogelijke fouten in de ontologie

die daarbij aan het licht komen worden nog gecorrigeerd, alvorens de ontologie gepubliceerd kan worden.

Verdere details over publicatie zijn nog niet bekend.


Evaluatie

Binnen deze expert sessie wordt de ontologie geëvalueerd aan de hand van een zestal criteria:

[1.] Aanpassingsvermogen:

Is de conceptuele basis van de ontologie voldoende voor het scala aan verwachte taken die zij moet kunnen? Kan de ontologie daar waar nodig uitgebreid

en gespecialiseerd worden door haar gebruikers?

[2.] Beknoptheid:

Bevat de ontologie irrelevante concepten of relaties betreffende het domein van beheer en onderhoud van ondergrondse infrastructuur? Zijn er overbodige

concepten en beschrijft de ontologie puur de essentiële zaken van het domein?

[3.] Consistentie:

Zijn er tegenstrijdigheden in de ontologie? Is de beschrijving van de concepten en relaties binnen de ontologie consistent?

[4.] Compleetheid:

Bevat de ontologie alle relevante concepten en relaties voor het domein van beheer en onderhoud van ondergrondse infrastructuur?

[5.] Helderheid:

Wordt de bedoelde betekenis van de gebruikte termen en definities in de ontologie effectief gecommuniceerd? Zijn de gebruikte termen en definities

helder beschreven en is daarmee de ontologie begrijpelijk?

[6.] Nauwkeurigheid:

Legt en representeert de ontologie de correcte aspecten van de ‘echte’ wereld vast? Voldoet de ontologie aan de deskundigheid van haar gebruikers?

Doel is om de acht UML diagrammen en bijbehorende catalogus langs te gaan en te evalueren hoe aan elk van de criteria wordt voldaan. Mochten er zich

onduidelijkheden of fouten voordoen in het model, kan dat beschreven worden in de tabel die voor elk van acht de modellen is opgesteld op de volgende pagina’s.

Als voorbeeld is onderstaande gegeven voor criteria ‘Compleetheid’. Voor elk model is tevens ruimte gelaten op de volgende pagina’s voor overige opmerkingen

op de stippellijnen onder de tabel. De volgende pagina’s volgen de volgorde van de UML diagrammen zoals in de data specificatie en catalogus.

# Criteria Opmerking

1 Compleetheid Voor het uitvoeren van activiteit ‘X’ mist het object ‘Y’ met attribuut ‘Z’ in het UML diagram.


Appendix VI – Possible BSc / MSc research subjects

[1] Treatment evaluation of the Operations and Maintenance conceptual schema

The Operations and Maintenance conceptual schema is not fully implemented yet in (spatial) asset

management and GIS software. In order to do so, the student continues with the implementation of the

conceptual schema at the Campus and Facility Management of the

University of Twente. Implementation is done in QGIS by making use

of the FME software. In addition to implementation only, the student

evaluates the conceptual schema through querying (by for example using

the software pgRouting) against its use cases. Outcome of the student’s

work is one utility discipline fully mapped to the conceptual schema’s

format. Also, the student shows whether the conceptual schema is

capable of delivering the information required for operations and

maintenance. In general, this research includes the following activities:

Mapping utility data of one utility discipline according to the Operations and Maintenance conceptual

schema through FME.

Validating the Operations and Maintenance conceptual schema through computer-interpretable

queries, for example, by making use of the pgRouting software.

Academic level BSc / MSc

Required background Civil engineering, geo-information science

Host organization Campus and Facility Management University of Twente

[2] Visualization of utility information from a socio-technical perspective

Mapping utility data through the Operations and Maintenance conceptual schema does result in a GIS

database structure. However, questions remain on how to visualize the utility data, but foremost, on which

utility data to be visualized. Therefore, the student focuses on the following two elements: (1) analysis on

how to visualize spatial data in geospatial software, and (2) analysis of which spatial utility data to be

visualized. Whereas the former is a relatively technical questions, the latter touches on the socio-technical

perspective. The visualization needs of utility data from the

end-user perspective receive only little attention in literature.

In this context, an end-user may be an utility owner, utility

operator or contractor. The student, thereby, contributes to

literature by providing new insights in visualization of

geospatial information, in specific, utilities. In general, this

research includes the following activities:

Analysis of which utility data to be visualized from the socio-technical, and thereby, end-user

perspective.

Analysis on how to visualize utility data in geospatial software, including its technical implications.

Academic level MSc

Required background Civil engineering, geo-information science

Host organization University, utility owner, utility operator


Appendix VII – Publications

Title Digitization for Integration: Fragmented Realities in the Utility Sector

Author Ramon ter Huurne, Léon Olde Scholtenhuis

Type Conference paper

Conference ARCOM 2018 Conference, Belfast, UK, 3-5 September 2018

Published Yes

Presented Yes

Language English

DIGITIZATION FOR INTEGRATION: FRAGMENTED

REALITIES IN THE UTILITY SECTOR

The construction industry and its reform agendas commonly assume that digitization of a

construction asset's life cycle also integrates its stakeholders. Behind this lies the premise that

stakeholders reduce ambiguity and create consistency by using software that operates on the

basis of shared and uniform knowledge. To explore this premise, this study identified the

knowledge bases - data standards and modelling protocols for engineering software - that

distinctive underground infrastructure owners use. To this end, we analysed a utility

engineering consultancy that registers and processes asset data of twelve major utility owners.

We observed their utility information managers and studied their asset management guidelines.

We used two utility taxonomies from literature to compare identified digital modelling

standards. Subsequently, we used literature about modelling standards in digital practices to

argue how selected examples of divergent digital models hamper uniformity. We conclude that

digital reality models may also differ and thus confuse, fragment, and ultimately delimit

collaborative digital practices. This insight stresses the relevance of defining shared domain

understanding to facilitate the uptake of software for collaborative engineering practices. It

stimulates construction improvement agents to consider this important notion of shared digital

realities in their debates about achieving integration by ‘going digital'.

Keywords: digitization, fragmentation, integration, standardization, utility sector.

INTRODUCTION

Building Information Modelling (BIM) advancements drive state-of-the-art engineering and

problem-solving in the construction industry. Its implementation is a much-discussed topic in

literature and policy documentation (e.g. Bradley et al. 2016; Lu et al. 2015; Pauwels et al.

2016). One of the main steps in converting to this 'BIM paradigm' is through digitization,

which involves the development of 'digital twins' of construction assets. A general belief in

the construction industry - for example, visible in industry reform agendas - is that


digitization of the information relevant to the construction asset's life cycle further integrates

stakeholders. The argument follows the implicit logic that ambiguity will decrease and

consistency between exchanged information will increase when stakeholders all accept and

implement one uniform knowledge base for their (BIM) software. Taking this for granted,

however, may cause 'digitization hubris'.

The problem with this ideal perception that digitization stimulates integration of the

fragmented supply chains in the construction industry is that it ignores that digital practices

themselves are also fragmented. Software interoperability and information integration issues

(Lu et al. 2015) complicate this integration of fragmented practices. Turk (2001) describes a

typical way in which construction-IT developers capture practitioners' realities. He argues that

standardized data formats and structures help to achieve integration under the condition that

these are accepted and represent practitioners' shared perceptions of realities. In addition,

Gustavsson et al. (2012) and Samuelson and Björk (2011) indicate that a lack of consistency

in and acceptance of the adoption of standards creates a barrier to the realization of

integration.

The lack of consistency in and acceptance of the adoption of standards has led to the

phenomenon of, drawing on Timmermans and Epstein (2010), "a world of standards, but not a

standard world". This phenomenon is also typical for the architecture, engineering and

construction (AEC) industry, where nations, organizations and even individuals have been

developing digital (BIM) standards in a rather fragmented and self-centred manner (Azhar

2011).

Although existing literature argues that consistency in and acceptance of standards is a

prerequisite in achieving integration through digitization, this suggests that a professional

paradigm is able to develop a unified and accepted standard. This study verifies whether such

a unified and accepted standard is developed in practice. In specific, it explores the

digitization practices in the utility sector to understand the extent to which digitization leads

to uniform digital practices. We identified and assessed digital standardization practices in a

utility engineering consultancy and show that the industry currently uses various standards to

model the same utility asset information. Consequently, we argue that implementation of

digital practices may lead to digital information but that this does not necessarily result in a

common and accepted set of uniform practices. We show that the existence of different digital

realities hampers the integration of stakeholders.

The remainder of this paper is organized as follows: we first describe related literature about

digitization and standardization. Second, we present how we used a case study to compare

standards in practice. Third, we present findings by elaborating on selected examples of

differing standard descriptions of an asset object. We compare the findings to literature before

we draw our conclusions.

RELATED LITERATURE

The use of technology in construction projects can improve the inter-organizational

communication, cooperation and coordination (Adriaanse et al. 2010; Peansupap and Walker

2005). In the process of using such technologies, the construction industry digitizes

construction assets by defining concepts, attributes, and their relations (El-Diraby and Osman

2011). Digitizing asset data is realized through applications like BIM (Bradley et al. 2016).

Methodologies should be developed to facilitate exchange and communication between such

applications in order to streamline work flows. Currently, this happens through the

development of semantic web ontologies (Pauwels et al. 2016) and asset data modelling


standards such as the Industry Foundation Classes (IFC) for BIM software (Turk 2001) and

CityGML for geospatial software (Open Geospatial Consortium).

Standardization is critical to facilitate communication between different stakeholders in a

fragmented industry - like the architecture, engineering and construction (AEC) industry

(Howard and Björk 2008). Standards for representing construction data, such as IFC and

CityGML are gradually accepted and used as the predominant way to exchange data between

engineering software. However, common data formats for major types of infrastructure

projects, such as transport, utilities or environmental projects (Bradley et al. 2016) are less

developed.

The aim of standardization, in general, is to capture realities and construct uniformities across

cultures, time and geography on the basis of agreed-upon rules (Timmermans and Epstein

2010). These agreed-upon rules are thereby captured in standards, which, on their turn,

emerge from many fields (Bowker and Star 1999; Timmermans and Epstein 2010). The types

of standard relevant to this study, are digital modelling standards. Such standards are also

referred to as 'ontologies' (El-Diraby and Osman 2011). In computer science, ontologies are

used in the process of knowledge elicitation - i.e. the process and output of reality modelling.

In this process, knowledge is modelled in artefacts such as domain ontologies. Ontologies

describe the world as seen by a group of people at a certain time according to a school of

thought that is based on a set of fundamental propositions or world views (El-Diraby and

Osman 2011). Once adopted and shared amongst practitioners, they represent domain

knowledge in a unified, simplified, and consistent way.

Capturing realities through digital modelling standards - i.e. ontologies - for the fields in

which digitization emerges requires thought about phenomenology - a branch of philosophy

that deals with how to take things for what they are and what it means 'to be' - and

hermeneutics - a branch of philosophy focussing on interpretation. Intention and interpretation

are relevant when capturing realities, because their meanings can be shaped both by the

authors and users of standards. Once explicated in a textual form realities can, therefore, have

several plausible interpretations (Turk 2001). Likewise, Lampland and Star (2009) argue that

it is not surprising that standards have many possible antonyms, given the range of possible

meanings packed in a term.

When digital modelling standards are not adopted in digital practices, this may hamper

construction IT adoption. In their adapted model of IT adoption - based on the unified theory

of acceptance and use of technology, the theory of planned behavior, and the technology

acceptance model - Adriaanse et al. (2010), have identified that differences in working

practices, resources and objectives hamper successful adoption of IT. The existence of

differing work practices also impacts digital modelling practices. Co-existence of multiple

practices, may, for example also result in situations where practitioners use distinctive digital

modelling standards to model an asset. As a result, adopted IT may use distinctive knowledge

bases, and therefore show little uniformity in knowledge representation. Therefore, we

hypothesize that using IT, and developing standardizations, does not automatically enable

adoption and integration of IT users. The different digital realities can explain why adoption

and use of IT in AEC industry are not always as effective and efficient as they could

potentially be (Hjelt and Björk 2006; Sulankivi 2004).

To date, literature seems to have focussed on proposing a standard for a certain domain (e.g.

El-Diraby and Osman 2011) or argue that standards should be developed to achieve

integration (e.g. Gustavsson et al. 2012; Samuelson and Björk 2011; Turk 2001). It does not,

however, focus on the multiple standards - and as a consequence realities - that co-exist as a

result of varying work practices. Limited attention is given to the impact of different realities


on the successful adoption and integration of digital modelling practices. In light of shit

research gap, this study observes the use of standards and IT in the AEC industry and seeks to

provide the first evidence for our hypothesis.

RESEARCH METHOD

Different standards of reality, as a result of varying work practices, have received limited

attention in literature. Therefore, we considered an exploratory research approach most

appropriate. We conducted a qualitative case study to collect data and gain insights in the

topic investigated (Yin 2014). In this case study, we identified and compared the different

standards used in the construction domain. More specifically, we decided to focus on a

domain in which BIM technologies and standards are not adopted on large scale. The utility

sector is a good example of such a domain and was therefore selected. We studied how

standards and data protocols have been used in a Dutch utility engineering consultancy

company. This company registers and processes utility data of twelve major utility owners,

being our unit of analysis. The twelve utility owners cover the disciplines of water, gas,

electric, telecom and district heating, where several utility owners represented multiple

disciplines. As such, each utility discipline was covered by three utility owners.

The data collection approaches used in our case study include observations of work practices

and study of asset management guidelines. To this end, we observed seven information

managers whose daily task was to model underground networks. During the observations, the

information managers showed and explained how utility owners store their realities in digital

environments. While keeping notes on this, we had dialogues in which they explained their

asset management work routines.

We also collected asset management guidelines from six utility owners that were used by the

information managers as a guideline to verify data that surveyors and engineers modelled. We

found international, national, and organizational standards. Asset management guidelines

from the other utility owners were either not available or made accessible due to privacy

reasons.

The elicited realities from practice were analysed in a two-stage process: (1) qualitative

coding to abstract and compare the standards and guidelines, and (2) identifying differences

or similarities between the elicited realities.

To abstract and compare the standards and guidelines, we used qualitative coding (Saldaña

2015). El-Diraby and Osman's (2011) typology of infrastructure objects was used to compare

the various concepts and attributes in the standards that we found. This typology distinguishes

between component level, subsystem level, and system level objects and captures, for

example, spatial, dimensional, and material attributes. To this end, we identified how various

asset owners of underground infrastructures describe and store their ‘realities’ in data

standards and protocols.

After assigning objects to these various levels and attributes, our next step was to identify

differences or similarities between modelled realities. For this, we used a typology from

Gasevic et al. (2009) that essentially describes three elements of an ontology: (1) taxonomy

and hierarchy, (2) vocabulary, terms and names, and (3) semantics: the linguistic meaning of

the representation.

After identifying similarities and differences, we selected examples to explain how standards,

albeit digitized, are still fragmented. This serves as first evidence for our hypothesis that using

digital systems, and developing standardizations, does not automatically enable adoption and

integration of IT users.


FINDINGS

Our findings show that modelled realities used by information modelers were represented in:

(1) international, (2) national and (3) organizational standards. The case study, both through

observations of the work practices and study of asset management guidelines, reveals that, for

example, each utility owner prescribed her own asset data registration standard, based on their

own work practices. According to the modelers, the organizational standards were used more

frequently than the international and national standards. Since most examples follow from

these organizational standards, these will be elaborated on below.

The modelled realities represented in the organizational standards describe a comprehensive

set of utility asset data. To this end, we found around twenty to forty infrastructure objects

within a single reality, dependent on the type of utility discipline. Captured realities within the

telecom discipline, for example, covered around twenty objects, whereas realities from the gas

discipline covered up to forty objects. Most of the infrastructure objects found belong to the

component level of El-Diraby and Osman's (2011) typology of infrastructure objects. We also

found extensive lists of attribute information for the infrastructure objects at hand. Within

elicited realities from the electricity domain, for example, up to fifteen attributes for the

component level object 'kabel' (cable) were found. Within this example, spatial and

dimensional attributes were, amongst others, included. A comparable number of attributes

was found for other infrastructure objects.

When comparing the abstracted realities, we found that in general similar objects and

attributes were captured in the standards. Standards include comparable component,

subsystem and system level objects. This finding also applies to the type of attributes

captured. However, a more detailed comparison between these standards - i.e. realities -

shows differences. Following the typology of Gasevic et al. (2009), three illustrative

differences are presented in more detail, while briefly noting others:

First, one example of a taxonomical difference is visible when comparing three standards of

the telecom discipline. These standards use subsystem level and system level objects to model

their telecom network in the following two ways. First, two standards use subsystem level

objects to model their coaxial and fiber network as individual subsystems. Their main telecom

network, including both the coaxial and telecom network, is modelled on top of the taxonomy

at the system level. Second, one standard models both the coaxial and fiber network on the

subsystem level as one main telecom network. The particular network type here is specified

as an attribute of the subsystem object, i.e. the main network.

Another taxonomical difference, for example, is visible within the modelling of the object

'station' (station) when comparing three standards of the gas discipline. Where two standards

model a station as one single component level object and define its type (internal, external) at

the attribute level, one other standard defines the type of station already at the component

level object. In total, we found around six taxonomical differences.

Second, an example of the way in which realities are modelled with a different vocabulary is

the similar use of the words 'meting' (measurement) and 'nauwkeurigheid' (accuracy) when

comparing two standards of the electricity discipline. Both standards use these words to

describe the type of measurement of coordinates (either analogous or digital) in order to

estimate how accurate the coordinates of component level objects are.

Another notable difference in use of vocabulary, for example, is the similar use of the words

'ligging' (area) and 'locatie' (location) to describe the x and y coordinates of a component level

object. Differences in use of vocabulary were found to be most frequent, compared to the


other types of differences in ontological representation. In total, we found around fifteen

differences of the way in which realities are modelled with a different vocabulary.

Third, a semantic difference in the elicited realities is the ambiguous meaning of the word

'uitvoering' (implementation). The word is used to describe various characteristics of objects

on mainly the component level. Six standards across the telecom, gas and electricity

discipline, show the use of the word to describe divergent characteristics such as diameter,

manufacturer, material type, and installation type. This difference was even found in

individual realities of the gas discipline. In addition, in three standards of the electricity

discipline, the word is used to describe multiple characteristics at once, including

manufacturer, material and diameter.

Other examples of semantic differences include the ambiguous meaning of both the words

'sort' (soort) and 'type' (type). Similar to 'uitvoering' (implementation), these words are used to

describe various characteristics of objects, being mainly the installation type and material

type. In total, we found around eight examples of semantic differences.

Findings show that assets were modelled in standards for international, national and

organizational communities. There seems to be a favored use of organizational standards

defined by utility owners, rather than international and national standards. Moreover, the

results show differences in ontological representations, since the elicited realities differ in

their structure, use of terms and linguistic meaning of their representation.

DISCUSSION

Many organizations nowadays digitize their assets (e.g. Bradley et al. 2016; Lu et al. 2015;

Pauwels et al. 2016) through applications like BIM. Consequently, lots of different digital

knowledge bases for software systems are created. Whereas it is believed that digitization of

the information relevant to the construction asset's life cycle further integrates stakeholders,

the existence of different realities - as represented in standards - has implications on the

successful adoption of digital practices.

Realities in utility companies show differences in regional coverage and the ontological

aspects taxonomy, vocabulary, and semantics. The realities, therefore, reveal different

standards. This stresses the importance of the perspective of philosophy on integration. The

utility owners studied create their own knowledge base, from their own perception on how to

model the reality. Every utility owner, therefore, followed her own organizational standard.

Moreover, these various standards reveal different realities and work practices. Literature

argues that work practice differences and lacking acceptance of standards provide barriers to

successful IT adoption (Adriaanse et al. 2010), but we add to this that, even with usage of

locally accepted standards, it is not likely that an integrated digital practice emerges. This

eventually limits the adoption of a sector-wide uniform digital modelling practice.

Differences in standardized realities cause confusion in a digital reality. One reason for this

observation may be the fragmented nature of the AEC industry. According to Dubois and

Gadde (2002), the AEC industry as a whole can be featured as a loosely coupled system,

which stimulates the generation of variation. Because of this loose coupling, and therefore,

fragmentation, it is not a great surprise that also fragmented realities are seen in digitization

practices. A second reason may be the existing assumption in technology acceptance models

on the effect of standardization. The study showed that without a shared and accepted

standard, fragmented realities are likely to emerge. Whereas standardization is believed to be

a driver of adoption and integration of digital practices, fragmented standards mainly cause

confusion and thereby delimit collaborative digital practices.


This study contributes to literature as follows. First, this study adds better understanding to

the dynamics underlying the studies that identify 'factors' for the adoption of technology and

concludes that effectivity and efficiency of inter-organizational technologies are sometimes

below average (Hjelt and Björk 2006; Sulankivi 2004). By going beyond assuming that

digitization, via standardization, leads to integration, we provide evidence for the hypothesis

that technology adoption in an emerging field goes in line with the definition of many

standards. Based on this, we argue that such digital standards need to be unified and shared

before being able to achieve collaboration benefits of information systems. This notion of

'varied standardization' should receive greater attention in technology acceptance models.

The limitation of this study is that it focussed only on the modelling practices in the utility

domain. Although this is not representative for the full construction industry, it provides

valuable lessons for other domains in construction where digital systems are not yet adopted

by the larger community - e.g. in lower-tiers of supply chains and infrastructure domains.

Therefore, we believe that the differences in realities found in this study are likely to learn the

utility industry and the wider construction community about the importance of considering

shared domain understanding in research as well as in industry digitization initiatives. Future

studies can confirm these findings by extending our work with observation in other parts of

the construction sector. Moreover, this study has only assessed digitization of construction

asset data from an ontological perspective. Future studies should elaborate on the effect of

other types of standards on the integration of stakeholders through digitization.

CONCLUSION

This study postulates the hypothesis that digitization of the construction asset life cycle does

not automatically lead to integration of stakeholders and more collaborative work practices.

Our findings show that modelled realities are represented in international, national, and

organizational standards. Although similar objects and attributes were captured in the various

digital modelling standards, we show that these are 'standardized' in distinctive ways. A

selection of examples from digitization practices in the utility sector illustrates differences in

how domain knowledge is represented. The examples show how elicited realities differ in use

of taxonomy, vocabulary, and semantics. This provides evidence for the existence of

diverging realities. Such differences in modelled digital realities are likely to create ambiguity

and may, therefore, fragment and ultimately delimit integration of digital practices.

The existence of the distinctive standard realities imply that the utility sector currently lacks a

uniform digital modelling practice. This, in turn, limits the possibilities for IT developers to

align information systems that exchange network data in a uniform way between network

operators and contractors. These observed diverging realities seem less present in the facility

and building industry. This part of the construction industry already established and adopted

the object-modelling standard IFC.

This study confirms that various standards can co-exist in the utility sector. One reason for

this may be that this domain is currently making the transition toward a digital practice for

planning and managing their assets. This demonstrates that, while a sector moves toward

implementing digital practices, this does not immediately lead to unification of practices and

communication flows.

The example shows that initiatives that are aimed at stimulating 'digital collaboration', should

be cautious in assuming that digitization immediately supports integration. We, therefore,

urge practice in developing standards that capture shared ontological understandings. Such

shared perception is a precondition for achieving integration though digitization in the

fragmented construction sector.


ACKNOWLEDGEMENTS

We thank Siers Infra Consultancy for providing the authors access to their workplace for data

collection.

REFERENCES

Adriaanse, A, Voordijk, H and Dewulf, G (2010) Adoption and Use of Interorganizational

ICT in a Construction Project. Journal of Construction Engineering and

Management, 136(9), 1003-1014.

Azhar, S (2011) Building Information Modeling (BIM): Trend, Benefits, Risks, and

Challenges for the AEC Industry. Leadership and Management in Engineering,

11(3), 241-252.

Bradley, A, Haijiang, L, Lark, R and Dunn, S (2016) BIM for infrastructure: An overall

review and constructor perspective. Automation in Construction, 71, 139-152.

Bowker, G and Star, S L (1999) Sorting Things Out. Cambridge, MA: MIT Press.

Dubois, A and Gadde, L (2002) The construction industry as a loosely coupled system:

implications for productivity and innovation. Construction Management and

Economics, 20(7), 621-631.

El-Diraby, T E and Osman, H (2011) A domain ontology for construction concepts in urban

infrastructure projects. Automation in Construction, 20(8), 1120-1132.

Gasevic, D, Djuric, D and Devedzic, V (2009) Model Driven Engineering and Ontology

Development. New York, NY: Springer.

Gustavsson, T E, Samuelson, O and Wikforss, Ö (2012) Organising IT in Construction:

Present State and Future Challenges in Sweden. Journal of Information Technology in

Construction, 17, 520-533.

Hjelt, M and Björk, B C (2006) Experiences of EDM usage in construction projects.

Journal of Information Technology in Construction, 11, 113-125.

Howard, R and Björk, B C (2008) Building Information Modelling - Experts views on

standardisation and industry deployment. Advanced Engineering Informatics,

22(2), 271-280.

Lampland, M and Star, S L (2009) Standards and Their Stories: How Quantifying,

Classifying, and Formalizing Practices Shape Everyday Life. Ithaca, NY: Cornell

Univ. Press.

Lu, Y, Li, Y, Skibniewski, M, Wu, Z, Wang, R and Le, Y (2015) Information and

communication technology applications in architecture, engineering, and construction

organizations: a 15-year review. Journal of Management in Engineering, 31(1),

4014010.

Pauwels, P, Zhang, S and Lee, Y (2016) Semantic web technologies in the AEC industry: A

literature review. Automation in Construction, 73, 145-165.

Peansupap, V and Walker, D H T (2005) Factors enabling information and

communication technology diffusion and actual implementation in construction

projects. Construction Management and Economics, 24(3), 321 332.

Saldaña, J (2015) The Coding Manual for Qualitative Researchers. London: Sage


Samuelson, O and Björk, B C (2011) Adoption Processes for EDM, EDI and BIM in the

Construction Industry. Journal of Civil Engineering and Management, 19, 172

187.

Sulankivi, K (2004) Benefits of centralized digital information management in multipartner

projects. Journal of Information Technology in Construction, 9, 35-63.

Timmermans, S and Epstein, S (2010) A world of standards but not a standard world:

Toward a sociology of standards and standardization. Annual Review of

Sociology, 36, 69-89

Turk, Z (2001) Phenomenologial foundations of conceptual product modelling in

architecture, engineering and construction. Artificial Intelligence in Engineering,

2(15), 83-92

Yin, R K (2014) Case Study Research Design and Methods. 5ed. London: Sage

Title Introductie van een uniform objectmodel voor het beheer en onderhoud van

ondergrondse infrastructuur

Author Ramon ter Huurne

Type Congress

Congress CROW Infradagen 2018, Arnhem, the Netherlands, 27-28 June 2018

Published Yes

Presented Yes

Language Dutch

Introductie van een uniform objectmodel voor het beheer en onderhoud van ondergrondse infrastructuur

Ir. R.B.A. ter Huurne

Universiteit Twente

Samenvatting Het digitaliseren van bouwactiva is een veelbesproken onderwerp in de

bouwsector. Om de interoperabiliteit en uitwisselbaarheid van digitale modellen te garanderen,

kent de sector datastandaarden zoals IFC en CityGML. Echter, voor de ondergrondse


infrastructuur bestaan dergelijke datastandaarden slechts in beperkte mate. Bovenal voldoen

deze standaarden niet aan de toenemende informatiebehoefte van organisaties binnen de

nutssector om hun assets te beheren en onderhouden. Op basis van een observerende studie van

de digitale werkpraktijken van twaalf netbeheerders werd duidelijk dat om aan de

informatiebehoefte te kunnen voldoen, netbeheerders hun eigen objectmodellen en

datastandaarden configureren. Een vergelijk tussen deze organisatorische standaarden toont

verschillen in hoe domeinkennis wordt gemodelleerd. De verschillende wijzen waarop

‘realiteiten’ worden gemodelleerd, verminderen de interoperabiliteit en uitwisselbaarheid van

informatie in de sector. Een uniform datamodel voor het beheer en onderhoud van ondergrondse

infrastructuur zou uitwisselbaarheid van informatie en gebruik van digitale beheersystemen in

BIM en GIS kunnen vergroten. Deze paper licht dit standpunt toe en bespreekt de standaard die

momenteel aan de Universiteit Twente wordt ontwikkeld.

Steekwoorden Ondergrondse infrastructuur, beheer en onderhoud, objectmodel, ontologie,

datastandaard

1. Introductie

Building Information Modelling (BIM) is momenteel een veelbesproken onderwerp in

literatuur en beleidstukken (Bradley et al. 2016; Lu et al. 2015; Pauwels et al. 2016). BIM kan

gedefinieerd worden als een gedeelde digitale representatie van de fysieke en functionele

karakteristieken van een bouwobject (ISO 29481 2010) . Kenmerkend voor BIM modellen is

dat zij parametrisch en object-georiënteerd zijn. Implementatie van BIM heeft het ontstaan van

zogenoemde digitale ‘tweelingen’ als resultaat. Deze digitale tweelingen weerspiegelen het

werkelijke object middels een virtuele reconstructie, bijvoorbeeld in een ‘BIM systeem’. Om

de communicatie tussen dergelijke BIM systemen te faciliteren zijn datastandaarden

(objectmodellen) als de Industry Foundation Classes (IFC) (buildingSMART) geïntroduceerd

(Turk 2001).

Daar waar BIM met name wordt toegepast in de bouwsector, worden voor het modelleren van

ruimtelijke gegevens vooral Computer Aided Design (CAD) en Geographic Information

Systems (GIS) toegepast. Voor ruimtelijke gegevens bestaat de datastandaard CityGML (Open

Geospatial Consortium). Zowel IFC als CityGML worden geleidelijk aan geaccepteerd en

gebruikt als de dominante manier om domeinkennis te modelleren en gegevens uit te wisselen

tussen digitale systemen.

Echter, in tegenstelling tot de bouwsector zijn gemeenschappelijke objectmodellen voor andere

grote typen van infrastructuur, zoals transport en ondergrondse infrastructuur (Bradley et al.

2016) slechts in beperkte mate ontwikkeld. Zonder gemeenschappelijke objectmodellen is de

interoperabiliteit en uitwisselbaarheid van gegevens beperkt, omdat gebruikers geen afspraken

gemaakt hebben over hoe zij bepaalde objecten noemen, beschrijven en visualiseren. Dit kan

leiden tot verwarring en miscommunicatie indien gegevens toch uitgewisseld worden.

Vanuit deze gedachte werkt de Universiteit Twente aan een uniform objectmodel voor

ondergrondse infrastructuur, specifiek voor het domein van beheer en onderhoud. Daar waar

voor ondergrondse infrastructuur wel enkele objectmodellen bestaan, zoals het

Informatiemodel Kabels en Leidingen (IMKL) (Geonovum 2017) zijn deze vrij summier in het

beschrijven van beheer en onderhoud gerelateerde informatie. Echter, door informatie over

kabels en leidingen op een consistentie en complete manier vast te leggen, worden digitale


modellen beter bruikbaar voor beheer en onderhoud. Dit kan leiden tot efficiëntere

beheerprocessen.

Deze paper beschrijft een selectie van bestaande objectmodellen voor ondergrondse

infrastructuur en legt uit waarom één uniform objectmodel voor de uitwisseling van kabels- en

leidingdata voor het domein van beheer en onderhoud nodig is. Daartoe wordt allereerst de

invloed van digitalisering op het modelleren van asset data in het algemeen besproken. Daarna

worden bestaande initiatieven tot datastandaardisatie voor ondergrondse infrastructuur

uiteengezet op internationaal, nationaal en organisatorisch niveau. Dit leidt tot het bespreken

van de behoefte aan een uniform objectmodel. De paper eindigt met conclusies en

aanbevelingen voor vervolgonderzoek.

2. Een digitaal tijdperk

Sinds de opkomst van het digitale tijdperk, zijn digitale modellen bijna niet meer weg te denken

in de bouwsector. CAD, GIS en BIM systemen worden door tal van partijen binnen de

bouwsector inmiddels ingepast ter realisatie van de digitale ‘tweeling’.

2.1 Ontwikkeling: digitale ‘tweelingen’ van bouwobjecten

Het toepassen van technologie in bouwprojecten kan helpen in het verbeteren van de inter-

organisatorische communicatie, coöperatie en coördinatie (Adriaanse et al. 2010; Peansupap en

Walker 2005). Het digitaliseren van bouwactiva – en daarbij een digitale ‘tweeling’ – geschiedt

middels het proces van het definiëren van de concepten, attributen en hun relaties van een

betreffend bouwobject. Voor dit digitalisering-proces wordt gebruik gemaakt van met name

GIS en BIM systemen en in beperkte mate CAD systemen.

CAD systemen worden gebruikt voor het ontwerpen en visualiseren van, onder andere,

bouwactiva, in zowel 2D als 3D. CAD is sterk gefocust op het tekenen van gedetailleerde

modellen, bestaande uit punten, lijnen en polygonen. Kenmerkend voor CAD modellen is dat

zij geen topologie hebben en niet gekoppeld zijn aan objectbibliotheken en databases. Daarmee

is een CAD systeem minder geschikt voor het modelleren van digitale ‘tweelingen’.

GIS systemen zijn informatiesystemen die worden toegepast om (ruimtelijke) informatie over

geografische objecten op te slaan en daarbij te beheren, bewerken, analyseren en presenteren.

Ook bevatten GIS systemen, in tegenstelling tot CAD systemen, over een topologisch model

van punten, lijnen en polygonen, daarbij mogelijk object-georiënteerd en gelinkt aan een

objectbibliotheek en database. Hierdoor ‘begrijpt’ een GIS model de onderlinge relaties tussen

de gemodelleerde concepten en relaties en worden analyses op data mogelijk.

BIM systemen zijn informatiesystemen die worden toegepast voor het modelleren van alle

fysieke en functionele kenmerken van een gebouw. Kenmerkend voor een BIM model is, is dat

zij een gedeelde kennisbron is voor de informatie van het betreffende gebouw gedurende de

gehele levenscyclus. Daarnaast zijn BIM modellen object-georiënteerd, middels de koppeling

met een objectbibliotheek, op basis van een van een topologisch model. Dit betekent dat

verschillende partijen die in het BIM model werken, hun informatie aan het gelijke object

kunnen koppelen, wat niet alleen geometrische informatie behelst, maar ook non-geometrische

informatie zoals kosten en planning gerelateerd informatie. BIM modellen genereren daardoor

een rijke set aan asset data.

Hoewel BIM en GIS systemen een ander doel dienen, zijn beiden uitermate geschikt voor het

realiseren van een digitale ‘tweeling’ voor respectievelijk bouwactiva en geografische objecten.


De rijke set aan informatie die deze systemen kunnen genereren, biedt de mogelijkheid het

digitale model zo nauwkeurig mogelijk te beschrijven en aan te laten sluiten op de realiteit.

2.2 Gevolg: explosie van data

Een herkenbare trend in de bouwsector is de groeiende aandacht voor de

levenscyclusbenadering van assets (Bradly et al. 2016). Waar men voorheen alleen

objectlocaties digitaliseerde, vereist men tegenwoordig al meer digitale informatie voor het

beheer en onderhoud. Zo worden tegenwoordig bijvoorbeeld ook materiële, dimensionele,

kosten en planning gerelateerde informatie opgeslagen. Men refereert ook wel naar deze

ontwikkeling als ‘de explosie van data’. Om deze data op te slaan wordt gebruik gemaakt van

bouwobject- of geografische informatiesystemen.

De verschuiving naar een levenscyclusbenadering van assets gaat idealiter uit van

domeinkennis die bestaat uit een consistente en complete set aan concepten en relaties. Het

faciliteren van domeinkennis op een

dergelijke consistente en complete

manier vraagt om standaardisatie.

Voor BIM gerelateerde systemen is

dat IFC voor gebouwen. Voor GIS

gerelateerde systemen bestaat onder

andere CityGML voor stedelijke

informatie. Deze standaarden

schrijven een uniforme structuur en

naamgeving voor gerelateerde

domeinkennis voor. In het geval van

IFC wordt bijvoorbeeld een ‘deur’

(IfcDoor) gemodelleerd als gepresenteerd in figuur 1 (buildingSMART 2016). In figuur 1 is

‘IfcDoor’ onderdeel van bovengelegen klassen, waaronder ‘IfcBuildingElement’. Daarnaast,

niet gevisualiseerd in de figuur, heeft elk van de klassen een lijst aan attributen, en wordt binnen

IFC elk van de klassen en attributen middels een eenduidige definitie beschreven.

Een gemeenschappelijk objectmodel als IFC helpt in het systematisch vastleggen van

domeinkennis in een consistente en complete manier. IFC verbetert daarmee de

interoperabiliteit en uitwisselbaarheid van gebouw-gerelateerde digitale informatie. Echter,

voor ondergrondse infrastructuur zijn dergelijke gemeenteschappelijke objectmodellen in

slechts beperkte mate ontwikkeld.

3. Modelleren van ondergrondse infrastructuur

Het modelleren van ondergrondse infrastructuur heeft zich lange tijd beperkt tot het gebruik

van CAD omgevingen. Gezien de beperkte toepasbaarheid van CAD voor het opslaan van

informatie, omvatten deze CAD modellen vaak niet meer dan geometrische informatie.

Vanwege de toenemende complexiteit en omvang van netinformatie – gestimuleerd door de

groeiende aandacht voor de levenscyclusbenadering – wordt ondergrondse infrastructuur

tegenwoordig steeds vaker gemodelleerd in GIS georiënteerde omgevingen. Echter, zoals

Bradley et al. (2016) aangeven, zijn gemeenschappelijke dataformaten voor ondergrondse

infrastructuur slechts in beperkte mate ontwikkeld. Standaardisatie initiatieven die al wél

bestaan, worden in de volgende paragrafen op nationaal, internationaal en organisatorisch

niveau beschreven.

Figuur 1 – Modelleren van een ‘deur’ volgens IFC

IFC


3.1 Nationale en internationale initiatieven

Op basis van verkregen informatie uit een literatuurstudie is vergeleken welke initiatieven tot

standaardisatie van ondergrondse infrastructuur momenteel bestaan. Deze paper presenteert een

selectie van enkele bekende initiatieven, op zowel nationaal als internationaal niveau. Een

overzicht van deze geselecteerde initiatieven is gepresenteerd in tabel 1. Meerdere initiatieven

bestaan, maar worden in deze paper niet toegelicht.

Tabel 1 – Overzicht van een selectie van nationale en internationale initiatieven Naam Toepassingsgebied Doel

INSPIRE Europa Vergroten van interoperabiliteit en uitwisselbaarheid

van ruimtelijke gegevens tussen Europese lidstaten.

CityGML

UtilityNetwork ADE

Wereld Modelleren van ondergrondse infrastructuur in 3D

stadsmodellen.

IMKL Nederland Vergroten van interoperabiliteit en uitwisselbaarheid

van ruimtelijke gegevens tijdens

graafwerkzaamheden.

PAS 256 Verenigd Koninkrijk Verbeteren van de kwaliteit, nauwkeurigheid en

betrouwbaarheid van bestaande netinformatie.

INSPIRE (Infrastructure for Spatial Information in Europe) (European Commission 2013) is

een Europese richtlijn gericht op het creëren van een Europese infrastructuur waarover lidstaten

ruimtelijke gegevens uitwisselen. Doel hierbij is het vergroten van de interoperabiliteit en

uitwisselbaarheid van ruimtelijke gegevens. INSPIRE omvat dataspecificaties voor een breed

spectrum aan ruimtelijke gegevens, waarvan ondergrondse infrastructuur er één is. De INSPIRE

richtlijn beschrijft hoe ondergrondse infrastructuur middels concepten en relaties beschreven

dient te worden. CityGML UtilityNetwork ADE (Application Domain Extension) is een

extensie op CityGML (Open Geospatial Consortium 2012) en is gericht op het modelleren van

ondergrondse infrastructuur in 3D stadsmodellen. De standaard kan toegepast worden over de

gehele wereld. Als extensie op CityGML beschrijft de UtilityNetwork ADE de concepten en

relaties benodigd om ondergrondse infrastructuur te beschrijven binnen CityGML. Het IMKL

(Informatiemodel Kabels en Leidingen) (Geonovum 2017) is een Nederlands initiatief en

beschrijft concepten en relaties benodigd voor het vastleggen van netinformatie, om daarmee

de interoperabiliteit en uitwisselbaarheid van netinformatie tussen netbeheerders te vergroten.

Middels een centraal platform bij het Kadaster voorziet het IMKL netbeheerders van een

uniforme manier om netinformatie uit te wisselen in geval van graafwerkzaamheden. De PAS

(Publically Available Specification) 256 (British Standards Institution 2017) is een richtlijn

afkomstig uit het Verenigd Koninkrijk die helpt in het vastleggen, opnemen, onderhouden en

delen van locatiegegevens en gegevens van ondergrondse infrastructuur. De richtlijn heeft als

doel de kwaliteit, nauwkeurigheid en betrouwbaarheid van bestaande netinformatie te

verbeteren bij uitwisseling van dergelijke informatie.

Wanneer deze standaarden vergeleken worden met de informatiebehoefte vanuit het domein

van beheer en onderhoud, wordt duidelijk dat bestaande standaarden deze informatiebehoefte

niet kunnen beschrijven. Gezien het doel van de standaarden – welke niet het beheer en

onderhoud van ondergrondse infrastructuur betreft – is dit ook niet verwonderlijk. In het

algemeen beschrijven deze initiatieven wel de locatie, het thema, de dimensies en het materiaal,

maar missen zij specifieke gegevens zoals bijvoorbeeld het type van bepaalde objecten, kosten

en planning gerelateerde attributen alsook onderhoudsgegevens. Het gevolg hiervan is dat men

organisatorische initiatieven gaat ontwikkelen.

3.2 Organisatorische initiatieven


Gezien nationale en internationale standaarden niet aan de informatiebehoefte voldoen die

tegenwoordig in de nutssector vereist wordt, beslaat een overgroot deel van de manier waarop

de ondergrondse infrastructuur wordt gemodelleerd organisatorische initiatieven. Middels een

observatie van de werkpraktijken van twaalf netbeheerders is gebleken dat netinformatie wordt

vastgelegd volgens (1) software standaarden / configuraties of (2) standaarden / configuraties

van netbeheerders zelf. Binnen deze standaarden worden de concepten en relaties die relevant

geacht voor het beheer en onderhoud van ondergrondse infrastructuur opgenomen.

Bij een vergelijk van de geobserveerde organisatorische standaarden valt op dat concepten en

relaties beschreven worden middels verschillende (1) attributen, formats en relaties, en (2)

semantiek. Netbeheerders schrijven hun eigen objectmodel voor, gebaseerd op hun eigen

werkpraktijken. Een verschil in hoe netbeheerders de structuur van hun netten modelleren, is

bijvoorbeeld het specificeren van het type net als attribuut of als een eigen klasse. Meer

specifiek, in het geval van glasvezel kan er bijvoorbeeld gekozen worden om dit als attribuut

bij een telecom net te modelleren, of het te modelleren als een eigen klasse en daarmee

glasvezelnet. Een simpel voorbeeld voor een verschil in semantiek is bijvoorbeeld het

beschrijven van de x- en y-coördinaat van een object middels de term ‘ligging’ en de term

‘locatie’. In beide gevallen is de intrinsieke betekenis gelijk, maar gebruiken netbeheerders een

verschillende term om dit te beschrijven.

Tezamen kunnen dergelijke verschillen leiden tot verwarring en miscommunicatie indien de

netinformatie wordt uitgewisseld met andere partijen. Interoperabiliteit van netinformatie blijft

daarmee een groot probleem. Ploeger et al. (2005) formuleert de grote verscheidenheid in

datastandaardisatie van ondergrondse infrastructuur dan ook wel als “de chaos in de bodem”.

4. Behoefte aan een uniform objectmodel

Daar waar de bouwsector digitale gestandaardiseerde objectmodellen kent – zoals voor

gebouwen in de vorm van IFC – ontbreekt een dergelijke standaard voor de ondergrondse

infrastructuur. Vele initiatieven, voornamelijk op organisatorisch niveau, vergroten de

verscheidenheid in datastandaardisatie van ondergrondse infrastructuur en creëren daarmee een

“wereld van standaarden, maar niet een gestandaardiseerde wereld” (Timmermans en Epstein

2010). Om de interoperabiliteit en uitwisselbaarheid van asset data in de nutssector te

verbeteren, is het zaak af te spreken hoe de domein specifieke kennis van de nutssector voor

het beheer en onderhoud opgeslagen moet worden. Er is behoefte aan één uniform objectmodel.

4.1 Het standaardiseren van domeinkennis

Het doel van standaardisatie, in het algemeen, is het vastleggen van de ‘realiteit’ en daarmee

het creëren van uniformiteit tussen culturen, tijd en geografie. Het vastleggen van deze realiteit

gebeurt middels afgesproken regels, ook wel aangeduid als een standaard (Timmermans en

Epstein 2010). Standaarden komen daarbij in vele vormen voor (Bowker en Star 1999),

waaronder datastandaarden die relevant zijn binnen de context van deze paper.

De vraag is echter hoe een dergelijke realiteit gevangen kan worden in een datastandaard voor

het beheer en onderhoud van ondergrondse infrastructuur. De grote verscheidenheid in

organisatorische objectmodellen zoals eerder beschreven toont aan dat er vele verschillende

percepties op de realiteit bestaan. De intentie en interpretatie van domeinkennis zijn daarom


van grote relevantie wanneer een realiteit in een standaard gevangen moet worden, omdat de

betekenis zowel door de auteurs als de gebruikers van de standaarden gevormd kan worden.

Eenmaal geëxpliciteerd in een tekstuele vorm kunnen realiteiten daarom verschillende

plausibele interpretaties hebben (Turk 2001).

Naar een datastandaard kan ook gerefereerd worden als een ‘ontologie’. Een ontologie

beschrijft de wereld als gezien door een groep personen op een bepaalde tijd, volgens een school

van denken die gebaseerd is op een reeks fundamentele proposities of wereldbeelden (El-Diraby

en Osman 2011). Simpel gezegd is een ontologie een model of structuur van kennis. Eenmaal

geadopteerd, representeert een ontologie domeinkennis – en daarmee de ‘realiteit’ – in een

verenigde, vereenvoudigde en consistente manier. Binnen een ontologie wordt de taxonomie

en vocabulaire van de domeinkennis vastgelegd. De taxonomie beschrijft de hiërarchische

categorisatie / classificatie van de concepten. De vocabulaire beschrijft de terminologie en

naamgeving van de concepten, om semantische diversiteit te voorkomen (Gasevic et al. 2009).

Terugkijkend naar figuur 1 kan een uniforme taxonomie en vocabulaire ook in IFC herkend

worden.

Het gebruik van een ontologie is zodanig een uitstekend middel om de kennis benodigd voor

het domein van beheer en onderhoud voor ondergrondse infrastructuur vast te leggen in een

uniforme realiteit. Met andere woorden, aan de basis van een uniforme realiteit benodigd voor

een uniforme standaard, staat een ontologie waarin de concepten en relaties voor het domein

van beheer en onderhoud van ondergrondse infrastructuur zijn opgenomen.

Voor het verkrijgen van de domeinkennis is het van groot belang dat de meest representatieve

kennis vergaard wordt. Binnen het project aan de Universiteit Twente – waarin een ontologie

voor het domein van beheer en onderhoud voor ondergrondse infrastructuur wordt ontwikkeld

– wordt dit bewerkstelligd door eindgebruikers van de ontologie nauw te betrekken bij de

ontwikkeling. Hiermee wordt getracht de uniforme realiteit binnen de ontologie zo goed

mogelijk te laten aansluiten bij de verschillende percepties op de realiteit die de nutssector nu

kenmerkt. Dit vergemakkelijkt adoptie en implementatie van de ontologie.

Ter illustratie toont figuur 2 een

snapshot van de ontologie die

momenteel ontwikkeld wordt aan

de Universiteit Twente. De

ontologie is gebaseerd op het

CityGML UtilityNetwork ADE

objectmodel en is daar waar

nodig aangepast dan wel

uitgebreid met de relevante

concepten en relaties voor het

domein van beheer en

onderhoud. De ontologie is

gevisualiseerd in de Unified

Modelling Language (UML)

welke ook toegepast wordt in de

UtilityNetwork ADE, maar

tevens in bijvoorbeeld INSPIRE

en het IMKL. Figuur 2 toont hoe

een ‘Cable’ (kabel) en ‘Pipe’

(leiding) gemodelleerd kunnen

worden en toont de

verscheidene attributen die beide objecten bevatten zoals ‘materialType’

(materiaaleigenschappen) en ‘class’ (type kabel of leiding). Een kabel of leiding is binnen de

Figuur 2 – Snapshot van de ontologie ontwikkeld door de

Universiteit Twente


ontologie een ‘AbstractDistribution’ (distributie) element. Deze snapshot toont slechts een klein

gedeelte van de ontologie. Daarnaast is de ontologie in ontwikkeling wat betekent dat het model

nog aan mogelijke wijzigingen onderhevig is.

4.2 Voordelen: meer dan interoperabiliteit alleen

Het opstellen van één uniforme standaard – de ontologie – biedt de nutssector meerdere

voordelen. Allereerst helpt het in het overbruggen van de kloof tussen alle verschillende

organisatorische standaarden die de nutssector nu kenmerkt. Eén uniforme datastandaard helpt

om deze realiteiten op elkaar aan te laten sluiten. Dit vergroot de interoperabiliteit en

uitwisselbaarheid van data binnen de sector en helpt verwarring en miscommunicatie in de

werken van de sector voorkomen.

Ten tweede helpt een uniforme standaard in het versnellen van de ontwikkelingen van software

ontwikkelaars. Gekeken naar IFC en de toepassing hiervan in verschillende BIM gerelateerde

software, zoals Autodesk Revit, is het voor software ontwikkelaars gemakkelijker om hun

software te optimaliseren indien deze gebaseerd is op één uniforme datastandaard. Software

kan op deze manier ‘slimmer’ worden gemaakt door bijvoorbeeld specifieke simulaties aan te

bieden die analyses maken van de onderhoudsdata die wordt opgeslagen. Nu gebeurt het

configureren van software (bijna) geheel binnenshuis bij de gebruikers zelf. Een integrale

aanpak op basis van één uniforme standaard kan het optimaliseren van software versnellen.

Ten derde draagt een standaard voor de nutssector mogelijk ook bij aan de versnelde adoptie

en integratie van BIM en GIS systemen voor de ondergrond. In de literatuur (Bormann et al.

2014; Cheng et al. 2013; Hor et al. 2016) wordt de integratie van GIS en BIM als een grote

uitdaging gezien, vanwege syntactische en semantische verschillen tussen beiden domeinen.

Syntactisch refereert naar de opbouw en structuur van de data. Semantisch refereert naar de

betekenis van de data. Een uniforme standaard voor de nutssector draagt met name bij aan de

syntactische integratie. Om semantische verschillen te overbruggen wordt de laatste jaren veel

onderzoek gedaan naar ‘semantic web’ technologie (Pauwels et al. 2016).

5. Conclusies en vervolgonderzoek

Deze paper biedt een kijk in de spreekwoordelijke keuken van het modelleren van ondergrondse

infrastructuur. Het digitale tijdwerk waarin we ons bevinden, tezamen met een groeiende

aandacht voor de levenscyclusbenadering, heeft geleid tot een explosie van data binnen het

beheer en onderhoud van ondergrondse infrastructuur. Daar waar de verschuiving naar een

levenscyclusbenadering van assets idealiter uit gaat van domeinkennis bestaande uit een

consistente en complete set aan concepten en relaties, toont de praktijk grote verschillen.

De aanwezigheid van organisatorische – en daarbij uiteenlopende – standaarden impliceert dat

de nutssector op het moment een uniforme digitale modelleer standaard mist. Netbeheerders

modelleren netinformatie volgens hun eigen ‘realiteit’. Dit hindert de interoperabiliteit en

uitwisselbaarheid van netinformatie in de nutssector. Bovendien belemmert het software

ontwikkelaars om informatiesystemen gebruikt binnen het beheer en onderhoud van

ondergrondse infrastructuur op elkaar te laten aansluiten.

Deze paper zet aan tot het ontwikkelen van één uniforme datastandaard voor het domein van

beheer en onderhoud van ondergrondse infrastructuur. Als basis voor een dergelijke standaard

wordt het gebruik van een ontologie voorgesteld. Een ontologie representeert domeinkennis –

en daarmee de ‘realiteit’ – in een verenigde, vereenvoudigde en consistente manier. Een

ontologie helpt daarmee in het overbruggen van de kloof tussen organisatorische standaarden,


in het versnellen van software optimalisatie en mogelijk in de integratie van BIM en GIS

gerelateerde domeinen.

Adoptie van een uniforme datastandaard door de nutssector zal mogelijk in eerste instantie met

enige aarzeling verlopen. Tenslotte, het doorbreken van huidige routines en werkpraktijken kan

een kostbaar en tijdrovend proces zijn. Echter, de voordelen van één uniforme datastandaard

zullen op de lange termijn de gehele nutssector naar een hoger plan tillen. Deze paper tracht de

bewustwording van de huidige problematiek te vergroten en de sector aan te zetten tot het

investeren in uniformering van netinformatie.

Het ontwikkelen van een datastandaard voor de ondergrondse infrastructuur binnen het project

van de Universiteit Twente zal eind 2018 tot een einde komen. De paper roept daarom op tot

vereniging van netbeheerders om verdere ontwikkeling en adoptie van één uniforme standaard

te stimuleren.

6. Referenties

Adriaanse, A, Voordijk, H en Dewulf, G (2010) Adoption and Use of Interorganizational

ICT in a Construction Project. Journal of Construction Engineering and

Management, 136(9), 1003-1014.

Bormann, A, Kolbe, T H, Donaubauer, A, Steuer, H, Jubierre, J R en Flurl, M (2015) Multi

Scale Geometric-Semantic Modeling of Shield Tunnels for GIS and BIM

Applications. Computer-Aided Civil and Infrastructure Engineering, 30, 263-281.

Bower, G en Star, S L (1999) Sorting Things Out. Cambridge, MA: MIT Press.

Bradley, A, Haijiang, L, Lark, R en Dunn, S (2016) BIM for infrastructure: An overall

review and constructor perspective. Automation in Construction, 71, 139-152.

British Standards Institution (2017) PAS 256:2017. BSI Standards Limited 2017.

buildingSMART (2016) Industry Foundation Classes Version 4 – Addendum 2. Opgehaald

van http://www.buildingsmart-tech.org/ifc/IFC4/Add2/html/.

Cheng, J C P, Deng, Y en Du, Q (2013) Mapping Between BIM Models and 3D GIS City

Models of Different Levels of Detail. 13th International Conference of Construction

Applications of Virtual Reality, 30-31.

El-Diraby, T E en Osman, H (2011) A domain ontology for construction concepts in urban

infrastructure projects. Automation in Construction, 20(8), 1120-1132.

European Commission (2013) D2.8.III.6 INSPIRE Data Specification on Utility and

Government Services – Technical Guidelines.

Gasevic, D, Djuric, D en Devedzic, V (2009) Model Driven Engineering and Ontology

Development. New York, NY: Springer.

Geonovum (2017) IMKL2015 – Dataspecificatie Utiliteitsnetten.

Hor, A-H, Jadidi, A en Sohn, G (2016) BIM-GIS Integrated Geospatial Information Model

Using Semantic Web and RDF Graphs. ISPRS Annals of the Photogrammetry,

Remote Sensing and Spatial Information Sciences, 3(4), 73-79.

ISO 29481 (2010) ISO 29481-1-201(E) Building Information Modeling – Information

Delivery Manual – Part 1.

Lu, Y, Li, Y, Skibniewski, M, Wu, Z, Wang, R en Le, Y (2015) Information and

communication technology applications in architecture, engineering, and construction

organizations: a 15-year review. Journal of Management in Engineering, 31(1),

4014010.

Pauwels, P, Zhang, S en Lee, Y (2016) Semantic web technologies in the AEC industry: A

literature review. Automation in Construction, 73, 145-165.


Peansupap, V en Walker, D H T (2005) Factors enabling information and communication

technology diffusion and actual implementation in construction projects. Construction

Management and Economics, 24(3), 321-332.

Ploeger, H, Loenen, B, van, Kap, A, P en Stoter, J, E (2005) Kabels en leidingen: de chaos in

de bodem. Nederlands Juristenblad, 23, 1186-1191.

Timmermans, S en Epstein, S (2010) A world of standards but not s standard world:

Toward a sociology of standards and standardization. Annual Review of Sociology,

36, 69-89.

Turk, Z (2001) Phenomenologial foundations of conceptual product modelling in

architecture, engineering and construction. Artificial Intelligence in Engineering,

2(15), 83-92.

pdeng final reportspecification of the range of allowable cardinalities that a set may assume [iso...

Documents