Facilitating Semantic Interoperability of Trustworthy IoT Entities in Cultural Spaces: The Smart Museum Ontology ^†

Abstract

Nowadays, cultural spaces (e.g., museums and archaeological sites) are interested in adding intelligence in their ecosystem by deploying different types of smart applications such as automated environmental monitoring, energy saving, and user experience optimization. Such an ecosystem is better realized through semantics in order to efficiently represent the required knowledge for facilitating interoperability among different application domains, integration of data, and inference of new knowledge as insights into what may have not been observed at first sight. This paper reports on our recent efforts for the engineering of a smart museum (SM) ontology that meets the following objectives: (a) represent knowledge related to trustworthy IoT entities that “live” and are deployed in a SM, i.e., things, sensors, actuators, people, data, and applications; (b) deal with the semantic interoperability and integration of heterogeneous SM applications and data; (c) represent knowledge related to museum visits and visitors toward enhancing their visiting experience; (d) represent knowledge related to smart energy saving; (e) represent knowledge related to the monitoring of environmental conditions in museums; and (f) represent knowledge related to the space and location of exhibits and collections. The paper not only contributes a novel SM ontology, but also presents the updated HCOME methodology for the agile, human-centered, collaborative and iterative engineering of living, reused, and modular ontologies.

1. Introduction

Artworks and ancient objects that are usually isolated in indoor or outdoor environments, such as closed or open museums, are exposed to various environmental conditions. This consequently leads to the necessity of continuously monitoring such conditions and curating the exposed objects in an efficient and automated manner. An efficient and constant curating and monitoring is not a straightforward process due to the variety and volume of the exposed objects, and also due to their condition (partially damaged/material wear). Apart from the external weather conditions, a large number of museum visitors could affect the overall indoor environmental conditions. For example, humidity and temperature can change significantly and lead to irreparable wear of exposed cultural heritage objects. To protect and preserve them, the continuous monitoring of environmental factors becomes a necessity [1]. Toward this objective, the latest advancements of the internet of things (IoT) technology related to observations and sensors, such as temperature and humidity, steam pressure, and illumination (among others), are utilized in the intelligent monitoring systems of a smart museum (SM) [2].

SM systems and monitoring applications could be advantageous, and not only for the environmental protection of the exposed artworks. Another “smart” application in this context is the enhancement of visitors’ cultural experience by developing comfortable environmental conditions as well as by recognizing and adapting to visitors’ preferences (dynamic profiling) [3]. Last but not least, the capabilities raised from the development of intelligent systems/apps for a SM can be extended to support energy saving plans and subsequently to a more environmentally friendly cultural space.

As already stated, a museum can be considered “smart” for different reasons, including but not limited to (a) the facilitation, monitoring and analysis of physical and virtual visits, (b) the intelligent interaction of users with artifacts, (c) the 3D reconstruction of missing parts of ancient objects, (d) the environmental monitoring and protection of artifacts, and (e) the enhancement and optimization of user experience. In any case, the major problem to deal with is the efficient and effective management of the heterogeneous (big) data that are continuously generated by diverse types of IoT entities (e.g., sensors, embedded devices, and smart applications) [4].

Toward tackling this interoperability and integration problem, several approaches based on ontologies have been proposed for the SM domain, e.g., [5,6]. These approaches are focused on the semantic representation of objects and their generated data in order to deal with the transformation and integration of the heterogeneous and diverse data to a unified semantic space. Similarly, in our work, a novel ontology is proposed with the aim to efficiently represent the required knowledge in a smart cultural space to support the following objectives:

(a)

Represent the knowledge related to trustworthy IoT entities deployed in SMs i.e., things (e.g., artworks, spaces), sensors, actuators, people, data, and applications;

(b)

Deal with the semantic interoperability and integration of SM applications and data;

(c)

Represent knowledge related to museum visits and visitors towards enhancing visiting experience;

(d)

Represent knowledge related to energy saving;

(e)

Represent knowledge related to the monitoring of environmental conditions in museums;

(f)

Represent knowledge related to the space and location of exhibits and collections.

This paper extends the work in [7] as follows:

(a)

It presents a new ontology that mainly reuses the MESO ontology presented in [7], along with other ontologies reused to support the SM requirements;

(b)

It presents in detail the applied ontology engineering methodology used for the development of the presented ontology;

(c)

It presents the evaluation of the new ontology using additional scenarios related to a SM, beyond saving-energy-related scenarios presented in [7];

(d)

It presents the integration of trustworthy IoT entities modeling demonstrated in the related scenarios.

In this paper, the newly developed SM ontology is presented as an effort to reuse and extend existing related ontologies in order to meet specific requirements of the proposed SM concept. Such requirements are not fully covered by the related works, as discussed in detail in the Related Work section. In addition, the proposed ontology (namely, SmartMuseumOnto) is developed following a collaborative, agile, and iterative approach to ontology engineering (OE), namely, the  human-centered collaborative ontology engineering methodology (HCOME) [8]. This collaborative and human-centered methodology is selected for the engineering of a live, evolved and reusable ontology. The second contribution of this paper, in addition to the engineered SM ontology, is the revised version of the selected OE methodology that complies with the latest recommendations for modular and agile OE [9]. The revised methodology and its application to the engineering of the proposed SM ontology are presented in Section 3, Section 4, Section 5 and Section 6.

The paper is structured as follows: Section 2 presents the related work. Section 3 presents the revised ontology engineering methodology HCOME. Section 4 presents the specification phase of the developed ontology, describing indicative scenarios of its use. Section 5 presents the formalized conceptualizations. Section 6 presents the evaluation/validation of the ontology. Section 7 discusses the findings of this work and their implications in the broadest context. Finally, Section 8 presents our conclusion and points out several directions for future research.

2. Related Work

The related work is organized in three subsections: (a) the related (and reused) ontologies, (b) the related systems/applications, and (c) related standardization efforts [10]. The survey methodology for selecting the related work is based on information sources related to semantic and cultural domains published in the last five years. We mainly searched for academic articles and relevant literature using the widely used scientific search engines, such as Google and Semantic Scholar, ResearchGate, ACM Digital Library, and IEEEXplore. The used keywords for searching were “semantic interoperability”, “ontology + IoT”, “IoT + semantic interoperability”, and “ontology + smart museum”.

2.1. Related Ontologies

