This paper refers to methods and tools for enabling context detection and management based on events. We propose a context model that builds on top of previous efforts and we give details about the mechanisms developed for context detection in event marketplaces. In addition, we show how simple or complex events can be used in combination with external services in order to derive higher level context with the use of Situation-Action-Networks (SANs). Specifically, we present two different approaches, one for detecting low level context and another one for deriving higher-level contextual information using SANs. We present an illustrative scenario for demonstrating the process of specialization of our generic context model and its instantiation based on realtime events.
Context is “any information that can be used to characterize the situation of an entity,
i.e., a person, place, or object that is considered relevant to the interaction between a
user and an application, including the user and applications themselves.” [
Events from event marketplaces are an important source of context for
servicebased applications that consume them because they may convey important
information, which is relevant for service execution and adaptation. To achieve the
goal of injecting event processing results to context, an event-based context model is
needed along with context detection and derivation mechanisms. In previous work [
The simplest SAN possible is a two level tree with a parent (root) node and three child nodes, each of them having specific semantics. A parent node models the Goal sought. The leftmost child node describes a situation that must occur, in order to start goal seeking. The middle child node corresponds to context update and requires that a specific contextual condition is true before continuing with the SAN traversal. The rightmost child node specifies the action to be taken in order to fulfil the goal. Rightmost node can also be a sub-goal node with its own three child nodes, or it can even be a construct joining several sub-goals in sequence or in parallel. As the SAN becomes more complex, involving several subgoals (Figure 1), it deepens and reveals its hierarchical and goal-directed characteristics. In this work, SANs are extended so that they can be used for detecting and deriving context from events.
This paper continues with a discussion about related work in the domain of eventbased context management, while in section 3 it presents a generic context model that is considered appropriate for the needs of event marketplaces. In section 4, we consider two different approaches, one for detecting low level context and another one for deriving higher-level contextual information using SANs. In section 5, we show how the generic context model can be specialized so that it can be instantiated to support an example scenario. We conclude in section 6 with a summary of our event-based context management approach.
Context-awareness in service-oriented systems refers to the capability of a service or
service-based application to be aware of its physical environment or situation and to
respond proactively and intelligently based on such awareness; see e.g. [
Our work focuses on detecting context changes which correspond to either atomic
or complex events and use complex event processing to model and identify them.
Similarly to [
We propose a context model as a stepping stone for facilitating event-based context
detection and derivation functionality, in order to better understand situations in
dynamic service oriented environments that demand for new additional information
sources or/and lead to a number of service adaptations as means for successfully
coping with dynamic environmental changes. In order to achieve the goal of
extracting contextual information, analyzing them and then deriving higher level
context, we follow an event-based context modelling approach. In this section, we
present such a Context Model (Figure 2), expressed in UML 2.0 class diagram. This
model is based on the W4H model [
This Context Model expresses the temporal (i.e. When), spatial (i.e. Where),
declarative (i.e. Who, What) and explanatory (i.e. How) dimensions of context having
as central point of focus the notion of Entity. We refer to either physical or virtual
entities with specific profiles and preferences that characterise them (e.g. vessel, port
authority information system etc.). This way context obtains substance around the
notion of an entity which can be a customer of an event marketplace system. The
context class in our model constitutes the aggregation of several different context
elements that may refer to five dimensions of context. Each Context element can have
a value that can be acquired from the situation node of a SAN and/or a derived value
that arises from any kind of reasoning process or call of external services. All context
related information can be captured as objects which can store either a single scalar
value or multiple values such as vectors, sets, lists etc. As any of the available context
models [
In our context modelling approach and implementation, we consider entities as being able to own SAN trees. The scope of context elements is distinguished into three levels: “Local”: Context elements can be updated and used only by a specific SAN instance. “Entity”: Context elements can be updated and used by any of the SANs owned by the same entity. “Global”: Context elements can be updated and used by all SANs independently to which entity they belong to.
Using the SAN Editor, we can perform context model specializations based on the application scenario and can formulate the necessary queries to events for extracting contextual information. We provide two approaches for acquiring context from simple or complex events and instantiating our context model. Both approaches use the SAN Editor for: 1. defining SPARQL queries to specific RDF event payload information that can update the values of an entity’s context elements; and 2. defining SANs that can use information from several event streams, analyse them and/or combine them with external services, in order to update the derived values of context elements. In this way, we succeed in acquiring higher level context compared to the lower level information that events carry.
The application of both approaches is presented in the following section through the marine vessel traffic illustrative scenario, which uses events related to marine traffic control that can be used to detect potentially dangerous vessel movements informing a controller when two vessels are approaching each other.
A vast amount of real time events are available from portals connected to automatic identification systems (AIS) that contain important vessel information worldwide (e.g., speed, course, vessel type, wind conditions etc.) and the several different users/authorities that might be interested in them. In order to exploit efficiently all these information in an automated way we use our context model and present how it can be specialized for the specific application domain while we give a glimpse to its possible run time instantiations.
Context Model Specialization: Our context model needs to become application specific in order to be useful. In this section, we focus on context model specialisation which pertains the definition of entities along with their context elements necessary for capturing the context in terms of a specific application scenario. We use the marine vessel traffic scenario which is related to vessel and marine traffic control observing systems.
In this scenario, we consider the entity Port Authority as the owner of all SANs discussed below while the entity of interest is the Vessel. In order to capture contextual information related to Vessels’ context, we have defined the following Context Elements that shape the specialization of our context model: Speed, Course, Position, Status, Distance2Port.
In Figure 3, the reader can find the complete list of the five context elements associated with the Vessel entity, specialising the context model for the marine vessel traffic scenario, using the SAN editor. This model specialisation will be instantiated at run time through the context detection and derivation approaches that are presented in the following sections.
Detecting Context: In this section, we discuss our first approach for acquiring context from simple or complex events and instantiating our context model. Using SAN Editor, we are able to define SPARQL queries to specific event payload information that update the values of an entity’s context elements. As we show in the following figure 3 during our experiment we received events regarding a specific vessel called “Risoluto”. Details regarding the entity such as profile information automatically update the context of this entity based on the detected events in the situation node of a SAN.
Figure 4 depicts a screenshot of SAN editor with the required SPARQL queries for instantiating the “Position” context element of the vessel entity (Latitude/Longitude). Specifically, we query the vessel entity event payload with respect to the “LatLon” information. Similarly, other queries are used in the editor regarding the “Speed” and “Course” context elements and refer to event=based detection of low level context.
Deriving Context using SANs: Our second approach that we apply for extracting context from simple or complex events and instantiating our context model using SANs. We define a number of SANs that can use information from several event streams and combine them with external services in order to update the derived value class of context elements. In this way, we succeed in acquiring higher level context compared to the lower level information that events carry.
This context derivation can be complex and may involve multi-level SANs. Figure 1 shows a SAN that upon traversal will be able to update the derived value class of the Status context element. Specifically, the status of the vessel becomes “Docked” whenever we detect a vessel that has been stopped and its distance from any port is close to zero or “UnderWay” whenever vessel’s speed is close to average and “In Danger” when the system realizes that the vessel has almost stopped (away from any port) and strong winds are blowing from the side. Figure 5 is a screenshot of the runtime execution of the specific SAN for deriving the vessel’s status. A pop up alert has been added in order to better demonstrate the context derivation regarding the Status context element.
In this paper we presented methods and tools for enhancing context detection and management based on events. This proposed context management approach presented here is considered appropriate for the needs of event marketplaces. We described a Context Model that was used by the developed mechanisms for performing eventbased context detection and presented two different approaches for detecting low level context (using SAN Editor) and deriving higher-level contextual information using Situation-Action-Networks (SANs). We provided with a meaningful context model specialization and demonstrated how simple or complex events coming from an event marketplace can be used and combined with external services, in order to derive higher level context with the use of SANs.
This work has been partially funded by the European Commission under project PLAY (Grant FP7-258659). The authors would like to thank the project partners for their advices and comments regarding this work.