Service-Oriented Context-Aware Messaging System

In services oriented computing, location or spatial models are required to model the domain environment whenever location or spatial relationships are utilised by users and/or services. This research presents an ontology-based methodology for context-aware messaging service. There are five main contributions to this research. First, the research provides a service oriented methodology for modelling and building contextaware messaging systems based on ontological principles. Second, it describes a method that assists understanding the domain’s spatial environment. Third, it includes a proposal of the generic Mona-ServOnt core service ontology that offers context-aware reasoning for capture and use of context. Mona-ServOnt is able to support the deployment of context-aware messaging services in both indoor and outdoor environments. Fourth, a novel generic architecture that captures the requirements for context-aware messaging services is given. Fifth, the generic messaging protocols that describe the exchange of messages within context-aware messaging services is modelled. A few experiments were completed to measure the performance of the peer-to-peer services using actual smartphone with Bluetooth capability. In addition, the methodology’s main steps have been validated individually in various context-aware messaging domains. It has been evaluated using competency questions that gauge the scope of the proposed ontology. Furthermore, the generic architecture and messaging protocols have been verified in constructing for each domain. Keywords—Context-Awareness; messaging service; service ontology; semantic web service


I. INTRODUCTION
Service-oriented technology is moving beyond the personal computer to everyday mobile devices.It has become increasingly common for people to interrelate with serviceoriented technology in many aspects of their daily lives and the continual miniaturisation, increase in processing power and connectivity has amplified this trend.We shall refer to this result as 'pervasive' service-oriented computing as this trend can be observed in most facets of modern life.
Pervasive computing was first mentioned in [1] that shows that computation resources can be used in many environments.Since then, many pervasive services have been developed.Pervasive computing is currently powered by services oriented computing [2] aims to develop intelligent applications that understand the available context information and respond with the best services.These applications are known as contextaware services.Aljawarneh et al. [3] stated that pervasive services have several common features.For example, pervasive services use distributed sensors and a context source to collect information about the environment.Pervasive services also have reasoning functions to recognise the semantic significance of the collected information and perform the appropriate action.In addition, they possess several types of procedures to handle simple and complex activities.Finally, the main feature of pervasive services is the application of their services in multiple environments.
Context-aware service began two decades ago in [4] which provides examples of context as location, nearby people and objects, and changes to service objects over time.Context acquisition, interpretation, understanding and context response are the primary concepts pertinent to context-aware systems.Location awareness and activity recognition are also paramount as the user's location and activity are necessary to many services [5].Context can play a major role in communication services, especially in messaging services.Context information can be used effectively for addressing or describing targets when sending messages.There are other various services supported by context, such as travel services and commercial services.
In order to provide modelling, an ontology that offers sharing and usage of the available information about the domain is required [6].Ontologies have been extensively used to represent various real-world service domains and are significantly employed as a tool to assist in information sharing between domains.An ontology's target is to achieve a collective knowhow of a provided discipline.
Every context-aware service has its own characteristics in order to achieve its goal and depends on the service's requirements.However, context-aware services share common methods of using context information.The definition of context pertaining to actors in the domain is necessary when proposing and constructing context-aware messaging services and comprises a fundamental comprehension of domain features.Constructing context-aware services depends on understanding several factors within pervasive computing.This paper identifies and addresses a gap in current research, that is, the need for a general methodology for contextaware messaging services as well as the description of a generic ontology for such context-aware messaging services.This notion of what we call Context-Aware Messaging Service Methodology Based on Ontology (CAMSMBO) will be examined as a solution to achieve this.Based on the notion of CAMSMBO, the Mona-ServOnt core service ontology has been built to represent context-aware messaging domains.Accordingly, this paper aims to address the following research questions: 3) How can we address the identified requirements to model a context-aware messaging domain?4) What is the importance of the ontology and how can it be developed for context-aware services?5) How can we evaluate a generic ontology for contextaware messaging?6) How can such a methodology be described?

II. SERVICE ORIENTED METHODOLOGY
We propose a service-oriented methodology for building context-aware messaging services called Context-Aware Messaging Service Methodology Based on Ontology (CAMSMBO).The methodology starts with understanding the domain spatial environment, followed by modelling the context-aware messaging environment based on a core service ontology, called the Mona-ServOnt core service ontology, that can be applied and adapted in all types of context-aware messaging services.Then, the service can be designed based on our previous language service architecture [7] and agent architecture [8] for context-aware messaging with a generic messaging service protocol.The CAMSMBO methodology acts as a guide, providing the steps for building context-aware messaging services.Fig. 1 illustrates the steps in the CAMSMBO methodology.We elaborate on the steps of the CAMSMBO methodology in the following subsections.

A. Understanding the Spatial Environment for Context-Aware Messaging Domains
In order for a messaging service to be effective, it should be noted that the word spatial can represent numerous concepts within the available space; an area or any interval of space for example.Spatial information retrieval and mobile information systems are key elements behind the majority of mobile services.The major processes required in mobile services to perform a task are to be able to recognise the available context information, such as actor location information as well as the service's available context information.Spatial awareness demands acquiring spatial contexts from sensors, representing and interpreting context information and sharing it with other services.In order to propose a spatial environment for contextaware messaging service, three steps need to be undertaken.Fig. 2 describes the procedure for defining the spatial environment in the following steps.First, the spatial environment for context-aware messaging that matches the requested domains is determined.Second, the spatial environment is categorised into sub-divisions.Finally, the relations between the spatial concepts and entities involved within the domain Describing the context information for a context-aware messaging domain is essential in identifying the spatial environment for context-aware messaging that matches any domain.Most context-aware messaging services use common types of context information in the process of achieving a task.In addition, respective context information assists in defining the domain spatial environment.For example, emergency, guidance and notification, social media, medical and learning domains use different types of context information that meet the requirement of each respective domain.However, contextaware messaging domains will often share common context information.
Spatial information such as location information is considered an essential part in context-aware messaging services.The guidance and notification services, such as Community Reminder [9], depend on location in order to execute tasks.Location is commonly used in the area of social network services to facilitate greater interaction between agents such as groups of nearby friends in the services.However, these context-aware messaging services employ different types of context information to describe the spatial environment for the service, depending on the domain.
The spatially separated parts contribute to the description of the domain environment.For example, the spatial environment of a building contains apartments, halls, roof and stairs.This division assists in dealing with the separate parts independent of the spatial environment.Also, defining the spatial environment into sub-divisions enhances the description of the domain context information [10].In addition, spatial environment subdivisions can be anything related to a certain area or space and not necessarily physically geographic, for example, human activities such as going to the farm and walking in the park.Spatial relations can be used in spatially linking instances in ontology knowledge.

