Keywords

1 Introduction

The Smart Appliance REFerence ontology (SAREF) is a shared model of consensus developed in close interaction with the industry to facilitate the matching of existing assets (i.e., standards, data models, protocols, specifications) in the smart appliances domain. Smart appliances are intelligent and networked devices that accomplish some household functions, such as cleaning or cooking. Smart appliances play an active role in the energy management of the buildings and are of strategic importance in achieving the goal of higher energy efficiency in the European economy [1]. SAREF focuses on the concept of “device”, which is a tangible object designed to accomplish a particular task in households, common public buildings or offices. In order to accomplish this task, a device performs one or more “functions”. For example, a washing machine is designed to wash (task) and to accomplish this task it performs, among others, a start and stop function. When connected to a network, a device offers a “service”, which is a representation of a function to a network that makes the function discoverable, registerable and remotely controllable by other devices in the network. A device is also characterized by an “energy profile” and a “power profile” that can be used to optimize the energy efficiency in a home or office that are part of the building. SAREF is expressed in OWL-DL and contains 124 classes, 56 object properties and 28 datatype properties. The documentation of SAREF is available onlineFootnote 1 where the ontology file can be downloaded in Turtle formatFootnote 2. A detailed description of the main classes and properties of SAREF can be found in our earlier work [3], in which we also described the approach taken during the SAREF development and we articulated the general principles learned from our experience in working with the community of industrial practitioners in the ontology creation process.

In this paper we focus on specific aspects of SAREF’s development cycle, such as the stakeholders’ requirements, the fundamental design principles used to create the ontology and the best practices followed to describe, document and publish SAREF in order to promote its usage in the smart appliances community. Moreover, we discuss the work to be done in the immediate future for SAREF to evolve concerning its maintenance, versioning, extension and governance. Open questions are how to guarantee the correct usage of SAREF, how to systematically organize future extensions and specializations in a consistent network of ontologies, and who should be responsible for these activities. The paper is structured as follows. The next section addresses various aspects that help to understand the modelling decisions underlying SAREF (i.e., requirements, principles and best practices), followed by the discussion on the maintenance, versioning, extension and governance of the ontology network sprouting from SAREF. The final section concludes the paper.

2 SAREF: Requirements, Principles and Best Practices

One of the most important stakeholders of SAREF is the European Commission (EC). The lack of a shared model of consensus in the smart appliances industry is a bottleneck for the EC to reach their energy saving ambitions [2, 4, 5]. Therefore the EC financed the development of the initial version of SAREFFootnote 3 [2], which project we subsequently executedFootnote 4. During the development of SAREF, we had to take into account various requirements that the EC specifically mentioned in the tender document [2], and additional requirements set by our industrial collaborators. Often this meant that we had to balance apparently contradicting requirements. For example, the tender specification indicated OWL as the preferred ontology language for the project. However, the tender also stated that “the tenderer is free to suggest in his offer other tools or formalized languages, especially if they could facilitate collaborative aspects of ontology development and dynamic evolution of ontology networks in distributed environments”. We decided to use OWL-DL as suggested, since it provided us with formal semantics and allowed a sufficient degree of semantic reasoning, being supported by a large number of software reasoning and consistency checking tools. Moreover, the tender required SAREF to be as complete as possible “to cover the needs of all appliances relevant for energy efficiency”, and at the same time optimize the ontology “to be synthetic, compact and with the minimum redundancy”. The reference ontology resulting from our work was also meant to cover all semantic requirements as discovered in the project, but also “designed in a way that it can be expanded to cover future intelligence requirements”. Finally, from a foundational point of view, we wanted to have a well axiomatized ontology to exploit the reasoning capabilities offered by OWL-DL, although the tender stated that the ontology under development was expected to be “a rather simple ontology as compared of state of the art ontology engineering level of complexity”. In conclusion, it was required to produce an artefact with an exhaustive coverage in which all the different stakeholders in the domain could recognize their work, but which should be also rather simple, understandable and easy to use, in order to ease the adoption by the stakeholders. This was not a trivial task, and as described in [3] we had to compromise between the conceptual thinking underlying the world of formal ontologies and the more practical point of view of industrial stakeholders.