Smart appliances reference (SAREF) ontology [11]. This ontology serves as a common conceptual model that can support the communication of existing standards, protocols and data models, mainly for smart appliances that use the ETSI TS 103 267: “SmartM2M” Smart Appliances Communication framework [12]. The SAREF’s initial data point is each smart device providing specific blocks while allowing the recombination and division of various parts of the ontology. The main disadvantage of SAREF is that it does not support all sensors and equipment that usually exist in a building. The SAREF ontology aims to enable interoperability between different solutions, providers, protocols, sensors in the IoT while contributing to the development of a bigger scale market, such as smart cities. SAREF can be easily adopted for many sectors, such as health, smart grid, energy management and others, by reusing its classes. It is accessible from SAREF’s formal web page [11].

SAREF4ENER ontology [13]. This OWL-DL ontology is tailored to the energy domain and extends SAREF ontology. In order to enable a communication and inner connection of different data models, the Italy- and Germany-based industry associations made by EEBus [14] and Energy@Home [15] created the SAREF4ENER ontology. SAREF4ENER is used as a customer energy manager (CEM) for smart grids and smart homes enabling demand response strategies. SAREF4ENER ontology has two types of classes, i.e., classes reused from other ontologies, such as SAREF, and classes introduced in SAREF4ENER. This extension provides the ability to reuse SAREF4ENER classes as an overall ontology schema. The main objective of this ontology is to facilitate smart energy management while adapting users’ preferences. It is accessible from the SAREF4ENER formal web page [13].

SAREF4BLDFG ontology [16]. This ontology is an extension of SAREF tailored in the building domain. Its main modification is the adaptation to the Industry Foundation Classes (IFC) [17] standard for buildings’ data and information. As a result, main building information about the building life cycle enables the missing interoperability between various building actors, such as architects, and building applications, such as construction. SAREF4BLDG is also an OWL-DL ontology that reuses SAREF classes and also has new classes, which include IFC devices and other physical objects in building spaces. It is accessible from the SAREF4BLDFG’s web page [17]. This ontology is reused in order to cover the objective (d) of energy saving.

RE-COGNITION ontology [18]. This ontology was recently proposed in a European Horizon 2020 project to model all the information and data needed to assure the communication of different modules, following the main principles of the web of things ontology. The ontology is a fusion of SAREF, SAREF4ENER, and SAREF4BLDFG and also an extension is made so as to add new building actors, such as the building manager, and various building roles, such as guest or administrator. The ontology reuses classes from all the aforementioned SAREF-extented ontologies and also includes new ones based on end-user requirements. The ontology is accessible from GitHub [19].

The IoT ontology developed in the work of Kotis and Katasonov (2013) [4] supports the automated deployment of IoT entities in heterogeneous IoT environments. It mainly serves as a semantic registry for the registration of devices/systems, as well as for the registration of applications that utilize the services provided by those devices/systems. In further work on this line of research [20], a simple and extensible trust model for representing IoT entities was proposed. This model is integrated in IoT ontologies to ensure the deployment of trustworthy IoT entities. In our work, the representation of trustworthy entities are of particular importance to meet the objectives of the ontology; therefore, this IoT trust model is reused.

The semantic sensor network (SSN) ontology [21] and the sensor observation, sample and actuator (SOSA) ontology [22] aim to represent knowledge about entities, relations and activities included in sensing, sampling and actuation in a flexible and coherent way. The SSN/SOSA has been reused in several IoT-related ontologies and is a main/base candidate for reuse in the proposed ontology either directly or indirectly (via the reuse of ontologies that already import SSN/SOSA). This work partially covers the objectives (a, d).

ThinkHome [23] combines artificial intelligence (AI) with semantic context considering building management from a holistic overview. BASont [24] ontology aims to model building automation in a modular way to facilitate interoperability and communication between various cases and tools. Finally, Dogont [25] offers an extensive model for the communication of all IoT devices of a smart home. These ontologies, as well as the ones discussed in the remaining paragraphs of this section, were also examined for their suitability to be reused in SmartMuseumOnto, according to their aim and objectives (with respect to the aim and objectives of SmartMuseumOnto).

The CIDOC conceptual reference model (CRM) [26] describes an ontology focused on the integration and interchange of heterogeneous cultural heritage information. The CIDOC-CRM ontology is used widely in the research community, as it can efficiently deal with the managing of data generated from diverse data sources. In addition, applications relying on CIDOC-CRM were developed, such as lightweight information describing objects (LIDO) [27] and linked art [28]. Specifically, LIDO stands out because of its ability to support a wide range of descriptive information about various objects located in museums. Linked art describes cultural heritage resources special for museum objects and provides interoperability with other systems with data related to culture. These works partially cover our objectives (c, f).

The Europeana data model (EDM) [29] refers to an ontology that was developed in order to collect, connect, and enrich the descriptions provided by Europeana data providers.

Schema.org [30] is a collaborative, community activity designed to create, maintain and promote schemata for structured data on the internet. In the context of cultural heritage, Schema.org allows the description of the creative work of many kinds of cultural resources. Hence, Schema.org is reused in the proposed ontology.

The museum energy-saving ontology (MESO) [7] aims to represent the knowledge related to trustworthy IoT entities deployed in energy-saving museum intelligent environments to support the interoperability and integration of entities, data, processes and systems. MESO is heavily reused in the proposed SM ontology to mainly cover the “energy-saving” objective. This work partially covers the objectives of our work (a, b, c, d, and e).

2.2. Related Systems and Applications

In the work of Hajmoosaei and Skoric [31], two types of ontologies are built following an iterative development methodology in order to manage the data generated by heterogeneous museum data sources. Specifically, a top-level ontology is built, consisting of entities of individual (local) ontologies. The definition of each local ontology is added to the top-level ontology that is able to hierarchically unify many local ontologies. The top-level ontology is applied on the metadata for the New Zealand museum and the local ontology on the data sources related to the information of New Zealand World War soldiers. Both ontologies are used to semantically model knowledge related to the different entities of the cultural heritage domain. Thus, functionalities, such as semantic search or data transferring, among diverse data sources of the New Zealand museum can be developed. Finally, a detailed representation of how EDM and CIDOC-CRM ontologies are used for the design and creation of New Zealand’s museum ontology is presented. This work partially fulfills our objective (b) in order to deal with the interoperability of heterogeneous data sources in the context of a SM.

