Reviewing Task and Planning Ontologies: An Ontology Engineering

Process

Julita Bermejo-Alonso

UPM Autonomous Systems Laboratory (ASLab) c/Jos

e Guti

errez Abascal, 2, 28006 Madrid, Spain

Keywords:

Task Ontologies, Planning Ontologies, Ontological Engineering, Autonomous Systems.

Abstract:

Bermejo-Alonso and colleagues (Bermejo-Alonso et al., 2018) deﬁne an ontology for tasks and planning in

the autonomous system domain. It focuses on an emergency scenario for Unmanned Ground Vehicles (UGVs)

or Unmanned Aerial Vehicles (UAVs). In this context, it is necessary to deﬁne how the autonomous system

will act, detailing how the actions should be done to achieve system goals. The planning process starts with

detailing the planning domain knowledge: the initial state, the goals, the actors, the resources, etc. This domain

knowledge is then fed into a planner that, if a solution exists, will produce a plan or a set of plans to be used

by the robotic system. Ontologies are a useful way to provide this domain knowledge and can be used to

characterise the planning domain knowledge. However, there is a number of available ontologies for planning,

being unclear which one is best for autonomous systems. This paper presents a review of existing task and

planning vocabularies, taxonomies and ontologies, as a necessary ﬁrst step in an ontology engineering process

that addressed the autonomous system planning needs. This paper describes the analised ontologies, their

main features, and how the process to integrate them was carried out.

1 INTRODUCTION

To solve a problem, we would need two kinds of

knowledge: the domain knowledge and the problem–

solving knowledge (Chandrasekaran et al., 1998).

If this problem relates to planning, the knowledge

about the domain represents the objects, states, cau-

ses of change states, tasks, effects, etc. The problem–

solving knowledge would represent the goal, the dom-

ain data, the problem–solving state, the methods and

algorithms, etc. The challenge is how to integrate

the planning algorithms and methods (i.e. problem–

solving knowledge) with a rich representation of plan-

ning and task knowledge in terms of e.g. plans, tasks,

actions and events (i.e. domain–speciﬁc knowledge)

(Gil, 2005). The idea would be to provide the planner

a consistent representation of the complete domain to

work with for any individual planning problem (Har-

tanto and Hertzberg, 2009).

Deﬁning the different elements involved in a plan-

ning problem tends to be a time–consuming task,

since it requires to detail all the elements involved

in the planning process, each time the planning pro-

blem is approached. It would be a key element not

only that the knowledge about processes and activi-

ties could be shared among the stakeholders, but also

that this knowledge could be reused from planning to

planning problem.

An ontology that provides the concepts and rela-

tionships of the domain can ease the planning pro-

cess. Firstly, ontologies can be used to characterise

and share the planning domain knowledge, as some

kind of knowledge base. They represent an approach

to enable richer plan representations, as well as kno-

wledge reuse across planning applications (Gil and

Blythe, 2000). Secondly, ontologies are the core ba-

sed on which the planning reasoning mechanisms do

produce the plan (Moreno et al., 2000).

However, there is not a unique, agreed view on

a planning ontology. This is the problem we faced

when attempting to ﬁnd an existing ontology as back-

bone for our particular planning problem for an auto-

nomous system in an emergency scenario. This pa-

per describes the review process and not the resulting

ontology that has been described elsewhere. The re-

view process analysed and compared existing vocabu-

laries and ontologies, to evaluate their possible re-use

or their integrability into a single ontology. The re-

sulting ontology would become a reusable component

integrated in the Ontology for Autonomous Systems

(OASys) (Bermejo-Alonso et al., 2011), (Bermejo-

Alonso et al., 2013).

Bermejo-Alonso, J.

Reviewing Task and Planning Ontologies: An Ontology Engineering Process.

DOI: 10.5220/0006922401830190

In Proceedings of the 10th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (IC3K 2018) - Volume 2: KEOD, pages 183-190

ISBN: 978-989-758-330-8

183

The paper is organised as follows: Section 2 re-

views the different ontologies found in the literature.

Section 3 summarises the performed ontological en-

gineering process. Finally, Section 4 provides some

concluding remarks, as well as future lines of rese-

arch.

2 A SUMMARY OF PLANNNING

ONTOLOGIES

This sections summarises the main features of the re-

viewed ontologies. They are classiﬁed based upon

the formalisation mechanism or language used in their

deﬁnition.

2.1 Natural Language Task Ontologies,

Vocabularies and Taxonomies

Natural language was the ﬁrst approach to develop

vocabularies, taxonomies and ontologies for the plan-

ning domain. Sometimes, the conceptualisation fo-

cuses on tasks only. Other times, the ontologies also

provide additional concepts to characterise the goals,

the actions, and plan features.

An initial attempt to provide a planning ontology

in natural language is proposed in (Valente, 1995)

with a set of concepts or vocabulary at knowledge-

level to compare different planning approaches exis-

ting at that time. They deﬁne the kind of knowledge

involved in the planning task, specifying the dynamic

and static roles involved. The dynamic role refers to

the plan as the goal of the planning task. It will be

equivalent to the problem–solving knowledge. The

static roles relate to the plan model consisting of the

world description and the plan description. Concepts

are deﬁned in natural language, with a medium level

of formalisation. The same approach is further de-

tailed and extended in (Benjamins et al., 1996) but

with an even lower level of formalisation.

To standardise process and plan interchanges, ot-

her natural language ontology is proposed in (Tate,

1996), (Tate, 1998). The ontology is structured as dif-

ferent elements: meta-ontology, top level ontology, li-

brary of shared ontological elements and detailed on-

tology section. The concept deﬁnitions includes terms

such as plan, agent, constraint , environment, and is-

sue. Strictly speaking, it consist more of a dictionary

or taxonomy of plan related concepts than a proper

ontology. Some relations are verbally expressed bet-

ween the concepts Agent and Constraint, but no other

elements required in an ontology, such as axioms, are

provided.

An ontology for a problem solver is described in

(Chandrasekaran et al., 1998), considering two diffe-

rent levels of ontologies. The ﬁrst one relates to the

domain knowledge. The second–level one to the met-

hods and algorithms to be used in the planning pro-

cess. As part of the ﬁrst–level one, the Domain Fac-

tual Knowledge (objects, properties, relations, classes

and subclasses, states, processes, events, and parts),

the Problem Solving Goal (world description), or the

Problem State components (goals, subgoals, require-

ments as preconditions, etc). Within the second–level

ontology, a Control Ontology where tasks are charac-

terised as sequential, conditional, iteration, and recur-

sion. Despite of being called ontologies, the actual

descriptions do not sum up. A series of concepts are

considered and merely deﬁned.

A comprehensive effort to conceptualise the plan-

