water analytics and intelligent sensing for demand...

Small or medium-scale focused research project (STREP) FP7-ICT-2013-11

Water analytics and Intelligent Sensing for Demand Optimised Management

WISDOM

Project Duration: 2014.02.01 – 2017.01.31

Grant Agreement number: 619795

Collaborative Project

WP2

D2.2 CU

WISDOM Water Semantic Models

Submission Date (intermediate version): 02.06.2016

Due Date:

01.06.2016

Status of Deliverable: DrA WoD ReL DeL AppR

Nature of Deliverable:

R P D O

Dissemination Level: PU PP RE CO

Project Coordinator: Daniela BELZITI Tel: +33 4 93 95 64 14 Fax: +33 4 93 95 67 33 E-mail: [email protected] Project website: www.wisdom-project.eu

http://www.wisdom-project.eu/

WISDOM

D2.2 – WISDOM Water Semantic Models 2

Small or medium-scale focused research project (STREP) FP7-ICT-2013-11 – GA: 619795

DOCUMENT INFORMATION

Submission Date:

Version: V2

Author(s): Shaun Howell (CU)1

Contributor(s): Alberto Musetti (DAPP)2

Reviewer(s): Yacine Rezgui (CU), Thomas Beach (CU), Eugene Ryan (Intel), Keith Ellis (Intel)

1 Sole author and primary contributor

2A contribution is recognised of background information provision, and elicitation of feedback regarding the Italian pilot site of the WISDOM project

WISDOM



DOCUMENT HISTORY

Date Version Name Remark

27/10/15 1.0 Shaun Howell [CU] Preliminary version of deliverable completed

27/10/15 1.1 Mathew Preece [CCC] Preliminary Review

11/5/16 1.2 Shaun Howell [CU] Knowledge base section and inference section drafted

16/5/16 1.3 Shaun Howell [CU] Document updated to be coherent with recent progress

24/5/16 1.4 Shaun Howell [CU] Final draft prepared for PSC review

31/5/16 1.5 Eugene Ryan [Intel] Review comments

31/5/16 1.6 Keith Ellis [Intel] PTC review comments

31/5/16 1.7 Shaun Howell [CU] Comments incorporated into final version for delivery

WISDOM



COPYRIGHT

© Copyright 2014 WISDOM Consortium consisting of CSTB, DAPP, CU, CCC, ASP, SAT, INTEL, ICL, ADV, IDRAN.

This document may not be copied, reproduced, or modified in whole or in part for any purpose without written permission from the WISDOM Consortium. In addition to such written permission to copy, reproduce, or modify this document in whole or part, an acknowledgement of the authors of the document and all applicable portions of the copyright notice must be clearly referenced.

All rights reserved.

WISDOM



TABLE OF CONTENTS

Document Information ............................................................................................................... 2

Document History ....................................................................................................................... 3

Copyright .................................................................................................................................... 4

Table of Contents ........................................................................................................................ 5

List of Figures .............................................................................................................................. 9

List of Tables ............................................................................................................................. 11

Abbreviations ........................................................................................................................... 12

Industrial Foreword .................................................................................................................. 13

Executive Summary .................................................................................................................. 14

1. Introduction ....................................................................................................................... 15

1.1. Semantic Models in Water Management ....................................................................................... 15

1.2. Introduction to Ontologies .............................................................................................................. 18

1.3. The Role of the WISDOM Project’s Semantic Models ..................................................................... 20

1.4. Document Summary ....................................................................................................................... 21

2. Methodology ..................................................................................................................... 22

2.1. Knowledge Acquisition & Product Specification ............................................................................. 24

2.2. Developing a Meta-Model from Reusable Ontologies .................................................................... 24

2.3. Developing WISDOM Ontology ....................................................................................................... 24

2.3.1. Enumerating Concepts .......................................................................................................... 24

2.3.2. Class Hierarchy Design and Alignment .................................................................................. 25

2.3.3. Object Property Slots ............................................................................................................ 25

2.3.4. Data Property Slots ............................................................................................................... 25

2.3.5. Restrictions ........................................................................................................................... 26

2.4. Instantiating Pilot Site Knowledge Bases ........................................................................................ 26

2.5. Deployment as a Web Service ......................................................................................................... 26

2.6. Preliminary Validation ..................................................................................................................... 27

2.7. Development of Inference Engine ................................................................................................... 27

2.8. Validation within WISDOM Platform ............................................................................................... 28

3. Requirement Specification ................................................................................................. 29

WISDOM



3.1. Ontology Scoping & Competency Questions .................................................................................. 29

3.2. Software Implementation Requirements ........................................................................................ 30

4. Ontology Domain Models .................................................................................................. 32

4.1. Domain Independent Meta-Model ................................................................................................. 32

4.2. Water Catchment Information Model ............................................................................................. 33

4.2.1. The Water Value Chain Processes ......................................................................................... 34

4.2.2. Water Network Model .......................................................................................................... 35

4.2.3. Natural Water Artefacts ........................................................................................................ 39

4.2.4. Supply-Side artefacts ............................................................................................................ 41

4.2.5. Domestic Artefacts ................................................................................................................ 44

4.3. Sensor Ontology .............................................................................................................................. 46

4.3.1. Sematic Sensor Network Extension ...................................................................................... 46

4.3.2. Data Enrichment & WCIM Links ............................................................................................ 50

4.3.3. Modelling patterns for KairosDB-Ontology integration ........................................................ 51

4.3.4. Problems and alerts .............................................................................................................. 52

4.4. Water Value Chain Social Model ..................................................................................................... 52

4.4.1. Social Network Model ........................................................................................................... 53

4.4.2. Water Management Stakeholders ........................................................................................ 57

4.4.3. Supply-Side Relationships ..................................................................................................... 57

4.4.4. Domestic Social Relationships............................................................................................... 58

4.4.5. Supply Side Socio-Technical Relationships ............................................................................ 61

4.4.6. Domestic Socio-Technical Relationships ............................................................................... 63

4.4.7. Economic Concepts & Relationships ..................................................................................... 64

4.5. WISDOM Domain Ontology Validation ........................................................................................... 64

4.6. Integration with Existing Standards and Ontologies ....................................................................... 66

4.6.1. Alignment with WatERP Ontology ........................................................................................ 66

4.6.2. Alignment with the Industry Foundation Classes ................................................................. 70

4.6.3. Alignment with INSPIRE ........................................................................................................ 71

4.6.4. Placement within Existing Standards .................................................................................... 73

5. Pilot Site Knowledge Bases ................................................................................................ 74

WISDOM



5.1. Knowledge Base Introduction ......................................................................................................... 74

5.2. Methodology .................................................................................................................................. 75

5.3. Knowledge Base Results .................................................................................................................. 79

5.3.1. Cardiff Pilot Model ................................................................................................................ 80

5.3.2. Tywyn and Aberdovey Pilot Model ....................................................................................... 81

5.3.3. Gowerton Pilot Model .......................................................................................................... 82

5.3.4. Italian Pilot Model ................................................................................................................ 82

6. Inference and Rule Engine .................................................................................................. 84

6.1. Semantic Inference Introduction .................................................................................................... 84

6.2. Semantic Inference Architecture ..................................................................................................... 85

6.2.1. Jena Built-In Reasoner .......................................................................................................... 85

6.2.2. Pellet Inference Engine ......................................................................................................... 85

6.3. Inference Use Case Requirements .................................................................................................. 85

6.3.1. Sensing Capability Inference ................................................................................................. 86

6.3.2. Problem Detection and Alert Propagation ............................................................................ 87

6.4. SWRL Rules ..................................................................................................................................... 88


6.4.2. Problem Detection and Alert Propagation ............................................................................ 91

6.4.3. Ad-hoc Rules ......................................................................................................................... 95

6.5. Inference Use Case Testing ............................................................................................................. 96


6.5.2. Problem Detection and Alert Propagation .......................................................................... 100

7. Conclusion ....................................................................................................................... 105

8. References ....................................................................................................................... 106

Appendix A - Scoping and Competency Questions ................................................................... 109

Scenario 1 – Behaviour & Feedback ......................................................................................................... 109

Scenario 2 – Network Monitoring ............................................................................................................ 110

Scenario 3 – Household leakage ............................................................................................................... 111

Scenario 4 – Waste Predictive .................................................................................................................. 111

Scenario 5 – Advanced Devices ................................................................................................................ 112

Scenario 6 – Pumping Optimisation ......................................................................................................... 113

WISDOM



Scenario 7 – Network leakage .................................................................................................................. 113

Scenario 8 – Peak Reduction .................................................................................................................... 113

Scenario 9 - Energy Predictive .................................................................................................................. 114

Scenario 10 – Supply Predictive ................................................................................................................ 114

Scenario 11 – Reservoir Optimisation ....................................................................................................... 114

Scenario 12 - Crowdsourcing .................................................................................................................... 114

Appendix B - Full Object Property List ..................................................................................... 116

WISDOM



LIST OF FIGURES

Figure 1: BPMN diagram of semantic modelling activities ............................................................................. 23

Figure 2: Main reused concepts and relationships from the STS ontology ..................................................... 32

Figure 3: Excerpt of the meta-model for intelligent sensing in socio-technical systems ................................ 33

Figure 4: Main groups of concepts in the WCIM ............................................................................................ 34

Figure 5: Processes in the water value chain .................................................................................................. 34

Figure 6: Process model within a property ..................................................................................................... 35

Figure 7: Description of a generic node and its relevant data ........................................................................ 36

Figure 8: Description of a generic pipe and its relevant data ......................................................................... 37

Figure 9: Simple water value chain showing connection of nodes (labelled) and arcs (arrows) .................... 38

Figure 10: Main WCIM level classes and relationships ................................................................................... 39

Figure 11: Main WCIM classes and relationships relevant to natural water bodies ....................................... 40

Figure 12: Main supply side WCIM classes and relationships ........................................................................ 43

Figure 13: WCIM Domestic artefacts .............................................................................................................. 45

Figure 14: The W3C SSN ontology, simplified ................................................................................................. 46

Figure 15: OWL implementation of the SSN ontology .................................................................................... 47

Figure 16: The main class hierarchy extensions to the SSN ontology for WISDOM ........................................ 49

Figure 17: Key relationships between WCIM & Sensor Ontology concepts ................................................... 50

Figure 18: Mapping between KairosDB terms and WISDOM ontology terms ................................................ 51

Figure 19: Key concepts and relationships regarding network problems and alerts ...................................... 52

Figure 20: WVCSM class hierarchy of main social network entities ............................................................... 54

Figure 21: Example supply-side social network .............................................................................................. 55

Figure 22: Example domestic social network ................................................................................................. 56

Figure 23: WVCSM water management organization class hierarchy ............................................................ 57

Figure 24: WVCSM class hierarchy of supply side relationships ..................................................................... 58

Figure 25: WVCSM Domestic social relationship class hierarchy .................................................................... 59

Figure 26: WVCSM domestic properties ........................................................................................................ 60

Figure 27: Partial, fictitious example socio-technical network ....................................................................... 61

Figure 28: WVCSM socio-technical arc classes on both supply and demand side .......................................... 62

Figure 29: WVCSM main supply side social and socio-technical classes and relationships ............................ 63

WISDOM



Figure 30: WVCSM Consumption pattern concept and relevant object properties ....................................... 64

Figure 31: Example annotation showing slots for multi-lingual support, comments and alignments ............ 67

Figure 32: Alignments between WISDOM and other models and standards ................................................. 73

Figure 33: Representation of the separate knowledge base approach in WISDOM ....................................... 74

Figure 34: Main parts of the GIS - RDF conversion Python script ................................................................... 76

Figure 35: GIS entity database screenshot ..................................................................................................... 77

Figure 36: Exported CSV data from GIS entity database ................................................................................ 77

Figure 37: RDF/XML serialization from entity description in CSV format ....................................................... 78

Figure 38: 'CombinedWastePipe' instances and their properties, following conversion from CSV ................ 78

Figure 39: Input EPANET data ......................................................................................................................... 79

Figure 40: Jena inference architecture [15] .................................................................................................... 85

Figure 41: Explicitly stated knowledge regarding water meters and sensors at assets, from legacy systems 86

Figure 42: Required inference for the sensing capability use case ................................................................. 87

Figure 43: Problem detection and alert propagation inference use case requirements ................................ 88

Figure 44: Rules developed for sensing capability inference use case ........................................................... 89

Figure 45: Sensing capability inference test case instance ............................................................................. 98

Figure 46: Resultant explicit and inferred Abox knowledge from sensor capability inference testing ........... 99

Figure 47: Problem and alert inference test case illustration ....................................................................... 100

Figure 48: Instance of problem and alert inference requirements for test case .......................................... 102

Figure 49: Excerpt of resultant Abox knowledge after problem and alert inference testing ........................ 103

Figure 50: Key knowledge inferred and extendable through the alert and problem inference testing ........ 104

WISDOM



LIST OF TABLES

Table 1: Comparison of relevant existing semantic models ........................................................................... 17

Table 2: Subtypes of the generic node ........................................................................................................... 36

Table 3: Artefacts in each water value chain process ..................................................................................... 41

Table 4: Artefacts relevant to domestic water consumers ............................................................................. 44

Table 5: Descriptions of main ambiguous SSN classes ................................................................................... 47

Table 6: Example competency question testing evidence .............................................................................. 65

Table 7: Alignment of WISDOM and WatERP concepts .................................................................................. 67

Table 8: Main heterogeneity between WatERP ontology and WISDOM ........................................................ 69

Table 9: Potentially aligned WISDOM and IFC concepts ................................................................................. 70

Table 10: Aligned terms between the WISDOM ontology and the INSPIRE utility data models ..................... 72

Table 11: Summary of Cardiff pilot input data ............................................................................................... 80

Table 12: Summary of Cardiff pilot output knowledge base before inference ............................................... 80

Table 13: Summary of Tywyn and Aberdovey pilot input data ....................................................................... 81

Table 14: Summary of Tywyn and Aberdovey pilot output knowledge base before inference ...................... 81

Table 15: Summary of Gowerton pilot input data .......................................................................................... 82

Table 16: Summary of Gowerton pilot output knowledge base before inference .......................................... 82

Table 17: Summary of Italian pilot input data ................................................................................................ 83

Table 18: Summary of Italian pilot output knowledge base before inference ................................................ 83

Table 19: SWRL interpretations table, extended from W3C recommendation [36] ....................................... 88

WISDOM



ABBREVIATIONS

Acronym Full name

W3C World Wide Web Consortium

IDEF0 Integrated computer aided manufacturing definition for function modeling

SSN Semantic sensor network

SPARQL SPARQL Protocol and RDF Query Language

WVCSM Water value chain social model

WSSN Water semantic sensor network

STS Socio-technical systems

CSV Comma-separated value

PDF Portable Document Format

OWL Web Ontology Language

OCF Open Connectivity Foundation

XML Extensible Markup Language

SWRL Semantic web rule language

GIS Geographic information systems

BIM Building information modelling

ICT Information and communications technology

IIC Industrial Internet Consortium

IoT Internet of Things

CUAHSI Consortium of Universities for the Advancement of Hydrologic Science, Inc.

SWEET Semantic Web for Earth and Environmental Terminology

SIG Special interest group

WCIM Water catchment information model

GML Geography markup language

RDF Resource description framework

BSI British Standards Institution

IFC Industry Foundation Classes

ADE Application Domain Extension

BPMN Business Process Modelling Notation

WISDOM



INDUSTRIAL FOREWORD

A key aspect of the WISDOM project is the integration of data, analytics, and decision support components across the water value chain. This interoperation presents a significant challenge for existing technologies which use proprietary protocols, and convey messages with widely different terminologies and meanings.

Currently, within the water sector, it is common for system integration to be ad-hoc, and require a manual mapping between each heterogeneous component. As water networks become smarter, the time-intensive nature of this process, and of expert interpretation of the network’s data, will prohibit business-as-usual approaches. In order to overcome these challenges, alongside the trend of the internet of things, semantic modelling of the water industry must be undertaken. This need has been widely acknowledged in smart power grids through IEC standards [1] and in the building information modelling field through BuildingSmart [2], eeBUS [3], Haystack [4] and BSI standards. Indeed the Internet of Things domain recognises interoperability as a primary challenge and barrier to adoption within target verticals such as water resource management. Initiatives such as the Industrial Internet Consortium(IIC) [5], Open Connectivity Foundation [6] and Hypercat [7] are targeting Integrability (technical connectivity), Interoperability (syntactic and semantic) [8], and proposing a path towards Composability [9], [10]. Of the various interoperability challenges, semantics have been particularly noted in the water sector, with the ICT4Water cluster of EU research projects noting “that semantics is the most important hurdle to overcome, even preceding the other priority sectors”.

Semantic models store knowledge about the network in a more comprehensive manner than traditional GIS or database-centric approaches, such that intended meaning is more precisely and reliably shared between interoperating software. Further, as relationships between data concepts are expressed, this enables the application of a knowledge based systems approach to the data management, whereby the water sector’s decision makers are empowered by comprehensive, timely, and accurate knowledge, which is coupled closely with their management processes.

For example, rather than a water operations manager being notified of a pump alarm and then having to cross-reference and apply expert knowledge using several ICT systems, this can be achieved automatically, with semantics providing the mappings between systems to inform the expert; (a) exactly what the error is, (b) what the likely cause is, (c) what the impact is likely to be, and (d) what actions should be taken.

The semantic web approach also presents the key benefit to utility companies of avoiding vendor lock-in, and is built from the ground-up to allow extensibility and scalability as the company’s sensing and ICT infrastructure grows and changes over time. This technology also paves the way for enabling the use of artificial intelligence for the processing of water network data network, providing further added value to the data being collected. This inherent extensibility could also allow for an evolution whereby upgraded infrastructure and systems can infuse semantic meaning at lower levels of the technological stack thus moving towards increasingly distributed models of the IoT.

The semantic models of the WISDOM project represent a significant step towards this interoperable and knowledge-based approach. This deliverable presents the process and outcomes of this work, in terms of a domain semantic model for the water industry, a means to integrate legacy systems with the approach to produce pilot knowledge bases, and an ontology rule engine which begins to deliver tangible value to decision makers. The deliverable also discusses the role of semantics and ontologies in the water sector, and the need for standardisation; similar to the building information modelling field, where information exchange processes and artefacts are standardised.

WISDOM



EXECUTIVE SUMMARY

This deliverable presents the results of the WISDOM semantic modelling activities that have been conducted through Task 2.2 of the WISDOM project. This deliverable presents the final results of the task to a full state of completion.

This deliverable focuses on presenting the domain ontologies which have been developed to underpin the WISDOM platform, and also delivers the results of the work conducted to scope the task, capture relevant knowledge, and produce a robust methodology. This updated version also delivers the instantiation of the domain ontology at each of the pilot sites, and an inference and rule engine. Specifically, the goals of this deliverable are:

To introduce the role of semantic models in water management

To state the role and requirements of the semantic model within the WISDOM project

To outline the contribution of the WISDOM project’s semantic model within the field

To present the methodology adopted in developing these models

To introduce and discuss in detail the domain models developed

To present the methodology and results of instantiating pilot site knowledge bases, based on the domain modelling

To present use-case based requirements, methodology, results, and discussion of an inference engine for the proposed knowledge ecosystem

The core element of this deliverable; the domain ontology, has been engineered following the guidance of the well-established NeOn methodology [11], and contains a formal and shared description of the concepts and relationships in the domain of water management. Specifically, these are grouped into a Water Catchment Information Model, a Water Semantic Sensor Network Ontology and a Water Value Chain Social Model. Classes, class hierarchies, object properties, data properties and semantic restrictions are formalized in depth across these sub-domains as extensions of a meta-model which reuses a well-established semantic sensor network ontology [12] and a socio-technical system ontology, and all of this is presented in detail. This process has produced a domain ontology and ontology service towards the specifications described in D1.3 and D2.1, which are elaborated on in this deliverable, and has undergone a multi-stage validation process. The instantiation of the knowledge bases was accomplished through a reproducible method of legacy system integration, through the development of a Python script. The inference engine delivered exceeds the initial project requirements following industrial feedback on the benefit of further investigation. This is discussed herein, as well as a discussion of how the outputs of this task represent both underpinning artefacts in the WISDOM project and significant outputs of the project towards an important challenge in the domain.

WISDOM



1. INTRODUCTION

This deliverable presents the process and outputs towards semantic modelling of the water value chain within the WISDOM project. This work is specifically related to Task 2.2 within the WISDOM project, and addresses the goals outlined in the executive summary. The current document is the final version of the deliverable, which updates the intermediate version delivered in November 2015; primarily to present the full instantiation of the knowledge bases across the pilot sites and the development and testing of an inference engine. The work has been conducted iteratively between ontology experts, broader ICT domain experts, and water domain experts to reach a shared and sufficient formal conceptualization of the domain and its manifestation at the pilot sites. This aims to capture ontology engineering best practices to produce semantic models which are useful within the WISDOM ICT platform and beyond.

