SAREF4WATR ontology and semantics

Introduction and overview

The present document is a technical specification of SAREF4WATR, an OWL-DL ontology that extends SAREF for the Water domain.

SAREF4WATR V2.1.1 is a major revision of SAREF4WATR, using updated reference ontology patterns specified in ETSI TS 103 548 [3] to solve the harmonization needs identified in ETSI TR 103 781 [i.9], with updated development framework and tools defined in ETSI TS 103 673 [i.10].

This extension has been created by investigating resources from potential stakeholders of the ontology, such as standardization initiatives, associations, European projects, EC directives, existing ontologies, and data repositories, as reported in ETSI TR 103 547 [i.1]. In addition, the use cases defined in [i.1] were also taken into account, namely:

• Use case 1: Remote reading of metrological registers
• Use case 2: Advanced meter reading and configuration
• Use case 3: Risk management over water critical infrastructure
• Use case 4: Interaction of cross-domain variables and models for policy-making

Taking into account ontologies, data models, standards and datasets provided by the identified stakeholders, a set of requirements were identified and grouped in the following categories: Water infrastructure, Water meter, Meter observations, Infrastructure observations, Water observations, Indicators, and Tariff. Such requirements and categories were validated during the "SAREF4WATR Validation Workshop" at the ICT4Water Cluster annual event in Brussels on 11^th June 2019. During the workshop, attendees validated the use cases proposed above and the list of requirements for the above-mentioned categories. According to the feedback and outcomes of the workshop, some actions were taken such as to better define the geolocation of meters or to allow connecting information from the water domain to other domains. The concrete decisions were reported in ETSI TR 103 547 [i.1]. The requirements listed in ETSI TR 103 547 [i.1] were taken as input for the ontology development.

SAREF4WATR is an OWL-DL ontology that extends SAREF and reuses six other ontologies. SAREF4WATR includes 54 classes (40 defined in SAREF4WATR and 14 reused from the SAREF, SAREF4CITY, SAREF4SYST, time, geo, and sf), 34 object properties (8 defined in SAREF4WATR and 26 reused from SAREF, SAREF4CITY, SAREF4SYST, and geo), 19 data type properties (12 defined in SAREF4WATR and 7 reused from SAREF and SAREF4CITY), and 65 individuals.

SAREF4WATR focuses on extending SAREF in order to create a common core of general concepts for water data oriented to the IoT field. The main idea is to identify the core components, as mentioned, that could be extended for particular water subdomains, for example, for water supply.

The prefixes and namespaces used in SAREF4WATR and in the present document are listed in Table 1.

SAREF4WATR

General Overview

An overview of the SAREF4WATR ontology is provided in Figures 1 and 2. For all the entities described in the present document, it is indicated whether they are defined in the SAREF4WATR extension or elsewhere by the prefix included before their identifier, i.e. if the element is defined in SAREF4WATR, the prefix is s4watr, while if the element is reused from another ontology it is indicated by a prefix according to Table 1.

Arrows are used to represent properties between classes and to represent some RDF, RDF-S and OWL constructs, more precisely:

• Plain arrows with white triangles represent the rdfs:subClassOf relation between two classes. The origin of the arrow is the class to be declared as subclass of the class at the destination of the arrow.
• Dashed arrows between two classes indicate a local restriction in the origin class, i.e. that the object property can be instantiated between the classes in the origin and the destination of the arrow. The identifier of the object property is indicated within the arrow.
• Dashed arrows with no identifier are used to represent the rdf:type relation, indicating that the element in the origin of the arrow is an instance of the class in the destination of the arrow.

Datatype properties are denoted by rectangles attached to the classes, in an UML-oriented way. Dashed boxes represent local restrictions in the class, i.e. datatype properties that can be applied to the class they are attached to.

Individuals are denoted by rectangles in which the identifier is underlined.

Note that Figures 1 and 2 aim at showing a global overview of the main classes of SAREF4WATR and their mutual relations. More details on the different parts of the figures are provided from clause 4.2.2 to clause 4.2.9.

Observation

As it appears in Figure 3, the modelling of observations in the SAREF4WATR ontology relies on the observation model proposed in SAREF. In order to reduce duplication with SAREF documentation, the reader is referred to the SAREF specification ETSI TS 103 264 [1] for details about observation modelling including here details only for the new concepts.

SAREF allows to define the temporal extent of an observation by defining the timestamp for it (using the saref:hasResultTime property) and to define the temporal interval to which an observation applies, apart from the temporal instant defined by the timestamp (using the saref:hasPhenomenonTime property).

