NOTE: The text in this section is extracted from ETSI TS 103 264 (V4.1.1) [0], and therefore falls inside the ETSI IPR Policy

NOTE: The text in this section is extracted from ETSI TS 103 264 (V3.2.1) [0], and therefore falls inside the ETSI IPR Policy

The Smart Applications REFerence ontology (SAREF) is intended to enable interoperability between solutions from different providers and among various activity sectors from 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 ontology engineering 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, maintainability to facilitate the process of identifying and correcting defects, accommodate new requirements, and cope with changes in (parts of) SAREF. In addition, a principle of generic versus specific entity distinction ensures that SAREF can be useful both for editors of online catalogues, taxonomies, and vocabularies, and developers of smart applications.

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].

Figure 1: The role of SAREF in the mapping among different assets

NOTE 1: Bluetooth® Low Energy, Matter™, EnOcean® are examples of suitable products available commercially. This information is given for the convenience of users of the present document and does not constitute an endorsement by ETSI of these products.

NOTE 2: EnOcean®, EnOcean Alliance logo, EnOcean Alliance technology and promoter/member logo are registered trademarks of EnOcean GmbH and EnOcean Alliance Inc. All other product or service names are the property of their respective owners.

NOTE: The text in this section is extracted from ETSI TS 103 264 (V3.2.1) [0], and therefore falls inside the ETSI IPR Policy

General Overview

Main classes and properties of SAREF Core

SAREF is designed to model both generic and specific entities.

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

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

Figure 3: Overview of the main classes and properties of SAREF Core

NOTE: Classes represented in yellow should be instantiated only in taxonomies, vocabularies, and catalogues.
Classes represented in blue should be instantiated only in smart applications.
Classes represented in light grey can be instantiated in either type of usage of SAREF.
An instance of any class from which originates the red lines can be linked to an instance of any class where the red lines end.

Classes and properties for generic entities

SAREF provides a standardized way to define generic or prototypical entities in taxonomies, vocabularies, and catalogues, ensuring broad semantic interoperability across domains.

Figure 4 shows an overview of the classes and properties for generic entities.

NOTE: Classes represented in yellow should be instantiated only in taxonomies, vocabularies, and catalogues.
An instance of any class from which originates the red lines can be linked to an instance of any class where the red lines end.

Classes and properties for specific entities

SAREF also enables the description of real-world specific entities within smart applications, ensuring precise and context-aware implementation.

Figure 5 shows an overview of the classes and properties for specific entities.

NOTE: Classes represented in blue should be instantiated only in smart applications.
An instance of any class from which originates the red lines can be linked to an instance of any class where the red lines end.

Relation to other documents

ETSI EN 303 760 [1] provides guidelines to apply, extend, and contribute to the evolution of SAREF Core. The SAREF Communication framework as defined in ETSI TS 103 267 [3]. SAREF Core development conforms to ETSI TS 103 673 [4]. SAREF Core reuses and extends SAREF Reference ontology patterns as specified in ETSI TS 103 548 [5].

Device kinds and devices

Figure 6 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 [5].

NOTE 1: SAREF V4.1.1 introduced the class saref:DeviceKind for the prototypical description of devices that can populate online taxonomies, vocabularies, and catalogues. Considering saref:Device was mostly instantiated for smart applications, it was decided to keep this identifier for the specific class (instead of introducing some class like "DeviceOfInterest"), and introduce saref:DeviceKind.

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.

EXAMPLE 1: Examples of devices are a light switch, a temperature sensor, an energy meter, a water flow meter, and a laundry dryer. A laundry dryer is designed to dry laundry, and to accomplish this task it has a start/stop function.

EXAMPLE 2:

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 .

EXAMPLE 3:

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, see [5]) and features of interest (saref:FeatureOfInterest).

Class saref:DeviceKind allows to describe kinds of devices, with common properties and common states having the same value, and with common functions and services. Devices kinds may be used to describe models of devices in online catalogues.

A device can be linked to its device kinds using OP saref:hasDeviceKind.

EXAMPLE 4:

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

A device can target (OP saref:targets) features, properties, or states. SAREF Core defines different sub properties of saref:targets:

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

NOTE 2: Property saref:targets also applies to functions, commands, and procedure executions.

EXAMPLE 5:

s4abcd:AAHeatPumpDryer a saref:DeviceKind ;
    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 and measure 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 additionally do some computation and/or display one or more properties or states of one or more features of interest.

The manufacturer and model of a saref:DeviceKind or a saref:Device can be statedd using DPs saref:hasManufacturer and saref:hasModel, respectively.

EXAMPLE 6:

ex:Meter4837QW123 a saref:Device ;
    saref:hasManufacturer "ABC"@en ;
    saref:hasModel "4837QW123"@en .

Feature kinds and features of interest

Figure 7 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 [5].

NOTE 1: Class saref:FeatureKind has been introduced in SAREF V3.2.1 for the prototypical description of features of interest that can populate online taxonomies, vocabularies, and catalogues.

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.

EXAMPLE 1:

<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:Device is a subclass of saref:FeatureOfInterest.

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

EXAMPLE 2:

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

Class saref:DeviceKind is a subclass of saref:FeatureKind.

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

EXAMPLE 3:

<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. OP saref:hasDeviceKind is a sub-property of OP saref:hasFeatureKind.

EXAMPLE 4:

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

NOTE: Feature of interest inherit broader feature kinds.

saref:hasFeatureKind o skos:broader ⊑ saref:hasFeatureKind

EXAMPLE 5:

<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 feature kinds or features of interest).

EXAMPLE 6:

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

EXAMPLE 7:

<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 [5] to specify if a saref:FeatureKind or 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.

EXAMPLE 8:

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

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 [5], and illustrated on Figure 8.

Figure 8: Taxonomy of tasks, grouped by categories

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

EXAMPLE 1: Example of tasks are cleaning, drying, and lighting.

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.

EXAMPLE 2:

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

EXAMPLE 3:

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

NOTE 1: Property saref:accomplishes can also apply to other classes such as functions, commands, and procedure executions.

NOTE 2: External ontologies can be used to further describe tasks.

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 [5], and illustrated on Figure 9.

Figure 9: Taxonomy of commodities, grouped by categories

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

NOTE: Concepts from existing code lists, vocabularies, and taxonomies, may be used as instances of saref:Commodity, for example from the ISDA taxonomy of commodities [i.23], the Standard International Energy product Classification (SIEC) [i.24], the IRENA Energy Taxonomy [i.25] or Wikidata [i.26].

EXAMPLE 1:

ex:Electricity a ex:EnergyCommodity ;
  rdfs:label "Electricity"@en ;
  rdfs:comment "The electricity energy commodity."@en ;
  rdfs:isDefinedBy "The IDSA taxonomy of energy commodities" .

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.

EXAMPLE 2:

s4abcd:AAHeatPumpDryer a saref:FeatureKind ;
  saref:consumes ex:Electricity ;
  saref:produces <http://www.wikidata.org/entity/Q7892> .

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.

NOTE: SAREF V3.2.1 introduced the class saref:PropertyOfInterest for identifying the association between a feature of interest and a property in some smart application. Considering saref:Property was mostly instantiated in online taxonomies and vocabularies, it was decided to keep this identifier for the generic class (instead of introducing some class like "PropertyKind"), and introduce saref:PropertyOfInterest.

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 [5].

Properties

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

EXAMPLE 1: Air temperature, pressure, luminosity, etc. are all properties.

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:Luminosity a saref:Property ;
    rdfs:label "Temperature"@en ;
    rdfs:comment "The luminosity property kind."@en .

NOTE 1: Until SAREF V3.1.1 [i.7], there was an ambiguity between whether properties should be specific or generic to features of interest. This ambiguity has been solved in SAREF V3.2.1 [i.8], and the new modelling choice has been enforced in SAREF V4.1.1 [0].

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

NOTE 2: Concepts from existing code lists, vocabularies, and taxonomies, may be used as instances of saref:Property..