In the related work of Vassilakis and Poulopoulos [32], the authors propose a system, namely exhiSTORY, in order to incorporate the advantages of semantics and IoT into the exhibits of a museum. Specifically, the semantic information and the corresponding descriptions generated by the smart exhibits are used in order to create stories about a subject. These exhibitions are placed in the smart place, connecting through a Wi-Fi network connection, and communicating and cooperating with the other exhibitions nearby. Furthermore, the exhiSTORY system applies personalization techniques in order to generate the proper story for each visitor depending on each profile. This work partially covers our objectives (a, b, c, and f).

In the related work of Yu and Zhou [33], the authors propose a scalable context-aware intelligent museum in order to help third-parties to develop independent applications. Specifically, the proposed system, named iMuseum, combines the advantages of the ontologies and hierarchical models to collect data of real visitors from handheld devices and then processes them in order to provide visitor-adaptable services. Furthermore, the proposed system follows a layer-developed architecture that is able to separate the context-aware applications from context providers. Finally, they develop two applications for demonstration purposes and evaluation of the proposed system. This work partially covers our objectives (a, b, c, and e).

In the related work of Vlachidis and Bikakis [6], the structure and the development process of the CrossCult knowledge base is described. Specifically, the authors define the CrossCult upper-level ontology by using the standard cultural heritage ontology CIDOC-CRM [26]. In addition, the proposed ontology incorporates a vocabulary for historically related data with a commonly agreed structure and tries to consolidate different cultural heritage data. The CrossCult ontology is reused in our proposed SM ontology. This work partially covers our objectives (b and f).

In the related work of Martini and Araújo [34], the authors develop an ontology in order to represent knowledge about the emigration phenomena, extracted from the data of the virtual Emigration museum. Based on the ontology of CIDOC-CRM [26] the proposed system tries to automatically translate plain text that includes emigration information into resource description framework scheme (RDF). In addition, the created RDF triples are stored into a database in order to be queried using the SPARQL query language https://www.w3.org/TR/rdf-sparql-query/, (accessed on 6 December 2021). This work partially covers our objectives (c).

In the related work of Chianese and Piccialli [35], a system for creating single smart spaces (s3) is presented. In particular, the objective of the intelligent cultural space produced is that it focuses on enhancing the user experience. End users have easy access to appropriate cultural heritage information while moving around the cultural environment. To achieve this, the authors have placed smart sensors, called smart crickets, around cultural objects, adopting the IoT paradigm. Smart applications connect to these smart crickets and retrieve data that interest and satisfy the visitor. This work partially covers our objectives (a, b, c, and e).

In the related work of Michalakis and Moraitou [36], an IoT system for the preservation of cultural heritage institution (CHI) collections is proposed. In this system, semantic web technologies are exploited for better organization and effective management of the data provided by IoT entities, according to the documentation proposed by scientists. For the knowledge representation, the system makes use of ontologies in order to enhance interoperability between the applications and data. This work partially covers our objectives (a, b, and e).

2.3. Related Standardization Efforts

The Alliance for Innovation in the Internet of Things (AIOTI) was initiated by the European Commission in 2016 to promote dialogue and interaction between internet of things (IoT) stakeholders in Europe and help create a dynamic European IoT ecosystem to accelerate the spread of IoT. AIOTI’s Working Group 3 focuses on standardization. One of the primary objectives of AIOTI is to foster experimentation, replication, and deployment of IoT and to support the convergence and interoperability of IoT standards. More details on this effort can be found at https://aioti.eu/, (accessed on 6 December 2021).

The EU officially recognizes ETSI as the European Organization for Standardization (ESO). ETSI provides its members with an environment to support the development, validation and testing of globally applicable standards for ICT systems and services in all sectors of industry and society. As already mentioned in Section 2.1, the SAREF ETSI TS 103 264 standard was developed as a reference ontology for smart devices. More details on this effort can be found at www.etsi.org/, (accessed on 6 December 2021).

ISO/IEC JTC1 is a joint committee of ISO and IEC created in 1987 to elaborate standards on IT. ISO/IEC JTC1/SC41, internet of things and related technologies, was created in 2016 and has already published 26 international standards specifically for IoT. ISO/IEC JTC 1/SC 41 developed ISO/IEC 30141 (IoT reference architecture) and ISO/IEC 20924 (IoT vocabulary). The current work includes the following:

• IoT trustworthiness framework (ISO/IEC 30149).
• Methodology for the trustworthiness of IoT system/device (ISO/IEC 30147).
• Data exchange platform requirements for IoT services (ISO/IEC 30161).
• Compatibility requirements and model for devices within industrial IoT systems (ISO/IEC 30162).
• Diverse use-cases covered by IoT.
• Monitoring the ongoing technology IoT requirements.
• Development of IoT standards that build on the foundational standards in relevant ISO/IEC JTC 1 Sub-Committees.

More details on this effort can be found at https://www.iec.ch/ords/f?p=103:23:508736678596334::::FSP_ORG_ID,FSP_LANG_ID:20486,25, (accessed on 6 December 2021).

oneM2M was formed in 2012, and it is a global initiative that develops specifications to ensure the efficient deployment of machine-to-machine (M2M) communication systems and the IoT. The oneM2M specifications provide a framework to support applications and services, such as the smart grid, connected car, home automation, public safety and health, and to encourage industries to join oneM2M to ensure that the solutions developed support their specific needs. oneM2M standards are open, accessible and internationally recognized. More details on this effort can be found at www.onem2m.org, (accessed on 6 December 2021).

Finally, the thing description (TD) ontology is an RDF axiomatization of the TD information model, one of the building blocks of the web of things (WoT). The TD ontology can be used to process contextual information on things and for alignments with other WoT-related ontologies. The WoT TD has been a W3C Recommendation since 9 April 2020. More details about this effort of the W3C WoT working group can be found at https://www.w3.org/2019/wot/td and https://www.w3.org/TR/wot-thing-description/, (accessed on 6 December 2021).

To conclude, in our work presented in this paper, a new ontology, namely SmartMuseumOnto, is proposed, since related works (ontologies, systems, and standards) individually do not fully cover in a unified/integrated manner the aim and objectives of our effort toward the semantic interoperability of trustworthy IoT entities living in cultural spaces, and specifically living in a SM. Having said that, related ontologies/standards are not ignored, but they are appropriately reused in the proposed ontology at the extent that they cover its requirements. For instance, the proposed SM ontology reuses W3C TD for the conceptualization of things in the SM domain, e.g., lamp and heater.