B. Constructing the Services Ontology
Constructing an ontology was a process considered an art more than an engineering activity until the mid-1990s.An ontology enables the sharing and use of available information about the domain [6].According to [11], there are five component types to distinguish information in an ontology, i.e. taxonomy, relations, functions, axioms and instances.In addition, an ontology that describes a targeted domain requires domain expertise and comprehensive knowledge of the ontology elements and relationships.
An ontology assists in the distribution of information regarding certain events.However, every development team generally defines a set of principles, design criteria and phases for constructing an ontology to meet their requirements.Furthermore, the nonexistence of universal and structured guidelines is considered time-consuming for the growth of ontologies within and between teams.
We develop Mona-ServOnt core service ontology, a general service ontology that can be applied in several context-aware messaging domains.The process starts with distinguishing the uses of Mona-ServOnt and determining the service domain that wishes to use Mona-ServOnt.The second step is to establish the concepts within Mona-ServOnt that describe the messaging domain.The following step is identifying the spatial relations that connect the Mona-ServOnt concepts that assist in defining the context-aware messaging scenario.Finally, Mona-ServOnt is evaluated to ensure the verification and validity as well as the usability of the ontology, using different techniques.
There are many research projects that apply ontologies for context modelling and reasoning in context-aware messaging services [12], [13].However, these ontologies are developed and defined to meet the requirements of a particular service within particular domains.Mona-ServOnt can be used within several context-aware messaging service domains including emergency services, guidance and notification services, social media services, health and medical management services, and education and learning services.
Generally, an ontology is designed to meet the requirements of a certain service.As a result, there is a need to build an ontology that supports context-aware messaging services for the clear specification and understanding between actors in the domain, as well as facilitating the capturing, filtering, sharing and reasoning of contexts within a spatial environment for messaging purposes.Based on the Mona-ServOnt core service ontology, a Mona-ServOnt domain ontology can be applied in many types of service domains.Mona-ServOnt is built according to several motivating scenarios according to the requested domain and based on the concepts represented in one of the domain articles.This method is inspired by the Cyc method, an ontology based on everyday common sense knowledge that allows reasoning [14].Mona-ServOnt is defined in Web Ontology Language for Services (OWL-S) [15] for several types of context-aware messaging services such as emergency, guidance and notification, social, health and medical management and education and learning as supported in Fig. 3.It describes the Mona-ServOnt classes and the properties that connect them.
Mona-ServOnt assists in describing common scenarios that occur within context-aware messaging domains.It uses ordinary language concepts, attributes and relations that are easily understandable by people.The domain management unit contains information about the user who has position relation and needs to be directed to a POI, that represents points that assist in performing the domain tasks.In addition, according to the information requested by the domain, the domain management unit may categorise the spatial environment into sub-areas, depending on the information for the requested task of the domain.
Fig. 4 gives an overview of the main concepts of Mona-ServOnt and the spatial relations that connect these concepts.The Mona-ServOnt key concepts can be generalised to meet the requirements of five types of context-aware services as follows: • Domain management unit represents the management and service of the actors.It exchanges information with the actors depending on the scenario.
• Domain context represents the context information of the domain that assists in performing the requested tasks during domain events.
• Spatial environment represents the spatial area in which the messaging service is operational.It might be divided into several divisions or sub-areas depending on the task to be performed by the domain.
• Actor refers to the people that use the context-aware messaging service such as the user, flag-bearer and administrator, as explained later.
• POI represents the features that assist in performing a task using context information.The POI is a taskrelated role.Also, it helps in positioning and filtering information as well as performing a required task.It is usually part of the spatial environment.
The spatial relation links the ontology concepts using common English expressions that are easily understood by people.It illustrates the Mona-ServOnt where spatial relationships are applied in order to connect the service's main concepts as well as describing domain events.The ontology is used to define the knowledge that can be shared between actors using contextaware approaches.
The spatial relationships are applied in order to connect the domain's main concepts as well as describing an event during situations.Mona-ServOnt allows the domain service to employ spatial relations qualitatively and quantitatively.The quantitative spatial relation information is converted automatically by the domain management unit into qualitative relation information in the form of domain and position relations.
The qualitative spatial relation is described using common language that the user can easily understand.In addition, the quantitative spatial relation is utilised to provide data to assist in defining the range or distance between objects within the context-aware messaging domain that uses Mona-ServOnt.
We illustrate the Mona-ServOnt concepts and the subconcepts that may represent the context-aware messaging domain, for example, the concept actor described using type, location, age, actor ID, status and actor activity as seen in Fig. 5.It shows the sub-concepts that describe actors within the context-aware messaging domain.These concepts are common within the area of the context-aware messaging domains, such as actor ID which is common to many domains, and assists in clarifying the registered actor in emergency and social media domains.In addition, actor location determines the actor's positional information, and actor type describes the actor's role within the context-aware messaging service such as administrator, user or flag-bearer.
The 'administrator' represents the service provider or the service supervisor side, the 'user' represents the persons who benefit from the services and the 'flag-bearer' is an actor that has more responsibility such as forwarding the messages using peer-to-peer techniques.The flag-bearer can act as an independent server and provide the service to other actors in case the connection with the main server is lost.Moreover, the flagbearer can register new actors with the server.For example, in emergency domains, the flag-bearer is responsible for assisting other actors within his range to ensure that all actors follow the server's instructions.Also, the flag-bearer can provide alert messages to a survivor who has lost communication with the disaster management unit.Moreover, the actor status defines the actor's situation or condition information.Additionally, the 'actor activity' describes the actor's current action according to the domain.
The domain's context information assists representing the domain where the Mona-ServOnt ontology is applied.It can be identified with the context information such as 'task' which clarifies the context-aware messaging domain's list of tasks that can be offered and accomplished by the Mona-ServOnt.In addition, the domain status describes the domain condition where the domain event normally presents the list of occasions, as shown in Fig. 6.
The spatial environment represents the area where the context-aware messaging domain service runs.It has a division, static location and status (see Fig. 7).The divisions of the spatial environment include sub-areas that assist in simplifying and clarifying the domain's positional context information.Also, the spatial environment status describes the contextaware messaging service area condition where the spatial environment division illustrates the context-aware messaging service sub area.
The POI is a fixed point within the spatial environment that assists in positioning or capturing information.It has a type that describes the POI according to the context-aware messaging service objective.Also, static location locates the POI within the spatial environment and the status defines the condition of the POI (see Fig. 8).
The concepts and their sub-concepts are used to give an overview of Mona-ServOnt for context-aware messaging services as illustrated in Fig. 9.It shows that in contextaware messaging service domains, there are several common concepts that need to be addressed such as location, actor ID and status.The purpose of the Mona-ServOnt core service ontology is to create an ontology for a specific domain (answered research question number 4).