We created SAREF using fundamental principles of ontology engineering [6], such as reuse and alignment of concepts that are defined elsewhere. Since a large amount of work was already being done in the smart appliances domain, we have not invented anything new, but harmonized and aligned what was already there. The SAREF ontology was therefore built using core concepts that describe existing semantic assets (i.e., standards, data models, protocols, specifications) in the smart appliances community. A mapping that aligns concepts from existing semantic assets to core concepts in SAREF is available at the project websiteFootnote 5 as a complementary file to the project’s final deliverable [7]. Moreover, SAREF reuses ontologies and vocabularies that have been developed in the Semantic Web community. In particular, SAREF directly imports the W3C WGS84 geo positioning vocabularyFootnote 6 and the W3C Time ontologyFootnote 7. SAREF also refers to the Ontology of units of Measure (OM)Footnote 8 to define the members of its “unit of measure” subclasses, such as the “power unit” class in the following example:

We have not directly imported OM since we only needed a reference to some basic units of measure and not the entire reasoning capability of this complex ontology, which in our opinion, if imported, would have confused the smart appliances industry - main user of SAREF - who is rather pragmatic and not acquainted with (complex) ontologies. In contrast, we decided to include the W3C WGS84 geo positioning vocabulary and the W3C Time ontology as direct imports to fully exploit their reasoning capability and since they are reasonably small and usable also by non-expert users.

SAREF is furthermore based on the principle of modularity to allow separation and recombination of different parts of the ontology depending on specific needs. Towards this aim, SAREF provides building blocks that can be combined to accommodate different needs and points of view. The starting point in SAREF is the concept of “device”. For example, a “switch” is a device. A device is always designed to accomplish one or more functions. Therefore, SAREF offers a lists of basic functions that can eventually be combined in order to have more complex functions in a single device. For example, the mentioned switch offers an actuating function of type “switching on/off”. Each function has some associated commands, which can also be picked up as building blocks from a list. For example, the “switching on/off” function is associated with the commands “switch on”, “switch off” and “toggle”. Depending on the function(s) it accomplishes, a device can be found in a corresponding state. States are also listed as building blocks, making it easy and intuitive to combine devices, functions and states. The switch considered in our example can be found in one of the two states “on” or “off”. SAREF also provides a list of properties that can be used to further specialize the functioning of a device. For example, a “light switch” specializes the more general “switch” for the purpose of controlling the “light” property.