EXAMPLE 2: Two examples using the QUDT Quantity Kind vocabulary [i.27], and the British Oceanographic Data Centre Parameter Usage Vocabulary [i.30]..

<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.

EXAMPLE 3:

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

NOTE 3: Feature kinds inherit the properties of their broader feature kinds.

skos:broader o saref:hasProperty ⊑ saref:hasProperty

NOTE 4: Features of interest inherit the properties of their feature kinds.

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.

EXAMPLE 1: The air temperature of the atmosphere sample at a certain location and altitude, the received signal strength indicator of a wireless IoT connection, the luminosity of the ETSI ATHENA amphitheatre.

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 entities.

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".

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

EXAMPLE 2: The luminosity of the ETSI ATHENA amphitheatre belongs to the ETSI ATHENA amphitheatre.

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

NOTE 2: Properties of interest inherit broader properties.

saref:hasPropertyKind o skos:broader ⊑ saref:hasPropertyKind

NOTE 3: Features of interest inherit the property kinds of their properties of interest.

saref:hasPropertyOfInterest o saref:hasPropertyKind ⊑ saref:hasProperty

EXAMPLE 3: The ETSI ATHENA amphitheatre has a property luminosity.

<etsi_premises/athena> a saref:FeatureOfInterest ;
  saref:hasPropertyOfInterest <etsi_premises/athena#luminosity> ;
  saref:hasProperty saref:Luminosity .

Property Values

Class saref:PropertyValue describes the value for a property. The property value is optionally 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).

EXAMPLE 1:

[] a saref:PropertyValue ;
  saref:hasValue 22.7 ;
  saref:isMeasuredIn <https://qudt.org/2.1/vocab/unit/DEG_C> .

EXAMPLE 2:

[] a saref:PropertyValue ;
  a <http://www.ontology-of-units-of-measure.org/resource/om-2/Temperature> ;
  saref:hasValue 22.7 ;
  saref:isMeasuredIn <http://www.ontology-of-units-of-  measure.org/resource/om-2/degreeCelsius> .

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

Concepts from existing code lists, vocabularies, and taxonomies, may be used as instances of saref:UnitOfMeasure. For example the QUDT Unit vocabulary [i.28] or the OM vocabulary [i.29].

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

EXAMPLE 2:

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

NOTE 2: The property values are inherited in the hierarchy of feature kinds. This enables to incrementally construct prototypical descriptions of features of interest.

skos:broader saref:hasPropertyValue ⊑ saref:hasPropertyValue

NOTE 3: A feature of interest does not inherit the property values of its kinds. There may be multiple reasons why the property value of a feature of interest is different from that of its prototypical descriptions. For example, it may be caused by a defect, a deterioration, or a customization.

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

EXAMPLE 4:

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

NOTE 4: A property value about a property of interest is also a property value of its property kinds.

saref:isValueOfProperty o saref:hasPropertyKind ⊑ saref:isValueOfProperty

NOTE 5: saref:hasPropertyValue and saref:isValueOfProperty are not inverse properties.

States, states of interest, and state values

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. State values describe the value for a state.

NOTE 1: SAREF V3.2.1 introduced the class saref:StateOfInterest for identifying the association between a feature of interest and a state in some smart application. Considering saref:State was mostly instantiated in online taxonomies and vocabularies, it was decided to keep this identifier for the generic class (instead of introducing some class like "StateKind"), and introduce saref:StateOfInterest.

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

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

NOTE 2: States and Properties are parallel, distinct, but not disjoint. Users can chose whichever seems to best fit their needs. Clause 5.14 discusses Composite Properties, that help to combine properties, states and features of interest in one composite property.

States

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

EXAMPLE 1: A switch can be found in the saref:OnOffState.

ex:OnOffState a saref:State .

ex:Switch a saref:FeatureKind ;
  saref:hasState ex:OnOffState .

SAREF is not restricted to binary states such as the ex:OnOffState, but allows to define also enumerated states.

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

NOTE 2: Concepts from existing code lists, vocabularies, and taxonomies, may be used as instances of saref:State.

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

EXAMPLE 2:

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 .

NOTE 3: Feature kinds inherit the states of their broader feature kinds.

skos:broader o saref:hasState ⊑ saref:hasState

NOTE 4: Features of interest inherit the states of their feature kinds.

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.

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

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 state of interest should not contain "state".

EXAMPLE 1: Switch has two up/down states of interest.

<switch_sdf5ze4fz3> a saref:Device ;
    saref:hasDeviceKind s4abcd:TwoButtonsOneWaySwitch ; 
    saref:hasStateOfInterest <switch_sdf5ze4fz3#btn1> ;
    saref:hasStateOfInterest <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.

NOTE 2: States of interest inherit broader states.

saref:hasStateKind o skos:broader ⊑ saref:hasStateKind

NOTE 3: Features of interest inherit the state kinds of their states of interest.

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:

State Values

Class saref:StateValue describes the value for a state. The state value is optionally linked the states or states of interest it is a value of (OP saref:isValueOfState).

EXAMPLE 1:

saref:OnState a saref:StateValue ; 
  saref:isValueOfState saref:OnOffState .
saref:OffState a saref:StateValue ;
  saref:isValueOfState saref:OnOffState.

The OP saref:hasStateValue links a feature kind, a feature of interest, or a state of interest, to a state value.

EXAMPLE 2:

<switch_sdf5ze4fz3#btn1> a saref:StateOfInterest ;
  saref:isStateOf <switch_sdf5ze4fz3> ;
  saref:hasStateValue saref:OnState .

NOTE 1: The state values are inherited in the hierarchy of feature kinds. This enables to incrementally construct prototypical descriptions of features of interest.

skos:broader saref:hasStateValue ⊑ saref:hasStateValue

NOTE 2: A feature of interest does not inherit the state values of its kinds. There may be multiple reasons why the state value of a feature of interest is different from that of its prototypical descriptions. For example, it may be caused by a defect, a deterioration, or a customization.

The OP saref:isValueOfState links a state value to the states and states of interest it is a value of.

NOTE 3: A state value about a state of interest is also a state value of its state kinds.

saref:isValueOfState o saref:hasStateKind ⊑ saref:isValueOfState

NOTE 4: saref:hasStateValue and saref:isValueOfState are not inverse properties.

Functions and functions of interest

Introduction

