CONTEXT BASED ADAPTATION OF
SEMANTIC RULES IN SMART
BUILDINGS
Vikash Kumar (kumar@ftw.at)
Anna Fensel (fensel@ftw.at, anna.fensel@sti2.at)
Peter Fröhlich (froehlich@ftw.at)
iiWAS„13, December 4, 2013, Vienna, Austria
Outline







Introduction: Motivation & Research Question
State of the Art in Rule Exchange
Approach: Towards Semantic Rules Adaptation
Implementation
Evaluations
Conclusion
Introduction: Motivation and
Research Question
Motivation
 Rules find increasing use in semantic applications as well
as traditional IT systems for representing preferences,
privacy constraints, etc.
 Several initiatives aim to transform a Rule from:

 However, there is little or no provision for:

© FTW

-4-
So where is the „Real Problem“??
Research Questions

© FTW

-6-
State of the Art in Rule
Exchange
State of the Art in Rule Exchange (1)
 W3C received several submissions towards
standardization of a Web rule language specification:
- Semantic Web Rule Language (SWRL)
- Web Rule Language (WRL)
- Semantic Web Services Language (SWSL)

 In 2005 W3C launched a Rule Interchange Format (RIF)
working group tasked with standardizing a common rule
interchange format for the web
- Consists of various interconnected dialects representing rule
languages
- Dialects provide a formal description of a rule„s syntax, semantics
& XML serialization
- Existing and upcoming rule languages may be mapped to this
format serving as an interlingua between various languages
© FTW

-8-
State of the Art in Rule Exchange (2)
 Linked Rules: A set of basic principles by which rules can
be represented and shared over the web
- Several methods of rule reuse proposed
- Demonstration on N3 based AIR web rule languages

 Rule Markup Language (RuleML), Reasoning on the Web
with Rules and Semantics (REWERSE)

© FTW

-9-
Approach: Towards Semantic
Rule Adaptation
The Approach
 This thesis focuses on contextual independence rather
than language independence
 The main objective is to achieve adaptation of a Policy
created in a certain rule language into a different context
in the same language
 To achieve this we:
- Identify the context parameter trigger and its inter-dependence
with other context parameters
- Manipulate the dependent parameters based on the triggering
parameters

© FTW

- 11 -
Context Definition

*Dey, A.K., Abowd, G.D., Salber, D.: A conceptual framework and a toolkit for supporting the rapid
prototyping of context-aware applications. Human-Computer Interaction 16 (2-4), 97-166, 2001.
Context Parameters Considered
 All parameters defined wrt Sensors as subject
 Parameters involved:
1.
2.
3.
4.
5.
6.

Location – physical location of the sensor
Time – of reading the sensor value
Identity – Unique id of the sensor
Type – Sensor type (heat, light, motion, etc.)
State – ON/OFF, Temp reading, luminosity, etc.
People – Individuals or groups, co-located or distributed
Example

rdf:type
gr:computingTablet

rdf:type gr:Location
rdf:type gr:DateTime

Send me all offers for Samsung Galaxy tab
from 4020, Linz on Weekdays after 11 AM
© FTW

- 14 -
Preserving the Semantic Idea
 Explore how change in one context (location, time, etc.)
affects other contexts
 The context interdependence is described keeping in mind
our use cases
 Which other context parameters might need to be adapted
in an ON/OFF or Alert Policy when a particular context
changes
 Other contexts may either Definitely get affected,
Possibly get affected or Not get affected
Context Interdependence

*Identity is NOT the same as Type
# Parameters in Gray represent the contexts that May get affected while those in
Black represent contexts that Will get affected
Adaptation Rules
 The priority order is decided on the basis of three rules:
1.

The parameter that definitely affects the most number of
parameters has highest priority

2.

The parameter that potentially affects other parameters comes
next

3.

Only the parameters affected by initial parameter change gets
affected (i.e. there are no cycles)
The Adaptation Protocol
Implementation
Types of Rules Considered
 ON/OFF Policies
- Policies the upon satisfaction of conditions in its antecedent, can
change device states from ON <-> OFF

 ALERT sending policies
- Policies that upon satisfaction of conditions in its antecedent,
produce/send an alarm to designated services
Triggering
Context

The Architecture

Contextually
Adapted Rule

Rule Parser
Output

Language Specific
Parsing
User
Interaction

Target
Rule
Implementation Details
 Extend the Ontology with concept-context relationship
 Parametrized SPARQL rules (CONSTRUCT queries)
 Adapted using ARQ (QuerySolutionMap)
- ARQ is a query engine for Jena
- A map of variable names to RDFNode objects
- Used for dynamic binding of variables to values

 Interaction with user asking values for affected
variables/parameters
- Present the user with justified ontology* showing explanation of
the context

 Instantiating the Rule with new values for variables
*A justification for an entailment in an ontology, is a minimal subset of the ontology that is
sufficient for the entailment to hold
Two Real Smart Building Setups
 School in Austria

 Factory floor in Russia
Smart Building Installation @ School
 Several Smart Meters
 Sensors (e.g. light, temperature,
humidity)
 Smart plugs, for individual