According to best practices in the Semantic Web, SAREF includes basic metadata that allow others to correctly understand and properly reuse the ontology, such as creator, publisher, date of issue, title and descriptionFootnote 9. SAREF is self-descriptive since it contains labels, definitions and comments for its classes, and we also created a human-readable description that explains the main classes and properties. This description is available at the project websiteFootnote 10, together with the descriptions of the technology- and domain-specific ontologies that we used for the construction of SAREFFootnote 11. We published the SAREF ontology at a stable URL (http://w3id.org/saref) in order to guarantee persistent access and facilitate its (re)usability in the smart appliances community.

3 Discussion

In this section we discuss the work to be done in the immediate future for SAREF to evolve and stay relevant to the EC and industry, also now that the initial project is completed. This work concerns the usage, extension, maintenance, versioning and governance of SAREF. The observations follow from our experience in the development of SAREF, but can be generalized for other (networks of) ontologies in different application domains. First, the adoption of SAREF and its correct usage need to be promoted. During the project, the EC and ETSI organized a number of workshops to allow us to publicly present SAREF, answer the stakeholders’ questions and collect their feedback in an interactive fashion. Version 1.0 of SAREF is available online since the end of the project and can be used by anybody that is interested in its capabilities. SAREF’s online documentation is supported by the project’s ad-interim reportsFootnote 12, which are collected and harmonized in the final deliverable [7]. However, no explicit strategy has been defined on how to support users in using SAREF, especially if they only need a limited set of capabilities that suit their purpose, instead of the entire model. This issue becomes even more relevant when the interested users are not ontology experts, and therefore not acquainted to create new ontologies by importing or referencing to concepts defined elsewhere. We therefore conclude that there is a need for flexible and user-friendly solutions in terms of tools, methods, guidelines and best practices to (1) further promote the adoption of SAREF, and (2) allow third-party developers and users to utilize the ontology, either the whole model or a relevant subset of it.

Another important observation comes from the fact that SAREF is a conceptual artefact that does not cease to live because the project in which it was conceived is finished. SAREF has its own lifecycle and we expect it to continuously evolve in the future to cover new domains that are relevant in the home environment, such as e-health and entertainment. There will be new devices and consequently new functions, commands, services and so forth to be added as extensions to SAREF. Furthermore, it would be extremely beneficial to enhance the reasoning capabilities of SAREF by enabling its extension by means of rules. Moreover, the current concepts in SAREF are rather high-level, since SAREF contains core concepts that are recurring in the smart appliances domain. These concepts need to be specialized into a finer-grained level of detail to accommodate the requirements of specific use cases that come at hand. As a consequence, we envision that SAREF will grow into a network of ontologies that will require some governance. We should therefore investigate a modular and consistent way to enable this growth, while acknowledging that different stakeholders should be able to 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 linked to existing concepts in SAREF. The minimum requirement is therefore that any extension/specialization must import or refer to SAREF.

An example on how to extend SAREF as described above is provided by an interoperability initiative taken by the EEBusFootnote 13 and Energy@homeFootnote 14 associations. The initiative includes the development of an extension of SAREF to bridge the semantic gap between the EEBus and Energy@home data models. These two data models focus on the same concept, namely the concept of “power profile”, but they use different terminologies. A power profile contains the information about the consumption and production of smart appliances in the household, for example a washing machine or a refrigerator. This information is exchanged between the appliances and the Consumer Energy Manager (CEM) for the purpose of energy efficiency optimization. SAREF already contains the concept of power profile, but this concept needs to be specialized in more detail in order to accommodate the specific requirements of the use cases prescribed by EEBus and Energy@home. This initiative helps with creating the envisioned network of ontologies, learning by experience from these use cases, and laying out (initial) best practices that can be reused and improved by anybody interested in this task.

An additional and essential point of discussion concerns who should be responsible for the extension of SAREF, its maintenance and, more in general, the governance of the envisioned network of ontologies. Not only SAREF, but also the network of ontologies needs to be maintained in order to identify and correct defects, accommodate new requirements, and cope with changes over time. In principle, anybody can create a new ontology that makes use of SAREF and the creator of such ontology is responsible for its maintenance and versioning, independent from SAREF. In this way, the maintenance of the network will be distributed over the creators of the new ontologies sprouting from SAREF. To avoid inconsistency and confusion, we in contrast believe that the maintenance of SAREF should be delegated to a single party (e.g., an individual organization or a group of organizations) who should also take care of aligning SAREF with new ontologies in the network when necessary. Consider, for example, the case in which several extensions, like the one created for EEBus and Energy@home, are developed to accommodate different use cases, but present common recurring concepts or properties that could be “promoted” as core-upper concepts in SAREF. Which organization is going to implement the necessary updates and create the new version of SAREF? TNO could be a natural candidate as the creator of the first version of SAREF, but it is the EC who is the official owner of SAREF, ETSI is given the responsibility to adopt SAREF as a Technical Specification (TS) [8], and a large number of industrial stakeholders have closely collaborated as domain experts in SAREF’s development. Also new parties such as W3C could play a role.

4 Conclusions

This paper follows our earlier work [3] in which we presented SAREF, the Smart Appliances REFerence ontology, pointing out the lesson learned from our collaboration with the industry during the ontology development process. In this paper we elaborated on several aspects of the development lifecycle of SAREF. We discussed various requirements that we had to take into account when creating SAREF, partly mentioned by the EC in the tender document, but also set by our industrial collaborators during the development process. Often this meant that we had to balance apparently contradicting requirements. We furthermore discussed how SAREF is based on fundamental principles of ontology engineering, such as reuse and modularity. We also pointed out best practices that we have used to describe, document and publish SAREF in order to guarantee persistent access and facilitate its (re)usability in the smart appliances community. We finally discussed the work to be done in the immediate future for SAREF to evolve concerning its maintenance, versioning, extension and governance. We concluded that there is a need for flexible and user-friendly solutions to further promote the adoption of SAREF and allow third-party developers and users to utilize the ontology, either the whole model or a relevant subset of it. Moreover, we identified the need for suitable mechanisms to define the SAREF extension and maintenance workflow, manage SAREF extensions and changes submitted by its users, possibly exploiting state-of-the-art versioning and consistency checking. The question of which organization(s) should be responsible for the maintenance, extension and governance of the SAREF network of ontologies remains open and needs special attention in the immediate future.