In SAREF, functions are logical groups of commands that devices support to accomplish their tasks. Function can target (OP saref:targets 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.

NOTE: SAREF V3.2.1 introduced the class saref:FunctionOfInterest for specifying which command is actually exposed, and which actual property of interest or state of interest it targets. Considering saref:Function was mostly instantiated in online taxonomies and vocabularies, it was decided to keep this identifier for the generic class (instead of introducing some class like "FunctionKind"), and introduce saref:FunctionOfInterest.

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 [5].

Functions

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

EXAMPLE 1: To accomplish the task of controlling the light, a smart light switch may have a function for turning on and off the light, and another to set the luminosity of the light.

EXAMPLE 2: To accomplish the task of sensing the temperature, a temperature sensor should have a sensing function.

EXAMPLE 3: To accomplish the task of washing clothes, a washing machine should have a function for washing.

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

NOTE 1: Concepts from existing code lists, vocabularies, and taxonomies, may be used as instances of saref:Function.

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

EXAMPLE 4:

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

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

NOTE 2: Device kinds inherit the functions of their broader device kinds.

skos:broader o saref:hasFunction ⊑ saref:hasFunction

NOTE 3: Devices inherit the functions of their device kinds.

saref:hasDeviceKind o saref:hasFunction ⊑ saref:hasFunction

NOTE 4: No just devices can have functions. OP saref:hasFunction can link other entities to functions. For example, software applications may have functions.

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 functions of interest. Its inverse is saref:isFunctionOfInterestOf and is functional.

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

NOTE 1: Functions of interest need not always be explicited. It depends on the use case. Typically, functions of interest are useful to specify which command is actually exposed, and which actual property of interest or state of interest it targets.

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

NOTE 2: Functions of interest inherit broader functions.

saref:hasFunctionKind o skos:broader ⊑ saref:hasFunctionKind

NOTE 3: Devices inherit the function kinds of their functions of interest.

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 target (OP saref:targets 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.

NOTE: SAREF V3.2.1 introduced the class saref:CommandOfInterest for specifying which actual property of interest or state of interest it targets. Considering saref:Command was mostly instantiated in online taxonomies and vocabularies, it was decided to keep this identifier for the generic class (instead of introducing some class like "CommandKind"), and introduce saref:CommandOfInterest.

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 [5].

Commands

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

EXAMPLE 1: Observe property, control property, observe state, control state, invoke action, cancel action, turn on or off, change colour, subscribe, publish, etc. are all commands.

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

NOTE 1: Functions inherit the mandatory commands of their broader functions.

skos:broader o saref:hasMandatoryCommand ⊑ saref:hasMandatoryCommand

NOTE 2: Functions of interest inherit the mandatory commands of their function kinds.

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.

EXAMPLE 2: Different complementary commands can be defined for controlling a light. Turn on or off the light based on a desired state value, toggle the light status of a specific light, set the luminosity level with a transition time, set the default transition time.

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

EXAMPLE 3: Different complementary commands can be defined for observing a smart home. Observe the temperature will output the indoor temperature property value; observe status of the entry door will output an open/close state.

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

Commands of Interest

A saref:CommandOfInterest is a directive 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 target.

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.

NOTE 1: Commands of interest need not always be explicited. It depends on the use case. Typically, commands of interest are useful to specify the actual property of interest or state of interest that is expected as input parameter, output, or that will be observed or controlled.

EXAMPLE 1: The corridor smart light switch supports a command of kind "turn on/off", which controls the state of the outdoor light.

EXAMPLE 2: The smart fridge supports a command of kind "observes temperature", which observes the temperature inside the fridge.

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

NOTE 2: Commands of interest inherit broader commands.

saref:hasCommandKind o skos:broader ⊑ saref:hasCommandKind

NOTE 3: Devices inherit the commands of their commands of interest.

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.

NOTE 1: Typically, a device connected to a given network offers one service for each of its functions of interest.

EXAMPLE 1: A light switch can offer the service of remotely switching the lights in a home through mobile phone devices that are connected to the local network (ex:SwitchOnService class). This "remote switching" service represents the ex:OnOffFunction.

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.

EXAMPLE 2: To turn on a light, send a CoAP PUT request with CBOR content `0xf5` (true).

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.

NOTE 2: Typically, a device connected to a given network offers one service for each of its functions of interest, and each service has one operation per command of interest of the function of interest it represents.

EXAMPLE 3: In the set of operations exposed by a smart light bulb on a given network, one may be dedicated to turn on and off the light and expect a boolean as input. Another one may be dedicated to set the luminosity status and expect a target luminosity level (a byte) and a transition time (encoded on two bytes).

EXAMPLE 4: In the set of operations exposed by a smart washing machine on a given network, one may be dedicated to set the water temperature for the washing cycle, and expected as input an enumerated value. Another one may be dedicated to start, pause, or stop the washing cycle.

NOTE 3: The concept of service is further elaborated in the oneM2M Base Ontology [1], to which the reader is referred in order to model the details of a service that are out of the scope of SAREF.

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.

EXAMPLE 1: The observation of the temperature in a room made by a temperature sensor.

OP saref:madeBy can link a procedure execution to any entity, not necessarily a tangible device.

EXAMPLE 2: The prediction of the temperature in a room made by a software application.

EXAMPLE 3: A manual measurement of the circumference of a branch of a tree made by a person.

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:hasStartTime links a procedure execution to the instant of time when it was initiated or tasked, expressed as an xsd:dateTime literal.

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 [8].

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 target (OP saref:targets) 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.

EXAMPLE 1: A CoAP PUT request with CBOR content `0xf5` (true), a CoAP response with code `2.04` (Changed).

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.

NOTE 1: If a command execution is an execution of a command, it is also the execution of its broader commands.

saref:isExecutionOf o skos:broader ⊑ saref:isExecutionOf

NOTE 2: If a command execution is an execution of a command of interest, it is also the execution of the command kind of that command of interest.

saref:isExecutionOf o saref:hasCommandKind ⊑ saref:isExecutionOf

Observations and Actuations

Figure 17 illustrates the main classes and properties for describing observations 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 value. An observation of a state (OP saref:observes) should have a state value as a result (OP saref:hasResult). Respectively, an observation of a property should have a property value as a result.

EXAMPLE 1:

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 .

EXAMPLE 2:

[] a saref:Observation ;
    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 .

NOTE 1: saref:Observation is more general than saref:Measurement, as it applies to states in addition to properties. The indirection saref:hasResult to a property value improves its semantic correctness. It also improves the alignment with the OGC® and W3C® SOSA/SSN ontology [7]. Therefore, saref:Measurement has been deprecated in version V3.2.1 [i.8], and has been deleted in the present document [0].

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 or state value. An actuation of a state (OP saref:controls) should have a state value as input (OP saref:hasInput). Respectively, an actuation of a property should have a property value as input.

NOTE 2: An observation or an actuation may also be a command execution, if it corresponds to the execution of a directives a device supports and exposes to some network. However, an observation or an actuation should not be an operation execution, as these are intended to be machine interpretable descriptions of network communications.

NOTE 3: It is acceptable that the inputs or results of a command execution are observations or actuations. For example: - A command execution to aggregate observations will have these observations as input. - A command execution to retrieve the past five observations will have these observations as output. - A command execution to plan a series of actuations will have these actuations as input, and potentially also as result if successful.

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:consumes, saref:produces, or saref:stores, and optionally to some property or state using OP saref:targets or its sub-properties.

EXAMPLE 1:

ex:Device_1 a saref:Device ;
    saref:consumes 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 [8].

NOTE: saref:hasApplicableTime may be applied to other entities, such as functions, commands, or procedure executions.

EXAMPLE 2:

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

EXAMPLE 3:

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).

EXAMPLE 4:

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

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

EXAMPLE 5:

ex:FlexibilityProfile
saref:whenState [
  a saref:StateValue ;
  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.

EXAMPLE 6:

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.9]. 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.

EXAMPLE 7:

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 [9], 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 [9], section 6.4.

EXAMPLE 1:

<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) [9], section 7.

EXAMPLE 2:

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

Composite Properties and Property Values

The OP saref:consistsOf can link a composite property, property of interest, or property value to its individual components.

NOTE 1: A feature kind or feature of interest has the individual components of its composite properties.

saref:hasProperty o saref:consistsOf ⊑ saref:hasProperty

Composite Properties can consist of feature kinds, properties, and states. Figure 19 illustrates the local restrictions of saref:consistsOf on the class saref:Property.

Figure 19: Local restrictions of saref:consistsOf on the class of Properties

EXAMPLE 1: A 2D position property observed by a position sensor consists of x and y coordinates.

s4abcd:2DPosition_xCoordinate a saref:Property .
s4abcd:2DPosition_yCoordinate a saref:Property .
s4abcd:2DPosition a saref:Property ;
  saref:consistsOf s4abcd:2DPosition_xCoordinate ;
  saref:consistsOf s4abcd:2DPosition_yCoordinate .

EXAMPLE 2: A composite presence property observed by a smart presence sensor consists of persons, an occupied/not occupied state, and a temperature property.

ex:Person a saref:FeatureKind .
s4abcd:OccupiedOrNotOccupied a saref:State .
s4abcd:Temperature a saref:Property .
s4abcd:CompositePresence a saref:Property ;
    saref:consistsOf ex:Person ;
    saref:consistsOf s4abcd:OccupiedOrNotOccupied ;
    saref:consistsOf s4abcd:Temperature .

In addition, properties of interest can be composed of features of interest, properties of interest and states of interest. Figure 20 illustrates the local restrictions of saref:consistsOf on the class saref:PropertyOfInterest.

Figure 20: Local restrictions of saref:consistsOf on the class of Properties of Interest

NOTE 2: When composed of a property of interest, a property of interest is also composed of the kinds of this property of interest.

