What Would You Like To Drink

1. What Would You LikeTo Drink? Stefano Spaccapietra Ecole Polytechnique F�d�rale de Lausanne (EPFL) Database Laboratory http://lbd.epfl.ch joint work with Christine Parent University of Lausanne

2. 2 A simple, non-ambiguous question �

3. 3 An ambiguous question � Where do you come from? Geneva (the airport I started from)? Lausanne or Switzerland (the city I�m living in)? Switzerland (the country I�m living in)? France (the country I am a citizen of)? Milano (the place I was born)?

4. 4 Context is pervasive Google "Everything is Context-Dependent" "If everything is context dependent, then what about the help desk scenario. Can you please tell me what context you are in?" http ://www.isr.uci.edu/events/twist/twist99/presentations/day/day-qna.html "Third, everything is context dependent. I've done nothing wrong when I stumble out of 1015 drunk as hell and hail a cab, but my drunken stumble is not something that I want to expose to my advisor or, frankly, the government." http://www.zephoria.org/thoughts/archives/2006/06/09/nsa_spying_on_d.html "Everything is context-dependent. That's what makes it fun!" http://www3.java.no/JavaZone/2005/presentasjoner/TedNeward/effectivehtml/text12.html

5. 5 � yet some things "look" context-independent Universal truth? Assertions that convey a state of affairs not subject to interpretation and not influenced by anything else, e.g.: I am awake I am giving a talk Currently, Paris is the capital of France �. Notice, however, the implicit "now" context and the "speaker" context Universal truth --> agreed unique context

6. 6 Context-aware data services Services that return data that pertain to the same context as the query

7. 7 What's in a Context? Context: "any information that can be used to characterize the situation of any entity. An entity is a person, place, or object, that is considered relevant to the interaction between a user and an application, including the user and the application themselves" (Anind K.Dey, 2000) Any information? "where, when, who, why, what, how" (Schilit et al., 1994) "A context (or "microtheory") is a set of assertions, representing a particular set of surrounding circumstances, relevant facts, IF-THEN rules, and background assumptions" (Cyc�) http://www.cyc.com/cycdoc/course/what-is-a-context.html

8. 8 Multiplicity of Contexts Context-use is context-dependent "For example, if you just want to ask Cyc� about brushing your teeth, Cyc� doesn't need to know every kind of fact in the Cyc� Knowledge Base, such as how much a toothbrush costs. In the ManualHumanActivitiesMt context for typical human activities (like tooth-brushing) there is no fact about this, although in a different context, ShoppingGMt, the cost is there because it's relevant to shopping." Contexts are different from ontologies Defining the semantics of concepts (ontologies), versus Defining which of the many semantics of a concept holds due to the "environment" surrounding the use of the concet^pt

9. 9 Examples Range Low-level context domains: location, time, nearby objects, networking configuration, orientation, environment (light, temperature, pressure, sound, pollution, etc.) High-level context domains: social context (e.g., social status of the user or of the location) personal context (e.g., user�s intention and preferences: "user profile")

10. 10 Example Application: LBS

11. 11 Contexts and Ontologies in LBS From User Queries to Context-aware Queries What if query terms are unknown? ==> External Ontologies What if query terms are known but ambiguous or imprecise?  ==> LBS Ontology What implicit knowledge about the user can help in better grasping the query? ==> User Profiles What other factors can influence the answer to the query?  ==> Environment Profile Contextualized Data Which data for which context? ==> Data profile Context-aware Data Service Matching user query with data within the chosen context

12. 12 Issues Making queries context-aware Add relevant predicates inferred from user profiles and context descriptions Basically a query modification strategy Replacement patterns are one technique, but they need pre-planning Matching the query against the data Similarity matching largely investigated, including approximate matching Making data context-aware Few investigations, limited results ==> my topic now

13. 13 Multiple Viewpoints

14. 14 Multiple resolution

15. 15 Multiple geometry

