Design and Implementation of ZigBee-Ontology-Based Exhibit Guidance and Recommendation System

Abstract

Even though information devices and systems have been widely applied in guidance service for museums and exhibitions, there are still several critical requirements unsatisfied. In our research, we systematically examine the requirements and then propose a new architecture for museum/exhibition guidance service; we further, based on ZigBee and ontology, implemented a new guide device and a new guidance and recommendation system. The contributions include (1) an extendable and comprehensive architecture for guidance service; (2) an automatic and personalized guidance service system; (3) overcoming the limitations and weaknesses of conventional guidance systems short distance limitation and network saturation problem in crowded environments; and (4) on-line user status monitoring and real-time recommendation service.

1. Introduction

The feasibility of integrating various information technologies and connecting mobile devices and computers facilitates the development of many innovative and creative applications. This concept of Internet of Things (IoT) has aroused people's attention and interests in exploring new applications. On one side, some researchers are devoted to design new model for these potential applications; on the other side, some designs have been proposed, implemented, and evaluated. This paper designs and implements one such application—a ZigBee-ontology-based intelligent exhibit guidance system.

There are several kinds of museum/exhibit guidance services: human guidance, signboard, CD player, TV, Kiosk, PDA, smart phone application, and so forth. Among them, human guidance could be the most interactive and intelligent, but it is very human resource intensive. As the demand of museum/exhibit guidance is increasing, more and more information technologies and devices are applied in facilitating museum/exhibit guidance.

An ideal museum/exhibit guidance system is expected to satisfy the following characteristics. (1) Personalized service: it provides the services, based on personalized preference; like one's preferred language. (2) Easy operation: it does not require users learning complicated operations, tools, or software. (3) Operability in crowded environments: a popular museum or exhibition usually attracts lots of visitors; therefore, a guidance service should still be operable in such environments; some extant systems require users to scan RFID-tagged targets or QR codes in a very short distance like 10 cm, but it is feasible for most visitors to approach the targets in crowded environments. Another weakness of extant systems is that some systems require users to download audio or video on-line; however, in a crowded environment, the network connection is either infeasible or saturated. (4) On-line visitor tracking and guidance: the system should track users' visiting patterns and provide suitable recommendation or guidance on-line. (5) Extend-ability: the system should be extendable to integrate new services as technologies and requirements evolve; examples of these applications are like social services, context-aware services, data mining, and so forth.

As technologies advance, many information technologies and devices (like CD player, TV, Kiosk, PDA, RFID, QR codes, and smart phones) have been applied in museum/exhibit guidance services. The adoption of these technologies has partially improved the services but does not satisfy all the requirements of the ideal museum-guidance service. In order to identify targets, some systems requires users to input specific numbers into their PDAs, and some require them to scan RFID tags or QR codes; however, in crowded environments, it is very difficult for most visitors to approach their targets in short distance. After identifying targets, some systems require users to download audio files or video files from the servers; the intensive downloading would saturate the network and deteriorate the service quality. Smart phone-based system could use GPS to provide good positioning service in outdoor environments, but it does not work well in indoor environments. Most extant systems also fail to track visitors on-line and to provide suitable guidance and recommendation, based on users' current context.

We, therefore, systematically reexamine the requirements of an ideal exhibit guidance system and then propose our system model. Based on this model, we select some off-the-shelf technologies and design and implement our museum/exhibit guidance system. The rest of this paper is organized as follows. Section 2 reviews some related work. Section 3 systematically examines the requirements, proposes our system model, and introduces our implementation. Section 4 discusses the application of our system on one exhibition and its ontology. Section 5 states our conclusions and future work.

2. Related Work

San Francisco Museum of Modern Art provided the iPAQ Gallery Explorers service [1] of which users can input the specific number of an exhibit and then the PDA plays the audio file for this exhibit. Instead of manually inputting digits, some systems like [2] used handheld device (e.g., PDA or smart phone) to scan QR codes and then download the corresponding media from a remote server. Likewise, RFID is used to identify object and then the corresponding index is used to retrieve media from a remote server for guidance [3]. All these similar applications share the same weakness that users are assumed to be able to approach their targets in short distance. However, this assumption is infeasible in crowded environments.

To design museum-guidance system, Chou et al. [4] focused on the object identification function and found that Wifi and Bluetooth technologies might have interference effect and GPS could not be well in indoor environments; they chose infrared ray as their identification, but infrared ray could not be well applied in crowded environments.