saref:consistsOf o saref:hasPropertyKind ⊑ saref:consistsOf

NOTE 3: When composed of a state of interest, a property of interest is also composed of the kinds of this state of interest.

saref:consistsOf o saref:hasStateKind ⊑ saref:consistsOf

In addition, property values can be composed of property values, and state values. Figure 21 illustrates the local restrictions of saref:consistsOf on the class saref:PropertyValue.

Figure 21: Local restrictions of saref:consistsOf on the class of Property Values

EXAMPLE 4: A 2D position value as the result of the observation made by a position sensor.

<position_sensor> a s4abcd:PositionSensor ;
  saref:madeExecution <observation> .
<observation> a saref:Observation ;
  saref:observes s4abcd:2DPosition, <room> ;
  saref:hasResult <value> .
<value> a saref:PropertyValue ;
  saref:consistsOf <value_x> , <value_y> .
<value_x> a saref:PropertyValue ;
  saref:isValueOfProperty s4abcd:2DPosition_xCoordinate ;
  saref:hasValue 2 .
<value_y> a saref:PropertyValue ;
  saref:isValueOfProperty s4abcd:2DPosition_yCoordinate ;
  saref:hasValue 3 .

EXAMPLE 5: A composite presence value as the result of the observation made by a smart presence sensor.

<smart_camera> a s4abcd:SmartPresenceSensor ;
    saref:madeExecution <observation> .
<observation> a saref:Observation ;
  saref:observes s4abcd:CompositePresence, <room> ;
  saref:hasResult <composite_presence_value> .
<composite_presence_value> a saref:PropertyValue ;
    saref:consistsOf <person1>, <person2> ;
    saref:consistsOf s4abcd:Occupied ;
    saref:consistsOf <temperature_value> .
s4abcd:Occupied a saref:StateValue ;
    saref:isValueOfState s4abcd:OccupiedOrNotOccupied .
<temperature_value> a saref:PropertyValue ;
    saref:hasValue 22.7 ;
    saref:isMeasuredIn <https://qudt.org/2.1/vocab/unit/DEG_C> .

NOTE 4: When composed of a property value, a property value is also composed of that value's property.

saref:consistsOf o saref:isValueOfProperty ⊑ saref:consistsOf

NOTE 5: When composed of a state value, a property value is also composed of that value's state.

saref:consistsOf o saref:isValueOfState ⊑ saref:consistsOf

NOTE 6: When composed of a feature of interest, a property value is also composed of the kind of that feature of interest.

saref:consistsOf o saref:hasFeatureKind ⊑ saref:consistsOf

Ontology Reference

Classes

saref:Actuation
saref:Actuator
saref:Appliance
saref:Command
saref:CommandExecution
saref:CommandOfInterest
saref:Commodity
saref:Device
saref:DeviceKind
saref:FeatureKind
saref:FeatureOfInterest
saref:Function
saref:FunctionOfInterest
saref:Meter
saref:Observation
saref:Operation
saref:OperationExecution
saref:ProcedureExecution
saref:Profile
saref:Property
saref:PropertyOfInterest
saref:PropertyValue
saref:Sensor
saref:Service
saref:State
saref:StateOfInterest
saref:StateValue
saref:Task
saref:UnitOfMeasure

saref:Actuation — Actuation top Classes ToC

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.

has super-classes: saref:madeBy only saref:Actuator
saref:controls min 1
saref:ProcedureExecution

saref:Actuator — Actuator top Classes ToC

A device designed to control one or more properties or states of one or more features of interest.

has super-classes: saref:controls min 1
saref:Device

saref:Appliance — Appliance top Classes ToC

A device designed to accomplish a particular task for occupant use. It consumes, produces, or stores, some commodity.

has super-classes: saref:Device

saref:Command — Command top Classes ToC

The lowest-level directives a function exposes to some network. Commands can target (OP saref:targets and its sub-properties) features, properties, or states. An instance of saref:Command is independent of any device.

has super-classes: skos:broader only saref:Command
skos:narrower only saref:Command
is in domain of: saref:isCommandOf
is in range of: saref:hasCommand
saref:hasCommandKind

saref:CommandExecution — Command Execution top Classes ToC

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).

has super-classes: saref:isExecutionOf only ( saref:Command or saref:CommandOfInterest)
saref:ProcedureExecution

saref:CommandOfInterest — Command Of Interest top Classes ToC

The lowest-level directives a device supports and exposes to some network. Commands can target (OP saref:targets and its sub-properties) features, properties, or states. A saref:CommandOfInterest is a directives actually supported by a device and exposed to some network.

has super-classes: saref:isCommandOfInterestOf exactly 1
is in domain of: saref:hasCommandKind
saref:isCommandOfInterestOf
is in range of: saref:hasCommandOfInterest

saref:Commodity — Commodity top Classes ToC

A marketable item which may be supplied without qualitative differentiation.

has super-classes: skos:broader only saref:Commodity
skos:narrower only saref:Commodity
is in domain of: saref:isConsumedBy
saref:isProducedBy
saref:isStoredBy
is in range of: saref:consumes
saref:produces
saref:stores

saref:Device — Device top Classes ToC

A tangible object designed to accomplish a particular task. In order to accomplish this task, the device performs one or more functions. An instance of saref:Device represents one specific real world entity.

has super-classes: saref:FeatureOfInterest
s4syst:System
has sub-classes: saref:Actuator
saref:Appliance
saref:Meter
saref:Sensor
is in domain of: saref:hasDeviceKind
saref:hasFunctionOfInterest
saref:offers
is in range of: saref:isFunctionOfInterestOf
saref:isOfferedBy

saref:DeviceKind — Device kinds top Classes ToC

Device kinds allow to describe kinds of devices, with common properties and common states having the same value, targeting the same properties and states, common functions, and common services. Devices kinds may be used to describe models of devices in online catalogues.

has super-classes: skos:broader only saref:FeatureKind
skos:narrower only saref:FeatureKind
saref:FeatureKind
is in range of: saref:hasDeviceKind

saref:FeatureKind — Feature kinds top Classes ToC

Feature kinds allow 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.

has super-classes: skos:broader only saref:FeatureKind
skos:narrower only saref:FeatureKind
saref:consistsOf only saref:FeatureKind
has sub-classes: saref:DeviceKind
is in range of: saref:hasFeatureKind

saref:FeatureOfInterest — Feature of interest top Classes ToC

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

has super-classes: saref:consistsOf only saref:FeatureOfInterest
has sub-classes: saref:Device
is in domain of: saref:hasFeatureKind
saref:hasPropertyOfInterest
saref:hasStateOfInterest
saref:madeExecution
is in range of: saref:isPropertyOfInterestOf
saref:isStateOfInterestOf
saref:madeBy

saref:Function — Function top Classes ToC

Logical groups of commands that devices support to accomplish their tasks. Function can target (OP saref:targets and its sub-properties) features, properties, or states. An instance of saref:Function can apply to different devices.

has super-classes: skos:broader only saref:Function
skos:narrower only saref:Function
is in domain of: saref:hasMandatoryCommand
saref:hasOptionalCommand
saref:isFunctionOf
is in range of: saref:hasFunction
saref:hasFunctionKind

saref:FunctionOfInterest — Function of Interest top Classes ToC

has super-classes: saref:isFunctionOfInterestOf exactly 1
is in domain of: saref:hasCommandOfInterest
saref:hasFunctionKind
saref:isFunctionOfInterestOf
is in range of: saref:hasFunctionOfInterest
saref:isCommandOfInterestOf

saref:Meter — Meter top Classes ToC

A device designed to observe and additionally do some computation and/or display one or more properties of one or more features of interest.

has super-classes: saref:observes min 1
saref:Device

saref:Observation — Observation top Classes ToC

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.

has super-classes: saref:madeBy only saref:Sensor
saref:observes min 1
saref:ProcedureExecution

saref:Operation — Operation top Classes ToC

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.

has super-classes: saref:represents only ( saref:Command or saref:CommandOfInterest)
saref:represents min 1 saref:CommandOfInterest
saref:isOperationOf exactly 1
is in domain of: saref:isOperationOf
is in range of: saref:hasOperation

