Task 1 2 Context definition and specification Outline





















- Slides: 21
Task 1. 2 Context: definition and specification
Outline Introduction Work method Context definition Context specification Overview Usage Conclusion Leuven, 14 oktober 2004
Introduction Context = con – text General meaning Comes from literature Facts or circumstances surrounding situation or event In computer science No consensus in literature Case based definition 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 Co. DAMo. S project Specification 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 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 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) 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 Leuven, 14 oktober 2004
Specification Overview Main concepts User uses (to execute a task) Services One or more platforms In an environment uses. Service* user uses. Platform* provides. Service* service Leuven, 14 oktober 2004 has. Environment platform environment
Specification: 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 Leuven, 14 oktober 2004
Specification: User Main concepts User uses (to execute a task) Services One or more platforms In an environment preference profile isa has. Profile activity has. Activity* role profile has. Profile has. Mood has. Role* task user has. Task* uses. IODevice* uses. Service* service Leuven, 14 oktober 2004 mood i/o device
Specification: Platform - Software Run-time environment Operating system (API, libc) Name, edition, version Virtual machine(s) API (J 2 SE 1. 4. 1, . . . ) Name & edition (SUN JRE 1. 4. 1, Jikes. RVM 2. 3. 2) Software Name, version Rendering engine modality 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 Leuven, 14 oktober 2004
Specification: Platform has software and hardware Hardware Resource I/O device supports. Modality* rendering engine operating system virtual machine Software Provides services Requires. . . middleware power resource modality memory resource isa cpu resource isa provides. Service* service software requires. Platform* network resource provides. Software* platform has. Environment Leuven, 14 oktober 2004 storage resource hardware i/o device provides. Hardware* isa input device uses. IODevice* environment user output device
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, … Leuven, 14 oktober 2004
Specification: Services Used for tasks Provided by software Description based on OWL-s task uses. Service* software service has. Service. Profile provides. Service* has. Service. Grounding has. Service. Model service profile Leuven, 14 oktober 2004 service model service grounding
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 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 Leuven, 14 oktober 2004
Specification: Environment Location Environmental conditions Time platform has. Environment environment has. Environmental. Condition* has. Location* temperature pressure has. Time* location is. Relative. To* time isa relative isa Leuven, 14 oktober 2004 address environmental condition isa humidity lighting absolute noise
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 Leuven, 14 oktober 2004
Conclusion Validation Other work packages Scenarios Reiteration After 2 years based on gained experience Work packages Feedback Leuven, 14 oktober 2004