C. The Evaluation of the Mona-ServOnt
Intuitively, an ontology can be evaluated in different ways because the main goal of an ontology is to provide an explicit specification and understanding within a particular domain.Ontology content evaluation began in 1994 [16].Ontology evaluation is a technological judgment of the ontology.The Mona-ServOnt core service ontology is designed to meet the requirements of several types of context-aware messaging services.The purpose of Mona-ServOnt is to model and capture the context of entities within a domain, with the purpose of context-aware messaging.
Mona-ServOnt is evaluated using three different methods.First, we employ a set of natural language questions used to measure the capability of the ontology in the real world, called competency questions [17].The competency questions are used to validate the extent of the ontology.These questions and their answers are applied both to extract the main concepts and their properties, relations and axioms on the ontology.We defined the following key questions to verify the scope of Mona-ServOnt.

1) What type of service domains can use the Mona-
ServOnt core service ontology?It can be used in many domains.This is kept in mind when designing the ontology, so as to be general.2) How does the Mona-ServOnt support the representation of different areas within the spatial environment?It contains the concept of the division of the spatial environment which defines a sub-area within the main area.3) What type of information is used to define a POI?It describes domain POIs using different properties such as POI status, POI type and its static location.
For example, POI status can be used to label the POI as negative or positive, restricted or open and then inform the administrator about the status and location of that POI. 4) What useful information about actors' conditions needs to be included to describe actors in the domain?It uses the concept actor status that allows the actor to define their situation, such as "enjoying" or "having a heart attack".
Once Mona-ServOnt is designed and evaluated, structuring a generic architecture for context-aware messaging service is applicable in the building of a context-aware messaging service for a domain.

D. Designing the Service Architecture and Protocol
Inspired by [4], we employ numerous types of contextaware modifications to both the management and actor sides of the ontology in order to structure context-aware architecture for context-aware messaging services.This helps characterise the physical requirements for the context-aware messaging service.The proposed architecture combines two types of techniques.The Mona-ServOnt architecture utilises centralised architecture in the form of client-server architecture at the top level and multiple actor peer-to-peer architecture at the lower levels.The context-aware messaging service architecture includes three main components: the actor, the domain management unit and the database as illustrated in Fig. 10.The figure presents the context-aware general architecture and the flow of information between the service entities and its components.
We propose a message content protocol that has been exchanged between the domain server and the actors within the context-aware messaging approaches.The messaging approach defines the context depending on the task required by the domain as well as the situation and the time of the event.This allows the service to define the target and the content of the message.All context information is stored into the domain database.Most context-aware messaging approaches use location information in addition to particular types of context in order to complete the required tasks.
The messaging protocol supports a few types of services and can be implanted within different types of context-aware service domains.For example, it supports automatic messaging services generating several types of messages that are sent automatically and repeatedly by the server to the actor according to the actor type, time and event within the domain.The messaging protocol can be used to define the content and the target of the message within context-aware messaging domains.
Fig. 11 illustrates the multiplicity of context used with the messaging protocol in the exchange process.First of all, the actor is required to register within the domain server using his context information such as actor ID, name and location.The context information differs slightly depending on the actor's role such as user or administrator as well as being dependent on the domain task.The following scenario may explain the use of the messaging protocol in social media domains.For example, during the New Year festival, the social media service wants to direct people to the most suitable area that would meet their interests.In this case, the user's context information can be location as well as some personal information such as age, type, interest, skills, educational level and activity.
We assume that the server has information about several events that have been held in different places within the city such as the function type, location and the number of people the venue can hold.The server compares the user's context information with the event context information and starts to automatically message the people within the city about the POI which represents the most suitable function to meet their desire, such as a music party, using spatial relations where the suburb is represented by the division of the spatial environment.In addition, Melbourne city symbolises the domain spatial area.Furthermore, the messaging protocol offers manual messaging services where messages can be transferred manually by the service administrator to a group or particular users using custom messages.
The protocol can provide information to other institutions that may involve people during the New Year festival, such as the police, and inform them about the people's context information depending on their specialties.Additionally, the approach can share information with people inside the spatial area using their context information.