These semantic models, and the inference engine, represent a significant output of the WISDOM project, as they contribute towards a critical area of research within the application of ICT to water management, as discussed further in section 1.1. The models also serve as the backbone of integration between other software components in the WISDOM platform and hence facilitate their objectives. Finally, the deployment of these models as a web service alongside an advanced inference engine represents significant benefits to software developers in the domain through a knowledge-driven, semantic web approach. This ultimately assists the integration and enrichment of data and knowledge across scales and systems within water management to empower decision makers towards sustainable and profitable management schemes both directly and through further analytics software. The role of these semantic models in the domain is now elaborated before ontologies themselves are introduced and the rest of the document structure is introduced.

1.1. Semantic Models in Water Management

The application of ICT to water management holds the potential to improve management intelligence, communication and operational efficiency, similar to other fields where ICT is being applied, such as in smart electricity grids or smart cities. This is being recognised through the emergence of a trend towards ‘smart water’ [13], [14]. However, as with these fields, the application of ICT in the water value chain is restricted due to an inability to share data and knowledge, and hence interoperate, across the people and software components involved [15]. In smart grids, this has been stated by authoritative bodies to occur due to three main issues: lack of machine communication protocols, lack of common data formats and lack of common meaning of exchanged content [16]. In the ‘smart water’ domain, the same core issues have restricted the utility and hence prevalence of ICT penetration. In the smart grid domain, this is being addressed in research, in part through the development of shared data models to facilitate data exchange, integration of legacy systems, and to enable system security and performance [16]. In the smart water domain, the same key functions of shared data models are required, and so recognition of the value of a similar approach in this field is growing. Notably, a recent report from the ICT4Water cluster of EC FP7 projects highlighted the need for standardised models to address the issue of interoperability in the smart water domain [17] and specifically indicated the importance of ontologies as a means to maintain semantic clarity and integrate knowledge, even noting one standardization session where semantic modelling was agreed as the most important hurdle in the domain. Finally, within the wider field of smart cities, the challenge of interoperability has been broadly noted, with BSI recently publishing a suite of standards to

WISDOM



guide in addressing the issue, again specifically highlighting the role of semantics by publishing a smart city vocabulary [18, p. 180] and a guide towards a smart city concept model for interoperability [19]. All of this leads to a clear emerging challenge in the smart water domain of developing common communication protocols, data models and semantic vocabularies.

Semantic models address the issue of interoperability by creating a shared understanding of the domain and a shared method of representing data and their meaning. Within this remit, various manifestations of what constitutes a ‘semantic model’ exist, which exhibit a tradeoff between expressiveness and comprehension. Specifically, simple models tend not to capture the nuances of a domain, but are more easily developed, understood and utilized. However, the utility of these ‘nuances’ should not be understated, with ontologies representing the highest level of expressive potential but also the greatest potential for human and computational complexity. These benefits have been acknowledged in the field of semantic web technologies through the World Wide Web Consortium (W3C) ‘semantic web stack’, which represents a generic framework for web based interoperability and shows ontologies playing a critical role. Further, ontology based models allow the use of inference to produce new knowledge about a system beyond what has been explicitly stated, allows the application of local rules for compliance checking or event triggering, and allows more simple integration of smart water domain knowledge with potential future synergies such as other smart city systems and beyond. For these reasons, and primarily the semantic expressiveness they allow, the WISDOM project has adopted an ontological approach to developing semantic models. The nature of ontologies and their application in computer science is introduced in section 1.2.

As a relatively recent challenge, ontological models in the smart water field are sparse, although several relevant examples were identified. The most relevant is the ontology developed in the WatERP project [20], a sister project to WISDOM within the ICT4Water cluster. Another very relevant model is the semantic water interoperability model (SWIM) [21], which formalizes a description of water sector devices such as sensors, pumps, reservoirs and valves. As well as this, Waternomics, another ICT4Water project, has developed a ‘linked data model’, and several examples of water ontologies have been identified in the literature, albeit generally not specifically for the purpose described previously. Most notably are the works of CUAHSI [22], SWEET [23] and HydrOntology [24]. These ontologies, and several others, are compared in Table 1 below, followed by more discussion on the WatERP ontology and the contribution of the WISDOM semantic models to the field. Furthermore, the WaterML2 standard is highly relevant but does not express semantics in the manner that the WISDOM ontology does, although it is discussed later. Note that Table 1 includes models deemed significant but with somewhat different scopes to the WISDOM ontology, such as the Industry Foundation Classes (IFC).

WISDOM



Table 1: Comparison of relevant existing semantic models

Acronym/name Description Owner # Entities Date

SWIM Device level IoT semantic model for the water industry. Aquamatix ? 2016

WISDOM Middle and lower level ontology of technological, social and sensory concepts in the water value chain, at the network and domestic levels.

Cardiff University 492 2016

Industry foundation classes

Open format for the exchange of building information models. buildingSMART 768 2015

WaterML2 Common format for exchange of hydrological time series data. OGC 131 2014

INSPIRE Data Spec3 The INSPIRE directive is establishing an infrastructure for spatial information exchange in Europe, resulting in data models for many application domains, including utility networks, of which water and sewer networks are a subset.

EC 68 2013

WatERP Lightweight ontology of generic concepts for water sensing and management.

EURECAT 25 classes 2013

Water data transfer format

Format for transferring flood warning and forecasting data to the governing body.

Australian Bureau of Meterology

337 2013

Water Innovation Thesaurus

Aims to facilitate collaboration for water innovation by establishing and highlighting recognised terminology and providing clear definitions for these as well as demonstrating the relationships between terms.

EIP Water 548 2013

CityGML UtilityADE CityGML ADE for the modelling of utility networks in 3d city models, based on topology and component descriptions.

OGC 317 2012

SWEET Middle-level ontology for environmental terminology. NASA 6000 2011

Hydrologic Ontology for Discovery

Supports the discovery of time-series hydrologic data collected at a fixed point.

CUAHSI 4098 2010

HydrOntology Aims to integrate data sources regarding hydrographical information from a civil engineering or town planning perspective and a top down methodology.

Vilches-Blázquez et al.

250 2009

From Table 1, it is clear that whilst significant semantic modeling has been conducted, this is mainly aimed towards the field of earth sciences rather than considering man-made water infrastructure artefacts, and is hence not relevant to real-time management systems such as in the WISDOM project and water value chain management in general. The INSPIRE data model [25] is within the same domain as WISDOM; water and sewer networks, but the modelling conducted only formalizes simple concepts and relationships, hence only including 68 named entities in the UML formalisation available. Regardless, this work is still relevant, and aligning the WISDOM ontology with it is deemed valuable. The WatERP ontology is however very relevant and has significant overlap with the WISDOM ontology remit. The WatERP ontology is split conceptually into a ‘supply and demand ontology’, ‘observation and measurement ontology’ and an ‘alerts and actions’ ontology. Of these, the ‘observation and measurement ontology’ is similar to the WISDOM sensor ontology, due to their shared roots in the W3C SSN ontology [12], although the WatERP ontology’s alignment with the SSN ontology is shallow; only reusing a few high level concepts. The WISDOM sensor ontology however, thoroughly reuses the SSN ontology, and extends it directly in order to be relevant to the

3 From the data specification on utility & government services, this includes the generic network components, common network components, water network components, and sewer network components.

WISDOM



water domain. The WatERP ‘supply and demand ontology’ contains concepts from across the rest of the WISDOM ontology, but again only captures high level concepts such as physical element types (storage, transfer, etc.) and a few types of actors (bulk water suppliers, consumers, regulators and water utilities). The WatERP ontology therefore contains no depth of social knowledge, nor does it abstract the system from a network perspective, and it contains no depth of knowledge regarding subclasses of ‘features of interest’ such as data regarding pipes, reservoirs, pumps etc. Hence, the WISDOM ontology is suited to a different purpose to that which the WatERP ontology achieves, as it captures far more depth and breadth of knowledge about the domain, to be suitable for real time network management, and abstraction to a network perspective allows greater inference potential. Furthermore, the WISDOM ontology captures domestic knowledge, which the WatERP ontology does not, and its classification of actors abstracts to a more generic level suitable for use across water management landscapes in different countries. The ‘alerts and actions’ ontology of WatERP could be reused as an extension of the WISDOM ontology if a situation arose where such an extension would be useful. In short, the WatERP ontology adopts a far more simple approach to representing the domain and almost represents a subset of the WISDOM ontology: it would henceforth be useful to compare the differing applicability and performance of each ontology in detail. Collaboration is ongoing with the WatERP project, and the WISDOM ontology has been aligned with the WatERP ontology, as detailed in section 4.6.1.

From this discussion of previous efforts in semantic modeling in the water management domain, it is evident that little effort to date has focused on the challenge which the WISDOM ontology intends to meet; most efforts have been targeted at the earth science domain rather than the man-made water value chain. Semantic modeling in this specific domain has been raised as a critical issue [17], and is widely acknowledged as such in the neighboring fields of smart grids and smart cities. Whilst the WatERP ontology is relevant, it is only suitable for capturing generic knowledge about a water network and relating observations to features of interest and alerts. For these reasons the WISDOM ontology offers a significant advancement in the field by capturing in-depth knowledge regarding the technological, network, social, sensory and ICT artefacts involved in water management decisions in a water value chain. Specifically, the WISDOM ontology is fully aligned with the SSN ontology and extends this to the target domain. Also, the WISDOM ontology abstracts the water network from network modeling and process modeling perspectives, formalizes knowledge about different asset and component types, formalizes domestic water use knowledge and captures social knowledge across the target domain.

1.2. Introduction to Ontologies

An ontology, in the broadest sense, is a shared and formal conceptualisation of a domain, and stems from the field of philosophy regarding the nature of knowledge and meaning. This has since been adopted within the computer science field, where it holds a more specific meaning as a software entity used to represent concepts, relationships, descriptions and restrictions in a domain. This has been further adopted within the semantic web community as a specific means of integrating data, knowledge and meaning between people and software components. Full discussions of this history and the current fields of ontology engineering and application are beyond the scope of this deliverable, and have been discussed elsewhere in literature, but will be introduced here from a semantic web perspective to aid the understanding of the deliverable’s contents.

A semantic web ontology is a collection of statements about a domain, structured in a specific manner such that the statements can easily be brought together by a machine into a cohesive collection of knowledge

WISDOM



about the domain, and then used to enrich data regarding an instance of the domain. As discussed in D2.1, the WISDOM ontology utilises the W3C semantic web stack, and so is written in OWL. This mandates that the statements are formed as RDF triples, which is to say that they must follow the format of subject-predicate-object. An example of this would be ‘Dog’ ‘isATypeOf’ ‘Animal’, such that the terms ‘Dog’ and ‘Animal’ would then be linked to any other statements including those terms. An ontology file is hence a collection of such statements, which is interpreted by a machine to produce a network of concepts (e.g. ‘Dog’, ‘Animal’) and relationships (e.g. ‘isATypeOf’). However, in an actual OWL file, each element of the triple contains a namespace as well as the term, and is formed according to a specific format defined by the serialisation used, for example the previous statement could appear as follows according to RDF/XML serialisation:

<owl:Class rdf:about="http://www.ontology.org/testOntology#Dog">

<rdfs:subClassOf rdf:resource=" http://www.ontology.org/testOntology#Animal"/>

</owl:Class>

The above RDF/XML excerpt states in the first line that the statement(s) which follow will be ‘about’ the ‘Class’ ‘Dog’ within the ‘testOntology’, and that the meaning of ‘Class’ and ‘about’ are defined at locations referred to as ‘owl’ and ‘rdf’ respectively, which are each defined elsewhere in the document. The second line then states that the previously stated class is a sub-class of another class defined in the document; the ‘Animal’ class, and again the meanings of sub-class and ‘resource’ are defined elsewhere. The third line then closes the statement and allows another statement to follow. By formalising all parts of these statements to such an extent, they become machine interpretable and enable easily integration across semantic web resources, as well as inference and rule applicability.

When defining an ontology, there are typical groupings of knowledge which can be captured through ‘statements’: classes, class hierarchies, object properties, data properties, restrictions and annotations. Classes are the types of object which occur in the domain; both physical and otherwise, such as both the ‘objects’ of a ‘Pipe’ and a ‘Physical Network Arc’; this use of the term ‘object’ reflects its broad use in the computer science field. Class hierarchies are then statements of ‘X’ ‘isASubclassOf’ ‘Y’, which defines the basic knowledge in a domain such as categorising physical elements, but also abstracting these with statements such as ‘Pipe’ ‘isASubclassOf’ ‘DesignedArtefact’, such that all statements made of designed artefacts are also true of pipes. These classes are then ‘instantiated’ within an instance of the domain to create individuals, such as a pilot site in the WISDOM project, whereby numerous instances of ‘Pipe’ are created; for each pipe in the pilot site. Object properties are then the relationships between these individuals, and are modelled as object property ‘slots’ between classes such that a relationship can occur between any two instances of two classes. These also typically contain a prescription of their ‘domain’ and ‘range’, such as for the instantiation of ‘Sensor_01’ ‘collectsDataAboutEntity’ ‘Pipe_01’, where the slot’s domain is ‘Sensor’ and the range of the slot is ‘PhysicalArc’ or ‘PhysicalNode’, and a pipe is a type of physical arc. Data properties then relate individuals to simple data such as numbers or words, and their slots typically define what data can be stored, such as a sensor reading always being stored as a number with a decimal point. Restrictions then define further logical statements about the classes and properties in order to ensure correct information is entered and to allow the inference of further knowledge based on what is explicitly entered. This represents a key benefit of ontologies, but is beyond the scope of this introduction. Finally, annotations define extra information about entities in the ontology, such as labels and comments for classes (to aid human understanding of them), and explicit mapping statements to allow the class to be

WISDOM



considered equivalent to a class in another ontology or semantic resource. Annotations also provide a capability for multi-lingual support, hyperlinks and many other automated or manual enrichments of an ontology’s core functionality.

The above definition of an ontology covers two components typically considered as separate; the domain ontology (called a T-box) which includes statements generic across all instances of the domain, and the instantiation of this (called an A-box), which contains statements specific to an instance of the domain. The union of these two components forms a knowledge base, and alongside an inference engine, a query engine and a storage capability, this composes a knowledge management system. Within these, the inference engine utilises the statements made in order to infer new knowledge (see section 6.1), the query engine is the method of extracting data and knowledge from the knowledge base (see D2.4) and the storage capability physically and virtually stores the OWL and RDF data on disks and in computer memory (see D2.4). This system may be accessed directly by an interface exposed to users, but more commonly it will form the backend of an application or several applications in order to provide a data-store similar to a typical database but which captures meaning, contextualises data, standardises terminology, facilitates rule application and produces new knowledge from that which is put in. This therefore assists software developers in producing applications which can more easily utilise in-depth knowledge and data sets from heterogeneous sources, and can more easily integrate with other software components, and deliver more powerful analytics to users.

1.3. The Role of the WISDOM Project’s Semantic Models

Further to the benefits of semantic models in the domain identified in section 1.1 and the implementation of ontologies outlined in section 1.2, the WISDOM semantic models have a specific role within the target project and target software platform. This is outlined in the project’s description of work, and has been elaborated into full requirement specifications for the ontology and the ontology service as presented in section 3, but is introduced here.

The WISDOM semantic models aim to capture sufficient water management knowledge for the implementation of the WISDOM scenarios through the WISDOM platform’s business services. Specifically, as a formalized, shared and instantiated conceptualisation of the domain, the WISDOM semantic models:

Formalize a description of physical artefacts (buildings, reservoirs etc) and non-physical concepts (building users, water value chain stakeholders)

Contain a sensor ontology (describes the sensors, sensing processes & sensed phenomena) to

contextualise sensors and allow inference of sensing capabilities

Describe relevant ICT, socio-technical system and measurement concepts and their relationships to the above sensory, physical and non-physical concepts, to contextualize and enrich data

Abstract these concepts sufficiently for inference and re-use purposes

Define the water value chain’s elements and their relationships and constraints

Describe the data (and metadata) required for efficient water management

Reuse GIS and BIM data where suitable

WISDOM



Contain a representation of the current state of the water network, to be used as a lookup engine to provide near real-time data to intelligent modules

Use SWRL rules and inference to produce an estimated complete representation of the water network given the available sensor data

Are separated into a domain ontology and pilot site instantiations, for reusability

Are utilised at exploitation time to produce models that configure and update the relevant

intelligent modules to ensure consistency

The WISDOM semantic models underpin the ICT platform by formalizing a vocabulary of concepts and their relationships within the water management domain, and subsequently instantiate pilot site knowledge bases. These describe each site’s technological, sensory and socio-economic systems to the depth necessary for implementing the WISDOM scenarios. This provides a common interface for the software components to share data through, enriches sensed data with contextual meaning and utilizes inference to produce new knowledge from that which is explicitly inputted or reused from GIS data sources.

1.4. Document Summary

Following this introduction, this deliverable begins by outlining the methodology adopted for scoping and developing the semantic models, then discusses the domain ontology developed in detail, before presenting the work conducted towards and results of, instantiating the ontology for the WISDOM pilot sites. The reasoning engine is then presented and discussion is made towards a knowledge-based systems approach for the water industry before concluding remarks.

WISDOM



2. METHODOLOGY

The methodology adopted in scoping, developing and deploying the WISDOM semantic models primarily utilized the recommendations of the NeOn methodology to utilize a collaborative approach with domain experts and ontological experts, through an iterative process shown in Figure 1. This adheres to BPMN standards to show the main processes, sub-processes and data objects throughout the activities of Task 2.2. The main stages involved in this workflow are described through sub-sections. Firstly the knowledge acquisition and scoping phase is discussed, then the development of a domain independent meta-model as an extension of reusable ontologies, then each of the stages of the actual ontology development process are elaborated. The pilot site instantiation process is then discussed before the web service development process, the preliminary validation, inference engine development process and secondary validation and finally the process of mapping to other ontologies. This overall process is essentially an instance of Kolb’s experiential learning cycle whereby one senses the domain, actors, and goals, then tries to understand more about what is required and how others have done that, before deciding on possible approaches. These decisions are then acted on, before sensing the appropriateness of the actions and continuing to iterate.

WISDOM



Figure 1: BPMN diagram of semantic modelling activities

WISDOM



2.1. Knowledge Acquisition & Product Specification

The first phase of the semantic modelling activities was to thoroughly understand the challenge faced, followed by significant domain research and knowledge acquisition, and finally the production of formal requirement specifications for both the ontology and the overall ontology service. These requirement specifications are living documents and continue to naturally evolve as the WISDOM project matures and requirements are added, removed or refined. After gaining a conceptual understanding of the domain, the pilot sites and the role of the ontology service in the WISDOM platform, these were formalized into IDEF0 [26] process models, use case models, explicit scenarios and deployments, and finally, requirement specifications. These were all then iterated through a collaborative process with domain experts to promote their accuracy and completeness. Also, significantly, a collection of relevant ontological and non-ontological models were collected and evaluated for re-use, as is best practice in ontological modelling. Once the specifications and assorted data objects were validated successfully, the ontology was conceptualised and the reusable resources were merged and extended into a domain-independent meta-model.

2.2. Developing a Meta-Model from Reusable Ontologies

Given a clear ontology scope, domain conceptualisation and an assortment of relevant knowledge modelling resources, these were then analysed for reuse potential and subsequently merged into a meta-model. Of the broad list of resources identified in D2.1, those which were reused were the W3C semantic senor network (SSN) ontology and the socio-technical system (STS) ontology of van Dam [27]. The SSN ontology was adapted slightly in developing the meta-model to suit the WISDOM project, and the STS ontology directly reused, but only in part; again to suit the needs of the WISDOM project. This is discussed further in section 4.1. The guidance of the suggested upper merged ontology (SUMO) [28] was considered in merging these and developing the meta-model, so as to facilitate alignment with SUMO at a later stage.

2.3. Developing WISDOM Ontology

The WISDOM ontology’s design extended the domain-independent meta-model to be domain specific, and was supplemented with an automated web-based term-extraction process. The main stages in developing the draft ontology were to enumerate the domain’s concepts, build a class hierarchy from this which was aligned with the meta-model, then define class relationships and data properties before stating restrictions. The knowledge necessary for this task and the modelling decisions made was derived from the previous stage of scoping and knowledge acquisition, and was conducted alongside domain experts to further promote the ontology’s accuracy and sufficiency. A full explanation of the nature of the various aspects of ontological modelling is beyond the scope of this deliverable; for an understanding of concepts such as object properties, data properties and classes the reader is asked to refer to literature on the field. The main steps in this process are now briefly summarised in turn.

2.3.1. Enumerating Concepts

The concept enumeration involved utilising the data objects produced previously in the task to list all of the types of object and any other key aspects of the domain’s vocabulary. This involved a manual review of literature and domain expert communications as well as the IDEF0 models, use case models and scenarios; primarily for key nouns which represent classes of objects in the domain but also key adjectives and verbs

WISDOM



which may represent properties and class relationships. Also, the ontology expert who conducted the modelling had experience with the water value chain through a civil engineering background. The GIS data schema utilised by DCWW was also provided for analysis, which provided many key object types and properties. Finally, an automated web-based term extraction process was conducted across over 100 relevant websites, with a novel semantic ranking methodology being utilised to extract the class types most relevant to the water management domain. This noun list was used to elaborate the concept enumeration and was used in the preliminary validation stage described in section 2.6 as an indication of ontology completeness.

