<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Learning Static Constraints for Domain Modeling from Training Plans</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Rabia Jilani</string-name>
          <email>rabia.jilani@hud.ac.uk</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>University of Hudders eld</institution>
          ,
          <addr-line>Hudders eld</addr-line>
          <country country="UK">UK</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>Intelligent agents solving problems in the real-world require domain models containing widespread knowledge of the world. Synthesising operator descriptions and domain speci c constraints by hand for AI planning domain models is time-intense, error-prone and challenging. To alleviate this, automatic domain model acquisition techniques have been introduced. For example, the LOCM system requires as input some plan traces only, and is e ectively able to automatically encode the dynamic part of the domain model. However, the static part of the domain, i.e., the underlying structure of the domain that can not be dynamically changed, but that a ects the way in which actions can be performed is usually missed, since it can hardly be derived by observing transitions only. In this paper we introduce ASCoL, a tool that exploits graph analysis for automatically identifying static relations, in order to enhance planning domain models. ASCoL has been evaluated on domain models generated by LOCM for the international planning competition, and has been shown to be e ective.</p>
      </abstract>
      <kwd-group>
        <kwd>Automated Planning</kwd>
        <kwd>Knowledge Engineering</kwd>
        <kwd>Domain Model Acquisition</kwd>
        <kwd>Domain Constraints</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>Intelligent agents that solve problems in the real-world use models containing
vast knowledge of that world to plan their actions. Designing complete domain
models and gathering application knowledge is crucial not only for the e ciency
of intelligent planning systems, but also for the correctness of the resulting
action plans generated by intelligent agents. Creating such models is a di cult
task, that is usually done manually; it requires planning experts and it is
timeconsuming and error-prone.</p>
      <p>In this paper we present ASCoL, (Automated Static Constraint Learner), a
tool that can e ectively identify static knowledge by considering plan traces as
the only source of information.</p>
      <p>In the following sections, we rst provide a general background of the areas
and concepts included in this research which is followed by the research question,
problem, contribution, the developed system and system evaluation. The paper
is concluded with a discussion of some future goals.</p>
    </sec>
    <sec id="sec-2">
      <title>Background</title>
      <sec id="sec-2-1">
        <title>AI Planning</title>
        <p>The term Planning refers to the process of reasoning about actions and then
organizing those actions to accomplish a desired goal. It gives a full scheme
for doing or accomplishing something. In Arti cial Intelligence (AI) terms this
scheme is known as a Plan. Plan generation is considered an important
property of intelligent behaviour. AI Planning has been a part of study in arti cial
intelligence for over two decades.</p>
        <p>
          Classical planning [
          <xref ref-type="bibr" rid="ref2">2</xref>
          ] deals with nding a (partially or totally ordered)