ning process is the PLANET ontology (Gil and

Blythe, 2000), where different planning related con-

cepts and relationships are provided in natural lan-

guage. The notion of a plan is represented using a se-

ries of concepts: initial-planning-context, goals, acti-

ons, tasks, and choice-points. The initial-planning-

context consists of an initial state, goal description,

and external constraints and a resulting plan is repre-

sented as a set of commitments to actions taken by an

agent to achieve the speciﬁed goals. The goals des-

cribe what needs to be achieved when developing a

plan. A solution plan is validated against completion,

consistency, feasibility, and justiﬁed criteria. The on-

tology does not include traditional planning elements

related to actors or agents, locations, time and resour-

ces. Neither the evaluation of plans according to a

criterion.

The viewpoint of planning consisting of dynamic

and static roles deﬁned in (Valente, 1995) is reused

and extended in (Rajhpathak and Motta, 2004). In

this case, the authors provide a task ontology in terms

of the initial world state, the goal to be achieved with

the planning process, the plan tasks, the actions, the

agents, the constraints, the preferences as soft con-

straints, and the evaluation through a cost function.

The ontology is aimed at representing a generic plan-

ning task ontology, not related to a particular planning

paradigm, speciﬁc domain or application. It is forma-

lised at a high level, with a precise and comprehen-

sive description of planning related terms for the plan-

ning problem. However, it uses the Operational Con-

ceptual Modelling Language (OCML) (Motta, 1997)

which was used during some years but lacks an upda-

ted version.

A recent effort to characterise a Task Ontology

within the robotics domain is provided by (Balakir-

sky et al., 2017). The authors propose doing task

KEOD 2018 - 10th International Conference on Knowledge Engineering and Ontology Development

184

characterisation in terms of different task dimensions

(description, property, implementation, and context)

to suitably organise the ontological elements. These

deﬁnitions are an initial step towards the ontological

engineering of a Robot Task Representation ontology

to be standardised by IEEE. The dimensions appro-

ach is a good mechanisms to approach the different

ontology perspectives.

2.2 Description Logics based Ontologies

Other ontologies have been formalised using Des-

cription Logics (DL) (Baader et al., 2010), a family

of knowledge representation languages used to for-

malise the knowledge of an application domain in a

structured manner. There are several efforts to cha-

racterise or analyse the planning knowledge from a

DL perspective, as reviewed in (Gil, 2005). Gene-

rally speaking, these ontologies focused on the dom-

ain representation only, as taxonomies of objects in

the domain, action, plan, and goals. Procedural or

problem–solving knowledge is rarely considered in

these ontologies. Using DL allows to organise the

class description in a taxonomic hierarchy, which is

useful when a Hierarchical Task Network approach is

used to solve the planning problem. Moreover, DL

reasoners provide two interesting capabilities: class

subsumption and instance recognition. Additional DL

beneﬁts include inference, modularity and tolerance

for inconsistent descriptions. This paper also lists use

of these taxonomies by different planning algorithms

and reasoners.

The DOLCE+DnS Plan Ontology (DPPO) (Gan-

gemi et al., 2005), where DnS stands for the Onto-

logy of Descriptions and Situations, is an ontology

for planning based in DOLCE (Borgo and Masolo,

2010). The intended use of DPPO is to specify plans

at an abstract level, without considering existing re-

sources. The underlying idea is to provide an onto-

logy to specify social or cognitive plans, not so much

computationally executable plans. This example fo-

cuses more on conceptualising the domain object re-

presentation, not so much on procedural knowledge

about how to tackle the planning process. It is worth

mentioning that the different kinds of tasks initially

mentioned in (Chandrasekaran et al., 1998) are de-

tailed and extended in this ontology. This way a task

is not only deﬁned as an activity to perform, but also

on how it should be performed as part of a plan.

Additional research attempted to integrate the

domain knowledge with the planning process. A DL

ontology for the Hierarchical Task Network (HTN)

planning paradigm is described in (S

anchez-Ruiz

et al., 2007). The authors consider that to resolve a

planning problem, two different kinds of knowledge

need to be formalised. On the one hand, the domain

description as the rules of the world where the planner

will act in terms of domain constraints and operators

(this term being understood from a HTN perspective,

not a human-being within the planning problem). On

the other hand, the description of the problem in terms

of the initial state and the goal, where a plan becomes

a sequence of grounded operators to evolve the world

from this initial state to a ﬁnal one that fulﬁls or satis-

ﬁes the expressed goal.

A combination of OWL-DL and HTN planning

is proposed in (Hartanto and Hertzberg, 2009), (Har-

tanto, 2009), where DL is used to express the planning

domain by an ontology. The HTN Planning Ontology

includes a DL formalisation of concepts such as plan-

ning domain, planning problem, HTN method, opera-

tor, and task network. Once the ontology is deﬁned,

it is used by a DL reasoner, to obtain a concrete or

ﬁltered DL model. The overall process was applied to

a mobile robotic navigation domain. However, the re-

search focuses more on the reasoning process phases

as a combination of DL reasoning and a HTN planner,

where the problem–solving knowledge is formalised

as an ontology. No mention is made to the domain

knowledge.

Behnke et al. (Behnke et al., 2015a), (Behnke

et al., 2015b) provide an approach to integrate onto-

logies within the planning problem. Their objective is

twofold. Firstly, to deﬁne an ontology as the central

element of domain knowledge. This ontology con-

sists of two ontologies, one for the planning domain

concepts (O1) and a second one for the domain kno-

wledge (O2). Within O1, different planning-related

concepts in terms of abstract tasks (compound tasks),

subtasks, task hierarchy, reﬁnement or decomposition

method, relations and axioms are deﬁned following

the HTN planning formalism. O2 contains the know-

ledge about the objects and elements in the domain.

The overall ontology is used as the knowledge ele-

ment. The level of formalisation is not high, but too

oriented to the HTN planning paradigm.

2.3 OWL Related Ontologies

Another set of ontologies for task and planning have

made use of OWL (W3C, 2012). In (Sirin et al.,

2004), an OWL reasoner was integrated with an ar-

tiﬁcial intelligence planner. The reasoner was used

to store the world state, answer the planner’s queries

about the evaluation of preconditions, and update the

state when the planner simulated the effects of ope-

rators. An HTN planning system was integrated with

an OWL DL reasoner to explore the use of semantic

Reviewing Task and Planning Ontologies: An Ontology Engineering Process

185

reasoning over the ontology. Some general notions

on concepts supporting the planning process, such as

action, effects, or states are given. No detailed des-

cription of the ontology is provided, with a focus on

the planning mechanisms from a HTN perspective.

Bouillet et al. (Bouillet et al., 2007) propose a

domain-independent, general purpose knowledge en-

