exercise described in the previous section, live context representations were persisted each time an evaluator (de)activated a situation. These examples were
all used to simulate the characterization of the situation. The context matching technique was then reapplied to match each of the live context representations against the modified situation. The results
indicate that there is further room for improvement,
since although the similarity of 78.6 percent of the
positive situation examples increased, so did 50 percent of the negative ones.
Ontology-Based Event Processing
We now describe a technique that compares perceived PIM events to the conditions of DRMO rules.
Events include PIM item changes (for example, file
changed, modified or deleted) and all context
changes supported by DCON (for example, file
opened, nearby person registered, and so forth). For
the comparison to take place, the rules are loaded at
runtime and kept in memory. To optimize this
process, a rule network (RN) is constructed to minimize search time. New events are broadcast directly
to the RN, which is processed with each change to
determine whether any of the rules should fire.
A Rule Network Generator
To generate the RN, each rule is decomposed into
conditions and their constraints (refer to the DRMO
description). Each distinct condition type is attached
to the network’s root as a topmost node. In the exam-
ple shown in figure 2, the condition types are Near-
by Person (represented by the DCON Peers aspect),
and Image. To each of these condition nodes the con-
strained properties are attached, followed by the con-
strained object. This trio (condition, property, object)
forms the basis for querying RDF triples in the PIM
graph. However, the DRMO value constraint is
optional, and its absence denotes a “wildcard.” For
example, as shown in figure 2, Rule 5 (R5) entirely
omits constraints, effectively expressing that a per-
sonal device needs to register the presence of any
nearby person for the rule to fire.
The join nodes join conditions and constraints
that need to be activated in parallel. For example, the
and join node leading to R5 joins this rule’s two constrained values, to say that an image needs to be created while a person is nearby. Join nodes do not correspond directly to the earlier introduced DRMO
condition operators. In particular, DRMO conditions
joined by the or operator will result in two distinct
rule nodes; for example, R1 and R2 in figure 2 could
derive from one DRMO instance saying that an image
is shared with person A or person B. This decreases
response time due to fewer triple patterns being
added to the queries.
A join node refers to two ordered inputs. Conditions joined by the succession- and precession-type
operators generate two specialized join nodes, which
indicate which condition should occur first: the one
on the left in the former case; the one on the right in
the latter. Other join nodes have no restraint on their
order. For each input, the intermediate query and
intermediate result is stored. These are used as a
shortcut to deactivate entire network paths or subpaths once a partial condition is no longer satisfied.
The intermediate query returns a result for each of
the inputs. Unless both queries return a valid result
(that is, they match perceived events) the (sub)paths
leading to the join node are deactivated.
Figure 2. An Example of a Rule Network Embodying Five Rules.
R1: Image shared with Person A
R2: Image shared with Person B
R3: Image shared with Person B,
R4: Image created, tagged
R5: Image created,
anyone is Nearby