1. 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 possi-
blity 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 Introduction
Nowadays, a lot of devices with considerable computing power and connectivity
mechanisms 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 and
DLNA for home entertainment, or are controlled by a single company, such as
the Apple ecosystem. The domain specic interoperability standards are chal-
lenging for nomadic devices such as smart phones, which ideally should be able
to interoperate with any device it can connect to at any given time. A nomadic
device will currently have to implement multiple standards to be able to partic-
ipate in the dierent domains. Furthermore, the existing standards often target
specic use cases instead of attempting to specify a more general interoperability
framework.
One initiative to target a generic interoperability framework is the semantic
web [1]. The goal of the semantic web is to provide machine readable information
about the World Wide Web in order to allow automating many tasks that the web
is currently used for manually. Eventually this would result in one giant global
graph describing the resources of the web in RDF [10] according to ontologies
dened in dedicated languages such as in OWL [9]. However, the web is not the
best platform for sharing the rapidly changing, dynamic local information about
the immediate environment of a device.
Smart-M3 is an interoperability platform that allows devices to easily share
and access local semantic information, while also allowing the more global se-
mantic information to be available. The information is represented by using same
mechanisms as in semantic web, thus allowing easy exchange of global and lo-
cal information. The RDF representation also allows extremely easy linking of
data also between dierent ontologies, thus making cross-domain interoperability
straightforward.

2. 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 engine
also understands the owl:sameAs property. The implemented reasoning mech-
anisms in Smart-M3 are currently domain-independent, that is, they can take
into account properties dened in RDFS or OWL, but not information dened in
domain ontologies. However, in many applications creating domain-specic rea-
soners would be useful. We present an approach where we use logic programming
for dening the domain specic reasoning rules.
As each RDF triplet can be interpreted as a fact of arity two, there is a
straightforward link between RDF content and rulebases. Therefore, various
logic programming approaches can be used in a natural manner to deduce new
information by means of user constructed rules executed over the fact base. The
logic programming approach is useful in creating domain specic instructions
for 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. In
short, a rule mechanism can be used to provide additional functional semantics
to 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 exible
alternative to query languages like SPARQL [12] or Wilbur Query Language
[5]. This approach is not new, for instance Wielemaker et. al. [13] have proposed
Prolog to be fundament for application development for semantic web for similar
reasons.
The smodels [6] is a system for answer set programming. It consists oflparse
front end which transforms rule language to input suitable for smodels, which
is a solver based on stable model semantics of logic programming. Here we refer
to 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 are
always decidable.
ssls 1 is a command-line tool giving access to Smart-M3 operations with
some additional convenience features as well as a possiblity of interfacing external
tools to operate on the results of the operations. We use ssls to integrate smodels
with 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 a
component in Smart-M3 technology stack.
In section 2 we introduce the Smart-M3 interoperability platform, in section
3 we present the integration between smodels and ssls, in section 4 we give an
example of use and nally in section 5 we present our conclusions and possibilities
for future work.
1
available at http://sourceforge.net/projects/ssls