saref:OperationExecution — Operation Execution top Classes ToC

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.

has super-classes: saref:isExecutionOf only saref:Operation
saref:ProcedureExecution

saref:ProcedureExecution — Procedure Execution top Classes ToC

Represents the act of carrying out a procedure.

has sub-classes: saref:Actuation
saref:CommandExecution
saref:Observation
saref:OperationExecution
is in domain of: saref:hasResult
saref:hasResultTime
saref:isExecutionOf
saref:madeBy
is in range of: saref:madeExecution

saref:Profile — Profile top Classes ToC

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.

is in domain of: saref:isProfileOf
saref:profileHasPrice
saref:whenPropertyValue
saref:whenState
is in range of: saref:hasProfile

saref:Property — Property top Classes ToC

Identifiable qualities of features of interest that can be target of devices, such as observed or controlled. A property can apply to different features of interest.

has super-classes: saref:consistsOf only ( saref:FeatureKind or saref:Property or saref:State)
skos:broader only saref:Property
skos:narrower only saref:Property
is in domain of: saref:isPropertyOf
is in range of: saref:hasProperty
saref:hasPropertyKind

saref:PropertyOfInterest — Property of Interest top Classes ToC

Identifiable qualities of features of interest that can be target of devices, such as observed or controlled. An instance of saref:PropertyOfInterest is specific to a feature of interest. It is inherent to and cannot exist without that feature of interest.

has super-classes: saref:isPropertyOfInterestOf exactly 1
saref:consistsOf only ( saref:FeatureKind or saref:Property or saref:State or saref:PropertyOfInterest or saref:StateOfInterest)
is in domain of: saref:hasPropertyKind
saref:isPropertyOfInterestOf
is in range of: saref:hasPropertyOfInterest

saref:PropertyValue — Property Value top Classes ToC

Describes the value for a property. The property value is optionally 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).

has super-classes: saref:hasValue max 1
saref:isMeasuredIn max 1
saref:consistsOf only ( saref:FeatureKind or saref:Property or saref:State or saref:PropertyOfInterest or saref:StateOfInterest or saref:FeatureOfInterest or saref:PropertyValue or saref:StateValue)
is in domain of: saref:isValueOfProperty
is in range of: saref:hasPropertyValue
saref:profileHasPrice
saref:whenPropertyValue

saref:Sensor — Sensor top Classes ToC

A device designed to observe and measure one or more properties or states of one or more features of interest.

has super-classes: saref:observes min 1
saref:Device

saref:Service — Service top Classes ToC

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

has super-classes: saref:represents only ( saref:Function or saref:FunctionOfInterest)
saref:represents min 1 saref:FunctionOfInterest
saref:isOfferedBy exactly 1
is in domain of: saref:hasOperation
saref:isOfferedBy
is in range of: saref:isOperationOf
saref:offers

saref:State — State top Classes ToC

Identifiable conditions that features of interest are or may be in, and that can be target of devices, such as observed and controlled. A state can apply to different features of interest.

has super-classes: skos:broader only saref:State
skos:narrower only saref:State
is in domain of: saref:isStateOf
is in range of: saref:hasState
saref:hasStateKind
saref:whenState

saref:StateOfInterest — State of Interest top Classes ToC

Identifiable conditions that features of interest are or may be in, and that can be target of devices, such as observed and controlled. An instance of saref:StateOfInterest is specific to a feature of interest. It is inherent to and cannot exist without that feature of interest.

has super-classes: saref:isStateOfInterestOf exactly 1
is in domain of: saref:hasStateKind
saref:isStateOfInterestOf
is in range of: saref:hasStateOfInterest

saref:StateValue — State Value top Classes ToC

Describes the value for a state. The state value is optionally linked the states or states of interest it is a value of (OP saref:isValueOfState).

is in domain of: saref:isValueOfState
is in range of: saref:hasStateValue

saref:Task — Task top Classes ToC

The goal for which a device is designed, from a user perspective.

has super-classes: skos:broader only saref:Task
skos:narrower only saref:Task
is in domain of: saref:isAccomplishedBy
is in range of: saref:accomplishes

saref:UnitOfMeasure — Unit of measure top Classes ToC

The unit of measure is a standard for measurement of a quantity, such as a Property.

is in range of: saref:isMeasuredIn

Object Properties

saref:accomplishes
saref:consistsOf
saref:consumes
saref:controls
saref:hasApplicableTime
saref:hasCommand
saref:hasCommandKind
saref:hasCommandOfInterest
saref:hasDeviceKind
saref:hasFeatureKind
saref:hasFunction
saref:hasFunctionKind
saref:hasFunctionOfInterest
saref:hasInput
saref:hasMandatoryCommand
saref:hasOperation
saref:hasOptionalCommand
saref:hasOutput
saref:hasPhenomenonTime
saref:hasProfile
saref:hasProperty
saref:hasPropertyKind
saref:hasPropertyOfInterest
saref:hasPropertyValue
saref:hasResult
saref:hasState
saref:hasStateKind
saref:hasStateOfInterest
saref:hasStateValue
saref:isAccomplishedBy
saref:isCommandOf
saref:isCommandOfInterestOf
saref:isConsumedBy
saref:isControlledBy
saref:isExecutionOf
saref:isFunctionOf
saref:isFunctionOfInterestOf
saref:isMeasuredIn
saref:isObservedBy
saref:isOfferedBy
saref:isOperationOf
saref:isProducedBy
saref:isProfileOf
saref:isPropertyOf
saref:isPropertyOfInterestOf
saref:isStateOf
saref:isStateOfInterestOf
saref:isStoredBy
saref:isTargetOf
saref:isValueOfProperty
saref:isValueOfState
saref:madeBy
saref:madeExecution
saref:observes
saref:offers
saref:produces
saref:profileHasPrice
saref:represents
saref:stores
saref:targets
saref:whenPropertyValue
saref:whenState

saref:accomplishes — accomplishes top Object Properties ToC

Links a certain entity (e.g., a device) to the task it accomplishes.

has range: saref:Task
is inverse of: saref:isAccomplishedBy
saref:isAccomplishedBy

saref:consistsOf — consists of top Object Properties ToC

A relationship indicating a composite entity that consists of other entities (e.g., a temperature/humidity sensor that consists of a temperature sensor and a humidity sensor)

has sub-property chains: ( saref:consistsOf o saref:hasPropertyKind)
( saref:consistsOf o saref:hasStateKind)
( saref:consistsOf o saref:isValueOfProperty)
( saref:consistsOf o saref:isValueOfState)
( saref:consistsOf o saref:hasFeatureKind)

saref:consumes — consumes top Object Properties ToC

Links a feature kind, feature of interest, or device, to the commodity it consumes

has domain: saref:FeatureKind or saref:FeatureOfInterest or saref:DeviceKind or saref:Device
has range: saref:Commodity
is inverse of: saref:isConsumedBy
saref:isConsumedBy

saref:controls — controls top Object Properties ToC

Links a device, function, command, or procedure execution, to the feature, property, or state, it controls.

has super-properties: saref:targets
has domain: saref:DeviceKind or saref:Actuator or saref:Function or saref:FunctionOfInterest or saref:Command or saref:CommandOfInterest or saref:Actuation
is inverse of: saref:isControlledBy
saref:isControlledBy

saref:hasApplicableTime — has applicable time top Object Properties ToC

Links an entity (e.g., a profile) to an instant or interval or other compound temporal entity expressed using OWL Time, which bounds temporally the applicable context of that entity.

has range: time:TemporalEntity or time:TemporalPosition

saref:hasCommand — has command top Object Properties ToC

Links a function or function of interest and the command it supports.

has sub-properties: saref:hasMandatoryCommand
saref:hasOptionalCommand
has domain: saref:Function or saref:FunctionOfInterest
has range: saref:Command
is inverse of: saref:isCommandOf
saref:isCommandOf
has sub-property chains: ( saref:hasFeatureKind o saref:hasMandatoryCommand)
( saref:hasCommandOfInterest o saref:hasCommandKind)

