History, Design Principles, Extensions

Introduction and Overview

The Smart Applications REFerence ontology (SAREF) is intended to enable interoperability between solutions from different providers and among various activity sectors in the Internet of Things (IoT), thus contributing to the development of the global digital market.

SAREF explicitly specifies the recurring core concepts in the Smart Applications domain, the main relationships between these concepts, and axioms to constrain the usage of these concepts and relationships. SAREF is based on the fundamental principles of reuse and alignment of concepts and relationships that are defined in existing assets, modularity to allow separation and recombination of different parts of the ontology depending on specific needs, extensibility to allow further growth of the ontology, and maintainability to facilitate the process of identifying and correcting defects, accommodate new requirements, and cope with changes in (parts of) SAREF.

Mappings to other concepts used by different semantic assets allow translation from the reference ontology to specific assets, reducing the effort of translating from one asset to another, since the reference ontology requires one set of mappings to each asset, instead of a dedicated set of mappings for each pair of assets. Figure 1 shows the role of the reference ontology in the mapping by means of sample assets. The mappings of SAREF to various assets are available in [i.4].

A Brief History of SAREF

The SAREF initiative started in 2014/2015 with a study requested by the European Commission on "Available Semantics Assets for the Interoperability of Smart Appliances: Mapping into a Common Ontology as a M2M Application Layer Semantics" [i.1]. Such study acknowledged that the energy utilization of Smart Appliances can be reduced if they are managed and controlled on a system level. The system needs standardized interfaces to ensure interoperability. Many of the required standards already exist, but a common architecture does not, resulting in a market which is too fragmented and powerless. Therefore, a reference ontology of consensus was designed to cover the needs of all appliances relevant for energy efficiency. The study consisted of three tasks:

• Task 1: Take stock of existing semantic assets and use case assets.
• Task 2: Perform a translation exercise of each model (or use case) to a common ontology language and a mapping or matching exercise between all the models.
• Task 3: Propose a reference ontology and document the ontology into the ETSI M2M architecture.

