context from conceptual modeling through acquisition to data tailoring
Download
Skip this Video
Download Presentation
Context: from conceptual modeling , through acquisition , to data tailoring

Loading in 2 Seconds...

play fullscreen
1 / 28

Context: from conceptual modeling , through acquisition , to data tailoring - PowerPoint PPT Presentation


  • 84 Views
  • Uploaded on

Context: from conceptual modeling , through acquisition , to data tailoring. Letizia Tanca, Fabio A. Schreiber. Context. derived from the Latin cum (with or together) and texere (to weave)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Context: from conceptual modeling , through acquisition , to data tailoring' - madeline-kosta


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
context from conceptual modeling through acquisition to data tailoring
Context:from conceptual modeling, through acquisition, to data tailoring

Letizia Tanca, Fabio A. Schreiber

context
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.
context management elements
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
design time
Design time

CONTEXT MODEL (CDT)

run time
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

context dimension tree
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)
software and service hooking
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
relevant areas or projections
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,..)
data tailoring the view specification problem
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)

collecting context data
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.
context aware sensor query
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

more context aware examples

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

perla key features
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, …)
perla and context management
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

perla and context management1
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

managing context quick look
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
introducing context in perla
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>

introducing context in perla1
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>

introducing context in perla2
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>

example putting all together
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

example putting all together1
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

example putting all together2
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

more on context sensing

Di

DIAGNOSE

RULES

D

SITUATION

DEFINITIONS

S i

DISEASE

DIAGNOSE

SITUATION

SUBSPACE

Rji

STATE VARIABLES

VALUES

SENSORS

More on context sensing
the feedback problem

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
conclusions and future work
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
ad