3. Engineering the SM Ontology

In general, ontologies are the basic building blocks on the semantic web for the modeling of structured knowledge and the inferencing of new knowledge. As stated in W3C’s OWL requirements documents [37], an ontology defines the terms (concepts and properties that capture the knowledge of a domain) used to describe and represent a domain of knowledge. Concepts are organized in a hierarchy that expresses the relationships among them by means of superclasses representing higher level concepts and subclasses representing specific (constrained) concepts. Properties are of two types: those that describe attributes (features) of the concepts, and those that introduce binary relations between the concepts. In this work, the proposed ontology focuses on the domain of the SM. An simple example ontology build for this domain is depicted in (Figure 1).

The proposed SM ontology is engineered following an agile, human-centered, collaborative and iterative approach to OE, namely the human-centered collaborative ontology engineering methodology (HCOME). An agile methodology consists of a set of practices through which the continuous repetition of development and testing activities is promoted collaboratively throughout the development of a project [20].

In this paper, we extend the HCOME methodology in the following ways. First of all, a new workflow (as depicted in Figure 2) is designed in order to capture the agile, human-centered, collaborative and iterative aspects of engineering live and modular ontologies, based on our long experience in using the HCOME methodology, and following the latest OE recommendations presented in related work [9], which in summary are as follows: (a) use collaborative tools to support collaborative OE, (b) provide early versions of the modular ontology that need to be evaluated and validated by knowledge workers in a continuous, iterative approach, (c) the engineered ontology should reuse third-party ontologies but also ensure the reuse of its own discrete modular parts by others, (d) support modular ontology definitions, mapping, and development of modules in shared collaborative workplaces. Secondly, in Phase 1 (specification) of the HCOME methodology, the tasks are designed to capture the ontological requirements’ specifications in a more efficient manner. Thirdly, in Phase 2 (conceptualization) of the HCOME methodology, a new process is introduced, i.e., Process 2.2 “Design modular ontology”, in order to efficiently capture the ontological design choices and preparations that are of particular importance to the development phase.

As depicted in the updated methodology’s workflow design (Figure 2), the HCOME methodology consists of three phases: the specification phase (1), the conceptualization phase (2), and the exploitation phase (3). Some tasks are performed in the personal space (P) of participating stakeholders (knowledge engineers, knowledge workers, domain experts), and some others in a shared space (S) that is established by the team for their collaboration.

3.1. Specification Phase (1)

The ontology specification phase is referred to for better capturing of the ontology requirements and is composed of two processes.

• Specify aim, objectives, team (Process 1.1, Figure 2). In this process, members of the team form working groups with the aim of collaboratively developing ontologies. The team members then decide on the subject and purpose of the ontology. More specifically, the following tasks are proposed to be performed:
  • Identify collaborators (S). The roles involved include knowledge workers, knowledge/ontology engineers and domain experts. Knowledge workers are the members of the team who solve problems or analyze data by exploiting the ontology in operational conditions. Knowledge/ontology engineers are people who have experience in fields, such as knowledge reproduction or ontology tools to make ontological specifications, and coordinate an OE work. Domain experts are people who provide the knowledge of the domain to be modeled. In special cases (critical domains such as the surveillance one), the team invites experts in AI bias (sociologists/anthropologists) in order to ensure that fair ontologies are engineered (to contribute in assessing and mitigating bias in ontology-based AI models/applications).
  • Specify aim and objectives (S). In this task, the team specifies the reason(s) and the goal(s) for developing the ontology. A detailed objectives list is encouraged as a guide to the specification of requirements (next step).
• Specify requirements (Process 1.2, Figure 2). In the second process, members discuss the ontological requirements, i.e., what knowledge the ontology should represent based on the already agreed objectives, and a set of example domain-related questions/queries identified early in the process. This stage contains the following tasks:
  • Specify domain-related queries (S). A representative list of domain-related queries based on objectives, shaped after discussion within the team.
  • Discuss and specify requirements (S). Initiate of an argumentative dialogue between the members of the team in order to specify commonly accepted/agreed requirements of the ontology.
  • Produce specification documents (S). The recording of commonly accepted specifications in appropriate forms and documents, by storing them in a shared space using open web-based collaborative technology (e.g., Google docs).

3.2. Conceptualization Phase (2)

The second phase is composed of three processes:

• Acquire and learn knowledge (Process 2.1, Figure 2). During this process, the collaborating stakeholders learn and consult other well-known and widely acknowledged ontologies.
  • Find knowledge sources (P). The specification of the information sources are used to learn a kick-off/seed ontology.
  • Import ontological definitions from ontology libraries (P). Introduce existing related ontologies for reuse (parts or as a whole).
  • Consult generic top ontologies (P). A better understanding, clarification and confirmation of the field of ontology is sought.
  • Consult domain experts by discussion (S). Initiate argumentation dialogues of knowledge workers with domain experts toward consensual domain conceptualizations.
  • Learn kick-off ontology from queries (P). The learning of kick-off/seed ontologies from information sources can be an automated task (ontology learning). The learning of kick-off/seed ontologies, i.e., simple and lightweight ontologies, can be supported by specific tools.
  • Consult kick-off/seed ontologies (P). The consultation of a kick-off ontology to support the improvising of other (new) ontological definitions.
• Design modular ontology (Process 2.2, Figure 2). During this process knowledge workers initiate the design of the ontology, designing one or more ontological modules collaboratively. This process is composed of the following tasks:
  • Identify example scenarios (S). Collaborative writing scenarios that capture the specific requirements of the ontology.
  • Identify terms and properties (S). The definition of related terms and properties that emerge through those scenarios.
  • Identify ontological modules (S). The design of distinguished but interlinked modules based on the requirements and objectives of the ontology.