Chien et al. [5] adopted ZigBee and Gen 2 RFID in designing smart home service. Hirakata et al. [6] used ZigBee in designing an intelligent parking system. Even though ZigBee has been applied in designing many services, it was used mainly for identification and communication. In our design, we integrate ZigBee with MP3 player and SD card to provide an intelligent exhibit guidance device.

Other related work includes ontology-based tour guidance [7–9] and context-aware applications [5, 10–12]. Various kinds of context like user background, location, social information, time, and actions could be utilized to improve personalized services. MyGuide [10] is a context-aware exhibit guidance system of which a user uses his handheld device equipped with RFID tag to touch an exhibit (which is equipped with an RFID reader), and then the reader sends the tag's identity back to a server; the server then searches its database to identify the user and to locate suitable media; it then sends the media or the link of the media to the user's smart phone. This system worked, but it does not fit crowded environments. Gallego et al. [11] used several kinds of context like time, location, and social situation to provide restaurant recommendation; their system used GPS to position user's location.

Ontology is a specification of a conceptualization and is used to describe some domain knowledge. The study of ontology aims at better representing knowledge, applying knowledge, and sharing knowledge [13, 14]. OWL (Web Ontology Language) is one popular language for ontology and is one key mechanism for building semantic network developed by W3C. An example for traveling ontology was given in [7], and Li et al. [8] designed an ontology-based travel system. Li et al. discussed the methodology of constructing tourism ontology. Choi et al. [9], based on ontology, designed a tourism recommendation system. Even though these systems have applied ontology in designing tourism recommendation system, these systems did not consider users' real-time context.

3. System Design and Architecture

3.1. Evaluation of Extant Systems and Available Technologies

Owing to the observations in Table 1, we try to evaluate a museum/exhibit guidance system based on the following key functions and modules: (1) the object identification sub-system/module which identifies the object; (2) the user identification sub-system/module which identifies user's identity; (3) the media storage sub-system/module which stores the media of guidance information, and the media could be text, audio, or video; (4) the communication sub-system which connects the other subsystems/modules; (5) the guidance interface sub-system like smart phone, PDA, CD player, or MP3 player, and so forth; (6) the backend intelligent subsystem like data mining, ontology module, recommendation module, or other context-aware applications.

Table 1

Simple evaluation of popular museum-guidance systems.

	RFID based [3]	QR codes based [2]	PDA (or smart phone) based [1]
Identification of target	The reading range of passive tags usually less than 10 cm	Reading range less than 10 cm	Users either manually input digit number or scan RFID (or QR codes). The reading range less than 10 cm
Identification of user	Usually not provided	Usually not provided	Usually not provided
Storage of guidance information (either storage in handheld device or on server)	Most systems download files from the server. It causes network saturation or low-quality service.	Most systems download files from the server. It causes network saturation or low-quality service.	Some prestore media on users' devices, and some download from the servers.
Backbone communication	Most wifi, but few 3G	Most wifi, but few 3G	Most wifi, but few 3G
Guidance interface and operation	Sometimes PDA (or smart phone)	Sometimes PDA (or smart phone)	PDA (or smart phone)
Intelligent backend module	Most do not support	Most do not support	Most do not support

Based on the above criteria, we give a simple evaluation of popular museum/exhibit guidance systems in Table 1. From Table 1, we notice that most of popular museum/exhibit guidance systems only focus on identifying targets but not users; they, therefore, do not collect users' visiting patterns and cannot provide on-line real-time recommendation or guidance. Smart phonebased systems are good at positioning in outdoor environments, but they do not work well in indoor environments. If a system stores its media on server and requires users to download multimedia files from the server, then the network usually saturates and deteriorates the service quality in crowded environments.

3.2. The Proposed System

After evaluating technologies on the market, we choose ZigBee because it can serve as identification module for identifying users and for identifying targets simultaneously, in addition to being the communication channel between users' handheld devices and system backbones. We propose our system in Figure 1 and describe each module function in the following.

Figure 1

System architecture.

Our system targets those environments that require guidance or recommendation service; some examples are like museums and exhibitions indoors or outdoors. It is easy for users to operate the devices and users are not required to input numbers or to learn complicated operations. It could operate well in crowded environments; it means users are not required to approach targets in short distance and the network connection operates well even if there are moderate people in every single spot. ZigBee here serves as communication channel between users' handheld devices and ZigBee routers (one router is placed at each exhibit; each router serves as an identifiable object for that exhibit and it also identifies each user in the nearby) and communication among routers and ZigBee coordinators. The communication from coordinators to/from the backend servers is via the backbone, and the backbone could be either wifi or fixed wiring.