sockets
 Rule based shutdown services
for PCs
 Rule based alarms/alerts
 User interfaces and apps: Web,
tablet, smartphone (Android)
The Alert Monitoring app
Power Management Service - Tablet
Power Management Service - Smartphone
Evaluations
Evaluation Criterion
 Policy adaptation
- correctness,
- automation,
- acceptance, etc.

 Tools evaluated
- Alert Monitoring App
- Power Management Services
Alert Monitoring Policies - Evaluation
 App installed in 2 Android based tablets
 Data collected over ~6 months used to come up with alert
thresholds
 Underlying system policies were adapted according to
these threshold values
 Pupils of a class were allowed to share the tablets and
use them for monitoring alerts and set filters themselves
 Trials were carried out for 1 week
Alert Monitoring Policies - Evaluation
Power Management Service - Evaluation
 Android based smartphones and tablets were distributed
among pupils and teachers
 App was used to monitor and control the power
management service installed in 3 of the computer rooms
of the school
 The app would also allow a user to change the state of the
computers in computer rooms from IDLE to AWAKE or
OFF.
 Tests performed with pupils from two classes for 1 week
each (= total 2 weeks) with the tablets and 1 week with the
smart phones
 Policies were adapted after every week (Phase) of the trial
Power Management Service –
Evaluation: Week 1 vs Week 2
Power Management Service –
Evaluation: Week 2 vs Week 3
Conclusion
Conclusions
1. How dependent are semantic policies on the contextual
conditions for which they have been developed?


Various degrees of dependence of policies on various
parameters shown

2. Which context parameters are included in a typical
policy?


A list of five context parameters identified and studied in details.
“People” as context deliberately excluded from this list
Conclusions
3. How dependent are the context parameters on each
other?
 The inter-dependencies of the listed parameters studied and
explained in details

4. Can a policy be adapted from one contextual setting to
another using this knowledge and still solve the purpose
for which the policy was originally created?
 A technique for context based adaptation of semantic policies was
proposed and evaluated for the use case of smart buildings on
real users
Thank You for Attention

Reference:
Kumar, V., Fensel, A., Fröhlich, P. “Context Based Adaptation of Semantic
Rules in Smart Buildings”. In Proceedings of the 15th ACM International
Conference on Information Integration and Web-based Applications &
Services (iiWAS2013), ACM, 2-4 December 2013, Vienna, Austria.