2.3.2. Class Hierarchy Design and Alignment

From the list of relevant concepts, a list of domain specific classes was extracted, and this was iteratively developed into a hierarchy, aligned with the meta-model previously produced. The inherent modelling decisions were based on the knowledge acquisition conducted previously, common sense, and domain expert consultation. This produced a domain specific class hierarchy enriched with significant domain-independent abstraction to facilitate valuable inference and to better represent the underlying concepts in the domain, allowing its reuse or alignment with existing ontologies, upper ontologies and potential future applications. This class hierarchy represented a simple categorisation of types of concepts in the domain, including tangible and common sense knowledge such as ‘a waste water pipe is a type of pipe’ as well as more complex and abstract knowledge such as ‘a pipe is a type of physical arc and also a type of designed artefact’.

2.3.3. Object Property Slots

Object properties, which are relationships between instances of classes, were then modelled in agreement with the domain knowledge previously acquired. However, the object properties to be modelled were inherently considered during the class hierarchy design, as they are an integral part of the modelling decision process. This involved analysing the domain knowledge acquired and deducing statements such as ‘a sensor makes observations about a network entity’, then determining if the knowledge such a statement allows to be modelled is relevant and required within the requirement specifications given. Where the inferred statements were deemed necessary and valid, they were then formalised into the ontology. This resulted in many relationships between the social, sensing and physical systems in the domain, between the abstract and physical descriptions of the water network, between the designed and natural physical entities and between all entities and descriptive properties where they themselves were represented as concepts.

2.3.4. Data Property Slots

Relevant domain specific data properties were then added, to facilitate the ontology’s intended purpose of representing the current state of the water network. This implied that as well as static data such as pipe diameters and topologies, some dynamic data should be stored in the ontology, such as the latest reading from a sensor or the current flow rate in a pipe. This stage involved a thorough consideration of the software specification, so as not to duplicate the functionality offered by the event database whilst sufficiently capturing the data required about objects in the domain. The data property slots formalised are expected to be extended considerably as the WISDOM project matures and the data required by other software components evolves. Regarding the social modelling, much use was made of the previous work of

WISDOM



capturing knowledge at the individual domestic consumer level through surveys to identify the key properties which describe residents from a water usage perspective.

2.3.5. Restrictions

Finally, restrictions (axioms) were modelled to supplement the potential inference and hence the new knowledge which may be inferred through the ontology. These included both ‘necessary’ and ‘necessary and sufficient’ restriction. Respectively these state that a class must adhere to a rule, and beyond that, if an individual adheres to the rule then it is a member of the class. This is useful in stating for example that a storage node must not change the water type between its input and output, and for stating that if an individual does change its water type from ‘raw’ to ‘potable’, it must be a treatment node, respectively. This rule development is related to the inference engine work which is presented in section 6.

2.4. Instantiating Pilot Site Knowledge Bases

The pilot site knowledge bases have been produced for each of the 3 Welsh sites and the Italian site. These have mainly been produced by reusing GIS data, sensor databases, EPANET [29] models, and social entity descriptions provided for the sites by industrial partners. This was accomplished in an automated manner using a Python application written as part of this task, for this specific purpose, following the manual federation of the data schema into the domain ontology as described previously. This data has been federated into RDF format and has been enriched through additional data gathered through domain knowledge and domain expert consultation. This utilised the RDFlib Python library [30] to store the RDF data in memory, and the Python CSV library to parse the input data, as well as manual pre-processing of the EPANET input file.

2.5. Deployment as a Web Service

The deployment of the ontology as a web service supports the benefits of a service-oriented architecture [16] and hence allows plug-and play capability with other software components of the WISDOM architecture. This software development was conducted in line with the software requirement specification produced for the ontology service. This was developed as a RESTful web service, written in Java, and based on the Apache Jena [31] suite of APIs for semantic web software development. The software was developed and tested on a local machine and has since been deployed on the secure cloud environment provided by ICL. This software is now at a mature stage where it is able to handle real-time SPARQL requests as well as custom functions for the most common foreseen uses of the ontology service, and meets the requirement specification. Further work is envisaged within other project tasks to integrate this web service with the other WISDOM components and subsequently both refine and maintain the work presented herein.

The ontology has been deployed through a web service to test its capability to handle real-time data, and this has been documented previously in D2.4; the architecture and intended service is described in D2.1 and a full description and API specification is given in D2.4. Therefore, no further detail will be given in this deliverable.

WISDOM



2.6. Preliminary Validation

The ontology design process was followed by a novel, collaborative, and semi-automated preliminary validation, and was validated through the planned secondary validation and revision iteration at the WISDOM SIG meeting held in November 2015. The preliminary stage utilised common ontology validation techniques and was supplemented by the semi-automated process. The initial validation consisted of using Protégé’s [32] built in consistency checker, which determines if any of the explicit statements which have been made are contradictory. This was followed by competency question checking and iterative ontology revisions until the questions could be answered successfully, at this point the ontology could be assumed to sufficiently meet the stated objectives. However, it is critical to further test whether these stated objectives are an adequate representation of the intended objectives, and even further testing to determine whether these intended objectives are a valid representation of what the objectives should be. This testing has been conducted at a preliminary level through validation of the model by domain experts within the WISDOM project, in terms of: whether it meets their view of what the ontology should be, whether its statements are correct, and whether this is genuinely a valid representation of the wider domain. This was then further checked, still at a preliminary stage, through a semi-automated web-based term-extraction process.

The full details of the semi-automated validation are beyond the scope of this deliverable, but it is briefly summarised here. The first stage consisted of automatically ‘crawling’ a manually selected list of relevant websites (and their linked websites) for public HTML (raw ‘screen text’), Microsoft Word, .txt and .PDF documents based on loose rules for relevance, through a Python program written by CU for the task. These were then processed to extract a list of all the words, and several metrics about them, per document. This data was then further processed through another novel Python program to identify the most relevant and likely candidate class and property names. This Python program first ranked the words by frequency and ‘term frequency, inverse document frequency’ (tf-idf), a common metric of the importance of a word in a document), filtered out ‘stop words’ such as ‘if’, ‘the’ and ‘is’, then looked up the word in the WordNet lexical database and retrieved a definition of the word. The relevant words in this definition were then looked for in the list of words found in the crawled web documents, and their tf-idf values summed when they were found, to produce another metric of ‘importance’ for the crawled document word in the target domain. This was then utilised alongside each word’s tf-idf value to produce a hybrid measure of importance of the word, and the list was ordered by this metric of importance. Finally the script utilised WordNet to separate the proper nouns (which would be instances of classes), nouns (which represent candidate classes) and adjectives and adverbs (candidate properties); other linguistic components were removed. From the resulting data the representative domain coverage of the ontology was calculated and possible missing classes and properties were identified.

2.7. Development of Inference Engine

The inference engine used native OWL axioms as well as custom SWRL rules to infer domain specific and useful knowledge from that which is explicitly stated in the ontology, so as to produce a richer and more complete representation of each pilot site, at each time step of the ontology’s instantiation, and to perform various checks which will raise alarm events if they fail. This followed a robust use-case based approach to elicit the requirements of the inference engine, and subsequently develop and test the inference in the context of real-world situations. These custom rules supplement the default inference capabilities available to all ontologies through reasoners such as the Jena native reasoner and the Pellet reasoner, with heuristic

WISDOM



rules relevant to the management decision process. This work was tested in the Protégé software, and the capabilities and efficiency of the engine is reported.

2.8. Validation within WISDOM Platform

Following the preliminary validation of the domain ontology as described in section 2.6 and the development of the other semantic components as indicated in Figure 1, these have been tested together in the WISDOM platform as a web service, through its capability to sufficiently provide knowledge management services to the other platform components. This served to test and revise the previously produced requirement specifications based on the ontology service’s contribution to the overall goals of the WISDOM project in supporting the other services. This formed an iterative process of semantic component revision and re-testing until the collective result was deemed satisfactory. The final artefacts are now deemed sufficient to enter their maintenance lifecycle stage.

WISDOM



3. REQUIREMENT SPECIFICATION

The scoping and specification of an ontology is a crucial stage, as the ontology must be detailed and accurate enough for the intended application, utilize sufficient abstraction and breadth for potential future reuse, yet be concise enough to meet the performance requirements of its intended application. The scoping/specification was hence conducted alongside the process modeling and scenario modeling presented in D1.1 and D1.3, the software requirement specifications in D2.1, and domain expert consultations, with ontology expert formalization of these preliminary activities into competency questions. These questions represent a range of queries the ontology should be able to answer directly or through inference, and serve as a ‘litmus test’ of whether the ontology delivers the planned functionality. This then serves as an initial validation of the ontology, with further validation required into whether this ‘planned functionality’ is sufficient within the intended application and whether the modeling choices are agreed upon amongst the application stakeholders and ideally beyond. This section therefore summarizes the requirements of the WISDOM semantic models and web service and, hence, competency questions are produced to test the vocabulary’s ‘planned functionality’. However, full details can be found in the deliverables mentioned above or appendix A, which contains the competency questions.

3.1. Ontology Scoping & Competency Questions

Section 1.3 discussed the role of the semantic models within the WISDOM platform; this section serves to elaborate on that section, and introduce the competency questions which resulted from the preliminary stages of T2.2. Whilst the role of the models has been stated from an ICT perspective, this section states its role from a knowledge modeling perspective.

The WISDOM project aims to implement intelligent sensing and analytics to integrate the management of the water network across conceptual scales, such as the domestic and whole system scales, whilst improving management schemes and domestic consumption profiles. From this statement, the knowledge domain can begin to be inferred. The WISDOM ontology will hence formalize a description of the sensing in the water network, the network itself, the social entities involved, the domestic entities and the relationships between them. To further elaborate on the scope of the ontology, statements regarding what is not focused on in this ontology can help to clarify the boundaries of the WISDOM knowledge domain:

Natural artefacts will be included, but their management is not a focal point

Electricity consumption will be included, but its management is not a focal point

Non-domestic consumers are not a focal point

Managing the internal operation of treatment plants and pumping stations is not a focal point

Economic concepts will be included, but they are not a focal point

By understanding and acknowledging these boundaries, reusing the WISDOM ontology in future applications is facilitated, as its role alongside other ontologies becomes clearer. For example, it could be aligned with a model of treatment plant concepts to enrich and integrate data between high level system

WISDOM



management and asset level performance objectives. From this general scope and the other general study outputs of the preliminary stages of T2.2, a set of competency questions were produced collaboratively and iteratively with domain experts.

The competency questions utilized the scenario-driven approach and its subsequent outputs, by considering the main entities and their properties within each scenario. Questions were then formed which elicited these properties. The opposite was also conducted in an organic manner; natural questions about the water value chain which were deemed likely were analyzed for the property and entity they were referring to. Examples of various types of these are presented below and a full list is available in appendix A:

Scenario 1 (Behaviour & Feedback): How much water does person X consume per week, on average?

Property – average weekly water consumption

Entity – domestic resident Which water meter is attached to house X?

Property – attached water meter

Entity – domicile, domestic water meter

Scenario 2 (Network monitoring):

What property does sensor X detect?

Property – observed property

Entity – sensor

Scenario 11 (Reservoir optimization):

What is the maximum storage volume of service reservoir X?

Property – max storage volume

Entity – service reservoir

Critically, the competency questions aim to emulate the questions which other software components in the platform will be asking of the water value chain in order to meet their requirements and goals. This emulation is inherently an iterative process, such that the competency questions will change and adapt as the other software components become more mature in their development stage, and so some interpretation is required in utilising competency questions to guide the development of an ontology; that is to say, some foresight is ideal. Though, whilst the competency questions form a solid grounding and a minimum standard for the ontology, they are unlikely to capture many important nuances which become apparent through the ontology modelling or software development processes, and have been viewed as such.

3.2. Software Implementation Requirements

Beyond scoping the ontology as a knowledge modelling task, it is critical to consider the end use of the ontology within WISDOM as an ICT component throughout the development stages of the task. Therefore, beyond the scope and competency questions stated in section 3.1, this section introduces the software

WISDOM



requirements which were taken into account in designing the ontology as well as developing the software which deployed it. These requirements arose from the system analysis and design process detailed in D1.3, utilising use cases towards the WISDOM scenarios to elicit the main functions required by each component of the WISDOM platform. Example software requirements are presented below, but D1.3 should be consulted for a full list:

Manage ontology (UC-SAS5): this process allows a system administrator to manage the WISDOM water network ontology. It allows the installation, update or replacement of the underlying ontology model(s) of the WISDOM water knowledge management subsystem as well the management of existing ontology instances and their properties.

Manage field entities (UC-SAS6): this process allows a system administrator to manage field devices/entities that are integrated into the WISDOM system. By interacting with the ontology statistics and operational performance indicators can be obtained. Furthermore, the ontology allows setting of device parameters and configurations which are implemented through the actuation management service.

Update ontology (UC-WKM3): the water ontology provides a process that allows dynamic updating of the ontology representation/attributes based on incoming events to reflect an up-to-date view of the water network.

From these requirements, the conceptualisation of the ontology was refined prior to its design, as modelling choices then reflected the end use of the ontology as well as the knowledge scoping and competency questions. Furthermore, both sets of requirements were tested themselves as a requirement set in terms of whether they were clear, sufficient and explicit; again as detailed in D1.3.

WISDOM



4. ONTOLOGY DOMAIN MODELS

This section presents the semantic domain models which have been produced, as OWL ontologies. To aid in presenting these, they have been split into three conceptual regions; the Water Catchment Information Model (WCIM), Water Semantic Sensor Network Ontology (WSSNO) and the Water Value Chain Social Model (WVCSM). These represent a language used to produce knowledge bases (presented in section 5) for each of the pilot sites, which will be presented separately. This section will first present the meta-model developed from the W3C SSN ontology and the STS ontology before discussing and showing each of the above models in turn. This section will focus on the class hierarchies and object relationships which have been modelled in the domain alongside some key data properties.

4.1. Domain Independent Meta-Model

Following the alignment and extension of the reused ontologies, a domain independent meta-model was produced which described the concepts and relationships in the upper domain of intelligent sensing in a socio-technical network. The choice of a socio-technical system approach was made due to both the autonomy exhibited in the water network’s social subsystems and the clear divide between physical, technological concepts and social concepts. This implied that the modelling view should go beyond a systems theory approach and even beyond a system of systems approach to a socio-technical systems approach, and hence reused the work of Koen van Dam [27], the main relevant components of which are shown in Figure 2.

Figure 2: Main reused concepts and relationships from the STS ontology

The use of the W3C SSN ontology was a natural choice due to the heavy reliance on intelligent sensing in WISDOM, and so this was merged with the STS ontology through an alignment process. The resultant meta-

WISDOM



model was extended slightly with object properties and object property restrictions, and an excerpt of it is shown in Figure 3.

Figure 3: Excerpt of the meta-model for intelligent sensing in socio-technical systems

4.2. Water Catchment Information Model

The Water Catchment Information Model (WCIM) describes the concepts and relationships relevant to the technological infrastructure in the water value chain, including natural and built-environment concepts. This has been developed based on the business process modelling conducted in WP1, GIS data from DCWW, and the knowledge acquired through the preliminary stages of T2.2. The WCIM model can be conceptually divided up into 4 models as shown in Figure 4 below. Of these models, the water management network model and water value chain process model abstract the water value chain from a network modelling and process modelling perspective respectively, in order to contextualise the components described within the supply-side and domestic artefact models, which categorise and describe the physical components in each part of the water value chain.

WISDOM



Figure 4: Main groups of concepts in the WCIM

4.2.1. The Water Value Chain Processes

Figure 5 below shows the IDEF0 process model produced within WP1 of the water value chain’s key processes. These are used to categorise the purpose of WCIM components and hence allow knowledge to be inferred from sensed data. From Figure 5, each process has been modelled as a concept; all technical components facilitate one of these processes, and each process is related to other processes by giving and receiving specific types of physical substance (water types or by-products such as sludge, waste solids, rag & grit).

Figure 5: Processes in the water value chain

WISDOM



As WISDOM aims to integrate the supply and demand-side management of water, the ‘usage’ process from Figure 5 is elaborated in Figure 6 below, and concepts relevant to these processes have been modelled for demand-side knowledge. The key OWL concepts elicited from these diagrams are included in subsequent descriptions and diagrams.

Figure 6: Process model within a property

4.2.2. Water Network Model

The WCIM models water networks as a collection of distributed nodes connected by arcs, where nodes interact with the water at a WVC asset and arcs transport water. Physical nodes and arcs then have subclasses, such as ‘storage node’ or ‘pipe’, which are stated as being equivalent to the physical artefacts ‘storage asset’ or ‘main’ presented in the next section. In this manner, the water network model abstracts the interactions between physical components to a simpler level which is homogenised across the water network, allowing a systemic consideration of the network rather than viewing it only as a collection of assets. Node and arc descriptions will now be presented before a brief example of their manifestation and a discussion of the OWL implementation of these concepts.

Each component which performs a function other than the distribution of water is generally considered as a node in the water value chain, such as pumping stations, reservoirs, houses etc. This refers to components at the network level rather than the asset level; devices such as individual pumps are not modelled at this level but are instead modelled at a higher level of detail view. Specifically, these devices are stated to be situated at an entity, where the device is the individual pump and the entity is the pumping station, in this example. All nodes are an instance of subtypes of the generic node presented in Figure 7 below. As well as the water-specific properties listed here, each node is also described by the properties of geographic coordinates, elevation, and by its preceding and succeeding arcs. Natural water bodies are modelled separately as described later.

WISDOM



Figure 7: Description of a generic node and its relevant data

From this generic node description, subtypes are described by the restrictions they place on aspects of the generic node; these are detailed in Table 2 below. Note that these may be broken down into further sub-classes before instantiation. Please note that ‘abstraction node’ and ‘discharge node’ refer to the start and end of the man-made water network. These correspond to an abstraction point and discharge point respectively, and do not themselves refer to natural water bodies. They are instead related to natural water bodies through the ‘abstractsFrom’ and ‘dischargesTo’ relationships, as shown in the ontology excerpt below and Figure 11:



<owl:ObjectProperty rdf:about="&WCIM;dischargesTo">

<rdfs:domain rdf:resource="&WCIM;DischargeNode"/>

<rdfs:range rdf:resource="&WCIM;WaterBody"/>

<rdfs:subPropertyOf rdf:resource="&WCIM;hasNetworkNatureRelationship"/>

</owl:ObjectProperty>

Table 2: Subtypes of the generic node

Node subtype Restrictions Extra properties

Abstraction node Output type must be ‘raw water’.

Contained water volume is assumed to be infinite.

Has no input.

Max output

Discharge node Max contained water volume is assumed to be infinite.

Has no output.

Pump node Output water pressure must be higher than input.

Input flow must equal output flow.

Input type must equal output type.

Currently active

WISDOM



Contained water volume is assumed to equal zero.

Storage node Input type must equal output type.

Max contained water volume must not equal zero.

Max stage height, current stage height, min stage height

Consumption node Output type must be ‘foul water’.

Treatment node Output type must not equal input type. Max output

Valve node Contained water volume is assumed to equal zero.

Input type must equal output type.

Current degree of openness

Each component which primarily transports water in the water network is modelled as an arc. These are further classified as either ‘WaterVehicle’ or ‘Pipe’. Each pipe is modelled as an arc within the water value chain graph and is a subset of the generic pipe presented in Figure 8 below.

Figure 8: Description of a generic pipe and its relevant data

Based on this model of an arc, each fitting between pipes would be considered as a node, however they serve little purpose within WISDOM, so arcs have been modelled as being able to be connected directly to other pipes where necessary, with the implicit assumption that a fitting exists at the connection. Pipes are classified as either; clean, raw, or waste, and are classified further as shown in Figure 12. As well as water specific properties, pipes are also described by their construction material, IPID, diameter (absolute and nominal), length, starting and finishing coordinates and elevations, and the preceding and succeeding nodes or pipes. Pipe shapes are modelled as object properties as shown in the OWL file excerpt below:



<owl:ObjectProperty rdf:about="&WCIM;hasPipeShape">

<rdfs:domain rdf:resource="&WCIM;Main"/>

<rdfs:range rdf:resource="&WCIM;PipeShape"/>

WISDOM



Based on the generic node and arc descriptions above, a water network is assumed to be made up only of instances of these two types of component, whereby each arc can be connected between only two nodes (including the implicit fitting nodes), but nodes can have any number of input and output arcs. Nodes cannot be connected without an arc. A simple and fictitious water network is shown in Figure 9 below to demonstrate how a network modelled using these nodes and arcs can manifest. Each entity in the network would then be enriched with a description of the physical components which it consists of as well as the sensors, data, regulations, social concepts and further descriptions which are relevant to it.

Figure 9: Simple water value chain showing connection of nodes (labelled) and arcs (arrows)

The network model described above has been formalised in OWL as an extension of the metamodel shown previously, and the main upper level classes and relationships of it are shown in Figure 10, next.

WISDOM



Figure 10: Main WCIM level classes and relationships

4.2.3. Natural Water Artefacts

