context and intention in ontologies rick wallace & tabbasum naz cork constraint computation...

Context and Intention in Ontologies

Rick Wallace & Tabbasum NazCork Constraint Computation Centre

University College CorkCork, Ireland

ARCOE 2010, Lisbon

Motivation• Normally, an ontology embodies intentions (sometimes called

“competencies”)

• Intentions usually remain implicit– May not be expressed in the concepts included in the ontology– Relevance of a given concept to the purpose of the ontology may not be clear

• Ontologies often seem deficient in their organisation– Ontology building still appears to be a fairly undisciplined process in that

concepts are included on a more or less intuitive basis– Organisational principles lacking

(despite approaches such as OntoClean and availability of top-level ontologies)– To what degree is this because ‘intentionality’ is not explicit?– To what degree can a means of making such intentionality more explicit help

improve the organisation?

?’s

• How can we characterise these problems?

• How can we evaluate appropriateness of ontology for given task?

• How can we determine organisational quality of ontologies – including completeness?

Outline

• Basic proposal

• Implementing these ideas

• Future vistas

Outline• Basic proposal

o Central ideao Mapping to ontological elementso Representing intention(s) within ontologyo Bringing in background conceptso Dealing with ‘completeness’o Characterising good organisation

• Implementing these ideas

• Future vistas

Outline• Basic proposal

o Central ideao Mapping plan elements to ontological elementso Representing intention(s) within ontologyo Bringing in background conceptso Characterising good organisation

• Implementing the idea

• Future vistas

Solution (top-level)

We approach ontology construction as if we were building a plan.

This means that we must start by defining a goal.

Critical insight

Pace Bratman (1988), we consider the idea of intention as bound upwith the creation of a plan. This leads to the approach described inthis talk.

How To Proceed?

In the tourism domain, the basic goal is to support trip-planning.

This goal is associated with a central concept, in this case trip.

(Interestingly, this concept does not appear in either of the twoontologies shown before.)

“For example, if one’s goal is to attend the IJCAI-93 conferencein Chambery, France, advanced planning is suggested. The goalof attending the conference engenders many subgoals: bookingplane tickets, getting to the airport, changing dollars to francs,making hotel reservations, finding the hotel, and so on.”

D. S. WeldAn introduction to least commitment planningAI Magazine, Winter 1994, pp. 27-61

We can accommodate subgoals using an HTN planningscheme.

In the present case, we can think of the basic action,trip-planning, as decomposed into component actions.

An example is shown in the next slide.

plan_trip

book_flight find_accomodation choose_activity

Plan actions

Outline• Basic proposal

o Central ideao Mapping plan elements to ontological elementso Representing intention(s) within ontologyo Bringing in background conceptso Dealing with ‘completeness’o Characterising good organisation

• Implementing these ideas

• Future vistas

A Second Domain

• Let’s consider the pizza domain

• And different intentions– Eating a pizza– Making a pizza

• How to characterise the Owl example?– Cataloguing/classifying the kinds of pizzas (?)

get_pizza

go_to_pizza_place buy_pizza eat_pizza

select_pizza pay_for_pizza

select_topping

classify_pizzas

specify_features classify_pizzas_by_features

Antecedent: ¬haveFeaturesEffect: haveFeatures

Antecedent: haveFeaturesEffect: haveTaxonomyofPizzas

specify_topping specify_base

Mapping plan elements to ontological elements

• Consider the “specify_features” action

• This could be mapped to a <hasFeature> property in the ontology

• <hasFeature> could have subproperties <hasTopping> and <hasBase>

Mapping plan elements to ontological elements - 2

• Admission– In this case, we built a plan to go with the ontology (and

the plan was, essentially, to build an ontology)– So, naturally, a plan element could be transformed back

into an ontology element

• But …– This example is at least suggestive

• Hence, a tentative proposal is that actions in a plan should map to properties in the ontology

Mapping plan elements to ontological elements - 3

• Admission– In this case, we built a plan to go with the ontology (and

the plan was, essentially, to build an ontology)– So, naturally, a plan element could be transformed back

into an ontology element• But …

– This example is at least suggestive• Hence, a tentative proposal is that actions in a plan

should map into properties in the ontology• A second proposal is that antecedents and effects

should map to concepts in the ontology

Outline• Basic proposal