3. III
2 Smart-M3
Smart-M3 is a space-based interoperability platform consisting of two main com-
ponents: semantic information broker (SIB) and knowledge processor (KP). A
smart 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 presented
in 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 information
content 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 guaranteed
in 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 Access
Protocol (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 fol-
lowed by insert, executed atomically
Query : Query for information in the space us-
ing 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 any
SOA style service network such as the Network on Terminal architecture [7], or
by using a suitable transport protocol such as XMPP or TCP/IP. This approach
allows using already deployed communication mechanisms and protects previous
investments. Furthermore, it also means that KPs can connect to smart spaces
by using the mechanism most suited to them.
2
Distributed deductive closure is not implemented in the current Smart-M3 imple-
mentation

4. 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 Application
The notion of application in a smart space diers from the concept of traditional
application. Instead of a monolithic application running on a single screen, the
smart space applications are better seen as scenarios that can be executed to
meet the goals of the user. The scenario emerges from the observable actions,
taken by the participating knowledge processors, based on the information in the
smart space, and also from the use of available services. The scenarios may also
be transient: the scenario will change as the participating KPs join and leave
the smart space, and also as services become available or unavailable.
One of the targets of Smart-M3 has been to make combining the scenarios
easy. This is achieved by the loose coupling between the KPs, as they only
communicate by modifying and querying the information in the smart space.
Thus, any eect that appearance or disappearance of KPs may have on the rest
of the environment is limited to the information seen in the smart space. KPs
may, of course, communicate with each other by any available means. but this
is outside the scope of Smart-M3.
A KP understands its own, non-exclusive set of information. This information
may be thought of as the ontology of a KP. It is rarely dened formally, and is
mostly an implicit concept which can be useful in some situations. Overlap of the
sets of information understood by KPs is an essential precondition for achieving
interoperability, as otherwise the KPs will never see each others actions.
Smart-M3 has been used as an interoperability platform for a number of case
studies. The case studies illustrate the applicability of the concept to a variety
of areas.
A case study of cross domain interoperability is described in [4]. The scenario
involved 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 by
a phone call observer application. All domains share information using a M3
smart space, resulting in improved user experience compared to the case where
the components operate independently. For example, when a call is received, the

5. V
game and music player see the information that a call is ongoing in the smart
space 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 loses
lives, the music changes appropriately. Finally, the game may award extra lives
if the player has been exercising lately.
Other case studies include a building automation case [3], a smart meeting
room case [11], a home sensor network case [8], and a health care case developed
by University of Bologna.
In the building automation case, information from the installed sensors and
systems is shared for others by using Smart-M3, allowing also devices that do
not implement the oBIX or other building automation protocols to access the
information.
In the smart meeting room case, Smart-M3 is used to coordinate access to
the resources of a meeting room, such as a projector for presentations.
The home sensor network case is remarkable in that all the hardware used is
commercially available. The demo shows input from several sensors on multiple
devices, such as Apple iPhone, Nokia N810 and laptop.
The health care case uses information from temperature and humidity sensor
and patient's heartrate monitor to determine if the external conditions may be
hazardous for the patient.
Furthermore, a demonstration showing a combination of the home sensor
network and healthcare demos where the information from the sensors used in
home sensor network demo was used in the healthcare system, illustrating the
ease 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 involves
re-implementing a specic ruleset and its support mechanisms in the host lan-
guage.
3 Integrating smodels using ssls
For this work the purpose of ssls is to integrate the smodels system as a node
local 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 least
some part of the SIB contents is fetched to the node for the duration of the rule
execution.
The basic operation of rule execution is that given a command, ssls fetches
the contents of the SIB and generates a rulebase from them. The rules themselves
have been dened locally in a le or within ssls and they are executed against
the rulebase using smodels. The result will be a set of triples to be inserted in the
SIB and set of triples to be deleted from the SIB, which are then committed to

6. VI
the SIB. There are mechanisms for limiting the amount of fetched information as
well 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 for
all triples and they are converted from subject, predicate, object triplet to fact
predicate(subject, object). In order to satisfy the lparse syntax checker
all URIs are quoted, which poses some problems for distinguishing between
literals 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 subset
of lparse language features are supported. The result of the smodels execution
over the fact base and the rules is parsed for predened facts which trigger adding
content to insert and delete buers, which are then committed to SIB. The facts
for adding triples to insert and delete buers are correspondingly i and d, both
of arity three. Note that both i and d are ssls commands for adding triples
to the buers, which are then committed by the SSAP command update. After
all generated facts have been parsed the update command is issued which will
cause atomically the deletions to occur, followed by the insertions. In addition
to the above i and d there are specic facts which cause ssls to print their
arguments.
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 rule
execution. In this way the node with the rule engine is stateless. Of course it
may be that the SIB is modied inbetween two rule executions and thus the
results will be dierent for the same rules.
However, it may be useful to have a hidden state, which is not published to
the SIB. This may be due to security issues or performance reasons. This can
be achieved by adding facts to the le with rules, but there is also a mechanims
which allows to create a new persistent fact by means of rules themselves. If the
fact ssls_fact with arity two is deduced, ssls calls its own rule command to
add a new fact to its internal rulebase with the given arguments. The downside
of introducing hidden state is that the state is local and the distribution of rules
which use ssls_fact may be harder.
Above we mentioned that the whole SIB is transferred to the node as the
factbase for rule execution. Since the transferral is done by means of the SSAP
query command, it is possible to limit the amount of information transferred.
ssls contains a view mechanims which allows constructing a query with a set of
triple patterns. So far we do not have any mechanism to check whether a view
enables all rules, so this is an ad-hoc mechnism of reducing the amount trac
and requires an understanding of the particular rules to be safe.
Finally, we may automatically trigger execution of rules by using the SSAP
subscription mechanism. The mechanism allows setting up a persistent query and
whenever there are changes in SIB pertaining to the query, the node is informed

7. VII
about them. ssls allows naming subscriptions and whenever a subscription with
its name prexed by smls res, the rule execution is initiated. This provides for
a simple reactive mechanism to execute the rules.
Note that so far each single execution of the rule-engine is decidable, but the
above mechanism together with the notion of state (either in SIB or locally in
the node) makes it impossible to determine the behaviour of such a chaining of
single rule-engine executions. On the other hand this enables more generic pro-
gramming, but the required mechanisms and sensibility of this approach needs
further research.
4 A rule example
We have chosen smodels over other similar alternatives (like Prolog) for couple
of 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 future
distribution strategies for rule execution. Thirdly, the system is well established
with several implementations. Finally, the smodels language contains several fea-
tures, which are very useful in constructing rules, namely: possiblity of choosing
a dened number of facts, a negation which works as set negation and weighing
facts.
const threshold = 10.
% Rule 1
3 {
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 2
connection_active(X) :-
1 {mob:gsm(X,on),
mob:wlan(X,on)}.
% Rule 3
3 {
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

8. VIII
We give a simplistic example highlighting the two rst features. In this case
we have a mobile device, which monitors its battery level and if the level falls
under a preset value, puts the device to a power saving mode unless a connection
is 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 three
facts power_save_on, i and d for a device instance X, if the battery level is less
than threshold and the fact connection_active does not exist in the rulebase.
The head has three facts surrounded by minimum and maximum bounds, here
both are three. This means that if the body matches, smodels should choose
precisely 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 dierent
bounds we could choose subset(s) of the facts. Rule 2 states that we can derive
connection_active if at least one of the listed possibilities exists. Rule 3 acts
as a complement of Rule 1, turning power saving o when needed.
Note, that power_save_on and power_save_off facts are not used anywhere
in here. They are redundant as we expect that the information produced by i
and 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 components
in those. In a way these facts act as an interface that this set of rules is oering
for other rules.
5 Conclusions and Future Work
We have presented an integration of an answer-set programming system smodels
to Smart-M3. The mechanism we have presented is simple and not specic to
smodels, any other logic-programming system could be integrated by similar
means.
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 simple
reactive mechanism in our system, which allows us the possiblity of implement-
ing those kinds of programs using logic programming mechanisms. This comes
at a price as the behaviour of the system when chaining several rule executions
may not be easily predictable. One of our future research items is to understand
and solve the challenges arising from this.
As Smart-M3 does not currently have advanced reasoning capabilities, we use
this 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 an
ontology for expressing the rulesets. This would allow executing rules dened by
KPs in the SIB. For KPs with limited computing power this could be used as
a mechanism to ooad some of the computation from a small device to a more
powerful device. Furthermore, as mentioned in section 2.1, in most scenarios
there seems to be a need to utilize reasoning which is well suited to be expressed
succinctly using rules. This reasoning could be performed conveniently in the SIB
with the embedded rules engine. However, the exact benets, e.g. less network
trac, and tradeos, e.g. performance of SIB, need to be further researched.

9. IX
The previous issues yield more particular technical research topics and work
items 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 rule
based approach.
Acknowledgement
This work was supported by SOFIA (Smart Objects For Intelligent Applica-
tions) project and funded by Tekes (the Finnish Funding Agency for Technology
and 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 in-
teroperability: 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/.

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