SOFIA - Integration of an Answer Set Engine to Smart m3. NOKIA

Integration of an answer set engine to Smart-M3 1 1 Vesa Luukkala and Jukka Honkola Nokia Research Center, Itämerenkatu 11, Helsinki, Finland vesa.luukkala@nokia.com, jukka.honkola@nokia.com Abstract. We present our work in integrating an answer-set engine smodels to Smart-M3 interoperability platform. This gives user a possiblity of programming and trialing logic program reasoning in Smart-M3 environment. The smodels programming model guarantees that evalu- ation of rules is terminating. We add reactive features on top of the answer-set programming model and discuss its implications.1 IntroductionNowadays, a lot of devices with considerable computing power and connectivitymechanisms are present in the everyday environment. The potential of these de-vices has also increased the interest in getting them to interoperate. Currently,interoperability standards mostly apply for single domains, such as UPnP andDLNA for home entertainment, or are controlled by a single company, such asthe Apple ecosystem. The domain specic interoperability standards are chal-lenging for nomadic devices such as smart phones, which ideally should be ableto interoperate with any device it can connect to at any given time. A nomadicdevice will currently have to implement multiple standards to be able to partic-ipate in the dierent domains. Furthermore, the existing standards often targetspecic use cases instead of attempting to specify a more general interoperabilityframework. One initiative to target a generic interoperability framework is the semanticweb [1]. The goal of the semantic web is to provide machine readable informationabout the World Wide Web in order to allow automating many tasks that the webis currently used for manually. Eventually this would result in one giant globalgraph describing the resources of the web in RDF [10] according to ontologiesdened in dedicated languages such as in OWL [9]. However, the web is not thebest platform for sharing the rapidly changing, dynamic local information aboutthe immediate environment of a device. Smart-M3 is an interoperability platform that allows devices to easily shareand access local semantic information, while also allowing the more global se-mantic information to be available. The information is represented by using samemechanisms as in semantic web, thus allowing easy exchange of global and lo-cal information. The RDF representation also allows extremely easy linking ofdata also between dierent ontologies, thus making cross-domain interoperabilitystraightforward.

II While the used semantic web technologies have been designed to allow rea-soning over the information, Smart-M3 currently supports only limited reason-ing. Queries in Smart-M3 understand subclass relations, and the query enginealso understands the owl:sameAs property. The implemented reasoning mech-anisms in Smart-M3 are currently domain-independent, that is, they can takeinto account properties dened in RDFS or OWL, but not information dened indomain ontologies. However, in many applications creating domain-specic rea-soners would be useful. We present an approach where we use logic programmingfor dening the domain specic reasoning rules. As each RDF triplet can be interpreted as a fact of arity two, there is astraightforward link between RDF content and rulebases. Therefore, variouslogic programming approaches can be used in a natural manner to deduce newinformation by means of user constructed rules executed over the fact base. Thelogic programming approach is useful in creating domain specic instructionsfor searching and abstracting over the RDF content. Also searching for con-gurations and policies are natural to express using logic programming means.Furthermore it is possible to generate consitency rules based on ontologies. Inshort, a rule mechanism can be used to provide additional functional semanticsto accompany ontologies. Rules can also be thought of as views in the underly-ing RDF-base. In this way the logic programming mechanism provides a exiblealternative to query languages like SPARQL [12] or Wilbur Query Language[5]. This approach is not new, for instance Wielemaker et. al. [13] have proposedProlog to be fundament for application development for semantic web for similarreasons. The smodels [6] is a system for answer set programming. It consists oflparsefront end which transforms rule language to input suitable for smodels, whichis a solver based on stable model semantics of logic programming. Here we referto the combination of lparse front end and smodels solver simply as smodels.smodels allows constructing programs using extended logic programming con-cepts, atoms and inference rules, but by language construction the programs arealways decidable. ssls 1 is a command-line tool giving access to Smart-M3 operations withsome additional convenience features as well as a possiblity of interfacing externaltools to operate on the results of the operations. We use ssls to integrate smodelswith Smart-M3 as a node of the system. We do not expect this work to provide a complete programming environ-ment for applications (even though it in principle could be one), but rather as acomponent in Smart-M3 technology stack. In section 2 we introduce the Smart-M3 interoperability platform, in section3 we present the integration between smodels and ssls, in section 4 we give anexample of use and nally in section 5 we present our conclusions and possibilitiesfor future work.1 available at http://sourceforge.net/projects/ssls