Natural water bodies have been modelled as separate objects to the man-made water network, and are connected through abstraction and discharge nodes. As WISDOM focuses on the designed water network, little detail has been modeled surrounding natural artefacts. Natural artefacts have been categorized based on their type (e.g. reservoir, river, sea or borehole), with each containing any number of abstraction and discharge points and imposing restrictions on those based on the water body’s description. The water bodies’ relevant data properties are:

Natural reservoir

o Max volume

o Current volume

o Max depth

o Current depth

o Indicative coordinates

o Min depth

WISDOM



o Min volume

River

o Start coordinates

o End coordinates

Sea

Borehole

o Max abstraction rate


Lake


Aquifer


Well


Stream

o Start coordinates

o End coordinates

Spring


Ocean

The main concepts related to natural water bodies in the ontology are shown in Figure 11 below, which

further shows the connection between water bodies and abstraction and discharge nodes, and also shows

that water bodies are described by their water type, which would be ‘RawWater’.

Figure 11: Main WCIM classes and relationships relevant to natural water bodies

WISDOM



4.2.4. Supply-Side artefacts

Each node and arc within the water value chain serves a purpose towards a water value chain process and manifests physically as a physical artefact. These artefacts are described through the node and arc properties described previously. Table 3 details the main artefacts and their node types within each process of the water value chain and Figure 12 presents the main aspects of the OWL implementation of this class hierarchy.

Table 3: Artefacts in each water value chain process

Process Artefact Node type Sub-types

Abstraction Raw pumping station Pump node

Raw water pipe N/A (arc)

Raw water vehicle N/A (arc)

Clean treatment Clean water treatment plant Treatment node

Clean distribution Clean main N/A (arc) Communication pipe, Distribution pipe, Trunk main

Water vehicle N/A (arc)

Clean storage device Storage node Service reservoir, water tower

Clean pumping station Pump node

Clean valve Valve node Boundary valve, control valve, pressure regulating valve

Consumption Hydrant Consumption node

Boundary box Valve node

Building Consumption node Commercial building, Industrial building, Domestic building, Other building

Domicile Consumption node

Waste distribution Waste main N/A (arc) Combined waste main, connecting sewer, foul pipe, lateral drain, surface water pipe

Waste truck N/A (arc)

WISDOM



Chamber Storage node Combined chamber, foul chamber, storm water chamber, surface water chamber, treated effluent chamber

Waste pumping station Pump node

Waste treatment Waste treatment works Treatment node combined treatment works, foul treatment works, surface treatment works

Discharge Discharge pipe N/A (arc) Storm overflow pipe, emergency overflow pipe, treated effluent pipe

WISDOM



Figure 12: Main supply side WCIM classes and relationships

WISDOM



4.2.5. Domestic Artefacts

A key goal of the WISDOM project is to integrate knowledge across scales, where relevant domestic artefacts have been modelled. These primarily consist of consumption devices, but include water-saving devices and greywater devices. Where demand-side semantic knowledge is available for a customer, the demand-side WCIM instantiation for the customer’s property can be used to modify the consumption node’s properties at the supply level. As water flows between devices are not, often, actively managed in domestic properties, domestic pipes are not represented. This is because they can be assumed to exist, such that all domestic consumption simply uses water from the main supply, except in the case of this being offset through rainwater and greywater usage. Table 4 details the artefacts relevant at the domestic consumer scale and the domestic processes they contribute towards and Figure 13 presents the OWL class hierarchy of this. Also of relevance to domestic artefacts is the distinction between a ‘DomesticBuilding’ and a ‘Domicile, where the former is the physical building which contains one or more of the latter, as described in the following OWL excerpt:



<owl:Class rdf:about="&WCIM;DomesticBuilding">

<rdfs:subClassOf rdf:resource="&WCIM;ConsumerBuilding"/>

<rdfs:subClassOf rdf:resource="&WCIM;ConsumptionNode"/>

<rdfs:comment>A physical building, the purpose of which is to contain one or more domiciles</rdfs:comment>

</owl:Class>



<owl:Class rdf:about="&WCIM;Domicile">

<rdfs:subClassOf rdf:resource="&DUL;PhysicalPlace"/>

<rdfs:comment>The physical part of a domestic building which is inhabited by an individual group of tennants, which could be the entire building or could be a flat</rdfs:comment>

</owl:Class>

Table 4: Artefacts relevant to domestic water consumers

Process Artefact Sub-types Extra properties

Water usage Water using appliance tap, bath, shower, toilet, washing machine, dishwasher,

Average water consumption per use, average energy consumption per use

WISDOM



irrigation system, boiler, other

Rainwater usage Rainwater harvesting device

Rainwater purification device

Waste storage Domestic waste storage tank Septic tank, Cess pit

Greywater usage Greywater harvesting device Reuse device, harvesting device

Water metering Domestic water meter

Figure 13: WCIM Domestic artefacts

WISDOM



4.3. Sensor Ontology

The sensor ontology describes the concepts and relationships relevant in describing the physical characteristics and detection processes of the WISDOM sensing infrastructure, as well as linking resultant data to the WCIM by describing the sensed phenomena and sensed entities. This modelling has been conducted by adapting the Semantic Sensor Network (SSN) ontology developed by the World Wide Web Consortium (W3C) for the purposes of the WISDOM project, and water management in general. This section now outlines the key extensions to the SSN which have been conducted, and then indicates how this is integrated with the WCIM to enrich the sensed data through concept relationships.

4.3.1. Sematic Sensor Network Extension

The SSN ontology models sensors as devices which implement a ‘sensing process’ through a ‘measurement capability’. The ‘measurement capability’ is subject to various conditions and properties regarding operating conditions and accuracy. The sensing process receives a stimulus from the sensed event and outputs an information object describing some property of the stimulus. These sentiments are formalised into classes and relationships, these are simplified in Figure 14 and expressed further as an OWL implementation in Figure 15. The main ambiguous classes from Figure 15 are described in Table 5.

Figure 14: The W3C SSN ontology, simplified

WISDOM



Figure 15: OWL implementation of the SSN ontology

Table 5: Descriptions of main ambiguous SSN classes

Class Description

Stimulus The event which is the input of the sensing process

Operating range The environmental conditions and characteristics of a system/sensor's normal operating environment.

Survival range The conditions a sensor can be exposed to without damage.

Measurement property A characteristic of a sensor’s output. e.g. Accuracy, detection limit, drift, frequency, latency, measurement range, precision, resolution, response time, selectivity, sensitivity.

Observed property The quality of the physical phenomenon sensed which the sensor observes.

Sensing A process implemented by a sensor which produces an information object describing the value of a property of a phenomenon.

Measurement capability Collects together measurement properties (accuracy, range, precision, etc.) and the environmental conditions in which those properties hold, representing a specification of a sensor's capability in those conditions.

Condition Used to specify ranges for qualities that act as conditions on a system/sensor's operation.

WISDOM



The SSN ontology does not include any measurement concepts (units, etc.), nor domain concepts such as water management concepts, so has been extended beyond the classes and relationships shown above, to be suitable for use in an intelligent water sensing system. The main extensions applied to the SSN ontology for the purposes of WISDOM are subclasses of the sensor, property, sensing and stimulus classes with water specific concepts. An excerpt of these are shown in Figure 16 below, where all arrows indicate a ‘hasSubclass’ relationship. Restrictions are also in place between instances of these classes, for example a ‘FlowSensor’ can only implement ‘FlowSensing’. Water sensors also have additional data properties which are represented, including ‘ProductNumber’, ‘Manufacturer’ and ‘Attachment Type’ etc.

WISDOM



Figure 16: The main class hierarchy extensions to the SSN ontology for WISDOM

WISDOM



4.3.2. Data Enrichment & WCIM Links

In order for the knowledge stored in the sensor ontology to be leveraged alongside the WCIM knowledge, and to make greater use of the real time data, relationships between the physical, sensory and virtual concepts in the domain have been modelled. These manifest primarily between the sensor ontology, the WCIM and the new concept of a ‘TimeSeriesStore’; a virtual object which stores time series data from a sensor. The key relationships to this end are shown in Figure 17 below (inverse relationships may be valid but not shown for simplicity).

Figure 17: Key relationships between WCIM & Sensor Ontology concepts

Through the relationships shown in Figure 17 above, data have been contextualised in terms of the component they relate to, their unit, the sensor they originated from and the water property they relate to. Specifically, instances of the ‘Sensor’ class have a ‘collectsDataAboutEntity’ object property slot, the range of which is a physical node or arc, and the ‘TimeSeriesStore’ which collates data from the ‘Sensor’ has a ‘collatesDataAboutEntity’ relationship with the same node or arc, as shown below:



<owl:ObjectProperty rdf:about="http://www.WISDOM.org/WISDOMontology#collectsDataAboutEntity">

<rdfs:domain rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#Sensor"/>

<rdfs:range rdf:resource="http://www.WISDOM.org/WISDOMmetamodel#PhysicalArc"/>

WISDOM



<rdfs:range rdf:resource="http://www.WISDOM.org/WISDOMmetamodel#PhysicalNode"/>


 <owl:ObjectProperty rdf:about="http://www.WISDOM.org/WISDOMontology#collatesDataAboutEntity"> <rdfs:range rdf:resource="http://www.WISDOM.org/WISDOMmetamodel#NetworkEntity"/> <rdfs:domain rdf:resource="http://www.WISDOM.org/WISDOMontology#TimeSeriesStore"/> </owl:ObjectProperty>

Furthermore, as an instance of the superclass ‘Device’, all sensors have the object property slot ‘isSituatedAtEntity’ to describe their physical location in the water network. In this way the sensing capabilities of the network can be inferred and data can be shared more easily between software components, as its meaning is understood and shared. Dynamic data will actually exist both as a data property for instances of the ‘TimeSeriesStore’ class (for the most recent data) and within the separate dynamic database, which the TimeSeriesStore provides a pointer to (as its name is the event database path of the sensor).

4.3.3. Modelling patterns for KairosDB-Ontology integration

Figure 18 clarifies the modelling pattern adopted for the data layer in accordance with the SSN ontology, by illustrating the mapping between terms used in the ontology and terms used in the KairosDB system.

Figure 18: Mapping between KairosDB terms and WISDOM ontology terms

WISDOM



4.3.4. Problems and alerts

During the development of the inference engine, and based on industry feedback, ontological concepts regarding alarms, problems, and alerts, were modelled. This allowed the rule engine developed within this task to provide more powerful inference, and useful decision support. Please note that this is a separate entity to the rules engine developed in WP3 (T3.1). The key concepts and relationships of the modelling pattern adopted are presented in Figure 19 below. Within this pattern, the entity->problem relationship is inferred at runtime based on the sensor data. Further, WaterAlert individuals have an ‘isActive’ Boolean property. As description logic is monotonic, semantic reasoning cannot infer the existence of new individuals. This means that the alerts and problems must either all be defined in the ontology prior to deployment (where all the potential problems are enumerated but ‘inactive’), or external software must create new named individuals when a problem arises, which is far preferable in terms of scalability, extensibility, and development time. The only condition for alert triggering which has been modelled is a simple range-based condition, where the alert is active if the sensor reading falls outside that range. This could be extended for other use cases, such as sensors not returning readings for a period of time, Boolean rules, state based rules, and more complex alerts such as network scale water balancing issues.

Figure 19: Key concepts and relationships regarding network problems and alerts

4.4. Water Value Chain Social Model

The Water Value Chain Social Model (WVCSM) formalizes the domain vocabulary for the social nodes and arcs implied in the meta-model presented previously. This vocabulary shares parallels with the WCIM as the node-arc relationship is similar in nature, although, a somewhat different modelling approach has been adopted in the WVCSM. Within this model the arcs are social agent to social agent relationships, yet are modelled as classes themselves rather than object properties, which is the case between physical artefacts and physical artefacts. This choice has been made as relationships between entities are of far more importance in the social domain, such that complete descriptions of the relationships themselves are necessary to fully describe a pilot site. For example, describing the details of a contract between a

WISDOM



regulatory body and a water company is important to fully formalize its implications. The main groups of concepts in this model are its graph model parallel to the WCIM graph model, the relationship artefact descriptions and stakeholder descriptions. This section will discuss these in turn before presenting the links between the social ontology and the WCIM and sensor ontologies.

4.4.1. Social Network Model

As with the WCIM, the social aspects of the water management domain are modelled here as a network of nodes connected by arcs. However, the social network varies in that the majority of the complexity lies in arc descriptions rather than node descriptions. Social nodes are referred to as ‘agents’, and agents in this domain are typically people or organisations, although the majority of the social information required to manage the water network lies in the relationships between these people and organisations, and between these and components of the physical water network. This has been modelled through the network entity class hierarchy shown in Figure 20. This contrasts the WCIM graph model where arcs are simply pipes or trucks which transport water from one node to another, whereby the nodes infer the management complexity. Nonetheless, data properties will describe the organisations and people themselves as appropriate. As with the WCIM, the water social ontology exhibits a clear divide between ‘supply’ side concepts and domestic concepts.

WISDOM



Figure 20: WVCSM class hierarchy of main social network entities

A social ‘node’ is a conceptually bounded entity connected to any number of arcs, and a social arc is a relational entity which connects 2 nodes. Supply side social arcs represent entities such as employment contracts, regulations and management structure relationships. A generic social graph model is shown below in Figure 21, where people and organisations are nodes and relationships are arcs, which can exist between any permutation of both internal and external relationships relative to an organisation. Each of the node and arc classes shown in Figure 21 are an upper class that is divided into a number of sub-classes in either the node descriptions or the relationship descriptions, in either the supply side or demand side domains, as explained further on.

WISDOM



Figure 21: Example supply-side social network

It is important to notice the system-of-systems approach within this model, meaning that knowledge can be captured both at the interpersonal and inter-organisational level, whereas in the physical water network there are no clear, relevant, autonomous sub-systems to warrant the use of a system-of-systems approach. This implies a multiple level-of-detail approach, where a user of the ontology could input only organisational nodes and relationships for simplicity (e.g. ‘DCWW’ ‘isRegulatedBy’ ‘Ofwat’) or could model as much interpersonal data as required for the scenarios they wish to implement (e.g. ‘DMAmanager1’ ‘coordinates’ ‘PumpManager1’). In this way organisations interact within an upper network and people interact within organisations through sub-networks, or they can interact across organisational boundaries.

Finally, it is critical to appreciate the different purposes of the supply-side (clean & waste services) social model and the domestic social model. The supply-side model aims to enrich asset descriptions and sensory data and facilitate data exchange, optimisations and data relevance, whereas the domestic model aims to categorise a ‘domicile’ based on the social system which occupies it and its water use, integrate water data across scales and facilitate neighbourly water interactions. An example of a simple domestic social network is shown in Figure 22, which models two houses and their inhabitants; one with a parent and two children, and one with a single inhabitant.

WISDOM



Figure 22: Example domestic social network

The domestic social model is further enriched with demographic and water data and object properties, more so than other areas of the ontology, regarding each node and arc, based on the questions asked of residents via surveys. The nature of this enrichment is shown in the following excerpt from the XML serialization of the ontology:

 <owl:DatatypeProperty rdf:about="http://www.WISDOM.org/WISDOMontology#considersWaterConservationImportant"> <rdfs:domain rdf:resource="http://www.WISDOM.org/WISDOMontology#Resident"/> <rdfs:subPropertyOf rdf:resource="http://www.WISDOM.org/WISDOMontology#hasResidentProperty"/> <rdfs:range rdf:resource="&xsd;boolean"/> </owl:DatatypeProperty>  <owl:DatatypeProperty rdf:about="http://www.WISDOM.org/WISDOMontology#hasAge"> <rdfs:domain rdf:resource="http://www.WISDOM.org/WISDOMontology#Resident"/> <rdfs:subPropertyOf rdf:resource="http://www.WISDOM.org/WISDOMontology#hasResidentProperty"/> <rdfs:range rdf:resource="&xsd;int"/> </owl:DatatypeProperty>  <owl:DatatypeProperty rdf:about="http://www.WISDOM.org/WISDOMontology#hasAverageMinutesPerShower"> <rdfs:domain rdf:resource="http://www.WISDOM.org/WCIM#Domicile"/> <rdfs:subPropertyOf rdf:resource="http://www.WISDOM.org/WISDOMontology#hasDomicileProperty"/> <rdfs:range rdf:resource="&xsd;int"/> </owl:DatatypeProperty>

WISDOM



 <owl:ObjectProperty rdf:about="http://www.WISDOM.org/WISDOMontology#hasGenderIdentity"> <rdfs:range rdf:resource="http://www.WISDOM.org/WISDOMontology#GenderIdentity"/> <rdfs:domain rdf:resource="http://www.WISDOM.org/WISDOMontology#Resident"/> <rdfs:subPropertyOf rdf:resource="http://www.WISDOM.org/WISDOMontology#hasResidentProperty"/> </owl:ObjectProperty>

4.4.2. Water Management Stakeholders

The main stakeholder organisations (which are social agents represented as nodes) within a water value chain have been categorised according to the class hierarchy shown in Figure 23. Please note that an individual organisation could be an instance of multiple subcategories, e.g. DCWW both abstracts and supplies water. Furthermore, a supply company could be both a ‘RetailCompany’ and a ‘PotableSaleCompany’. Where necessary for the WISDOM project’s scenarios, individual persons within water supply companies may be modelled. These are categorised by job role, primarily so as to determine the persons responsible for controlling and monitoring assets; for example to determine data relevance.

Figure 23: WVCSM water management organization class hierarchy

4.4.3. Supply-Side Relationships

Supply-side relationships are modelled as entities in themselves so that they can be described in detail, such as where a contract details a number of obligations of an organization: the contract is modelled as a

WISDOM



relationship and its relevant details are described as object and data properties. These relationships, which are arcs in the social graph model, are categorised as either person-person, person-organisation, organisation-organisation, organization-governing body or organization-municipality; where ‘organisation’ refers to a water company. These relationships are further categorized, the main groups of which are shown in Figure 24. The main classes foreseen as likely to be instantiated are the organisational relationships, in order to capture their descriptions and obligations. Individual people and their relationships could be modelled for scenarios where this would be useful, such as delegating a specific pump to a pump controller and describing the pump controller’s management hierarchy in order to determine the data and decisions to present to each person.

Figure 24: WVCSM class hierarchy of supply side relationships

4.4.4. Domestic Social Relationships

To classify domestic consumption profiles and formalise domestic level water use behaviour, domestic social networks are modelled. Within domiciles, all people are simply modelled as people (rather than ‘parent’ or ‘child’), and domestic role distinctions are modelled through relationships between the domicile’s inhabitants and neighbours. Additionally, these relationships can be described through data properties and supplementary object properties if it becomes apparent that this is necessary for the WISDOM project’s scenarios. The main relationships are family and neighborly relationships, which can broadly categorise domiciles into usage profiles and be used to distinguish potential water game interactions between people. It is important to note that this domain model represents the language used to describe concepts relevant to the domain, and does not imply that the WISDOM project will aim to populate detailed domestic relationship data across its pilot households, but rather provides the option of describing these relationships where they are elicited explicitly, or are inferred, where suitable and respectful of all privacy and data security concerns. The relationship hierarchy is shown in Figure 25 below and the relevant properties are summarized in Figure 26, the data properties of which are formalized in the same manner as shown in the following OWL excerpt:

WISDOM





<owl:DatatypeProperty rdf:about="http://www.WISDOM.org/WISDOMontology#hasNumberOfRooms">

<rdfs:domain rdf:resource="http://www.WISDOM.org/WCIM#Domicile"/>

<rdfs:subPropertyOf rdf:resource="http://www.WISDOM.org/WISDOMontology#hasDomicileProperty"/>

<rdfs:range rdf:resource="&xsd;int"/>

</owl:DatatypeProperty>

Figure 25: WVCSM Domestic social relationship class hierarchy

WISDOM



Figure 26: WVCSM domestic properties

WISDOM



4.4.5. Supply Side Socio-Technical Relationships

As well as modelling relationships between social entities at the supply and domestic level, it is critical to formalise a vocabulary for describing relationships between these entities and the physical and virtual entities of the water value chain. Again, these relationships exist either at the supply or domestic level, to ensure efficient management or to promote improved consumption behaviour (& behaviour modelling) respectively. By linking the social and technical networks, a socio-technical network emerges whereby the implications and contexts of management decisions can be considered across both systems, regulations can be modelled in terms of the social entities they affect and data relevance can be inferred based on a person or organisation’s role in the water value chain. A simple, fictitious, example socio-technical water system is shown partially in Figure 27 (blue – social, red – technical, green – virtual, white – relationship) to aid understanding of the approach adopted.

Figure 27: Partial, fictitious example socio-technical network

Whereas physical relationships were modelled as object properties and social relationship types were modelled as classes, socio-technical relationship types have been modelled as either a class or an object property type. It is variable whether the relationship itself will require much description, and directly relating instances is preferable towards computability of inference. For example, the relationship of a person or company controlling a pump has been modelled as an object property, whereas a regulation which enforces that a company maintain a set water

WISDOM



pressure requires much description, so has been modelled as a class. The nature of these socio-technical classes is shown in Figure 28 below with an example on both the supply and domestic side. The main social and socio-technical classes and relationships are then shown in Figure 29.

Figure 28: WVCSM socio-technical arc classes on both supply and demand side

WISDOM