About 50 different semantic assets (i.e. standards, protocols, data models, ontologies) had been identified that describe various properties of Smart Appliances in residential environments. After translating half of these semantic assets into Web Ontology Language (OWL) (https://sites.google.com/site/smartappliancesproject/ontologies), 20 recurring concepts were used as initial building blocks for creating the Smart Applications REFerence ontology. The concepts were mapped from the semantic assets to SAREF to allow for translations between different semantic assets [i.4].

In November 2015, SAREF was transformed into a Technical Specification and published by ETSI SmartM2M as ETSI TS 103 264 [i.5].

In 2016, ETSI SmartM2M requested a Specialist Task Force (STF) to identify and create possible extensions of SAREF, and provide input to update SAREF according to the requirements collected from the stakeholders that have used SAREF since its first release in April 2015. This led to a new release SAREF V2.1.1 [i.6], which incorporated the feedback both from the STF that created the first SAREF extensions, and from the stakeholders that provided their input for improving SAREF. This feedback can be found in ETSI TR 103 411 [i.3] and was used to create SAREF V2.1.1.

The scope of the first release of SAREF was limited to an indoor managed domain, such as a building managed by a building manager or an apartment managed by a user. This scope also included the outdoor premises that belong to the considered indoor managed domain, in other words, a pergola that is part of the building is also within the scope, as well as a sensor located under that pergola. Note that the smart city domain was not originally considered, i.e. if the same sensor that is under the pergola is also in a street, then the sensor in the street was out of the scope of SAREF. After extending SAREF to different domains, it was clear the need for broadening the scope of SAREF from home appliances and buildings to any device that can be found in smart applications; this motivated the change of name of the ontology from "Smart Appliances REFerence ontology" to "Smart Applications REFerence ontology".

In June 2018, another STF started in SmartM2M with the goal (among others) of consolidating SAREF with new reference ontology patterns, based on the experience from the EUREKA ITEA SEAS project. As a result of this STF, 37 different issues were identified and discussed in ETSI TR 103 549 [i.20], proposing and agreeing on resolutions for most of them. Furthermore, it was identified the need for moving some transversal terms used in several extensions of SAREF to the core SAREF ontology, because of the broad applicability of such terms. This led to the release of SAREF ETSI TS 103 264 V3.1.1 [i.7].

SAREF and its different extensions were developed quite independently by different teams of experts, sometimes in parallel. Sometimes different modelling decisions were made, with the result that SAREF extensions had important discrepancies. SmartM2M started to identify ontology patterns that may be used to homogenise the structure of SAREF extensions. In 2022, two new STFs started in SmartM2M with the goal to homogenise and facilitate the use of SAREF and existing 11 SAREF domain mapping by using common ontology patterns. A total of 91 different issues were identified and discussed in ETSI TR 103 781 [i.21], and a set of SAREF Core reference ontology patterns was specified in ETSI TS 103 548 [4].

A summary of the most relevant changes made in SAREF ETSI TS 103 264 V2.1.1 [i.6], V3.1.1 [i.7] and V3.2.1 (the present document) is provided in annex A.

SAREF Design Principles

The Smart Applications REFerence ontology (SAREF) is conceived as a shared model of consensus that facilitates the matching of existing semantic assets for building smart applications, reducing the effort of translating from one asset to another, since SAREF requires one set of mappings to each asset, instead of a dedicated set of mappings for each pair of assets.

Different semantic assets share some recurring, core concepts, but they often use different terminologies and adopt different data models to represent these concepts. Using SAREF, different assets can keep using their own terminology and data models, but still can relate to each other through their common semantics. In other words, SAREF enables semantic interoperability in smart applications through its shared, core concepts.

SAREF explicitly specifies recurring core concepts in smart applications, the main relationships between these concepts, and axioms to constrain the usage of these concepts and relationships. SAREF has been created based on the following fundamental principles:

• Reuse and alignment of concepts and relationships that are defined in existing assets. Since a large amount of work was already being done in the smart appliances and in the Internet of Things domains, nothing has been re-invented, but harmonized and aligned what was already there. SAREF is based on the core concepts that were identified as especially relevant to describe the existing semantic assets for smart applications and is aligned to the main classes and properties of the oneM2M base ontology [1].

• Modularity to allow separation and recombination of different parts of the ontology depending on specific needs. SAREF provides building blocks that can be combined to accommodate different needs and points of view. The starting point is the concept of device, which is actually common to all the semantic assets considered in the study, although some assets may refer to it with different names, such as resource or product, but mappings for that are provided in [i.4]. A device is always designed to perform one or more functions, therefore, SAREF offers a list of basic functions that can be eventually combined in order to have more complex functions in a single device. Each function has some associated commands, which can also be selected as building blocks from a list. Depending on the function(s) it performs, a device can be found in some corresponding states that are also listed as building blocks, so that it is easy and intuitive to combine devices, functions and states. SAREF also provides a list of properties that can be used to further specialize the functioning of a device.
• Extensibility to allow further growth of the ontology. Different stakeholders can specialize the SAREF concepts according to their needs and points of view, add more specific relationships and axioms to refine the general (common) semantics expressed in the reference ontology, and create new concepts, as long as they explicitly link these extensions to at least one existing concept and/or relationship in SAREF. The minimum requirement is that any extension/specialization shall comply with SAREF. Examples of extensions of SAREF in different domains are SAREF4ENER (energy domain) [i.8], SAREF4ENVI (environment domain) [i.9] and SAREF4BLDG (building domain) [i.10]. SAREF and extensions are based on patterns that are used in different domains. SAREF extension developers should reuse SAREF reference ontology patterns as specified in ETSI TS 103 548 [4].
• Maintainability to facilitate the process of identifying and correcting defects, accommodate new requirements, and cope with changes in (parts of) SAREF. According to the extensibility criterion mentioned above, a new module/ontology can be created to further extend/specialize concepts of SAREF. The party that creates the extension should also be responsible for the maintenance of this extension and its evolution over time. SAREF extension developers shall comply with the SAREF Development Framework and Workflow as specified in ETSI TS 103 673 [3]. For an initial strategy proposed in ETSI to extend, maintain and evolve SAREF (and its extensions), see ETSI TR 103 411 [i.3].

SAREF Extensions

SAREF is the reference ontology for smart applications and contains recurring concepts that are used in several domains. SAREF has a close relation with the oneM2M Base Ontology, for which a mapping is defined in clause 6. As smart applications are not restricted to only one domain, it is possible that specific concepts for a certain domain are not part of SAREF. To be able to handle these additional concepts and provide different domains with a proper ontology that reflects the specific needs of that domain, extensions to SAREF should be created. Figure 11 shows SAREF as the core model to be used as basis for creating extensions in different domains, which are represented as rectangles. Each domain can have one or more extensions, depending on the complexity of the domain and the different needs. Extensions of SAREF have been created for:

• SAREF4ENER for the Energy domain in ETSI TS 103 410-1 [i.8].
• SAREF4ENVI for the Environment domain in ETSI TS 103 410-2 [i.9].
• SAREF4BLDG for the Building domain in ETSI TS 103 410-3 [i.10].
• SAREF4CITY for the Smart City domain in ETSI TS 103 410-4 [i.11].
• SAREF4INMA for the Industry and Manufacturing domain in ETSI TS 103 410-5 [i.12].
• SAREF4AGRI for the Agrifood domain in ETSI TS 103 410-6 [i.13].
• SAREF4AUTO for the Automotive domain in ETSI TS 103 410-7 [i.14].
• SAREF4EHAW for the eHealth and Ageing Well domain in ETSI TS 103 410-8 [i.15].
• SAREF4WEAR for the Wearables domain in ETSI TS 103 410-9 [i.16].
• SAREF4WATR for the Water domain in ETSI TS 103 410-10 [i.17].
• SAREF4LIFT for the Smart Lifts domain in ETSI TS 103 410-11 [i.18].
• SAREF4GRID for the Smart Grids domain in ETSI TS 103 410-12 [i.19].

Other extensions can be created for new domains and, if needed, also for the same domains for which extensions already exist.

Develop, apply and evolve SAREF ontologies

The following provisions apply to SAREF:

Provision 1: SAREF Core and SAREF Extension development shall conform to ETSI TS 103 673 [3].

Provision 2: Whenever appropriate, SAREF Extensions should reuse and extend SAREF Reference ontology patterns as specified in ETSI TS 103 548 [4].

Provision 3: SAREF shall use the SAREF Communication framework as defined in ETSI TS 103 267 [2].

Some examples of device built using SAREF can be found in ETSI TR 103 411 [i.3] and in the different SAREF extensions ([i.8] to [i.19]).

Specification of SAREF

Prefixes and Namespaces

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

General Overview

Figure 3 shows an overview of the main classes and properties of SAREF Core.

A detailed explanation of each class is presented in clause 5.2 to clause 5.13.

Feature kinds and features of interest

Figure 4 illustrates the main classes and properties for feature kinds and features of interest. SAREF extensions and applications may create, specialize, and categorize feature kinds and features of interest as specified in ETSI TS 103 548 [4], clause 5.2.

Class saref:FeatureOfInterest represents any real world entity from which a property or a state may be acted upon, such as observed and controlled. An instance of saref:FeatureOfInterest represents one specific real world entity.

<etsi_premises/athena> a saref:FeatureOfInterest ;
            rdfs:label "ATHENA amphitheatre"@en ;
            rdfs:comment "The ATHENA amphitheatre in the ETSI premises."@en .
    <etsi_premises/athena/window5> a saref:FeatureOfInterest ;
            rdfs:label "ATHENA Window 5"@en ;
            rdfs:comment "Window 5 of ATHENA amphitheatre"@en .

Class saref:FeatureKind allows to describe kinds of features of interest, with common properties having the same value, and common states being the same. An instance of saref:FeatureKind represents an archetype of real world entities, for example to populate product catalogs.

<1000x2000mmWindowOrientedNorth> a saref:FeatureKind ;
            rdfs:label "1000x2000mm window oriented north"@en ;
            rdfs:comment "The kind of windows with dimensions 1000x2000mm and oriented north."@en .

Feature kinds can be organized in a taxonomy using OPs skos:narrower and skos:broader.

<1000x2000mmWindowOrientedNorth> a saref:FeatureKind ;
            skos:broader <1000x2000mmWindow> ;
skos:broader <WindowOrientedNorth> .

A feature of interest can be linked to its kind(s) using OP saref:hasFeatureKind.

<etsi_premises/athena/window5>
            saref:hasFeatureKind <1000x2000mmWindowOrientedNorth> .

<etsi_premises/athena/window5>
            saref:hasFeatureKind <1000x2000mmWindow> ;
saref:hasFeatureKind <WindowOrientedNorth> .

A feature kind (respectively a feature of interest) may consist of (OP saref:consistsOf) other feature kinds (respectively features of interest).

s4abcd:AAHeatPumpDryer a saref:FeatureKind ;
    saref:consistsOf s4abcd:HeatPump , s4abcd:AirCyclingCircuit , s4abcd:Dryer .

<etsi_premises/athena> a saref:FeatureOfInterest ;
        saref:consistsOf <etsi_premises/stage> ;
        saref:consistsOf <etsi_premises/athena/window5> .

Whenever appropriate, SAREF extensions and applications should also use the classes from SAREF4SYST to specify if a saref:FeatureOfInterest is a system (s4syst:System), a Connection between systems (s4syst:Connection), or a connection point of a system (s4syst:ConnectionPoint).

The model and the manufacturer of a saref:FeatureKind or a saref:FeatureOfInterest can be explicited using DPs saref:hasModel and saref:hasManufacturer, respectively.

<ball-bearing-xsd215sd7f> a saref:FeatureOfInterest ;
        saref:hasManufacturer "Company X"@en ;
    saref:hasModel "6000-2RZ1 "@en .

Devices

Figure 5 illustrates the main classes and properties for devices. SAREF extensions and applications may create, specialize, and categorize devices as specified in ETSI TS 103 548 [4], clause 5.3.

Class saref:Device represents any tangible object designed to accomplish a particular task by performing one or more functions. An instance of saref:Device represents one specific real world entity.

ex:Meter4837QW123 a saref:Device ;
            rdfs:label "Meter 4837QW123"@en ;
            rdfs:comment "The meter that measures the incoming water flow 
                             of the Computer Science school."@en .

ex:Dryer354A1E08FA a saref:Device ;
            rdfs:label "Dryer 354A1E08FA"@en ;
            rdfs:comment "The laundry dryer with serial number 354A1E08FA"@en.

Devices are also systems (s4syst:System) and features of interest (saref:FeatureOfInterest).

A device can be linked to its feature kinds using OP saref:hasDeviceKind. Kinds of devices describe models of devices, with common properties having the same value, common states being the same, common functions, and common services. OP saref:hasDeviceKind is a sub-property of OP saref:hasFeatureKind.

ex:Meter4837QW123 saref:hasDeviceKind s4abcd:SmartWaterMeterABC123 . s4abcd:SmartWaterMeterABC123 a saref:FeatureKind ;
    rdfs:label "Smart Water Meter ABC123"@en ;
    rdfs:comment "The smart water meter ABC123 of manufacturer ABC. A device kind."@en .

A device can act upon (OP saref:actsUpon) features, properties, or states. SAREF Core defines different sub-properties of saref:actsUpon:

• saref:observes for when a device observes a feature, or property or state of that feature.
• saref:controls for when a device controls a feature, or property or state of that feature.

s4abcd:AAHeatPumpDryer a saref:FeatureKind ;
    saref:controls s4abcd:DryerRotationalSpeed ;
    saref:controls s4abcd:DryerTemperature ;
    saref:observes s4abcd:LaudryBatchHumidity .

As shown in Figure 6, SAREF Core provides some examples of classes of devices including appliances, sensors, actuators, and meters. Their definitions are the following:

• saref:Appliance: The class of devices designed to accomplish a particular task for occupant use. It consumes, produces, or stores, some commodity.
• saref:Sensor: A device designed to observe one or more properties or states of one or more features of interest.
• saref:Actuator: A device designed to control one or more properties or states of one or more features of interest.
• saref:Meter: A device designed to observe and measure one or more properties of one or more features of interest.

Tasks

Class saref:Task represents goals for which a device is designed, from a user perspective.

SAREF extensions and applications may create, specialize, and categorize tasks as specified in ETSI TS 103 548 [4], clause 5.4 and illustrated on Figure 7.

Tasks can be organized in a taxonomy using OPs skos:narrower and skos:broader.

saref:Drying a saref:Task ;
            rdfs:label "Drying"@en ;
            rdfs:comment "A type of task for which a device is designed."@en .

Device kinds and devices can be linked to the one or more tasks they are designed to accomplish with OP saref:accomplishes.

s4abcd:AAHeatPumpDryer a saref:FeatureKind ;
saref:accomplishes s4abcd:DryingLaundry .

ex:switch21354 a saref:Device ;
saref:hasDeviceKind s4abcd:Switch ;
        saref:accomplishes s4abcd:Lighting .

Commodities

Class saref:Commodity represents marketable items which may be supplied without qualitative differentiation. Commodities may be consumed, produced, or stored, by some feature of interest or device.

SAREF extensions and applications may create, specialize, and categorize commodities as specified in ETSI TS 103 548 [4], clause 5.5 and illustrated on Figure 8.

Commodities can be organized in a taxonomy using OPs skos:narrower and skos:broader.

SAREF Core defines the category of energy commodities that groups electricity, gas, propane (of kind gas), coal. It furthermore defines the category of natural resource commodity.

s4abcd:Electricity a saref:EnergyCommodity ;
            rdfs:label "Electricity"@en ;
            rdfs:comment "The electricity energy commodity."@en .

A feature kind, feature of interest, or device, can consume (OP saref:consumes), produce (OP saref:produces), or store (OP saref:stores), a certain commodity.

s4abcd:AAHeatPumpDryer a saref:FeatureKind ;
saref:consumes s4abcd:Electricity ;
saref:produces s4abcd:Water .

Properties, properties of interest, and property values

Introduction

In SAREF, properties refer to the identifiable qualities of features of interest that can be acted upon by devices, such as observed or controlled. While properties can apply to different features of interest, properties of interest are specific to a feature of interest. Property values describe the value for a property.

Figure 10 illustrates the main classes and properties for describing properties, properties of interest, and property values.

SAREF extensions and applications may create, specialize, and categorize properties as specified in ETSI TS 103 548 [4], clause 5.6.

Properties

An instance of saref:Property can apply to different features of interest.

s4abcd:Temperature a saref:Property ;
    rdfs:label "Temperature"@en ;
    rdfs:comment "The temperature property kind."@en . 
s4abcd:Pressure a saref:Property ;
    rdfs:label "Pressure"@en ;
    rdfs:comment "The pressure property kind."@en .
s4abcd:Luminance a saref:Property ;
    rdfs:label "Temperature"@en ;
    rdfs:comment "The luminance property kind."@en .

Properties can be organized in a taxonomy using properties skos:narrower and skos:broader.

<https://qudt.org/2.1/vocab/quantitykind/ActiveEnergy> a saref:Property ;
    rdfs:label "Active Energy"@en ;
    rdfs:comment "\"Active Energy\" is the electrical energy transformable into some other form of energy."@en .
<http://vocab.nerc.ac.uk/collection/P01/current/CDTSZZ01/> a saref:Property ;
    skos:prefLabel "Absolute temperature standard deviation of the atmosphere by dry bulb thermometer"@en

The OP saref:hasProperty may be used to link a feature kind or feature of interest to its properties. Its inverse is saref:isPropertyOf.

s4abcd:AAHeatPumpDryer a saref:FeatureKind ;
saref:hasProperty s4abcd:DryerRotationalSpeed ;
saref:hasProperty s4abcd:DryerTemperature .

skos:broader o saref:hasProperty ⊑ saref:hasProperty

saref:hasFeatureKind o saref:hasProperty ⊑ saref:hasProperty

Properties of interest

An instance of saref:PropertyOfInterest is specific to a feature of interest. It is inherent to and cannot exist without that feature of interest.

The OP saref:hasPropertyOfInterest may be used to link a feature of interest to its properties of interest. Its inverse is saref:isPropertyOfInterestOf and is functional.

A property of interest is the property of (OP saref:isPropertyOfInterestOf) exactly one feature of interest.

• NOTE 1:: Properties of interest need not always be explicited. It depends on the use case. Typically, properties of interest are useful in applications, where the association between a feature of interest and a property (i.e. the property of interest) needs to be identified and related to other properties of interest.

Given a property of interest belongs to exactly one feature of interest, it is recommended that its identifier consists of the identifier of the feature of interest, followed by character '#' and a fragment identifier. The fragment identifier part of the IRI of a property of interest should not contain "property".

<etsi_premises/athena#luminance> a saref:PropertyOfInterest ;
    saref:isPropertyOfInterestOf <etsi_premises/athena> ; 
    rdfs:comment "The luminance of amphitheatre ATHENA"@en .

A property of interest can be linked to its kind(s) using OP saref:hasPropertyKind.

saref:hasPropertyKind o skos:broader ⊑ saref:hasPropertyKind

<etsi_premises/athena#luminance> a saref:PropertyOfInterest ;
    saref:hasPropertyKind saref:Luminance .

saref:hasPropertyOfInterest o saref:hasPropertyKind ⊑ saref:hasProperty

<etsi_premises/athena> a saref:FeatureOfInterest ;
    saref:hasPropertyOfInterest <etsi_premises/athena#luminance> ;
    saref:hasProperty saref:Luminance .

Property Values

Class saref:PropertyValue describes the value for a property. The property value is linked to its value expressed as an RDF literal (DP saref:hasValue), optionally to the unit of measurement (OP saref:isMeasuredIn), and optionally to the properties or properties of interest it is a value of (OP saref:isValueOfProperty).

The range of saref:isMeasuredIn is defined as saref:UnitOfMeasure.

The OP saref:hasPropertyValue links a feature kind, a feature of interest, or a property of interest, to a property value.

<etsi_premises/athena#size> a saref:PropertyOfInterest ;
                            saref:isPropertyOf  ;
                        saref:hasPropertyValue [
                            a saref:PropertyValue ;
                            saref:hasValue 105.0 ;
                            saref:isMeasuredIn <https://qudt.org/2.1/vocab/unit/M2> ] .

skos:broader saref:hasPropertyValue ⊑ saref:hasPropertyValue

The OP saref:isValueOfProperty links a property value to the properties and properties of interest it is a value of.

<1000x2000mmWindowOrientedNorth> a saref:FeatureKind ;
                        saref:hasProperty  ;
                        saref:hasPropertyValue [
                            a saref:PropertyValue ;
                            saref:hasValue 2.0 ;
                            saref:isMeasuredIn https://qudt.org/2.1/vocab/unit/M2 ;
                            saref:isValueOfProperty <WindowArea> ] .

saref:isValueOfProperty o saref:hasPropertyKind ⊑ saref:isValueOfProperty

States and states of interest

Introduction

In SAREF, states refer to the identifiable conditions that features of interest are or may be in, and that can be acted upon by devices, such as observed and controlled. While states can apply to different features of interest, states of interest are specific to a feature of interest.

Figure 11 illustrates the main classes and properties for describing states and states of interest.

SAREF extensions and applications may create, specialize, and categorize states as specified in ETSI TS 103 548 [4], clause 5.7.

States

An instance of saref:State can apply to different features of interest.

saref:OnOffState a saref:State .
    saref:OnState a saref:State ;
        skos:broader saref:OnOffState .
    saref:OffState a saref:State ;
        skos:broader saref:OnOffState .
    s4abcd:Switch a saref:FeatureKind ;
    saref:hasState saref:OnOffState .

States can be organized in a taxonomy using properties skos:narrower and skos:broader.

The OP saref:hasState may be used to link a feature kind to its states. Its inverse is saref:isStateOf.

s4abcd:TwoButtonsOneWaySwitch a saref:FeatureKind ;
    saref:hasState s4abcd:Button1UpDownState , s4abcd:Button2UpDownState .
s4abcd:Button1UpDownState a saref:State ;
    skos:broader s4abcd:ButtonUpDownState .
s4abcd:Button2UpDownState a saref:State ;
    skos:broader s4abcd:ButtonUpDownState .

The narrowest states of the taxonomy of states can be considered as the state values.

s4abcd:ButtonUp a saref:State ;
    skos:broader s4abcd:ButtonUpDownState .
s4abcd:ButtonDown a saref:State ;
    skos:broader s4abcd:ButtonUpDownState .

skos:broader o saref:hasState ⊑ saref:hasState

saref:hasFeatureKind o saref:hasState ⊑ saref:hasState

States of Interest

An instance of saref:StateOfInterest is specific to a feature of interest. It is inherent to and cannot exist without that feature of interest.

The OP saref:hasStateOfInterest may be used to link a feature of interest to its states of interest. Its inverse is saref:isStateOfInterestOf and is functional.

A state of interest is the state of (OP saref:isStateOfInterestOf) exactly one feature of interest.

Given a state of interest belongs to exactly one feature of interest, it is recommended that its identifier consists of the identifier of the feature of interest, followed by character '#' and a fragment identifier. The fragment identifier part of the IRI of a property of interest should not contain "state".

<switch_sdf5ze4fz3> a saref:Device ;
saref:hasDeviceKind s4abcd:TwoButtonsOneWaySwitch ; 
saref:hasState <switch_sdf5ze4fz3#btn1>, <switch_sdf5ze4fz3#btn2> .

<switch_sdf5ze4fz3#btn1> a saref:StateOfInterest ; saref:hasStateKind s4abcd:Button1UpDownState . <switch_sdf5ze4fz3#btn2> a saref:StateOfInterest ; saref:hasStateKind s4abcd:Button2UpDownState .

A state of interest can be linked to its kind(s) using OP saref:hasStateKind.

saref:hasStateKind o skos:broader ⊑ saref:hasStateKind

saref:hasStateOfInterest o saref:hasStateKind ⊑ saref:hasState

As the narrowest states of the taxonomy of states can be thought of as the state values, it is possible to assign a stable value to a state as follows:

<switch_sdf5ze4fz3#btn2> a saref:StateOfInterest ;
        saref:hasStateKind s4abcd:Button2UpDownState ;
        saref:hasState s4abcd:ButtonUp .

Functions and functions of interest

Introduction

In SAREF, functions are logical groups of commands that devices support to accomplish their tasks. Function can act upon (OP saref:actsUpon and its sub-properties) features, properties, or states. While functions are independent of any devices, functions of interest are functions actually supported by a device.

Figure 12 illustrates the main classes and properties for describing functions and functions of interest.

SAREF extensions and applications may create, specialize, and categorize functions as specified in ETSI TS 103 548 [4], clause 5.8.

Functions

An instance of saref:Function can apply to different devices.

Functions can be organized in a taxonomy using properties skos:narrower and skos:broader.

Kinds of devices can be defined from pre-defined building blocks, based on the functions they have.

s4abcd:AAHeatPumpDryer a saref:FeatureKind ;
saref:hasFunction s4acd:WashingFunction .

The OP saref:hasFunction may be used to link a feature kind or device to its functions. Its inverse is saref:isFunctionOf.

skos:broader o saref:hasFunction ⊑ saref:hasFunction

saref:hasDeviceKind o saref:hasFunction ⊑ saref:hasFunction

Functions of Interest

An instance of saref:FunctionOfInterest is supported by exactly one device.

The OP saref:hasFunctionOfInterest may be used to link a device to its function of interest. Its inverse is saref:isFunctionOfInterestOf and is functional.

A function of interest is the function of (OP saref:isFunctionOfInterestOf) exactly one device.

A function of interest can be linked to its kind(s) using OP saref:hasFunctionKind.

saref:hasFunctionKind o skos:broader ⊑ saref:hasFunctionKind

saref:hasFunctionOfInterest o saref:hasFunctionKind ⊑ saref:hasFunction

Commands and commands of interest

Introduction

In SAREF, commands represent the lowest-level directives a device supports and exposes to some network. Commands can act upon (OP saref:actsUpon and its sub-properties) features, properties, or states. While commands are independent of any function, commands of interest are commands actually supported by a function of interest.

Figure 13 illustrates the main classes and properties for describing commands and device commands.

SAREF extensions and applications may create, specialize, and categorize commands as specified in ETSI TS 103 548 [4], clause 5.8.

Commands

An instance of saref:Command is independent of any device.

Commands can be organized in a taxonomy using OPs skos:narrower and skos:broader.

Functions can be defined from pre-defined building blocks, based on the commands they have.

The OP saref:hasCommand may be used to link a function or function of interest to its commands. Its inverse is saref:isCommandOf. SAREF Core defines two sub-properties of saref:hasCommand, that only apply to functions:

• saref:hasMandatoryCommand for when the command is mandatory to the function;
• saref:hasOptionalCommand for when the command is optional to the function.

skos:broader o saref:hasMandatoryCommand ⊑ saref:hasMandatoryCommand

saref:hasFunctionKind o saref:hasMandatoryCommand ⊑ saref:hasCommand

A command may be described in terms of its input parameters using OP saref:hasInput. Typically, input parameters are feature kinds, properties, or states.

A command may be described in terms of its outputs using OP saref:hasOutput. Typically, outputs are properties or states.

A command may be described in terms of the properties or states it acts upon, such as observe, or control.

Commands of Interest

A saref:CommandOfInterest is a directives actually supported by a device and exposed to some network.

Like for commands, commands of interest may be described in terms of their input parameters, outputs, and of which properties or states they act upon.

The OP saref:hasCommandOfInterest may be used to link a function of interest to its command of interest. Its inverse is saref:isCommandOfInterestOf and is functional.

A command of interest is the command of (OP saref:isCommandOfInterestOf) exactly one function.

A command of interest can be linked to its kind(s) using OP saref:hasCommandKind.

saref:hasCommandKind o skos:broader ⊑ saref:hasCommandKind

saref:hasCommandOfInterest o saref:hasCommandKind ⊑ saref:hasCommand

Services and Operations

Figure 14 illustrates the main classes and properties for describing services and operations.

A saref:Service is a digital representation of a function in a network, making it discoverable, registerable and remotely controllable in the network.

OP saref:represents links a service to some function or function of interest it exposes to the network.

A service represents at least one function of interest.

OP saref:offers links a device to a service it exposes to a network. Its inverse if saref:isOfferedBy.

A service is offered by exactly one device.

A saref:Operation is the means of a service to communicate in a procedure-type manner over the network (i.e. transmit data to/from other devices). It is the -machine interpretable- exposure of a -human understandable- command to a network.

An operation may be described in terms of its inputs and outputs using OP saref:hasInput and saref:hasOutput. Inputs and outputs of operations typically describe the expected schema or shape of network messages.

OP saref:represents also links an operation to some command or command of interest it exposes to the network.

An operation represents at least one command of interest.

OP saref:hasOperation links a service to its operations. Its inverse is saref:isOperationOf.

An operation belongs to exactly one service.

Procedure executions and sub-classes

Procedure executions

A saref:ProcedureExecution represents the act of carrying out a procedure.

Figure 15 illustrates the main properties for describing procedure executions.

OP saref:madeBy links a procedure execution to the device that made it.

A procedure execution may be linked to its inputs using OP saref:hasInput.

A procedure execution may be linked to its result using OP saref:hasResult.

DP saref:hasResultTime links a procedure execution to the instant of time when the procedure is completed, expressed as an xsd:dateTime literal.

OP saref:hasPhenomenonTime links a procedure execution to the time that the result applies. It may be an interval or an instant, or some other compound temporal entity expressed using OWL Time [7].

When the execution time and the phenomenon time are the same time instants, then DP saref:hasTimestamp can be used to simply link a procedure execution to the time of these instants, expressed as an xsd:dateTime literal.

Optionally, a procedure execution can act upon (OP saref:actsUpon) a feature, property, or state.

Command executions and operation executions

Figure 16 illustrates the main classes and properties for describing command executions and operation executions.

A saref:CommandExecution describes the execution of a command. Typically, its inputs and outputs are human understandable and relate to some feature of interest, such as its state (e.g. s4abcd:On), or the value of its temperature (e.g. property value 21,0 °C).

A saref:OperationExecution describes the execution of an operation in a network: the-machine interpretable- description of a communication between devices over the network. Typically, its input and result are network messages, that conform to the input and output of the executed operation.

OP saref:isExecutionOf links a command execution to the command or command of interest that was executed. It also liks an operation execution to the operation that was executed.

saref:isExecutionOf o skos:broader ⊑ saref:isExecutionOf

saref:isExecutionOf o saref:hasCommandKind ⊑ saref:isExecutionOf

Observations, Measurements, and Actuations

Figure 17 illustrates the main classes and properties for describing observations, measurements, and actuations.

A saref:Observation is the act of carrying out a procedure to estimate or calculate a value of a property of a feature of interest, or a state of a feature of interest. It links to a sensor to describe what made the observation, and to the observed feature, property, property of interest, state, or state of interest. Typically, its result is a property value or a state. An observation of a state (OP saref:observes) should have a state as a result (OP saref:hasResult). Respectively, an observation of a property should have a property value as a result.

ex:DTSObservation106 a saref:Observation ;
    saref:madeBy <meter> ;
saref:hasTimestamp "2023-12-06T21:01:10"^^xsd:dateTime ;
    saref:observes s4watr:Cadmium ;
saref:hasResult ex:Meter4837QW123Value184 .
    ex:Meter4837QW123Value184 a saref:PropertyValue ;
    saref:isValueOfProperty s4watr:Cadmium ;
    saref:hasValue 0.005 .

saref:madeBy <sensor> ;
    saref:hasTimestamp "2023-12-06T21:47:10"^^xsd:dateTime .
saref:observes <door_zef53ze7> ;
saref:observes <door_zef53ze7#openclose> ;
    saref:observes saref:OpenClose ;
saref:hasResult saref:Open .

A saref:Actuation is the act of carrying out a procedure to control the state of the world using an actuator. It links to an actuator to describe what made the actuation, and to the controlled feature, property, property of interest, state, or state of interest. Typically, its input is a property value or a state. An actuation of a state (OP saref:controls) should have a state as input (OP saref:hasInput). Respectively, an actuation of a property should have a property value as input.

Profiles

A device in SAREF can be further characterized by profiles. Figure 18 illustrates the main classes and properties for describing profiles.

A saref:Profile describes the money earned (negative values) or paied (positive values) for the use (production or consumption) of a commodity by a device in a certain context.

OP saref:hasProfile links a device to its profile. Its inverse is saref:isProfileOf. The device should be linked to a certain commodity using OP saref:isUsedFor or its sub-properties, and optionally to some property or state using OP saref:actsUpon or its sub-properties.

ex:Device_1 a saref:Device ;
    saref:isUsedFor s4abcd:Electricity ;
    saref:hasProfile ex:FlexibilityProfile ;
    saref:controls <house#temperature> .
ex:FlexibilityProfile a saref:Profile ;
    saref:hasPrice <pricePropertyValue> .

The applicable context of a profile can be bound temporally using DP saref:hasTimestamp or its subproperties defined by SAREF extensions, or OP saref:hasApplicableTime which links to instant or interval or other compound temporal entity expressed using OWL Time [7].

ex:FlexibilityProfile
saref:hasTimestamp "2023-12-15T11:00:00"^^xsd:dateTime .

ex:FlexibilityProfile
    rdfs:comment "applies only on Saturdays"@en ;

saref:hasApplicableTime [ 
        a time:DateTimeDescription ;
        time:dayOfWeek time:Saturday ] .

The applicable context can be restricted to when the property of a feature of interest has some value (OPs saref:whenPropertyValue).

ex:FlexibilityProfile
saref:whenPropertyValue [
        a saref:PropertyValue ;
        saref:hasValue 22.0 ;
        saref:isMeasuredIn <http://qudt.org/vocab/unit/DEG_C> ;
    saref:isValueForProperty <house#comfort_temperature_setpoint> ] .

The applicable context can be restricted to when a feature of interest has a certain state (OPs saref:whenState).

ex:FlexibilityProfile
saref:whenState [
        a saref:State ;
        skos:broader s4abcd:ComfortSetpoint ;
    saref:isStateOf <house#temperature_setpoint> ] .

OP saref:profileHasPrice links a profile to the money earned (negative values) or paid (positive values) for the use (production or consumption) of the commodity by the device.

ex:FlexibilityProfile
saref:profileHasPrice [
        a saref:PropertyValue ;
        saref:hasValue 0.2 ;
        saref:isMeasuredIn <http://qudt.org/vocab/currency/EUR> ] .  

A set of specializations of a Profile is given via the Flexibility Profile defined in the SAREF4ENER extension in ETSI TS 103 410-1 [i.8]. Each Flexibility Profile describes the ways in which a device can regulate its energy consumption and production. Therefore, the Flexibility Profile is a static set of options to choose from and a set of user preferences, instead of a pre-calculated energy usage time series. The details of each Flexibility Profile can be specified using the related extensions.

A specialization of a Profile may additionally relate to other SAREF classes via properties defined in the extensions, including, but not limited to a state, property, property value, function, and command.

ex:FlexibilityProfile a saref:Profile ;
    s4abcd:{someConditionDefinedBySAREF4ABCD} <conditionSpecification> .

Features of Interest, devices, and spatial objects

An instance may be classified as both saref:FeatureOfInterest and geo:SpatialObject.

The class saref:Device is a sub-class of geo:Feature from the GeoSPARQL standard [8], section 6.2.

SAREF application may attach a geometry to a saref:FeatureOfInterest or a saref:Device using geo:hasGeometry or its sub-properties geo:hasBoundingBox, geo:hasCentroid, geo:hasDefaultGeometry [8], section 6.4.

<etsi_premises> a saref:FeatureOfInterest , geo:Feature ; 
    geo:hasCentroid "POINT( 7.052986 43.6169446 )"^^geo:wktLiteral .

SAREF application may describe how things are spatially related using different families of topological relations from GeoSPARQL, such as the Simple Features relation family (e.g. geo:sfWithin, geo:sfOverlaps), the Egenhoer Relation Family (e.g. geo:ehInside, geo:ehOverlap), the RCC8 Relation Family (e.g. geo:rcc8tpp, geo:rcc8po) [8], section 7.

<etsi_premises/athena> a saref:FeatureOfInterest , geo:Feature ; 
    geo:sfWithin <etsi_premises> .

Mapping between SAREF and oneM2M Base Ontology

Introduction

In ETSI TS 118 112 [1], oneM2M has created a base ontology that describes key classes, relations and properties that are relevant for enabling semantic functionalities within oneM2M systems, as well as enabling interoperability between applications and interworking with existing non-oneM2M technologies. The approach is that given a semantic description of instances according to the oneM2M Base Ontology, a oneM2M resource structure can be automatically created.

General oneM2M resources are created for those ontology instances that are related to functions, e.g. creating an Application Entity resource for a device like a washing machine and creating containers, e.g. for storing the status of the washing machine. They will enable application interactions and thus concern dynamic aspects. Other, more static aspects like the manufacturer of a device will be stored in special semantic descriptor resources that are attached to general oneM2M resources, e.g. there is oneM2M resource representing a device which has a semantic descriptor resource attached that contains semantic information related to the device, e.g. the manufacturer. Such a semantic descriptor resource also contains information concerning the relation to other resources, e.g. operations that can be executed.

A two-step approach for the mapping of SAREF instances to oneM2M resources is used. In the first step, key SAREF classes are mapped to oneM2M Base Ontology classes by defining relations between the SAREF and the oneM2M classes. In the second step, instances modelled according to those SAREF classes for which such a definition exists, are also automatically modelled according to the corresponding oneM2M Base Ontology classes. In the second step, the oneM2M instantiation rules are applied to those instances of SAREF classes that are derived from oneM2M classes. Not all SAREF classes can be mapped to base ontology classes as SAREF models certain aspects that are closely related to the smart applications domain and the base ontology is meant to be agnostic to specific application domains. If no equivalent oneM2M Base Ontology classes exist, e.g. for saref:Commodity, the respective SAREF instances are stored together with SAREF instances with which they are connected through an object property and which are mapped to the oneM2M Base Ontology.

Mapping between SAREF and oneM2M Base Ontology

Figure 19 shows the mapping between SAREF and the oneM2M Base Ontology. Relationships based on owl:equivalentClass and owl:equivalentProperty are considered to link the key classes and object properties of SAREF and the oneM2M Base Ontology. These are needed to be able to apply the oneM2M instantiation rules to the semantic description of entities that are described according to SAREF.

Table 2 shows which SAREF class is mapped to which oneM2M class (and vice-versa). As a result, all oneM2M instantiation rules defined for the oneM2M class can also be applied to the instance of the respective SAREF class, and oneM2M instances can be discovered from SAREF when querying for devices, functions, commands and services.

Table 3 shows which SAREF object property is mapped to which oneM2M object property.

Instantiation Rules for Creating the oneM2M Resource Structure

The Smart Applications oneM2M Mapping shall follow the instantiation rules defined in clause 7 of ETSI TS 118 112 [1].

References

Normative references

• [0] ETSI TS 103 264 (V3.2.1): "SmartM2M;; Smart Applications; Reference Ontology and oneM2M Mapping".
• [1] ETSI TS 118 112: "oneM2M; Base Ontology (oneM2M TS-0012)".
• [2] ETSI TS 103 267: "SmartM2M; Smart Applications; Communication Framework".
• [3] ETSI TS 103 673: "SmartM2M; SAREF Development Framework and Workflow, Streamlining the Development of SAREF and its Extensions".
• [4] ETSI TS 103 548: "SmartM2M; SAREF consolidation with new reference ontology patterns, based on the experience from the SEAS project".
• [5] W3C^® Recommendation 18 August 2009: "SKOS Simple Knowledge Organization System Reference".
• [6] W3C^® Recommendation 19 October 2017:"Semantic sensor network ontology", OGC^® and W3C^® Spatial Data on the Web working Group.
• [7] W3C^® Candidate Recommendation Draft 15 November 2022: "Time ontology in OWL", OGC^® and W3C^® Spatial Data on the Web working Group.
• [8] OGC^® IS 11-052r4 (V1.0): "GeoSPARQL - A Geographic Query Language for RDF Data".

Informative references

• [i.1] European Commission and TNO: "Study on Semantic Assets for Smart Appliances Interoperability", final report, April 2015.
• [i.2] ETSI SAREF: "SAREF: the Smart Applications REFerence ontology".
• [i.3] ETSI TR 103 411: "SmartM2M Smart Appliances SAREF Extension Investigation".
• [i.4] European Commission and TNO D-S4 - SMART 2013-0077: "Smart Appliances - Mapping SAREF to short list assets.xlsx", February 2015.
• [i.5] ETSI TS 103 264 (V1.1.1): "SmartM2M; Smart Appliances; Reference Ontology and oneM2M Mapping".
• [i.6] ETSI TS 103 264 (V2.1.1): "SmartM2M; Smart Appliances; Reference Ontology and oneM2M Mapping".
• [i.7] ETSI TS 103 264 (V3.1.1): "SmartM2M; Smart Applications; Reference Ontology and oneM2M Mapping".
• [i.8] ETSI TS 103 410-1: "SmartM2M; Extension to SAREF; Part 1: Energy Domain".
• [i.9] ETSI TS 103 410-2: "SmartM2M; Extension to SAREF; Part 2: Environment Domain".
• [i.10] ETSI TS 103 410-3: "SmartM2M; Extension to SAREF; Part 3: Building Domain".
• [i.11] ETSI TS 103 410-4: "SmartM2M; Extension to SAREF; Part 4: Smart Cities Domain".
• [i.12] ETSI TS 103 410-5: "SmartM2M; Extension to SAREF; Part 5: Industry and Manufacturing Domains".
• [i.13] ETSI TS 103 410-6: "SmartM2M; Extension to SAREF; Part 6: Smart Agriculture and Food Chain Domain".
• [i.14] ETSI TS 103 410-7: "SmartM2M; Extension to SAREF; Part 7: Automotive Domain ".
• [i.15] ETSI TS 103 410-8: "SmartM2M; Extension to SAREF; Part 8: eHealth/Ageing-well Domain".
• [i.16] ETSI TS 103 410-9: "SmartM2M; Extension to SAREF; Part 9: Wearables Domain".
• [i.17] ETSI TS 103 410-10: "SmartM2M; Extension to SAREF; Part 10: Water Domain".
• [i.18] ETSI TS 103 410-11: "SmartM2M; Extension to SAREF; Part 11: Lift Domain".
• [i.19] ETSI TS 103 410-12: "SmartM2M; Extension to SAREF; Part 12: Smart Grid Domain".
• [i.20] ETSI TR 103 549: "SmartM2M; Guidelines for consolidating SAREF with new reference ontology patterns, based on the experience from the ITEA SEAS project".
• [i.21] ETSI TR 103 781: "SmartM2M; Study for SAREF ontology patterns and usage guidelines".
• [i.22] QUDT.org Quantity Kind: "QUDT Quantity Kind Vocabulary Version 2.1".
• [i.23] QUDT.org Unit: "QUDT Unit Vocabulary Version 2.1".
• [i.24] British Oceanographic Data Centre: "BODC Parameter Usage Vocabulary - P01".

Acknowledgements

The editors would like to thank the ETSI SmartM2M technical committee for providing guidance and expertise.

Also, many thanks to the ETSI staff and all other current and former active Participants of the ETSI SmartM2M group for their support, technical input and suggestions that led to improvements to this ontology.

Also, special thanks goes to the ETSI SmartM2M Technical Officer Guillemin Patrick.