Towards a hybrid approach to Towards a hybrid approach to context modelling, reasoning and context modelling, reasoning and

interoperationinteroperation

Karen Henricksen

CRC for Enterprise Distributed Systems Technology

(DSTC)

Steven Livingstone and Jadwiga Indulska

School of Information Technology and Electrical

Engineering, The University of

Queensland

MotivationMotivation

Context modelling requirements:

Formality

Support for efficient reasoning

Support for imperfect context information (imprecise, ambiguous, incomplete information)

Appropriate abstractions to support requirements analysis, design and programming tasks

Support for interoperability

BackgroundBackground

We have been building context-aware applications and infrastructure for several years using our own layered modelling approach

Our approach: leverages proven information modelling techniques developed by

the IS community provides two levels of abstraction:

facts situations

To evaluate possible extensions to our modelling approach, we: performed a comparison with recently proposed ontology

approaches investigated the potential benefits of a hybrid approach

A comparison of context modelling A comparison of context modelling approachesapproaches

Requirements Our approach Ontology-based approaches

Formality

Support for efficient reasoning (but potential exists

to extend supported types of reasoning)

Possible but tools for new standards

are still limited

Support for imperfect

information

Possible but difficult (especially reasoning)

Abstractions for design/programmi

ng

Interoperability

Overview of our modelling approachOverview of our modelling approach

We model context as follows: fact types (and constraints) are modelled graphically using

CML

situations are defined in terms of logical expressions over fact types and variables

CML provides a natural graphical notation to support design and requirements analysis tasks

Situations and context-dependent preferences (expressed in terms of situations) are used as a basis for our programming models

CML modelling conceptsCML modelling concepts

Special fact types: Static, sensed, derived, profiled

Historical

Alternative/ambiguous

Quality-annotated

CML exampleCML example

Person(name)

Device(id)

located near

permitted to use

Activity(name)

engaged in

[ ]

Comm.channel(id)

has channel

Location(name)

located ata

*

requires device

Comm.mode(name)

has mode

s

s

located at

a

synchronous

Certainty

Probability(nr)+

Legend

Object type

Fact type

Static fact type

Sensed fact type

Derived fact type

Profiled fact type

Alternative fact type

Historical fact type

Uniqueness (key)Constraints

Dependency

*

a

[ ]

s

Modelling situationsModelling situations

Defined using a novel form of predicate logic Contain variables (application context) and fact types

(shared context) Examples:

CanUseChannel(person, channel) :forall device ● RequiresDevice[channel, device] ● LocatedNear[person, device] and PermittedToUse[person,

device]

Related work: ontology-based Related work: ontology-based approachesapproaches

Many context ontologies have recently appeared based on new standards such as OWL

These support reasoning for: Derivation of new types of context information Detection and correction of inconsistencies Evaluation of privacy policies (e.g., eWallet, CoBrA)

Shortcomings: Reasoning is being held back by immature standards/tools Good potential for interoperability, but not yet realised Focus is on modelling and reasoning, not on provision of

software engineering abstractions

Towards a hybrid approachTowards a hybrid approach

We have evaluated extending our approach to use ontology concepts for: modelling additional concepts that are not well supported

by CML reasoning for:

deriving additional context information model checking interoperation

Our evaluation focused on: OWL: The new W3C standard and currently most popular

ontology language SWRL: Extends OWL with rules by merging OWL and RuleML

Using ontology concepts for Using ontology concepts for context representationcontext representation

To compare our current representation with an ontology-based representation, we: Mapped our current modelling concepts into an OWL

representation Evaluated the potential to extend this to capture

additional concepts Results:

Positives of ontology representation: Reuse of concepts is straightforward Meta-modelling: can model the modelling concepts

themselves (and reason about them) Can model some additional properties such as transitivity

Using ontology concepts for Using ontology concepts for context representation (continued)context representation (continued)

Negatives:

Unnatural to model complex relationships in OWL (must be represented as objects rather than properties)

OWL provides no built-in support for expressing uncertainty

Verbose (in contrast to CML’s user-friendly graphical notation)

Using reasoning to derive additional Using reasoning to derive additional context informationcontext information

OWL can support reasoning based on relations such as transitivity and commutativity

