## SAREF patterns for states

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

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

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

SAREF Core pattern for States: states and states of interest

### States

#### Creating states

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

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

The identifier and the label of an instance of state should not contain "state" and its comment may mention "state kind" or "kind of state".

EXAMPLE:

    ex:Open a saref:State ;
          rdfs:label "Open"@en ;
          rdfs:comment "The situation of being in an open state. A kind of state"@en .

#### Specializing states

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

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

NOTE: Depending on the use case, the state can explicit the physical dimension of the property it relates to (ex. ex:ColdTemperature), the feature of interest it applies to (ex. ex:AlarmActivated), the individual states kinds below in the taxonomy (ex. ex:OpenClose), etc.

EXAMPLE: ex:Open is a specialization of ex:OpenClose.

    ex:Open a saref:State ;
          skos:broader ex:OpenClose ;
          rdfs:label "Open"@en ;
          rdfs:comment "The situation of being in an open state. A kind of state."@en.

#### Categorizing states

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

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

The identifier, and the label of a state class should end with "State", and its comment should mention "state class" or "class of states".

EXAMPLE: The class ex:WashingState groups states related to the phases in which a washing device may be in.

    ex:WashingState a owl:Class ;
          rdfs:subClassOf saref:State ;
          rdfs:label "Washing State"@en ;
          rdfs:comment "Class of states related to the washing phases."@en .

### States of interest

#### Creating states of interest

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

Given a state of interest belongs to exactly one feature of interest, its identifier should consist 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".

A specific instance of the class saref:StateOfInterest should link to its kind (an instance of saref:State) using property saref:hasStateKind, and to the unique feature of interest it is a state of using OP saref:isStateOfInterestOf.

#### Categorizing states of interest

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

### Specializing OPs and DPs related to states

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

- saref:hasState
- saref:isStateOf
- saref:hasStateOfInterest
- saref:isStateOfInterestOf
- saref:hasStateKind

NOTE: In some SAREF extensions or application, it may be specified that features of interest of a specific category can have only one state of a certain kind. Cardinalities different than zero or one should not be defined using this type of axioms.

EXAMPLE:

    ex:WaterDevice a owl:Class ;
              rdfs:subClassOf saref:Device , [
                  owl:onProperty saref:hasState ;
                  owl:cardinality 1 ;
                  owl:onClass [
                      owl:onProperty saref:hasStateKind ;
                      owl:hasValue ex:HotInletOpenClose ] ] .