III. APPLYING TO MULTIPLE SERVICE DOMAINS
Ontologies have been extensively used to represent various real world service domains and are employed significantly as a tool to assist in knowledge sharing within domains.The use of ontology within context-aware services offers a wider knowledge base that can be incorporated into context information to describe events and activities.
We provide the Mona-ServOnt core service ontology which offers context reasoning and sharing, and allows the capture of context information in various domains.Due to the page limitation, only two service domains are shown in this paper: the guidance and notification domain and the health management domain.The core service ontology serves as a useful beginning point for designing domain ontologies for context-aware messaging systems.Corresponding competency questions relevant to each domain are used to evaluate the particular domain ontology built (based on the Mona-ServOnt core service ontology).

A. The Guidance and Notification Service Ontology
Location information, apart from service context information, is useful for guidance and notification services.This section discusses the use of Mona-ServOnt in a context-aware messaging approach for guidance and notification purposes.We illustrate the Mona-ServOnt guidance and notification service ontology using context-aware services for guidance and notification for a museum environment.The existing museum visitor's guidance service uses context information for messaging.The design supports small groups of visitors in a museum, with context-aware communication services.The framework includes context-aware communication services integrated with facilities such as data projectors to display presentations.The museum visitors' guidance service contains two services to target the sharing of the museum experiences and service-to-visitors communication.
The service ontology enhances and supports knowing sharing capabilities as well as messaging functionalities for guidance and notification purposes such as work done in Community Reminder.Community Reminder [9] provides the user with reminders and situations that can be applied in many ways.Mona-ServOnt contains similar context information that can be applied to offer guidance and notification services.For example, Mona-ServOnt uses location information, in addition to other context information, of actors as well as of points of interest (POI), to determine spatial relations between concepts within Mona-ServOnt; for example, the POI can be a milk bar that has location information that can be compared with the actor's location information.
We design the service ontology to serve Melbourne Museum visitors.For example, Mr. Smith and his family are visiting the museum for the first time.The family includes six people, Mr. & Mrs. Smith, their two sons, James and Mark and their grandparents Mr. & Mrs. Ray.Everyone has different interests and attitudes about their tour plan.Mr. & Mrs. Smith intend on visiting the Mind and Body Gallery whereas their boys are attracted to the Science and Life Gallery, in particular, the Tarbosaurus (giant meat eater, Tyrannosauridae) section.In addition, the grandparents are interested in the Bunjilaka Aboriginal Cultural Centre.Furthermore, the museum contains more permanent exhibits that the whole family wants to see such as the Melbourne Gallery and Large skeleton of a Pygmy Blue Whale.
Furthermore, the family want to share their experiences and message each other while touring inside the Museum.For example, Mr. & Mrs. Smith would like to message their parents saying "the Mind and Body Gallery is closed, and it will open in two hours".Also, James and Mark want to make notes saying "Science and Life Gallery is impressive".Additionally, the grandparents need information about the direction from the Bunjilaka Aboriginal Cultural Centre to the Forest Gallery.These scenarios and more can be addressed using messaging with concepts in the service ontology.For example, the family members are directed to a particular gallery inside the Museum according to the available context information.Also, the museum management unit will continue tracking Mr. Smith's family member's locations to redirect them in case they lose the right path.In addition, other guidance and notification tasks can be performed such as playing a presentation once a user reaches a specific gallery.Also, the visitor can report back to the museum management unit her experiences about a particular section in textual form.The text can be shared through the management unit with other users or family members.
We propose an approach that offers the administrator the ability of the museum management unit to contact a group of visitors or an individual visitor using context information.For example, the administrator may want to address all the visitors with a message saying "The Mind and Body Gallery is closed for maintenance, and will re-open in two hours".The administrator may want to send a message to all the actors who "have been to the Science and Life Gallery" or who "are currently in Science and Life Gallery".In addition, an individual may need to have messages sent out in the case of an emergency such as Mrs. Ray having a heart attack and that all family members should attend a specific location.The administrator messages the family members about Mrs. Ray's situation and asks them to move towards a location.In addition, the administrator might want to send visitors within the Bunjilaka Aboriginal Cultural Centre a message saying "a short presentation will be playing shortly".Moreover, the museum management unit allows the user of the guidance and notification service to share and learn from each other's experiences.For example, Mr. Smith can receive an idea about his father's experiences in the museum and possibly prepare him the ideal birthday gift.In addition, the scheme offers a notification capability to the end user.For example, the grandparents (Mr. & Mrs. Ray) first met each other in China in 1955 while they were travelling along the Great Wall of China and Mr. Ray wants to surprise Mrs. Ray once they reach that area within the museum and give her a gift as a reminder about the time when they first met.The museum management unit will notify Mr. Ray once they reach the Great Wall of China exhibit inside the Touring Hall section so he can give Mrs. Ray his present.
Mona-ServOnt guidance and notification service ontology is an ontological service in OWL-S providing guidance and messaging as sketched in the scenarios above.Fig. 12 shows the concepts in the service ontology apart from the property that connects these concepts.Moreover, these basic concepts can be elaborated on, i.e. new concepts can be further added and linked to these concepts, extending this basic ontology in order to describe different scenarios.It supports the description of relevant entities for guidance and notification functions and uses ordinary-language concepts, attributes and relations.It can be used to describe the targets and the contents of guidance and notification messages.
The service ontology captures context relating to situations of entities that occur over a region.A unit of administration is associated with an area being covered for messaging purposes, and is represented by the concept of the guidance and Fig. 13 shows an overview of the service ontology, expressing the relations between the ontology's fundamental concepts.When a museum is the unit of administration, there are important concepts in the service ontology as follows: • Museum management unit is a conceptual unit of administration associated with a region where the actors are tracked and context information including guidance and notification context information is collected and managed.
• Museum context refers to context information about the museum including museum tasks, status and events.Museum tasks refer to the list of tasks that can be done within the museum such as send notification message, get direction, leave a note, play presentation when actors arrive, and so on.For example, we want to direct Mr. Smith inside the museum towards a particular section and also inform Mr. Ray once he is near the Great Wall of China exhibit.The museum context status describes the museum context condition such as available, postpone or not available.The museum event describes the list of events that may happen within the museum such as an event for children or a scientific demonstration.
• Region refers to the area where the service is running, such as the museum environment.The region, in this example, includes several divisions such as the Science and Life Gallery, Mind and Body Gallery, and Bunjilaka Aboriginal Cultural Centre.Also, the region has its own static location and status which describes the condition of the museum; 'open', 'closed' or 'under maintenance'.
• Actor refers to the people within the museum that use the guidance and notification messaging services.
Actors have the following context information; actor location, actor type, ID, experience, status, activity and age.The actor type refers to either administrator or visitor.It is categorised to define the actor's different roles.The actor may have multiple roles.For example, the actor can be assigned as flag-bearer who has more responsibility within the museum such as a guide.Moreover, administration manages the available context information to administer the museum tours such as 'play presentation' or 'notify visitor'.In addition, the actor's relatives can be defined using the social aspect within the service ontology, especially in the case of urgent calls.The actor experience refers to the actor's opinion regarding a particular section or the whole tour.The actor status describes the actor's current condition such as 'busy', 'happy' or 'enjoying' and the activity describes the actor's current action such as 'watching presentation'.
• POI represents the geographical (which can be indoor) points that the actors are interested in and where the actor may want to perform a certain task, such as giving a present, in the case of Mr. Ray's scenario.
Examples of POI's are "Skeletons of Dinosaurs" and "Hatching the Past: Dinosaur Eggs and Babies".It has a static location.Also, the POI has a type attribute that assists in categorisation.Also, POI has status to describe the POI condition such as positive and negative.The positive POI refers to the sections where the visitor is allowed to visit, whereas, a negative POI refers to the sections that are prohibited.
The relations between concepts connect the ontology's main concepts and can be used to describe a situation in guidance and notification scenarios, as well as to describe the information shared between actors using the guidance and notification service such as finding certain actor's locations within the museum categories as follows: • Guidance and notification relation: Used to explain the guidance and notification circumstances such as "start", "finish", "end", and "belong" within the museum.For example, a presentation will start in the Forest Gallery section in 10 minutes.
• Position relation: Used to capture practical position relation concepts such as "near", "far", "next to", "close to", "far away from" and "in the neighbourhood of".
We apply the service ontology in the Melbourne Museum visitor scenario (see Fig. 14).The figure shows the classes and subclasses as well as the properties that connect them in The service ontology for the museum represents the available context information to describe the situations of actors and objects (e.g., for guidance and notification tasks) in the visitor scenario within the museum.The perspective taken is that messages are provided by (and via) the Museum management unit to the actors within the museum.Fig. 15 (a specialisation of Fig. 13) gives an overview of the main concepts in the service ontology adapted for the museum environment.
The museum represents the area, which itself has many sections.The requested messaging tasks are like those mentioned in the scenario earlier.Furthermore, the museum has POI relevant to the actors.These POIs are in position relations within the museum and with respect to the actors.
Note that the service ontology might include more concepts as explained the previous scenario.For example, Fig. 16 illustrates a detailed elaboration of the guidance and notification ontology with more concepts for museum visitors and museum administrator.
The figure illustrates the relations between the service ontology concepts as described before (in blue) and new concepts added (in white).Note that the "has" relation is short for "has X" where X is the property; for example, the actor has a type and location: actor "has type" actor type and actor "has location" location.
The service ontology clarifies the information about visitor's situations.It uses qualitative spatial relations that can be mapped from quantitative spatial relations.The spatial relations assist in the connection of information about visitor's activities within the museum.The service ontology clarifies the information that can be used by the visitor and the guidance and notification service for context-aware messaging in the museum.
We evaluate the service ontology by suggesting a range of key competency questions.These questions are answered by our version of the service ontology applied to the museum that shows the expressiveness of the ontology as it stands.But we note that, indeed, further elaboration of the ontology can be done.
Competency questions are used to show that the service ontology is able to capture and manage information useful for messaging in the guidance and notification tasks, as well as to illustrate various issues addressed by the service ontology presented earlier: • What information about actors and their context can be used if one wants to send messages to actors in the museum?
The service ontology classifies actors into different types, e.g.'visitor' and 'administrator', and have information about actors such as actor type and other context information such as 'location', 'status' and 'interests' that assists in defining the requested messaging tasks.For example, the ontology may be used to describe a group of actors according to their position relative to a certain POI in order to provide messaging services such as 'play presentation', or notifications for the group.Or, the Museum management unit (administrator) wants to trigger messages and a presentation once Mr. & Mrs. Smith are within the Mind and Body Gallery and near the sample of the brain cells.
• What information about actors is needed to facilitate actors touring the museum in a way that they see exhibits most relevant to them?
The Museum management unit serves the actors according to their interests.An actor's interest (as represented in the ontology) defines the requested messaging tasks of the museum management unit.For example, the museum management unit will explain different tours to Mr. & Mrs. Smith's family members according to their respective interests, such as directing the boys James and Mark to the Science and • What context can support the tasks of actors sharing information with each other?
The visitors can follow each other's locations and message each other to share experiences.Also, visitors can update their experiences at any time to be shared with others.Moreover, we assume that visitors can use the guidance and notification messaging service to access the museum guidance and notification tasks which include leaving notes that display their opinion, getting directions and triggering presentations.For example, James and Mark update their experiences about the Science and Life Gallery, in particular the Tarbosaurus section expressed as a note.
• What knowledge does the museum administration need to direct actors through the museum during an event such as a family member being in an emergency situation?For example, the administrator wants to inform Mr. & Mrs. Smith's family about Mrs. Ray's situation and tell them to go to the main gate in the case of an emergency.
• What is the knowledge that the service ontology offers to guide actors through the museum and to help actors know where they are?The service ontology offers a wide range of context information to the museum visitors which allows them compare their current location and the POI location so that they can check and adjust their tour plan.Also, it allows them to discover the location of other sections and define a new tour plan.
• What kind of notification can the service ontology generate?
The service ontology allows the Museum management unit to keep tracking the visitors' locations in order to provide suitable location-based notifications when it's required.For example, the Museum management unit will remind Mr. Ray about the surprise gift that he prepared for his wife once Mr. and Mrs. Ray reach the Great Wall of China exhibit inside the Touring Hall part of the museum.
• How can different actors and roles be distinguished?
The actor type helps distinguish different actors.
• How can an actor, whose role is to forward messages to other actor(s), be identified?She can be identified using the flag-bearer concept.
• What is the required knowledge for a flag-bearer to forward messages to other actors?
The flag-bearer is one of the actor types which have more responsibilities towards other actors near her position.The service ontology provides position relations to support communication among the actors, and the flag-bearer forwards the messages to a cluster via ad-hoc communication (for instance, using Bluetooth communication) filtered via position relations.
• What types of relations can be used to describe situations within museum?The spatial relations, described in the ontology earlier, relate to situations that are illustrated in the museum scenario such as position relation.In addition, the service ontology uses social relations to describe the social aspects between the actors.The spatial relations can be used together with social relations to help describe a situation.
• What is the information that actors can share with one another inside the museum?
The service ontology support actors who wish to share their experiences, and combined with context, such experiences are "geo-tagged" or located.Also, actors can share their interest as well as a range of context information.For example, actors can leave a note that presents her experience about certain sections or update her profile information to display her interests and experiences during the tour.
• What are the messaging tasks that can be performed with the museum?
The service ontology describes the tasks such as 'leave notes', 'play presentation', 'give direction' and 'reminder messaging'.These tasks are an example of range of tasks that might be included in a real implementation.
• How can messaging related to different sections of the museum be performed?
The service ontology offers information that relates to the museum's different sections using the concept "LE Division".The ontology represents the museum's different sections and divisions, and each division has a static location and type.
• How can an actor's status be described within the museum?
The service ontology uses the concept "actor status" to determine the actor's situation such as "enjoying" or "having a heart attack".In addition, the ontology has the actor's location, age and type.
• What sort of events and activity can be found in the museum?
The service ontology defines events through the use of the concept museum context that includes the museum's available events.On the other hand, the activity concept is defined within the actor's context information which describes the actor's actions at a certain time such as (Mr. & Mrs. Ray) celebrating their anniversary.
The competency questions reflect the kind of queries that the service ontology is designed to answer, in particular, in relation to context-aware messaging for a museum.The competency questions reveal the extent of the ontology's information content for messaging purposes.