sequence of actions transforming the static, deterministic and fully observable
environment from some initial state to a desired goal state. In the classical
representation atoms are predicates. States are de ned as sets of ground (positive)
atoms. A planning operator op = (name(o); pre(o); ef f (o); ef f +(o)) is
specied such that name(o) = op name(x1; : : : ; xk) (op name is a unique operator
name and x1; : : : xk are variable symbols (arguments of certain types)
appearing in the operator), pre(o) is a set of predicates representing the operator's
preconditions, ef f (o) and ef f +(o) are sets of predicates representing the
operator's negative and positive e ects. Actions are ground instances of planning
operators. An action A = (pre(A); ef f (A); ef f +(A)) is applicable in a state s
if and only if pre(A) s. Application of A in s (if possible) results in a state
(s n ef f (A)) [ ef f +(A).
2.2
        </p>
      </sec>
      <sec id="sec-2-2">
        <title>Knowledge Engineering for AI Planning</title>
        <p>Knowledge Acquisition and Knowledge Engineering (KE) have been signi cant
to Arti cial Intelligence (AI) research since the elds inception. Acquiring
domain knowledge from input training data has attracted much interest in research.</p>
        <p>
          The domain model acquisition problem has mainly been tackled by exploiting
two approaches. On the one hand, knowledge engineering tools for planning
have been introduced over time, for supporting human experts in modelling the
knowledge. Two particular examples are itSIMPLE [
          <xref ref-type="bibr" rid="ref10">10</xref>
          ] and PDDL studio [
          <xref ref-type="bibr" rid="ref8">8</xref>
          ].
Recently, also crowd-sourcing has been exploited for acquiring planning domain
models [
          <xref ref-type="bibr" rid="ref13">13</xref>
          ]. On the other hand, a number of techniques are currently available
for automatic domain model acquisition; they rely on example data for deriving
domain models. For example ARMS [
          <xref ref-type="bibr" rid="ref12">12</xref>
          ], SLAF [
          <xref ref-type="bibr" rid="ref9">9</xref>
          ] and many more. Signi cant
di erences can be found in terms of the quantity and quality of the required
inputs. [
          <xref ref-type="bibr" rid="ref6">6</xref>
          ] presents a brief overview of nine di erent knowledge engineering tools
used in planning and compares these systems on a set of criteria.
2.3
        </p>
      </sec>
      <sec id="sec-2-3">
        <title>The LOCM System</title>
        <p>
          One such knowledge acquisition tool is LOCM (Learning Object-Centred
Models) [
          <xref ref-type="bibr" rid="ref1">1</xref>
          ] that carries out automated generation of a planning domain model from
a set of example training plans. Each plan is a sequence of actions, where each
action in the plan is stated as a name and a list of objects that are a ected or
are needed during the actions execution. Di erent plan traces are generated by
observing the behaviour of an agent in its environment.
        </p>
        <p>
          The LOCM method is unique in that it requires no prior knowledge and can
learn action schema without requiring any additional information about
predicates or initial, goal or intermediate state descriptions of objects for the example
action sequences. The exception to this is that LOCM e ectively determines the
dynamic part of the domain model of objects but not the static part i.e., the
underlying structure of the domain that can not be dynamically changed, but
that a ects the way in which actions can be performed.
1. Dynamic Knowledge: a set of parametrised operator schema representing
generic actions and resulting changes in the domain under study.
2. Static Knowledge: relationships/constraints that are implicit in the set of
operators and are not directly expressed but essentially are present while
de ning a domain model. These can be seen to appear in the preconditions
of operators only and not in the e ects. In simple words static facts never
change in the world. According to Wickler [
          <xref ref-type="bibr" rid="ref11">11</xref>
          ], let O = fO1; O2; : : : ; Ong
be a set of operators and let P r = fP r1; P r2; : : : ; P rng be a set of all the
predicate symbols that occur in these operators. A predicate P ri 2 P r is
uent i there is an operator Oj 2 O that has an e ect that changes the
truth of the predicate P ri. Otherwise the predicate is static.
        </p>
        <p>In many domains, there are static relationships or constraints which restrict
the values of variables in domain modelling. For example learning the map of
roads in transport domains or the xed card stacking rules between speci c cards
in card-games domains, that never change with the execution of actions.
3</p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>The Research</title>
      <p>Our work is aimed at automating the acquisition of static constraints. We aim
to enhance the LOCM system to learn complete domain models including the
knowledge of static constraints by using sequences of plans as the only input
training data. The static knowledge is not explicitly captured in the plan traces
and so it is a big challenge to learn such static constraints from them.</p>
      <p>We introduced ASCoL, an e cient and e ective tool for identifying static
knowledge missed by domain models automatically acquired.</p>
      <p>The proposed approach generates a directed graph for each pair of
sametype arguments of operators and, by analysing linearity properties of the graphs,
identi es relevant relations between arguments. Remarkably, the contributions of
ASCoL, as demonstrated by our large experimental analysis, are: (i) the ability
to identify di erent types of static relations, by exploiting graph analysis; (ii)
ASCoL can work with both optimal and suboptimal plan traces; (iii) considering
pairs of same-typed objects allows the identi cation of all the static relations
considered in the benchmark models, and (iv) it can be a useful debugging tool
for improving existing models, which can indicate hidden static relations helpful
for pruning the search space.</p>
      <p>
        A preliminary version of ASCoL has been presented in [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ]; this version was
able to identify inequality constraints only. After further development and a
large experimental analysis, in the recent AI*IA publication [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ], we demonstrate
the ability of ASCoL in nding static relations for enhancing domain models
automatically acquired by LOCM.
3.1
      </p>
      <sec id="sec-3-1">
        <title>The Learning Problem</title>
        <p>We de ne the learning problem that ASCoL addresses as follows. Given the
knowledge about object types, operators and predicates, and a set of plan traces,
how can we automatically identify the static relation predicates that are needed
by operators' preconditions? We base our methodology on the assumption that
plan traces contain tacit knowledge about constraints validation/acquisition.</p>
        <p>Speci cally, a learning problem description is a tuple (P, T), where P is a set
of plan traces and T is a set of types of action arguments in P (taken from the
LOCM learnt domain model). The output for a learning problem is a constraint
repository R that stores all admissible constraints on the arguments of each
action A in plan traces P.
4</p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>The ASCoL Tool</title>
      <p>We now brie y present the ASCoL tool that has been developed for identifying
useful static relations. The process steps can be summarised as follows:
1. Read the partial domain model (induced by LOCM) and the plan traces.
2. Identify, for all operators, all the pairs of arguments involving the same
object types.
3. For each of the pairs, generate a directed graph by considering the objects
involved in the matching actions from the plan traces.
4. Analyse the directed graphs for linearity and extract hidden static relations
between arguments.
5. Run inequality check.
6. Return the extended domain model that includes the identi ed static
relations.</p>
      <p>The main information available for ASCoL comes from the input plan traces.
As a rst control, we remove from the plan traces all the actions that refer to
operators that do not contain at least two arguments of the same type.</p>
      <p>Even though, theoretically, static relations can hold between objects of
different types, they mostly arise between same-typed objects. This is the case in
transport domains, where static relations de ne connections between locations.
Moreover, considering only same-typed object pairs can reduce the
computational time required for identifying relations. It is also worth noting that, in
most of the cases where static relations involve objects of di erent types, this is
due to a non-optimal modelling process. Furthermore, such relations can be
easily identi ed by naively checking the objects involved in actions; whenever some
objects of di erent type always appear together, they are likely to be statically
related.
5</p>
    </sec>
    <sec id="sec-5">
      <title>Experimental Evaluation</title>
      <p>Remarkable results have been achieved in complex domains, with regards to the
number of static relations. We considered fteen di erent domain models, taken
either from IPCs1 or from the FF domain collection (FFd)2.</p>
      <p>
        We selected domains that are encoded using di erent modelling strategies,
and their operators include more than one argument per object type. Table 1
shows the results of the experimental analysis. A detailed interpretation of
results can be found in the recent AI*IA publication. All domains but Gripper,
Logistics and Hanoi, exploit static relations. Input plans of these domains have
been generated by using the Metric-FF planner [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ] on randomly generated
problems, sharing the same objects. ASCoL has been implemented in Java, and run
on a Core 2 Duo/8GB processor. CPU-time usage of the ASCoL is in the range
of 35-320 (ms) for each domain.
      </p>
      <p>Interestingly, we observe that ASCoL is usually able to identify all the static
relations of the considered domains. Moreover, in some domains it is providing
1 http://ipc.icaps-conference.org/
2 https://fai.cs.uni-saarland.de/ho mann/ -domains.html
additional static relations, which are not included in the original domain model.
Remarkably, such additional relations do not reduce the solvability of problems,
but reduce the size of the search space by pruning useless instantiations of
operators.
6</p>
    </sec>
    <sec id="sec-6">
      <title>Conclusion and Future Goals</title>
      <p>
        We are considering several paths for future work. Grant, in [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ], discusses the
limitations of using plan traces as the source of input information. ASCoL faces
similar di culties as the only input source to verify constraints are sequences
of plans. We are also interested in extending our approach for considering static
relations that involve more than two arguments In particular, we aim to extend
the approach for merging graphs of di erent couples of arguments. Finally, we
plan to identify heuristics for extracting useful information also from acyclic
graphs.
      </p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Cresswell</surname>
            ,
            <given-names>S.N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>McCluskey</surname>
            ,
            <given-names>T.L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>West</surname>
            ,
            <given-names>M.M.</given-names>
          </string-name>
          :
          <article-title>Acquiring planning domain models using LOCM</article-title>
          .
          <source>The Knowledge Engineering Review</source>
          <volume>28</volume>
          (
          <issue>02</issue>
          ),
          <volume>195</volume>
          {
          <fpage>213</fpage>
          (
          <year>2013</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Ghallab</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Nau</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Traverso</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          :
          <source>Automated planning: theory &amp; practice</source>
          (
          <year>2004</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Grant</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          :
          <article-title>Identifying Domain Invariants from an Object-Relationship Model</article-title>
          . PlanSIG2010 p.
          <volume>57</volume>
          (
          <year>2010</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Ho</surname>
            <given-names>mann</given-names>
          </string-name>
          , J.:
          <article-title>The Metric-FF Planning System: Translating \Ignoring Delete Lists"</article-title>
          to Numeric
          <source>State Variables</source>
          <volume>20</volume>
          ,
          <issue>291</issue>
          {
          <fpage>341</fpage>
          (
          <year>2003</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Jilani</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Crampton</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kitchin</surname>
            ,
            <given-names>D.E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vallati</surname>
            ,
            <given-names>M.:</given-names>
          </string-name>
          <article-title>ASCoL: Automated acquisition of domain speci c static constraints from plan traces</article-title>
          .
          <source>In: The UK Planning and Scheduling</source>
          Special Interest Group (UK PlanSIG)
          <year>2014</year>
          (
          <year>2014</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Jilani</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Crampton</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kitchin</surname>
            ,
            <given-names>D.E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vallati</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Automated Knowledge Engineering Tools in Planning: State-of-the-art and Future Challenges</article-title>
          . In:
          <article-title>The Knowledge Engineering for Planning and Scheduling workshop</article-title>
          (KEPS) (
          <year>2014</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Jilani</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Crampton</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kitchin</surname>
            ,
            <given-names>D.E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vallati</surname>
            ,
            <given-names>M.:</given-names>
          </string-name>
          <article-title>ASCoL: a tool for improving automatic planning domain model acquisition</article-title>
          .
          <source>In: Proceedings of the 14th Conference of the Italian Association for Arti cial Intelligence (AI*IA</source>
          <year>2015</year>
          )
          <article-title>(</article-title>
          <year>2015</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Plch</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Chomut</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Brom</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bartak</surname>
          </string-name>
          , R.:
          <article-title>Inspect, edit and debug PDDL documents: Simply and e ciently with PDDL studio</article-title>
          .
          <source>System Demonstrations and Exhibits</source>
          at ICAPS pp.
          <volume>15</volume>
          {
          <issue>18</issue>
          (
          <year>2012</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Shahaf</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Amir</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          :
          <article-title>Learning partially observable action schemas</article-title>
          .
          <source>In: Proceedings of the national conference on arti cial intelligence (AAAI)</source>
          (
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Vaquero</surname>
            ,
            <given-names>T.S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Romero</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tonidandel</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Silva</surname>
            ,
            <given-names>J.R.</given-names>
          </string-name>
          :
          <source>itSIMPLE 2</source>
          .
          <article-title>0: An Integrated Tool for Designing Planning Domains</article-title>
          .
          <source>In: Proceedings of the International Conference on Automated Planning and Scheduling (ICAPS)</source>
          . pp.
          <volume>336</volume>
          {
          <issue>343</issue>
          (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Wickler</surname>
          </string-name>
          , G.:
          <article-title>Using planning domain features to facilitate knowledge engineering</article-title>
          .
          <source>KEPS</source>
          <year>2011</year>
          (
          <year>2011</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Yang</surname>
            ,
            <given-names>Q.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wu</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Jiang</surname>
            ,
            <given-names>Y.</given-names>
          </string-name>
          :
          <article-title>Learning action models from plan examples using weighted max-sat</article-title>
          .
          <source>Arti cial Intelligence</source>
          <volume>171</volume>
          (
          <issue>2</issue>
          ),
          <volume>107</volume>
          {
          <fpage>143</fpage>
          (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Zhuo</surname>
            ,
            <given-names>H.H.:</given-names>
          </string-name>
          <article-title>Crowdsourced Action-Model Acquisition for Planning</article-title>
          .
          <source>In: Proceedings of the AAAI Conference on Arti cial Intelligence</source>
          (
          <year>2015</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>