1. Task 1.2 Context: definition and specification

2. Leuven, 14 oktober 2004 Outline Introduction Work method Context definition Context specification  Overview  Usage Conclusion

3. Leuven, 14 oktober 2004 Introduction Context = con – text  Comes from literature General meaning  Facts or circumstances surrounding situation or event In computer science  No consensus in literature  Case based definition

4. Leuven, 14 oktober 2004 Introduction Main properties of information in context (HCI):  Important parts who, where, what [Schilit 1994] physical environment and software [Calvary 2002]  Relevant to interaction [Dey 2001]  About present and past [Coutaz 2002] Other important context properties  Distributed sources  Automated and human input  Ambiguous In work package 1  Working definition within CoDAMoS project  Specification

5. Leuven, 14 oktober 2004 Work methodology Workgroup Understanding of context in literature Decisions about context based on  Literature  Understanding of our own needs  Limited scenario instantiation  Discussion with partners (workshop) Validation  Work packages in first two years  Review after two years

6. Leuven, 14 oktober 2004 Our working definition Context is any information that is relevant for the interaction of a subject (person or service) with the platform and tells something about: The platform The user The environment The services

7. Leuven, 14 oktober 2004 Our working definition The platform  technical specification (CPU, RAM, I/O,...)  runtime environment (OS, VM,...) The user (human)  personal information  preferences The environment  tempo-spatial information  physical characteristics The services  what the platform provides to third parties (users or other services)

8. Leuven, 14 oktober 2004 Specification Ontology  What? Knowledge representation describing concepts with relations Reasoning and inducing new information  Why? Context is highly interrelated Easy sharing of knowledge  Instantiated using Web Ontology Language Semantic Web Standard Practical usage is possible Organized around main concepts from definition

9. Leuven, 14 oktober 2004 Specification Overview user platformenvironmentservice providesService* hasEnvironment usesService* usesPlatform* Main concepts  User uses (to execute a task) Services One or more platforms In an environment

10. Leuven, 14 oktober 2004 Specification: User User  Profile: contains properties of the user Properties can be complex (agenda) or simple (name) Mostly static information  Preferences: Device or service specific  Tasks: what the user wants to do Contains: activities (concrete actions)  Mood or current Role may change preferences

11. Leuven, 14 oktober 2004 Specification: User preference profile user role task activity service hasActivity* hasTask* hasRole* hasProfile usesService* hasProfile mood hasMood hasProfile i/o device usesIODevice* isa Main concepts  User uses (to execute a task) Services One or more platforms In an environment

12. Leuven, 14 oktober 2004 Specification: Platform - Software Run-time environment  Operating system (API, libc) Name, edition, version  Virtual machine(s) API (J2SE 1.4.1,...) Name & edition (SUN JRE 1.4.1, JikesRVM 2.3.2) Software  Name, version  Rendering engine modality

13. Leuven, 14 oktober 2004 Specification: Platform - Hardware CPU  Speed  Cache: sizes & organisation (levels + mapping scheme) I/O  Screen (size, colordepth, touch?,...)  Data-entry (keypad,...)  Network (ethernet, bluetooth, IR,...) Storage  Volatile or persistent  Total size & currently available Power  Total and currently available

14. Leuven, 14 oktober 2004 Specification: Platform user platform softwarehardware operating system virtual machine rendering engine input device output device resource memory resource cpu resource storage resource network resource power resource environment service isa providesSoftware* isa providesService* hasEnvironment middleware i/o device isa usesIODevice* modality requiresPlatform* supportsModality* providesHardware* Platform has software and hardware  Hardware Resource I/O device  Software Provides services Requires...

15. Leuven, 14 oktober 2004 Specification: Services Service description:  Coarse-grained specification High-level information to decide if we are interested in the service Semantic service discovery E.g.: “I need a messaging service.”  Fine-grained specification Provided and required service interfaces Service composition E.g.: APIs, non-functional requirements, …

16. Leuven, 14 oktober 2004 Specification: Services tasksoftware service profile service model service grounding hasServiceGrounding hasServiceProfile hasServiceModel usesService* providesService* Services  Used for tasks  Provided by software  Description based on OWL-s

17. Leuven, 14 oktober 2004 Specification: Services OWL-S ontology comprises three parts:  Service Profile: Properties for automatic discovery Service functionality Inputs / Outputs Preconditions / Effects Cfr.: Yellow page entry  Service Model Control flow and data flow involved in using the service Composition and execution of services  Service Grounding: Mapping to WSDL and SOAP Communication-level protocols Message descriptions

18. Leuven, 14 oktober 2004 Specification: Environment Describing physical characteristics of the environment  Sensed information Accuracy Scale Time stamp  Derived information Transform low-level information to human comprehensible high-level information Combining information

19. Leuven, 14 oktober 2004 Specification: Environment platform environment location environmental condition temperature pressure humidity lighting noise address absoluterelative isa hasEnvironment isRelativeTo* time hasLocation* hasTime* hasEnvironmentalCondition* Environment  Location  Environmental conditions  Time

20. Leuven, 14 oktober 2004 Conclusion Context definition and specification  Four main parts: User Platform Service Environment Advantage of using ontologies Allow existing knowledge reuse Connect ontologies to enlarge knowledge domain Reasoning and inducing new information

21. Leuven, 14 oktober 2004 Conclusion Validation  Other work packages  Scenarios Reiteration  After 2 years based on gained experience Work packages Feedback