The Smart Applications REFerence Ontology (SAREF)

SAREF Design Principles

The Smart Applications REFerence ontology (SAREF) is conceived as a shared model of consensus that facilitates the matching of existing semantic assets for building smart applications, reducing the effort of translating from one asset to another, since SAREF requires one set of mappings to each asset, instead of a dedicated set of mappings for each pair of assets.

Different semantic assets share some recurring, core concepts, but they often use different terminologies and adopt different data models to represent these concepts. Using SAREF, different assets can keep using their own terminology and data models, but still can relate to each other through their common semantics. In other words, SAREF enables semantic interoperability in smart applications through its shared, core concepts.

SAREF explicitly specifies recurring core concepts in smart applications, the main relationships between these concepts, and axioms to constrain the usage of these concepts and relationships. SAREF has been created based on the following fundamental principles:

Reuse and alignment of concepts and relationships that are defined in existing assets. Since a large amount of work was already being done in the smart appliances and in the Internet of Things domains, nothing has been re-invented, but harmonized and aligned what was already there. SAREF is based on the core concepts that were identified as especially relevant to describe the existing semantic assets for smart applications and is aligned to the main classes and properties of the oneM2M base ontology [i.1]. SAREF reuses the following resources:

• oneM2M base ontology [i.1];
• W3C® SKOS ontology [i.4];
• OGC® and W3C® SOSA/SSN ontology [i.5];
• OGC® and W3C® Time ontology [i.6];
• OGC® GeoSPARQL vocabulary [i.7].

SAREF currently does not contain explicit references to upper ontologies such as DUL or SUMO. The use of upper ontologies is a best practice in ontology engineering, but the industrial world - main user of SAREF - is very pragmatic and is not acquainted with high-level upper ontologies. Introducing DUL would have unnecessarily complicated the understanding and, consequently, the adoption of SAREF by the industry. Anyway, SAREF has been built on a solid ontological foundation and can be related to DUL, but this was not explicitly done in order not to confuse industry users. Furthermore, SAREF currently has mappings to the OGC® and W3C® SOSA/SSN ontology, which is in turn related to DUL. Therefore, SAREF currently includes an indirect reference to DUL through the OGC® and W3C® SOSA/SSN ontology.

Modularity to allow separation and recombination of different parts of the ontology depending on specific needs. SAREF provides building blocks that can be combined to accommodate different needs and points of view. The starting point is the concept of device, which is actually common to all the semantic assets considered in the study, although some assets may refer to it with different names, such as resource or product, but mappings for that are provided in [i.9]. A device is always designed to perform one or more functions, therefore, SAREF offers a list of basic functions that can be eventually combined in order to have more complex functions in a single device. Each function has some associated commands, which can also be selected as building blocks from a list. Depending on the function(s) it performs, a device can be found in some corresponding states that are also listed as building blocks, so that it is easy and intuitive to combine devices, functions and states. SAREF also provides a list of properties that can be used to further specialize the functioning of a device.

Extensibility to allow further growth of the ontology. Different stakeholders can specialize the SAREF concepts according to their needs and points of view, add more specific relationships and axioms to refine the general (common) semantics expressed in the reference ontology, and create new concepts, as long as they explicitly link these extensions to at least one existing concept and/or relationship in SAREF. The minimum requirement is that any extension/specialization shall comply with SAREF. Examples of extensions of SAREF in different domains are SAREF4ENER (energy domain) [i.10], SAREF4ENVI (environment domain) [i.11] and SAREF4BLDG (building domain) [i.12]. SAREF and extensions are based on patterns that are used in different domains. SAREF extension developers should reuse SAREF reference ontology patterns as specified in ETSI TS 103 548 [i.3].

Maintainability to facilitate the process of identifying and correcting defects, accommodate new requirements, and cope with changes in (parts of) SAREF. According to the extensibility criterion mentioned above, a new module/ontology can be created to further extend/specialize concepts of SAREF. The party that creates the extension should also be responsible for the maintenance of this extension and its evolution over time. SAREF extension developers shall comply with the SAREF Development Framework and Workflow as specified in ETSI TS 103 673 [i.2]. For an initial strategy proposed in ETSI to extend, maintain and evolve SAREF (and its extensions), see ETSI TR 103 411 [i.8].