SAREF: the Smart Applications REFerence ontology

Latest version:

https://saref.etsi.org/core/

Permanent IRI for this version (v4.1.1)

https://saref.etsi.org/core/v4.1.1/

Previous version

https://saref.etsi.org/core/

ETSI Technical Specification

https://www.etsi.org/deliver/etsi_ts/103200_103299/103264/04.01.01_60/ts_103264v040101p.pdf

Sources on the SAREF Forge

https://saref.etsi.org/sources/saref-core/

Publication Date

2024-10-31

Last Modification Date

2024-03-06

Creators

Ontology requirements and tests

requirements and tests

Prefix and namespace declaration:

Turtle: @prefix saref: <https://saref.etsi.org/core/> .

SPARQL: PREFIX saref: <https://saref.etsi.org/core/>

Download serialization:

License:

Abstract

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.

Introduction

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

Namespace Declarations

default namespace:: https://saref.etsi.org/core/
owl:: http://www.w3.org/2002/07/owl#
saref:: https://saref.etsi.org/core/
xsd:: http://www.w3.org/2001/XMLSchema#
skos:: http://www.w3.org/2004/02/skos/core#
rdfs:: http://www.w3.org/2000/01/rdf-schema#
rdf:: http://www.w3.org/1999/02/22-rdf-syntax-ns#
xml:: http://www.w3.org/XML/1998/namespace
s4syst:: https://saref.etsi.org/saref4syst/
dcterms:: http://purl.org/dc/terms/
time:: http://www.w3.org/2006/time#
vann:: http://purl.org/vocab/vann/
foaf:: http://xmlns.com/foaf/0.1/

Classes

Actuation back to ToC or Class ToC

IRI: https://saref.etsi.org/core/Actuation

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:ProcedureExecution^c
saref:controls^op min 1
saref:madeBy^op only saref:Actuator^c

Actuator back to ToC or Class ToC

IRI: https://saref.etsi.org/core/Actuator

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

has super-classes: saref:Device^c
saref:controls^op min 1

Appliance back to ToC or Class ToC

IRI: https://saref.etsi.org/core/Appliance

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

has super-classes: saref:Device^c

Command back to ToC or Class ToC

IRI: https://saref.etsi.org/core/Command

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^op only saref:Command^c
skos:narrower^op only saref:Command^c
is in domain of: saref:isCommandOf^c
is in range of: saref:hasCommand^c
saref:hasCommandKind^c

Command Execution back to ToC or Class ToC

IRI: https://saref.etsi.org/core/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).

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

Command Of Interest back to ToC or Class ToC

IRI: https://saref.etsi.org/core/CommandOfInterest

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^op exactly 1
is in domain of: saref:hasCommandKind^c
saref:isCommandOfInterestOf^c
is in range of: saref:hasCommandOfInterest^c

Commodity back to ToC or Class ToC

IRI: https://saref.etsi.org/core/Commodity

A marketable item which may be supplied without qualitative differentiation.

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

Device back to ToC or Class ToC

IRI: https://saref.etsi.org/core/Device

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^c
s4syst:System^c
has sub-classes: saref:Actuator^c
saref:Appliance^c
saref:Meter^c
saref:Sensor^c
is in domain of: saref:hasDeviceKind^c
saref:hasFunctionOfInterest^c
saref:offers^c
is in range of: saref:isFunctionOfInterestOf^c
saref:isOfferedBy^c

Device kinds back to ToC or Class ToC

IRI: https://saref.etsi.org/core/DeviceKind

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: saref:FeatureKind^c
skos:broader^op only saref:FeatureKind^c
skos:narrower^op only saref:FeatureKind^c
is in range of: saref:hasDeviceKind^c

Feature kinds back to ToC or Class ToC

IRI: https://saref.etsi.org/core/FeatureKind

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^op only saref:FeatureKind^c
skos:narrower^op only saref:FeatureKind^c
saref:consistsOf^op only saref:FeatureKind^c
has sub-classes: saref:DeviceKind^c
is in range of: saref:hasFeatureKind^c

Feature of interest back to ToC or Class ToC

IRI: https://saref.etsi.org/core/FeatureOfInterest

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^op only saref:FeatureOfInterest^c
has sub-classes: saref:Device^c
is in domain of: saref:hasFeatureKind^c
saref:hasPropertyOfInterest^c
saref:hasStateOfInterest^c
saref:madeExecution^c
is in range of: saref:isCommandOfInterestOf^c
saref:isPropertyOfInterestOf^c
saref:isStateOfInterestOf^c
saref:madeBy^c

Function back to ToC or Class ToC

IRI: https://saref.etsi.org/core/Function

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^op only saref:Function^c
skos:narrower^op only saref:Function^c
is in domain of: saref:hasMandatoryCommand^c
saref:hasOptionalCommand^c
saref:isFunctionOf^c
is in range of: saref:hasFunction^c
saref:hasFunctionKind^c

