context and intention in ontologies
DESCRIPTION
Context and Intention in Ontologies. Rick Wallace & Tabbasum Naz Cork Constraint Computation Centre University College Cork Cork, Ireland. ARCOE 2010, Lisbon. Normally, an ontology embodies intentions (sometimes called “competencies”) Intentions usually remain implicit - PowerPoint PPT PresentationTRANSCRIPT
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: haveFeatures
Effect: 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