intermediary concept of observations. As a result, as
shown in figure 1, context attributes are not directly
attached to the element representations, but to their
observation(s). Thus, if a person is carrying two
devices, each of which is able to detect the environment’s temperature (context element), DCON is able
to handle both temperature readings (attributes)
Each observation is linked to a data source, time-stamped, and also carries a validity period, which is
predefined depending on the element type. Based on
these periods, a garbage collector can remove outdat-ed information. For example, a Wi-Fi in range (
connectivity aspect) is connected to one device (
observation 1) but not another (observation 2). For each
data source, DCON also registers the current mode
(such as silent mode), the time of last activity and last
Aspects and elements can be assigned a specific
weight. Weights are not relevant for the live context.
However, they are crucial in the characterization
process of stored situations, as will be described later.
Situations are approximated based on one or more of
their instances (gray box C). Instances can be positive (that is, situation examples) or negative (
coun-terexamples), and consist of past live context snapshots. Thus, at the schema level, live contexts and
situations have few differences. However, the former
is meant to be unique and up to date, whereas as
many distinct situations as required can be stored.
Moreover, situations are independent of time since
they can recur. To improve the characterization
process, some elements can be marked as excluders
or required — meaning that their observation, or lack
of, excludes a situation from the candidates.
Building Blocks for Context-Driven Rules
The Di.me rule management ontology (DRMO) is able
to string PIM concepts and items as conditions for
personalisable context-driven rules. Using both time-independent and time-dependent attributes provided
by the ontology framework, it allows for each condition to be customized by selecting those circumstances under which the condition holds true. For
instance, when adopting a specific person as a condition, one can specify that the person must be nearby
(a time-dependent attribute provided by DCON).
However, if adopting the person concept as a condition, one can filter this to state also that the person
must be a member of a specific group (a time-independent attribute specified by PIMO). Adopting concepts rather than specific items is akin to enabling
wildcards — in the above example, signifying that
any nearby person satisfying the membership attribute will match the condition. We refer to these filters
as constraints. Multiple conditions can be strung
together, with the ultimate objective of firing predefined actions when all the conditions are met.
DRMO, also shown in figure 1, supports all the
above concepts and relationships. Conditions can be
joined together using four logical operators: and
(both joined conditions have to occur), or (occur-
rence of any joined condition), succession and preces-
sion (a condition must occur before, or after, anoth-
er). DRMO conditions can also be negated. The
ontology supports three general types of conditions,
corresponding to PIM items (resources) being creat-
ed, modified, or deleted. DCON changes are always
classified as modified items, for example, a live con-
text aspect registers a new person detected nearby
(attached to the Peers aspect). Item creation and
deletion are strictly reserved for PIM items (for exam-
ple, new email reaches the inbox, a new file is creat-
ed or deleted).
A condition can be flexibly constrained in two different ways. A constraint can be placed on the condition as a subject or the object of an RDF triple,
together with the specified property. Thus, the constraints on object or subject attributes shown in figure 1 are always used in conjunction with the constraint on property attribute. We explain the purpose
of these constraints through a simple example. If a
person (PIMO) condition needs to be filtered to say
that the person must belong to a particular group, a
constraint on object is created to look for a triple
stating that the person (subject) is a member of
(property) a group (the constrained object). Inversely, the same filter can be achieved by constraining
the person condition such that a group (constrained
subject) contains (property) the person (object).
Constraints may also have relational operators to filter out datatype values rather then relationships, for
example, to denote a person (subject) having a trust
value (property) that is greater than (the property
operator) a fixed value, or a file-type condition to
match files containing (property operator) a specific
The semantics of DRMO actions are meant to be
understood by a context-aware system, for example,
an email action should send the respective email.
Since in several cases items in a rule’s condition are
linked to the action, DRMO defines an action subject
and object. In the example, the email message is the
subject, and the recipient is the object.
To enable situation recognition, the live context is
compared to stored situations at a configurable regu-
lar interval to return a similarity score. Both represen-
tations consist of DCON instances and are stored as
RDF graphs. As we explain below, the comparison
takes into account all DCON schema levels: aspects,
observations, elements, and attributes. In addition,
we also describe a technique for the semiautomatic
characterization of situations, given that it is input for
a number of positive and negative training examples.