Figure 29: WVCSM main supply side social and socio-technical classes and relationships

4.4.6. Domestic Socio-Technical Relationships

The domestic socio-technical water system is simplified here to only model consumption and conservation behaviours, ignoring domestic plumbing and flow control as it is not actively managed in the majority of homes. Beyond the domestic social network described previously, this has been formally linked to relevant physical and sensory concepts such as appliances and measured consumption values. In order to relate these, the concept of an ‘ApplianceConsumptionPattern’ has been introduced, which links a person to a consumption process, an appliance and a piece of data regarding typical consumption (here assumed to be average weekly consumption, but this could be a detailed weekly schedule). This can then be used to infer the total consumption by a person or domicile for an appliance or overall, which can be used to improve demand prediction, and to integrate data across scales. These relationships are shown in Figure 30. It is intended that consumption pattern knowledge will be provided directly by users in most cases, but could be sensed directly where sufficient sensors have been deployed in a domicile. Beyond this relationship, the

WISDOM



notion of inhabiting a domicile has been modelled and is a socio-technical relationship as a domicile has been considered in its physical sense.

Figure 30: WVCSM Consumption pattern concept and relevant object properties

4.4.7. Economic Concepts & Relationships

Whilst this ontology primarily models social concepts, some economic concepts have been included in order to characterise social behaviour within domiciles and further contextualise management decisions and sensed data. The main economic entity in domestic water consumption is the water bill; this is related to a person through the ‘main bill payer’ relationship and to a tariff through the ‘charged according to’ relationship. The tariff could be a static rate or could be a dynamic pricing scheme. Economic concepts at the supply level have not been modelled but will be considered alongside the scenarios to be implemented and could be modelled if required.

4.5. WISDOM Domain Ontology Validation

The initial, automated check of the ontology’s consistency through the built in Protégé reasoner has been conducted many times throughout the ontology’s development to date, and has consistently passed the test; that is to say that the ontology does not contain contradictory statements and as such can be instantiated without contravening any statements. The competency questions have been utilized throughout the semantic activities as a guide, and from a manual check they can be answered by the ontology in its current form. This has been checked thoroughly by ‘asking’ the questions as SPARQL queries once the pilot site knowledge bases were finalized. The domain expert validation was conducted separately with the Italian and the Welsh domain expert partners through one day workshops, and in both cases the ontology’s modelling choices were broadly validated, the majority of the detailed modelling choices were validated and corroborated between workshops, and some revisions and extensions were suggested. These modifications have been made and are reflected in the version of the model presented in this deliverable. An additional workshop with the WISDOM partners and special interest group experts was then conducted, which served to validate that the changes made were sufficient and hence that the ontology is now sufficient. This workshop was held with parties from all WISDOM pilot sites present, so as to produce discussion and a consensus of either validity, or of the necessary revisions.

The domain ontology was tested for validity at the November 2015 SIG meeting, where it was considered by a wider range of stakeholders in the water value chain, most of which had little bias towards the WISDOM

WISDOM



project. This offered a broad view on the ontology and hence tested its extent, as well as its detail in areas of the water value chain which the WISDOM partners are not experts in. That consensus was reached that the WISDOM ontology represents a shared and sufficient conceptualization of the domain by this group, represents a significant milestone in its validation. Finally, the domain ontology was tested in an integrated manner with the other semantic components through the web service testing, which determined that the ontology successfully and sufficiently contributes to an ‘ICT for water’ web platform. This integration with the other WISDOM components has been conducted to a preliminary stage, and represents ongoing work within other project tasks.

Some of the comments from the SIG expert validation session were:

1. The ontology addresses the problem of interacting between tools (GIS, SAP, customer data) 2. Include alarms as well as sensors 3. ‘Governing body’ is also called ‘regulator’ 4. Include ‘water testing company’

The 2nd comment is addressed in Section 4.3.4, the 3rd comment has been addressed by adding a comment to the class, and the 4th comment was addressed by including a ‘waterTestingCompany’ class. The majority of comments were advisory or generic, such as regarding possible future work, rather than required changes in the scope currently addressed. Examples of these comments were:

The work could be considered as a type of enterprise service bus

An ontology is also called a taxonomy

Sensors could also be ‘social sensors’, which report numbers of tweets etc

Collaboration relationships exist between utilities which share a water resource

Table 6 below presents example outcomes of the competency question testing, showing how the deployment sufficiently answers the questions when formalized as SPARQL queries, where the queries were answered in circa 15ms.

Table 6: Example competency question testing evidence

Natural language question:

What is sensor E2000’s current reading?

SPARQL query

PREFIX wis:<http://www.WISDOM.org/WISDOMontology#>

PREFIX rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>

PREFIX dul: <http://www.loa-cnr.it/ontologies/DUL.owl#>

SELECT ?reading

WHERE {

WISDOM



wis:E2000 rdf:type wis:LevelSensor.

wis:E2000 wis:hasLatestOutput ?output.

?output dul:hasDataValue ?reading }

Output (csv format)

reading

2.0

Natural language question:

What is Pipe X’s material?

SPARQL queryp

PREFIX wis:<http://www.WISDOM.org/WISDOMontology#>

PREFIX rdf:<http://www.w3.org/1999/02/22-rdf-syntax-ns#>

PREFIX dul: <http://www.loa-cnr.it/ontologies/DUL.owl#>

SELECT ?material

WHERE {

wis:Pipe_01 rdf:type wis:Main.

wis:Pipe_01 wis:hasMaterial ?material }

Output (CSV format)

material

wis:PVC

4.6. Integration with Existing Standards and Ontologies

4.6.1. Alignment with WatERP Ontology

As described in the previous methodology section 2.9, the WISDOM ontology was aligned to the WatERP ontology, and hence (given WatERP’s existing alignment) with the recommendations of WaterML2. This was stated through OWL annotations for relevant classes and properties, an example of an OWL annotation is shown in Figure 31 below.

WISDOM



Figure 31: Example annotation showing slots for multi-lingual support, comments and alignments

The majority of modelling patterns adopted by the two ontologies were homogeneous (from their joint grounding in the SSN ontology), meaning that many equivalencies could be stated, and that a WatERP knowledge base could be broadly interoperated with a WISDOM knowledge base. This matching of the two ontologies emerges from their dual inheritance from the SSN ontology, where the meaning of ‘ontology inheritance’ is defined by [33]. However, further matching was achieved through manual alignment (again defined by [33]), which involved revising the WISDOM ontology by adding concepts and axioms and revising existing ones to produce a compatible domain perspective which still met the ontology’s requirements. The matched terms are stated in Table 7 below.

Table 7: Alignment of WISDOM and WatERP concepts

WISDOM concepts WatERP concept

Action Action

WholesaleCompany BulkWaterSupplier

ConsumptionAppliance Appliance

ConsumptionProcess WaterUse

ConsumptionProcess Activity

WaterBody BodyOfWater

WaterUtility WaterUtility

GoverningBody Regulator

occursAtEntity isModelOf

AgriculturalConsumption AgriculturalUse

SampledFeature SampledFeature

WISDOM



SupplyChainProcess WaterResourceManagement

TimeValuePair TimeValuePair

Organisation WaterIndustry

hasState hasState

FeatureOfInterest FeatureOfInterest

WaterAlert Alert

StorageNode Storage

TransformationNode Transformation

DesignedArtifact Infrastructure

WaterConsumer Consumer

PhysicalArc Transport

Property Phenomenon

requiredToSolve solves

WaterBalanceState State

AbstractionNode Source

observationResultTime hasTimestamp

ObservationResult ObservationResult

IndustrialConsumption IndustrialUse

Observation Observation

ConsumptionNode Sink

SocialAgent Actor

implementsConsumption peformsActivity

PhysicalTopologicalEntity WaterResource

isDescribedBy hasObservation

hasValue hasValue

This alignment represents a key benefit of the ontological approach, whereby knowledge bases can be interoperated following schema alignment. For example, a system modelled through the WatERP ontology could be extended with the WISDOM ontology’s detailed physical network concepts without having to redo or change the existing knowledge base. Some of the WatERP modelling patterns and concepts could not be aligned with the WISDOM ontology, as shown in Table 8, although this degree of heterogeneity wouldn’t preclude the symbiosis of the two ontologies in a deployed system. This extensibility is derived from the

WISDOM



fundamentally distributed and extensible nature of the semantic web, whereby domain perspectives can be interoperated by utilizing concepts, predicates and named individuals from across ontologies or RDF stores. An example of this manifesting would be a situation where a WatERP pipe is described using WISDOM concepts, such as in the triple WatERP:Pipe_001 RDF:type WIS:TrunkMain. This would then allow a reasoner to infer extra knowledge about the pipe based on the WISDOM Tbox, and would allow ontology-driven applications to leverage both domain perspectives on the available Abox. This is significant as it allows the extension of existing models without requiring the previous models to be converted to a new format, hence promoting stepwise evolution and modularity.

Table 8: Main heterogeneity between WatERP ontology and WISDOM

WatERP concept Closest WISDOM concept(s)

Comments on Heterogeneity

TimeSeriesObservation TimeSeriesStore, TimeValuePair

The WISDOM ontology perceives an observation result as the outcome of a single act of observation. This is such that an observation is made available at a single point in time, in accordance with SSN:ObservationResultTime.

Cluster WaterConsumer subclasses

The WISDOM ontology models types of water consumers as subtypes of water consumer, as it is logically inconsistent to state that a consumer is a type of group of consumer, as a group must contain more than one member.

WaterUse ConsumptionProcess Whilst these classes appear weakly aligned, it is inconsistent to state that a group of consumers is a type of consumption process, which would be explicit in the WISDOM ontology if this alignment was formalised, unless the definition of the WaterUse class has been misunderstood.

Consumer WaterConsumer, SocialAgent,Resident

The WatERP ontology states that a Consumer is a type of EndUser, but it is not clear which individuals may exist in the EndUser set but not in the Consumer set. In the WISDOM ontology, it is assumed that no such individuals exist, such that the two classes are equivalent.

UserClass WaterConsumer, SocialAgent,Resident

The WatERP ontology states that a UserClass is a type of Consumer, but the WISDOM ontology models types of Consumer as subclasses. In order to model specific people or water consuming organisations, an individual of type WatERP:UserClass would be a class and an individual, which would require the use of OWL Full, as “a class can not also be an individual” [34].

WISDOM



The key areas of the WatERP ontology which are outside of WISDOM’s scope are FinanceManagementFlow, Instruments, and AssessmentIndicator. The main aspects of the WISDOM ontology which are out of WatERP’s scope are WasteNetwork concepts, ConsumptionProcess subclasses, DesignedArtefact subclasses, DesignedArtefact properties, Sociotechnical relationships, Sensor subclasses, MeasurementCapability, Sensing, and subclasses and object properties which model additional depth to the concepts modelled by WatERP.

4.6.2. Alignment with the Industry Foundation Classes

Broad alignment with the non-ontological resource of the relevant parts of the Industry Foundation Classes (IFC) was achieved, as shown in Table 9, although the IFC schema assumes that all individuals are within the context of a building, or at least an ‘architecture, engineering and construction’ scope, so further testing and refinement is needed for this alignment.

Table 9: Potentially aligned WISDOM and IFC concepts

WISDOM term IFC term

Sensor IfcSensor

AlarmDevice IfcAlarm

PhysicalQuantity IfcPhysicalSimpleQuantity

Arc IfcEdge

DesignedArtifact IfcAsset

Pump IfcPump

Building IfcBuilding

Entity IfcObject

PhysicalArtifact IfcProduct

Process IfcProcess

Node IfcVertex

Fitting IfcPipeFitting

Condition IfcConstraint

Amount IfcQuantityCount

Length IfcQuantityLength

TopologicalNetworkEntity IfcTopologicalRepresentationItem

PhysicalTopologicalEntity IfcTopologicalRepresentationItem

WISDOM



Property IfcProperty

TimeInterval IfcQuantityTime

Area IfcQuantityArea

Chamber IfcDistributionChamberElement

WaterMeter IfcFlowMeter

StorageAsset IfcFlowStorageDevice

Weight IfcQuantityWeight

hasLocation IfcPlacement

TreatmentWorks IfcFlowTreatmentDevice

Volume IfcQuantityVolume

Main IfcPipeSegment

Actuator IfcActuator

Event IfcEvent

TerminalNode IfcFlowTerminal

Valve IfcValve

ElectricAppliance IfcElectricAppliance

WaterSensor IfcFlowInstrument

Material IfcMaterial

4.6.3. Alignment with INSPIRE

The INSPIRE directive [25] aims to facilitate geospatial data exchange within Europe, so as to foster international coordination in situations such as river contamination (where rivers cross country borders), and so has produced a set of data specifications, as UML class diagrams. These artefacts (from their application theme of utility networks and government services) include a data specification for generic networks and utility networks, and slightly more specific models for sewer networks and water networks. These model high level topological relationships and entities such as nodes and arcs, as well as some enumerations such as water types, node types, and warning types. Whilst full alignment with the code lists which INSPIRE propose is out of scope, this could be achieved given the alignment of critical modelling decisions. This alignment is shown in

Table 10 as a set of aligned terms, which represent classes and object properties.

WISDOM



Table 10: Aligned terms between the WISDOM ontology and the INSPIRE utility data models

WISDOM term INSPIRE term

WaterPipe WaterPipe

Main Pipe

WastePipe SewerPipe

Node Node

hasNetworkEntity elements

hasInputArc spokeEnd

isInNetwork inNetwork

hasEndNode endNode

PhysicalArc UtilityLink

hasOutputArc spokeStart

PhysicalNetwork UtilityNetwork

Arc Link

hasStartNode startNode

PhysicalTopologicalEntity Network::NetworkElement

PhysicalNode Appurtenance

WISDOM



4.6.4. Placement within Existing Standards

Based on the reuse and alignments of the WISDOM ontology with other knowledge modelling artefacts and standards, it is well situated to serve a role in the standardisation landscape, following some development of its maturity through industrial exposure and accepted standardisation processes. The ontology builds on existing work and interoperates with relevant standards in the water, IoT, and knowledge management fields, as illustrated in Figure 32.

Figure 32: Alignments between WISDOM ontology and other models and standards

WISDOM



5. PILOT SITE KNOWLEDGE BASES

Following directly from the domain ontology development, the knowledge base development represents the instantiation of this domain modelling at each specific pilot site. This follows typical semantic web practice whereby domain knowledge is formalized as ‘Tbox’ axioms, and instance level data is formalized as ‘Abox’ axioms. This section therefore presents the process and outputs of this work, which resulted in pilot site knowledge bases for each of the Cardiff, Gowertown, North Wales, and La Spezia pilot sites. This work adopts a novel methodology of converting GIS data to RDF data through a Python script, which itself represents a secondary output of the task. The section next discusses the Tbox – Abox approach further, before presenting the instantiation methodology and finally describing the process and outputs for each pilot site in turn. As the AQUASIM pilot site does not represent a network level pilot site, it is not relevant to instantiate the water value chain ontology proposed for this project, so this is not included.

5.1. Knowledge Base Introduction

The semantic knowledge bases produced here continue the use of the W3C semantic web framework adopted in formalising the ontology as an OWL ontology. The domain ontology presented represents a language which can be used to describe a water value chain, and each knowledge base uses this language to describe a pilot site. In this manner each pilot site knowledge base uses the same language, but is itself entirely separate to the other pilot site knowledge bases. That is not to say that knowledge cannot be shared between pilot sites, just that they have been separated for manageability, and because little direct utilisation of each other’s data was undertaken. The concept of this reuse of the domain ontology in

separate knowledge bases is shown in Figure 33 below through the example of instances of the ‘Pipe’ class at each pilot site.

Figure 33: Representation of the separate knowledge base approach in WISDOM

WISDOM



Each knowledge base was produced by reusing existing data from utility company project partners where possible, and completing the remaining instantiation manually, to the completeness required in order to satisfy the requirement specification. This process is now described, before each of the knowledge bases is presented in turn.

5.2. Methodology

The knowledge bases were instantiated primarily by reusing GIS, sensor, and simulation data provided by industrial partners, through the development of a Python script which performed this conversion. This was then enriched manually with further sensor and social entity descriptions. The scripts extracted the relevant entities and properties from the GIS and EPANET files and sensor databases provided (following automated conversion to comma-separated value (CSV) format) and produced an RDF/XML serialization of the data aligned with the domain ontology. Specifically at the Welsh sites, as subtly different GIS schemas were provided for each pilot site, which needed to be converged to the same domain model, different scripts were made for each pilot site, although each followed a similar pattern. At the Italian site, an EPANET model was provided, the input file for which was split into relevant CSV files describing each type of entity, before utilizing the same Python approach as at the Welsh sites. The main functions of each part of these scripts are the same, and these parts are shown in Figure 34 below. This script is now briefly described, before the data enrichment through the process is described, and then each Abox is presented in turn. Each Abox file could be trivially merged with the Tbox if required, or kept separate until storage in the triple store.

WISDOM



### 1 ### Import Python libraries

import rdflib

from rdflib import *

import csv

### 2 ### Instantiate rdflib ontology variable and namespaces

g = rdflib.Graph()

WIS=Namespace("http://www.WISDOM.org/WISDOMontology#")

SSN=Namespace("http://purl.oclc.org/NET/ssnx/ssn#")

#########################

### 3 ### Open CSV file

with open('Control Valves.csv', 'rb') as csvfile:

spamreader = csv.reader(csvfile, delimiter=',')

### 4 ### Iterate through all rows of the spreadsheet

for row in spamreader:

### 5 ### Ignore the first row of the sheet

if row[0]=="OBJECTID" : continue

print 'control valve', row[0]

### 6 ### Create new named individual with appropriate URI

rowURI = WIS['DcwTywConVal'+row[0]]

### 7 ### Assign all relevant properties from the row to the individual as RDF triples

g.add((rowURI,RDF.type,WIS.ControlValve))

g.add((rowURI,WIS.hasIpid, Literal(int(row[9]))))

g.add((rowURI, WIS.hasXcoord, Literal(float(row[11]))))

g.add((rowURI, WIS.hasYcoord, Literal(float(row[12]))))

if row[4] != "0": g.add((rowURI,WIS.hasNominalDiameter,Literal(float(row[4]))))

if row[5] != "0": g.add((rowURI, WIS.hasUnit,Literal(row[5])))

#########################

### 8 ### Repeated for other GIS database sheets …

print("graph has %s statements." % len(g))

### 9 ### Write the ontology to file with XML/RDF serialization

f=open('rdflibtest.rdf', 'w')

f.write(g.serialize(format='xml'))

f.close()

Figure 34: Main parts of the GIS - RDF conversion Python script

As shown in Figure 34, the Python script to convert the GIS export files to RDF data contained 9 parts; each similar across the pilot site scripts, although sections 3-7 used different terminology and column placements, due to the different GIS exports. These 9 steps are now briefly summarized:

1. Import the RDFlib [13] and CSV libraries, to facilitate use of these file formats 2. Create an RDFlib graph object, and RDFlib namespace; the graph is used as a container for the

triples and the Namespace variables shorten URIs 3. Use the Python CSV library to open the CSV file and create a reader object to parse the data into a

list of lists 4. Iterate over each nested list, which each includes the data from a single row 5. Ignore the column header row, then print the new individual’s name to the console

WISDOM



6. Create a new named individual using RDFlib, with a URI based on the base namespace, a pilot site and asset type string, and the entity’s GUID from the GIS system

7. Create triples from all the relevant columns of the sheet to fully populate the description of the individual. The example only shows RDF:type and OWL:DatatypeProperty statements, but the actual code also automated object property statements.

8. State the size of the resultant Abox to the console. 9. Open an RDF file and write the data to it, using RDF/XML serialisation

The GIS entity database is shown in Figure 35, and a CSV export of this is shown in Figure 36. The converted format of this data is shown in RDF/XML serialization in Figure 37 and in the Protégé software in Figure 38. This chain of data representations shows the enrichment the data has undergone in being federated into the WISDOM ontology: in the GIS format the data is simply stored as a list of values and the meaning of the values is assumed by the software using the data. In the RDF/XML serialization the data is linked to properties which themselves have descriptions, and where appropriate the property itself is an object with its own set of object and data properties; therefore, the meaning is far more explicit and could be reused by other software with far less risk of misinterpretation.

Figure 35: GIS entity database screenshot

Figure 36: Exported CSV data from GIS entity database

WISDOM



Figure 37: RDF/XML serialization from entity description in CSV format

Figure 38: 'CombinedWastePipe' instances and their properties, following conversion from CSV

Figure 39 shows an excerpt of the EPANET input file, and its CSV counterpart, which fed directly into the approach proposed. This approach of extracting CSV files from an EPANET input file simplified the coding required, although an EPANET Python library could have been used to directly extract knowledge from the EPANET input file, which represents a possible avenue of future work.

WISDOM



[TANKS]

;ID Elevation InitLevel MinLevel MaxLevel Diameter MinVol VolCurve

[PIPES]

;ID Node1 Node2 Length Diameter Roughness MinorLoss Status

p1 n1 n2 341.9 450 100 0 Open ;

p108 n129 n130 9.001 500 100 0 Open ;

p110 n133 n131 67.07 450 100 0 Open ;