B. The Health Service Ontology
Context-awareness in healthcare allows for adaptation with a changing environment and patient preferences to provide adapted health-related services.In medical services, context is commonly used to accomplish two objectives; medical condition assessment and personalised healthcare services.A health care service can link the target patient's context information with the existing health agency in order to provide medical assistance.These services help manage medical tasks such as providing medical advice and assistance.
Health context refers to the information which describes the state of an actor who needs to perform urgent healthrelated decisions.An actor can be a patient, family member, health agent, health manager, and others.The patient's context information can be provided via a smartphone to medical services.Furthermore, using context-aware information in healthcare monitoring systems assists in providing medical services which may save more lives by being rapidly responsive to health problems.To provide such context health or medical messaging services, designing ontology of useful concepts is useful.In this section, we focus on applying the Mona-ServOnt service ontology for healthcare purposes.It supports contextaware messaging for health and medical care services.
We consider the following scenario where Mr. Bill and Mr. Don are elderly gentlemen who live alone in Melbourne city after their respective spouses passed away.They have had heart surgery in the previous month.Mr. Bill's case needs to be followed up and monitored 24 hours a day for the rest of his life.However, he has two sons and one daughter and they all have their own families and work so they cannot stay with him continuously.As a result, attaching sensors to Mr. Bill's body to monitor his pressure and temperature may help solve the problem.These sensors can be connected via a wireless network to a smartphone, although they might slow down the platform as identified in [18].Then, the smartphone can send the information to health or medical control units, which can then examine the incoming sensor data and produce a report about his current medical condition.After that, this information can be forwarded to a family member, health manager, health agent or an expert to interpret and act on.For example, Dr. Davie wants a report on Mr. Bill's and Mr. Don's statuses for the last three weeks, including their blood pressure, temperature and situational information.Some of this information can be measured by the sensors whereas some others have to be supplied by Mr. Bill manually by completing a document or voice recording.
Another case is where Mr. Bill wants advice from his doctor Dr. Davie or health agency about certain activities such as going for a run at the nearby park.In addition, Smith who is Mr. Bill's son wants to monitor his father's situation because he knows that Mr. Bill is at the bar with his friends, and he is concerned about his alcohol consumption on that night.Other alternatives are also setup for that night, to prepare for the case where Mr. Bill is extremely unfortunate and direct communication with the health management team and son are lost.His phone then finds and connects to another device and uses it as a proxy to send reporting messages back.Moreover, Mr. Don went to his friend's beach house for the weekend, and Dr. Davie wants to message Mr. Don to All these scenarios need to be addressed for a health management service.In order to support such messaging, we develop the Mona-ServOnt health service ontology for contextaware messaging in such health-related scenarios.It builds on the Mona-ServOnt core service ontology, and is used for medical scenarios.It aims to support messaging using context in health-related services.For example, it assists the health agent and the family members with information about patients anywhere and at anytime.It is built and developed in OWL-S using Protege (see Fig. 17).
The service ontology concepts can be expanded using concepts to capture a particular scenario.Another view of the main concepts in the service ontology is illustrated in Fig. 18.The ontology assists in defining the targets and the contents of the exchanged messages between actors.
The important aspects of the service ontology are described as follows: • Health management unit refers to the administrative unit that is responsible for managing and tracking the actor's context information including health information, reporting medical situations as well as providing messaging services to the actors.The services are defined according to the actor type.It may represent any • Medical situation context represents the context that assists in defining the available medical context information and includes medical status, medical events and medical tasks.The medical status describes the measurement of medical conditions which contains three levels of medical situation: high, medium and low according to the patient's context information.
The medical event describes the available medical procedure such as "check-up", "medical examination" and "having surgery".The medical task includes the list of medical actions that be generated by the health management unit such as make emergency call, generate report and contact patient.
• Region signifies the area where the actors are involved in messaging (that is, the relevant area over which context-aware messaging would be supported), and located.It has a static location, division and status.The region status describes the region condition depending on the region type such as 'crowded', 'busy' or 'raining'.
• Actor refers to the people involved in messaging, but for this domain it refers to the people involved in the health monitoring and management process.We use the following context information to describe an actor in the medical situation such as actor type which can be "patient" and/or their relatives, "health manager" and "health agent".Actors may have mutable roles depending on the requested task.We also have actor ID, age, status, activity and location.Moreover, if the actor is a patient, her medical information includes temperature, blood pressure and heart rate.In addition, 'actor status' is necessary to define the actor's condition such as "healthy", "sick" or "under supervision", whereas 'actor activity' describes the actor's action or movement as we will elaborate on later.
• POI refers to the geographical points where the actor is available during the requested task.It has two types: 'private space' such as office, friend's house or home, and the 'public space' can be a park, shopping centre, bar or hospital.It has a status to describe the situation of the POI such as "open", "closed" or "not available".Also, it has a static location within the region.
Fig. 19 describes the service ontology concepts and relations in more detail.The concepts and its relations help describe medical situations.It uses similar relations as described within the previous domain relations.For example, the social relations express the people's societal relations as described in previous service ontologies.It describes context information in a context-aware health management and monitoring service.We assume there are mechanisms to sense and obtain the patient's information, to interpret the data in order to issue the appropriate level of medical action.The ontology provides a way to capture shareable information about medical situations.In addition, the service ontology can be enlarged by adding more concepts to express a certain situation.The figure shows the service ontology using more concepts and sub-concepts which supports describing the knowledge of the previous medical scenarios for Mr. Bill.
According to the medical status level and the available medical tasks, the health management unit performs the appropriate action.For example, if Mr. Bill's current medical attention situation is "high", the health management unit will inform his health manager, the closest health assistance within his range and his relatives to obtain immediate support for Mr. Bill.Furthermore, if Mr. Bill's medical situation is "low", it might only require Mr. Bill to do some easy activities such as drink a lot of water or stay away from the sun; that is, the health management unit will message Mr. Bill about the right procedure or inform his relatives about his status.The spatial relations support linking information about the medical condition and actors who are available in different places near certain POIs.
We use the following competency questions method to evaluate the ontology: • How can a doctor or health agency refer to patients for messaging purposes?The service ontology organises actors according to their context information in varying ways.For example, it groups actors according to whether they share the same POI relations or group actors within the region as well as grouping actors using their context information.For example, Dr. Davie can send a message to all his patients in Melbourne city to inform them that he will be away for a month.
• How does a medical agent or the hospital staff refer to a particular patient who is about do wrong actions near certain POIs?For example, Dr. Davie can send a message to Mr. Don who is near the beach to stay away from the water or message Mr. Bill to only walk for a short distance because of his medical situation.
• How is a medical health situation described?
The service ontology offers a rich knowledge base about a patient using her context information such as her location, temperature, blood pressure and status to be shared with other actors such as a family member, health agent or her doctor.For example, Mr. Smith can view Mr. Bill's medical information at any time.
• What happens if a patient loses the connection with the health management unit during emergency?
The service ontology supports actors being to communicate with each other using cluster services via ad-hoc communication (for instance, using Bluetooth communication).For example, Mr. Bill's phone can detect a heart condition and will forward his medical request to anyone at the bar so they can arrange an ambulance for Mr. Bill.The flag-bearer which is an actor type can always be responsible for a particular group.
• What are the requested relations to describe situations for health management?There are several types of relations to support describing medical situations.For example, there are relations to describe medical situations within the region such as the medical relation.Also, a relation to describe the position of an actor with medical situations is necessary such as position relation.Moreover, we require relations that define social aspects of a patient in case of high emergency situations, e.g., to contact her family might use a social relation.These relations are available with the service ontology.
• What information is needed for a health management service that offers messaging services to support various medical tasks?
The service ontology supports describing medical tasks.Such task information serves as additional useful context information for messaging.
• Who is involved in the health management and monitoring process?
The service ontology represents different actors involved in the health monitoring and management process.For example, Mr. Don will be directed by the health management unit to a hospital nearest to the beach house, and his doctor and family members will all be notified.
• What can an actor know about other actor's condition?
The service ontology, through the use of the concept actor status and other context information, allows the actors to describe their situations and be viewed by others.
• How can a Doctor or health agency know about the current situation and action of a patient?
The doctor or health agency needs to find out the current activity of patients so that they can perform the right action.

