Towards a hybrid approach to context modelling, reasoning and interoperation 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

Motivation 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

Background 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 approaches RequirementsOur approachOntology-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/programming Interoperability

Overview 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 concepts Special fact types: Static, sensed, derived, profiled Historical Alternative/ambiguous Quality-annotated

CML example Person (name) Device (id) located near permitted to use Activity (name) engaged in [ ] Comm. channel (id) has channel Location (name) located at a * 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 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 approaches 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 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 context 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 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 context 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 mapping Situation: CanUseChannel(person, channel) : forall device ● RequiresDevice[channel, device] ● LocatedNear[person, device] and PermittedToUse[person, device] SWRL rule: requiresDevice <swrlx:individualPropertyAtom swrlx:property="&cml;RequiresDeviceChannel"> requiresDevice channel

Example mapping (continued) <swrlx:individualPropertyAtom swrlx:property="&cml;RequiresDeviceDevice"> requiresDevice device locatedNear <swrlx:individualPropertyAtom swrlx:property="&cml;LocatedNearPerson"> locatedNear person <swrlx:individualPropertyAtom swrlx:property="&cml;LocatedNearDevice"> locatedNear device

Example mapping (continued) permittedToUse <swrlx:individualPropertyAtom swrlx:property="&cml;PermittedToUsePerson"> permittedToUse person <swrlx:individualPropertyAtom swrlx:property="&cml;PermittedToUseDevice"> permittedToUse device <swrlx:individualPropertyAtom swrlx:property="CanUseChannel"> person channel

Using reasoning to derive additional 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 checking 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 checking 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

Conclusions 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