Context Based Adaptation of Semantic Rules in Smart Buildings

  • 1.
    CONTEXT BASED ADAPTATIONOF SEMANTIC RULES IN SMART BUILDINGS Vikash Kumar (kumar@ftw.at) Anna Fensel (fensel@ftw.at, anna.fensel@sti2.at) Peter Fröhlich (froehlich@ftw.at) iiWAS„13, December 4, 2013, Vienna, Austria
  • 2.
    Outline       Introduction: Motivation &Research Question State of the Art in Rule Exchange Approach: Towards Semantic Rules Adaptation Implementation Evaluations Conclusion
  • 3.
  • 4.
    Motivation  Rules findincreasing use in semantic applications as well as traditional IT systems for representing preferences, privacy constraints, etc.  Several initiatives aim to transform a Rule from:  However, there is little or no provision for: © FTW -4-
  • 5.
    So where isthe „Real Problem“??
  • 6.
  • 7.
    State of theArt in Rule Exchange
  • 8.
    State of theArt in Rule Exchange (1)  W3C received several submissions towards standardization of a Web rule language specification: - Semantic Web Rule Language (SWRL) - Web Rule Language (WRL) - Semantic Web Services Language (SWSL)  In 2005 W3C launched a Rule Interchange Format (RIF) working group tasked with standardizing a common rule interchange format for the web - Consists of various interconnected dialects representing rule languages - Dialects provide a formal description of a rule„s syntax, semantics & XML serialization - Existing and upcoming rule languages may be mapped to this format serving as an interlingua between various languages © FTW -8-
  • 9.
    State of theArt in Rule Exchange (2)  Linked Rules: A set of basic principles by which rules can be represented and shared over the web - Several methods of rule reuse proposed - Demonstration on N3 based AIR web rule languages  Rule Markup Language (RuleML), Reasoning on the Web with Rules and Semantics (REWERSE) © FTW -9-
  • 10.
  • 11.
    The Approach  Thisthesis focuses on contextual independence rather than language independence  The main objective is to achieve adaptation of a Policy created in a certain rule language into a different context in the same language  To achieve this we: - Identify the context parameter trigger and its inter-dependence with other context parameters - Manipulate the dependent parameters based on the triggering parameters © FTW - 11 -
  • 12.
    Context Definition *Dey, A.K.,Abowd, G.D., Salber, D.: A conceptual framework and a toolkit for supporting the rapid prototyping of context-aware applications. Human-Computer Interaction 16 (2-4), 97-166, 2001.
  • 13.
    Context Parameters Considered All parameters defined wrt Sensors as subject  Parameters involved: 1. 2. 3. 4. 5. 6. Location – physical location of the sensor Time – of reading the sensor value Identity – Unique id of the sensor Type – Sensor type (heat, light, motion, etc.) State – ON/OFF, Temp reading, luminosity, etc. People – Individuals or groups, co-located or distributed
  • 14.
    Example rdf:type gr:computingTablet rdf:type gr:Location rdf:type gr:DateTime Sendme all offers for Samsung Galaxy tab from 4020, Linz on Weekdays after 11 AM © FTW - 14 -
  • 15.
    Preserving the SemanticIdea  Explore how change in one context (location, time, etc.) affects other contexts  The context interdependence is described keeping in mind our use cases  Which other context parameters might need to be adapted in an ON/OFF or Alert Policy when a particular context changes  Other contexts may either Definitely get affected, Possibly get affected or Not get affected
  • 16.
    Context Interdependence *Identity isNOT the same as Type # Parameters in Gray represent the contexts that May get affected while those in Black represent contexts that Will get affected
  • 17.
    Adaptation Rules  Thepriority order is decided on the basis of three rules: 1. The parameter that definitely affects the most number of parameters has highest priority 2. The parameter that potentially affects other parameters comes next 3. Only the parameters affected by initial parameter change gets affected (i.e. there are no cycles)
  • 18.
  • 19.
  • 20.
    Types of RulesConsidered  ON/OFF Policies - Policies the upon satisfaction of conditions in its antecedent, can change device states from ON <-> OFF  ALERT sending policies - Policies that upon satisfaction of conditions in its antecedent, produce/send an alarm to designated services
  • 21.
    Triggering Context The Architecture Contextually Adapted Rule RuleParser Output Language Specific Parsing User Interaction Target Rule
  • 22.
    Implementation Details  Extendthe Ontology with concept-context relationship  Parametrized SPARQL rules (CONSTRUCT queries)  Adapted using ARQ (QuerySolutionMap) - ARQ is a query engine for Jena - A map of variable names to RDFNode objects - Used for dynamic binding of variables to values  Interaction with user asking values for affected variables/parameters - Present the user with justified ontology* showing explanation of the context  Instantiating the Rule with new values for variables *A justification for an entailment in an ontology, is a minimal subset of the ontology that is sufficient for the entailment to hold
  • 23.
    Two Real SmartBuilding Setups  School in Austria  Factory floor in Russia
  • 24.
    Smart Building Installation@ School  Several Smart Meters  Sensors (e.g. light, temperature, humidity)  Smart plugs, for individual sockets  Rule based shutdown services for PCs  Rule based alarms/alerts  User interfaces and apps: Web, tablet, smartphone (Android)
  • 25.
  • 26.
  • 27.
  • 28.
  • 29.
    Evaluation Criterion  Policyadaptation - correctness, - automation, - acceptance, etc.  Tools evaluated - Alert Monitoring App - Power Management Services
  • 30.
    Alert Monitoring Policies- Evaluation  App installed in 2 Android based tablets  Data collected over ~6 months used to come up with alert thresholds  Underlying system policies were adapted according to these threshold values  Pupils of a class were allowed to share the tablets and use them for monitoring alerts and set filters themselves  Trials were carried out for 1 week
  • 31.
  • 32.
    Power Management Service- Evaluation  Android based smartphones and tablets were distributed among pupils and teachers  App was used to monitor and control the power management service installed in 3 of the computer rooms of the school  The app would also allow a user to change the state of the computers in computer rooms from IDLE to AWAKE or OFF.  Tests performed with pupils from two classes for 1 week each (= total 2 weeks) with the tablets and 1 week with the smart phones  Policies were adapted after every week (Phase) of the trial
  • 33.
    Power Management Service– Evaluation: Week 1 vs Week 2
  • 34.
    Power Management Service– Evaluation: Week 2 vs Week 3
  • 35.
  • 36.
    Conclusions 1. How dependentare semantic policies on the contextual conditions for which they have been developed?  Various degrees of dependence of policies on various parameters shown 2. Which context parameters are included in a typical policy?  A list of five context parameters identified and studied in details. “People” as context deliberately excluded from this list
  • 37.
    Conclusions 3. How dependentare the context parameters on each other?  The inter-dependencies of the listed parameters studied and explained in details 4. Can a policy be adapted from one contextual setting to another using this knowledge and still solve the purpose for which the policy was originally created?  A technique for context based adaptation of semantic policies was proposed and evaluated for the use case of smart buildings on real users
  • 38.
    Thank You forAttention Reference: Kumar, V., Fensel, A., Fröhlich, P. “Context Based Adaptation of Semantic Rules in Smart Buildings”. In Proceedings of the 15th ACM International Conference on Information Integration and Web-based Applications & Services (iiWAS2013), ACM, 2-4 December 2013, Vienna, Austria.

Editor's Notes

  • #10 Linked Rule Principles:1. Individual rules and rule-bases should be named using URIs.2. These URIs should be able to be \dereferenced&quot; to obtain a description in the RIF format.3. Rules should operate over data expressed in RDF.4. Rules must be linked.
  • #14 We ignored the parameter ‘People’ here to start with as this would make the use case more complex.