Task 1.2 Context: definition and specification

1. Task 1.2 Context:definition and specification

2. Outline Introduction Work method Context definition Context specification Overview Usage Conclusion

3. 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. 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. 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. 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. 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. 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. Specification Overview Main concepts User uses (to execute a task) Services One or more platforms In an environment user usesService* usesPlatform* providesService* hasEnvironment service platform environment

10. 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. Specification: User • Main concepts • User uses (to execute a task) • Services • One or more platforms • In an environment preference profile isa hasProfile hasProfile activity role profile mood hasProfile hasMood hasActivity* hasRole* task user hasTask* usesIODevice* usesService* service i/o device

12. 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. 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. Specification: Platform • Platform has software and hardware • Hardware • Resource • I/O device • Software • Provides services • Requires ... operating system virtual machine middleware rendering engine power resource supportsModality* modality memory resource resource isa cpu resource isa isa providesService* service software hardware storage resource network resource requiresPlatform* providesSoftware* isa platform i/o device input device providesHardware* hasEnvironment usesIODevice* output device environment user

15. 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. Specification: Services • Services • Used for tasks • Provided by software • Description based on OWL-s task software usesService* service providesService* hasServiceProfile hasServiceGrounding hasServiceModel service profile service model service grounding

17. 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. 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. Specification: Environment • Environment • Location • Environmental conditions • Time platform hasEnvironment environment temperature hasEnvironmentalCondition* hasLocation* pressure hasTime* location time environmental condition isa humidity isa lighting isRelativeTo* relative absolute noise isa address

20. 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. Conclusion • Validation • Other work packages • Scenarios • Reiteration • After 2 years based on gained experience • Work packages • Feedback