A Context Modeling Survey

1. A Context Modeling Survey T. Strang, C. Linnhoff-Popien German Aerospace Center (DLR), Ludwig-Maximilians-University Munich (LMU) Workshop on Advanced Context Modeling, Reasoning and Management, UbiComp, 2004 2008-09-29 Presentation by KwangHyun Nam, IDS Lab.

2. Contents • Introduction • Fundamentals • Modeling Approaches • Key-Value Models • Markup Scheme Models • Graphical Models • Object Oriented Models • Logic Based Models • Ontology Based Models • Evaluation • Summary, conclusion and outlook

3. Introduction • Past research • Published with respect to location, identity, time • Current research • To develop uniform context model, representation and query languages as well as reasoning algorithms • To facilitate context sharing and interoperability of applications • Aim of this paper • Survey of the most relevant current approaches to modeling context for ubiquitous computing

4. Fundamentals • Evolution Chain • Context dependency is a major issue in recent work in the area of ubiquitous computing systems • Ubiquitous computing is a specialization of distributed computing and mobile computing

5. Requirement for ubiquitous computing • Distributed composition (dc) • UbiComp is a derivative of a distributed computing system • Lacks of a central instance being responsible for the creation, deployment and maintenance of data and services, in particular context descriptions • Composition and administration of model varies with high dynamics in terms of time, network, topology and source • Partial validation (pv) • Desirable to enable to partially validate contextual knowledge on structure & instance level • This is particularly important • Due to the complexity of contextual interrelationships, which make any modeling intention error-prone

6. Requirement for ubiquitous computing • Richness and quality of information (qua) • The quality of a information and the richness of that may differ • Model should support quality and richness indication • Incompleteness and ambiguity (inc) • The set of contextual information at any point in time is usually incomplete and/or ambiguous • This should be covered by the model • Example • By interpolation of incomplete data on the instance level

7. Requirement for ubiquitous computing • Level of formality (for) • A challenge to describe contextual facts & interrelationships in a precise and traceable manner • “Print document on printer near to me” • What ‘near’ means to ‘me’? -> need a precise definition of terms • Each participating party in an ubiquitous computing interaction shares the same interpretation of the data exchanged • Shared understanding • Applicability to existing environments (app) • A context model must be applicable within existing the infrastructure of ubiquitous computing environment • Example • A service framework

8. Modeling approaches Environment Variables: Key-Value Models • Key-Value Models • Most simple data structure of models • Frequently used in distributed service frameworks • Described with a list of simple attributes in a key-value manner • Easy to manage • Not very efficient for more sophisticated structuring

9. Modeling approaches (cont’d) • Markup Scheme Models • Hierarchical data structure consisting of markup tags • Typical representatives: profiles • Based upon a serialization of a derivative of SGML • Examples • Defined as extension to • Composite Capabilities/Preference Profile (CC/PP) • User Agent Profile (UAProf) • Comprehensive Structured Context Profiles (CSCP) • Unlike CC/PP, not define any fixed hierarchy • Pervasive Profile Description Language (PPDL) • Allow to account for contextual information and dependencies when defining interaction pqtterns on a limited scale • Centaurus Capability Markup Language (CCML)

10. Modeling approaches (cont’d) • Graphical Models • Particularly useful for structuring, but usually not used on instance level • Examples • Well known: UML • A strong graphical component (UML diagram) • Due to its generic structure, UML is appropriate to model the context • Contextual Extended ORM • Basic modeling concept in ORM is the fact • The modeling of a domain involves indentifying proper fact types & roles • Extended ORM is allowed to categorize fact types either as static or as dynamic

11. Modeling approaches (cont’d) • Object Oriented Models • Intention behind object orientation is (as always) encapsulation and reusability • Examples • Representative: Cues (TEA project) • Provide an abstraction from physical and logical sensors • Regarded as a function • Taking the value of a single physical/logical sensor up to a certain time as input • Providing a symbolic/sub-symbolic output • Active Object Model (GUIDE project) • All the details of data collection and fusing are encapsulated within the active objects • Hidden to other components of the system.

12. Modeling approaches (cont’d) • Logic Based Models • Logic defines conditions on which a concluding expression or fact may be derived from a set of other expressions or facts (reasoning) • Context is defined as facts, expressions and rules • High degree of formality • Examples • McCarthy’s Formalizing Context • To give a formalization recipe which allows for simple axioms for common sense phenomena • Akman & Surav’sExtended Situation Theory • Extend the Situation Theory by Barwise & Perry • To model the context with situation which are ordinary situations

13. Modeling approaches (cont’d) • Ontology Based Models • Ontology is used as explicit specification of a shared conceptualization • Strong in the field of normalization and formality • Context is modeled as concepts and facts • Examples • ASC model of Context Ontology Language (CoOL) • Used to support context-awareness in distributed service frameworks for various applications • CONON ontology • An upper ontology which captures general features of basic contextual entities and a collection of domain specific ontologies and features. • CoBrA system • Provide a set of ontological concepts to characterize entities

14. Evaluation • Key-Value Models • Weak on the requirements 1 to 5 (-) • The simplicity of key-value pair is a drawback if quality meta-information or ambiguity shall be considered (-) • Solely the applicability is a strength (+) • Markup Scheme Models • Strong concerning the partial validation requirement (++) • Standard CC/PP & UAProf have only restricted overriding and merging mechanisms (-) • Applicability to existing markup-centric infrastructures is a strength (++)

15. Evaluation (cont’d) • Graphical Models • The strengths are definitely on the structure level • Mainly used to describe the structure of contextual knowledge and drive code or an ER-model from model • Distributed composition requirement has some constraints on the structure level (-) • Object Oriented Models • Strong regarding the distributed composition requirement (++) • A higher level of formality is reached through the use of well-defined interfaces (+) • The invisibility as consequence of encapsulation is a little drawback

16. Evaluation (cont’d) • Logic Based Models • Be composed distributed (++) • Formality is extremely high (++) • However, this model is weak with respect to other requirements(-) • Ontology Based Models • Strong in the distributed composition requirement (++) • Inherit the strengths in the field of normalization and formality from ontologies (++) • All requirements for UbiComp enable to be covered by this model.

17. Summary, Conclusion and Outlook Miss Ubiquitous Contest I’m so nervous Me, too. Thank you. I give all these glory to you!! Winner : Ontology But, all others are also valuable.

18. Summary, Conclusion and Outlook • The most promising assets for context modeling for ubiquitous computing environments • Ontology category • But, the other approaches aren’t unsuitable for UbiComp • This list of context modeling approaches is comprehensive, but - as in all surveys - incomplete

19. Discussion • Pros • Indicate definite criterion for comparison of models for ubiquitous computing • May help to identify appropriate approach for ubiquitous computing applications • Cons • Lack reasons of analysis decision with respect to criterion of some items • Typographical error • Specialisation -> Specialization ( 1 Page, right-side 6th line) • Categorised -> Categorized (3 Page, in content of Graphical Models)