IV. EVALUATION
The performance evaluation of peer-to-peer services within the implementation is non-trivial to investigate the robustness of the system.We examine whether the peer-to-peer service performs well enough in terms of the time it takes to forward a message from a flag-bearer (or tracker device) to other devices (called tracker devices), and receive an acknowledgment message from those devices.A set of smartphones was used to evaluate the peer-to-peer aspect.In particular, we conducted different sets of experiments to determine the average total

A. Experiment 1
In this experiment, we use one tracker device, and assign multiple values to the distance between tracker and tracker devices, and query length.For this configuration, the results of overall send-receive times, including both discovery times of roughly 10-12 seconds and transmission times for warning messages and acknowledgment messages, are summarised in Fig. 20 and 21.We can see that there is no significant difference between the total send-receive time after increasing the distance between the tracker devices and trackers (up to 12 metres in which case the performance degrades), and the query (i.e.message) length (we assume warning messages are succinct).

B. Experiment 2
We increased the number of devices arranged linearly from two (from flag-bearer/tracker to another device) to three where a device receives a warning message from the flag-bearer and then subsequently forwards it to a third device, and the third device, on receiving the warning message, returns an acknowledgment to the second device, which then, in turn, forwards it to the flag-bearer.The results for this experimental setup are summarised in Fig. 22, showing the send-receive times including the discovery time (of roughly 12s) in all devices.We can see that there is a significant difference between the total send-receive times after increasing the number of hops by only one.The reason for this is because, in the case of three devices, the middle device needs to maintain two Bluetooth connections and this severely degrades the performance (worse than double the case of the two devices -a non-linear increase).
Overall, we conclude from the aforementioned limited www.ijacsa.thesai.orgexperiments that two communicating devices need to be within 12 metres of each other (up to only six metres preferred), Bluetooth discovery time is very large compared to message transmission time (since we are mainly dealing with small messages) -transmission time is only around 0.5% of the discovery time, and the forwarding of only two hops can take substantially more time.However, the times are in the lower bounds of what is increasingly possible, as we see that improvements with Bluetooth (such as version 4.0) and newer, more capable devices could lead to improved performance.