• Develop and maintain ontological modules (Process 2.3, Figure 2). In this process, team members can develop modules of the ontology in their personal spaces (P) and then collaborate toward integrating their modules into the final version of the integrated ontology. Necessary tasks are as follows:
  • Improvise ontological definitions (P). The development of ontological modules by improvising new definitions (ontological axioms) based on the knowledge worker’s perception of the described field.
  • Manage conceptualizations (P). Edit, delete, insert conceptualizations at any time during the development process.
  • Merge and compare versions (P). Compare different versions of ontologies or modules to identify differences and explore the possibility of merging them.
  • Generalize/specialize versions (P). Classification of ontology/modules versions according to their content in the modular chain.
  • Add documentation (P). Attach the information to the classes and properties of the ontology or its modules, with comments, examples and details.
  • Re-use learned kick-off/seed ontologies (P). The reuse of a kick-off ontologies in the process of developing a module or the integrated ontology.
  • Compare with kick-off ontology (P). Reusing parts of kick-off ontology/ modules in an improvised ontology, after comparison.

3.3. Exploitation Phase (3)

The third phase is composed of two processes (use and evaluate ontology):

• Use ontology (Process 3.1, Figure 2). In the first process, collaborators take advantage of application-based use of the ontology, using and browsing the ontology in their personal space. This stage includes the following tasks:
  • Browse ontology (P). Review the final shared ontology by all stakeholders on their personal space, evaluating and criticizing the specified conceptualizations.
  • Exploit in applications (P). Use the ontology in applications (ontology-based functionality testing, e.g., searching, browsing, and inference).
• Evaluate ontology (Process 3.2, Figure 2). In the second process, the final versions of the integrated ontologies that the team built on the personal spaces (P) are collected in the shared space (S). Each of them is put in a shared working environment with the aim of evaluating and exploiting it in a collaborative manner. The main tasks are as follows:
  • Initiate arguments and criticism collaboratively (S). Publication of arguments, disagreements and proposals regarding the final versions of the integrated ontologies that each stakeholder has shared.
  • Compare others’ versions (S). Comparison of the shared versions of integrated ontologies to identify differences between them.
  • Browse/exploit agreed ontologies (S). Reach agreement on the shared ontologies, browse and exploit agreed ontologies in a collaborative manner.
  • Manage recorded discussions (S). Edit, copy, and share recorded arguments upon versions of integrated ontologies to support decisions for or against shared specifications and conceptualizations.
  • Propose new ontology versions (S). Formulation of proposals on new ontologies with the aim of publishing new versions of the ontology or integrating new modules to the agreed one.
  • Browse/exploit kick-off ontology (S). Browsing and exploitation of learned ontologies, bringing forward kick-off/seed conceptualizations.

In the following sections, we present the main tasks of the ontology engineering methodology followed for the engineering of the SM ontology. The processes are following an ontological module-based approach of task execution, as proposed by the updated HCOME methodology.

4. Ontology Specification

The decision to design and implement the proposed SM ontology (SmartMuseumOnto) is taken since the related works do not fully cover the aim and the objectives of a SM ontology, as these were specified in our work (Introduction section). The SmartMuseumOnto is designed as a modular ontology, reusing related ontologies (Figure 3). The main module reused is the MESO ontology [7] that we recently developed for a museums’ energy-saving scenario.

The aim of the proposed ontology is to efficiently represent the knowledge in a smart cultural space to support the following application-related objectives: (a) represent the knowledge related to trustworthy IoT entities deployed in smart cultural spaces i.e., things (e.g., artworks, spaces), sensors, actuators, people, data, and applications, (b) deal with the semantic interoperability and integration of "smart" museum applications and data, (c) represent knowledge related to museum visits and visitors toward enhancing visiting experience, (d) represent knowledge related to energy saving, (e) represent knowledge related to the monitoring of environmental conditions in museums, and (f) represent knowledge related to the space and location of exhibits and collections. The ontology engineering team is composed of knowledge workers, two ontology engineers, and a museum-domain expert.

A representative list of domain-related queries based on the aforementioned objectives, shaped after discussion with the team, are the following:

• Objective (a) (trustworthy IoT entities’ representation and management).
  • Which exhibits are located in “UoAMuseumRoomA1”?
  • How many sensors (all kinds) are hosted by the “IoTmuseumPlatformLG”?
  • Which smart lamps have trust value = 0.7 and lights Painting01?
• Objective (b) (interoperability and integration).
  • What is the temperature in the rooms that ongoing visits take place right now?
  • For observations that are made for painting “Painting 001” in the room “Museum Room A1” at 09.00 on 15/01/2021, what is its status in terms of its lamp brightness level (energy) and nearby visitors?
• Objective (c) (user experience).
  • Which rooms have been visited by "Visitor01"?
  • Which exhibit are most popular in July?
• Objective (d) (energy-saving).
  • Is there an activation of the light device in “UoAMuseumRoomA2” at 15.30 on 10/08/2021?
  • Is there an activation of the heating device in “UoAMuseumRoomA1” on 20/08/2021?
• Objective (e) (environmental conditions).
  • What measurements have been made in “UoAMuseumRoomA1” on 9 September 2021?
  • For observations made for “UoAMuseumRoomA1” at 11.00, 11/09/2021, what is the result of humidity measurements?
• Objective (f) (location of exhibits).
  • What types of rooms exist in the museum, based on its collections and exhibits?
  • How many sculptures are located in “UoAMuseumRoomA2”?

The requirements of the ontology are aligned to the specified and agreed objectives. Hence, the requirements of the ontology are outlined in the following list:

(a)

The ontology must represent knowledge related to trustworthy IoT entities that are deployed in a smart museum, i.e., things, sensors, actuators, people, data, applications.

(b)

The ontology must deal with the semantic interoperability and integration of “smart” museum applications and data.

(c)

The ontology must represent knowledge related to museum visits and visitors towards enhancing visiting experience.

(d)

The ontology must represent knowledge related to energy saving.

(e)

The ontology must represent knowledge related to the monitoring of environmental conditions in museums.

(f)

The ontology must represent knowledge related to the space and location of exhibits and collections.

5. Ontology Conceptualization

After specifying the requirements of the ontology, the next is the design and developing of the ontology, starting from improvising through scenarios that emerge from the knowledge workers in collaboration with the domain experts. A selective representative list of example scenarios is provided below:

• Requirement (a) (IoT entities representation and management).
  • Count all the trustworthy smart lamps of the museum, where the trust degree is more than 0.5.
  • Name all the paintings of the museum that were created by “Vincent van Gogh”.
