has property of interest
Links a feature of interest to one of its properties of interest.
V3.2.1: Introduced saref:hasPropertyOfInterest and saref:isPropertyOfInterestOf. Cannot use saref:hasProperty due to the combination of cardinality restrictions and sub-property chain axioms makes the ontology exist the OWL 2 DL prodile.
Feature of interest
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.
V3.2.1: Definition of saref:FeatureOfInterest: allValuesFrom axioms are unnecessary and have been deleted.
V3.2.1: Definition of saref:FeatureOfInterest is clarified, not only properties are measured, but properties and states can be observed and controlled.
V3.2.1: Definition of saref:FeatureOfInterest: Clarify it's a specific real world entity.
has property kind
links a property of interest to its kind, a property.
produces
Links a feature kind, feature of interest, or device, to the commodity it produces
has state value
Links a feature kind, a feature of interest, or a state of interest, to a state value.
V4.1.1: Introduced saref:hasStateValue.
Property Value
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).
V3.2.1: Introduced saref:PropertyValue to simplify the association of a measure to a property, without always needing it to be a measurement made by a device.
V4.1.1: saref:hasValue is now optional on saref:PropertyValue.
SAREF: the Smart Applications REFerence ontology
The Smart Applications REFerence ontology (SAREF) is intended to enable interoperability between solutions from different providers and among various activity sectors in the Internet of Things (IoT), thus contributing to the development of the global digital market.
Information about changes to version 3.1.1: NOTE: In some cases, references have been added to indicate the issue in the ETSI Forge (https://saref.etsi.org/sources/saref-core/issues) where the change was discussed and implemented. - Added the saref:FeatureOfInterest class and the properties used to relate it to saref:Measurement (saref:hasMeasurement and saref:isMeasurementOf) and to saref:Property (saref:hasProperty and saref:isPropertyOf). - Added the saref:measurementMadeBy property as inverse of saref:makesMeasurement. - The saref:relatesToProperty and saref:relatesToMeasurement properties are now inverse of each other. - The range of saref:hasValue, which was defined as xsd:float, has been removed to support other datatypes for measurements. - The range of datatype properties, which was defined as xsd:string, has been removed in order to support strings with language tags (rdf:langString). This affects saref:hasDescription, saref:hasManufacturer, saref:hasModel and saref:hasName, which now have implicitly a range of rdfs:Literal. - The saref:hasName property has been removed and the use of rdfs:label is recommended. - The saref:hasDescription property has been deprecated and the use of rdfs:comment is recommended. - Too restrictive restrictions have been removed and in some cases the ontology documentation has been updated to reflect this: a saref:Command having at most one saref:hasDescription; a saref:Task being accomplished by at least one saref:Device; a saref:Device having a typical consumption of only energy or power; a saref:Commodity being measured in units of measure; restrictions on the values of saref:accomplishes that only covered specific use cases; universal restrictions on the saref:actsUpon property have been changed to existential ones; restrictions on the commands that a saref:Function may have, since there could be others not included in the defined enumerations; restrictive documentation of saref:EventFunction and saref:SmokeSensor. - Bugs have been fixed: some devices (saref:DoorSwitch, saref:EnergyMeter, saref:LigthSwitch, saref:SmokeSensor, and saref:TemperatureSensor) were defined as subclass of a device and at the same time as consisting of such device; a saref:LightSwitch controls light and does not measure light, since it is an actuator; incorrect documentation of saref:OnState and saref:OffState. - The saref:BuildingRelated, saref:EnergyRelated and saref:FunctionRelated classes have been removed, since the different extensions already classify the device types. - The instances of the subclasses of saref:Command have been removed, since they represent examples. - The instances of saref:UnitOfMeasure have been moved to examples. - The classes related to the SAREF4ENER extension have been removed: saref:Generator, saref:Storage, saref:Load and saref:EnergyMeter. - Some instances of saref:Device have been moved to examples: saref:WashingMachine, saref:LightingDevice, saref:MicroRenewable, saref:Multimedia, and saref:Network. - Added domain and range axioms wherever the definition of a property unambiguously identifies the domain or the range of the property. - The OWL Time ontology is not imported anymore. - The documentation of some ontology terms has been updated for clarification. - Language tags have been added to all labels and comments.
Information about changes to version 2.1.1: - The classes and properties related to how to represent devices in building spaces (such as the saref:BuildingSpace class, saref:BuildingObject class and saref:isLocatedIn property) have been removed from SAREF and incorporated into the SAREF4BLDG extension related to buildings, including the reuse of the W3C? WGS84 geo positioning vocabulary. - The saref:DeviceCategory and saref:FunctionCategory classes have been removed. Instead, the hierarchy of device categories has been implemented directly as subclasses of the saref:Device class. - The information specific for energy efficiency has been moved to the SAREF4ENER extension. For example, the saref:Profile class has been redefined to accommodate only the properties that are general enough for any type of profile, not only for energy and power. Details on how to specifically model a power profile can be found in the SAREF4ENER extension. - The subclasses of the saref:Energy class have been removed (i.e., Average Energy, Maximum Energy, Minimum Energy, Total Energy, HVAC Energy, Hot Water Energy and Lighting Energy). - The saref:Property class has been split into two classes (saref:Property and saref:Measurement), as it is done in the SAREF4ENVI extension, in order to properly accommodate the distinction between the concept of property (an observable quality of something) and the concept of measurement (a concrete value observed for a property). - Too restrictive cardinality restrictions have been revised, sometimes making them optional rather than mandatory (better to make properties mandatory in the extensions that specialize SAREF for a specific purpose, rather than restricting SAREF, whose purpose is more general). For example, definitions of units of measurement using an enumeration (owl:oneOf) were too restrictive because they did not allow using other units than those enumerated. Therefore, the individuals of each class are still there, but the owl:oneOf enumeration has been removed. - The saref:UnitOfMeasure subclasses use individuals from the OM ontology for unit of measures, but this is not the only solution. It has been clarified in the comments that the OM ontology is an example, but other ontologies can be used. - The global restrictions (rdfs:domain and rdfs:range) in object properties have been completely removed not to hinder interoperability. Object properties are now only restricted locally in the classes. - The subclasses of saref:Task have been transormed in individuals. - The saref:hasTask property has been removed from the saref:Profile class to resolve an ambiguity with the saref:Task class.
Information about changes to version 3.2.1: NOTE: Rationale and decisions for many of the changes in V3.2.1 are available in issues in project https://saref.etsi.org/sources/saref-core/issues. - Definition of saref:FeatureOfInterest is clarified, not only properties are measured, but properties and states can be observed and controlled. - Definition of saref:FeatureOfInterest: Clarify it is a specific real world entity. - Definition of saref:FeatureOfInterest: allValuesFrom axioms are unnecessary and have been deleted. - Introduced class saref:FeatureKind - Use SKOS to organize generic classes in taxonomies. - Introduce hasClassKind for Class is Feature, Device, Property, State, Function, Command. - Add local restrictions on consistsOf on feature of interest - Defined domain of saref:hasManufacturer to union of feature kind and feature of interest. - Defined domain of saref:hasModel to union of feature kind and feature of interest. - Most axioms on saref:Device were useless and have been deleted. - definition of saref:Device clarifies it is a real world entity. - saref:Device is explicitly a subclass of saref:FeatureOfInterest and s4syst:System. - saref:actsUpon now holds not only between a command and a state. It generalizes actsUpon, observes, controls. Domain and range are unions of several classes. - Introduced property saref:isActedUponBy. - Introduced property saref:observes, as sub-property of saref:actsUpon. and generalization of measures. - Introduced property saref:controls, as sub-property of saref:actsUpon. and generalization of saref:controlsProperty. - Introduced property saref:isControlledBy. - saref:measuresProperty is deprecated: will be deleted in the next release of SAREF - saref:isMeasuredByDevice is deprecated: will be deleted in the next release of SAREF - saref:isControlledByDevice is deprecated: will be deleted in the next release of SAREF - saref:controlsProperty is deprecated: will be deleted in the next release of SAREF - Definition of saref:Appliance is grounded on tasks and commodities. - Definition of Sensor is simplified and grounded on saref:observes. Local restriction on saref:hasFunction is deleted. - Definition of Actuator is simplified and grounded on saref:controls. Local restriction on saref:hasFunction is deleted. - Definition of Meter is simplified and grounded on saref:observes. Local restriction on saref:hasFunction is deleted. - Deprecated saref:HVAC for it is only an example. - Deprecated saref:Switch for it is only an example. - Deprecated saref:DoorSwitch for it is only an example. - Deprecated saref:LightSwitch for it is only an example. - Deprecated saref:SmokeSensor for it is only an example. - Deprecated saref:TemperatureSensor for it is only an example. - The following tasks are deprecated, and may be deleted in the next release of SAREF: saref:Cleaning, saref:Comfort, saref:Drying, saref:EnergyEfficiency, saref:Entertainment, saref:Lighting, saref:MeterReading, saref:Safety, saref:Washing, saref:WellBeing. - Definition of saref:Commodity is simplified. - saref:Electricity is deprecated: will be defined as an instance of saref:Commodity in the next release of SAREF - saref:Gas is deprecated: will be defined as an instance of saref:Commodity in the next release of SAREF - saref:Coal is deprecated: will be defined as an instance of saref:Commodity in the next release of SAREF - saref:Water is deprecated: will be defined as an instance of saref:Commodity in the next release of SAREF - New category of commodities saref:EnergyCommodity - New category of commodities saref:NaturalResourceCommodity - Introduced saref:consumes, saref:isConsumedBy, saref:produces, saref:isProducedBy, saref:stores, saref:isStoredBy. - The definition and scope of usage for saref:Property is clarified. Axiomatization is simplified. - applicability of saref:hasProperty is relaxed to also saref:FeatureKind - Introduced saref:PropertyOfInterest to solved the ambiguity between generic vs specific properties. - Introduced saref:hasPropertyOfInterest and saref:isPropertyOfInterestOf. Cannot use saref:hasProperty due to the combination of cardinality restrictions and sub-property chain axioms makes the ontology exist the OWL 2 DL prodile. - Introduced saref:PropertyValue to simplify the association of a measure to a property, without always needing it to be a measurement made by a device. - Clarified definition of saref:hasValue. - Relaxed domain of saref:isMeasuredIn so it can apply to saref:PropertyValue as well as saref:Measurement. The new range will be enforced in the next release of SAREF. - Introduced saref:hasPropertyValue. - Introduced saref:isValueOfProperty. - The following classes are deprecated and may be defined as instances of saref:Property in the next release of SAREF: saref:Energy, saref:Humidity, saref:Light, saref:Motion, saref:Occupancy, saref:Power, saref:Pressure, saref:Price, saref:Smoke, saref:Temperature - saref:EnergyUnit is deprecated. Will be deleted in the next release of SAREF - saref:IlluminanceUnit is deprecated. Will be deleted in the next release of SAREF - saref:PowerUnit is deprecated. Will be deleted in the next release of SAREF - saref:PressureUnit is deprecated. Will be deleted in the next release of SAREF - saref:TemperatureUnit is deprecated. Will be deleted in the next release of SAREF - Clarified and generalized definition of saref:State. Can now apply to all features of interest, not just devices. - Relaxed domain of saref:hasState. - Introduced saref:isStateOf. - Introduced saref:StateOfInterest, parallel to saref:PropertyOfInterest. - Introduced saref:hasStateOfInterest and saref:isStateOfInterestOf, parallel to saref:hasPropertyOfInterest and saref:isPropertyOfInterestOf. - The following classes are deprecated and may be defined as instances of saref:State in the next release of SAREF: saref:CloseState, saref:MultiLevelState, saref:OffState, saref:OnOffState, saref:OnState, saref:OpenCloseState, saref:OpenState, saref:StartState, saref:StartStopState, saref:StopState. - Simplified definition and axiomatization of saref:Function. Added examples. - saref:SensingFunction is deprecated: may be defined as an instance of saref:Function in the next release of SAREF - saref:hasSensingRange is deprecated together with saref:SensingFunction. And may be defined as an instance of saref:Property in the next release of SAREF - saref:hasSensorType is deprecated together with saref:SensingFunction. Use saref:hasDeviceKind instead. - saref:EventFunction is deprecated: may be defined as an instance of saref:Function in the next release of SAREF - saref:hasThresholdMeasurement is deprecated together with saref:EventFunction. And may be defined as an instance of saref:Property in the next release of SAREF - saref:MeteringFunction is deprecated: may be defined as an instance of saref:Function in the next release of SAREF - deprecated saref:hasMeterReading together with saref:Measurement and saref:MeteringFunction - deprecated saref:hasMeterReadingType together with saref:MeteringFunction - saref:LevelControlFunction, saref:StartStopFunction, saref:OpenCloseFunction, saref:OnOffFunction, - saref:ActuatingFunction are deprecated: may be defined as an instance of saref:Function in the next release of SAREF. - Domain of saref:hasFunction is relaxed. - Introduced saref:isFunctionOf. - Introduced saref:FunctionOfInterest, parallel to saref:PropertyOfInterest. - Simplified definition and axiomatization of saref:Command. Added examples. - Domain of saref:hasCommand is relaxed to saref:Function or saref:FunctionOfInterest. - Introduced mandatory and optional commands. - Introduced saref:hasInput and saref:hasOutput. - Introduced saref:CommandOfInterest, parallel to saref:PropertyOfInterest. - The following classes are deprecated and may be defined as instances of saref:Command in the next release of SAREF: saref:ToggleCommand, saref:GetCommand, saref:NotifyCommand, saref:GetSensingDataCommand, saref:GetCurrentMeterValueCommand, saref:GetMeterDataCommand, saref:GetMeterHistoryCommand, saref:SetAbsoluteLevelCommand, saref:SetRelativeLevelCommand, saref:SetLevelCommand, saref:StepDownCommand, saref:StepUpCommand, saref:PauseCommand, saref:StartCommand, saref:StopCommand, saref:CloseCommand, saref:OpenCommand, saref:OnCommand, saref:OffCommand. - Simplified definition of saref:Service. Added examples. - Relaxed domain and range of saref:represents. - Clarified definition of saref:offers. - Clarified definition of saref:isOfferedBy. - saref:SwitchOnService is deprecated for it is just an example. It may be deleted in the next release of SAREF - Introduced saref:Operation and associated properties from oneM2M base ontology. - Introduced saref:ProcedureExecution. - Introduce saref:madeBy (resp. saref:madeExecution) as generalization of saref:measurementMadeBy (resp. saref:makesMeasurement). - saref:makesMeasurement is deprecated as one of the properties related to saref:Measurement. It may be deleted in the next release of SAREF - saref:makesMeasurement is deprecated as one of the properties related to saref:Measurement. It may be deleted in the next release of SAREF - Introduced saref:hasResult as part of general will to make SAREF and SOSA/SSN converge. - Introduced saref:hasResultTime as part of general will to make SAREF and SOSA/SSN converge. - Introduced saref:hasPhenomenonTime as part of general will to make SAREF and SOSA/SSN converge. - Tried to clarify definition of saref:hasTimestamp. Still unclear. - Deprecated saref:Measurement in favour of saref:Observation, to generalize to observation of states and convergence with SOSA/SSN. - Deprecated saref:isMeasurementOf together with saref:Measurement. - Deprecated saref:isMeasurementOf together with saref:Measurement. - Deprecated saref:isMeasurementOf together with saref:Measurement. - Deprecated saref:isMeasurementOf together with saref:Measurement. - Class saref:Profile has been re-specified, to take into account findings from SAREF4ENER V1.2.1. - Relaxed domain of saref:hasProfile to saref:FeatureKind or saref:Device - Deprecated saref:hasTime and use OWL Time instead whenever possible. - Deprecated saref:Time and use OWL Time instead whenever possible. - Deprecated saref:hasTypicalConsumption. May be defined as an instance of saref:Property in the next release of SAREF.
Information about changes to version 4.1.1: NOTE: Rationale and decisions for many of the changes in V4.1.1 are available in issues in project https://labs.etsi.org/rep/saref/saref-core/-/milestones/3#tab-issues - Deprecated classes and properties have been deleted - Reworded definition of saref:Sensor and saref:Meter - saref:hasValue is now optional on saref:PropertyValue - improved parallel between Property and State descriptions - introduced saref:StateValue - Removed examples of commodity categories - Added notes and examples in multiple sections - Added clause 5.14 about composite properties - Reworked figures throughout the document - Added migration guide from V3.1.1 to V4.1.1 - Updated the oneM2M base ontology to SAREF mapping - Added principle on generic versus specific entities distinction - Added references to EN 303 760
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.
V3.2.1: saref:Device is explicitly a subclass of saref:FeatureOfInterest and s4syst:System.
V3.2.1: definition of saref:Device clarifies it's a real world entity.
V3.2.1: Most axioms on saref:Device were useless and have been deleted.
For example, a washing machine is designed to wash (task) and to accomplish this task it performs a start and stop function.
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.
is function of interest of
Links a function of interest to the device it is a function of.
has command
Links a function or function of interest and the command it supports.
V3.2.1: Domain of saref:hasCommand is relaxed to saref:Function or saref:FunctionOfInterest.
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.
V3.2.1: Definition of Meter is simplified and grounded on saref:observes. Local restriction on saref:hasFunction is deleted.
V4.1.1: Definition of Sensor and Meter are updated to better distinguish one from the other.
has function kind
links a function of interest to its kind, a function
targets
Links a device, function, command, or procedure execution, to the feature, property, or state, it targets.
V4.1.1: saref:actsUpon is renamed saref:targets.
V3.2.1: saref:actsUpon now holds not only between a command and a state. It generalizes observes, observes, controls. Domain and range are unions of several classes.
Function of Interest
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:FunctionOfInterest is supported by exactly one device.
V3.2.1: Introduced saref:FunctionOfInterest, parallel to saref:PropertyOfInterest.
A function of interest is the function of (OP saref:isFunctionOfInterestOf) exactly one device.
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.
has version
Links some entity (e.g., a device) to its version.
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.
V3.2.1: Introduced saref:Operation and associated properties from oneM2M base ontology.
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.
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.
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 a enumerated value. Another one may be dedicated to start, pause, or stop the washing cycle.
To turn on a light, send a CoAP PUT request with CBOR content 0xf5 (true)
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).
has price
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
is execution of
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
Service
A saref:Service is a digital representation of a function in a network, making it discoverable, registerable and remotely controllable in the network.
V3.2.1: Simplified definition of saref:Service. Added examples.
Typically, a device connected to a given network offers one service for each of its functions of interest.
For example, 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.
has property
Links a feature kind or a feature of interest to one of its properties.
V3.2.1: applicability of saref:hasProperty is relaxed to also saref:FeatureKind
is target of
Links a feature, property, or state, to the device, function, command, or procedure execution, that targets it.
V3.2.1: Introduced property saref:isActedUponBy.
V4.1.1: Renamed property saref:isActedUponBy into saref:isTargetOf.
Sensor
A device designed to observe and measure one or more properties or states of one or more features of interest.
V3.2.1: Definition of Sensor is simplified and grounded on saref:observes. Local restriction on saref:hasFunction is deleted.
is consumed by
Links a commodity to the feature kind, feature of interest, or device, that consumes it
observes
Links a device, function, command, or procedure execution, to the feature, property, or state, it observes.
V3.2.1: Introduced property saref:observes, as sub-property of saref:targets. and generalization of measures.
is offered by
Links a service to the device that exposes it to a network
V3.2.1: Clarified definition of saref:isOfferedBy.
has feature kind
links a feature of interest to its kind, a feature kind
V3.2.1: Introduce hasClassKind for Class is Feature, Device, Property, State, Function, Command.
has optional command
Links a function and one of its optional commands
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.
V3.2.1: Class saref:Profile has been re-specified, to take into account findings from SAREF4ENER V1.2.1.
The applicable context can be restricted to when a feature of interest has a certain state (OPs saref:whenState).
The applicable context can be restricted to when the property of a feature of interest has some value (OPs saref:whenPropertyValue)
OP saref:hasPrice 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.
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.
OP saref:hasProfile links a device to its profile. 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 state
Links a feature kind or a feature of interest to one of its states.
V3.2.1: Relaxed domain of saref:hasState.
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.
V3.2.1: The definition and scope of usage for saref:Property is clarified. Axiomatization is simplified.
Until SAREF V3.1.1, 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, and the new modeling will be enforced in the next major revision of SAREF.
Concepts from existing code lists, vocabularies, and taxonomies, may be used as instances of saref:Property.
Air temperature, pressure, luminance, etc. are all properties.
Two examples using the QUDT Quantity Kind vocabulary, and the British Oceanographic Data Centre Parameter Usage Vocabulary. <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 .
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.
V3.2.1: Clarified and generalized definition of saref:State. Can now apply to all features of interest, not just devices.
Concepts from existing code lists, vocabularies, and taxonomies, may be used as instances of saref:State.
SAREF is not restricted to binary states such as the ex:OnOffState, but allows to define also enumerated states.
A switch can be found in the saref:OnOffState.
is operation of
Links an operation to the service it belongs to.
is value of property
Links a property value to the property or property of interest it is a value of.
V3.2.1: Introduced saref:isValueOfProperty.
has function
Links a feature kind or a device to one of its functions.
V3.2.1: Domain of saref:hasFunction is relaxed.
Property of Interest
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.
V3.2.1: Introduced saref:PropertyOfInterest to solved the ambiguity between generic vs specific properties.
A property of interest is the property of (OP saref:isPropertyOfInterestOf) exactly one feature of interest.
Per convention, the IRI of properties of interest should consist of the IRI of their feature of interest, suffixed with a fragment identifier #{P} where {P} refers to the name of the property.
Properties of interest need not always be explicited. It depends on the use case. Typically, properties of interest are useful in applications, where the association between a feature of interest and a property (i.e., the property of interest) needs to be identified and related to other properties of interest.
The air temperature of the atmosphere sample at a certain location and altitude, the received signal strength indicator of an wireless IoT connection, the luminance of the ETSI ATHENA amphitheatre. <etsi_premises/athena#luminance> a saref:PropertyOfInterest ; saref:isPropertyOfInterestOf <etsi_premises/athena> ; saref:hasPropertyKind saref:Luminance ; rdfs:comment "The luminance of amphitheatre ATHENA"@en .
has function of interest
Links a device to one of its functions of interest.
made execution
Links an entity (e.g., device) to the procedure execution it made.
is stored by
Links a commodity to the feature kind, feature of interest, or device, that stores it
Device kinds
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.
V4.1.1: Introduced class saref:DeviceKind
V4.1.1: Use SKOS to organize generic classes in taxonomies.
has model
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.
V3.2.1: Defined domain of saref:hasModel to union of feature kind and feature of interest.
has applicable time
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.
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.
V3.2.1: Simplified definition and axiomatization of saref:Command. Added examples.
Observe property, control property, observe state, control state, invoke action, cancel action, turn on or off, change color, subscribe, publish, etc. are all commands.
has property value
Links a feature kind, a feature of interest, or a property of interest, to a property value.
V3.2.1: Introduced saref:hasPropertyValue.
offers
Links a device to a service it exposes to a network.
V3.2.1: Clarified definition of saref:offers.
consists of
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)
V3.2.1: Add local restrictions on consistsOf on feature of interest
A feature kind (respectively a feature of interest) may consist of (OP saref:consistsOf) other feature kinds (respectively feature kinds or features of interest).
The OP saref:consistsOf can link a composite property, property of interest, or property value to its individual components.
has command kind
links a command of interest to its kind, a command.
is property of
Links a property to the feature kind or feature of interest it is a property of.
Unit of measure
The unit of measure is a standard for measurement of a quantity, such as a Property.
Concepts from existing code lists, vocabularies, and taxonomies, may be used as instances of saref:UnitOfMeasure. For example the QUDT Unit vocabulary
Our definition is based on the definition of unit of measure in the Ontology of units of Measure (OM).
For example, consumption power is a property and Watt is a unit of power that represents a definite predetermined power: when we say 10 Watt, we actually mean 10 times the definite predetermined power "Watt".
is produced by
Links a commodity to the feature kind, feature of interest, or device, that produces it
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.
V3.2.1: Simplified definition and axiomatization of saref:Function. Added examples.
To accomplish the task of washing clothes, a washing machine should have a function for washing.
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.
To accomplish the task of sensing the temperature, a temperature sensor should have a sensing function.
Feature kinds
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.
V3.2.1: Introduced class saref:FeatureKind
V3.2.1: Use SKOS to organize generic classes in taxonomies.
when state
Links a profile to a state that contributes to restricting its applicable context.
Command Of Interest
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.
V3.2.1: Introduced saref:CommandOfInterest, parallel to saref:PropertyOfInterest.
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 targeted.
Like for commands, commands of interest may be described in terms of their input parameters, outputs, and which properties or states they target.
The corridor smart light switch supports a command of kind “turn on/off”, which controls the state of the outdoor light.
The smart fridge supports a command of kind “observe temperature”, which observes the temperature of the fridge.
is measured in
A relationship identifying the unit of measure used for a certain entity.
V3.2.1: Relaxed domain of saref:isMeasuredIn so it can apply to saref:PropertyValue as well as saref:Measurement. The new range will be enforced in the next major revision of SAREF.
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 command of interest
Links a function of interest to one of its commands of interest.
consumes
Links a feature kind, feature of interest, or device, to the commodity it consumes
V3.2.1: Introduced saref:consumes, saref:isConsumedBy, saref:produces, saref:isProducedBy, saref:stores, saref:isStoredBy.
has value
Value of a property value expressed as an RDF literal. Note that, even if decimal values are expected, values could use other datatypes.
V3.2.1: Clarified definition of saref:hasValue.
has phenomenon time
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.
V3.2.1: Introduced saref:hasPhenomenonTime as part of general will to make SAREF and SOSA/SSN converge.
is command of
Links a command and a function or function of interest that supports it.
is observed by
Links a feature, property, or state, to the device, function, command, or procedure execution, that observes it.
is accomplished by
A relationship identifying an entity (e.g., a device) that can accomplish a task.
is state of interest of
Links a state of interest to the feature of interest it is a state of.
Command Execution
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).
Commodity
A marketable item which may be supplied without qualitative differentiation.
V3.2.1: Definition of saref:Commodity is simplified.
V4.1.1: Removed examples of commodity categories.
SAREF refers to energy commodities such as electricity, gas, coal and oil.
Concepts from existing code lists, vocabularies, and taxonomies, may be used as instances of saref:Commodity, for example from the ISDA taxonomy of commodities, the Standard International Energy product Classification (SIEC), the IRENA Energy Taxonomy or Wikidata.
is function of
Links a function to the feature kind or device it is a function of.
V3.2.1: Introduced saref:isFunctionOf.
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 result
Links a procedure execution (e.g., an observation) to its result (e.g., a property value).
V3.2.1: Introduced saref:hasResult as part of general will to make SAREF and SOSA/SSN converge.
made by
Links a procedure execution to the entity (e.g., device) that made it.
V3.2.1: Introduce saref:madeBy (resp. saref:madeExecution) as generalization of saref:measurementMadeBy (resp. saref:makesMeasurement).
has device kind
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 manufacturer
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.
V3.2.1: Defined domain of saref:hasManufacturer to union of feature kind and feature of interest.
Procedure Execution
Represents the act of carrying out a procedure.
V3.2.1: Introduced saref:ProcedureExecution.
has operation
Links a service to one of its operations.
has result time
Links a procedure execution to the instant of time when the activity was completed, expressed as an xsd:dateTime literal.
V3.2.1: Introduced saref:hasResultTime as part of general will to make SAREF and SOSA/SSN converge.
stores
Links a feature kind, feature of interest, or device, to the commodity it stores
has state kind
links a state of interest to its kind, a state
has profile
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.
V3.2.1: Relaxed domain of saref:hasProfile to saref:FeatureKind or saref:Device
Operation Execution
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.
when property value
Links a profile to a property value that contributes to restricting its applicable context.
has timestamp
Links a procedure execution or a profile to an instant.
V3.2.1: Tried to clarify definition of saref:hasTimestamp. Still unclear.
Applied on a profile, it describes the applicable instant of that profile
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.
Task
The goal for which a device is designed, from a user perspective.
Tasks can be accomplished by devices (saref:isAccomplishedBy).
For example, a washing machine is designed for the task of washing.
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.
V3.2.1: Relaxed domain and range of saref:represents.
has mandatory command
Links a function and one of its mandatory commands
V3.2.1: Introduced mandatory and optional commands.
is property of interest of
Links a property of interest to the feature of interest it is a property of.
Actuator
A device designed to control one or more properties or states of one or more features of interest.
V3.2.1: Definition of Actuator is simplified and grounded on saref:controls. Local restriction on saref:hasFunction is deleted.
is value of state
Links a state value to the state or state of interest it is a value of.
V4.1.1: Introduced saref:isValueOfState.
has input
Links a command, operation, or procedure execution, to its inputs.
V3.2.1: Introduced saref:hasInput and saref:hasOutput.
Different complementary commands can be defined for controlling a light. Turn on or off the light based on a desired state, toggle the light status of a specific light, set the luminosity level with a transition time, set the default transition time, start comfort.
is state of
Links a state to the feature kind or feature of interest it is a state of.
V3.2.1: Introduced saref:isStateOf.
is controlled by
Links a feature, property, or state, to the device, function, command, or procedure execution, that controls it.
V3.2.1: Introduced property saref:isControlledBy.
has identifier
Links some entity to its identifier. Extensions of SAREF may define sub-properties such as s4abcd:hasUUID, s4abcd:hasGTIN12, etc.
accomplishes
Links a certain entity (e.g., a device) to the task it accomplishes.
State Value
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).
V4.1.1: Introduced saref:StateValue.
has revision number
Links some entity (e.g., a device) to its revision number.
has state of interest
Links a feature of interest to one of its states of interest.
V3.2.1: Introduced saref:hasStateOfInterest and saref:isStateOfInterestOf, parallel to saref:hasPropertyOfInterest and saref:isPropertyOfInterestOf.
controls
Links a device, function, command, or procedure execution, to the feature, property, or state, it controls.
V3.2.1: Introduced property saref:controls, as sub-property of saref:targets. and generalization of saref:controlsProperty.
Appliance
A device designed to accomplish a particular task for occupant use. It consumes, produces, or stores, some commodity.
V3.2.1: Definition of saref:Appliance is grounded on tasks and commodities.
State of Interest
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.
V3.2.1: Introduced saref:StateOfInterest, parallel to saref:PropertyOfInterest.
Per convention, the IRI of states of interest should consist of the IRI of their feature of interest, suffixed with a fragment identifier #{S} where {S} refers to the name of the state.
A state of interest is the state of (OP saref:isStateOfInterestOf) exactly one feature of interest.
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 states of interest.
is command of interest of
Links a command of interest to the function of interest it is a command of.
is profile of
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 output
Links a command or operation to its outputs.
Different complementary commands can be defined for observing a smart home. Observe the temperature once will output the indoor temperature property; observe status of the entry door will output an open/close state.