C. Usability of Messages
To evaluate the usability of the messages, an eight-item questionnaire was devised and distributed to 50 participants, randomly chosen from the students and staff at La Trobe University, who willingly decided to take part in the survey.The participants were provided with a brief explanation (3 to 5 min) of a fire scenario.We assume that a real fire has started in the central cafe area of the university, where actors were available and two alert messaging styles were generated.The alert message interface as well as the normal text alert message is given in Fig. 23.
The participants were required to answer the following eight questions on a scale from 1 to 5 where 1 -very low, and 5 -very high.Table 1 shows the results, distributed amongst students and staff for a set of 50 surveyed actors.For example, Q1 has a mean score of 0.72 showing that; overall, participants rated the text alert message as low.However, the standard deviation shows that there is a huge difference between participants because some rank it as very high.Most of the participants gave a score of between 4 and 5 to Q2, Q3, Q4, Q5, Q6, Q7, and Q8, with a low standard deviation meaning that there are only small differences between the participants' answers.The survey result shows that most of the participants would prefer receiving the alert message instead of the normal messaging style (Q1 & Q2).The users considered the message was very easy to use (Q3) as well as useful when deployed (Q4 and Q5); the users were in favour of its use as a help through a smartphone when in a dangerous area (Q6 and Q7).Participants indicated that the alert message conveyed enough information (Q8); the lowest score given by the users was to question Q1 where a normal text message was provided.Fig. 24 shows the system usability according to the question loading/ranges.The results show that the participants favoured the concise short alert messaging style.They noted that the alert message is well organised, the danger information is clearly separated from the rescue information and also the information is easy to track, especially during updates.