Besides, the extension requires to be able to represent those devices that observe a certain feature of interest (and those features of interest that are observed by a device) independently of having observations from which this relationship could be inferred. This can be represented with two properties of SAREF that relate saref:Device and saref:FeatureOfInterest: saref:actsUpon and saref:isActedUponBy.

Water meter

Figure 4 provides an overview of how to represent a water meter using the s4watr:WaterMeter class. The representation of water meters and their properties has been extracted from the European M-Bus standard (EN 13757-2 [i.2]).

A water meter may be defined by the properties inherited from SAREF (e.g. saref:hasManufacturer or saref:hasModel) and also by a set of properties defined in SAREF4WATR to indicate: its fabrication number (s4watr:hasFabricationNumber), its firmware version (s4watr:hasFirmwareVersion), its hardware version (s4watr:hasHardwareVersion), its version (saref:hasVersion), the radio frequency in which it operates (s4watr:operatesAtRadioFrequency), and its required power (s4watr:requiresPower).

Observations may be taken from the water meter themselves. To enable the representation of such observations, water meters are defined as features of interest (saref:FeatureOfInterest) and a non-exhaustive list of properties has been defined based on the M-Bus standard to allow measuring: on time (s4watr:MeterOnTime), operating time (s4watr:MeterOperatingTime), battery operating time (s4watr:BatteryOperatingTime), battery last change (s4watr:BatteryLastChange), and battery remaining time (s4watr:BatteryRemainingTime).

Table 2 summarizes the properties that characterize the s4watr:WaterMeter class.

Water flow

Water meters are mainly intended to measure water flows. SAREF4WATR defines the main properties related to the water flow that are defined in the European M-Bus standard (EN 13757-2 [i.2]): pressure (s4watr:FlowPressure), rate (s4watr:FlowRate), temperature (s4watr:FlowTemperature), and volume (s4watr:FlowVolume). These properties are depicted in Figure 5.

Table 3 summarizes another property that characterizes the s4watr:WaterMeter class.

There are also other environmental factors that are relevant since they affect water and the infrastructures using it. Therefore, the following environmental properties, depicted in Figure 6, are defined: atmospheric pressure (s4watr:AtmosphericPressure), humidity (s4watr:Humidity), precipitation (s4watr:Precipitation) and temperature (s4watr:ExternalTemperature).

Tariff

SAREF4WATR allows describing the tariff that is applied to a water meter by means of the s4watr:Tariff class, as presented in Figure 7. The representation of tariffs has been extracted from TR 17167 [i.3].

A tariff may be described using different properties to describe its: start timestamp (s4watr:hasStartTimestamp), duration (s4watr:hasDuration), period (s4watr:hasPeriod), billing date (s4watr:hasBillingDate) and billing period (s4watr:hasBillingPeriod). Besides, a tariff can be related to a water meter by means of the s4watr:appliesTo property.

There are different types of tariffs, depending on whether they are based on thresholds (s4watr:ThresholdBasedTariff), consumption (s4watr:ConsumptionBasedTariff), or time (s4watr:TimeBasedTariff). Each of these types of tariffs has its own properties: for threshold-based ones their volume flow can be defined (s4watr:forVolumeFlow), for consumption-based ones their volume and financial consumption can be defined (s4watr:forVolumeConsumption and s4watr:forFinancialConsumption, respectively), and for time-based ones their absolute time at day, week day and day in month can be defined (s4watr:forAbsoluteTimeAtDay, s4watr:forWeekDay and s4watr:forDayInMonth, respectively). It is also possible to define a combined tariff by making it an instance of more than one type of tariff.

Table 4 summarizes the properties that characterize the s4watr:Tariff class.

Table 5 summarizes the properties that characterize the s4watr:ThresholdBasedTariff class.

Table 6 summarizes the properties that characterize the s4watr:ConsumptionBasedTariff class.

Table 7 summarizes the properties that characterize the s4watr:TimeBasedTariff class.

Water kinds

SAREF4WATR defines four kinds of water as instances of the s4watr:WaterKind class: raw water (s4watr:RawWater), drinking water (s4watr:DrinkingWater), storm water (s4watr:StormWater), and waste water (s4watr:WasteWater). All these kinds of water, depicted in Figure 8, are defined as feature kinds (saref:FeatureKind).

Water properties

SAREF4WATR includes a classification of the different water properties based on the classification proposed by the World Health Organization [i.4], as shown in Figure 9. Water properties (s4watr:WaterProperty) are classified into acceptability (s4watr:AcceptabilityProperty), chemical (s4watr:ChemicalProperty), and microbial (s4watr:MicrobialProperty) ones, being bacterial (s4watr:BacterialProperty) properties a subclass of microbial ones.