Function of Interest back to ToC or Class ToC

IRI: https://saref.etsi.org/core/FunctionOfInterest

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

Meter back to ToC or Class ToC

IRI: https://saref.etsi.org/core/Meter

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:Device^c
saref:observes^op min 1

Observation back to ToC or Class ToC

IRI: https://saref.etsi.org/core/Observation

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:ProcedureExecution^c
saref:madeBy^op only saref:Sensor^c
saref:observes^op min 1

Operation back to ToC or Class ToC

IRI: https://saref.etsi.org/core/Operation

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:isOperationOf^op exactly 1
saref:represents^op only (saref:Command^c or saref:CommandOfInterest^c)
saref:represents^op min 1 saref:CommandOfInterest^c
is in domain of: saref:isOperationOf^c
is in range of: saref:hasOperation^c

Operation Execution back to ToC or Class ToC

IRI: https://saref.etsi.org/core/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.

has super-classes: saref:ProcedureExecution^c
saref:isExecutionOf^op only saref:Operation^c

Procedure Execution back to ToC or Class ToC

IRI: https://saref.etsi.org/core/ProcedureExecution

Represents the act of carrying out a procedure.

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

Profile back to ToC or Class ToC

IRI: https://saref.etsi.org/core/Profile

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^c
saref:profileHasPrice^c
saref:whenPropertyValue^c
saref:whenState^c
is in range of: saref:hasProfile^c

Property back to ToC or Class ToC

IRI: https://saref.etsi.org/core/Property

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: skos:broader^op only saref:Property^c
skos:narrower^op only saref:Property^c
saref:consistsOf^op only (saref:FeatureKind^c or saref:Property^c or saref:State^c)
is in domain of: saref:isPropertyOf^c
is in range of: saref:hasProperty^c
saref:hasPropertyKind^c

Property of Interest back to ToC or Class ToC

IRI: https://saref.etsi.org/core/PropertyOfInterest

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:consistsOf^op only (saref:FeatureKind^c or saref:Property^c or saref:State^c or saref:PropertyOfInterest^c or saref:StateOfInterest^c)
saref:isPropertyOfInterestOf^op exactly 1
is in domain of: saref:hasPropertyKind^c
saref:isPropertyOfInterestOf^c
is in range of: saref:hasPropertyOfInterest^c

Property Value back to ToC or Class ToC

IRI: https://saref.etsi.org/core/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).

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

Sensor back to ToC or Class ToC

IRI: https://saref.etsi.org/core/Sensor

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

has super-classes: saref:Device^c
saref:observes^op min 1

Service back to ToC or Class ToC

IRI: https://saref.etsi.org/core/Service

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:isOfferedBy^op exactly 1
saref:represents^op only (saref:Function^c or saref:FunctionOfInterest^c)
saref:represents^op min 1 saref:FunctionOfInterest^c
is in domain of: saref:hasOperation^c
saref:isOfferedBy^c
is in range of: saref:isOperationOf^c
saref:offers^c

State back to ToC or Class ToC

IRI: https://saref.etsi.org/core/State

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^op only saref:State^c
skos:narrower^op only saref:State^c
is in domain of: saref:isStateOf^c
is in range of: saref:hasState^c
saref:hasStateKind^c
saref:whenState^c

State of Interest back to ToC or Class ToC

IRI: https://saref.etsi.org/core/StateOfInterest

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^op exactly 1
is in domain of: saref:hasStateKind^c
saref:isStateOfInterestOf^c
is in range of: saref:hasStateOfInterest^c

State Value back to ToC or Class ToC

IRI: https://saref.etsi.org/core/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).

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

Task back to ToC or Class ToC

IRI: https://saref.etsi.org/core/Task

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

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

Unit of measure back to ToC or Class ToC

IRI: https://saref.etsi.org/core/UnitOfMeasure

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

is in range of: saref:isMeasuredIn^c

Object Properties

accomplishes
consists of
consumes
controls
has applicable time
has command
has command kind
has command of interest
has device kind
has feature kind
has function
has function kind
has function of interest
has input
has mandatory command
has operation
has optional command
has output
has phenomenon time
has profile
has property
has property kind
has property of interest
has property value
has result
has state
has state kind
has state of interest
has state value
is accomplished by
is command of
is command of interest of
is consumed by
is controlled by
is execution of
is function of
is function of interest of
is measured in
is observed by
is offered by
is operation of
is produced by
is profile of
is property of
is property of interest of
is state of
is state of interest of
is stored by
is target of
is value of property
is value of state
made by
made execution
observes
offers
produces
has price
represents
stores
targets
when property value
when state

accomplishes back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/accomplishes

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

has range: saref:Task^c
is inverse of: saref:isAccomplishedBy^op