p114 n138 n139 53.84 450 120 0 Open ;

p125 n154 n151 215.75 450 120 0 Open ;

p127 n156 n152 104.92 450 120 0 Open ;

p173 n203 n204 807.28 450 100 0 Open ;

p180 n213 n214 203.80 450 120 0 Open ;

p207 n240 n241 3.73 200 120 0 Open ;

p211 n244 n245 4.12 50 120 0 Open ;

p225 n258 n256 2.84 32 100 0 Open ;

p229 n262 n259 2 65 100 0 Open ;

p230 n263 n264 3.57 450 100 0 Open ;

24 n218 n161 120.54 450 100 0 Open ;

25 n173 n161 43.46 450 100 0 Open ;

26 n173 n171 40.43 450 100 0 Open ;

27 n171 n167 39.30 450 100 0 Open ;

28 n167 n164 66.56 450 100 0 Open ;

29 n164 n176 183.79 450 100 0 Open ;

30 n176 n183 9.99 450 100 0 Open ;

49 n179 n156 16.67 450 100 0 Open ;

50 n183 n179 78.61 430 150 0 Open ;

Figure 39: Input EPANET data

Expressiveness and extensibility are significant benefits of the semantic modelling approach. For example, the ‘hasMaterial’ property is an object property which connects a pipe to a material, the material can then be described by properties such as surface roughness, for hydraulic modelling, or fracture toughness, for earthquake resilience simulation. These examples show respectively that the approach allows greater value to be derived from the initial data by formally describing it in a machine interpretable manner, and allows extensibility beyond its initial purpose with little effort. Further, semantic inference over the RDF form of the data allows greater value to be derived from the original data. For example the ‘goesToIpid’ is a datatype property which connects a pipe to an integer, but an SWRL is used to infer the knowledge that, given that the integer is the ID of another pipe, the latter is downstream of the former pipe. This is discussed more in the inference section.

5.3. Knowledge Base Results

This section presents the pilot site models developed, following the methodology described in the previous subsection. The input and output data for each model is summarised, before the main modelling patterns used and objects modelled in the knowledge bases are illustrated.

WISDOM



5.3.1. Cardiff Pilot Model

7 CSV files were used as a basis for extracting information regarding the Cardiff pilot site; these described the system valves, meters, mains, control valves, boundary valves, hydrants, and asset sensors. In total, these represented 352 KB of data. The number of entities and properties in each of these sheets is summarised in Table 11 below.

Table 11: Summary of Cardiff pilot input data

Entity type Number of entities Number of properties

Asset sensor 29 5

Hydrants 269 24

Boundary valves 47 19

Control valves 12 16

Mains 1210 28

Meters 29 30

System valves 370 22

Following the production of the knowledge base, an RDF/XML file was produced, which included only the Abox triples, and was 2183 KB in size, representing 17355 triples. This included the 1966 named entities, and the properties shown below in Table 12.

Table 12: Summary of Cardiff pilot output knowledge base before inference

Entity type Object Properties Datatype Properties

Asset sensor atAsset, observes comment, hasUnit

Hydrants hasIpid, hasXcoord, hasYcoord

Boundary valves hasNominalDiameter, hasUnit, hasIpid, hasXcoord, hasYcoord

Control valves hasNominalDiameter, hasUnit, hasIpid, hasXcoord, hasYcoord

Mains hasMaterial, hasWaterType, hasSubtype

hasNominalDiameter, hasUnit, hasLength, isPumped, goesFromIpid, goesToIpid, hasIpid, hasAbsoluteDiameter

Meters hasSubtype, observes

hasNominalDiameter, hasUnit, hasXcoord, hasYcoord, hasMeterType, hasMeterFunction, hasAttachedPipeType, hasIpid, hasSiteRef

System valves hasNominalDiameter, hasUnit, hasIpid, hasXcoord,

WISDOM



hasYcoord

5.3.2. Tywyn and Aberdovey Pilot Model

6 CSV files were used as a basis for extracting information regarding the Tywyn and Aberdovey pilot site; these described the system valves, meters, mains, control valves, hydrants, and asset sensors. In total, these represented 572 KB of data. The number of entities and properties in each of these sheets is summarised in Table 13 below.

Table 13: Summary of Tywyn and Aberdovey pilot input data


Asset sensor 29 5

Hydrants 261 18

Control valves 46 18

Mains 1517 19

Meters 26 15

System valves 485 19


Table 14: Summary of Tywyn and Aberdovey pilot output knowledge base before inference


Asset sensor atAsset, observes comment, hasUnit

Hydrants hasIpid, hasXcoord, hasYcoord

Control valves hasNominalDiameter, hasUnit, hasIpid, hasXcoord, hasYcoord

Mains hasMaterial, hasWaterType, hasSubtype

hasNominalDiameter, hasUnit, hasLength, isPumped, goesFromIpid, goesToIpid, hasIpid, hasAbsoluteDiameter

Meters hasSubtype, observes

hasNominalDiameter, hasUnit, hasXcoord, hasYcoord, hasMeterType, hasMeterFunction, hasAttachedPipeType, hasIpid, hasSiteRef

System valves hasNominalDiameter, hasUnit, hasIpid, hasXcoord, hasYcoord

WISDOM



5.3.3. Gowerton Pilot Model

As the Gowerton pilot site only includes waste water assets, its knowledge base is significantly different to the Cardiff and Tywyn & Aberdovy sites. 5 CSV files were used as a basis for extracting information regarding the Gowerton pilot site; these described the conduits, nodes, pumps, sensors and subcatchments. In total, these represented 5.28 MB of data. The number of entities and properties in each of these sheets is summarised in Table 15 below.

Table 15: Summary of Gowerton pilot input data


Sensors 103 12

Subcatchments 1372 140

Conduits 2574 204

Nodes 2621 71

Pumps 40 186


Table 16: Summary of Gowerton pilot output knowledge base before inference


Sensors atAsset, observes, subtype

hasXcoord, hasYcoord

Subcatchments subtype has Area, hasXcoord, hasYcoord, hasPopulation

Conduits Subtype, hasMaterial, hasUpstreamNode, hasDownstreamNode

hasNominalDiameter, hasXcoord, hasYcoord, hasLength, hasPipeShape, hasWidth, hasHeight, hasBottomRoughness, hasTopRoughness, hasUpstreamInvertlevel, hasUpstreamHeadloss, hasDownstreamInvertlevel, hasDownstreamHeadloss, hasGradient, hasCapacity

Nodes Subtype, atAsset hasXcoord, hasYcoord

Pumps Subtype, WaterType, PumpComment, hasOnDelay, hasOffDelay, hasDischarge

5.3.4. Italian Pilot Model

WISDOM



The Italian Pilot site was instantiated using a Python script to extract knowledge from the hydraulic model developed of the Italian pilot site, using the RDFlib Python library previously described and the EPANETTOOLS Python library [14]. This meant that instead of the Welsh pilot method of exporting CSV files, then parsing the CSV files into Python objects, the EPANET model could be parsed directly into Python objects, and then iterated over to add statements to an RDFlib graph and the WISDOM namespace, before being serialized into an RDF file. The Italian pilot input data was split across several sections of an EPANET input file, which described the 426 entities within 42 KB of data, as detailed in Table 17.

Table 17: Summary of Italian pilot input data

Entity Number of entities Properties

Junctions 99 Elevation, demand, X-Coord, Y-Coord

Pipes 99 Node1, Node2, Length, Diameter, Roughness, Status

Pipe vertices 190 Pipe, X-Coord, Y-Coord

Pumps 19 Node1, Node2, Parameters

Reservoirs 19 Head


Table 18: Summary of Italian pilot output knowledge base before inference

Entity Number of entities Properties

Junctions 99 Elevation, demand, X-Coord, Y-Coord

Pipes 99 hasStartNode, hasEndNode , Length, Diameter, Roughness

Pipe vertices 190 Pipe, X-Coord, Y-Coord

Pumps 19 hasStartNode, hasEndNode

Reservoirs 19

WISDOM



6. INFERENCE AND RULE ENGINE

As a key benefit of the semantic web approach, semantic inference is the ability of machine reasoning over explicit knowledge to produce new, inferred knowledge. This section therefore describes the inference capabilities exploited within the WISDOM semantic web service, based on the WISDOM domain ontology (Tbox), each pilot site’s knowledge base (Abox), a semantic reasoning engine (or architecture of engines), and a set of logic rules. The first subsection introduces semantic inference further, then the reasoning components used and discussed. The main work conducted is then presented; firstly 2 main use cases for inference are proposed, and their requirements from a rule engine are stated, then the SWRL rules themselves are proposed alongside a basic demonstration of their efficacy, before presenting them within the context of the proposed use cases to highlight the WISDOM reasoning engine’s capabilities and value. Please note that any inference or rule engine references here relate to separate entities to the WP3 Rules Engine, although knowledge from each deliverable has been shared across the project partners (the aims of the T3.1 Rules Engine are to provide the capability and ICT infrastructure to respond to real-time events as they pertain to existing and new water network rules).

6.1. Semantic Inference Introduction

Inference represents a key advantage of ontological modelling; that new knowledge can be created from explicit knowledge. That is to say that beyond what is manually or automatically instantiated from a domain model, it is possible to infer new knowledge based on the existing statements made in the domain model. This relies on the ‘open world assumption’ paradigm which ontological modelling utilises. This assumes that anything which is not stated may be true, as opposed to conventional object-oriented modelling which assumes that anything which is not stated is not true. Based on this, an inference engine can utilise various methods to infer further truths from the explicitly stated truths. A simple example of this is to say that ‘all wines contain grapes’ and that ‘red wine is a type of wine’; based on this one can infer that ‘red wine must contain grapes’. This simple form of inference can be extended to a great deal of complexity, and is utilised in the WISDOM ontology module to facilitate the inference of sensing capabilities, amongst other knowledge. The previously stated form of inference is based on the axioms native to OWL and is implemented by a reasoning engine, such as the Apache Jena reasoning engine or the Pellet reasoning engine. This form of reasoning doesn’t require the use of additional SWRL rules.

Native OWL axioms can be extended by explicitly stating further rules which utilise domain knowledge and would not otherwise have been inferred, based on more complex description logic situations. An example of this would be to state that ‘if the input water type of a node is raw and its output type is potable, then the node is a clean treatment node’ and to apply that rule to a knowledge base. Such statements are facilitated in the W3C semantic web framework through their serialisation in the semantic web rule language (SWRL). This is therefore utilised to capture heuristic rules regarding domain knowledge which stakeholders use in their decision making process.

WISDOM



6.2. Semantic Inference Architecture

6.2.1. Jena Built-In Reasoner

Apache Jena natively supports 4 types of reasoner based on the architecture shown in Figure 40: transitive reasoner, RDFS rule reasoner, OWL/Lite reasoners, and generic rule reasoner [31]. These increase in inference capability from the transitive reasoner to the generic rule reasoner, although even the most capable of the Jena reasoners typically achieves less inference than the Pellet reasoner, due to Jena being RDF based and Pellet considering the entire conjunctive query [35]. For this reason the Pellet reasoner was chosen to achieve the maximum reasoning capabilities from native OWL axioms.

Figure 40: Jena inference architecture [15]

6.2.2. Pellet Inference Engine

As the Jena API integrates the Pellet inference engine [36] with little effort, and the Pellet engine is well regarded for capability and speed, the Pellet reasoning engine was chosen to exploit the maximum potential from the OWL axioms. Further, Pellet relaxes OWL-DL restrictions on the OWL-Full features, and allows the majority of SWRL built-in atoms. This means that Pellet should be able to reason over rules which include maths features and numerical comparisons, which have been included in the developed SWRL rule set. Following current testing, the Pellet engine has been deemed sufficient for the ontology and ontology web service to meet the requirements. However, in the instance of further rules being required in the future, it may be necessary to utilise the Drool Business Rule Engine, which has also been tested for reasoning over the WISDOM knowledge bases and is described subsequently.

6.3. Inference Use Case Requirements

Two inference use cases were proposed towards the elicitation of a coherent set of SWRL rules, and towards demonstrating valuable inferences. Firstly, the ability to infer sensing capabilities in the network from explicitly stated knowledge was considered and a set of rules produced to achieve this. Secondly, the ability to detect problems in the network, and then determine the network entities affected by the problem, was deemed a suitable and valuable use case for SWRL reasoning. As well as these, several ad hoc

WISDOM



rules were produced where specific cases of inference were deemed useful. The two use cases are now described in terms of the inference they require.

6.3.1. Sensing Capability Inference

The ability to infer sensing capabilities in the water catchment area based on complex configurations of assets and components was defined as the need to elicit a fuller description of the available sensing infrastructure, from the comparatively basic description available in the legacy systems. This primarily manifested at the Welsh pilot sites, and so the task was framed by the GIS data available from those sites. Figure 41 below shows the input knowledge explicitly stated about the sensors.

Figure 41: Explicitly stated knowledge regarding water meters and sensors at assets, from legacy systems

Based on this knowledge, the inference engine was required to produce a full description of the sensing capabilities in the network, by expressing the relationships between the sensing entities and the physical context which they output information regarding. The required inference is therefore illustrated in Figure 42 below, where green lines illustrate explicit knowledge, and red lines indicate knowledge which should be inferred.

WISDOM



Figure 42: Required inference for the sensing capability use case

Based on the inferred knowledge illustrated, the sensor and node become directly linked through an object property, by their URIs, as opposed to indirectly, or through one of many ID numbers. This solidifies the link between the two objects in a machine interpretable manner, allowing the connection to be easily discovered by humans and machines, as opposed to manually looking up an ID number from one sheet in another. This represents a benefit as it reduces the time taken, reduces the likelihood of human error in transferring the ID number, and reduces the likelihood of machine error in misunderstanding which ID number to look up (as objects typically have various IDs for each database they are represented in). Further, by establishing this direct link, a SPARQL query can extract knowledge about the sensor capabilities at every sensed node, by ‘following’ the paths from the node, to a sensor, to its sensing capability and sensing process, to the relevant metadata. This query across data sources is achieved trivially through SPARQL, and is a key advantage over traditional relational database systems.

6.3.2. Problem Detection and Alert Propagation

As well as the sensing capability inference described, another valuable inference use case which was deemed well suited for SWRL and OWL based inference was the ability to infer knowledge of problems in the network based on sensed data, subsequently infer the affected entities, and link these to the alert raised by the problem. This extension of the initial scope was undertaken based on industrial feedback about the potential utility of further investigation. This would serve as decision support for operations managers, by empowering them with knowledge about the cause and impact of the problem, for example this would help to identify customers affected by a network blockage and hence proactively engage with them as opposed to waiting for customers to issue a complaint. The relevant explicit network knowledge and required inferred knowledge for this use case is illustrated in Figure 43 below, where the green arrows indicate explicit knowledge, red is knowledge inferred in this use case, and orange identifies knowledge inferred from the previous use case, thus highlighting the knowledge required from inference within this

WISDOM



use case. The next section presents the rules which aimed to achieve the inference described in these two use cases, before the results are related back to the use cases described in the final section.

Figure 43: Problem detection and alert propagation inference use case requirements

6.4. SWRL Rules

Towards achieving the inference ability requirements described in the previous subsection, a number of SWRL rules were written, to be utilized by an inference engine as well as the OWL axioms present in the domain ontology to facilitate the inference of the red arrows in Figure 42 and Figure 43. As well as these rules, some further rules were written to demonstrate other capabilities of the knowledge-based approach. An SWRL rule follows the standard ‘if THIS then THAT’ approach of rule based logic, where the ‘THIS’ and ‘THAT’ portions consist of SWRL atoms. An SWRL atom is a statement of truth, such that ‘if THIS (statement is true) then THAT (statement is also true)’. The basic types of SWRL atom are shown in Table 19 below, and a full description of SWRL is available from W3C [37]. SWRL built-ins include functions for comparisons, maths, and string manipulation etc. This section now describes the rules produced for each use case, then presents them in human readable form and machine interpretable syntax.

Table 19: SWRL interpretations table, extended from W3C recommendation [37]

Atom Name Syntax Condition on Interpretation

Example

Individual type C(x) S(x) ∈ EC(C) Pipe(x)

Data type D(z) S(z) ∈ EC(D) Integer(z)

Object property

P(x,y) <S(x),S(y)> ∈ ER(P) hasMaterial(x,HPPE)

Data property Q(x,z) <S(x),L(z)> ∈ ER(Q) hasXcoord(x,123456)

WISDOM



Same as sameAs(x,y) S(x) = S(y) sameAs(Node_1,Asset_1)

Different from differentFrom(x,y) S(x) ≠ S(y) differentFrom(Sensor_1, Meter_1)

Built In builtIn(r,z1,...,zn) <S(z1),...,S(zn)> ∈ D(f) subtract(minBound, average, tolerance)


Figure 44 below labels the required rules, for identification, and the following text specifies the rules in pseudo code and SWRL syntax. Note that in several cases one rule covers several arrows, as inverse object properties can be described in OWL, so an extra SWRL rule is not needed.

Figure 44: Rules developed for sensing capability inference use case

1. nearTo

In order to allow a decision support tool to show geographically nearby information for assets and sensors,

this rule infers knowledge about nearby physical entities. This is useful where an asset contains several

nodes, and sensor data about one node may be relevant to management decisions on another of the

nodes. As locations are expressed as Eastings and Northings (x and y co-ordinates), entities were considered

nearby if their x and y coordinates were less than 3 apart, which equates to approximately 4m or less. Note

that differentFrom(?A,?B) must be stated to avoid inferring that every entity is near itself, which is

redundant. This is due to the open world assumption in OWL, whereby the two individuals found aren’t

assumed to be different from each other.

1

2

3

WISDOM



If A has co-ordinates (x,y) and B has coordinates (a,b), where x-3<a<x+3 and y-3<b<y+3, and A and B are

different objects, they are near each other.

hasXcoord(?A, ?xA) ^ hasYcoord(?A, ?yA) ^ hasXcoord(?B, ?xB) ^ hasYcoord(?B, ?yB) ^ swrlb:subtract(?xAsmall, ?xA, 3) ^ swrlb:add(?xAbig, ?xA, 3) ^ swrlb:lessThan(?xB, ?xAbig) ^ swrlb:greaterThan(?xB, ?xAsmall) ^ swrlb:subtract(?yAsmall, ?yA, 3) ^ swrlb:add(?yAbig, ?yA, 3) ^ swrlb:lessThan(?yB, ?yAbig) ^ swrlb:greaterThan(?yB, ?yAsmall) ^ differentFrom(?A, ?B) -> nearTo(?A, ?B) Node(?n) ^ Sensor(?s) ^ atAsset(?s, ?a) ^ atAsset(?n, ?a) -> nearTo(?n, ?s) ^ nearTo(?s, ?n)

2. deployedAt

As sensors are not explicitly described in terms of the node which they are deployed at, this is fundamental

knowledge which must be inferred in order to contextualise the capability of the deployed sensors.

If sensor S is at asset A, and network entity E is

Sensor(?S) ^ atAsset(?S, ?A) ^ TopologicalNetworkEntity(?E) ^ atAsset(?E, ?A) -> deployedAtEntity(?S, ?E)

3. hasSensedNetworkProperty

It is beneficial to know the sensed properties in a network, so as to aid in decisions about upgrading the

sensing infrastructure, and about confidence in the current sensing infrastructure. This rule therefore infers

whether a property is directly observed by a sensor at a given node or arc in the network.

If sensor S is deployed at entity E and observes property P, P is sensed at entity E.

deployedAtEntity(?S, ?E) ^ observes(?S, ?P) -> hasSensedNetworkProperty(?E, ?P)

4. observes

Whilst it may be explicitly stated in the knowledge base that a sensor observes a certain property, this may

not be directly stated, as the SSN modelling pattern is that a sensor has a measurement capability, which is

then for a certain property. If this is the case, it is useful to infer the direct link between the sensor and the

property, to facilitate the previous rules.

If sensor S has measurement capability MC, and MC regards property P, then S observes P.

hasMeasurementCapability(?S, ?MC) ^ forProperty(?MC, ?P) -> observes(?S, ?P)

WISDOM




1. triggeredBySensor

The knowledge explicitly stated in the knowledge base is that an alert is connected to an entity (such as a pump, pipe, or reservoir), and that a sensor exists at that entity. Further, it is stated that the sensor observes a certain property, and the alert is for a certain property. By ensuring that these statements align correctly, a relationship can be inferred between the sensor and the alert. Note that an ‘alert’ does not have to be active at any given time, such that an entity can be related to an alert without the alert having been triggered.4

If entity E has sensor S and has alert A, and all of E, S and A are regarding the same property, then sensor S triggers alert A.

hasConnectedSensor(?E,?S)^hasAlert(?E,?A)^hasSensedNetworkProperty(?E,?P)^forProperty(?A,?P)^observes(?S,?P)->triggeredBySensor(?A,?S)

2. isActive

This inference ability shows the key benefits of the knowledge based approach utilized; as the sensor descriptions, asset descriptions, alert descriptions, and dynamic data are all semantically con nected, it is possible to directly infer whether or not a sensor reading triggers an alert. One example of the knowledge based approach is that the various data sources do not have to be in the same physical or virtual location, as the semantic web is built for distributed data storage.

