Context System

• Executive Summary
• Services Provided
• Services Needed
• Open Questions and Doubts
• Shared Data Structures
• Component-specific Errors
• Limitations

Executive Summary

The FastFix Context System includes functionality for context elicitation and context processing. The Context System observes application execution events and user interactions using sensors and stores the observed context information as a sequence of events in the Client Data Store.

Services Provided

• Provides means to register for specific events
• Provides a service that pushes information about occurring events (requirement: previous registration)
• Provides context processing capabilities, in particular to
  • aggregate events
  • infer semantical knowledge from events
  • detect event patterns (in a limited way as opposed to the event correlation component)

Services Needed

• From Client Data Store:
  • Needs to access ontologies in Client Data Store (to store events as semantic entities and query for existing events using semantic queries)
  • Needs to store observed events in Client Data Store
    From Application Bridge:
  • Needs to get sensed informations from sensors in Application Bridge/ Target Application
  • Needs to tune (e.g. turn off or increase sensing level) a specific deployed sensor in the Application Bridge/ Target Application

Open Questions and Doubts

• What is the difference/ relation to Application Bridge? Does the application bridge contain specific context system parts? Is the application bridge part of the context system?
• What parts of the Context System/ Application Bridge are independent from the target application and which are dependent (and have to be reimplemented for every target application)?
• Why is Context System and Client Data Store separated? Is that reasonable or should we merge both?
• What is the relation of Context System and instrumentation of WP5 and WP6? Are those instrumentations fully or partly part of the Context System? Which types of events are published over the Context Bus and which are not (e.g. due to performance considerations)?
• Are Context and Event Correlation Systems going to share a common Event Data Ontology? Both need to know (share) the data model of each type of event (e.g. What are the attributes of a TextInput of a concrete user? (text, timestamp, associated field, user id ...)
• How are the context events (or stream of context events) going to be encapsulated in the messages to be sent through the Communication System?

Shared Data Structures

• Sensor, SensingStrategy (with Application Bridge)
• ContextEvent (with most other components)

Component-specific Errors

see [Component Specific Error Types]

Limitations

see [Component Limitations]