1. Checkable Domain Management with Ontology and Rules Atif Alvi and David J. Greaves Computer Laboratory University of Cambridge, UK {firstname.lastname}@cl.cam.ac.uk AutoHAN Systems Research Group Computer Laboratory University of Cambridge

2. 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…

3. 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

4. ICIW 2008-Athens 4 Device Component Model

5. 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!

6. ICIW 2008-Athens 6 Example Implementations

7. ICIW 2008-Athens 7 DoP Structure Physical device = logical collection of Pebbles & Bundles

8. 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

9. 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

10. 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.

11. 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 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. 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

13. 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.

14. 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

15. ICIW 2008-Athens 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., Home#Klaxon#Sounding  Fan-out by variable sharing  Cannot handle per-instance state variables in bundle

16. 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.

17. 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.

18. 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...

19. 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..)

20. 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

21. 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. to Can be useful as intermediate step in ontology mapping procedures

22. 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

23. 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

24. 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