gineering and planning framework to construct plan-

ning domains and problems based on OWL ontolo-

gies. The planning model is described as a set of

OWL facts, represented as RDF graphs. Actions are

described as RDF graph transitions. In turn, precon-

ditions, effects as well as planning goals are also spe-

ciﬁed as RDF graph pattern. The framework allows

for the different stakeholders to participate as dom-

ain experts, action speciﬁers or end-users to specify

the ontologies, actions and planning goals respecti-

vely. The justiﬁcation to use OWL ontologies is to

be able to reuse available OWL ontologies with com-

mon and general concepts for planning, such as time

and so.

An OWL ontology is developed for planning dom-

ains using Prot

e, based on the HTN (Hierarchical

Task Network) paradigm in (Freitas et al., 2014). The

ontology provides a set of concepts such as: Domain-

Deﬁnition as the deﬁnition of the planning domain,

Operator to represent the primitive tasks, Method to

decompose compound tasks, Axioms to infer precon-

ditions for methods and operators, Predicates to repre-

sent the preconditions and postconditions of actions

and world state, Goal as method invocations, etc. To

exemplify its use, they instantiated the ontology for a

multi–agent scenario known as gold miners, with one

instance for the operator and the methods. They also

proposed algorithms to convert the OWL planning

ontology to other formalisms such AgentSpeak lan-

guage or to SHOP (an HTN planning system). This

way, they solved both the knowledge representation

(as an ontology) with the problem solving (automated

planning).

Balakirsky (Balakirsky, 2015) proposes an OWL

ontology within agile manufacturing. The ontology is

divided in three parts. The ﬁrst part contains know-

ledge on elements involved in the application: basic

elements such as point to conceptualise 3-D positions

or more complex elements such as parts to deﬁne how

a part is composed of, where is stored, and its name.

The second part contains all the action-related con-

cepts, with a focus on robotic and vision aspects. The

third part of the ontology contains the speciﬁc instan-

ces for this particular domain. The actual contents of

the three ontologies are provided in a graphical way,

with not much level of detail on actual deﬁnitions,

properties or axioms.

3 ONTOLOGICAL

ENGINEERING PROCESS

This section describes the different stages followed

in the ontological engineering of a planning ontology

for our robotic application, by analysing in detail the

reviewed ontologies described in Section 2.

3.1 Graphical Representations

As described in Section 2, different formalisms have

been used in planning ontologies. To establish a com-

parison of them, the ﬁrst step was to represent them

on a common ground. To prevent committing to a par-

ticular implementation language (natural, DL, OWL,

etc) or planning mechanism (HTN, etc), the represen-

tation of the ontologies was made as a diagram where

most important concepts and relationships were de-

tailed. This process was carried out for all the revie-

wed ontologies. For the sake of space in this paper,

partial examples are provided in Fig. 1, Fig. 2, and

Fig. 3.

WorldDescription

usedIn

PlanModel

PlanDescription

consistsOf

performs

Actor

Planning

StateDescription

StateChanges

consistsOf

PlanStructure

State

consistsOf

Event

Action

consistsOf

PlanAssessment

consistsOf

PlanComposition

consistsOf

StateChangeData

consistsOf

Constraints

Intended/

DesiredGoal

evaluates

considers

HardConstraint

SoftConstraint

obtains

Plan

InitialState

GoalState

Figure 1: Graphical representation of (Valente, 1995).

The goal was to represent the different planning

vocabularies, taxonomies and ontologies in a com-

mon and straightforward representation. This way, we

could analyse the main concepts and relationships, to

determine if any of them was suitable to be applied to

our particular robotic system application. The analy-

sis of the graphical representations provided different

outcomes.

Firstly, the different vocabularies and ontologies

focused on the main concepts for the planning dom-

ain knowledge, such as plan, task, action, actor, con-

straint, etc, however with different level of detail. The

two main problems were that i) the same term was

used with different purposes and ii) different terms

were used to represent the same concept. Aproaching

the analysis with a graphical representation helped

providing some insights on the main concepts to be

considered as the core of the integrated ontology.

KEOD 2018 - 10th International Conference on Knowledge Engineering and Ontology Development

186

GoalSpeciﬁcationPlanningProblemContext

Capability

PlanTask

(InstantiatedTask)

accomplishes

PlanTaskTemplate

(TaskModel or Tree)

consistsOf

Precondition

speciﬁedBy

has

Task Commitments

PlanTaskDescription

(Operator/

ActionSchema)

describedBy

considers

Ordering

Temporal

Subplan

Plan

InitialState/

WorldState

ExternalConstraints

JustiﬁedPlan

CompletePlan

ConsistentPlan

FeasiblePlan

spanInto

DesiredGoals

speciﬁes

StateBasedGoal

ObjectiveBasedGoal

Objects

Effect

has

PlanningProblem

has

CandidatePlan

becomes

Rejected

Feasible

Selected

Unexplored

consistOf

Commitment

PlanningLevel

has

PlanCommitments

considers

Figure 2: Graphical representation of (Gil and Blythe,

2000).

PlanningTask

Parameter

consistsOf

Precondition

PlanTask

(Operator/

ActionSchema)

considers

PlanModel

InitialWorldState

Constraints

(hard constraint)

Complete

Valid

GoalDescription

HasTimeRange

Postcondition

(effect)

obtains

CandidatePlan

satisﬁes

Preference

(soft

constraint)

AchievedByAction

considers

Action

RequiresAgent

TimeHorizon

CostFunction

achievedBy

Agent

Duration

Precondition

Postcondition

(effect)

has

becomesA

performedwithin

Plan

representedBy

Constraints

SolutionCriterion

has

perfoms

has

consistOf

satisﬁes

Figure 3: Graphical representation of (Rajhpathak and

Motta, 2004).

However, it was clear that further work was nee-

ded to establish commonalities among the different

ontologies. Not so much on the terms themselves, but

the underlying ontological conceptualisations.

3.2 Tabular Representation

As a ﬁrst step to reuse and integrate the ontological

contents, the different terms from the vocabularies,

taxonomies and ontologies were represented in an in-

termediate tabular form. Some partial views of the

tabular representation for the same graphical repre-

sentation in Section 3.1 are shown in Fig. 5, Fig. 6,

and Fig. 7.

These tables collected the deﬁnitions of the diffe-

rent terms, either explicitly provided in the original

paper or extracted from its text. The terms were furt-

her classiﬁed as concepts (C), attributes (A), or relati-

onships (R).

The ontological contents of these tables were later

divided and classiﬁed according to different dimensi-

ons as described in Section 3.3.

!"#$

%&'('&$%

)"*+'+!+('

!&,"

,-./$012-