consists of back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/consistsOf

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^op o saref:hasFeatureKind^op
saref:consistsOf^op o saref:hasStateKind^op
saref:consistsOf^op o saref:isValueOfProperty^op
saref:consistsOf^op o saref:isValueOfState^op
saref:consistsOf^op o saref:hasPropertyKind^op

consumes back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/consumes

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

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

controls back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/controls

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

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

has applicable time back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasApplicableTime

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^c or time:TemporalPosition^c

has command back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasCommand

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

has domain: saref:Function^c or saref:FunctionOfInterest^c
has range: saref:Command^c
is inverse of: saref:isCommandOf^op
has sub-property chains: saref:hasFeatureKind^op o saref:hasMandatoryCommand^op
saref:hasCommandOfInterest^op o saref:hasCommandKind^op

has command kind back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasCommandKind

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

has domain: saref:CommandOfInterest^c
has range: saref:Command^c
has sub-property chains: saref:hasCommandKind^op o skos:broader^op

has command of interest back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasCommandOfInterest

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

has domain: saref:FunctionOfInterest^c
has range: saref:CommandOfInterest^c
is inverse of: saref:isCommandOfInterestOf^op

has device kind back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasDeviceKind

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^op
has domain: saref:Device^c
has range: saref:DeviceKind^c

has feature kind back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasFeatureKind

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

has sub-properties: saref:hasDeviceKind^op
has domain: saref:FeatureOfInterest^c
has range: saref:FeatureKind^c
has sub-property chains: saref:hasFeatureKind^op o skos:broader^op

has function back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasFunction

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

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

has function kind back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasFunctionKind

links a function of interest to its kind, a function

has domain: saref:FunctionOfInterest^c
has range: saref:Function^c
has sub-property chains: saref:hasFunctionKind^op o skos:broader^op

has function of interest back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasFunctionOfInterest

Links a device to one of its functions of interest.

has domain: saref:Device^c
has range: saref:FunctionOfInterest^c
is inverse of: saref:isFunctionOfInterestOf^op

has input back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasInput

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

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

has mandatory command back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasMandatoryCommand

Links a function and one of its mandatory commands

has domain: saref:Function^c
has sub-property chains: skos:broader^op o saref:hasMandatoryCommand^op

has operation back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasOperation

Links a service to one of its operations.

has domain: saref:Service^c
has range: saref:Operation^c
is inverse of: saref:isOperationOf^op

has optional command back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasOptionalCommand

Links a function and one of its optional commands

has domain: saref:Function^c

has output back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasOutput

Links a command or operation to its outputs.

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

has phenomenon time back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/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.

has range: time:TemporalEntity^c

has profile back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/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.

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

has property back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasProperty

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

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

has property kind back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasPropertyKind

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

has domain: saref:PropertyOfInterest^c
has range: saref:Property^c
has sub-property chains: saref:hasPropertyKind^op o skos:broader^op

has property of interest back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasPropertyOfInterest

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

has domain: saref:FeatureOfInterest^c
has range: saref:PropertyOfInterest^c
is inverse of: saref:isPropertyOfInterestOf^op

has property value back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasPropertyValue

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

has domain: saref:FeatureKind^c or saref:FeatureOfInterest^c or saref:PropertyOfInterest^c
has range: saref:PropertyValue^c
has sub-property chains: skos:broader^op o saref:hasPropertyValue^op

has result back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasResult

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

has domain: saref:ProcedureExecution^c

has state back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasState

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

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

has state kind back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasStateKind

links a state of interest to its kind, a state

has domain: saref:StateOfInterest^c
has range: saref:State^c
has sub-property chains: saref:hasStateKind^op o skos:broader^op

has state of interest back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasStateOfInterest

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

has domain: saref:FeatureOfInterest^c
has range: saref:StateOfInterest^c
is inverse of: saref:isStateOfInterestOf^op

has state value back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/hasStateValue

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

has domain: saref:FeatureKind^c or saref:FeatureOfInterest^c or saref:StateOfInterest^c
has range: saref:StateValue^c
has sub-property chains: skos:broader^op o saref:hasStateValue^op

is accomplished by back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isAccomplishedBy

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

has domain: saref:Task^c
is inverse of: saref:accomplishes^op

is command of back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isCommandOf

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

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

is command of interest of back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isCommandOfInterestOf

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

has domain: saref:CommandOfInterest^c
has range: saref:FeatureOfInterest^c
is inverse of: saref:hasCommandOfInterest^op

is consumed by back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isConsumedBy

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

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

is controlled by back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isControlledBy

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

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

is execution of back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isExecutionOf

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^c
has range: saref:Command^c or saref:CommandOfInterest^c or saref:Operation^c
has sub-property chains: saref:isExecutionOf^op o skos:broader^op
saref:isExecutionOf^op o saref:hasCommandKind^op

