Reflecting on Ontologies: Towards Ontology-based Agent-oriented Software Engineering

1
Reflecting on Ontologies Towards Ontology-based
Agent-oriented Software Engineering

• Ghassan Beydoun, B. Henderson-Sellers, J. Shen,
  G. Low1beydoun, jshen _at_uow.edu.au, School of
  Information Systems and Technology, University of
  Wollongong, Wollongong2 brian_at_it.uts.edu.au,
  School of Software, University of Technology,
  Sydney3 g.low_at_unsw.edu.au, School of Information
  Systems, Technology and Management, University of
  New South Wales, Sydney

2
Motivation and Overview

• Motivation
• Many AOSE methodologies limited scopes,
  disagreements on what are essential elements, ..
• Reuse of SE knowledge by rationalising and
  unifying AOSE knowledge
• Re-use of software components (workproducts) for
  MAS
• Higher quality components (workproducts)
• Overview
• - Related previous work
• - From ontologies in single agents to ontologies
  in MAS reconciliation with views of models and
  ontologies within SE
• - Sketch of an Ontology-Based Development
• Conclusion and future work

3
Previous Related Work and Limitations

• Method engineering for MAS (Henderson-Sellers,
  Low, Beydoun 2005)

4

• ME challenges
• A unified language to represent methodologies
  work products. Solved in FAML (an ontology of
  methods workproducts) (IEEE Transactions on SE
  2009, Beydoun, Low, Henderson-Sellers et al)- now
  a MAS modelling language
• BUT
• Evaluation of FAML ? How to use it to represent
  various methodologies without authors themselves?
  
• After all is said and done, would it be worth it?

5

• Merging methodologies one at a time
• Same challenges as ME it may well be undoable
  as inconsistencies emerge quickly (Bernon et al
  2006).
• Alternative that is the work is pushing forward
  towards
• Push the ontology to the domain and sofwtare
  processes (rather than the method workproducts
  design)
• Aim to have reusable workproducts instead (of
  reusable method fragments) - developed in an
  ontology centric way, without imposing any
  methodology- instead an ontology-based
  development framework that overlays on-top of
  existing methodologies (Extends AOIS2006 and
  ABWE05)

6
From KBS ontologies to MAS ontology centric SDLC

• 80s the notion of knowledge level idea ?
  Categorisation of knowledge ? Decoupling problem
  solving from domain Knowledge leads to reusable
  components
• For a particular task only a small part of an
  ontology will actually be needed. A suitable
  problem-solving method is chosen to adapt the
  used ontology to a suitable level of refinement.

?
7

• LHS is Following (Guarino, 1998), (Ruiz and
  Hilera, 2006 Guizzardi, 2005)
• While an upper-level ontology is important, it
  is less important ontology is used. In fact, we
  omit upper level ontology from our methodological
  sketch.

8
From KBS ontologies to MAS ontology centric SDLC
An MAS is a distributed knowledge based system,
where each agent, has a localised KB Has private
knowledge but agent KBs may overlap. Currently
for MAS Ontologies are mainly used to provide a
communication model between agents. MAS methods
do not incorporate ontologies in the development
of design.
The initial motivation for using ontologies (for
single agent systems), that of enhancing reuse,
is absent in MAS agent oriented software
engineering (AOSE).
9
Linking Ontologies to SE models

• Multiple views of ontologies- What is an ontology
  anyway?
• - Formal (Corcho et al., 2006 OMG, 2005b
  Guizzardi, 2005 Rilling et al., 2007)- this is
  a varying scale (recall AAAI slide from Keynote
  talk)
• understandable by a computer- at some stage in
  SDLC- NOT in early phases
• Underpinned by a metamodel
• Having form, mathematical, ..
• Shared
• Represented by a vocabulary (set of human terms?)

10
Link to classical SE models ?
11

• OMG (Object Management Group) is working on
  creating a bridge Three level ontology
  architecture suggested by OMG (2008)

Ontologies are different in intent from software
models ( descriptive rather than prescriptive)
12
Ontology Requirement for MAS development

• MAS is a collection of agents, cooperating, and
  communicating towards system goals.
• MAS are sought to address KBS limitations as
  follows incomplete knowledge requirement
  specification, incomplete PSM requirement and
  limited computational resources (per agent).
• In other words, agents within an MAS
• May have varying Problem Solving Methods (PSM)
• Their ontologies may be incomplete in an MAS
• Individual PSM may be incomplete in an MAS
  (hence, need for cooperation, communication,
  etc..)

13
MAS knowledge use vs KBS knowledge use

• May have varying PSMs
• Individual and complementary PSM may operate at
  different levels of abstraction of the domain
• ? Ontology mappings to interface individual
  problem solvers to a common domain
  conceptualization
• ? Verification of individual PSM knowledge
  requirements against ontologies of individual
  agents, at design time.

14
Their ontologies may be incomplete in an MAS ?

• Extracting from domain and task ontologies will
  need to be iterative
• ? Knowledge extensibility is required at the
  agent level
• ? A structured and understood knowledge
  representation is required to resolve
  inconsistencies from above

15
Individual PSM may be incomplete in an MAS ?

• Agents interact to compensate limits of their
  PSMs. However, without complete consideration of
  individual PSMs against other available PSM
  within the system, there is no guarantee that
  this cooperation would ultimately work. 
• ? Iteration between the problem solver design
  choice and goal analysis /allocation to
  individual agents (iteratively ) ? A
  consideration of the total PSMs of all agents to
  ensure that system goals are achievable.

16
Towards Ontology-Based MAS development

• Similar to KBS development, we aim to have the
  development centred on the appropriate choice of
  PSM(s).
• Domain analysis is the first stage of developing
  the system. In other words, domain analysis
  yielding a global ontology is assumed to precede
  ontological analysis for individual problem
  solvers for each agent. Given the six SE
  requirements, such a methodology is characterised
  by the following
• Choice of PSMs driving the development process
• Ontology mappings to integrate agents into an MAS

17
Sketch of an Ontology-Based MAS methodology
PSMs (using PSM libraries) and system goals are
associated in the early stages of an MAS design.
Agents need to communicate their results and
instigate cooperation using a common language.
In the case of open systems, introducing new
agents may require extending the communication
ontology or some local ontologies to allow
cooperation with new agents
18

• The rest of the system can then be developed with
  appropriate ontological mappings (semantic
  operations).
• (between portions of domain ontology and local
  agents knowledge) is required to ensure all PSM
  have their knowledge requirement available to
  their reasoning format
• (perhaps between agents knowledge and a
  communication medium) to communicate.
• The collection of all PSMs for local goals should
  also be verified for completeness against stated
  system goals. These goals should also be checked
  against cooperation potential.

19
Concluding Remarks

• We recognize the inter-play between the role of
  reuse and various existing roles of ontologies in
  a MAS. e.g. We cannot have various reuse roles
  smoothly accommodated (e.g. interoperability) at
  run-time, without careful consideration of design
  time requirements.
• hierarchical ontologies are one way to have
  flexible domain ontology refinement for agents
  according to their PSMs, and to accommodate
  difference in strength of the PSM of agents.
• Ontologies roles in reasoning at run-time, is
  based on fulfilling PSM knowledge requirement at
  design time.

20
Future work
PSM choice is difficult, choosing an appropriate
PSM would not accommodate all domain dependent
concerns for a given MAS A complete
ontology-based methodology, has domain
independent concerns skeleton interleaved with
domain dependent concerns as steps optionally
enacted. To consider, ontology steps that
overlay on top of existing methodologies. E.g.
how do I improve goal/role models using
ontologies? How do I facilitate transition into
lower level design using ontologies?