o Central ideao Mapping plan elements to ontological elementso Representing intention(s) within ontologyo Bringing in background conceptso Dealing with ‘completeness’o Characterising good organisation

• Implementing these ideas

• Future vistas

Representing Central Intention• One idea

– Introduce a concept of <Agent>– <Agent> associated with only one property, which ‘points’

to the “central concept”, which reflects the intention

Agent pizzacatalogue

Agent tripplan

Outline• Basic proposal

o Central ideao Mapping plan elements to ontological elementso Representing intention(s) within ontologyo Bringing in background conceptso Dealing with ‘completeness’o Characterising good organisation

• Implementing these ideas

• Future vistas

Plan-(intention-)related Concepts

• Focal concepts– Associated with elements of the plan– E.g. “book_flight” => <booking>, <flight>, <flightBooking>

• Background concepts– Superclasses– Classes related to the focal concepts by ‘basic’ properties– Is it possible to use constraints, as in many planners?

Selection of Concepts - 2

• Tentative rule– Focal concepts must not be superordinate to

background concepts in a hierarchy– I.e. all focal concepts must occur at the bottom of

a concept-tree

background

focal

focal

other

focal other

Well-formed tree

Selection of Concepts - 3

• Tentative rule– Focal concepts must not precede background

concepts in a hierarchy– I.e. all focal concepts must occur at the bottom of

a concept-tree

background

focal

focal

background

focal other

Well-formed tree?other

Selection of Concepts - 4

• Tentative rule– Focal concepts must not precede background

concepts in any hierarchy– I.e. all focal concepts must occur at the bottom of

a concept-tree

background

focal

background

other

focal other

Ill-formed tree

Outline• Basic proposal

o Central ideao Mapping plan elements to ontological elementso Representing intention(s) within ontologyo Bringing in background conceptso Dealing with ‘completeness’o Characterising good organisation

• Implementing these ideas

• Future vistas

‘Completeness’ of Ontology

• Tentative proposal

– Ontology is complete if associated plan is complete, given an appropriate set of rules for translating and elaborating

Outline• Basic proposal

o Central ideao Mapping plan elements to ontological elementso Representing intention(s) within ontologyo Bringing in background conceptso Dealing with ‘completeness’o Characterising good organisation

• Implementing these ideas

• Future vistas

“Ontological mereology”

• Want to consider clusters of concepts

• Especially, clusters that, in some sense, partition a superclass

• Sticking point: how can you know when you have a complete partition?

• Weaker condition– Subclasses don’t overlap

Plans and Partitions

• Partition – a basic concept for ontologies ?

• Basic partition – of some background concept– Focal subconcept(s)– “Other”-subconcept (a better term might be “remainder”)

• Interpretation: individuals not covered by focal concepts

Plans and Partitions - 2

• Tentative rule– Focal concepts must not precede background

concepts in a hierarchy– I.e. all focal concepts must occur at the bottom of

a concept-tree

background

focal

focal

other

focal other

Well-formed tree

Partitions (cont.)

• Good (partial) partitions and bad partitions

BodyPart

Arm Leg

BodyPart

Arm Cell

Good Bad

Further Examples• Animal

– Arthropod– Chordate– Etc

• Animal– Winged– Legged– Crawling

• Animal– Radial symmetry– Bilateral symmetry

E.g.

VehicleModeOfTransport

Bus Rented_Car Airplane Car Bus Airplane

For trip-planning, hierarchy on left is more appropriate

Choice of background concepts

Outline

• Basic proposal

• Implementing these ideas

• Future vistas

Implementation

• Important issue– regarding conceptualization vs. HCI

• How should preceding ideas be reflected in actual implementation?

• More specifically, which of the distinctions in the model must the user be expected to make?

• Want to avoid some complexities of planning process

Implementation – Current Plan

• Planning interface– Supports HTN style of planning

• Concept extraction– Dictionary, string matching– Initially, use Java camelBack conventions for plan

elements– Use of top-level ontology to ‘locate’ concepts

derived from plan• Use of Owl with Java API

Outline

• Basic proposal

• Implementing the idea

• Future vistas

Ideas for Future

• Ontology building as replanning– Use of old plans, subplans

• Plan schemas– Interrogate user for associated actions, etc

(focal) concepts• Refining ideas of intention/requisite

competence– Handling multiple intentions

• Generating plan(s) from existing ontologies

END