V. CONCLUSION
The ontology based CAMSMBO methodology has been presented.Moreover, the Mona-ServOnt core service ontology has then been presented in the context of two service domains and the functionality evaluated using competency questions for each respective messaging domain and focused primarily on context-aware messaging.Moreover, six research questions have been answered.We can envision a future of easier ways to develop context-aware services when developers use the entire CAMSMBO methodology or some parts of it in their constructions.CAMSMBO, with its Mona-ServOnt, offers the approach of capturing, filtering and reasoning of information to yield a knowledge base for the developers to attain a better understanding of the context-aware service domain.

Fig. 2 .
Fig. 2. The process of understanding the spatial environment

Fig. 11 .
Fig. 11.Exchange messages in the messaging protocol

Fig. 16 .
Fig. 16.Guidance and notification ontology elaborated with more concepts

Fig. 17 .
Fig. 17.Concepts in health management ontology in OWL-S

Fig. 18 .
Fig. 18.Overview of the main concepts in health management ontology

Fig. 19 .
Fig. 19.Health service ontology using more concepts and sub concepts

Fig. 22 .
Fig. 22. Service time after increasing the number of devices

Fig. 24 .
Fig. 24.Message scores using the eight questions

TABLE I .
SUMMARY OF THE RESULTS OF THE CONDUCTED SURVEY Questions Mean Std Dev.Q1.Do you like Figure A? 0.72 1.678678 Q2.Do you like Figure B? 4.04 0.497826 Q3.The message is easy to understand.4.62 0.490314 Q4.The message is useful during a disaster.4.48 0.646498 Q5.I would use the service once it is deployed.4.6 0.534522 Q6.The message would help me to navigate through a hazardous situation.4.38 0.696639 Q7.It is a good idea to use a smartphone as an emergency guide.