When a user approaches an exhibit in a moderate distance (like 10~30 m), his handheld device identifies the exhibit (the router) and triggers the device to play the corresponding media. On the other side, the router also identifies the user's device and transmits that device's identity to the backend server, where the visitor records are kept and analyzed and ontology subsystem and recommendation subsystem are running. Recommendations or links of recommendations are sent to users' preregistered smart phones, and users can use smart phone to access our system on-line for getting more guidance services. The function and some details of each module are described as follows.

Hardware Modules and Functions

• (1)

ZigBee-SD card-MP3 end device: on the left side of Figure 1, we design a user handheld device which consists of ZigBee module, MP3 player and SD card module. On the CD card, the operator stores MP3 files. Now there are four MP3 files associated with each exhibit and they correspond to the audio files of Chinese, Taiwanese, Japanese, and English versions. When this end device identifies the nearby router's identity, it plays the corresponding MP3 files, based on user's language preference. We also design a button for user to select his preferred language version. It also sends its identity to the router which forwards this identity to the server, where the server can record user's visiting history and do some analysis. The functions of this module include identifying object, SD card management, ZigBee communication, and MP3 playing.

(2)

ZigBee router: each exhibit is associated with one router which serves as an identifiable object. It sends its identity to end device to locate the corresponding MP3 files. It also serves as communication hop between an end device to the communication backbone. In addition, it forwards visitor's end-device identity to the backend server for recording and analysis. These routers can be dynamically deployed in the environments. Now ZigBee deployment support star, tree, and mesh topology, and its transmission ranges from 30 m to 100 m. It requires low battery consumption and supports full duplex communication in large number of nodes. These characteristics make it quite suitable for both indoor and outdoor communication/identification.

(3)

ZigBee coordinator: this device acts as intermediary between the ZigBee network and the system backbone network. It is connected to a computer. On one side, it speaks ZigBee protocol and speaks TCP/IP via USB or RS232 interface on the other side. It accepts ZigBee packets from the ZigBee network and encapsulates and forwards the content into TCP/IP packets and vice versa.

(4)

Backend server: this could be a single server or a cluster of several servers. The services running on these servers include web server, database management, exhibition management, exhibit-item management, device management, user management, context-aware applications, and ontology and recommendation application.

Software Modules and Functions

• (1)

Client modules: on user's handheld device, our ZigBee-SD card-MP3 device, several software modules run. The functions include playing MP3 audio, identifying exhibit object, manually selecting user preferred language, and receiving messages from the server.

(2)

Software modules on backend servers (Figure 2): there are several management modules running on backend servers; including basic management functions and intelligent applications. These basic management functions include device management, exhibition and exhibit object management, user management, and user visiting records management. The intelligent applications include ontology module, context-aware application like real-time recommendation. The user management module maintains users' basic information like name, age, e-mail, preferred language, and so forth. The device management module maintains the data of ZigBee devices and the relation between ZigBee routers and exhibit objects. The exhibition and exhibit object management module maintains the data of each exhibition and its exhibits. Ontology module maintains the knowledge of the exhibition and the exhibits so that better recommendation could be provided to users. Now we implement real-time recommendation service which analyzes users' visiting records on-line and gives recommendation, based on the analysis and the ontology.

Figure 2

Backend service modules.

3.3. The Implementation

We chose the following tools, package, and language to implement our system. Hardware includes ZigBee module, MP3 chip, SD card module, notebook, computer, earphone set, speaker, and smart phone with Android platform. The software tools include Java, JSP, My SQL, Apache Tomcat, owl, pretege3.5 [15], and its plugins. The plugins we used include SWRL [16], JESS [17], and SWRLIQ [18]. One possible deployment of our system is depicted in Figure 3, where the deployed topology is tree.

Figure 3

One deployment scenario of our system.

4. Ontology of One Exhibition and Discussions

We have implemented the prototype of our system and have applied it to one famous scenery spot Sun Moon lake in Taiwan [19]. This exhibition built shows that our system fits not only indoor museum/exhibition environments but also outdoor environments. Several routers are deployed to demonstrate the feasibility of the concept and the system. However, deployment of large volume of devices is required to collect more field testing data. Each attraction, restaurant, bus stop, souvenir shop, and activity in the Sun Moon lake are viewed as one exhibit object, and one ZigBee router is assumed to be deployed at each exhibit spot. We also built the ontology for the Sun Moon lake scenery for providing better recommendation and future analysis. Now we introduce our ontology — SunMoonlake.owl — as follows.

