Checkable Domain Management with Ontology and Rules

1
Checkable Domain Management with Ontology and
Rules
AutoHAN Systems Research Group Computer Laboratory
University of Cambridge

• Atif Alvi and David J. Greaves
• Computer Laboratory
• University of Cambridge, UK
• firstname.lastname_at_cl.cam.ac.uk

2
Introduction

• The vision of Pervasive Computing multitude of
  concurrent applications serving user needs
  imperceptibly
• Requirement complete harmony
• Current technologies (UPnP, OSGi, WSDL etc) do
  not reflect code behaviour

3
Introduction

• Consider a home scenario, or other closed domain
  (train, plane, factory, space station)
• Domain of Participation (DoP)
• Two applications requesting two different
  channels on the same display
• feature interaction
• AutoHAN

4
Device Component Model
5
Our Approach

• Pebbles (passive) and bundles of rules (active,
  checkable)
• Code reflection through Pushlogic or .net CIL
  bytecode (not part of this presentation)
• Rehydration automatic binding, running and
  reaping of bundles
• Bundles checked before admission to domain for
  compatibility, hence harmony!

6
Example Implementations
7
DoP Structure
Physical device logical collection of Pebbles
Bundles
8
Our Approach

• Ontology is a quadruple C,I,P,R
• In description logic (OWL DL) in Protege-OWL
  ontology server
• Enables semantic interoperability
• Holds SWRL rules for rehydration and reaping
  bundles
• (Ontology in addition to tuplecore data plane)
• Updated dynamically as components enter and leave
  the DoP

9
Classical Logical Inference

• Concerning humans in the domain
• hasWife(?man, ?woman)
• hasSpouse(?man, ?woman)
• hasSpouse(?woman, ?man)
• All married persons' hasSpouse property updated
  with the inferred names of their spouses
• Hence, rules can be made conditional on domain
  membership by representing the domain name as a
  concept and having the rules check whether things
  are related to that domain under the domain
  membership role relation

10
Ontology Novelty

• Previous uses of ontologies focused on
  context-awareness, reasoning, sharing knowledge,
  and control.
• Our system further uses ontology to provide
  lifetime management of all components, especially
  running bundles
• Plus usual advantages classification, reasoning.

11
Ontology with Rules

• SWRL is rule language for the Semantic Web
• Superset of OWL DL
• Stored as part of ontology
• Horn-like rules in terms of OWL concepts
• antecedent consequent
• Parent(?x, ?y) Brother(?y, ?z)
• Uncle(?x, ?z)
• Declarative approach adapted for dynamic system
• Jess reasoner (Rete algorithm) automatically
  updates all results after any changes

12
Manual BindingLong Lifetime Statics

• domainName Buckingham Palace
• ownerName Elizabeth
• frontDoorBell tup//192.168.33.2
• livingRoom Room 07
• kitchen Room 04
• hallSmokeSensor tup//192.168.32.5

13
Automatically Recomputed Property

• Example rule forming part of fire alarm service
• Any domain with a smoke sensor and klaxon means
  it is protected against fire
• hasSmokeSensor(?room, ?smokesensor)
• hasKlaxon(?room, ?klaxon)
• isProtected (?room, true)
• All rooms in Home domain having fire alarm and
  klaxon(s) have their isProtected property set to
  true
• All of the properties (roles) hasSmokeSensor,
  hasKlaxon and isProtected are defined with a
  domain and a range
• The domain is a class (concept) in the ontology
  while the range can be a class or a data type
• The first and second arguments of the properties
  represent any instances in that domain and range
  respectively.

14
Bundle Rehydration

• hasSmokeSensor(?room, ?sensor)
• hasKlaxon(?room, ?klaxon)
• isRunningRehydratedBundle(RoomAlarmService,
  ?room, ?klaxon)
• Is connected via the Protégé jslot Java
  interface causes room alarm service to be run on
  an available platform