16. 16 Hierarchical value domains Describe the same property at different abstraction levels Hierarchical value domains for attributes (similar to classification hierarchies for objects)

17. 17 Contextualizing Data Identify the contexts e.g. a geographical database for risk assessment 3 resolutions : 1/1�000, 1/5�000, 1/25�000 3 viewpoints : Technician, Management, Public 9 contexts => {�T1, T5, T25, M1, M5, M25, P1, P5, P25 } Associate to each schema and database element the context ids of the contexts it belongs to Each real world object or link may have one or several representations (zero, one or more per context) Elements may be shared by different contexts Transactions may run using a single context or using multiple contexts

18. 18 Alternatives Designing a multi-context database Integrated modeling all representations merged in oneobject (or relationship) type Separate modeling each representation = one object type Inter-representation link Using a multi-context database Open as single-context => �normal� database Open as multi-context => a new kind of database new consistency rules

19. 19 Related Work: Cyc Cyc: One knowledge base as a container for multiple micro-theories (contexts) Microtheory = named set of assertions (facts and rules) Microtheories are organized into a hierarchy (with downward inheritance) Microtheories are autonomous: the same phenomenon may be represented in different microtheories in different, possibly "conflicting" ways not in one sub-MT and its super-MT Queries are local to a microtheory (+ inheritance)

20. 20 Related Work: Multi-Viewpoints A way for extracting a module (�viewpoint�) from an existing OWL ontology A module is defined by selecting a sub-vocabulary set of concept and role names Approximate reasoning infer the new axioms of the module Subsumption relations of a module are valid in any of its sub-modules Restrictions wrt OWL: no nominals no role hierarchy ...

21. 21 Related Work: C-OWL & DDL A formalism for reasoning with multiple local ontologies linked by semantic mappings (alike federated databases) "Bridge rule": directional mapping between two concepts of two ontologies O1 --> O2 O1: Publication is equivalent to O2:Paper O1 --> O2 O1: PhDThesis is more specific than O2:Thesis Distributed DLs Interpretation of the DDL: A local interpretation per ontology, and for every couple of ontologies linked by bridge rules, a binary relation between their instances. An interpretation is a model of the DDL: Each local interpretation is a model of the local ontology, and each bridge rule is satisfied.

22. 22 C-OWL & DDLs (2) Distributed reasoning Subsumptions propagate across ontologies � But bridge rule directionality does not ensure isolation, � and local inconsistencies may contaminate other ontologies ==> A special interpretation, hole, allows to integrate even inconsistent Tboxes The tableau algorithm is extended to DDLs

23. 23 C-OWL & DDLs (3) Lessons from DDBs Semantic mappings between roles are essential (issue now addressed) distributed reasoning? Semantic mappings should express binary relations between the (actual) interpretations O1: PhDThesis is more specific than O2:Thesis ==> All O1: PhDThesis are O2:Thesis

24. The MADS contextualization mechanism

25. 25 Integrated Modeling

26. 26 Integrated Instances

27. 27 Separate Modeling

28. 28 Multi-level context-awareness

29. 29 Consistency rule #1 (containment) Component / composite A composite element holding for contexts {c1, c2, c3} => Its components may at most hold for the same contexts {c1, c2, c3} Examples Object type -- attributes Object type -- instances Context-varying Attribute -- values Relationship type -- roles

30. 30 Consistency rule #2 Consistency rule for common attributes :Two representations of the same object (relationship) instance must have the same value for all common attributes Except for attributes whose value is context-varying

31. 31 IS-A and contexts Populations are context dependent

32. 32 Consistency rule #3 Contexts for an IS-A link and for overlapping link are included in contexts of both linked types

33. 33 Context-aware Relationships A relationship type may have context-varying Semantics Adjacent (i.e., link spatial objects with topologically adjacent geometry) Plain Roles Exam ( Student, Course ) Exam ( Student, Course, Professor ) Role cardinality (e.g., monovalued vs multivalued role)