Class and Property. The classes we built include the concepts in the Sun Moon lake scenery- accommodation, activity, attraction, bike rental station, bus, food, souvenir, souvenir shop, tour, population, and so forth. For each class, we define the corresponding properties; for example, we define “CanFitfor” property for the “attraction” class to specify what kind of population an attraction instance (in owl context, an instance is called an individual) fits for; one example of such instance is like “a restaurant can fit the family”. The defined properties include “ActiveIn,” “CanFitFor,” “ActiveAtNight,” “Free,” “hasBusStop,” “hasEcology,” “hasLatitude,” “hasLongitude,” “hasParkingLot,” “hasPrice,” “hasRoomType,” “hasURL,” “IsRomantic,”. The list of the classes and the properties is shown in Figure 4.

Figure 4

List of classes and properties in the SunMoonlake.owl.

SWRL Rules. We built some swrl rules to infer new knowledge from current facts (knowledge). For example, some simple rules are defined to infer which attraction or activity fit couple, or family or to infer which tour is free. Some swrl rules are introduced as follows and in Figure 5, and the result of executing these rules is shown in Figure 6:

• (1)

Attraction(?x) ∧ CanFitFor(?x, Family) → FamilyJourney(?x)

(2)

Event(?x) ∧ CanFitFor(?x, Couple) → CoupleJourney(?x)

(3)

Activity(?x) ∧ Free(?x, true) → FreeTour(?x)

Figure 5

Some swrl rules.

Figure 6

The result of executing the swrl rules.

SWRL IQ Query. We built some SWRLIQ queries to compute the direct distance between a user's current location and his target destination and to select the nearest destination from the user, depending on what kind of destination the user specifies. One example of such query is shown as follows, and it computes the direct distance between the parking lot and the current location. This version of the query computes the direct distance and does not consider the winding road (or path); in our next version, we will use Google map API to compute the real distance of the road and pack it as a SWRL builtin. The execution result is shown in Figure 7:

•  

Attraction(?x) ∧ hasParkingLot(?x, true) ∧ hasLatitude(?x, ?lat) ∧

 

hasLongitude(?x, ?lon) ∧ swrlb:subtract(?y, ?lat, 23.835473) ∧

 

swrlb:multiply(?q, ?y, 110.94) ∧ swrlb:subtract(?z, ?lon, 120.9364759) ∧

 

swrlb:multiply(?r, ?z, 101.779) ∧ swrlb:multiply(?a, ?q, ?q) ∧

 

swrlb:multiply(?b, ?r, ?r) ∧ swrlb:add(?c, ?a, ?b) ∧ swrlm:sqrt(?f, ?c).

Figure 7

The execution of a SWRLIQ query to compute the distance.

Discussions. Table 2 gives a simple comparison of various museum-guidance systems. In summary, our system out-performs extant systems in several respects. It fits crowded environment, while others do not. It can on-line track visitors, analyzes users' visiting patterns and gives real-time recommendations, while other do not. Our system integrates with ontology sub-system and other context-aware applications, while others do not.

Table 2

Comparison of various museum-guidance systems.

	The proposed system	QR Code [2]	RFID [3]	PDA with input number [1]
Operation	Manual and automatic	Manual	Manual	Manual
Expected distance between user and exhibit	Up to 30 m	10 cm	10 cm	About 60 cm
Suitable for crowded environments	Yes	No	No	No
Media storage	SD card	Web Server	Web Server	PDA
Network bandwidth requirement	Transmission of simple commands and short messages	Transmission of multimedia	Transmission of multimedia	No transmission
On-line tracking of visitor	Yes	No	No	No
Real-time recommendation	Yes	No	No	No
Ontology-based recommendation	Yes	No	No	No

5. Conclusions and Future Work

In this paper, we have provided our systematic analysis of extant museum/exhibit-guidance systems and have listed the requirements of an ideal museum-guidance system. We have designed a ZigBee-based museum/exhibit guidance system which fits crowded environments, tracks users' visiting patterns on-line and gives real-time recommendation. Our system also provides ontology subsystem for providing better recommendation service; however, the integration of ontology subsystem is off-line in the current prototype; we plan to improve it as an on-line version in our next version. Another future work of this research is to develop social interaction for visitors, based on the collected context.