• In practice, multiple sensors and klaxons across
  the domain
• Need universal quantification

15
Universal Quantification

• i) (forAll)Klaxons expands to actuals
• Klaxon1,Klaxon2,...,KlaxonN
• Only one rehydration but bundle size increases
  due to replication
• ii) Main bundle rehydrated once, but a
  mini-bundle replicated for each instance of a
  quantified binding.
• Bundle size is constant
• iii) Bundle does input/output through domain
  shared variables, e.g., HomeKlaxonSounding
• Fan-out by variable sharing
• Cannot handle per-instance state variables in
  bundle

16
Standing Rules

• Standing rules help provide domain harmony
• example
• SystemMute(true) isKlaxon(?klaxon)
• isSounding(?klaxon, false)
• Owing to this rule, the system will not accept
  klaxon pebbles unless there is at least one
  bundle that implements this behaviour, or
• Any klaxon pebble must default to notSounding to
  be fully registered.

17
Universal Rehydration Rule

• Actually, dont need detailed rules a global
  rule is quantified and used where needed by
  ontology inference.
• isPresentInDomain(?entity, ?somedomain)
• hasCannedBundle(?entity, ?canned)
• canRehydrate(?canned , ?rehydrated)
• isActiveInDomain(?entity, ?somedomain)
• isRunningRehydratedBundle(?entity,
  ?rehydrated)
• Rule commands that any entity present in a home
  domain that is a rehydratable, canned rule bundle
  will become active in the domain, running the
  rehydrated form of the bundle.

18
SWRL Assertion versus Bundle Execution

• Where to draw the boundary between assertion and
  execution in SWRL rules?
• hasSmokeSensor(?room, ?sensor)
• hasKlaxon(?room, ?klaxon)
• isRunningRehydratedBundle(RoomAlarmService,
  ?room, ?klaxon)
• Room Alarm Service is very simple. Therefore,
  dont use a bundle but implement directly in
  SWRL...

19
Assertion versus Bundle Execution 2

• This can be implemented without bundle using a
  bi-implication consequent
• hasSmokeSensor(?room, ?sensor)
• hasKlaxon(?room, ?klaxon)
• isSounding(?klaxon) isDetecting(?sensor)
• Macro-expand the bi-implication to a pair of
  antagonistic rules.
• We cant negate SWRL terms but we can flip
  complementary property values (true/false, off/on
  etc..)

20
Conclusion

• Prototype system for application launching,
  termination, resource description and binding
• Generic pervasive computing environment using
  part of a global ontology for domain
  specification and data about domain status
• Rehydration is a distinguishing feature
• The system is deployable as a secure,
  remotely-controllable system

21
Deploying a Canned Ontology in a Domain

• Can reuse a generic ontology in XML format
  (RDF/OWL) by rehydrating it for a particular
  domain
• Specialisation/rehydration of actuals needed. Can
  be performed by service companies
• Regional variations necessitate some translation
  despite a universal format (XML)
• XML tags and content can be substituted with
  domain-specific ones using library functions e.g.
  ltcatgt to ltchatgt
• Can be useful as intermediate step in ontology
  mapping procedures

22
Remote Control

• HCI important part of Pervasive Computing
• Previously in AutoHAN tangible interfaces,
  end-user programming
• Protege-OWL editor provides user-friendly access
• Centralised ontology and rule base with remote
  control facility
• Multiple clients with client/server can modify
  ontology

23
Security

• Each Protege ontology project has security
  settings in the form of Unix-like permissions
• In addition to any other security, like firewall
  etc
• Security settings (permissions) also present as a
  separate ontology
• Maybe suitable where users not first-class
  entities within the ontology, e.g., a Pizza
  ontology

24
Security

• Not suitable where users are part of the
  ontology, e.g., Spaceship Control, where
  Astronauts are users and also part of ontology
• Should they be represented twice?
• What type of users need to modify ontology?
• Maybe in time every user will be expert-enough