34. 34 Consistency rule for relationships In context-varying relationship types, for each multi-context instance a given role always links the "same" instance of the related object type, irrespectively of the context E.g.:The same Exam relationship must link the same Student and Course objects for all contexts the instance belongs to.

35. 35 Local and bridge relationships Blue context: the context of the relationship instance is locali.e. visible to transactions with blue context only Red context: the context of the relationship instance is not locali.e. not visible to transactions with red perception only.visible to transactions with at least (red and yellow) or (red and blue) contexts Green context: the context of the relationship instance is not local.visible to transactions with at least (green and blue) or (green and red and yellow) contexts

36. 36 Relationship Creation in MC DB S = INSERT Student (value:<�.>) ADD Student (oid=S, value:<�..>) C = INSERT Course (value:<�.>) R= INSERT Exam (student: S, course: C, �����������������������������������������������������value:<�.>)

37. 37 Open a DB with a single context

38. 38 Example: single context Open

39. 39 Single-Context Reducibility Open (database, this-context) A unique context (c) => a �normal� database All object types belonging to this context with all their attributes defined for this context with all their instances that belong to this context and as defined for this context, i.e. the �c representation� of the object type All relationship types that belong to this context and link object types belonging to this context (local) with all their roles that belong to this context with all their attributes that belong to this context with all their instances that belong to this context and are local All multi-instantiation links that belong to this context

40. 40 Multi-Context Semantics Open (database, context_set) Several contexts => multi-context database All object types "belonging to at least one of the contexts of the context_set" (BALOCCS) with all their attributes BALOCCS with all their instances BALOCCS All relationship types BALOCCS and linking object types that BALOCCS too with all their roles BALOCCS with all their attributes BALOCCS with all their instances BALOCCS and linking objects that BALOCCS too All multi-instantiation links that BALOCCS ( => possibly is-a and disjoint !)

41. 41 MC semantics - Example Open (green) => / Open (red) => Road1 Open (blue) => Road2 Open (green, red) => Road1 Open (green, blue) => Road2 Open (red, blue) => Road1, Road2 Open (green, red, blue) => Road1, Road2, Correspond

42. 42 Comparison of contextualization approaches "Module": set of knowledge relevant for a given context Contextualization of data =  database / ontology modularization

43. 43 Taxonomy of contextualization approaches One category: modular ontologies/DBModules and ontology/DB are defined at the same time CYC, MADS, Muro Another category: distributed reasoning/Federated DBExisting ontologies/DB are taken as modules and interrelated to enrich them with imported knowledge C-OWL, E-connections, conjunctive queries (Stuckenschmidt-Klein) Another category: modules as materialized viewsModules are "extracted" from the ontology/DB RDF/S views, RDF/S RVL lenses, RDF traversal views, Rector's segmentation, MOVE, Multi-Viewpoints

44. 44 Modular ontologies/DB (1)

45. 45 Modular ontologies/DB (2)

46. 46 Distributed Ontologies (1)

47. 47 Distributed Ontologies (2)

48. 48 Multi-Views

49. 49 Conclusion on MADS Data can be contextualized using context-ids and consistency rules MADS contribution: Fine-grained multilevel contextualization as needed to suit the multilevel organization of data Context-aware services can be implemented to guarantee that transactions working with a given set of contexts can only access data that is relevant for these contexts An algebra for querying MADS multi-context databases has been defined. It supports single-context reducibility as well as navigation between contexts using bridge relationships or multi-context types MADS and its algebra have been implemented on top of DBMS and GIS. They have even been used �

50. 50 Future Work for MADS More reasoning Bridge links between heterogeneous kinds of representations object -- relationship -- attribute continuous view -- discrete view Context definition from other contexts e.g. a context contains another context e.g. a context is defined as the union of other contexts

51. 51 General Conclusion All approaches are worth for corresponding purposes Further research is needed, in particular regarding real context management for applications Is a generic theory of context design and management possible?

52. 52