The extension defines different individuals for each type of water property, based in different EC directives on the quality of drinking water [i.5], bathing water [i.6] and groundwater [i.7]. This list of individuals does not aim to be exhaustive but to reflect the potential use of the ontology. Note, for example, that it is out of the scope to categorize chemical compounds according to their intended use (e.g. pesticide, fertilizer, etc.).

Water infrastructure

In SAREF4WATR water infrastructures can be defined using the s4watr:WaterInfrastructure class. Such infrastructures may be designed for one of the water kinds described in clause 4.2.6 (through the s4watr:isDesignedFor property), may have an intended use (through the s4watr:isIntendedFor property), and may be classified into five different types, although others may be defined if needed: distribution systems (s4watr:DistributionSystem), storage infrastructures (s4watr:StorageInfrastructure), treatment plants (s4watr:TreatmentPlant), hydroelectric power plants (s4watr:HydroelectricPowerPlant), and monitoring infrastructures (s4watr:MonitoringInfrastructure).

In order to represent the topology of a water infrastructure or its assets, the GeoSPARQL ontology has been reused and connected to the SARE4WATR terms. As shown in Figure 10, for representing spatial objects the geo:SpatialObject class from GeoSPARQL has been reused along with its subclasses that allow defining spatial features (geo:Feature) and geometries (geo:Geometry). Different properties from GeoSPARQL can be reused to define spatial relations among spatial objects (e.g. geo:sfContains, or geo:sfWithin)or to define the geometry of a feature (geo:hasGeometry). Two types of geometries from the GeoSPARQL Simple Features ontology are proposed to be used: points (sf:Point) and polygons (sf:Polygon), although others may also be used from that same ontology or from another one.

GeoSPARQL standard [i.8] reference is provided for further details on how to define the topology of water infrastructures.

By reusing the SAREF4SYST ontology, the different subsystems of a water infrastructure may be defined. A water infrastructure is a complex system (s4syst:System) and each of its subsystems may be defined (using the s4syst:hasSubSystem property) as a water asset (s4watr:WaterAsset).

As shown in Figure 11, SAREF4WATR defines the main types of water assets found in the literature in a hierarchy that is not intended to be exhaustive and that may be extended if needed. This hierarchy classifies water assets into source assets (s4watr:SourceAsset), sink assets (s4watr:SinkAsset), storage assets (s4watr:StorageAsset), and transport assets (s4watr:TransportAsset).

A dedicated class has been defined for water devices (s4watr:WaterDevice), which are those water assets that are also devices according to SAREF (saref:Device). A water meter, described in clause 4.2.3, is one special type of water device, among other possible water-related sensors and actuators.

Table 8 summarizes the properties that characterize the s4watr:WaterInfrastructure class.

Key Performance Indicator

Figure 12 provides an overview of the modelling of Key Performance Indicators (KPIs). The KPI modelling involves two main concepts, namely s4city:KeyPerformanceIndicator and s4city:KeyPerformanceIndicatorAssessment. As can be seen in the figure, the modelling of KPIs in SAREF4WATR totally relies on the KPI model proposed in SAREF4CITY [2]. In order to reduce duplication with the SAREF4CITY documentation, the reader is referred to the SAREF4CITY specification for details about KPI modelling.

In SAREF4WATR, KPIs are intended to be defined for water infrastructures (s4watr:WaterInfrastructure). However, KPIs may also be defined for other features of interest.

Instantiating SAREF4WATR

This clause shows different examples of how to instantiate the SAREF4WATR extension of SAREF.

The example presented in Figure 13 depicts a water meter (ex:Meter4837QW123). It can be described by a set of static properties either reused from SAREF (e.g. saref:hasModel) or from SAREF4WATR (e.g. s4watr:hasFirmwareVersion). The spatial extent of the meter is described by its geometry (ex:MeterGeom) that is represented as a point in space following its WKT representation. SAREF4WATR defines different measurable properties of a water meter, among them the battery remaining time (s4watr:BatteryRemainingTime) that is the one used in the example. Observations of the meter for this property can be represented (ex:WMObservation200206) using for example the time instant of the observation and its value and the unit of measure in a property value.

The main function of water meters is to measure water flow. Figure 14 presents two examples of water flow observations (ex:WFObservation170206 and ex:WFObservation643234) for a water flow property (s4watr:FlowVolume) and an environmental one (s4watr:ExternalTemperature), respectively. Notice how the flow volume observation is described with a time instant while the external temperature one is described with a time interval (ex:PT838452).