• Requirement (b) (interoperability and integration).
  • If there are more than two visitors in Museum Room A1 nearby an exhibit, classify this exhibit as an “interesting exhibit in UoAMuseumRoomA1”, turn up the light of this exhibit and classify the observation as a “trusted observation” if the trust value is greater than 0.5. Then lower the light of the remaining exhibits in the room.
  • If a visitor is interested in an exhibit in “UoAMuseumRoomA1”, then classify the exhibit as a “suggested exhibit in UoAMuseumRoomA1”, and classify the exhibits with no visitors as “no suggested exhibits in UoAMuseumRoomA1”.
  • If the temperature is less than 18 degrees Celsius or if the humidity is more than 55%, and there are visits in progress in UoAMuseumRoomA1, then activate the heating device or the dehumidifier device only in the room in which those visits take place.
• Requirement (c) (user experience).
  • When a visitor enters the museum for first time, send him/her a message with the number and types of rooms, the number and collections of exhibits, and the average duration of a visit per room.
  • When entering the museum, the visitor is given an e-form to fill, that is later used to build his/her profile. Based on this profile and his/her visiting history, it is suggested that he/she visits exhibit picasso_monaLisa_009 in Museum Room A1 and picasso_guernica_0037 in Museum Room A2 and other exhibits.
• Requirement (d) (energy saving).
  • If there are no visitors in room “UoAMuseumRoomA1”, then turn off the heating device.
  • If there are no visitors in room “UoAMuseumRoomA1”, then turn off the lights.
• Requirement (e) (environmental conditions).
  • If the temperature in room “UoAMuseumRoomA1” is more than 28 degrees Celsius, then activate the air conditioning (for visitors’ comfort).
  • If the humidity is more than 60 percent, then activate the dehumidifier device (for exhibit protection).
  • If the temperature in room “UoAMuseumRoomA1” is less than 19 degrees Celsius, then activate the heating device (for visitors’ comfort).
• Requirement (f) (location of exhibits).
  • If there are paintings in a room, then classify the room as “Room with Paintings”.
  • If there are sculptures in a room, then classify the room as “Room with Sculptures”.

The SM ontology proposed in this paper, namely SmartMuseumOnto, is implemented in OWL using Protégé 5.5 https://protege.stanford.edu/(accessed on 6 December 2021). The latest version is publicly available at https://github.com/KotisK/SmartMuseum (accessed on 6 December 2021), along with example queries for further evaluation and criticism by related communities of interest and practice. Other web resources of the developed ontology (v07) are (a) https://i-lab.aegean.gr/kotis/Ontologies/SmartMuseum/SmartMuseumOnto-v07.owl, (accessed on 6 December 2021) and (b) https://i-lab.aegean.gr/kotis/Ontologies/SmartMuseum/Smart Museum Ontology.htm, (accessed on 6 December 2021).

In order to demonstrate the capabilities of the ontology, specific scenarios were engineered using a rule language. The scenarios that cover the interoperability and integration capabilities of the ontology are listed below:

• If there are more than two visitors in Museum Room A1 close to (nearby) an exhibit, classify this exhibit as an “interesting exhibit in UoAMuseumRoomA1”, turn up the light of this exhibit and classify the observation as a “trusted observation” if the trust value is greater than 0.5. Then lower the light of the remaining exhibits in the room.
• If a visitor is interested in an exhibit in UoAMuseumRoomA1, then classify the exhibit as a “suggested exhibit in UoAMuseumRoomA1” and also classify the exhibits with no visitors as “no suggested exhibits in UoAMuseumRoomA1”.
• If the temperature is less than 18 degrees Celsius or if the humidity is more than 55%, and there are visits in progress in UoAMuseumRoomA1, then activate the heating device or the dehumidifier device only in the room in which those visits take place.

The first scenario is saving energy for the museum, enhances the visiting experience, while utilizing trustworthy IoT entities. The second scenario enhances the experience of a visitor while representing knowledge related to the location of exhibits. The third scenario is saving energy for the museum, and monitoring the environmental conditions in order to protect the exhibits and enhance the visitors’ comfort at the same time.

The name spaces of ontologies/vocabularies that are (re)used in the ontology are as follows:

• smo:http://i-lab.aegean.gr/kotis/Ontologies/SmartMuseumOnto/Smart-\MuseumOnto.owl#, (accessed on 6 December 2021) (the proposed ontology);
• meso:http://i-lab.aegean.gr/kotis/Ontologies/Meso/Meso.owl#, (accessed on 6 December 2021) (MESO ontology);
• cross:http://www.crosscult.eu/UserModel#, (accessed on 6 December 2021) (CrossCult ontology);
• sosa:http://www.w3.org/ns/sosa/, (accessed on 6 December 2021) (SOSA ontology);
• geonames:http://www.geonames.org/ontology#, (accessed on 6 December 2021) (Geonames ontology);
• crm:http://erlangen-crm.org/160714/, (accessed on 6 December 2021) (CIDOC-CRM ontology);
• iottrust:http://i-lab.aegean.gr/kotis/Ontologies/IoT/IoT-trust-onto.owl#, (accessed on 6 December 2021) (IoT-trust ontology);
• td:https://www.w3.org/2019/wot/td.owl#, (accessed on 6 December 2021) (Thing Description Ontology).

5.1. Ontology Classes

The main classes that are used in the evaluation scenarios and queries are listed below:

• smo:Humidity subclass of sosa:ObservationProperty, represents the humidity.
• smo:ActivateHeatObservation subclass of sosa:Observation, represents the observations result in turning up the heating device.
• smo:ActivateHumObservation subclass of sosa:Observation, represents the observations result in turning up the dehumidifier.
• smo:MuseumRoomHumObservation subclass of sosa:Observation, represents the observations of the humidity of a room in a museum.
• smo:NoSuggestedExhibitProximityObservation subclass of sosa:Observation, represents the non suggested exhibits.
• smo:SuggestedExhibitProximityObservation subclass of sosa:Observation, represents the suggested exhibits.
• smo:TrustedObservations subclass of sosa:Observation, represents the observations of trusted IoT entities.

5.2. Ontology Properties

The main properties of SmartMuseumOnto that are used in the evaluation scenarios and queries are listed below:

• sosa:madeBySensor represents the relation between a sosa:Observation and the corresponding sosa:Sensor.
• sosa:hasFeatureOfInterest represents the relation between a sosa:Observation and the observed meso:Exhibit.
• sosa:observedProperty represents the relation linking an sosa:observation to the observed property e.g., smo:Humidity.
• meso:nearByVisitors subproperty of geonames:nearby, represents the number of visitors (cross:Visitor) close to an meso:Exhibit.
• meso:brighteningLevel represents the brightening level (Low, Medium, High) of a meso:SmartLamp that meso:lights an meso:Exhibit.
• sosa:resultTime represents the timestamp of a completed observation.
• iottrust:hasTrustValue represents the value of trustworthiness of an entity.

6. Ontology Exploitation and Evaluation

According to the third phase of HCOME methodology, a list of selective representative SPARQL queries were designed for evaluation of the SmartMuseumOnto (inferred OWL model) in Protege 5.5 (using SNAP SPARQL plugin). Furthermore, a number of specific scenario-based SWRL rules were implemented and also evaluated in the same environment. Below, we present both (SPARQL queries and SWRL rules) as a proof-of-concept evaluation approach of the engineered SmartMuseumOnto ontology. The instance data for populating the ontology are not generated by real sensors but are synthetic-example data used only for the evaluation of the ontology. The evaluation of the ontology in a real application scenario is planned in our future work as a task of an SM-related project. In a real setting, the data generated by the sensors are stored in a relational or NoSQL database and then transformed to the populated ontology (knowledge base) by exploiting custom RDB (e.g., csv) to RDF mappings (e.g., provided in RML language).The knowledge base (populated ontology) is stored in a RDF triple store, such as TDB2, and accessed via a SPARQL endpoint of a related server, such as FUSEKI2 (Apache JENA technology, https://jena.apache.org/, (accessed on 6 December 2021)).

SPARQL Queries and SWRL Rules

The SPARQL queries are listed below:

• Which exhibits are located in UoAMuseumRoomA1?
  • PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
  • PREFIX owl: <http://www.w3.org/2002/07/owl#>
  • PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
  • PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
  • PREFIX geonames: <http://www.geonames.org/ontology#>
  • PREFIX meso:<http://i-lab.aegean.gr/kotis/Ontologies/Meso/Meso.owl#>
  • SELECT ?x
  • WHERE {
  • ?x  geonames:locatedIn meso:UoAMuseumRoomA1
  • }
• How many sensors (all kinds) are hosted by IoTmuseumPlatformLG?
  • PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
  • PREFIX owl: <http://www.w3.org/2002/07/owl#>
  • PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
  • PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
  • PREFIX geonames: <http://www.geonames.org/ontology#>
  • PREFIX sosa:<http://www.w3.org/ns/sosa/>
  • PREFIX meso:<http://i-lab.aegean.gr/kotis/Ontologies/Meso/Meso.owl#>
  • SELECT (COUNT(?x) AS ?numOfSensors)
  • WHERE {
  • meso:IoTmuseumPlatformLG sosa:hosts ?x
  • }
• Which smart lamps have trust value = 0.7 and lights Painting01?
  • PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
  • PREFIX owl: <http://www.w3.org/2002/07/owl#>
  • PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
  • PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
  • PREFIX geonames: <http://www.geonames.org/ontology#>
  • PREFIX sosa:<http://www.w3.org/ns/sosa/>
  • PREFIX iottrust:<http://i-lab.aegean.gr/kotis/Ontologies/IoT/IoT-trust-onto.owl#>
  • PREFIX meso:<http://i-lab.aegean.gr/kotis/Ontologies/Meso/Meso.owl#>
  • SELECT ?x
  • WHERE {
  • ?x iottrust:hasTrustValue 0.7.
  • ?x meso:lights meso:Painting01.
  • }
• Which rooms were visited by Visitor01?
  • PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
  • PREFIX owl: <http://www.w3.org/2002/07/owl#>
  • PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
  • PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
  • PREFIX geonames: <http://www.geonames.org/ontology#>
  • PREFIX sosa:<http://www.w3.org/ns/sosa/>
  • PREFIX meso:<http://i-lab.aegean.gr/kotis/Ontologies/Meso/Meso.owl#>
  • SELECT ?x
  • WHERE {
  • meso:Visitor01 meso:visits ?x
  • }
• What measurements were made in UoAMuseumRoomA1 on 9 September 2021?
  • PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
  • PREFIX owl: <http://www.w3.org/2002/07/owl#>
  • PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
  • PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
  • PREFIX geonames: <http://www.geonames.org/ontology#>
  • PREFIX sosa:<http://www.w3.org/ns/sosa/>
  • PREFIX meso:<http://i-lab.aegean.gr/kotis/Ontologies/Meso/Meso.owl#>
  • PREFIX :<http://i-lab.aegean.gr/kotis/Ontologies/SmartMuseumOnto/SmartMuseumOnto.owl#>
  • SELECT ?Observations
  • WHERE {
  • ?Observations sosa:hasFeatureOfInterest meso:UoAMuseumRoomA1.
  • ?Observations sosa:resultTime ?resultTime
  • FILTER(?resultTime="2021-09-09T11:00:12Z"^^xsd:dateTime).
  • }
• For observations made for UoAMuseumRoomA1 at 11.00, 11 September 2021,  what is the result of the humidity measurements?
  • PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
  • PREFIX sosa:<http://www.w3.org/ns/sosa/>
  • PREFIX meso:<http://i-lab.aegean.gr/kotis/Ontologies/Meso/Meso.owl#>
  • PREFIX :<http://i-lab.aegean.gr/kotis/Ontologies/SmartMuseumOnto/SmartMuseumOnto.owl#>
  • SELECT ?observation ?humidity
  • WHERE {
  • ?observation sosa:hasFeatureOfInterest meso:UoAMuseumRoomA1.
  • ?observation sosa:observedProperty :humidityInMuseumRoom.
  • ?observation sosa:hasSimpleResult ?humidity.
  • ?observation sosa:resultTime ?resultTime.
  • FILTER(?resultTime="2021-09-11T11:00:12Z"^^xsd:dateTime).
  • }
• How many sculptures are located in UoAMuseumRoomA2?
  • PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
  • PREFIX owl: <http://www.w3.org/2002/07/owl#>
  • PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
  • PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
  • PREFIX geonames: <http://www.geonames.org/ontology#>
  • PREFIX sosa:<http://www.w3.org/ns/sosa/>
  • PREFIX meso:<http://i-lab.aegean.gr/kotis/Ontologies/Meso/Meso.owl#>
  • SELECT (COUNT(?x) AS ?numOfSculptures)
  • WHERE {
  • ?x rdf:type meso:Exhibit_sculpture.
  • ?x geonames:locatedIn meso:UoAMuseumRoomA2.
  • }

Considering the specific scenarios already mentioned, the semantic web rule language (SWRL) https://www.w3.org/Submission/SWRL/, (accessed on 6 December 2021) is used to implement rules for the definition of semantically rich axioms related to the specific interoperability/integration scenarios.

Specifically, for the first scenario, if there are more than two visitors in UoAMuseumRoomA1 nearby an exhibit, classify this exhibit as an “interesting exhibit in UoAMuseumRoomA1”, turn up the light of this exhibit, and classify the observation as a "trusted observation" if the trust value is greater than 0.5. Then lower the light of the remaining exhibits in the room. The rules are depicted in Figure 4.

Based on the above SWRL rules and Pellet https://www.w3.org/2001/sw/wiki/Pellet, (accessed on 6 December 2021) reasoning engine, the first rule states that if the brightness level of the exhibit’s lamp is “Medium”, there are more than two visitors nearby the exhibit, and the trust value of the observation is greater than 0.5. Then, classify this observation as (a) an interesting-exhibit observation, (b) an observation to high level energy, meaning that the level of energy (light) for the lamp of the exhibit of this observation must be raised to high, and (c) a trusted observation, meaning that the lamp of the exhibit has a high level trust value. The second rule states that if the brightness level of the exhibit’s lamp is “Medium” and less than two visitors are nearby, then classify this as an observation of low level energy, meaning that the level of energy (light) for the lamp of the exhibit of this observation must be raised to low. The example rules automatically classify (semantically describe) exhibit proximity observations (meso:ExhibitProximityObservation) as interesting—exhibit proximity observations (meso:InterestingExhibitProximityObservation) and/or observations that must apply a change (decrease or increase) to the level of light (energy) of the observed exhibit (meso:ObservationToHighLevelEnergy or meso:ObservationToLowLevelEnergy) and /or also classify as trusted observation (smo:TrustedObservations). The specific time and location of the observations made are specified via geonames:locatedIn (for meso:Exhibit) and sosa:resultTime properties (for sosa:Observation).

For the second scenario, if a visitor is interested in an exhibit in UoAMuseumRoomA1, then classify the exhibit as a “suggested exhibit in UoAMuseumRoomA1” and also classify the exhibits with no visitors as “no suggested exhibits in UoAMuseumRoomA1”. The rules are depicted in Figure 5.

The first rule states that if there are visitors near the exhibit, then classify this observation as a suggested exhibit observation, meaning that the exhibit of the observation can become a proposed exhibit for other visitors to observe/visit. The second rule classifies the observation as a non-suggested exhibit observation if there are no visitors near the exhibit. The example rules automatically classify the observations as smo:SuggestedExhibitProximityObservation or smo:NoSuggestedExhibitProximityObservation.

For the third scenario, if the temperature is less than 18 degrees Celsius or if the humidity is more than 55%, and there are visits in progress in UoAMuseumRoomA1, then activate the heating device or the dehumidifier device only in the room in which those visits take place. The rules are depicted in Figure 6.

The first rule states that if there is humidity into the room of more than 55%, then classify this observation as an observation to activate the dehumidifier of the room. The second rule classifies the observation as an observation to activate the heater of the room if the temperature is less than 18 degrees Celsius. The example rules automatically classify the observations as smo:ActivateHumObservation or smo:ActivateHeatObservation.

7. Discussion

The proposed ontology is shaped in the presented version (0.7) with collaborative engineering (edit, evaluation) using Protege 5.5 and Google docs, e-mails and video-conferencing meetings. During the development of this version, the ontology engineering team was focused on implementing the specifically selected scenarios and example queries, as presented in this paper, emphasizing the interoperability and integration objectives. SmartMuseumOnto was engineered since existing ontologies do not fully cover the SM objectives, as described in Section 2. Furthermore, MESO is the primary ontology reused as an ontological module to cover the energy-saving objective. During team collaboration, the decision made was to avoid the extension of the MESO ontology and to build upon a new ontology, considering time efficiency and design complexity. Our expectations from the developed SM ontology include but are not limited to (a) wide usage of the ontology by the research community, (b) further extension of the proposed ontology, and (c) enhanced user experience in real-life applications. The proposed ontology contributes to an IoT ecosystem and smart environments’ applications as an approach for modeling and integrating heterogeneous trustworthy IoT entities that live in cultural spaces.

The limitations of the presented work are mainly related to the completeness of the trustworthiness aspect in terms of modeling it in the current ontology version and in the presented scenarios. In addition, the current version of the developed ontology does not fully reuse the imported ontologies due to the scenario-driven approach followed for its evaluation.

Future work will be focused on the elaboration of the ontology according to the valuable feedback we expect to obtain from the related research community on the GitHub-shared ontology versions. Considering the received feedback, we will further refine the ontology to thoroughly cover new ontological objectives and requirements. In addition, our future work includes an extensive evaluation of the ontology in a real-life application environment of an ongoing smart museums project in our department.

8. Conclusions

This paper presents a smart museum ontology, namely the SmartMueseumOnto, for facilitating smart applications in the domain of cultural spaces (museums). The engineered ontology meets the following objectives: (a) represent knowledge related to trustworthy IoT entities that “live” and are deployed in SM, i.e., things, sensors, actuators, people, data, applications, (b) deal with the semantic interoperability and integration of heterogeneous SM applications and data, (c) represent knowledge related to museum visits and visitors toward enhancing their visiting experience, (d) represent knowledge related to smart energy saving, (e) represent knowledge related to the monitoring of environmental conditions in museums, and (f) represent knowledge related to the space and location of exhibits and collections. Moreover, the paper reports the recent update of the HCOME methodology for the agile, human-centered, collaborative and iterative engineering of living, reused, and modular ontologies, applied in the engineering of SmartMuseumOnto. Following the HCOME methodology, specific requirement-based queries and scenarios were realized, conceptualized and implemented using OWL and SWRL semantics. The evaluation of this work was demonstrated within the Protege 5.5 environment, using synthetic/sample data. The evaluation of the ontology in a real-life application setting and further refinement of the ontology based on this feedback, as well as on the feedback of the research community, are included in our future plans.