III2 Smart-M3Smart-M3 is a space-based interoperability platform consisting of two main com-ponents: semantic information broker (SIB) and knowledge processor (KP). Asmart space is dened as a named search extent of information, where the infor-mation is stored in one or more SIBs. The architecture of the system is presentedin Figure 1. In the simplest case, one SIB will store all information in a smart space,but there is a possibility of connecting multiple SIBs to make up a smart space.The SIBs making up a smart space will be connected with a protocol that pro-vides distributed deductive closure [2]. Thus, any KP sees the same informationcontent in the smart space regardless of the SIB it connects to . 2 The information in the smart space is stored as an RDF graph, usually ac-cording to some dened ontology. The use of any specic ontology is not man-dated, however. Neither is the consistency of the stored information guaranteedin any way. The KPs may modify and query the information using the insert, re-move, update, query and subscribe operations by using the Smart Space AccessProtocol (SSAP). Join : Join a KP to a named space Leave : Leave a named space. After leaving, no more operations may be performed un- til a join operation Insert : Atomically insert a graph in the space Remove : Atomically remove a graph from the space Update : Atomically update a graph in the SIB. Update is a combination of remove followed by insert, executed atomically Query : Query for information in the space using any supported query language Subscribe : Set up a persistent query in the space; changes to the query results are re- ported to the subscriber Unsubscribe : Cancel an existing subscription The communication between KPs and SIB may be implemented by using anySOA style service network such as the Network on Terminal architecture [7], orby using a suitable transport protocol such as XMPP or TCP/IP. This approachallows using already deployed communication mechanisms and protects previousinvestments. Furthermore, it also means that KPs can connect to smart spacesby using the mechanism most suited to them.2 Distributed deductive closure is not implemented in the current Smart-M3 implementation

IV Agent Agent Agent Agent M3 Space SIB SIB SIB Fig. 1. A diagram of the general system architecture: Agents, M3 spaces and SIBs.2.1 Notion of ApplicationThe notion of application in a smart space diers from the concept of traditionalapplication. Instead of a monolithic application running on a single screen, thesmart space applications are better seen as scenarios that can be executed tomeet the goals of the user. The scenario emerges from the observable actions,taken by the participating knowledge processors, based on the information in thesmart space, and also from the use of available services. The scenarios may alsobe transient: the scenario will change as the participating KPs join and leavethe smart space, and also as services become available or unavailable. One of the targets of Smart-M3 has been to make combining the scenarioseasy. This is achieved by the loose coupling between the KPs, as they onlycommunicate by modifying and querying the information in the smart space.Thus, any eect that appearance or disappearance of KPs may have on the restof the environment is limited to the information seen in the smart space. KPsmay, of course, communicate with each other by any available means. but thisis outside the scope of Smart-M3. A KP understands its own, non-exclusive set of information. This informationmay be thought of as the ontology of a KP. It is rarely dened formally, and ismostly an implicit concept which can be useful in some situations. Overlap of thesets of information understood by KPs is an essential precondition for achievinginteroperability, as otherwise the KPs will never see each others actions. Smart-M3 has been used as an interoperability platform for a number of casestudies. The case studies illustrate the applicability of the concept to a varietyof areas. A case study of cross domain interoperability is described in [4]. The scenarioinvolved a wellness domain represented by SportsTracker application, home en-tertainment domain represented by music streaming using a UPnP service, gam-ing domain represented by SuperTux game, and telecom domain represented bya phone call observer application. All domains share information using a M3smart space, resulting in improved user experience compared to the case wherethe components operate independently. For example, when a call is received, the