4 This is partly to advise decision makers that the entity is ‘being watched’, and partly to overcome the limitations of SWRL, whereby a rule cannot infer the existence of a new named individual, which means that an alert cannot be ‘created’ by a rule. This is due to the open world assumption and the monotonicity of description logic.

2

1

3

5 4

7 8

6

WISDOM



If an alert has an acceptable range, and it is triggered by a sensor, and the sensor’s latest reading falls outside of the acceptable range, the alarm is triggered. This can occur if the reading is greater than the allowable maximum, or smaller than the allowable minimum, otherwise the alarm is not active.

WaterAlert(?A) ^ hasAlertCondition(?A, ?AC1) ^ hasAcceptableRange(?AC1, ?AR) ^ hasMaxValue(?AR, ?Xmax) ^ Sensor(?S) ^ triggersAlert(?S, ?A) ^ hasLatestOutput(?S, ?TVP) ^ hasValue(?TVP, ?X) ^ swrlb:greaterThan(?X, ?Xmax) -> isActive(?A, true) WaterAlert(?A)^hasAlertCondition(?A,?AC1)^hasAcceptableRange(?AC1,?AR)^hasMinValue(?AR,?Xmin)^Sensor(?S)^triggersAlert(?S,?A)^hasLatestOutput(?S,?TVP)^hasValue(?TVP,?X)^swrlb:lessThan(?X,?Xmin)-> isActive(?A,true) WaterAlert(?A)^hasAlertCondition(?A,?AC1)^hasAcceptableRange(?AC1,?AR)^hasMinValue(?AR,?Xmin)^hasMaxValue(?AR,?Xmax)^Sensor(?S)^triggersAlert(?S,?A)^hasLatestOutput(?S,?TVP)^hasValue(?TVP,?X)^swrlb:lessThanOrEqual(?X,?Xmax)^swrlb:greaterThanOrEqual(?X,?Xmin)-> isActive(?A,false)

3. hasDownstreamEntity

In order to generalise pipes, pumps, and reservoirs etc. to determine what is upstream or downstream of an entity, it is useful to use the IPID values held in the legacy GIS database to infer knowledge about flow chronology through the entities. This allows later inference of whether an entity is affected by any given problem, and greatly simplifies those rules.

If an entity goes from an entity with IPID of i, and another entity has an IPID of i, then the latter is downstream of the former, and vice versa.

goesFromIpid(?p, ?i) ^ hasIpid(?u, ?i) -> hasUpstreamEntity(?p, ?u) ^ hasDownstreamEntity(?u, ?p)

goesToIpid(?p,?i)^hasIpid(?d, ?i) -> hasUpstreamEntity(?d, ?p) ^ hasDownstreamEntity(?p, ?d)

4. hasProblem

In the situation that an alert is active, and the alert is caused by a certain problem, it is beneficial to connect the problem entity to the problem directly, which this rule achieves.

If an entity has an active alert, and the alert is for a certain problem, the entity has that problem.

hasAlert(?E, ?A) ^ forProblem(?A, ?P) ^isActive(?A,true) -> hasProblem(?E, ?P)

5. hasAffectedEntity

Tracing the impact of a problem downstream in a water network to determine further problems which the problem could cause, and its negative consequences for customers, is both highly beneficial and challenging, due to the system complexity. Further, if a problem is reported at a downstream entity, one expert task is tracing backwards in the value chain to determine if an upstream problem could be causing it. This rule aims to empower water experts by telling them upfront if an entity is affected by any upstream

WISDOM



problems. Further, the knowledge of an entity being affected by an upstream problem could be used automatically by a further rule to infer a likely problem at that entity, and even a required action to proactively mitigate the overall impact of the initial problem. Note that ‘hasProblemEntity’ is a sub-property of ‘hasAffectedEntity’, allowing this inference to propagate to all downstream elements.

If a water alert is active, and the problem entity has a downstream entity, then that entity is affected by the alert.

WaterAlert(?A) ^ isActive(?A,true) ^ hasAffectedEntity(?A, ?E) ^ hasDownstreamEntity(?E, ?D) -> hasAffectedEntity(?A, ?D)

6. affectedByProblem

This rule continues the benefits of rule 5 by directly linking the downstream entity with the problem which it is affected by. Note that ‘hasProblem’ is a sub-property of ‘affectedByProblem’, allowing the inference to propagate to all downstream entities.

If an entity has a downstream entity and is affected by a problem, then that downstream entity is also affected by the problem.

hasDownstreamEntity(?E, ?D) ^ affectedByProblem(?E, ?P) -> affectedByProblem(?D, ?P)

7. hasSeverity

This inference ability explores the possibility of evaluating how severe a problem is, based on how far outside the acceptable range a current sensor reading is. This has been achieved is a simple manner by finding the relative distance which the reading is outside of the acceptable range. This could be explored further with more specific use cases, and more domain knowledge about the criteria for problem severity, such as the likely total future impact on the organization’s KPIs. However, the current approach shows that the knowledge-based approach allows further knowledge to be derived quite easily about the current situation, to empower decision makers without them having to do their own analysis of the data.

Firstly, in the case of the reading being greater than the maximum allowable value, severity is defined by equation 1.

if ValActual > Valmax: Severity =ValActual− ValMax

(ValMax– ValMin

2)

(1)

If a problem causes an alert and the alert has an acceptable range, and the alert is triggered by a sensor whose latest reading is above that range, the severity of the problem is calculated as per equation 1.

Problem(?P)^isCauseOfAlert(?P,?A)^WaterAlert(?A)^hasAlertCondition(?A,?AC1)^hasAcceptableRange(?AC1,?AR)^hasMinValue(?AR,?Xmin)^hasMaxValue(?AR,?Xmax)^Sensor(?S)^triggersAlert(?S,?A)^hasLatestOutput(?S,?TVP)^hasValue(?TVP,?X)^swrlb:greaterThan(?X,?Xmax)^swrlb:subtract(?x1,?Xmax,?Xmin)^swrlb:divide(?x2,?x1,2)^swrlb:subtract(?SevAbs,?X,?Xmax)^swrlb:divide(?SevRel,?SevAbs,?x2) ->hasSeverity(?P,?SevRel)

WISDOM



In parallel to the above rule, the opposite logic holds if the sensor reading is below the minimum acceptable range, where the severity is calculated as per equation 2 below.

if ValActual < Valmin: Severity =ValMin− ValActual

(ValMax– ValMin

2)

(2)

Problem(?P)îsCauseOfAlert(?P,?A)^WaterAlert(?A)^hasAlertCondition(?A,?AC1)^hasAcceptableRange(?AC1,?AR)^hasMinValue(?AR,?Xmin)^hasMaxValue(?AR,?Xmax)^Sensor(?S)^triggersAlert(?S,?A)^hasLatestOutput(?S,?TVP)^hasValue(?TVP,?X)^swrlb:lessThan(?X,?Xmin)^swrlb:subtract(?x1,?Xmax,?Xmin)^swrlb:divide(?x2,?x1,2)^swrlb:subtract(?SevAbs,?Xmin,?X)^swrlb:divide(?SevRel,?SevAbs,?x2) ->hasSeverity(?P,?SevRel)

If the sensor’s reading is within the acceptable range, then the severity of the problem is 0.

Problem(?P)îsCauseOfAlert(?P,?A)^WaterAlert(?A)^hasAlertCondition(?A,?AC1)^hasAcceptableRange(?AC1,?AR)^hasMinValue(?AR,?Xmin)^hasMaxValue(?AR,?Xmax)^Sensor(?S)^triggersAlert(?S,?A)^hasLatestOutput(?S,?TVP)^hasValue(?TVP,?X)^swrlb:lessThanOrEqual(?X,?Xmax)^swrlb:greaterThanOrEqual(?X,?Xmin)->hasSeverity(?P,0.0)

8. hasDetectionTime

Given that the knowledge base will be iteratively updated as new sensor readings are received, and alerts may not be observed immediately, it would be beneficial to inform decision makers exactly when a problem was first observed. This is achieved by noting the time at which the sensors latest reading is outside the acceptable range, but the sensor’s previous reading was inside the acceptable range.

If an alert has an acceptable range, and is triggered by a sensor, and the sensor’s latest reading is outside that range, but its previous reading was inside the range, then the detection time of the problem is the latest reading’s timestamp. This can occur when the reading is above the maximum range, or below the minimum range.

Problem(?P)îsCauseOfAlert(?P,?A)^WaterAlert(?A)^hasAlertCondition(?A,?AC1)^hasAcceptableRange(?AC1,?AR)^hasMinValue(?AR,?Xmin)^hasMaxValue(?AR,?Xmax)^Sensor(?S)^triggersAlert(?S,?A)^hasLatestOutput(?S,?TVP)^hasValue(?TVP,?X)^swrlb:greaterThan(?X,?Xmax)^hasTimestamp(?TVP,?time)^hasPreviousOutput(?S,?TVPprev)^differentFrom(?TVP,?TVPprev)^hasValue(?TVPprev,?Xprev)^swrlb:lessThanOrEqual(?Xprev,?Xmax)^swrlb:greaterThanOrEqual(?Xprev,?Xmin)->hasDetectionTime(?P,?time)

Problem(?P) ^ isCauseOfAlert(?P, ?A) ^ WaterAlert(?A) ^ hasAlertCondition(?A, ?AC1) ^ hasAcceptableRange(?AC1, ?AR) ^ hasMinValue(?AR, ?Xmin) ^ hasMaxValue(?AR, ?Xmax) ^ Sensor(?S) ^ triggersAlert(?S, ?A) ^ hasLatestOutput(?S, ?TVP) ^ hasValue(?TVP, ?X) ^ swrlb:lessThan(?X, ?Xmin) ^ hasTimestamp(?TVP, ?time) ^ hasPreviousOutput(?S, ?TVPprev) ^ differentFrom(?TVP, ?TVPprev) ^ hasValue(?TVPprev, ?Xprev) ^ swrlb:lessThanOrEqual(?Xprev, ?Xmax) ^ swrlb:greaterThanOrEqual(?Xprev, ?Xmin) -> hasDetectionTime(?P, ?time)

9. hasWaterAlert, affectedByAlert

WISDOM



Whilst not directly required for this use case, it is also useful to directly relate alerts to assets where appropriate, given that water experts typically conceptualise the network in terms of its main assets as opposed to the individual nodes.

If an entity has an alert, or is affected by an alert, and is at an asset, then the same can be said of the asset.

hasWaterAlert(?e, ?A) ^ atAsset(?n, ?e) -> hasWaterAlert(?n, ?A) affectedByAlert(?e, ?A) ^ atAsset(?n, ?e) -> affectedByAlert(?n, ?A)

6.4.3. Ad-hoc Rules

Whilst not directly required for the primary use cases explored, several applications of inference were explored which were deemed valuable and could be expanded into full use cases. These are now described in turn.

1. hasLossFlowRate

If the flow rate at the start and end of a pipe is know, or the total flow rate into and out of a node is known,

then the total water loss from the entity can be calculated. To be particularly useful, this would require that

the flow rates through the network are estimated through simulation software, or an extensive sensing

infrastructure is installed. This inferred knowledge could be used to trigger alerts regarding unusual water

leakage, or to help identify key leaky pipes, and possible locations at which water is being consumed

without being accounted for.

If flow rate at end of pipe < start of pipe, leakage = start flow rate – end flow rate

hasEndFlowRate(?p, ?ef) ^ hasStartFlowRate(?p, ?sf) ^ swrlb:lessThan(?ef, ?sf) ^

swrlb:subtract(?lf, ?sf, ?ef) -> hasLossFlowRate(?p, ?lf)

2. hasAverageFlowVelocity, hasAverageFlowRate

This rule applies a basic hydraulic equation for full pipe flow, whereby if the velocity or flow rate is known, and the pipe area is known, then the other property (of velocity or flow rate) can be calculated. The complexity of the SWRL rules required to accomplish this simple equation highlight that the current SWRL built in functions are not well suited to applying mathematical formulae to graph databases. Arguably then, this clarifies that whilst the knowledge based approach has strengths at knowledge inference, mathematical and physical modelling is better handled by traditional methods.

If closed channel flow pipe p has flow rate f and area AAA, it has average velocity f/(pi*d*d/4)

FullPipeFlow(?flowtype) ^ hasFlowType(?p, ?flowtype) ^ hasAverageFlowRate(?p, ?avFlowRate) ^

hasNominalDiameter(?p, ?D) ^ swrlb:divide(?A, ?D, 4) ^ swrlb:multiply(?AA, ?D, ?A) ^

swrlb:multiply(?AAA, 3.14, ?AA) ^ swrlb:divide(?V, ?avFlowRate, ?AAA) ->

hasAverageFlowVelocity(?p, ?V)

WISDOM



If closed channel flow pipe p has velocity v and area AAA, it has flow rate v *(pi*r*r)

FullPipeFlow(?flowtype) ^ hasFlowType(?p, ?flowtype) ^ hasAverageFlowVelocity(?p, ?V) ^

hasNominalDiameter(?p, ?D) ^ swrlb:divide(?A, ?D, 4) ^ swrlb:multiply(?AA, ?D, ?A) ^

swrlb:multiply(?AAA, 3.14, ?AA) ^ swrlb:multiply(?F, ?V, ?AAA) -> hasAverageFlowRate(?p, ?V)

3. hasHighPressureFlag

As well as the ability to trigger alarms through SWRL rules, it is also useful to trigger non-problematic

state variables based on network knowledge. An example of this is that some types of pipe are subject

to different regulations if their pressure is higher than a certain amount. This rule therefore raises a

‘hasHighPressure’ flag if the pressure is high. This could be explored further by making ‘HighPressure’

a named individual, and modelling states as classes, as this would allow further inference of the

entity’s behavior based on a detailed description of its current state, and also automated state -

specific regulation checking.

If pipe AAA has pressure > 20 bar then pipe AAA has a high pressure flag

hasPressure(?p, ?press) ^ hasPressureLimit(?p, ?lim) ^ DUL:hasDataValue(?lim, ?limVal) ^

swrlb:greaterThan(?press, ?limVal) -> hasHighPressure(?p, true)

4. isCurrentlyPumping

One conceptually simple inference which was suggested as valuable by industrial partners would be the

ability to determine whether a pump is currently active or not, and subsequently know all the pumps which

are currently active in the network. The former aspect is achieved the following rule, and the latter could be

achieved by a simple SPARQL query.

If pump AAA has energy consumption > 0 then pump is active

PumpNode(?p) ^ hasCurrentEnergyConsumption(?p, ?e) ^ swrlb:greaterThan(?e, 0) ->

isCurrentlyPumping(?p, true)

6.5. Inference Use Case Testing

The rules were tested individually during development to ensure they were able to infer the desired knowledge from the desired explicit knowledge, and to ensure that obvious similar situations didn’t invoke false positive inferences, which the presented rule set consistently passed. However, use case based testing of the rules in unison is a far more reliable test of the performance of the inference engine, as this is far more likely to produce false positives due to increased complexity in the explicit knowledge, and the scenario is far closer to the likely real situation. This section therefore presents the use case based testing of

WISDOM



the rules, by illustrating the explicit knowledge in an example instance of each use case, then presenting the inferred knowledge, followed by discussion of the time taken, the robustness of the test, and the value of the inference achieved.

The rules were tested on a middle range laptop, a Samsung 900X, with an Intel i5 1.7GHz processor and 8GB of memory, on 64-bit Windows 7. The rules were tested in the Protégé software; given the computer specification and the testing environment it is expected that performance would be better within a dedicated high performance server or a cloud computing environment. The rules were tested on an instance of the domain ontology, such that the entire domain ontology was reasoned over, as well as the individuals specifically relevant to the use case. The input and output Aboxes sizes were determined directly through the RDFlib Python library by command line.

The rules were tested in Protégé using the Drools Rule Engine [38], which is a comprehensive, powerful, hybrid reasoning system. This was used as Pellet was observed to miss inferences in the Protégé environment which it then achieved in a standalone server deployment, whereas Drools performed well within Protégé. However, Drools is less simple to integrate with Jena, and takes longer to perform a full inference cycle than Pellet, so it is expected that Pellet will be used in production.


This use case aims to replicate a likely situation by which the knowledge explicitly contained within the utility network data when federated to the candidate ontology is used to infer more useful knowledge, specifically regarding the context of the deployed sensors. This use case was tested by instantiating a level meter and reservoir, and testing whether the desired knowledge could be inferred. Figure 45 below illustrates the tested instance of the use case, whereby a reservoir asset with a level meter deployed can trigger several rules to be fired and hence increase the useful knowledge between the relevant named individuals. Note that the reservoir is both an asset and a node, highlighting the difference between description logic and object oriented programming, in that the instance Reservoir_01 can have multiple types, which accurately reflects the expert domain perspective.

WISDOM



Figure 45: Sensing capability inference test case instance

As shown in Figure 45, it was desired that the nearTo rule would infer a connection between the objects despite their locations not being equal; this is a likely situation given that the reservoir’s location would be measured at its centre, but the sensor may be installed at the edge of the reservoir. It was also desired that the deployedAt connection was made between the level meter and the reservoir, as the topological representation of the network as connected nodes and arcs is primarily used for subsequent inference, rather than the reservoir’s physical manifestation as an asset. This is because whilst some assets are nodes, most nodes are not assets as per the legacy schema, and some assets have multiple nodes. This could be further explored with the concept of a ‘super node’ which represents a cluster of nodes at an asset, to include a ‘level of detail’ approach similar to that used by CitGML [39].

The test case described consisted of 18 Abox triples within the 2622 total triples, which includes the domain ontology proposed. This input Abox is shown below:

WISDOM





<owl:NamedIndividual rdf:about="http://www.WISDOM.org/WISDOMontology#LevelMeter_01">

<rdf:type rdf:resource="http://www.WISDOM.org/WISDOMontology#LevelSensor"/>

<ssn:observes rdf:resource="http://www.WISDOM.org/WISDOMontology#WaterLevel"/>

<atAsset rdf:resource="http://www.WISDOM.org/WISDOMontology#Reservoir_01"/>

<hasXcoord rdf:datatype="http://www.w3.org/2001/XMLSchema#int">200001</hasXcoord>

<hasYcoord rdf:datatype="http://www.w3.org/2001/XMLSchema#int">100001</hasYcoord>

</owl:NamedIndividual>



<owl:NamedIndividual rdf:about="http://www.WISDOM.org/WISDOMontology#Reservoir_01">

<rdf:type rdf:resource="http://www.WISDOM.org/WISDOMontology#StorageNode"/>

<atAsset rdf:resource="http://www.WISDOM.org/WISDOMontology#Reservoir_01"/>

<hasXcoord rdf:datatype="http://www.w3.org/2001/XMLSchema#int">200000</hasXcoord>

<hasYcoord rdf:datatype="http://www.w3.org/2001/XMLSchema#int">100000</hasYcoord>




<owl:NamedIndividual rdf:about="http://www.WISDOM.org/WISDOMontology#WaterLevel">

<rdf:type rdf:resource="http://www.WISDOM.org/WISDOMontology#WaterNetworkProperty"/>


Following the application of the inference engine, the Abox contained 181 triples in total, meaning 163 triples were inferred in the Abox, within 6883 total inferred axioms. The test took 1369 ms on the first instance (without caching), and the duration reduced to 358 ms after 5 iterations. The output knowledge regarding the level meter and reservoir is shown in Figure 46. The inferred knowledge satisfies the requirements of this use case.

Figure 46: Resultant explicit and inferred Abox knowledge from sensor capability inference testing

WISDOM




Following the testing of the first use case, and the scope extension to include problem and alert concepts based on industry feedback, the second use case was tested in a similar manner. Firstly, an instance of the use case was defined, whereby a reservoir node is connected formally to a level sensor, and has a tree of downstream nodes and arcs. It was considered that the sensor’s latest reading indicated that the reservoir’s water level was too low, and the ability of the inference engine to provide decision support was tested. The described test case is illustrated in Figure 47, which also shows the named individuals for the alert, and acceptable range and latest output.

Figure 47: Problem and alert inference test case illustration

The proposed test case was then instantiated in RDF, whereby the knowledge inferred in the previous use case was stated explicitly, so as to test this use case in isolation. This produced 56 Abox triples, an excerpt of which is shown below.

WISDOM



<owl:NamedIndividual rdf:about="http://www.WISDOM.org/WISDOMontology#AcceptableRange">

<hasMaxValue rdf:datatype="http://www.w3.org/2001/XMLSchema#double">6.0</hasMaxValue>

<hasMinValue rdf:datatype="http://www.w3.org/2001/XMLSchema#double">3.0</hasMinValue>


<owl:NamedIndividual rdf:about="http://www.WISDOM.org/WISDOMontology#LatestOutput">

<rdf:type rdf:resource="http://purl.oclc.org/NET/ssnx/ssn#SensorOutput"/>

<hasTimestamp rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">20160412135411</hasTimestamp>

<DUL:hasDataValue rdf:datatype="http://www.w3.org/2001/XMLSchema#double">2.0</DUL:hasDataValue>


<owl:NamedIndividual rdf:about="http://www.WISDOM.org/WISDOMontology#LevelAlert">