!"#$%#%&'#(%)*%#(+%,"#$%)*%-#+.%/01%2$%3/(*)*$*%/0%$".%

!/4'+5.*34)&$)/( #(+%$".%

6'#(5.*34)&$)/(

304-1)256478970/

8(/,'.+9.%#:/;$%$".%!/4'+%)(%,")3"%$".%6'#(()(9%,)''%$#<.%&'#3.1%2$%3/-&4)*.*%

=$#$.5.*34)&$)/(

#(+%=$#$.7"#(9.

304-1%9.92

>".%=$#$.%/0%$".%!/4'+

%9.92)256478970/

6#4$%/0%

!/4'+5.*34)&$)/(1%8(/,'.+9.%$/%4.&4.*.($%$".%!/4'+=$#$.

%9.92:;./<25

6#4$%/0%

!/4'+5.*34)&$)/(1%8(/,'.+9.%$/%4.&4.*.($%$".%3"#(9.*%)(%$".%!/4'+=$#$.1%

=&.3)0)3#$)/(%/0%$".%.'.-.($*%#%6'#(%)*%3/-&/*.+%/01

,-./

%=>8-./

?/;$)(.*%$"#$%#4.%3/-&/*.+%/0%3/--#(+*%,")3"%#4.%.)$".4%@3$)/(*%/4%/$".4%

=;:&'#(*

,-./)256478970/

8(/,'.+9.%#:/;$%$".%6'#(%$/%:.%9.(.4#$.+1%2$%3/(*)*$*%/0%

6'#(=$4;3$;4. #(+%

6'#(@**.**-.($8(/,'.+9.

,-./%94=69=42

2$%*&.3)0).*%"/,%$".%&#4$*%/0%#%6'#(%*;3"%#*%@3$)/(*%/4%

=;:&'#(* #4.%#**.-:'.+%

$/9.$".41%2$%3/(*)*$*%/0%

6'#(7/-&/*)$)/( #(+%=$#$.7"#(9.5#$#

,-./:0?8057970/

5.*34)&$)/(%/0%$".%&'#(%,)$"%4.*&.3$%$/%"/,%$".%

=$#$.7"#(9.* #4.%#44#(9.+%$/%-#<.%

;&%#%&'#(1

%9.92:;./<2).9.

8(/,'.+9.%#:/;$%$".%?.*/;43.*%A@9.($B%$)-.B%

.$3C%#**)9(.+%$/%=$#$.7"#(9.*1

,-./@55255?2/9A/0B-21<2

D#3$/4*%$"#$%-#<.%#%3.4$#)(%6'#(%A/4%

=;:&'#(C%:.$$.4%$"#$%#(/$".4

Figure 4: Tabular representation of (Valente, 1995).

!"#$

%&'('&$%

)"*+'+!+('

!&,"

,-./$012-

!"#$%#%&'#(%)*%#(+%,"#$%)*%-#+.%/01%2$%3/(*)*$*%/0%$".%

!/4'+5.*34)&$)/( #(+%$".%

6'#(5.*34)&$)/(

304-1)256478970/

8(/,'.+9.%#:/;$%$".%!/4'+%)(%,")3"%$".%6'#(()(9%,)''%$#<.%&'#3.1%2$%3/-&4)*.*%

=$#$.5.*34)&$)/(

#(+%=$#$.7"#(9.

304-1%9.92

>".%=$#$.%/0%$".%!/4'+

%9.92)256478970/

6#4$%/0%

!/4'+5.*34)&$)/(1%8(/,'.+9.%$/%4.&4.*.($%$".%!/4'+=$#$.

%9.92:;./<25

6#4$%/0%

!/4'+5.*34)&$)/(1%8(/,'.+9.%$/%4.&4.*.($%$".%3"#(9.*%)(%$".%!/4'+=$#$.1%

=&.3)0)3#$)/(%/0%$".%.'.-.($*%#%6'#(%)*%3/-&/*.+%/01

,-./

%=>8-./

?/;$)(.*%$"#$%#4.%3/-&/*.+%/0%3/--#(+*%,")3"%#4.%.)$".4%@3$)/(*%/4%/$".4%

=;:&'#(*

,-./)256478970/

8(/,'.+9.%#:/;$%$".%6'#(%$/%:.%9.(.4#$.+1%2$%3/(*)*$*%/0%

6'#(=$4;3$;4. #(+%

6'#(@**.**-.($8(/,'.+9.

,-./%94=69=42

2$%*&.3)0).*%"/,%$".%&#4$*%/0%#%6'#(%*;3"%#*%@3$)/(*%/4%

=;:&'#(* #4.%#**.-:'.+%

$/9.$".41%2$%3/(*)*$*%/0%

6'#(7/-&/*)$)/( #(+%=$#$.7"#(9.5#$#

,-./:0?8057970/

5.*34)&$)/(%/0%$".%&'#(%,)$"%4.*&.3$%$/%"/,%$".%

=$#$.7"#(9.* #4.%#44#(9.+%$/%-#<.%

;&%#%&'#(1

%9.92:;./<2).9.

8(/,'.+9.%#:/;$%$".%?.*/;43.*%A@9.($B%$)-.B%

.$3C%#**)9(.+%$/%=$#$.7"#(9.*1

,-./@55255?2/9A/0B-21<2

D#3$/4*%$"#$%-#<.%#%3.4$#)(%6'#(%A/4%

=;:&'#(C%:.$$.4%$"#$%#(/$".4

Figure 5: Tabular representation of (Valente, 1995).

!"#$

%&'('&$%

)"*+'+!+('

!&,

,-.//0/,123-4562/7487

!"#$#%&'(#)*"'%++,-.$#/"+'%0/,$'$1*'2&%""#"(23/0&*-

,-.//0/9,123-45

5.*6#7#6'8/%&+9'4/"+$3%#"$+'%":'%++,-.$#/"+'%0/,$'$1*'

;</3&:=>!"#$#%&5$%$*

:21-;%7.74

?/:*&'/7'$1*'@")#3/"-*"$'7/3'A1#61'$1*'2&%"'#+'#"$*":*:

:21-;

@")#3/"-*"$

:21-;+/070.-%7.74

!"#$#%&</3&:5$%$*

B'6*3$%#"'</3&:5$%$*':*+63#.$#/"

)4<014;=2.-

<1%$'#+'$/'0*'%66/-.&#+1*:'#"'$1*'.3/6*++'/7'+/&)#"('$1*'

2&%""#"(23/0&*-

"8741/.-62/<71.0/7

C*+#3%0&*'/3',":*+#3%0&*'.3/.*3$#*+'/3'@77*6$+'/7' 5/&,$#/"+'$/'

$1*'2&%""#"(23/0&*-9' +,61'%+',+*3'%:)#6*'%":'.3*7*3*"6*+

