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 functions

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

Introduction

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

The figure below illustrates the main classes and properties in the SAREF Core patterns for Functions.

SAREF Core pattern for Functions: functions and functions of interest
SAREF Core pattern for Functions: functions and functions of interest

Functions

Creating functions

SAREF extensions should create instances of the class saref:Function, such that they can be reused in different SAREF applications.

SAREF applications may also create specific instances of the class saref:Function.

The identifier and the label of an instance of function should end with "Function" and its comment may mention "function kind" or "kind of function".

EXAMPLE:

ex:OnOffControlFunction a saref:Function ;
            rdfs:label "on off function"@en ;
            rdfs:comment "The on off function represents the functionality to control the on/off state of a feature of interest. The on off function has three optional commands to turn on, to turn off, and to toggle the state."@en ;
            saref:controls ex:OnOff .

Specializing functions

SAREF extensions may define a taxonomy of functions using skos:broader and skos:narrower.

The identifier, the label, and the comment of an instance of saref:Function should explicit its position in the taxonomy of functions.

NOTE: The set of functions is specialized down the taxonomy of functions. The observed or controlled property or state may be specialized, individual commands may be specialized, new commands may be introduced, optional commands may be deleted or become mandatory, etc.

EXAMPLE: ex:ColorLightControlFunction, may be a specialization of ex:LightControlFunction.

Categorizing functions

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

The identifier, the label, and the comment of a sub-class of saref:Function should explicit its position in the hierarchy of function classes.

The identifier, and the label of a function class should end with "FunctionCategory", and its comment should mention "function class" or "class of functions".

EXAMPLE: The class ex:LightingFunctionCategory groups functions related to the lighting task.

ex:LightingFunctionCategory a owl:Class ;
            rdfs:subClassOf saref:Function, [
                a owl:Restriction ;
                owl:onProperty saref:accomplishes ;
                owl:hasValue ex:Lighting ] ;
            rdfs:label "Lighting Function Category"@en ;
            rdfs:comment "Category of functions that accomplish lighting."@en .

Functions of interest

Creating functions of interest

SAREF extensions should not create specific instances of the class saref:FunctionOfInterest, as they are meant to be specific to an application. The only exceptions to this provision are if the associated device is intended to be used by most applications of the SAREF extension.

Given a function of interest belongs to exactly one device, its identifier should consist of the identifier of the device, followed by character '#' and a fragment identifier. The fragment identifier part of the IRI of a state of interest should not contain "function".

A specific instance of the class saref:FunctionOfInterest should link to its kind (an instance of saref:Function) using property saref:hasFunctionKind, and to the unique device it is a function of using OP saref:isFunctionOfInterestOf.

Categorizing functions of interest

SAREF extensions should not define sub-classes of saref:FunctionOfInterest, as this would duplicate information already part of the taxonomy of functions.

Specializing OPs and DPs related to functions

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

  • saref:hasFunction
  • saref:isFunctionOf
  • saref:hasFunctionOfInterest
  • saref:isFunctionOfInterestOf
  • saref:hasFunctionKind