Vgame and music player see the information that a call is ongoing in the smartspace and can take appropriate action, in this case pause the music and game.When the call ends, music continues automatically. Furthermore, the played mu-sic changes according to the state of the game, for example, when the player loseslives, the music changes appropriately. Finally, the game may award extra livesif the player has been exercising lately. Other case studies include a building automation case [3], a smart meetingroom case [11], a home sensor network case [8], and a health care case developedby University of Bologna. In the building automation case, information from the installed sensors andsystems is shared for others by using Smart-M3, allowing also devices that donot implement the oBIX or other building automation protocols to access theinformation. In the smart meeting room case, Smart-M3 is used to coordinate access tothe resources of a meeting room, such as a projector for presentations. The home sensor network case is remarkable in that all the hardware used iscommercially available. The demo shows input from several sensors on multipledevices, such as Apple iPhone, Nokia N810 and laptop. The health care case uses information from temperature and humidity sensorand patients heartrate monitor to determine if the external conditions may behazardous for the patient. Furthermore, a demonstration showing a combination of the home sensornetwork and healthcare demos where the information from the sensors used inhome sensor network demo was used in the healthcare system, illustrating theease of creating mash-up applications, has been created. All of these scenarios have been implemented by using various kinds of wrap-pers on top of SSAP protocol and ontological concepts on procedural languages,like C, C# and Python. All of these scenarios contain KPs whose essential be-haviour can easily be expressed as a set of rules and a part of the eort involvesre-implementing a specic ruleset and its support mechanisms in the host lan-guage.3 Integrating smodels using sslsFor this work the purpose of ssls is to integrate the smodels system as a nodelocal rule execution environment. This allows us to easily trial various function-alities, which may later on be integrated to SIB itself. We assume that at leastsome part of the SIB contents is fetched to the node for the duration of the ruleexecution. The basic operation of rule execution is that given a command, ssls fetchesthe contents of the SIB and generates a rulebase from them. The rules themselveshave been dened locally in a le or within ssls and they are executed againstthe rulebase using smodels. The result will be a set of triples to be inserted in theSIB and set of triples to be deleted from the SIB, which are then committed to

VIthe SIB. There are mechanisms for limiting the amount of fetched information aswell as adding a degree of reactivity, which are described later on in this section. The conversion of the SIB contents is straghtforward: the SIB is queried forall triples and they are converted from subject, predicate, object triplet to factpredicate(subject, object). In order to satisfy the lparse syntax checkerall URIs are quoted, which poses some problems for distinguishing betweenliterals and URIs. This is solved by doublequoting the URIs with < and >.For example, a triplet :abcd-2ew4, rdf:type, wp1:Person would produce a fact"<rdf:type>"("<:abcd-2ew4>", "<wp1:Person>"). The rules are written in a text le, which is given to ssls as a parameter.It is also possible to dene rules within the ssls interpreter, but only a subsetof lparse language features are supported. The result of the smodels executionover the fact base and the rules is parsed for predened facts which trigger addingcontent to insert and delete buers, which are then committed to SIB. The factsfor adding triples to insert and delete buers are correspondingly i and d, bothof arity three. Note that both i and d are ssls commands for adding triplesto the buers, which are then committed by the SSAP command update. Afterall generated facts have been parsed the update command is issued which willcause atomically the deletions to occur, followed by the insertions. In additionto the above i and d there are specic facts which cause ssls to print theirarguments. During the rule execution several facts beside the ones which are interpreted(described above) may have been deduced. Unless these facts have been mar-shalled by means of i and d to the SIB, they will disappear after the ruleexecution. In this way the node with the rule engine is stateless. Of course itmay be that the SIB is modied inbetween two rule executions and thus theresults will be dierent for the same rules. However, it may be useful to have a hidden state, which is not published tothe SIB. This may be due to security issues or performance reasons. This canbe achieved by adding facts to the le with rules, but there is also a mechanimswhich allows to create a new persistent fact by means of rules themselves. If thefact ssls_fact with arity two is deduced, ssls calls its own rule command toadd a new fact to its internal rulebase with the given arguments. The downsideof introducing hidden state is that the state is local and the distribution of ruleswhich use ssls_fact may be harder. Above we mentioned that the whole SIB is transferred to the node as thefactbase for rule execution. Since the transferral is done by means of the SSAPquery command, it is possible to limit the amount of information transferred.ssls contains a view mechanims which allows constructing a query with a set oftriple patterns. So far we do not have any mechanism to check whether a viewenables all rules, so this is an ad-hoc mechnism of reducing the amount tracand requires an understanding of the particular rules to be safe. Finally, we may automatically trigger execution of rules by using the SSAPsubscription mechanism. The mechanism allows setting up a persistent query andwhenever there are changes in SIB pertaining to the query, the node is informed

