1 / 20

Towards a hybrid approach to context modelling, reasoning and interoperation

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.

elewa
Download Presentation

Towards a hybrid approach to context modelling, reasoning and interoperation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

  3. 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

  4. A comparison of context modelling approaches

  5. 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

  6. CML modelling concepts • Special fact types: • Static, sensed, derived, profiled • Historical • Alternative/ambiguous • Quality-annotated

  7. CML example has mode synchronous s Comm. channel (id) Comm. mode (name) Legend s requires device 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 has channel Probability (nr)+ permitted to use s Person (name) Device (id) * Certainty * engaged in a a located near located at [ ] [ ] a Location (name) Activity (name) located at

  8. 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]

  9. 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

  10. 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

  11. 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

  12. 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)

  13. 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

  14. Example 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>

  15. 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>

  16. 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>

  17. 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

  18. Using reasoning for model checkingand 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.

  19. Using reasoning for model checkingand 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

  20. 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

More Related