OWL does not currently support axiomatic rules (but these can be expressed in SWRL)

We compared our situation-based reasoning approach with an SWRL rules approach by attempting to map situations to rules

Example mappingExample mapping

Situation: CanUseChannel(person, channel) :

forall device ● RequiresDevice[channel, device] ● LocatedNear[person, device] and PermittedToUse[person, device]

SWRL rule:<ruleml:imp> <ruleml:_body> <swrlx:classAtom> <owlx:Class owlx:name="&cml;RequiresDevice"/> <ruleml:var>requiresDevice</ruleml:var> </swrlx:classAtom> <swrlx:individualPropertyAtom swrlx:property="&cml;RequiresDeviceChannel"> <ruleml:var>requiresDevice</ruleml:var> <ruleml:var>channel</ruleml:var> </swrlx:individualPropertyAtom>

Example mapping (continued)Example mapping (continued)

<swrlx:individualPropertyAtom swrlx:property="&cml;RequiresDeviceDevice"> <ruleml:var>requiresDevice</ruleml:var> <ruleml:var>device</ruleml:var> </swrlx:individualPropertyAtom> <swrlx:classAtom> <owlx:Class owlx:name="&cml;LocatedNear"/> <ruleml:var>locatedNear</ruleml:var> </swrlx:classAtom> <swrlx:individualPropertyAtom swrlx:property="&cml;LocatedNearPerson"> <ruleml:var>locatedNear</ruleml:var> <ruleml:var>person</ruleml:var> </swrlx:individualPropertyAtom> <swrlx:individualPropertyAtom swrlx:property="&cml;LocatedNearDevice"> <ruleml:var>locatedNear</ruleml:var> <ruleml:var>device</ruleml:var> </swrlx:individualPropertyAtom>

Example mapping (continued)Example mapping (continued)

<swrlx:classAtom> <owlx:Class owlx:name="&cml;PermittedToUse"/> <ruleml:var>permittedToUse</ruleml:var> </swrlx:classAtom> <swrlx:individualPropertyAtom swrlx:property="&cml;PermittedToUsePerson"> <ruleml:var>permittedToUse</ruleml:var> <ruleml:var>person</ruleml:var> </swrlx:individualPropertyAtom> <swrlx:individualPropertyAtom swrlx:property="&cml;PermittedToUseDevice"> <ruleml:var>permittedToUse</ruleml:var> <ruleml:var>device</ruleml:var> </swrlx:individualPropertyAtom> </ruleml:_body> <ruleml:_head> <swrlx:individualPropertyAtom swrlx:property="CanUseChannel"> <ruleml:var>person</ruleml:var> <ruleml:var>channel</ruleml:var> </swrlx:individualPropertyAtom> </ruleml:_head></ruleml:imp>

Using reasoning to derive additional Using reasoning to derive additional context information (continued)context information (continued)

Evaluation:

SWRL does not offer a natural way to reason over uncertain context information (in contrast, we support ambiguous and incomplete information using a three-valued logic)

SWRL representation is verbose and unwieldy (but a more compact notation can be used)

Situation logic’s explicit quantification is more natural than SWRL’s implicit quantification

Using reasoning for model checkingUsing reasoning for model checkingand interoperation and interoperation

In OWL, can capture: relationships between concepts (e.g., equivalence of

classes and properties) various constraints (e.g., restrictions on property values)

Can use these to reason about models (both for model checking and interoperation)

Model checking examples: can define static fact types in a way that precludes other

classifications such as temporal or sensed can check for valid uniqueness constraints on fact types,

cyclic dependencies, etc.

Using reasoning for model checkingUsing reasoning for model checkingand interoperation (continued)and interoperation (continued)

Interoperation examples:

can define equivalence between classes or properties to transfer information between context models

can define (SWRL) rules for translating different representations

ConclusionsConclusions

Ontology-based reasoning about context offers few benefits over situation-based reasoning

We are most interested in ontology-based reasoning over context models

Current ontology approaches do not fully explore the potential of this type of reasoning

We are exploring a hybrid approach in which we: model using our CML and situation abstractions incorporate ontology-based reasoning about the models

into our tools/infrastructure for model checking and interoperation