VIIabout them. ssls allows naming subscriptions and whenever a subscription withits name prexed by smls res, the rule execution is initiated. This provides fora simple reactive mechanism to execute the rules. Note that so far each single execution of the rule-engine is decidable, but theabove mechanism together with the notion of state (either in SIB or locally inthe node) makes it impossible to determine the behaviour of such a chaining ofsingle rule-engine executions. On the other hand this enables more generic pro-gramming, but the required mechanisms and sensibility of this approach needsfurther research.4 A rule exampleWe have chosen smodels over other similar alternatives (like Prolog) for coupleof reasons: rstly, the execution is decidable, removing a whole class of errors.Secondly, the execution order of the rule body is not relevant. This enables futuredistribution strategies for rule execution. Thirdly, the system is well establishedwith several implementations. Finally, the smodels language contains several fea-tures, which are very useful in constructing rules, namely: possiblity of choosinga dened number of facts, a negation which works as set negation and weighingfacts.const threshold = 10.% Rule 13 { power_save_on(X),i(X,"<mob:pmode>","low"),d(X,"<mob:pmode>","high")} 3 :- "<rdf:type>"(X,"<mob:Device>"), "<mob:battery_level>"(X,Y), not connection_active(X), lt(Y,threshold).% Rule 2connection_active(X) :- 1 {"<mob:gsm>"(X,"on"), "<mob:wlan>"(X,"on")}.% Rule 33 { power_save_off(X),i(X,"<mob:pmode>","high"),d(X,"<mob:pmode>","low")} 3 :- "<rdf:type>"(X,"<mob:Device>"), "<mob:battery_level>"(X,Y), ge(Y,threshold). Fig. 2. smodels rules for a simple power manager

VIII We give a simplistic example highlighting the two rst features. In this casewe have a mobile device, which monitors its battery level and if the level fallsunder a preset value, puts the device to a power saving mode unless a connectionis active. We dene connection as either GSM being active or a WLAN connec-tion being active. Figure 2 shows three rules to achieve this. Rule 1 derives threefacts power_save_on, i and d for a device instance X, if the battery level is lessthan threshold and the fact connection_active does not exist in the rulebase.The head has three facts surrounded by minimum and maximum bounds, hereboth are three. This means that if the body matches, smodels should chooseprecisely three facts from the three possible choices. Here this is used as short-hand to avoid writing the same body for three dierent heads, but with dierentbounds we could choose subset(s) of the facts. Rule 2 states that we can deriveconnection_active if at least one of the listed possibilities exists. Rule 3 actsas a complement of Rule 1, turning power saving o when needed. Note, that power_save_on and power_save_off facts are not used anywherein here. They are redundant as we expect that the information produced by iand d will trigger the appropriate behaviour by some other node in the system.However, if there will be other rules, these two facts can be used as componentsin those. In a way these facts act as an interface that this set of rules is oeringfor other rules.5 Conclusions and Future WorkWe have presented an integration of an answer-set programming system smodelsto Smart-M3. The mechanism we have presented is simple and not specic tosmodels, any other logic-programming system could be integrated by similarmeans. smodels does not as such contain any reactive features but Smart-M3 appli-cations are by their nature reactive. This is why we have introduced a simplereactive mechanism in our system, which allows us the possiblity of implement-ing those kinds of programs using logic programming mechanisms. This comesat a price as the behaviour of the system when chaining several rule executionsmay not be easily predictable. One of our future research items is to understandand solve the challenges arising from this. As Smart-M3 does not currently have advanced reasoning capabilities, we usethis approach to trial possible solutions to be included in the Smart-M3 system.One interesting possibility is to embed the rule engine in the SIB, and dene anontology for expressing the rulesets. This would allow executing rules dened byKPs in the SIB. For KPs with limited computing power this could be used asa mechanism to ooad some of the computation from a small device to a morepowerful device. Furthermore, as mentioned in section 2.1, in most scenariosthere seems to be a need to utilize reasoning which is well suited to be expressedsuccinctly using rules. This reasoning could be performed conveniently in the SIBwith the embedded rules engine. However, the exact benets, e.g. less networktrac, and tradeos, e.g. performance of SIB, need to be further researched.

