I have copied this pyramid from an academic project site from Monash University in Australia that explores the notion of context in pervasive computing It represents quite well the location of context - between the raw events ("sensory originated data" in this picture), and the derived events ("situation" in this picture).
The rationale behind this term is that under different circumstances, we identify different situations from the same event or combination of events. This can be temporal : "during working hours" we detect different situations than "during off-working hours" or "as long as red alert is in effect, it can be spatial : "if it happens within the county limits", or it can be entity-driven such as "if it relates to platinum customers".
Is context a first level abstraction ? - not in SQL oriented languages, where the "where" is semantically overloaded, although there is a limited support to temporal contexts with the notion of "time window" (which is usually just a time offset). Some works of context support in rules exist, though not in the main-stream products in this area. However, the benefits of getting context to be first class citizen:
- It is a first-class semantic abstraction: people think in contexts.
- It provides computational efficiency. E.g. in event processing network - context can determine the partition of agents, each agent does "function within context" (i.e. detecting a "complex event processing pattern", thus events are routed only to the agents that meet their context requirement.
I'll continue to discuss contexts in later blogs.
2 comments:
"...under different circumstances, we identify different situations from the same event or combination of events..."
If I understood correctly circumstances are contexts while situations are composite events, however, in what is a circumstance different from a situation? In other words, can't a circumstance be modelled as a situation? That is, can't context be modelled as situations and thus as a composite events?
Certainly the examples of context that you mention can be modelled as situations:
C1 = "during working hours", if we have an event source that emits an event of type tick every time an hour begins then the situation "during working hours" is just a composite event on the tick events.
C2 = "during off working hours" is the negation of "during working hours", thus, another composite event
C3 = "as long a red alert is in effect", if we have an event source that emits an event when the red alert starts and another one when the read alert stops then the situation "as long a red alert is in effect" is a composite event on the alert start/stop events.
C4 = "if it happens within the community limits", in this case we can safely assume that all the events candidates to be "affected" by this "context" must carry spatial information, then the situation "if it happens within the community limits" is a composite event directly on the candidadte events to be affected by the context.
C5 "if it relates to platinium customers", again in this case we can safely assume that all the candidate events to be affected by this context carry information about wether the customer is platinium or not, hence the situation is analogous to (4).
Now let's illustrate with two examples how the "context as situation" approach achieves the same goal for which contexts were introduced, i.e., identify different situations from the same event or combination of events depending on the context.
Example1: Well, let's say that while in context C1 you want to derive situation A from the occurrence of event e1 followed by event e2 but while in context C2 you want to derive situation B, you can use the following event pattern rules:
R1: C1 and e1 followed by e2 => A /*since context C1 has been modelled as a composite event it can be used in the event pattern rule*/
R2: !C1 and e1 followed by e2 => B
Example2: let's say that only while in context C3 you want to derive situation A' from the occurrence of event e1 followed by event e2, you can use the following event pattern rule:
R3: C3 and e1 followed by e2 => A'
The point is, it seems that modelling contexts as situations, i.e. as composite events, is an elegant and economic way of introducing contexts without introducing any new entitie in the model. The approach fulfills all requirements: (1) makes contexts 1st class citizens, since context becomes composite events, which already are first class citizens and (2) allows to infer different situations from the same event patterns depending on the context.
What do you think?
Respond: yes - it is true that it is possible to express context as composition of events - however, this will miss the point of having context as a distinct semantic term. See the following blog for further details about the semantic distinctions.
Opher
Post a Comment