Different tariffs can be applied to water meters. Figure 15 presents an example of a consumption-based tariff (ex:Meter4837QW123Tariff) for a water meter (ex:Meter4837QW123). Different individuals are defined for describing the duration (ex:FiveYears), period (ex:OneYear) and billing period (ex:OneMonth) of the tariff. SAREF4WATR does not restrict how to define particular conditions of a tariff; in the example, for the consumption description a string literal is used.

The observation of the different properties of the water itself is also of interest. Figure 16 presents two observations (ex:DTSObservation106 and ex:DTSObservation107) of one chemical property (s4watr:Cadmium) and of one bacterial property (s4watr:EscherichiaColi), along with their timestamps, values and units. Even if SAREF4WATR includes a set of predefined water properties, other properties could be defined by instantiating the corresponding s4watr:WaterProperty subclass.

Figure 17 depicts a water infrastructure (ex:DowntownDS) that represents a distribution system for drinking water (s4watr:DrinkingWater) intended for domestic use (s4watr:Domestic). The spatial extent of the infrastructure is described by its geometry (ex:DSGeom) that is represented as a polygon in space following its WKT representation. The water distribution system has different subsystems: a water meter (ex:Meter4837QW123), a tank (ex:Tank38472) and a pump (ex:PumpRT73467). These subsystems can be represented through their geometries, as points in the example (ex:MeterGeom, ex:TankGeom, ex:PumpGeom), and different measures could be made of them such as the one depicted (ex:PObservation854306) that observes the flow rate (s4watr:FlowRate) of the pump.

Figure 18 contains an example of a key performance indicator (ex:MinimumPressureLevel) defined for a water distribution system (ex:DowntownDS). The key performance indicator is defined with its name and calculation period (ex:OneWeek). Besides, an assessment is made for the KPI (ex:MPL2020020723), derived from existing observations (ex:PLObservation56206, ex:PLObservation56207 and ex:PLObservation56208), indicating the value of the assessment and its temporal properties.

Discussion

In the following paragraphs, several observations about the SAREF4WATER ontology and its usage are mentioned.

The hierarchies and individuals defined in the extension should not be considered exhaustive, the ontology currently represents those devices described in different relevant standards and directives. It might be needed to extend the hierarchies and lists of individuals for particular use cases, as well as to specialize some of the defined classes.

Apart from this, some of the properties defined for a water meter that were extracted from the M-Bus standard are quite generic (e.g. s4watr:hasHardwareVersion or s4watr:hasFirmwareVersion) and could be applicable to other domains (at least those covered by the standard: energy and gas). Therefore, they could also be moved to SAREF.

References

Normative references

• [0] ETSI TS 103 410-10 (V2.1.1): "SmartM2M;; Extension to SAREF; Part 10: Water Domain".
• [1] ETSI TS 103 264: "SmartM2M; Smart Applications; Reference Ontology and oneM2M Mapping".
• [2] ETSI TS 103 410-4: "SmartM2M; Extension to SAREF; Part 4: Smart Cities Domain".
• [3] ETSI TS 103 548: "SmartM2M; SAREF reference ontology patterns".
• [4] Void.

Informative references

• [i.1] ETSI TR 103 547 (V1.1.1) (10-2019): "SmartM2M; SAREF extension investigation; Requirements for the Water domain".
• [i.2] EN 13757-2:2017: "Communication systems for meters - Part 2: Wired M-Bus communication", (produced by CEN).
• [i.3] TR 17167: "Communication system for meters - Accompanying TR to EN 13757-2,-3 and -7, Examples and supplementary information", (produced by CEN).
• [i.4] World Health Organization (2017): "Guidelines for Drinking‐water Quality. Fourth edition incorporating the first addendum".
• [i.5] Council Directive 98/83/EC of 3 November 1998 on the quality of water intended for human consumption.
• [i.6] Directive 2006/7/EC of the European Parliament and of the Council of 15 February 2006 concerning the management of bathing water quality and repealing Directive 76/160/EEC.
• [i.7] Directive 2006/118/EC of the European Parliament and of the Council of 12 December 2006 on the protection of groundwater against pollution and deterioration.
• [i.8] OGC 11-052r4: "OGC GeoSPARQL - A Geographic Query Language for RDF Data". Version 1.0.
• [i.9] ETSI TR 103 781: "SmartM2M; Study for SAREF ontology patterns and usage guidelines".
• [i.10] ETSI TS 103 673: "SmartM2M; SAREF Development Framework and Workflow, Streamlining the Development of SAREF and its Extensions".

Acknowledgements