SAREF reference ontology patterns

The SAREF reference ontology patterns provide guidelines on how to use and extend SAREF concepts and relationships for the modelling and the description of any kind of applications-related data/information/systems. The SAREF reference ontology patterns can be applied to different verticals to provide the SAREF suite of ontologies a homogeneous and predictable structure, and to achieve higher semantic interoperability.

SAREF patterns for devices

NOTE: The text in this page is taken from ETSI TS 103 548, and therefore falls under the ETSI IPR Policy

Introduction

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.

The pattern for devices follows the pattern for feature kinds and features of interest.

The figure below illustrates the main classes and properties in the SAREF Core pattern for Devices.

SAREF Core pattern for Devices: device kinds and devices

Creating devices

SAREF extensions should not create specific instances of the class saref:Device, as they are theoretically specific to an application.

Categorizing devices

SAREF extensions and applications may define categories of devices by creating sub-classes of saref:Device.

NOTE: Defining a category of devices is especially useful for multi-typing, or to be able to use it as the domain or range of some relationship to other entities, captured as OPs in the extension.

EXAMPLE 1: s4watr:WaterDevice categorize devices that are also water assets.

s4watr:WaterDevice rdfs:subClassOf saref:Device , s4watr:WaterAsset ;
            rdfs:label "Water device"@en ;
            rdfs:comment "A water device is a device that is also a water asset."@en .

It is possible to define hierarchies of device types by defining sub-class relationships between them. SAREF already declares a hierarchy of device types that have to be reused when defining device type hierarchies (e.g. saref:Sensor or saref:Actuator).

It is recommended that the identifier, the label and the comment of a sub-class of saref:Device explicits its position in the hierarchy of device classes.

EXAMPLE 2: s4watr:WaterMeter rdfs:subClassOf saref:Meter , s4watr:WaterDevice ;

rdfs:label "Water meter"@en ;
            rdfs:comment "A water meter is an instrument intended to measure continuously, memorize, and display the volume of water passing through the meter."@en .

SAREF extensions should not place restrictions on the saref:Device class directly.

The main categories a device belongs to are the classes it explicitly instantiates.

EXAMPLE 3: Device <HTPMP_4A2EF1SI85> is categorized under ex:HeatPumpDryer_HTPMP and ex:AAHeatPumpDryer.

<HTPMP_4A2EF1SI85> a ex:HeatPumpDryer_HTPMP , ex:AADevice ;
            rdfs:label "HTPMP_4A2EF1SI85"@en ;
            rdfs:comment "Heat pump dryer of kind HTPMP with serial number 4A2EF1SI85"@en .

Further categories are defined transitively through the class hierarchy.

EXAMPLE 4: By being an instance of s4watr:WaterMeter, the meter in the example below also belongs to the following device types: s4watr:WaterDevice, saref:Meter and saref:Device.

<Meter4837QW123> a s4watr:WaterMeter .

Feature kind vs category of device

SAREF extensions can model a category of devices either as an instance of saref:FeatureKind or as a sub-class of saref:Device. The modelling choice depends on the knowledge representation needs, as defined in clause 5.2.4.

Specializing OPs and DPs related to devices

SAREF extensions and applications shall not define sub-properties of the following properties:

saref:hasDeviceKind
saref:actsUpon
saref:isActedUponBy
saref:observes
saref:isObservedBy
saref:controls
saref:isControlledBy