,-./

B'+*$'/7'4/--#$-*"$'/7'B6$#/"+'$%D*"'0E'%"'B(*"$'$/'%61#*)*'

+/-*'+.*6#7#*:'8/%&+F

6./;0;.74,-./

2/$*"$#%&'+/&,$#/"'$/'%'2&%""#"(23/0&*-

>/7104;

4%":#:%$*2&%" $1%$'#+' E*$'$/'0*'*G.&/3*:'/3'$*+$*:

#4?4@74;

H/3'+/-*'3*%+/"9'

4%":#:%$*2&%" $1%$'1%+'0**"'3*I*6$*:'%+'$1*'

.3*7*33*:'/"*

*4.<03-4

4%":#:%$*2&%" $1%$'1%+' 0**"'$3#*:'%":'"/$'3*I*6$*:

%4-4@74;

4%":#:%$*2&%" $1%$'1%+' 0**"'

=2.-%A4@0B0@.702/

B"E$1#"('$1%$'(*$+'%66/-.&#+1*:'0E'%'2&%"9'

5,0.&%" /3'J%+D

%7.74C.<4;=2.-%A4@0B0@.702/

8/%&5.*6#7#6%$#/"

$/'3*.3*+*"$'8/%&+'$1%$'3*7*3'$/'+/-*'

.3*:#6%$*',+*:'$/':*+63#0*'$1*'

</3&:5$%$*

(3?4@70D4C.<4;=2.-%A4@0B0@.72/

8/%&5.*6#7#6%$#/"

$/'3*.3*+*"$')*30K /3'%6$#/"K0%+*:'

*G.3*++#/"+

EF5./#4.;.3-4)4<@10A702/

8/%&5.*6#7#6%$#/"

$/'.3/)#:*'%':*+63#.$#/"'/7'%'8/%&'$/'%"'

@":L+*3

,-./!.<G)4<@10A702/

J%+DC*6/-./+#$#/"

J%+DJ3**

B6$#/"+'/3'/.*3%$#/"+'$1%$'6%"'0*'$%D*"'#"'$1*'

</3&:5$%$*

,-./!.<G

J%+D

B"'#"+$%"$#%$#/"'/7'%'J%+D'%+'#$'%..*%3+'#"'%'2&%"

,-./!.<G!45A-.74

J%+DJ*-.&%$*

B"'B6$#/"'$1%$'6%"'0*'.*37/3-*:'#"'$1*'

</3&:5$%$*

%F37.<G

J%+DC*+63#.$#/" ;%D%'J%+D>

,105070D4,-./!.<G)4<@10A702/

B'.3#-#$#)*'

J%+DJ*-.&%$*

6.A.30-07H

B'8/%&'7/3'A1#61'$1*'J%+D'6%"'0*',+*:

Figure 6: Tabular representation of (Gil and Blythe, 2000).

3.3 Concept Integration

To establish a criterion on how to organise the ontolo-

gical conceptualisations, we considered that the main

component in any planning process is the task. As

such, a task theory enables addressing tasks at class

level through the deﬁnition of tasks, environment, and

their characteristics from a formal viewpoint (Thoris-

son et al., 2016). Being impossible to represent or

characterise all possible tasks, such a theory should

focus on characterising the main features of different

Reviewing Task and Planning Ontologies: An Ontology Engineering Process

187

!"#$

%&'('&$%

)"*+'+!+('

!&,

+-./.0123415%/0/6

!"#$%&'()*+,+#$,+$+"#$-#./00/0.$ &1$+"#$2(,00/0.$2'&3#44

7301

6#4/'#)$%&'()*+,+#$+&$,3"/#7#$+"'&8."$ +"#$2(,00/0.$2'&3#449

,10-!089

:$4#+$&1$2(,0+,4;$<"/3"$42#3/1=$/0+#'>#)/,+#$?&,(4$<"/3"$0##)$+&$-#$

,33&>2(/4"#)$+&$,3"/#7#$+"#$&7#',(($?&,($&1$+"#$@(,00/0.$ !,4;

:;/.3-

:$1/0/+#$4#+$&1$:3+/&04$+&$-#$#A#38+#)$+&$,33&>2(/4"$,$@(,0!,4;

:<6-/

:$4#+$&1$:.#0+4$<"&$,'#$'#42&04/-(#$1&'$,3"/#7/0.$@(,0!,4;4$+"'&8."$+"#$

#A#38+/&0$&1$:3+/&049$:$2#'4&0B$.'&82$&'$#0+/+=$<"/3"$"&()4$,$28'2&4#$,0)$/4$

'#42&04/-(#$1&'$,3"/#7/0.$)/11#'#0+$@(,0!,4;4$+"'&8."$+"#$#A#38+/&0$&1$

:3+/&049

,040=6/64

@&/0+#'$+&$)&>,/0$#0+/+/#4$'#(#7,0+$+&$+"#$@(,00/0.$@'&3#44

!.=6>34.?3-

:$+/>#$</0)&<$ </+"/0$<"/3"$+"#$@(,0$/4$'#C8/'#)$+&$+,;#$2(,3#

@3-8/40.-/

D,')

5&04+',/0+

:$4#+$&1$3&04+',/0+4$0&+$+&$-#$7/&(,+#)$-=$+"#$@(,09$:$@'&2#'+=$+",+$>84+$0&+$

-#$7/&(,+#)$-=$,$7,(/)$*&(8+/&09

,46A646-;68

*&1+$3&04+',/0+

:$4#+$&1$3'/+#'/,$1&'$2,'+/,((=$',0;/0.$3&>2#+/0.$2(,04

@38/*B-;/.3-

:$1803+/&0$<"/3"$2'&7/)#4$,$.(&-,($>#3",0/4>$1&'$3&>2,'/0.$+"#$5&4+$&1$

:(+#'0,+/7#@(,0

%31B/.3-@4./64.3-

:$>,22/0.$1'&>$,$@(,0$+&$E+'8#B$1,(4#F$<"/3"$)#+#'>/0#4$<"#+"#'$,$

5,0)/),+#@(,0$/4$,$*&(8+/&0

,10-(C/.=.?0/.3-

@4./64.3-

:$5'/+#'/&0$+&$3"&&4#$,0$G2+/>,(@(,0$</+"$+"#$(#,4+$5&4+

(C/.=01,10-

:$@(,0$</+"$+"#$(#,4+$5&4+$,33&')/0.$+&$4&>#$#7,(8,+/&0$1803+/&0

,10-$3561

5,0)/),+#

@(,0

:$4#C8#03#$&1$E@(,0!,4;B:.#0+F$2,/'4$<"#'#$+"#$:.#0+$/4$,-(#$+&$#A#38+#$+"#$

:3+/&04$,44&3/,+#)$</+"$+"#$@(,0!,4;

D08,040=6/64

@,',>#+#'$,44&3/,+#)$</+"$,$@(,0!,4;

D08,46;3-5./.3-

5&0)/+/&0$ +&$-#$+'8#$-#1&'#$,$@(,0!,4;$/4$#A#38+#)

D08,38/;3-5./.3-

5&0)/+/&0$ +&$-#$+'8#$,1+#'$,$@(,0!,4;$/4$#A#38+#)

0;D.6E65FG:;/.3-

:3+/&0$+&$-#$#A#38+#)$+&$,3"/#7#$+"#$@(,0!,4;

46HB.468:<6-/

:$@(,0!,4;$/4$,44&3/,+#)$</+"$&0#$&'$>&'#$:.#0+4$+&$,3"/#7#$/+

D08!.=6#0-<6

!"#$!/>#%/0)&<$</+"/0$<"/3"$,$@(,0!,4;$>84+$+,;#$2(,3#9

Figure 7: Tabular representation of (Rajhpathak and Motta,

2004).

task-related concepts: the task itself, the environment

where it takes place, the goals, the effects, and the

agents that perform the task. With this approach, the

tabular representations made for each one of the vo-

cabularies, taxonomies and ontologies considered in

Section 2 were further classiﬁed to characterise diffe-

rent dimensions of the concept of task:

• Task Context: this set of concepts were focused

on the world (aka the environment) and its state.

Considered concepts such WorldInitialState, Wor-

ldDescription, etc.

• Task Description: the concept of task is the cor-

nerstone of the ontology. How the concept of task

has been named and conceptualised was conside-

red within this dimension. A partial view of the

result is shown in Table 1.

Table 1: Some concepts for the Task Description dimension.

!"#$

%&!'!&#

($)*!*+*'!

+&,$

!'+$%

%'-./$

!"#$

%&'

%()*+&',*)-'./+.0/'

*&.1)'

"&2'+1).1)'

*&3+/4")*+&')-")'4+50#'

)-0'"..6*(")*+&'3/+4'+&0'

7)")0'

)+'"&+)-0/8

9+&(0.)

:"6"$*/#$;<=>?

!"#$

%()*5*);