IX The previous issues yield more particular technical research topics and workitems pertaining to our rule based approach, such as: how to derive a suitable query expression from the rules to reduce the amount of trac needed how to parallelize the execution of rules implement publishing and reading in rules from SIB, enabling reective cre- ation of rules how to derive rules from an ontology to enforce consistency of SIB contents implement an ssls primitive to start subscriptions from the rules We also aim to reimplement parts of the existing scenarios using the rulebased approach.AcknowledgementThis work was supported by SOFIA (Smart Objects For Intelligent Applica-tions) project and funded by Tekes (the Finnish Funding Agency for Technologyand Innovation) and the European Commission, and DIEM (Devices and Inter-operability Ecosystem) funded by Tekes.References 1. Tim Berners-Lee, James Hendler, and Ora Lassila. The semantic web. Scientic American, May 2001. 2. Sergey Boldyrev, Ian Oliver, and Jukka Honkola. A mechanism for managing and distributing information and queries in a smart space environment. In Proceedings of MDMD2009, May 2009. 3. Kary Främling, Ian Oliver, Jukka Honkola, and Jan Nyman. Smart spaces for ubiquitously smart buildings. In Proceedings of UBICOMM2009, October 2009. 4. Jukka Honkola, Hannu Laine, Ronald Brown, and Ian Oliver. Cross-domain interoperability: A case study. In Sergey Balandin, Dmitri Moltchanov, and Yev- geni Koucheryavy, editors, Proceedings of Smart Spaces and Next Generation Wired/Wireless Networking, volume 5764 of Lecture Notes in Computer Science, pages 2231. Springer, 2009. 5. Ora Lassila. Programming Semantic Web Applications: A Synthesis of Knowl- edge Representation and Semi-Structured Data. PhD thesis, Helsinki University of Technology, November 2007. 6. Ilkka Niemelä and P. Simons. Smodels an implementation of the stable model and well-founded semantics for normal logic programs. In Proceedings of the 4th International Conference on Logic Programming and Non-Monotonic Reasoning, pages 420429, Dagstuhl, Germany, July 1997. Springer-Verlag. 7. Network on terminal architecture. http://www.notaworld.org, 11 2008. 8. Openm3 demonstration release. http://sourceforge.net/projects/smart- m3/les/OpenM3.tar.gz/download. 9. Web ontology language. http://www.w3.org/2004/OWL/.10. Resource description framework. http://www.w3.org/RDF/.

X11. Aleksander Smirnov, Aleksey Kashevnik, Nikolay Shilov, Ian Oliver, Sergey Ba- landin, and Sergey Boldyrev. Anonymous agent coordination in smart spaces: State-of-the-art. In Sergey Balandin, Dmitri Moltchanov, and Yevgeni Kouch- eryavy, editors, Proceedings of Smart Spaces and Next Generation Wired/Wireless Networking, volume 5764 of Lecture Notes in Computer Science, pages 4251. Springer, 2009.12. W3c recommendation: Sparql query language for rdf. http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115.13. Jan Wielemaker, Michiel Hildebrand, and Jacco van Ossenbruggen. Using Prolog as the fundament for applications on the semantic web. In S.Heymans, A. Polleres, E. Ruckhaus, D. Pearse, and G. Gupta, editors, Proceedings of the 2nd Workshop on Applicatiions of Logic Programming and to the web, Semantic Web and Semantic Web Services, volume 287 of CEUR Workshop Proceedings, pages 8498. CEUR- WS.org, 2007.

SOFIA - Integration of an Answer Set Engine to Smart m3. NOKIA

by Sofia Eu

Accessibility

Upload Details

Usage Rights

Statistics

SOFIA - Integration of an Answer Set Engine to Smart m3. NOKIA Document Transcript