<rdf:type rdf:resource="http://www.WISDOM.org/WISDOMontology#WaterAlert"/>

<forProblem rdf:resource="http://www.WISDOM.org/WISDOMontology#LowLevelProblem"/>

<forProperty rdf:resource="http://www.WISDOM.org/WISDOMontology#ReservoirLevelProperty"/>

<hasAlertCondition rdf:resource="http://www.WISDOM.org/WISDOMontology#LevelAlertCondition"/>


<owl:NamedIndividual rdf:about="http://www.WISDOM.org/WISDOMontology#LevelAlertCondition">

<hasAcceptableRange rdf:resource="http://www.WISDOM.org/WISDOMontology#AcceptableRange"/>


<owl:NamedIndividual rdf:about="http://www.WISDOM.org/WISDOMontology#LevelSensor">

<rdf:type rdf:resource="http://www.WISDOM.org/WISDOMontology#LevelSensor"/>

<ssn:observes rdf:resource="http://www.WISDOM.org/WISDOMontology#ReservoirLevelProperty"/>

<hasLatestOutput rdf:resource="http://www.WISDOM.org/WISDOMontology#LatestOutput"/>


<owl:NamedIndividual rdf:about="http://www.WISDOM.org/WISDOMontology#LowLevelProblem">

<rdf:type rdf:resource="http://www.WISDOM.org/WISDOMontology#Problem"/>


<owl:NamedIndividual rdf:about="http://www.WISDOM.org/WISDOMontology#Node_11">

<goesFromIpid rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">1</goesFromIpid>

<hasIpid rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">2</hasIpid>


<owl:NamedIndividual rdf:about="http://www.WISDOM.org/WISDOMontology#Reservoir_01">

<hasAlert rdf:resource="http://www.WISDOM.org/WISDOMontology#LevelAlert"/>

<hasIpid rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">1</hasIpid>


This RDF data instantiated the use case proposed earlier in Figure 43, such that the explicit knowledge and required inference ability is illustrated below in Figure 48.

WISDOM



Figure 48: Instance of problem and alert inference requirements for test case

Figure 48 displays the required inference ability, based on the OWL axioms in the domain model, and the SWRL rules embedded in the inference engine. The main desired outcomes of this inference are the triggering of the alert, the link between a problem and downstream entities, and knowledge about the time and severity of the problem. Following the application of the inference engine, the Abox contained 972 triples, meaning that 916 triples had been inferred, of 7185 total inferred axioms. This inference occurred in 1427 ms on the first instance (without caching), which reduced to circa 450 ms after caching. The desired knowledge primarily centres on the problem and downstream entity named individuals, so Figure 49 displays the Abox knowledge at these entities following the inference. This shows that the node is linked to its upstream and downstream entities, is affected by the active alert, and is affected by the low level problem. Figure 49 also shows that the problem individual is linked to all the downstream nodes, and its severity and timestamp have been inferred.

WISDOM



Based on the inference achieved through the application of the inference engine to the test case, Figure 50 below highlights some of the key inferred knowledge. Specifically, this shows that knowledge about the reservoir problem can be inferred, and this can be linked directly to downstream entities. By integrating system knowledge in this manner, little work would be required to automatically infer required actions due to the impact of the problem on customers, as shown at the right hand side of Figure 50. The knowledge-based system approach therefore allows the impact of problems to be comprehensively checked, a task which is otherwise prohibited by the time taken, due to the complexity of the system. The inference ability demonstrated is a significant first step towards an integrated knowledge-based approach, and serves as proof of concept that the approach allows decision makers to be better informed in managing the water network.

Figure 49: Excerpt of resultant Abox knowledge after problem and alert inference testing

WISDOM



Figure 50: Key knowledge inferred and extendable through the alert and problem inference testing

Whilst further research around the potential of this knowledge-based approach is outside the scope of this deliverable, some key avenues are suggested:

The knowledge of an entity being affected by an upstream problem could be used automatically by a further rule to infer a likely problem at the downstream entity, and even a required action to proactively mitigate the overall impact of the initial problem.

If an entity is affected by an upstream problem, but has another upstream entity, then the former entity is only partially affected by the upstream problem. This could be explored further for the case of two upstream entities, both with different problems, or to infer more specific knowledge about how badly affected an entity is by an upstream problem, based on the relative flow rate it derives from the problematic upstream entity.

The inference could also be extended with provenance knowledge: by determining if a sensor often malfunctions, or has ‘drifted’ and needs recalibrating, it would be possible to assign a reliability metric to a sensor observation and subsequently infer the likelihood of a false positive when triggering an alert, which would further inform decision makers.

A closer coupling of the knowledge base with simulation software, and an ontological representation of the organisations’ KPIs, could provide powerful decision support. Further coupling of this with social entities could then be used to infer the person or organisation suggested to enact the proposed actions.

WISDOM



7. CONCLUSION

This document has presented the outcomes of the semantic modelling activities of Task 2.2 of the WISDOM project. Following a scoping, requirements, and methodology section, this deliverable has focused on the domain ontology developed and has discussed in detail both the modelling choices made and their implementation towards an OWL ontology. Further, the instantiation of the ontology into pilot site knowledge bases was presented and discussed as a reproducible method, representing a secondary output of the task. Finally, the inference engine was discussed in detail to demonstrate the knowledge-based approach and to indicate the value of the semantic approach. A discussion was also made in the introduction, and throughout, regarding the role of semantics in the field and the contribution of the proposed domain ontology to that field.

The methodology used to develop the ontology followed the guidance of the NeOn methodology through the reuse of ontological resources and an iterative and collaborative process to ensure a genuinely shared conceptualisation of the domain was produced which met both the scope of the ontology and the performance requirements of the ontology web service, whilst encouraging future reuse and extension. The stages of this process were outlined as well as their links through information entities, and their sub-processes. The use of a domain-independent meta-model to facilitate reuse and cross-domain knowledge integration through significant abstraction was justified and presented. The ongoing multi-stage validation process was discussed, including the use of a novel semi-automated web-based term extraction method.

The main output presented was the domain ontology, which was divided into 3 groups of concepts: a Water Catchment Information Model (WCIM), a Water Semantic Sensor Network Ontology (WSSN) and a Water Value Chain Social Model (WVCSM). These respectively formalised a description of the physical, sensory and social entities. The WCIM extended the meta-model’s concepts of nodes and arcs within a network to the domain of water management, including node types such as storage nodes and pumping nodes, as well as the manifestation of these concepts as assets such as service reservoirs and pumping stations. This model further contextualised these within the water value chain processes such as abstraction, treatment and discharge, modelled natural artefacts such as rivers and included other relevant concepts such as hydrants, water types, consumer building types and domestic water artefacts. The WSSN ontology reused the W3C SSN ontology to the water management domain by developing a taxonomy of relevant sensors, water properties, sensing processes, sensed phenomena and units. Furthermore, the WSSN was integrated with the WCIM by relating sensors to specific physical entities and assets, and integrating a new concept of a time series data store in order to link real time data to both sensors and physical entities. The WVCSM then modelled a generic taxonomy of potential actors in the water value chain, including both water companies, consumers and governing bodies, and a further level of detail through the potential to model specific people, where necessary for the ontology’s role. This model also formalised a description of the various permutations of relationships in the domain, both on the supply side and domestic consumer side; arguing and presenting the need to model social relationships as concepts themselves to fully capture their semantics. Object and data properties were presented throughout these models to fully describe the entities represented. Finally the representation of the domain as a socio-technical system was presented through the links between the WVCSM and the WCIM; relationships such as control, appliance consumption patterns and regulatory obligations linked the physical and social networks to fully contextualise data and enrich the water network descriptions.

WISDOM



8. REFERENCES

[1] A. W. McMorran, “An Introduction to IEC 61970-301 and 61968-11: The Common Information Model,” University of Strathclyde, 2007.

[2] BuildingSmart, “IFC4 Add1 Release.” [Online]. Available: http://www.buildingsmart-tech.org/specifications/ifc-releases/ifc4-add1-release. [Accessed: 18-Jan-2016].

[3] eeBUS, “About us,” 2012. [Online]. Available: https://www.eebus.org/en/about-us/. [Accessed: 01-Jun-2016].

[4] Project Haystack, “Home – Project Haystack.” [Online]. Available: http://project-haystack.org/. [Accessed: 01-Jun-2016].

[5] “Industrial Internet Reference Architecture | Industrial Internet Consortium.” [Online]. Available: http://www.iiconsortium.org/IIRA.htm. [Accessed: 01-Jun-2016].

[6] “OPEN CONNECTIVITY FOUNDATION (OCF).” [Online]. Available: http://openconnectivity.org/. [Accessed: 01-Jun-2016].

[7] “Hypercat - Home.” [Online]. Available: http://www.hypercat.io/. [Accessed: 01-Jun-2016].

[8] H. van der Veer and A. Wiles, “Achieving technical interoperability,” Eur. Telecommun. Stand. Inst., 2008.

[9] W. Wang, A. Tolk, and W. Wang, “The levels of conceptual interoperability model: applying systems engineering principles to M&S,” in Proceedings of the 2009 Spring Simulation Multiconference, 2009, p. 168.

[10] J. A. Muguira and A. Tolk, “Applying a methodology to identify structural variances in interoperations,” J. Def. Model. Simul. Appl. Methodol. Technol., vol. 3, no. 2, pp. 77–93, 2006.

[11] “NeOn Wiki.” [Online]. Available: http://neon-toolkit.org/wiki/Main_Page. [Accessed: 10-Apr-2015].

[12] M. Compton, P. Barnaghi, L. Bermudez, R. García-Castro, O. Corcho, S. Cox, J. Graybeal, M. Hauswirth, C. Henson, A. Herzog, V. Huang, K. Janowicz, W. D. Kelsey, D. Le Phuoc, L. Lefort, M. Leggieri, H. Neuhaus, A. Nikolov, K. Page, A. Passant, A. Sheth, and K. Taylor, “The SSN ontology of the W3C semantic sensor network incubator group,” Web Semant. Sci. Serv. Agents World Wide Web, vol. 17, pp. 25–32, Dec. 2012.

[13] “CTRL+SWAN - Cloud Technologies & ReaL time monitoring + Smart WAter Network (AG126) | EIP Water.” [Online]. Available: http://www.eip-water.eu/CTRL_SWAN. [Accessed: 18-Feb-2016].

[14] SWAN, “What are smart water networks.” .

[15] EIP Water, “AugMent - Water Monitoring for Decision Support (AG124) | EIP Water.” [Online]. Available: http://www.eip-water.eu/AugMent. [Accessed: 18-Feb-2016].

[16] IEEE Standards Committee, P. IEEE Standards Coordinating Committee 21 on Fuel Cells Dispersed Generation and Energy Storage, Institute of Electrical and Electronics Engineers, and IEEE-SA Standards Board, IEEE guide for smart grid interoperability of energy technology and information technology operation with the electric power system (EPS), end-use applications and loads. New York, N.Y.: Institute of Electrical and Electronics Engineers, 2011.

WISDOM



[17] ICT4Water, “ICT4Water standards report.” 2015.

[18] BSI, “PAS180.pdf.” .

[19] BSI, “Smart city concept model- guide to establishing a model for data interoperability.” 2014.

[20] WatERP, “D1.3 Generic ontology for water supply distribution chain.” 2013.

[21] Laurie Reynolds, “SWIM – a semantic ontology for interoperability.” 2014.

[22] CUAHSI, “CUAHSI Hydrologic Information System - Hydrologic Ontology for Discovery.” [Online]. Available: http://his.cuahsi.org/ontologyfiles.html. [Accessed: 23-Oct-2015].

[23] SWEET, “SWEET Overview.” [Online]. Available: https://sweet.jpl.nasa.gov/. [Accessed: 23-Oct-2015].

[24] Vilches-Blázquez, L. M., Ramos, J. A., López-Pellicer, F. J., Corcho, O., and Nogueras-Iso, J., “hydrOntology: a global ontology of the hydrographical domain,” 2009. [Online]. Available: http://mayor2.dia.fi.upm.es/oeg-upm/index.php/en/ontologies/107-hydrontology. [Accessed: 23-Oct-2015].

[25] INSPIRE Thematic Working Group Utility and Government Services, “D2.8.III.6 Data Specification on Utility and Government Services – Technical Guidelines,” European Commission Joint Research Centre, Dec. 2013.

[26] “IDEF – Integrated DEFinition Methods (IDEF).” [Online]. Available: http://www.idef.com/. [Accessed: 01-Jun-2016].

[27] K. H. van Dam, Capturing socio-technical systems with agent-based modelling. Delft: Next Generation Infrastructures Foundation, 2009.

[28] “The Suggested Upper Merged Ontology (SUMO) - Ontology Portal.” [Online]. Available: http://www.adampease.org/OP/. [Accessed: 27-Oct-2015].

[29] USEPA, “EPANET | Water Research | US EPA.” [Online]. Available: https://www.epa.gov/water-research/epanet. [Accessed: 19-May-2016].

[30] RDFlib, “GitHub - RDFLib/rdflib: RDFLib is a Python library for working with RDF, a simple yet powerful language for representing information.” [Online]. Available: https://github.com/RDFLib/rdflib. [Accessed: 19-May-2016].

[31] “Apache Jena - Jena Ontology API.” [Online]. Available: https://jena.apache.org/documentation/ontology/. [Accessed: 24-Feb-2015].

[32] “protégé.” [Online]. Available: http://protege.stanford.edu/. [Accessed: 01-Jun-2016].

[33] J. Euzenat and P. Shvaiko, Ontology Matching. Berlin, Heidelberg: Springer Berlin Heidelberg, 2013.

[34] W3C, “OWL Web Ontology Language Guide.” [Online]. Available: https://www.w3.org/TR/owl-guide/. [Accessed: 21-May-2016].

[35] Complexible, “FAQ · Complexible/pellet Wiki · GitHub.” [Online]. Available: https://github.com/Complexible/pellet/wiki/FAQ#different-results. [Accessed: 19-May-2016].

WISDOM



[36] Complexible, “GitHub - Complexible/pellet: Pellet is an OWL 2 reasoner in Java; open source (AGPL) and commercially licensed, commercial support available.” [Online]. Available: https://github.com/Complexible/pellet. [Accessed: 19-May-2016].

[37] “SWRL: A Semantic Web Rule Language Combining OWL and RuleML.” [Online]. Available: https://www.w3.org/Submission/SWRL/. [Accessed: 18-Jan-2016].

[38] Drools, “Drools - Drools - Business Rules Management System (JavaTM, Open Source).” [Online]. Available: http://www.drools.org/. [Accessed: 19-May-2016].

[39] G. Gröger and L. Plümer, “CityGML – Interoperable semantic 3D city models,” ISPRS J. Photogramm. Remote Sens., vol. 71, pp. 12–33, Jul. 2012.

WISDOM



APPENDIX A - SCOPING AND COMPETENCY QUESTIONS

These tables are intended to be used as a whole, meaning that for any given scenario there may be relevant questions in previous tables; this reduces duplication by only including new requirements per scenario.

Scenario 1 – Behaviour & Feedback

Entity Example properties Potential Question Typical Answer

In-house display

Mobile application

Domestic consumer Current/recent total water consumption of person

Current/recent electricity consumption of person’s water devices

Current rank in neighbourhood for total water consumption

Current consumption relative to personal trends

Recent impact on water value chain

Predicted upcoming water bill cost

Predicted change in water bill from previous/average

Person’s stated neighbourhood

Person’s stated friends

How much water is person X currently consuming?

Person X is currently consuming 5l/s

What is person X’s water consumption rank within their friends?

Person X is currently ranked 3rd within their friends

How does person X’s consumption this week compare to last week?

Person X has consumed 10% less water so far this week.

What is person X’s predicted upcoming water bill cost?

Person X’s upcoming water bill is predicted to be £150.

How many registered people are in person X’s neighbourhood?

There are 12 people registered in person X’s neighbourhood.

Water using appliance Current consumption

Consumption for recent period

How much water does appliance X consume per use, on average?

Appliance X consumes 30l per use, on average.

Water value chain Overall current performance metric

How well is the water network operating currently?

Currently, 98% of the network is operating as planned.

WISDOM



DMA Local performance metric

Residence Current/recent performance indicator

Current/recent water consumption

Water billing tariff Tariff type (flat/peak/dynamic)

Flat: cost per unit

Peak: cost per peak/off-peak unit, peak time range

Dynamic: current cost per unit

Scenario 2 – Network Monitoring


Pipe Material

Length

Diamter (nominal/absolute)

From ID

To ID

Water type

What is pipe X’s water type?

What pipes does water from pipe X flow to before consumption at property A?

What is the current water pressure in pipe X?

Pipe X contains raw water.

Pipe X feeds into pipes Y and Z before reaching property A.

The water in pipe X is currently pressurised to a 1m head.

Water value chain

Physical water network Total unaccounted for water losses

How much water is currently being lost from the network which is unaccounted for?

80 m^3/s are currently being lost from the water network.

Pump ID

From pipe ID

To pipe ID

Current/recent energy

What pipes do pump X pump water to?

How much energy is pump X currently

Pump X supplies pipes A, B and C before reaching a DMA boundary.

Pump X is currently

WISDOM



consumption

Maximum pressure head

Maximum discharge

consuming? consuming 0W.

Reservoir ID

Max storage volume

Current water volume

From ipid

To ipid

Footprint

How much water is currently in reservoir X?

What water type is in reservoir X?

Reservoir X currently holds 10000m^3 of water

Reservoir X holds potable water

Chamber Volume

Cover depth

Water type

From ipid

To ipid

Fitting X,y,z coords

Sensor Location ID

Sensor variable

What is sensor X’s current reading?

Sensor X is currently reporting 10m^3/s.

Valve Location ID

Current openness

Time to action change

How open is valve X?

How long does it take to close valve X?

Valve X is open 25%

It takes on average 3 hours to change the state of valve X.

Scenario 3 – Household leakage


House Attached meter

Current leakage prediction

What water meter is attached to house X?

How much water is estimated to be leaking from house X?

Water meter M1234 is attached to house X

Currently, 0l/s of water is leaving house X through leakage.

Scenario 4 – Waste Predictive

WISDOM




Sewer Currently spilling (binary)

Maximum level

Current level

Current inflow

Current outflow

From ipid

To ipid

Which pipes feed into sewer X?

Is sewer X likely to overflow imminently?

Sewer X is fed by pipes A,B and C.

Sewer X is 90% full and is currently filling at 2% per hour.

Scenario 5 – Advanced Devices


Device Device type

Location ID

Initial investment

Annual maintenance costs

Device lifetime

Financial return per year

Water use reduction

Energy use reduction

Where in the physical network is the device situated?

What is the device’s ROI?

How much water does the device save per year?

How much energy does the device directly save per year?

The device is attached to pipe X.

The device pays for itself after 20 years.

The device saves 1000l per year.

The device saves 100kWh per year

Greywater heat recovery unit

Recent daily flow through device.

Energy recovered in past week.

How much energy has unit X recovered in the past week?

Unit X has recovered 1mWh in the past week.

Energy efficient water using device

Water consumption of device.

Energy consumption of device.

Typical energy

How much energy has device X saved in the past week?

Device X has saved 2 mWh in the past week.

WISDOM



consumption of common alternative.

Kinetic energy device Recent flow through device.

Energy recovered in past week.

How much energy has device X recovered in the past week?

Device X has recovered 1 kWh in the past week.

Intelligent valve Current openness %

Control method

How open is valve X? Valve X is open 50%

Rainwater harvesting device

Current volume of water stored.

Current inflow.

Recent amount harvested.

How much water is currently stored in device X?

Device X is currently holding 80l water.

Water efficient water using device

Water consumption of device.

Typical water consumption of common alternative.

How much water has device X saved in the past week?

Device X has save 4l in the past week.

Scenario 6 – Pumping Optimisation

No new competency questions

Scenario 7 – Network leakage


Pipe Estimated current leakage

How much water is currently leaving pipe X through leakage?

Pipe X is currently leaking 2l/s.

Scenario 8 – Peak Reduction


WISDOM



Customer Past week peak water consumption

Weekly peak water consumption metric

Peak water consumption metric ranking amongst friends

Recent peak water consumption trend

What was person X’s peak water consumption in the past week?

What is person X’s current peak consumption score based on the past week?

Person X’s peak consumption in the past week was 100l/m

Person X’s current peak consumption score is 8/10

Physical water network Past week peak water consumption

What was the peak consumption on the network in the past week?

The highest consumption in the past week was 1000000l/m

Scenario 9 - Energy Predictive


Device Current energy consumption

Recent energy consumption

What is the current energy consumption of device X?

The current consumption is 10W

Scenario 10 – Supply Predictive

No new competency questions.

Scenario 11 – Reservoir Optimisation

No new competency questions.

Scenario 12 - Crowdsourcing


WISDOM



Consumer Ongoing issues reported

Reliability metric

What issues has person X reported recently?

Person X reported issues A,B and C.

Ongoing issue Affected entities

Report date

Severity

Affected persons

Resolution ETA

When is issue X expected to be resolved by?

Issue X should be resolved by 23/10/15.

WISDOM



APPENDIX B - FULL OBJECT PROPERTY LIST

water analytics and intelligent sensing for demand...

Documents