Context: from conceptual modeling , through acquisition , to data tailoring

1. Context:from conceptual modeling, through acquisition, to data tailoring Letizia Tanca, Fabio A. Schreiber

2. Context • derived from the Latin cum (with or together) and texere (to weave) • a context is not just a profile, but an active process dealing with the way humans weave their experience within their whole environment, to give it meaning • any information that can be used to characterize the situation of an entity [Dey], where an entity is a person, a place, or an object that is considered as relevant for the interaction between a user and an application.

3. Context management elements • Design time: • Context modeling • Application domain modeling (data, functions) • Design of the relationship between the context model and the application domain • Run time: • Context sensing (numeric observables) • Context recognition (symbolic observables) • Context feeding (binding) • Context aware behavior

4. Design time CONTEXT MODEL (CDT)

5. Run-time Context-awarebehavior Context feeding (through the association between contexts and “relevant application parts”) Other sources of context elements Symbolic variables (context dimension values) Observable, numerical variables gathered from sensors

6. Context Dimension Tree context Context-Dimension Tree: • representation independent • extensible • context-validity constraints support • induces a partial order on contexts (more or less abstract contexts)

7. Software and service “hooking” Possible associations: • Context  (associated to) set of ECA rules • Rules activate and deactivate behaviors • Context  (associated to) set of pairs <class, role> • Each object takes a context-aware role • Context  (associated to) set of program “variations” • An agent triggers context-aware variations which change process behavior • Context  (associated to) a set of model elements (??) • a (contextual) label is assigned to each model element

8. Context-aware database design

9. Relevant areas, or projections Projection: • is the set of relevant data for a given user in a given context • projected over the data sources • is context-aware • possible for any kind of data source (RFIDs, sensors,..)

10. Context Dimension Tree: the Real Estate Case Study

11. Data Tailoring: the View Specification Problem For each possible context instance we specify the relevant data as views Context-aware database design based on the viewpoint abstraction (Motschnig-Pitrik, Mylopoulos)

12. On-the-fly data integration

13. Collecting context data • Sensor data are used to collect “object” information • They can also be used also to gather the current context • Typical sensor-derived context data: time and location • More examples: • light, latitude and time-of-the-day used to • derive the season, • wind speed and orientation • to derive vineyard situation, etc.

14. Context-aware sensor query Suppose we want to monitor the temperature of some containers inside a container ship BUT We are only interested in those containers exposed at direct sunlight Every container has a light sensor on the outside, and a temperature sensor in the inside, not directly connected to each other. Photo by Patrick Boury (CC) Light sensor We only have to query those sensors which are in the light, and we are not interested in those sensors which are in the shade  context-aware reduction of the query space Temperature sensor

15. More context-aware examples Monitor the tampering sensor of the accessible containers when the ship is docked (GPS information): if tampering is detected monitor nearby containers at a higher frequency Photo by Patrick Boury (CC) Tampering sensor

16. PerLa: KEY FEATURES High level interface: the language Low level interface: the hardware abstraction layer • SQL-like syntax • Three levels of queries • High level query (HLQ) • Equivalent to SQL for streaming DB • Actuation query (AQ) • Executes commands, set parameters on devices • Low level query (LLQ) • Defines the behaviour of a single or of a group of devices • Devices as a Functionality Proxy Component (FPC) • An FPC provides: • Attribute reading (id, temperature, pressure, power level, last sensed RFID reader, …) • Event notification (last sensed RFID reader changed, …) • Meta-description (name, data type, …)

17. PerLa and Context management PerLa defines a language to manage, configure and maintain a pervasive system. In its original conception, PerLa does not provide context definition statements

18. PerLa and Context management • PerLa defines a language to manage, configure and maintain a pervasive system. In its original conception, PerLa does not provide context definition statements • Up to now, we are working towards providing PerLa with context definition statements Key Idea: extend the language to manage context

19. Managing Context: quick look • During the analysis of the application domain, the designer identifies the “realistic set” of contexts • The designer must provide • A context validity condition (a condition on numerical observable variables) • A set of actions to be performed when the validity condition becomes true • (possibly) a set of actions to be performed when the validity condition become false • The evaluation frequency of the validity condition

20. Introducing Context in PerLa A first attempt: CREATE CONTEXT <context_name> VALID WHEN <validity_expr> ON ENABLE [<query_stm>]+ ON DISABLE [<query_stm>]+ REFRESH EVERY <period>

21. Introducing Context in PerLa SELECT FIELD1,…,FIELDN WHERE <SQL_BOOLEAN_EXPRESSION> CREATE CONTEXT <context_name> VALID WHEN <validity_expr> ON ENABLE [<query_stm>]+ ON DISABLE [<query_stm>]+ REFRESH EVERY <period>