%&'"()*5*);'"#'."/)'+3'"'

@6"&

9+&(0.)

:0-&$0<=>AB

@6"&!"#$

!"#$

%&'*&#)"&)*")*+&'+3'"'

!"#$'"#'*)'"..0"/#'*&'"'

@6"&

9+&(0.)

@6"&'C1#)'"#'"'

./03*D')+'*4.6;'*)'*#'

"'!"#$'."/)'+3'"'

@6"&E',-*(-'60"2#'

)+'+/20/*&F'+/'

)04.+/"6'"#.0()#8

G*6<===

@6"&!"#$

%'#0)'+3'@6"&'!"#$#'

,-*(-'#.0(*3;'

*&)0/402*")0'G+"6#'

,-*(-'&002')+'B0'

"((+4.6*#-02')+'

"(-*050')-0'+50/"66'

G+"6'+3')-0'

@6"&'!"#$

9+&(0.)

H"C)".-"$<==I

• Task Decomposition: different types of tasks were

included, such as CompoundTask to characterise

tasks to be further decomposed, as well as Primiti-

veTask to be used for single tasks. Synonyms were

established from all the analysed ontologies. A

partial view on different task decomposition con-

cepts are shown in Table 2.

Table 2: Some concepts for the Task Decomposition dimen-

sion.

!"#$

%&!'!&#

($)*!*+*'!

+&,$

!'+$%

%'-./$

!"#$#%#&'()*+

,%-$#.()*+

/#$01'()*+

21'$'3%)1()*+

234#35()*+

('"$#3)1()*+

,6*#351'6()*+6%7)%6.)368'6

0'"9-"$'468:6)6*#351'6,5'3%6

;,.%-"

()*+6%7)%6.)33-%68'6

4'.-$0-*)81'

,6()*+6%7)%6.)368'64#"'.%1:6

'>'.?%'468:6%7'6@*'"6

;,5'3%A,.%-"B<=

C-3.'0%

/?8.1)**6-96()*+

D)"#-?*6

)?%7-"*

D)"#-?*6)?%7-"*

E'73+'FGHI8

C-$0-?34()*+

C-$01'>6()*+

,6()*+6%7)%6.)368'6

4'.-$0-*'46#36-%7'"6

/?8()*+*

,8*%").%6()*+6-"67#57

J1'&'16

()*+6%7)%67)*6%-68'6"'9#3'46

#3%-6$-"'6%)35#81'6()*+*K6

8'#356

!"#$#%#&'()*+ -"6-%7'"6

C-$0-?34()*+

C-3.'0%

/?8.1)**6-96()*+

D)"#-?*6

)?%7-"*

E'73+'FGHI8

/?8%)*+

,6()*+6-3'6#*64'.-$0-*'46

#3=

C-3.'0%

E)1)+#"*+:FGHL

• Task Implementation: from our viewpoint, there

is a subtle difference between the concept of Task

and Action. Task is regarded from a conceptual

viewpoint, whereas action will be used in the ac-

tual planning process to assign actors and resour-

ces. In this sense, the implementation concepts

included Precondition or Effect to represent the

conditions to and the result of performing a par-

ticular action. Among this set of concepts, it is

also needed to characterise the Actor that per-

forms the action, to make possible to further dis-

tinguish among the human or the artiﬁcial actors

in the system. Also, preconditions and constraints

are part of this dimension, as they will be used to

determine whether an action can or cannot be per-

formed to fulﬁl a required task. Some concepts

are shown in Table 3, and Table 4.

Table 3: Precondition concepts for the Task Implementation

dimension.

!"#$

%&!'!&#

($)*!*+*'!

+&,$

!'+$%

%'-./$

!"#$%&'()(%&

*+&#$#,,-".+$%&'()(%&+

/%"+-+0-,1

*,+-+$3-,,+%"+-,+-))"(45)#+

%/+0-,16