saref:hasCommandKind — has command kind top Object Properties ToC

links a command of interest to its kind, a command.

has domain: saref:CommandOfInterest
has range: saref:Command
has sub-property chains: ( saref:hasCommandKind o skos:broader)

saref:hasCommandOfInterest — has command of interest top Object Properties ToC

Links a function of interest to one of its commands of interest.

has domain: saref:FunctionOfInterest
has range: saref:CommandOfInterest
is inverse of: saref:isCommandOfInterestOf
saref:isCommandOfInterestOf

saref:hasDeviceKind — has device kind top Object Properties ToC

Links a device to its kind, a device kind. Kinds of devices describe models of devices, with common properties and common states having the same value, targeting the same properties and states, common functions, and common services.

has super-properties: saref:hasFeatureKind
has domain: saref:Device
has range: saref:DeviceKind

saref:hasFeatureKind — has feature kind top Object Properties ToC

links a feature of interest to its kind, a feature kind

has sub-properties: saref:hasDeviceKind
has domain: saref:FeatureOfInterest
has range: saref:FeatureKind
has sub-property chains: ( saref:hasFeatureKind o skos:broader)

saref:hasFunction — has function top Object Properties ToC

Links a feature kind or a device to one of its functions.

has domain: saref:FeatureKind or saref:FeatureOfInterest
has range: saref:Function
is inverse of: saref:isFunctionOf
saref:isFunctionOf
has sub-property chains: ( skos:broader o saref:hasFunction)
( saref:hasDeviceKind o saref:hasFunction)
( saref:hasFunctionOfInterest o saref:hasFunctionKind)

saref:hasFunctionKind — has function kind top Object Properties ToC

links a function of interest to its kind, a function

has domain: saref:FunctionOfInterest
has range: saref:Function
has sub-property chains: ( saref:hasFunctionKind o skos:broader)

saref:hasFunctionOfInterest — has function of interest top Object Properties ToC

Links a device to one of its functions of interest.

has domain: saref:Device
has range: saref:FunctionOfInterest
is inverse of: saref:isFunctionOfInterestOf
saref:isFunctionOfInterestOf

saref:hasInput — has input top Object Properties ToC

Links a command, operation, or procedure execution, to its inputs.

has domain: saref:Command or saref:CommandOfInterest or saref:Operation or saref:ProcedureExecution

saref:hasMandatoryCommand — has mandatory command top Object Properties ToC

Links a function and one of its mandatory commands

has super-properties: saref:hasCommand
has domain: saref:Function
has sub-property chains: ( skos:broader o saref:hasMandatoryCommand)

saref:hasOperation — has operation top Object Properties ToC

Links a service to one of its operations.

has domain: saref:Service
has range: saref:Operation
is inverse of: saref:isOperationOf
saref:isOperationOf

saref:hasOptionalCommand — has optional command top Object Properties ToC

Links a function and one of its optional commands

has super-properties: saref:hasCommand
has domain: saref:Function

saref:hasOutput — has output top Object Properties ToC

Links a command or operation to its outputs.

has domain: saref:Command or saref:CommandOfInterest or saref:Operation

saref:hasPhenomenonTime — has phenomenon time top Object Properties ToC

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.

has range: time:TemporalEntity

saref:hasProfile — has profile top Object Properties ToC

Links a device to its profile. Its inverse is saref:isProfileOf. The device should be linked to a certain commodity using OP saref:consumes, saref:produces, or saref:stores, and optionally to some property or state using OP saref:targets or its sub-properties.

has domain: saref:DeviceKind or saref:Device
has range: saref:Profile
is inverse of: saref:isProfileOf
saref:isProfileOf

saref:hasProperty — has property top Object Properties ToC

Links a feature kind or a feature of interest to one of its properties.

has domain: saref:FeatureKind or saref:FeatureOfInterest
has range: saref:Property
is inverse of: saref:isPropertyOf
saref:isPropertyOf
has sub-property chains: ( skos:broader o saref:hasProperty)
( saref:hasFeatureKind o saref:hasProperty)
( saref:hasPropertyOfInterest o saref:hasPropertyKind)
( saref:hasProperty o saref:consistsOf)

saref:hasPropertyKind — has property kind top Object Properties ToC

links a property of interest to its kind, a property.

has domain: saref:PropertyOfInterest
has range: saref:Property
has sub-property chains: ( saref:hasPropertyKind o skos:broader)

saref:hasPropertyOfInterest — has property of interest top Object Properties ToC

Links a feature of interest to one of its properties of interest.

has domain: saref:FeatureOfInterest
has range: saref:PropertyOfInterest
is inverse of: saref:isPropertyOfInterestOf
saref:isPropertyOfInterestOf

saref:hasPropertyValue — has property value top Object Properties ToC

Links a feature kind, a feature of interest, or a property of interest, to a property value.

has domain: saref:FeatureKind or saref:FeatureOfInterest or saref:PropertyOfInterest
has range: saref:PropertyValue
has sub-property chains: ( skos:broader o saref:hasPropertyValue)

saref:hasResult — has result top Object Properties ToC

Links a procedure execution (e.g., an observation) to its result (e.g., a property value).

has domain: saref:ProcedureExecution

saref:hasState — has state top Object Properties ToC

Links a feature kind or a feature of interest to one of its states.

has domain: saref:FeatureKind or saref:FeatureOfInterest or saref:StateOfInterest
has range: saref:State
is inverse of: saref:isStateOf
saref:isStateOf
has sub-property chains: ( skos:broader o saref:hasState)
( saref:hasFeatureKind o saref:hasState)
( saref:hasStateOfInterest o saref:hasStateKind)

saref:hasStateKind — has state kind top Object Properties ToC

links a state of interest to its kind, a state

has domain: saref:StateOfInterest
has range: saref:State
has sub-property chains: ( saref:hasStateKind o skos:broader)

saref:hasStateOfInterest — has state of interest top Object Properties ToC

Links a feature of interest to one of its states of interest.

has domain: saref:FeatureOfInterest
has range: saref:StateOfInterest
is inverse of: saref:isStateOfInterestOf
saref:isStateOfInterestOf

saref:hasStateValue — has state value top Object Properties ToC

Links a feature kind, a feature of interest, or a state of interest, to a state value.

has domain: saref:FeatureKind or saref:FeatureOfInterest or saref:StateOfInterest
has range: saref:StateValue
has sub-property chains: ( skos:broader o saref:hasStateValue)

saref:isAccomplishedBy — is accomplished by top Object Properties ToC

A relationship identifying an entity (e.g., a device) that can accomplish a task.

has domain: saref:Task
is inverse of: saref:accomplishes
saref:accomplishes

saref:isCommandOf — is command of top Object Properties ToC

Links a command and a function or function of interest that supports it.

has domain: saref:Command
has range: saref:Function or saref:FunctionOfInterest
is inverse of: saref:hasCommand
saref:hasCommand

saref:isCommandOfInterestOf — is command of interest of top Object Properties ToC

Links a command of interest to the function of interest it is a command of.

has characteristics: functional
has domain: saref:CommandOfInterest
has range: saref:FunctionOfInterest
is inverse of: saref:hasCommandOfInterest
saref:hasCommandOfInterest

saref:isConsumedBy — is consumed by top Object Properties ToC

Links a commodity to the feature kind, feature of interest, or device, that consumes it

has domain: saref:Commodity
has range: saref:FeatureKind or saref:FeatureOfInterest or saref:DeviceKind or saref:Device
is inverse of: saref:consumes
saref:consumes

saref:isControlledBy — is controlled by top Object Properties ToC

Links a feature, property, or state, to the device, function, command, or procedure execution, that controls it.

has super-properties: saref:isTargetOf
is inverse of: saref:controls
saref:controls

saref:isExecutionOf — is execution of top Object Properties ToC

Links a command execution to the command or command of interest that was executed. Also liks an operation execution to the operation that was executed

