Checkable Domain Management with Ontology and Rules

Atif Alvi and David J. GreavesComputer LaboratoryUniversity of Cambridge, UK{firstname.lastname}@cl.cam.ac.uk

AutoHAN

Systems Research Group

Computer Laboratory

University of Cambridge

ICIW 2008-Athens 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…

ICIW 2008-Athens 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

ICIW 2008-Athens 4

Device Component Model

ICIW 2008-Athens 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!

ICIW 2008-Athens 6

Example Implementations

ICIW 2008-Athens 7

DoP Structure

Physical device = logical collection of Pebbles & Bundles

ICIW 2008-Athens 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

ICIW 2008-Athens 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

ICIW 2008-Athens 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.

ICIW 2008-Athens 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 conceptsantecedent 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

ICIW 2008-Athens 12

Manual Binding—Long 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

ICIW 2008-Athens 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.

ICIW 2008-Athens 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

ICIW 2008-Athens 15

Universal Quantificationi) (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., Home#Klaxon#Sounding

Fan-out by variable sharingCannot handle per-instance state variables in bundle

ICIW 2008-Athens 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.

ICIW 2008-Athens 17

Universal Rehydration Rule

Actually, don’t 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.

ICIW 2008-Athens 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, don’t use a bundle but implement directly in SWRL...

ICIW 2008-Athens 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 can’t negate SWRL terms but we can flip

complementary property values (true/false, off/on etc..)

ICIW 2008-Athens 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

ICIW 2008-Athens 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. <cat> to <chat>

Can be useful as intermediate step in ontology mapping procedures

ICIW 2008-Athens 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

ICIW 2008-Athens 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

ICIW 2008-Athens 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