22. Introducing Context in PerLa PerLa High Level, Low Level and Actuation queries CREATE CONTEXT <context_name> VALID WHEN <validity_expr> ON ENABLE [<query_stm>]+ ON DISABLE [<query_stm>]+ REFRESH EVERY <period>

23. Example: putting all together CREATE STREAM RawDataFromWineyard (SensorID ID, temperature FLOAT, humidity FLOAT) AS LOW: EVERY 10 m SELECT humidity, temperature SAMPLING EVERY 60 s ON DISABLE DROP RawDataFromWineyard REFRESH EVERY 10 m CREATE CONTEXT “grapes_harvest” VALID WHEN SELECT GPS_VALUE, TIMESTAMP, ID_NODE WHERE GPS_VALUE = ($LAT_X, $LONG_Y) AND TIMESTAMP > “15 Sept 2009” AND TIMESTAMP < “16 Oct 2009” AND (ID_NODE = $AN_ID OR ID_NODE = $ANOTHER_ID…) ON ENABLE CREATE OUTPUT STREAM DataFromWineyard (SensorID ID, avgTemp FLOAT, avgHum FLOAT, varTemp FLOAT, varHum FLOAT) AS HIGH: EVERY 1 h SELECT AVG (temperature, 10 m), AVG (humidity, 10 m), VARIANCE (temperature, 10 m), VARIANCE (temperature, 10 m) FROM RawDataFromWineyard GROUP BY SensorID

24. Example: putting all together Validity expr. CREATE STREAM RawDataFromWineyard (SensorID ID, temperature FLOAT, humidity FLOAT) AS LOW: EVERY 10 m SELECT humidity, temperature SAMPLING EVERY 60 s ON DISABLE DROP RawDataFromWineyard REFRESH EVERY 10 m CREATE CONTEXT “grape_harvest” VALID WHEN SELECT GPS_VALUE, TIMESTAMP, ID_NODE WHERE GPS_VALUE = (LAT_X, LONG_Y) AND TIMESTAMP > “15 Sept 2009” AND TIMESTAMP < “16 Oct 2009” AND (ID_NODE = AN_ID OR ID_NODE = ANOTHER_ID) ON ENABLE CREATE OUTPUT STREAM DataFromWineyard(SensorID ID, avgTemp FLOAT, avgHum FLOAT, varTemp FLOAT, varHum FLOAT) AS HIGH: EVERY 1 h SELECT AVG(temperature, 10 m), AVG(humidity, 10 m), VARIANCE(temperature, 10 m), VARIANCE(temperature, 10 m) FROM RawDataFromWineyard GROUP BY SensorID

25. Example: putting all together PerLa HLQ PerLa LLQ CREATE STREAM RawDataFromWineyard (SensorID ID, temperature FLOAT, humidity FLOAT) AS LOW: EVERY 10 m SELECT humidity, temperature SAMPLING EVERY 60 s ON DISABLE void REFRESH EVERY 10 m CREATE CONTEXT “grape_harvest” VALID WHEN SELECT GPS_VALUE, TIMESTAMP, ID_NODE WHERE GPS_VALUE = (LAT_X, LONG_Y) AND TIMESTAMP > “15 Sept 2009” AND TIMESTAMP < “16 Oct 2009” AND (ID_NODE = AN_ID OR ID_NODE = ANOTHER_ID) ON ENABLE CREATE OUTPUT STREAM DataFromWineyard(SensorID ID, avgTemp FLOAT, avgHum FLOAT, varTemp FLOAT, varHum FLOAT) AS HIGH: EVERY 1 h SELECT AVG(temperature, 10 m), AVG(humidity, 10 m), VARIANCE(temperature, 10 m), VARIANCE(temperature, 10 m) FROM RawDataFromWineyard GROUP BY SensorID

26. Di DIAGNOSE RULES D SITUATION DEFINITIONS S i DISEASE DIAGNOSE SITUATION SUBSPACE Rji STATE VARIABLES VALUES SENSORS More on context sensing

27. QUERY/RESULT PATH CONTEXT MANAGEMENT SYSTEM CONTEXT MODEL (CDT) APPLICATION VALUED DIMENSIONS ENVIRONMENT VALUED DIMENSIONS QUERY MODEL (XML) DATA MODEL (E-R/RELATIONAL) DB QUERY STEREOTYPE QUERY TAILORING DATA TAILORING DATA CLEANING, NOISE FILTERING, DAMPING CA-DB OPERATIONAL SYSTEM CONTINUOUS QUERIES DBMS SENSORS VALUE PRESET PATH APPLICATION ENVIRONMENT VALUES FEEDBACK PATH The feedback problem

28. Conclusions and future work • Design time: • Context modeling • Modeling dynamics yet to be solved • Design of the context model / application domain hooks • Resource-dependent • Run time: • Context sensing (numeric observables)  PerLa ? • Context recognition (symbolic observables) • Depends on the specific hooks • Context feeding and context aware behavior • Resource-dependent • Dynamic context generation and recognition