has domain: saref:ProcedureExecution
has range: saref:Command or saref:CommandOfInterest or saref:Operation
has sub-property chains: ( saref:isExecutionOf o skos:broader)
( saref:isExecutionOf o saref:hasCommandKind)

saref:isFunctionOf — is function of top Object Properties ToC

Links a function to the feature kind or device it is a function of.

has domain: saref:Function
has range: saref:FeatureKind or saref:FeatureOfInterest
is inverse of: saref:hasFunction
saref:hasFunction

saref:isFunctionOfInterestOf — is function of interest of top Object Properties ToC

Links a function of interest to the device it is a function of.

has characteristics: functional
has domain: saref:FunctionOfInterest
has range: saref:Device
is inverse of: saref:hasFunctionOfInterest
saref:hasFunctionOfInterest

saref:isMeasuredIn — is measured in top Object Properties ToC

A relationship identifying the unit of measure used for a certain entity.

has range: saref:UnitOfMeasure

saref:isObservedBy — is observed by top Object Properties ToC

Links a feature, property, or state, to the device, function, command, or procedure execution, that observes it.

has super-properties: saref:isTargetOf
is inverse of: saref:observes
saref:observes

saref:isOfferedBy — is offered by top Object Properties ToC

Links a service to the device that exposes it to a network

has characteristics: functional
has domain: saref:Service
has range: saref:Device
is inverse of: saref:offers
saref:offers

saref:isOperationOf — is operation of top Object Properties ToC

Links an operation to the service it belongs to.

has characteristics: functional
has domain: saref:Operation
has range: saref:Service
is inverse of: saref:hasOperation
saref:hasOperation

saref:isProducedBy — is produced by top Object Properties ToC

Links a commodity to the feature kind, feature of interest, or device, that produces it

has domain: saref:Commodity
has range: saref:FeatureKind or saref:FeatureOfInterest or saref:DeviceKind or saref:Device
is inverse of: saref:produces
saref:produces

saref:isProfileOf — is profile of top Object Properties ToC

Links a profile to the device it describes. The device should be linked to a certain commodity using OP saref:consumes, saref:produces, or saref:stores, and optionally to some property or state using OP saref:targets or its sub-properties.

has domain: saref:Profile
has range: saref:DeviceKind or saref:Device
is inverse of: saref:hasProfile
saref:hasProfile

saref:isPropertyOf — is property of top Object Properties ToC

Links a property to the feature kind or feature of interest it is a property of.

has domain: saref:Property
has range: saref:FeatureKind or saref:FeatureOfInterest
is inverse of: saref:hasProperty
saref:hasProperty

saref:isPropertyOfInterestOf — is property of interest of top Object Properties ToC

Links a property of interest to the feature of interest it is a property of.

has characteristics: functional
has domain: saref:PropertyOfInterest
has range: saref:FeatureOfInterest
is inverse of: saref:hasPropertyOfInterest
saref:hasPropertyOfInterest

saref:isStateOf — is state of top Object Properties ToC

Links a state to the feature kind or feature of interest it is a state of.

has domain: saref:State
has range: saref:FeatureKind or saref:FeatureOfInterest
is inverse of: saref:hasState
saref:hasState

saref:isStateOfInterestOf — is state of interest of top Object Properties ToC

Links a state of interest to the feature of interest it is a state of.

has characteristics: functional
has domain: saref:StateOfInterest
has range: saref:FeatureOfInterest
is inverse of: saref:hasStateOfInterest
saref:hasStateOfInterest

saref:isStoredBy — is stored by top Object Properties ToC

Links a commodity to the feature kind, feature of interest, or device, that stores it

has domain: saref:Commodity
has range: saref:FeatureKind or saref:FeatureOfInterest or saref:DeviceKind or saref:Device
is inverse of: saref:stores
saref:stores

saref:isTargetOf — is target of top Object Properties ToC

Links a feature, property, or state, to the device, function, command, or procedure execution, that targets it.

has sub-properties: saref:isControlledBy
saref:isObservedBy
has domain: saref:FeatureKind or saref:FeatureOfInterest or saref:Property or saref:PropertyOfInterest or saref:State or saref:StateOfInterest
has range: saref:DeviceKind or saref:Device or saref:Function or saref:FunctionOfInterest or saref:Command or saref:CommandOfInterest or saref:ProcedureExecution
is inverse of: saref:targets

saref:isValueOfProperty — is value of property top Object Properties ToC

Links a property value to the property or property of interest it is a value of.

has domain: saref:PropertyValue
has range: saref:FeatureKind or saref:FeatureOfInterest or saref:Property or saref:PropertyOfInterest
has sub-property chains: ( saref:isValueOfProperty o saref:hasPropertyKind)

saref:isValueOfState — is value of state top Object Properties ToC

Links a state value to the state or state of interest it is a value of.

has domain: saref:StateValue
has range: saref:FeatureKind or saref:FeatureOfInterest or saref:StateOfInterest
has sub-property chains: ( saref:isValueOfState o saref:hasStateKind)

saref:madeBy — made by top Object Properties ToC

Links a procedure execution to the entity (e.g., device) that made it.

has domain: saref:ProcedureExecution
has range: saref:FeatureOfInterest
is inverse of: saref:madeExecution
saref:madeExecution

saref:madeExecution — made execution top Object Properties ToC

Links an entity (e.g., device) to the procedure execution it made.

has domain: saref:FeatureOfInterest
has range: saref:ProcedureExecution
is inverse of: saref:madeBy
saref:madeBy

saref:observes — observes top Object Properties ToC

Links a device, function, command, or procedure execution, to the feature, property, or state, it observes.

has super-properties: saref:targets
has domain: saref:DeviceKind or saref:Sensor or saref:Function or saref:FunctionOfInterest or saref:Command or saref:CommandOfInterest or saref:Observation
is inverse of: saref:isObservedBy
saref:isObservedBy

saref:offers — offers top Object Properties ToC

Links a device to a service it exposes to a network.

has domain: saref:Device
has range: saref:Service
is inverse of: saref:isOfferedBy
saref:isOfferedBy

saref:produces — produces top Object Properties ToC

Links a feature kind, feature of interest, or device, to the commodity it produces

has domain: saref:FeatureKind or saref:FeatureOfInterest or saref:DeviceKind or saref:Device
has range: saref:Commodity
is inverse of: saref:isProducedBy
saref:isProducedBy

saref:profileHasPrice — has price top Object Properties ToC

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

has domain: saref:Profile
has range: saref:PropertyValue

saref:represents — represents top Object Properties ToC

Links a service to some function or function of interest it exposes to the network. Also links an operation to some command or command of interest it exposes to the network.

has domain: saref:Service or saref:Operation
has range: saref:Function or saref:FunctionOfInterest or saref:Command or saref:CommandOfInterest

saref:stores — stores top Object Properties ToC

Links a feature kind, feature of interest, or device, to the commodity it stores

has domain: saref:FeatureKind or saref:FeatureOfInterest or saref:DeviceKind or saref:Device
has range: saref:Commodity
is inverse of: saref:isStoredBy
saref:isStoredBy

saref:targets — targets top Object Properties ToC

Links a device, function, command, or procedure execution, to the feature, property, or state, it targets.

has sub-properties: saref:controls
saref:observes
has domain: saref:DeviceKind or saref:Device or saref:Function or saref:FunctionOfInterest or saref:Command or saref:CommandOfInterest or saref:ProcedureExecution
has range: saref:FeatureKind or saref:FeatureOfInterest or saref:Property or saref:PropertyOfInterest or saref:State or saref:StateOfInterest
is inverse of: saref:isTargetOf

saref:whenPropertyValue — when property value top Object Properties ToC

Links a profile to a property value that contributes to restricting its applicable context.

has domain: saref:Profile
has range: saref:PropertyValue

saref:whenState — when state top Object Properties ToC

Links a profile to a state that contributes to restricting its applicable context.

has domain: saref:Profile
has range: saref:State

saref:hasIdentifier — has identifier top Data Properties ToC

Links some entity to its identifier. Extensions of SAREF may define sub-properties such as s4abcd:hasUUID, s4abcd:hasGTIN12, etc.

