Context and Intention in Ontologies

1. Context and Intention in Ontologies Rick Wallace & Tabbasum Naz Cork Constraint Computation Centre University College Cork Cork, Ireland ARCOE 2010, Lisbon

2. 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? Motivation

4. ?’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?

5. Outline • Basic proposal • Implementing these ideas • Future vistas

6. Outline Basic proposal Central idea Mapping to ontological elements Representing intention(s) within ontology Bringing in background concepts Dealing with ‘completeness’ Characterising good organisation Implementing these ideas Future vistas

7. Outline Basic proposal Central idea Mapping plan elements to ontological elements Representing intention(s) within ontology Bringing in background concepts Characterising good organisation Implementing the idea Future vistas

8. How To Proceed? Critical insight Pace Bratman (1988), we consider the idea of intention as bound up with the creation of a plan. This leads to the approach described in this talk. Solution (top-level) We approach ontology construction as if we were building a plan. This means that we must start by defining a goal.

9. 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 two ontologies shown before.)

10. “For example, if one’s goal is to attend the IJCAI-93 conference in Chambery, France, advanced planning is suggested. The goal of attending the conference engenders many subgoals: booking plane tickets, getting to the airport, changing dollars to francs, making hotel reservations, finding the hotel, and so on.” D. S. Weld An introduction to least commitment planning AI Magazine, Winter 1994, pp. 27-61

11. We can accommodate subgoals using an HTN planning scheme. 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.

12. Plan actions plan_trip book_flight find_accomodation choose_activity

13. Outline Basic proposal Central idea Mapping plan elements to ontological elements Representing intention(s) within ontology Bringing in background concepts Dealing with ‘completeness’ Characterising good organisation Implementing these ideas Future vistas

14. 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 (?)

15. get_pizza go_to_pizza_place buy_pizza eat_pizza select_pizza pay_for_pizza select_topping

16. specify_topping specify_base classify_pizzas specify_features classify_pizzas_by_features Antecedent: ¬haveFeatures Effect: haveFeatures Antecedent: haveFeatures Effect: haveTaxonomyofPizzas

17. 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>

18. 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

19. 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

20. Outline Basic proposal Central idea Mapping plan elements to ontological elements Representing intention(s) within ontology Bringing in background concepts Dealing with ‘completeness’ Characterising good organisation Implementing these ideas Future vistas

21. catalogue Agent pizza plan Agent trip 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

22. Outline Basic proposal Central idea Mapping plan elements to ontological elements Representing intention(s) within ontology Bringing in background concepts Dealing with ‘completeness’ Characterising good organisation Implementing these ideas Future vistas

23. 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?

24. 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 Well-formed tree focal other focal focal other

25. 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 Well-formed tree? focal background other focal focal other

26. 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 Ill-formed tree focal other focal background other

27. Outline Basic proposal Central idea Mapping plan elements to ontological elements Representing intention(s) within ontology Bringing in background concepts Dealing with ‘completeness’ Characterising good organisation Implementing these ideas Future vistas

28. ‘Completeness’ of Ontology • Tentative proposal • Ontology is complete if associated plan is complete, given an appropriate set of rules for translating and elaborating

29. Outline Basic proposal Central idea Mapping plan elements to ontological elements Representing intention(s) within ontology Bringing in background concepts Dealing with ‘completeness’ Characterising good organisation Implementing these ideas Future vistas

30. “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

31. 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

32. 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 Well-formed tree focal other focal focal other

33. Partitions (cont.) • Good (partial) partitions and bad partitions BodyPart BodyPart Arm Cell Arm Leg Bad Good

34. Further Examples • Animal • Arthropod • Chordate • Etc • Animal • Winged • Legged • Crawling • Animal • Radial symmetry • Bilateral symmetry

35. E.g. ModeOfTransport Bus Rented_Car Airplane Car Bus Airplane Choice of background concepts Vehicle For trip-planning, hierarchy on left is more appropriate

36. Outline Basic proposal Implementing these ideas Future vistas

37. 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

38. 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

39. Outline Basic proposal Implementing the idea Future vistas

40. 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

41. END