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 features

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

Introduction

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.

Class saref:FeatureKind allows 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.

The figure below illustrates the main classes and properties in the SAREF Core patterns for Feature kinds and features of interest.

SAREF Core pattern for Features: feature kinds and features of interest
SAREF Core pattern for Features: feature kinds and features of interest

Feature kinds

Creating feature kinds

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

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

The identifier and the label of an instance of feature kind should not contain "feature". Its comment should mention "kind". The identifier should not end with "Kind".

EXAMPLE:

ex:1000x2000mmWindow a saref:FeatureKind ;
      rdfs:label "1000x2000mm window kind"@en ;
      rdfs:comment "The kind of windows with dimensions 1000x2000mm."@en;
      saref:hasPropertyValue 
          [   saref:hasValue 1000 ;
              saref:hasUnit <http://qudt.org/vocab/unit/MilliM> ;
              saref:isValueOfProperty saref:Width ] ,
          [   saref:hasValue 2000 ;
              saref:hasUnit <http://qudt.org/vocab/unit/MilliM> ;
              saref:isValueOfProperty saref:Height ].

Specializing feature kinds

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

The identifier, the label, and the comment of an instance of saref:FeatureKind should explicit its position in the taxonomy of feature kinds.

EXAMPLE: ex:1000x2000mmSmartWindow is a specialization of ex:1000x2000mmWindow.

  ex:1000x2000mmSmartWindow a saref:FeatureKind ;
      rdfs:label "1000x2000mm smart window"@en ;
      skos:broader ex:1000x2000mmWindow ;
      rdfs:comment "The kind of smart windows with dimensions 1000x2000mm, controlled by an electric window actuator."@en ;
      saref:hasPropertyValue
          [   saref:hasValue 1000 ;
              saref:hasUnit <http://qudt.org/vocab/unit/MilliM> ;
              saref:isValueOfProperty saref:Width ] ,
          [   saref:hasValue 2000 ;
              saref:hasUnit <http://qudt.org/vocab/unit/MilliM> ; 
              saref:isValueOfProperty saref:Height ] ;
          saref:isControlledBy ex:ElectricWindowActuatorKind .

Categorizing feature kinds

SAREF extensions and applications may define categories of feature kinds by creating sub-classes of saref:FeatureKind.

NOTE: Defining categories of features kinds is especially useful to group those feature kinds that are defined in the same taxonomy.

The identifier, the label and the comment of a sub-class of saref:FeatureKind should explicit its position in the hierarchy of feature kind classes. The identifier should end with "Kind".

EXAMPLE: The class ex:WindowKind groups all window kinds of a taxonomy ex:.

ex:WindowKind a owl:Class ;
      rdfs:subClassOf saref:FeatureKind ;
      rdfs:label "Window Kind"@en ;
      rdfs:comment "Category ex:WindowKind groups archetypes of real world windows."@en .

Features of interest

Creating features of interest

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

NOTE: The only exceptions to this provision are if the feature of interest is intended to be used by most applications of the SAREF extension.

The identifier and the label of an instance of feature of interest should not contain "of interest". The comment may mention "feature of interest".

EXAMPLE: The earth atmosphere is unique and may be used in most applications related to earth satellite observations.

ex:EarthAtmosphere a saref:FeatureOfInterest ;
      rdfs:label "Earth Atmosphere"@en ;
      rdfs:comment "The earth atmosphere."@en .

Categorizing features of interest

SAREF extensions and applications may define categories of features of interest by creating sub-classes of saref:FeatureOfInterest.

NOTE: Defining a category of features of interest 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: The category ex:Window is the range of OP ex:hasExteriorWindow.

ex:Window a owl:Class ;
      rdfs:subClassOf saref:FeatureOfInterest ;
      rdfs:label "Window"@en ;
      rdfs:comment "Class of windows: an opening in the wall or roof of a building or vehicle, fitted with glass in a frame to admit light or air and allow people to see out."@en .
  ex:hasExteriorWindow a owl:ObjectProperty ;
      rdfs:range ex:Window .

It is possible to define hierarchies of feature of interest classes by defining sub-class relationships between them.

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

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

The main categories a feature of interest belongs to are the classes it explicitly instantiates.

EXAMPLE 2: Feature of interest <1000x2000mmSmartWindow_az21az4ze1> is categorized under ex:Window, and has feature kind ex:1000x2000mmSmartWindow.

<1000x2000mmSmartWindow_az21az4ze1> a ex:Window ;
      saref:hasFeatureKind ex:1000x2000mmSmartWindow ;
      rdfs:label "1000x2000mmSmartWindow #az21az4ze1"@en ;
      rdfs:comment "1000x2000mm smart window with id az21az4ze1"@en .

Further categories are defined transitively through the class hierarchy.

EXAMPLE 3: By being an instance of ex:Window, a feature of interest also belongs to the type saref:FeatureOfInterest.

Feature kind vs category of features of interest

SAREF extensions can model a category of features of interest either as an instance of saref:FeatureKind or as a sub-class of saref:FeatureOfInterest. The modelling choice depends on the knowledge representation needs:

  • Use an instance of saref:FeatureKind to simply attach properties and optionally their values, states, related commodities, or related sensor kinds that can observe or control features of interest having this kind.
  • Use a sub-class of saref:FeatureOfInterest if the category needs to be defined as the domain or range of some relationship, modelled as an OP in the extension.

In all cases, it shall not happen that the same identifier is used for an instance of saref:FeatureKind and a sub-class of saref:FeatureOfInterest.

Specializing OPs and DPs related to features

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

  • skos:narrower
  • skos:broader
  • saref:hasManufacturer
  • saref:hasModel

There shall be a unique sub-property of saref:hasFeatureKind, with identifier saref:hasDeviceKind.