saref:hasManufacturer — has manufacturer top Data Properties ToC

A relationship identifying the manufacturer of an entity (e.g., device). The value is expected to be a string or a string with language tag.

has domain: saref:FeatureKind or saref:FeatureOfInterest

saref:hasModel — has model top Data Properties ToC

A relationship identifying the model of an entity (e.g., device). The value is expected to be a string or a string with language tag.

has domain: saref:FeatureKind or saref:FeatureOfInterest

saref:hasResultTime — has result time top Data Properties ToC

Links a procedure execution to the instant of time when the activity was completed, expressed as an xsd:dateTime literal.

has domain: saref:ProcedureExecution
has range: xsd:dateTime

saref:hasRevisionNumber — has revision number top Data Properties ToC

Links some entity (e.g., a device) to its revision number.

has range: xsd:string

saref:hasTimestamp — has timestamp top Data Properties ToC

Links a procedure execution or a profile to an instant.

has domain: saref:ProcedureExecution or saref:Profile
has range: xsd:dateTime

saref:hasValue — has value top Data Properties ToC

Value of a property value expressed as an RDF literal. Note that, even if decimal values are expected, values could use other datatypes.

saref:hasVersion — has version top Data Properties ToC

Links some entity (e.g., a device) to its version.

has range: xsd:string

Normative references

[0] ETSI TS 103 264 (V4.1.1): "SmartM2M; Smart Applications; Reference Ontology and oneM2M Mapping".
[1] ETSI EN 303 760: "SmartM2M; SAREF Guidelines for IoT Semantic Interoperability; Develop, apply and evolve Smart Applications ontologies".
[2] ETSI TS 118 112: "oneM2M; Base Ontology (oneM2M TS-0012)".
[3] ETSI TS 103 267: "SmartM2M; Smart Applications; Communication Framework".
[4] ETSI TS 103 673: "SmartM2M; SAREF Development Framework and Workflow, Streamlining the Development of SAREF and its Extensions".
[5] ETSI TS 103 548: "SmartM2M; SAREF reference ontology patterns".
[6] W3C® Recommendation 18 August 2009: "SKOS Simple Knowledge Organization System Reference".
[7] W3C® Recommendation 19 October 2017:"Semantic Sensor Network Ontology", OGC® and W3C® Spatial Data on the Web working Group.
[8] W3C® Candidate Recommendation Draft 15 November 2022: "Time Ontology in OWL", OGC® and W3C® Spatial Data on the Web working Group.
[9] OGC® IS 22-047r1 (V1.1): "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: "The Smart Applications REFerence ontology (SAREF)".
[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 264 (V3.2.1): "SmartM2M; Smart Applications; Reference Ontology and oneM2M Mapping".
[i.9] ETSI TS 103 410-1: "SmartM2M; Extension to SAREF; Part 1: Energy Domain".
[i.10] ETSI TS 103 410-2: "SmartM2M; Extension to SAREF; Part 2: Environment Domain".
[i.11] ETSI TS 103 410-3: "SmartM2M; Extension to SAREF; Part 3: Building Domain".
[i.12] ETSI TS 103 410-4: "SmartM2M; Extension to SAREF; Part 4: Smart Cities Domain".
[i.13] ETSI TS 103 410-5: "SmartM2M; Extension to SAREF; Part 5: Industry and Manufacturing Domains".
[i.14] ETSI TS 103 410-6: "SmartM2M; Extension to SAREF; Part 6: Smart Agriculture and Food Chain Domain".
[i.15] ETSI TS 103 410-7: "SmartM2M; Extension to SAREF; Part 7: Automotive Domain ".
[i.16] ETSI TS 103 410-8: "SmartM2M; Extension to SAREF; Part 8: eHealth/Ageing-well Domain".
[i.17] ETSI TS 103 410-9: "SmartM2M; Extension to SAREF; Part 9: Wearables Domain".
[i.18] ETSI TS 103 410-10: "SmartM2M; Extension to SAREF; Part 10: Water Domain".
[i.19] ETSI TS 103 410-11: "SmartM2M; Extension to SAREF; Part 11: Lift Domain".
[i.20] ETSI TS 103 410-12: "SmartM2M; Extension to SAREF; Part 12: Smart Grid Domain".
[i.21] ETSI TR 103 549: "SmartM2M; Guidelines for consolidating SAREF with new reference ontology patterns, based on the experience from the ITEA SEAS project".
[i.22] ETSI TR 103 781: "SmartM2M; Study for SAREF ontology patterns and usage guidelines".
[i.23] ISDA: "ISDA Taxonomy 2.0".
[i.24] European Environment Agency: "Vocabulary: Standard International Energy Product Classification (SIEC)".
[i.25] International Renewable Energy Agency: "Energy taxonomy: Classifications for the energy transition". ISBN: 978-92-9260-583-4.
[i.26] Wikidata.
[i.27] QUDT.org Quantity Kind: "QUDT Quantity Kind Vocabulary Version 2.1".
[i.28] QUDT.org Unit: "QUDT Unit Vocabulary Version 2.1".
[i.29] OM 2.0: "Ontology of units of Measure (OM)".
[i.30] 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.

Browse ontology

Table Of Contents

General Overview

Main classes and properties of SAREF Core

Classes and properties for generic entities

Classes and properties for specific entities

Relation to other documents

Device kinds and devices

Feature kinds and features of interest

Tasks

Commodities

Properties, properties of interest, and property values

Introduction

Properties

Properties of interest

Property Values

States, states of interest, and state values

Introduction

States

States of Interest

State Values

Functions and functions of interest

Introduction

Functions

Functions of Interest

Commands and commands of interest

Introduction

Commands

Commands of Interest

Services and Operations

Procedure executions and sub-classes

Procedure executions

Command executions and operation executions

Observations and Actuations

Profiles

Features of Interest, devices, and spatial objects

Composite Properties and Property Values

Ontology Reference

Classes

saref:Actuation — Actuation top Classes ToC

saref:Actuator — Actuator top Classes ToC

saref:Appliance — Appliance top Classes ToC

saref:Command — Command top Classes ToC

saref:CommandExecution — Command Execution top Classes ToC

saref:CommandOfInterest — Command Of Interest top Classes ToC

saref:Commodity — Commodity top Classes ToC

saref:Device — Device top Classes ToC

saref:DeviceKind — Device kinds top Classes ToC

saref:FeatureKind — Feature kinds top Classes ToC

saref:FeatureOfInterest — Feature of interest top Classes ToC

saref:Function — Function top Classes ToC

saref:FunctionOfInterest — Function of Interest top Classes ToC

saref:Meter — Meter top Classes ToC

saref:Observation — Observation top Classes ToC

saref:Operation — Operation top Classes ToC

saref:OperationExecution — Operation Execution top Classes ToC

saref:ProcedureExecution — Procedure Execution top Classes ToC

saref:Profile — Profile top Classes ToC

saref:Property — Property top Classes ToC

saref:PropertyOfInterest — Property of Interest top Classes ToC

saref:PropertyValue — Property Value top Classes ToC

saref:Sensor — Sensor top Classes ToC

saref:Service — Service top Classes ToC

saref:State — State top Classes ToC

saref:StateOfInterest — State of Interest top Classes ToC

saref:StateValue — State Value top Classes ToC

saref:Task — Task top Classes ToC

saref:UnitOfMeasure — Unit of measure top Classes ToC

Object Properties

saref:accomplishes — accomplishes top Object Properties ToC

saref:consistsOf — consists of top Object Properties ToC

saref:consumes — consumes top Object Properties ToC

saref:controls — controls top Object Properties ToC

saref:hasApplicableTime — has applicable time top Object Properties ToC

saref:hasCommand — has command top Object Properties ToC

saref:hasCommandKind — has command kind top Object Properties ToC

saref:hasCommandOfInterest — has command of interest top Object Properties ToC

saref:hasDeviceKind — has device kind top Object Properties ToC

saref:hasFeatureKind — has feature kind top Object Properties ToC

saref:hasFunction — has function top Object Properties ToC