7(38999

!"#$%&'()(%&

2%&'()(%&+5&'#"+:;($;+-+

!"(<()(=#0-,1

$-&+4#+

->>3($-43#+(&+-+?)-)#

!-")+%/+!"(<()(=#0-,1@+

A#/(&#'+-,+3()#"-3

B#;&1#89CD4

*E(%<

!"#$%&'()(%&,+&%)+

#E>3($()3.+-,,#")#'+(&+);#+

$5""#&)+?)-)#

AF?2*GAHAI+-E(%<+(,+-+

"#,#"=#'+:%"'

J"#()-,89CKL+

89CK4

!"#'($-)#

HE>"#,,(%&+5,#'+)%+

"#>"#,#&)+!"#$%&'()(%&L+

!%,)$%&)(%&

J"#()-,89CKL+

89CK4

!-"-<#)#"

!%(&)#"+)%+'%<-(&+

#&)()(#,+"#3#=-&)+)%+);#+

>3-&&(&M+>"%$#,,

G-N)->;-1899K

• Task Evaluation: an important part of the plan-

ning process is to deﬁne the goal and some evalu-

ation mechanism to choose among feasible plans.

The latter is usually made using some kind of cost

evaluation in terms of resources or time. With this

purpose, concepts such as Goal or CostFunction

were included in the integrated ontology.

KEOD 2018 - 10th International Conference on Knowledge Engineering and Ontology Development

188

Table 4: Constraint concepts for the Task Implementation

dimension.

!"#$

%&!'!&#

($)*!*+*'!

+&,$

!'+$%

%'-./$

!"#$%&'#()"*'(

%&'#()"*'(

,*-*("(*&' ./0*'*'1

(2/

./#*)/.

3)&3/)(*/# &0

(2/

!"#$

%&'5/3(

6","$*)#$789:;

%&'#()"*'(

+'<"##/)(*&'<(2"(<5"'<=/<

/>",?"(/.<@*(2<)/#3/5(<

(&<"<1*>/'<A,"'

!"(/:BBC

%&'#()"*'(

D").%&'#()"*'(

+<#/(<&0<5&'#()"*'(#<'&(<

(&<=/<>*&,"(/.<=7<(2/<

A,"'4<

+<A)&3/)(7<(2"(<-?#(<'&(<

=/<>*&,"(/.<=7<"<>",*.<

E&,?(*&'4

%&'5/3(

+<5&'#()"*'(<5"'<=/<

(2/&)/(*5",F<(/52'*5",F<

/'1*'//)*'1F<#&5*",<

&)<5&1'*(*>/<5&'()&,<

"5(*&'#

G"H("32"$899I

JK(/)'",%&'#()"*'(

L/#*)"=,/<&)<?'./#*)"=,/<

3)&3/)(*/#<&)<J00/5(#<&0<

E&,?(*&'#<(&<(2/<

A,"''*'1A)&=,/-

F<#?52<

"#<?#/)<".>*5/<"'.<

3)/0/)/'5/#

%&'5/3(

M*,8999

%&--*(-/'(

E&-/<$*'.<&0<52&*5/<(&<

=/<("$/'<*'(&<"55&?'(N<+<

%&'#()"*'(<(2/<+1/'(<

/,/5(#<(&<"..<"#<"<3")(*",<

#3/5*0*5"(*&'<&0<"<A,"'

%&'5/3(

GJO+!PQRES<+'<

+1/'(<-"7<P'(/'.F<

L/#*)/F<J'0&)5/<&)<

E7'(2/#*#/<"<

%&--*(-/'(

M*,8999

A)/0/)/'5/

E&0(<5&'#()"*'(

+<#/(<&0<5)*(/)*"<0&)<

3")(*",,7<)"'$*'1<

5&-3/(*'1<3,"'#

%&'5/3(

G"H("32"$899I

For each aspect, related concepts from the ana-

lysed vocabularies and ontologies were grouped, to

identify similarities, becoming synonyms, e.g. sim-

ple tasks are named PrimitiveTask, EndingTask, Sing-

leTask, TerminalTask are used. The underlying con-

ceptualisation was the same, so a single concept Sim-

pleTask was chosen. Names were analysed to use a

meaningful one, e.g. between Agent and Actor, the

second one was chosen to remove the software rela-

ted meaning of agent. Around 175 concepts regarding

task and planning were identiﬁed, deﬁned, grouped,

and analysed for the ﬁnal ontology.

4 CONCLUSIONS

As a result of the review and the ontological engi-

neering process described in former sections, an in-

tegrated ontology to provide a common terminology

and relationships to deﬁne the planning problem in

a high–level and abstract way was obtained. The

ontology rationale, the initial set of concepts inclu-

ded, and its application in an emergency scenario for

a combined UAV/UGV robotic system is detailed in

(Bermejo-Alonso et al., 2018). The ontology is un-

der extension, as additional information needs to be

added.

To provide the ﬂexibility and the autonomy requi-

red in a robotic unmanned system, it will be important

to detail additional aspects for tasks. For example,

concurrency among tasks being performed, or delibe-

ration tasks for deliberation states in the autonomous

system. It is also important to extend the HTN ap-

proach of compound tasks to be decomposed. With

this purpose, a general concept TaskRepresentation

was chosen to expando to other representations, such

as behaviour trees (Colledanchise and Ogren, 2018)

that address reactive behaviour depending on the set

of action decided by the player in a game. Another

example would be the need for deliberation tasks as a

task to represent deliberation states in the autonomous

system.

The ontology obtained as result of the ontological

engineering process described in this paper focused

mainly in the domain knowledge, that is, the concepts

needed to conceptualise a task theory from different

viewpoints (context, implementation, evaluation, etc)

as described in Section 3.3. Nevertheless, as stated

in Section 1, for the planning process is necessary

to consider both this domain knowledge, but also the

problem–solving knowledge. The set of concepts re-

lated to the latter are not yet conceptualised in the

current ontology. Among other elements, future de-

velopment should pay attention to the decomposition

methods for task trees, to behaviour trees handling, or

to other algorithms to obtain the ﬁnal plan according

to the selected cost or evaluation, where actors and

resources are clearly allocated to speciﬁc actions.

We would also explore using UML (OMG, 2015b)

and SysML (OMG, 2015a), to represent both dom-

ain knowledge and the problem-solving knowledge.

Domain knowledge could be represented as class

diagrams, object diagrams, SysML BDD or IBD.

Problem– solving knowledge can be formalised as

activity, sequence and state machine diagrams, allo-

cation diagrams, etc. The purpose would be to in-

tegrate metamodelling, modelling and ontologies for

the planning domain from a systems engineering per-

spective: to deﬁne the plan requirements based on the

domain knowledge ontology, how preconditions and

constraints are considered, how to allocate the actions

to speciﬁc actors, how the reasoning and deliberation

process takes place to obtain the possible and candi-

date plans from the ontology, and how the evaluation

process can be implemented to select among feasible

plans.

ACKNOWLEDGEMENTS

We acknowledge the support of the Spanish Go-

vernment through grants RTC-2016-5191-8 Sistema

Aut

onomo de VIgilancia y SEguridad basado en

multirrotores (ADVISE), and RTC-2016-5059-8 Sis-

tema Aut

onomo para La INtervenci

on en Emergen-

cias (SALINE).

REFERENCES

Baader, F., Calvanese, D., McGuinness, D., Nardi, D., and

Patel-Schneider, P. F., editors (2010). The Description

Reviewing Task and Planning Ontologies: An Ontology Engineering Process

189

Logic Handbook: Theory, Implementation and Appli-

cations. Cambridge, 2nd edition edition.

Balakirsky, S. (2015). Ontology based action planning and

veriﬁcation for agile manufacturing. Robotics and

Computer–Integrated Manufacturing, (33):21–28.

Balakirsky, S., Schlenoff, C., Fiorini, S., Redﬁeld, S., Bar-

reto, M., Nakawala, H., Carbonera, J., Soldatova,

L., Bermejo-Alonso, J., Maikore, F., Goncalves, P.,

de Mori, E., Ragavan, S. V., and Haidegger, T. (2017).

Towards a robots task ontology standard. In Proc.

ASME 2017 International Manufacturing Science and

Engineering Conference, Los Angeles, CA, USA.

Behnke, G., Bercher, P., Biundo, S., Glimm, B., Ponoma-

ryov, D., and Schiller, M. (2015a). Integrating onto-

logies and planning for cognitive systems. In Proc.

28th International Workshop on Description Logics

(DL 2015). CEUR Workshop Proceedings.

Behnke, G., Ponomaryow, D., Schiller, M., Bercher, P., Not-

hdurft, F., Glimm, B., and Biundo, S. (2015b). Co-

herence across components in cognitive systems - on

ontology to rule them all. In Proc. 24th Internatio-

nal Joint Conference on Artiﬁcial Intelligence (IJCAI

2015), pages 1442–1449. AAAI Press.

Benjamins, R., de Barros, L. N., and Va-

lente, A. (1996). Constructing planners

through problem-solving methods. At

http://ksi.cpsc.ucalgary.ca/KAW/KAW96/benjamins/.

Bermejo-Alonso, J., Salvador, J., and Sanz, R. (2018). To-

wards an ontology for task and planning in autono-

mous systems: An emergency scenario. In Advances

in Intelligent Systems and Computing,, volume 693,

pages 429–440. Springer, Cham.

Bermejo-Alonso, J., Sanz, R., Rodr

ıguez, M., and

Hern

andez, C. (2011). An ontological framework for

autonomous systems modelling. International Jour-

nal on Advances in Intelligent Systems, 3(3):211–225.

Bermejo-Alonso, J., Sanz, R., Rodr

ıguez, M., and

Hern

andez, C. (2013). Ontology engineering for the

autonomous systems domain. In Communications in

Computer and Information Science, volume 348, pa-

ges 263–277. Springer Berlin Heidelberg.

Borgo, S. and Masolo, C. (2010). Ontological Foundations

of Dolce, pages 279–295. Springer Netherlands.

Bouillet, E., Feblowitz, M., Liu, Z., Ranganathan, A., and

Riabov, A. (2007). A knowledge engineering and

planning framework based on owl ontologies. In Pro-

ceedings of the Second International Competition on

Knowledge Engineering.

Chandrasekaran, B., Josephson, J., and Benjamins, V. R.

(1998). Ontology of tasks and methods. In Proc. of the

11th Workshop on Knowledge Acquisition, Modeling

and Management (KAW98), Banff, Alberta, Canada.

Colledanchise, M. and Ogren, P. (2018). Behavior Trees in

Robotics and AI: An Introduction. Taylor and Francis.

Freitas, A., Schmidt, D., Panisson, A., Meneguzzi, F.,

Vieira, R., and Bordini, R. H. (2014). Semantic Re-

presentations of Agent Plans and Planning Problem

Domains, volume 8758 of Lecture Notes in Artiﬁcial

Intelligence (LNAI), pages 351–366. Springer Inter-

national Publishing.

Gangemi, A., Borgo, S., Catenacci, C., and Lehmann, J.

(2005). Task tanomies for knowledge content. Techni-

cal Report D07, Laboratory for Applied Ontology.

Gil, Y. (2005). Description logics and planning. AI Maga-

zine, 26(2):73–84.

Gil, Y. and Blythe, J. (2000). PLANET: a shareable and

reusable ontology for representing plans. In Proc.

of the AAAI Workshop on Representational Issues for

Real-world Plannning Systems, pages 28–33.

Hartanto, R. (2009). Fusing DL Reasoning with HTN Plan-

ning as Deliberative Layer in Mobile Robotics. PhD

thesis, Universit

at Osnabr

uck.

Hartanto, R. and Hertzberg, J. (2009). On the beneﬁt of

fusing dl-reasoning with htn-planning. In B. Mert-

sching, M. H. and Aziz, Z., editors, Lecture Notes

in Artiﬁcial Intelligence, volume 5803, pages 41–48.

Springer-Verlga Berlin Heidelberg.

Moreno, R., Borrajo, D., and Meziat, D. (2000). Process

modelling and AI planning techniques: A new appro-

ach. In Proc. 2nd International Workshop on Infor-

mation Integration and Web-based Applications and

Services, Indonesia.

Motta, E. (1997). An overview of the OCML modelling

language. Technical report, KMI.

OMG (2015a). OMG systems modeling language (SysML)

version 1.4.

OMG (2015b). Uniﬁed modeling language (UML) version

2.5 modeling language (SysML) version 1.4.

Rajhpathak, D. and Motta, E. (2004). An ontological forma-

lization of the planning task. In Proc. of the Interna-

tional Conference on Formal Ontology in Information

Systems (FOIS), Torino, Italy.

anchez-Ruiz, A., Gonz

alez-Castro, P. A., and D

ıaz-

Aguado, B. (2007). Planning with description logics

and syntactic updates.

Sirin, E., Parsia, B., Wu, D., Hendler, J., and Nau, D.

(2004). HTN planning for web service composition

using SHOP2. Journal of Web Semantics, 1(4):377–

396.

Tate, A. (1996). Towards a plan ontology. AI*IA Notizie

(Journal of the Italian Association for AI, 9(1).

Tate, A. (1998). Roots of SPAR - shared planning and acti-

vity representation. The Knowledge Engineering Re-

view, 13(1):121–128.

Thorisson, K. R., Bieger, J., Thorarensen, T., Sigurdardot-

tir, J. S., and Steunebrink, B. R. (2016). Why artiﬁcial

intelligence needs a task theory and what it might look

loke. In Artiﬁcial General Intelligence, number 9782

in LNAI, pages 118–128. Springer International Pu-

blishing.

Valente, A. (1995). Knowledge-level analysis of planning

system. SIGART Bulletin, 6(1):33–41.

W3C (2012). OWL 2 Web Ontology Language, second edi-

tion edition.

KEOD 2018 - 10th International Conference on Knowledge Engineering and Ontology Development

190