=Paper=
{{Paper
|id=Vol-2134/paper06
|storemode=property
|title=Integrating Ontologies for Context-based Constraint-based Planning
|pdfUrl=https://ceur-ws.org/Vol-2134/paper06.pdf
|volume=Vol-2134
|authors=Uwe Köckemann,Marjan Alirezaie,Lars Karlsson,Amy Loutfi
|dblpUrl=https://dblp.org/rec/conf/ijcai/KockemannAKL18
}}
==Integrating Ontologies for Context-based Constraint-based Planning==
https://ceur-ws.org/Vol-2134/paper06.pdf
Tenth International Workshop Modelling and Reasoning in Context (MRC) – 13.07.2018 – Stockholm, Sweden
Integrating Ontologies for Context-based Constraint-based Planning
Uwe Köckemann, Marjan Alirezaie, Lars Karlsson, Amy Loutfi
Center for Applied Autonomous Sensor Systems, Örebro University, Sweden
Abstract formation goals. We propose that the problem of automation
configuration is seen as a planning problem where configura-
We describe an approach for integrating ontolo- tion planning aims at automatically finding a set of sensor and
gies with a constraint-based planner to compile actuator instances to use for gathering and processing data
configuration planning domains based on the cur- and to answer information queries.
rent context. We consider two alternative ap- In this paper, we describe a way to re-use information from
proaches: The first one integrates SPARQL queries the same ontology to dynamically assemble a configuration
directly with the planner while the second one gen- planning problem. Our main motivation for this is to avoid
erates SPARQL queries dynamically from provided redundancy in various parts of the E-Care@Home system. It
triples. The first approach offers the full freedom is achieved by compiling the domains for a constraint-based
of the SPARQL query language, while the second configuration planner for a given context and based on infor-
offers a more dynamic way for the planner to in- mation from the ontology.
fluence queries based on what is currently relevant Figure 1 illustrates the idea of the approach. We have a
for the planner. We evaluate the approach based model of the environment, a goal in the form of an informa-
on how much redundancy is removed by “out- tion request, and an ontology that tells us about available sen-
sourcing” knowledge into the ontology compared sors and what information we can obtain from them. From
to modeling it directly into the domain of the plan- this we want to create and solve a configuration planning
ner. problem that allows to configure the smart home environ-
ment in order to provide the requested information when it
1 Introduction is needed. Using an ontology in this context is convenient
because the same set of concepts and relations represented in
The E-Care@Home project1 aims to achieve semantic inter- an ontology can be used for many different purposes (e.g.,
operability between information provided by environmental activity recognition). In most cases, a domain for task plan-
sensors, medical sensors, as well as information from pub- ning will only be used for a single purpose and might con-
lic health records in order to help health care professionals tain redundancy wrt. other parts of an overall system. We
to process and gather information from an Ambient Assisted present two approaches that allow a constraint-based planner
Living (AAL) environment [Alirezaie et al., 2017]. One ma- to include dependencies on ontologies. The first approach
jor contribution of E-Care@Home is the SmartEnv ontology2 is to use SPARQL queries [Prud’hommeaux and Seaborne,
which as a reusable and publicly accessible knowledge model 2008] directly. The second approach extends the planner’s
describes the sensors available in a given environment and domain definition language to directly refer to parts of the
provides a way to interpret the data they provide for activity ontology via triples and prefixes identifying the ontologies
recognition [Alirezaie et al., 2018]. that are used. We provide a simple evaluation that shows how
Although the symbolic language of the ontology makes it we can generate planning operators from an ontology of a re-
easy for human users to query the knowledge about the ambi- alistic smart home environment. Neither approach is linked
ent assisted living context, it is still important that users can directly to configuration planning and both can be used for
express their queries in terms of activities and locations with- any constraint-based planning problem.
out having to refer to specific instances of sensors or actu- Before going to the details we briefly introduce the
ators. In addition, there may be multiple ways to infer the SmartEnv ontology in the following:
same information, and available sensors and actuators can
vary over time and be different from one home to another. 1.1 SmartEnv Ontology
This leads to a need for some form of decision making re-
garding which sensors are used in what way to achieve in- SmartEnv is an ontology designed to represent different as-
pects of a smart environment including the objects (e.g.,
1
http://ecareathome.se/ chairs, couches, TVs), their properties (such as pressure, il-
2
http://w3id.org/smartenvironment/smartenv.owl lumination), the feature of interests for a specific observa-
22
Tenth International Workshop Modelling and Reasoning in Context (MRC) – 13.07.2018 – Stockholm, Sweden
the HTN planning problem and the problem of finding a con-
figuration that satisfies all information dependencies.
[Di Rocco et al., 2013] go one step further and integrates
information dependencies with causal, temporal and resource
reasoning. Information is still treated as static in the sense
that it does not consider information being available for only
a limited temporal interval. Configuration planning problem
with multiple, partially-ordered preferences was considered
by [Silva-Lopez et al., 2015]. In [Köckemann and Karlsson,
2017], we presented two approaches to integrate information
dependencies into the constraint-based planner SpiderPlan3 .
The goal-based approach simply adds information goals and
dependencies as goals and preconditions to the planner’s op-
erators. This allows to simply use the planner without exten-
sion. The second approach defines a sub-problem to satisfy
Figure 1: The problem: generate the configuration planning information dependencies as a Constraint Satisfaction Prob-
problem from information about the environment, an infor- lem (CSP) that can be solved on its own but may introduce
mation request, and ontological information about sensors further task-requirements for the planner. The goal based ap-
and concepts. proach tends to be faster, while the CSP-based approach pro-
vides better quality solutions (since it uses optimization on
the sub-problem).
tion process(e.g., pressure under the couch), the observation Existing work on combining planning with ontologies in-
(or sensing) process itself including the sensors, rate of sam- cludes the work by Galindo and Saffiotti [2013] who model
pling and the network configurations. SmartEnv also provides norms as part of an ontology to create goals in case robot ob-
the representational basis required to model the temporal and servations deviate from the norm. McNeill et al. [2005] dis-
spatial aspects of the environment, events or activities refer- cuss the translation from ontologies to the Planning Domain
ring to a change that can interpreted as a specific situation in Defintion Language (PDDL) [Ghallab et al., 1998]. In com-
the environment (e.g., the pressure sensor under the couch is parison, our approach is focused on integration, rather than
triggered which is interpreted as some one is sitting on the translation. In this way, we can focus on fetching relevant
couch). Further details with scripted scenarios can be found available information from ontologies, while modeling oper-
in [Alirezaie et al., 2018]. ators and their constraints in the planner’s domain definition
The rest of the paper is formed as follows: Section 3 pro- language. Considering the connection to the ontology as a
vides a short description of constraint-based planning. Sec- new constraint type that is solved by a dedicated solver leads
tion 4 describes how the constraint-based planner can be ex- to a clear conceptual separation.
tended to use SPARQL queries. Section 5 describes the al-
ternative triple-based approach. Finally, Section 6 provides 3 Constraint-based Planning
an initial evaluation based on the reduction of redundancy of- The approach to constraint-based planning that we use in this
fered by the ontology-based approach. paper models different types of knowledge via different types
of constraints. Solvers for constraint-based planning prob-
2 Related Work lems can be composed of solvers for individual constraint
types. Each of these types poses a sub-problem and solving
The constraint-bases planner described in Section 3 was de- all sub-problems leads to a solution to the overall problem.
scribed by [Köckemann, 2016; Köckemann et al., 2014] who A sub-problem for a constraint type can have three different
used it to provide solutions for several challenges of human- outcomes. It can be satisfied, unsatisfiable, or require to re-
aware planning. Configuration planning combines task plan- solve a flaw. In the latter case, there might be a choice of re-
ning, which attempts to reach a set of goals by applying oper- solvers that need to be explored systematically. For each con-
ators (or actions), with information dependencies and infor- straint type we assume a solver that decides if a sub-problem
mation goals. This can be viewed as an extension of the task can be resolved and how. This search over resolvers of flaws
planning problem. Operators may require information to be for all constraint types defines the constraint-based planning
applicable (information dependency). A robot, for instance, problem as a search problem. Our implementation of this
may require a camera feed of a ceiling camera in order to approach (SpiderPlan), supports an extendable domain defi-
move safely through the environment. Indeed, gathering in- nition language. In the following we will go over the basics
formation might even be the goal (i.e., an information goal) of the representation, but we will keep the description of the
which requires task planning to be achieved. actual planning approach to a minimum since we are more
[Lundh, 2009] describes an early approach to configuration interested in problem generation.
planning based on an extension of hierarchical task-network A Constraint Database (CDB) Φ is a set of constraints of
planning [Nau et al., 2003]. Operators are extended to func- different types. Constraint types considered in this paper are
tionalities that describe input and output of information. The
3
configuration planning problem is solved as a composition of spiderplan.org
23
Tenth International Workshop Modelling and Reasoning in Context (MRC) – 13.07.2018 – Stockholm, Sweden
statements, arithmetic (math) and cost constraints, temporal be applicable, a set of effect statements E that are added when
constraints, open goals, and interaction constraints. We will the operator is applied, and a set of constraints C that must be
go over each type in turn. Later, we also introduce a new type satisfied when the operator is applied. Usually, C contains
of constraint for configuration planning that will be utilized temporal constraints that relate the temporal intervals of pre-
in our second approach. In our approach to constraint-based conditions and effects to the operator itself. If an operator’s
planning, CDBs constitute the problem, as well as the solu- effect adds a statement that can be matched to a goal that goal
tion. In the following section, we show how a complex CDB can be satisfied by connecting them with a temporal equals
can be generated from a simpler CDB that depends on infor- constraint (forcing effect and goal intervals to have the same
mation from an ontology. In the remainder of this section solution space). In the next section we will see how operators
we go over some constraint types that we use in the example can be used to establish information links.
domains in the next sections.
The most basic type is statement. Statements relate state- Example 3. The following operator requires a raw camera
variable assignments to temporal intervals. They have the feed and produces a processed one. Information is repre-
form (I x v) where I is a temporal interval, x is the state- sented by precondition and effect statements. The temporal
variable and v the value. We use statements to model both overlaps constraint assures that the required information is
the context for the task planner (initial state, preconditions, available before processing (interval ?P has to start at least
and effects), as well as information that is available during a 10 time units before interval ?E ). The operators interval
temporal interval. (represented by ?THIS ) is equal to the effect interval.
Example 1. The first two statements below represent the lo-
(:operator (process-camera-feed)
cation of a robot and an object. The third statement is used to (:preconditions (?P (camera-feed-raw ?R ?O)) )
represent which object the robot is facing. The last two state- (:effects (?E (camera-feed-processed ?O)) )
ments actually represent information that is available during (:constraints (:temporal (equals ?THIS ?E)
their intervals. (overlaps ?P ?E [10 inf] [1 inf]) ) ) )
(:statement (I1 (at robot) location)
(I2 (at object) location) The following goal can be achieved by the example opera-
(I3 (facing robot) object) tor if the raw camera feed is available during a temporal in-
(I4 (camera-feed-raw robot object)) terval that can satisfy temporal constraints of both goal and
(I5 (camera-feed-processed object)) )
operator. The temporal equals constraint is used to link ef-
fects with goals that they achieve (as shown below).
A temporal context for statements is established by tempo-
ral constraints that can impose, e.g., flexible durations, re-
(:goal (G (camera-feed-processed object)) )
lease times or precedence constraints. We express tempo- (:temporal (at G [0 50] [80 inf])
ral constraints via quantified Allen’s interval relations Allen (equals G I5) ) ;; G is satisfied by I5
[1984]; Meiri [1996] between statements in CDBs. For con-
venience, we add disjunctions of conceptually neighboring
constraints such as during-or-equals Freksa [1992]. We also Cost constraints are used to add up costs. Math constraints
add the unary temporal constraints release, deadline, dura- can be used to perform calculations. In this paper we use
tion and at. these constraints to calculate and sum up the costs of us-
Example 2. The following temporal constraints applied to ing sensors based on information from the SmartEnv ontol-
the statements from Example 1 state that the robot is facing ogy. Interaction Constraints (ICs) essentially allow to di-
the object while they are both at the same location. The raw rectly model flaws and resolvers in terms of any constraint
camera feed is provided during the interval where the robot type used by the planner. Flaws and resolvers if ICs are user-
is facing the object. The two bounds state the difference be- provided CDBs. This can be used, for instance, to model
tween start and end times of the two intervals. Finally, the social acceptability of generated plans. Using a camera dur-
processed camera feed is provided with a temporal delay of ing specific human activities may be considered unaccept-
10 time units. able. This could be modelled by two statements (represent-
ing camera usage and human activity) and a temporal con-
(:temporal (during I3 I1 [1 inf] [1 inf])
straint (these statements can overlap in time). Possible re-
(during I3 I2 [1 inf] [1 inf])
(during I4 I3 [1 inf] [1 inf]) solvers could impose temporal constraints to make sure that
(overlaps I5 I4 [10 inf] [1 inf]) ) the camera is used before or after this human activity. ICs
are a very powerful tool to express complex situations and
Goals are statements that the task planner is supposed to how they should be resolved. In this paper we use them to
achieve. Temporal constraints on the intervals of goal state- dynamically assemble value-domains for variables based on
ments allow to define during what interval the goal has to be the information found in an ontology.
reached. Goal constraints require operators that define which Since we focus on context-based problem construction, we
statements can be reached from a CDB. An operator o is a tu- omit the details of the algorithms and the description of in-
ple (name, P, E, C) that consists of a name, a set of precon- dividual solvers. Details can be found, e.g., in Köckemann
dition statements P that must be in a CDB for the operator to [2016].
24
Tenth International Workshop Modelling and Reasoning in Context (MRC) – 13.07.2018 – Stockholm, Sweden
4 Integrating SPARQL Queries into (query-link-3 "./queries/query-link-3.
Constraint-based Planning sparql")
(query-link-4 "./queries/query-link-4.
SPARQL is a semantic query language which is applied to sparql") )
query the data represented in RDF (Resource Description
Framework) [Carroll et al., 2004]. In this section we de- Example 2. A simple SPARQL query that requests all the
scribe how we integrate SPARQL (under the Jena framework) information that can be provided by sensors without any spe-
into constraint-based planning. The basic idea is to include a cial requirements. The prefixes assigned to the ontologies are
SPARQL query from a separate file and define how the vari- used in the body of the queries as the replacement of the on-
ables in this query are linked to the variables used by the plan- tology URIs to make the queries shorter.
ner.
As mentioned above, SmartEnv is the ontology that we use PREFIX ecare:
PREFIX sensing:
requirements) under which the information is valid. PREFIX foi:
tended easily with new types of constraints. To achieve our PREFIX dul:
allows to substitute their results into our configuration plan- PREFIX rdf:
ning domain. For this to be possible, we need several compo-
nents: SELECT ?Sensor ?Info ?Cost
1. Ontology description (TBox), referring to the general
knowledge common to all sensors and smart homes. WHERE {
?Sensor rdf:type sensing:SmartHomeSensor.
2. Ontology data (ABox), referring to individuals defining ?sensingProcess dul:implementedBy ?Sensor.
specific smart homes and sensors. ?sensingProcess rdf:type sensing:
SensingProcess.
3. SPARQL query (posing questions to the ontology) ?sensingProcess dul:hasConstituent ?Info.
4. SPARQL expressions (connecting SPARQL query to ?Info rdf:type foi:
constraint-based planner) SmartHomeFeatureOfInterest.
?sensingProcess sensing:hasCost ?Cost.
Given the TBox and the ABox of the ontology, this solution ?sensingProcess sensing:
requires the user to define queries in SPARQL and relate the requiresConfiguration none.
variables retrieved as answers to these queries to expressions ?sensingProcess sensing:
used in the planner’s domain definition. The query is then requiresLocation none.
?sensingProcess sensing:requiresTargeting
executed and its results are substituted into the planner’s do-
none. }
main. This effectively allows to define operators in a context
determined by the content of the ontology. As a result we can
remove all domain specific knowledge (except the relations Example 3. An extension of the previous example that re-
used in the queries) on the planner’s side. A comprehensive turns all information provided by sensors that have a specific
example is provided below. configuration ?Config. The difference to the previous exam-
ple is the extra variable (prefixes are omitted). The following
Example 1. Here we import the ontology ABox together with corresponds to query − sensor − config:
the scripts of seven different queries. This will allow us to re-
fer to the corresponding queries in Example 4. The file names SELECT ?Sensor ?Info ?Config ?Cost
could be substituted by URLs:
WHERE {
(:include ?Sensor rdf:type sensing:SmartHomeSensor.
(ecare-ontology-data "./ecare-data.rdf") ?sensingProcess dul:implementedBy ?Sensor.
(query-sensor-none "./queries/ ?sensingProcess rdf:type sensing:
query-sensor-none.sparql") SensingProcess.
(query-sensor-config "./queries/ ?sensingProcess dul:hasConstituent ?Info.
query-sensor-config.sparql") ?Info rdf:type foi:
(query-sensor-location "./queries/ SmartHomeFeatureOfInterest.
query-sensor-location.sparql") ?sensingProcess sensing:hasCost ?Cost.
(query-sensor-targeting "./queries/ ?sensingProcess sensing:
query-sensor-targeting.sparql") requiresConfiguration ?Config.
(query-link-2 "./queries/query-link-2. ?sensingProcess sensing:
sparql") requiresLocation none.
25
Tenth International Workshop Modelling and Reasoning in Context (MRC) – 13.07.2018 – Stockholm, Sweden
?sensingProcess sensing:requiresTargeting sons to avoid including SPARQL queries in the planner’s do-
none. } main, not least the fact that adding another language fragment
to the domain definition language can affect its readability.
Once imported, queries like the ones shown above can be We therefore investigate how queries to an ontology can be
used by operators to decide when they are applicable. expressed directly in the language of the planner, in the form
Example 4. The operator below uses the query shown in of ontology expressions. These expressions are converted to
Example 2 to determine all sensors that can provide infor- a SPARQL query, whose answers are then substituted to the
mation without special requirements. Notice that the vari- relevant variables used by the planner. The main difference
ables used by this operator appear in various other places to the approach presented in the previous section is in the
in the operators definition. If we assume that the data in the inclusion of triples in the domain definition language of the
ontology does not change, we can replace the operator by planner. As a result, we can substitute into these triples based
a set of operators using every combination of the variables on the outcome of other reasoning processes. This could be
?Sensor , ?Info, and ?Cost that are returned by the query used, for instance, to determine which relation to use in a
query − sensor − none. triple.
In comparison, SPARQL queries in the previous approach
(:operator
are static. As we will see below, the advantage in using
(infer-sensor ?Sensor - sensor ?Info -
concept ?Cost - cost) SPARQL directly is that we can rely on its full set of fea-
(:preconditions ) tures. Dynamically generated queries are limited to triples
(:effects we require to be present and triples we do not allow. When
(?E1 (inferring ?Info)) the planner solves a set of ontology constraints, it will gener-
(?E2 (sensor-state ?Sensor) on) ) ate a SPARQL query, run i, and provide all possible answers.
(:constraints The last part uses the same mechanism as the previous ap-
(:temporal proach. In the following we will look at a series of examples
(equals ?THIS ?E1) to illustrate the approach.
(during ?THIS ?E2 [1 inf] [1 inf]) )
(:sparql Example 6. First we include an ontology from a file. Then,
(query-sensor-none ecare-ontology-data ? we define a set of prefixes (essentially a way to short-
Sensor ?Info ?Cost) ) hand queries). Finally, we provide an operator that uses
(:math (eval-int (intervalCost ?E1) (mult ( a set of ontology expressions to decide to which situations
sub (EET ?E1) (LST ?E1)) ?cost))) it can be applied. We require the sensor object to be of
(:cost (add link-cost (intervalCost ?E1))) type smh sensing:SmartHomeSensor. The sensing process
) ) ?Sensing has to be of type smh sensing:SensingProcess. The
sensor has to implement the sensing process.
Since we can use any existing constraint type as part of
an interaction constraint, the following examples shows how (:initial−context
we can use ICs to create domains for the temporal configura- (:include (sensor-ont "./SmartHome_ORU_Home1.
tion planning approach presented by Köckemann and Karls- owl"))
son [2017]. (:ontology sensor-ont
(prefix rdf "")
based on SPARQL queries. ICs can be preprocessed in the (prefix owl "")
replaced by one for every allowed combination for sensor, ...
information, and cost. The resulting IC ’s condition is always (prefix ssn "")
(prefix dul "") ))
(add-basic-sensor-link ?Sensor - sensor ?
Info - concept ?Cost - cost) (:operator (sense-basic ?Sensor ?Sensing)
(:condition (:signature sensor sensing)
(:sparql (:preconditions
(query-sensor-none ecare-ontology-data ? (?P (available ?Sensor)) )
Sensor ?Info ?Cost) ) ) (:effects
(:resolver (:configuration-planning (link ? (?E (sensing ?Sensing)) )
Info {?Sensor} ?Cost)) ) ) (:constraints
(:temporal
(during ?E ?P [1 inf] [1 inf]) )
5 Dynamically Generate SPARQL using (:ontology sensor-ont
Triples (triple ?Sensor "rdf:type" "
smh_sensing:SmartHomeSensor")
As shown above, the planner can make use of SPARQL to (triple ?Sensing "rdf:type" "
“natively” query an ontology. There are, however, good rea- smh_sensing:SensingProcess")
26
Tenth International Workshop Modelling and Reasoning in Context (MRC) – 13.07.2018 – Stockholm, Sweden
(triple ?Sensing "ssn:implementedBy" ? (:constraints
Sensor) ))) (:temporal
(during ?E ?P [1 inf] [1 inf]))
The advantage of this approach is in its integration into (:ontology sensor-ont
the domain definition language. This makes it possible to (triple ?Sensor "rdf:type" "
dynamically decide, for instance, which relations are used in smh_sensing:SmartHomeSensor")
(triple ?Sensing "ssn:implementedBy" ?
a query by using variables to represent them. Sometimes we
Sensor)
need negative relations to express that a certain property does (triple ?Sensing "rdf:type" "
not hold in the ontology. Consider the following examples smh_sensing:SensingProcess")
(omitting initial context). (not ?Config "rdf:type" "
Example 7. Again we have an operator for using a sensor to smh_sensing:SensorConfiguration")
provide a sensing process. This time we also consider that the (not ?Config "dul:isSettingFor" ?Sensor
)
sensor needs a specific configuration (e.g., settings its sam-
(not ?Config "dul:isSettingFor" ?
pling rate). The main difference to Example 6 is the extra Sensing) )))
effect that assigns the sensor configuration to a temporal in-
terval and the two extra triples that relate the configuration One issue with the approach presented in this section is that
to sensor and sensing process. This allows the planner to as- it lacks the modeling freedom offered by writing queries in
sure (via scheduling) that each sensor only uses a single con- SPARQL directly. We might, for instance, want to count the
figuration at any given time. The presence of this operator, number of information inputs needed to compute some new
however, creates a problem with Example 6. The operator in information. The following query is an example that counts
Example 6 will allow every operator sense − config allows how many events are required as preconditions for a complex
because its triples are a subset. event.
(:operator (sense-config ?Sensor ?Sensing) SELECT ?event (COUNT(?event) AS ?
(:signature sensor sensing) numberOfPreconditions)
(:preconditions WHERE {
(?P (available ?Sensor))) ?event rdf:type event:ComplexEvent.
(:effects ?event dul:hasPrecondition ?ec.
(?E1 (sensing ?Sensing)) ?ec rdf:type event:EventCondition.
(?E2 (config ?Sensor) ?Config)) } Group by ?event
(:constraints
(:temporal In such cases we can revert to the approach presented in
(during ?E1 ?P [1 inf] [1 inf]) the previous section. In fact, the constraint-based planner can
(equals ?E1 ?E2) ) easily use both approaches in a single domain.
(:ontology sensor-ont
(triple ?Sensor "rdf:type" "
smh_sensing:SmartHomeSensor") 6 Evaluation
(triple ?Sensing "rdf:type" " In this section we provide a preliminary evaluation of our sec-
smh_sensing:SensingProcess")
ond approach. We use the SmartEnv ontology with an instan-
(triple ?Sensing "ssn:implementedBy" ?
Sensor) tiation of a real home. For this we provide a domain defini-
(triple ?Sensor "dul:hasSetting" ?Config tion for the planner that uses ontology expressions presented
) in the previous section to compile a concrete set of opera-
(triple ?Config "rdf:type" " tors and to populate type domains. We query the ontology
smh_sensing:SensorConfiguration")))) to create operators (as shown in the previous section) and to
populate the domains of the types used by the planner. We
What we really want in the sense − basic operator is to then use the number of domain and operator expressions in
get all the cases sensors and sensing processes that do not re- the domain before and after this step as an indicator for the
quire a specific configuration to be used. This is where neg- amount of information that was taken from the ontology.
ative triple come in. The following example is a version of Example 9. The following example uses an Interaction Con-
sense − basic that works as intended. straint (IC ) to add every sensor known to the ontology to the
Example 8. The operator below is identical with Example 6 domain named sensor.
except for including three ”not” triples that impose that there
(:ic (add-sensors-to-domain ?Sensor)
is no sensor configuration specified for a given sensor and (:condition (:ontology sensor-ont (triple ?Sensor
sensing process combination. "rdf:type" "
(:operator (sense-basic ?Sensor ?Sensing) smh_sensing:SmartHomeSensor")))
(:signature sensor sensing) (:resolver (:domain (enum sensor { ?Sensor }) )
(:preconditions ))
(?P (available ?Sensor)))
(:effects The pattern shown in Example 9 is used for all types in the
(?E (sensing ?Sensing))) domain (sensors, sensing processes, features of interest, and
27
Tenth International Workshop Modelling and Reasoning in Context (MRC) – 13.07.2018 – Stockholm, Sweden
Before After domain. They can be added easily, however, in the same way
Operators 4 62 in which we added configurations.
Domain constraints 4 80 For now the presented approach provides operators only
from existing structures. That is the operators themselves ex-
Table 1: Number of operators and domain constraints before ist, but information from the ontology instantiates them. An
and after information was fetched from the ontology. interesting direction for future work is to dynamically gener-
ate structures of operators based on the same reasoning. As
an example, consider configuration planning operators that
situation, see Section 1.1). This technique is very convenient require task planning for different reasons: A sensor may
since it maintains a strong connection to the ontology by im- need to be pointed at an object and/or in the same location
porting its terms. as the object and/or be in a specific configuration to provide
To measure how much redundancy is avoided we compare the required information. These three things could be mod-
the size of the planner’s domain before and after the ontology eled as preconditions. In the current approach, however, we
is queried. Specifically, we will measure how many operators would need to supply 8 template operators for all different
we have before and after and how many domain constraints. combinations of preconditions. Adding another type of task
The four initial domain constraints simply define the types requirement would further multiply the number of templates
with empty domains. The four planning operators include the needed. This problem could be solved by dynamically de-
ones from Examples 7 and 8 and two operators that extract ciding when to add a precondition to an operator. A general
a feature of interest form a sensing process and a situation mechanism for this type of problem would be very interesting
from a feature of interest, in turn. The resulting domain defi- for constraint-based planning in general.
nition is completely independent of the concrete smart home
Acknowledgments:
environment at hand.
The work is supported by the project E-care@home funded
Table 1 shows the resulting numbers of operators and do-
by the Swedish Knowledge Foundation 2015-2019.
main constraints. While we could avoid writing down all
62 operators by other means (e.g., Prolog rules or precondi-
tions), we would have to repeat this effort for every instance References
of a smart home environment instead of relying on existing Marjan Alirezaie, Jennifer Renoux, Uwe Köckemann, An-
knowledge. Domain constraints would be completely redun- nica Kristoffersson, Lars Karlsson, Eva Blomqvist, Nico-
dant wrt. the ontology as the usual approach is to list all ele- las Tsiftes, Thiemo Voigt, and Amy Loutfi. An Ontology-
ments of a domain in the planner’s domain definition directly. based Context-aware System for Smart Homes: E-
All it takes to change to another environment is to replace the care@home. Sensors, 17(7), 2017.
file containing the ontology instances (see include in Example Marjan Alirezaie, Karl Hammar, and Eva Blomqvist.
6). Smartenv as a network of ontology patterns. Semantic Web
Journal (SWJ), 2018.
7 Conclusion J.F. Allen. Towards a general theory of action and time. Arti-
ficial Intelligence, 23:123–154, 1984.
We proposed a solution to re-use information from an ontol-
ogy to dynamically assemble a configuration planning prob- Jeremy J. Carroll, Ian Dickinson, Chris Dollin, Dave
lem in order to avoid redundancy in various parts of the E- Reynolds, Andy Seaborne, and Kevin Wilkinson. Jena:
Care@Home system. For this, we presented two alternative Implementing the semantic web recommendations. In Pro-
solutions for integrating ontologies into a constraint-based ceedings of the 13th International World Wide Web Con-
planner. In the first approach we include SPARQL queries ference on Alternate Track Papers &Amp; Posters, WWW
into the planner’s domain definition language. In the second Alt. ’04, pages 74–83, New York, NY, USA, 2004. ACM.
one we rely on triples and prefixes. The first approach al- Maurizio Di Rocco, Federico Pecora, and Alessandro Saf-
lows more flexibility when it comes to queries since we can fiotti. When robots are late: Configuration planning for
write SPARQL directly we have access to all it’s features. multiple robots with dynamic goals. In Proc. of the
The second approach automatically generates SPARQL. It is IEEE/RSJ Int. Conf. on Intelligent Robots and Systems
less flexible in that way but allows us to dynamically sub- (IROS), pages 9515–5922. IEEE, 2013.
stitute the results of other solvers used by the planner into a C. Freksa. Temporal Reasoning Based on Semi-Intervals. Ar-
query. In this way we could, for instance, dynamically decide tificial Intelligence, 54:199–227, 1992.
which relation is of interest for a specific query depending on
the context. Cipriano Galindo and Alessandro Saffiotti. Inferring robot
Our evaluation gives a first impression on the way in which goals from violations of semantic knowledge. Robot. Au-
integrating ontologies can avoid redundancies in the domain ton. Syst., 61(10):1131–1143, October 2013.
definition of the planner. Our current domain does not yet M Ghallab, A Howe, C Knoblock, D McDermott, A Ram,
cover aspects such as sensors that require targeting or mobile M Veloso, D Weld, and D Wilkins. PDDL - The Plan-
sensors (or robots). Since the evaluation presented here is ning Domain Definition Language. Technical report, CVC
based on a real smart home setup, we simply do not have TR-98-003/DCS TR-1165, Yale Center for Computational
any mobile sensors or sensors which require targeting in our Vision and Control, 1998.
28
Tenth International Workshop Modelling and Reasoning in Context (MRC) – 13.07.2018 – Stockholm, Sweden
Uwe Köckemann and Lars Karlsson. Configuration planning
with temporal constraints. In Proceedings of the 31st Con-
ference on Artificial Intelligence (AAAI), 2017.
Uwe Köckemann, Federico Pecora, and Lars Karlsson.
Grandpa Hates Robots — Interaction Constraints for Plan-
ning in Inhabited Environments. In Proceedings of the 28th
Conference on Artificial Intelligence (AAAI), 2014.
Uwe Köckemann. Constraint-based Methods for Human-
aware Planning. PhD thesis, Örebro university, 2016.
Robert Lundh. Robots that Help Each Other: Self-
Configuration of Distributed Robot Systems. PhD the-
sis, Örebro University, School of Science and Technology,
2009.
Fiona McNeill, Alan Bundy, and Chris Walton. Planning
from rich ontologies through translation between repre-
sentations. In Proceedings of the 15th International Con-
ference on Automated Planning and Scheduling (ICAPS),
2005.
I. Meiri. Combining Qualitative and Quantitative Constraints
in Temporal Reasoning. In Artificial Intelligence, pages
260–267, 1996.
Dana S. Nau, Tsz-Chiu Au, Okhtay Ilghami, Ugur Kuter,
J. William Murdock, Dan Wu, and Fusun Yaman. SHOP2:
An HTN planning system. Journal of Artificial Intelligence
Research, 20:379–404, 2003.
Eric Prud’hommeaux and Andy Seaborne. SPARQL Query
Language for RDF. W3C Recommendation, January 2008.
http://www.w3.org/TR/rdf-sparql-query/.
Lia Susana d. C. Silva-Lopez, Mathias Broxvall, Amy Loutfi,
and Lars Karlsson. Towards configuration planning with
partially ordered preferences: Representation and results.
KI, 29(2):173–183, 2015.
29