is function of back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isFunctionOf

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

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

is function of interest of back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isFunctionOfInterestOf

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

has domain: saref:FunctionOfInterest^c
has range: saref:Device^c
is inverse of: saref:hasFunctionOfInterest^op

is measured in back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isMeasuredIn

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

has range: saref:UnitOfMeasure^c

is observed by back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isObservedBy

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

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

is offered by back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isOfferedBy

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

has domain: saref:Service^c
has range: saref:Device^c
is inverse of: saref:offers^op

is operation of back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isOperationOf

Links an operation to the service it belongs to.

has domain: saref:Operation^c
has range: saref:Service^c
is inverse of: saref:hasOperation^op

is produced by back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isProducedBy

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

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

is profile of back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isProfileOf

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^c
has range: saref:DeviceKind^c or saref:Device^c
is inverse of: saref:hasProfile^op

is property of back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isPropertyOf

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

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

is property of interest of back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isPropertyOfInterestOf

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

has domain: saref:PropertyOfInterest^c
has range: saref:FeatureOfInterest^c
is inverse of: saref:hasPropertyOfInterest^op

is state of back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isStateOf

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

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

is state of interest of back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isStateOfInterestOf

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

has domain: saref:StateOfInterest^c
has range: saref:FeatureOfInterest^c
is inverse of: saref:hasStateOfInterest^op

is stored by back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isStoredBy

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

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

is target of back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isTargetOf

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

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

is value of property back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isValueOfProperty

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

has domain: saref:PropertyValue^c
has range: saref:FeatureKind^c or saref:FeatureOfInterest^c or saref:PropertyOfInterest^c
has sub-property chains: saref:isValueOfProperty^op o saref:hasPropertyKind^op

is value of state back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/isValueOfState

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

has domain: saref:StateValue^c
has range: saref:FeatureKind^c or saref:FeatureOfInterest^c or saref:StateOfInterest^c
has sub-property chains: saref:isValueOfState^op o saref:hasStateKind^op

made by back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/madeBy

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

has domain: saref:ProcedureExecution^c
has range: saref:FeatureOfInterest^c
is inverse of: saref:madeExecution^op

made execution back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/madeExecution

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

has domain: saref:FeatureOfInterest^c
has range: saref:ProcedureExecution^c
is inverse of: saref:madeBy^op

observes back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/observes

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

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

offers back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/offers

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

has domain: saref:Device^c
has range: saref:Service^c
is inverse of: saref:isOfferedBy^op

produces back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/produces

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

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

has price back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/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

has domain: saref:Profile^c
has range: saref:PropertyValue^c

represents back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/represents

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^c or saref:Operation^c
has range: saref:Function^c or saref:FunctionOfInterest^c or saref:Command^c or saref:CommandOfInterest^c

stores back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/stores

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

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

targets back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/targets

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

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

when property value back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/whenPropertyValue

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

has domain: saref:Profile^c
has range: saref:PropertyValue^c

when state back to ToC or Object Property ToC

IRI: https://saref.etsi.org/core/whenState

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

has domain: saref:Profile^c
has range: saref:State^c

Data Properties

has identifier
has manufacturer
has model
has result time
has revision number
has timestamp
has value
has version

has identifier back to ToC or Data Property ToC

IRI: https://saref.etsi.org/core/hasIdentifier

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

has manufacturer back to ToC or Data Property ToC

IRI: https://saref.etsi.org/core/hasManufacturer

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^c or saref:FeatureOfInterest^c

has model back to ToC or Data Property ToC

IRI: https://saref.etsi.org/core/hasModel

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^c or saref:FeatureOfInterest^c

has result time back to ToC or Data Property ToC

IRI: https://saref.etsi.org/core/hasResultTime

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

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

has revision number back to ToC or Data Property ToC

IRI: https://saref.etsi.org/core/hasRevisionNumber

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

has range: xsd:string

has timestamp back to ToC or Data Property ToC

IRI: https://saref.etsi.org/core/hasTimestamp

Links a procedure execution or a profile to an instant.

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

has value back to ToC or Data Property ToC

IRI: https://saref.etsi.org/core/hasValue

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

has version back to ToC or Data Property ToC

IRI: https://saref.etsi.org/core/hasVersion

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

has range: xsd:string

Named Individuals

References

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.

This documentation page was generated automatically using SPARQL-Generate, developed by Maxime Lefrançois. The SAREF public portal, the SAREF sources with continuous integration and deployment, the SAREF Pipeline software, and ETSI Technical Specification TS 103 673 v1.1.1 "SAREF Development Framework and Workflow, Streamlining the Development of SAREF and its Extensions", have been developed in the context of the ETSI STF 578, which followed the ETSI STF 556.

© ETSI 2024
Visit ETSI website for more information on Terms & Conditions.

Legal matters

Contact & Support

Back to top