reflecting on ontologies: towards ontology-based agent-oriented software engineering

Reflecting on Ontologies: Towards Ontology-based Agent-

oriented Software Engineering

Ghassan Beydoun, B. Henderson-Sellers, J. Shen, G. Low

1{beydoun, jshen} @uow.edu.au, School of Information Systems and Technology, University of Wollongong, Wollongong2 [email protected], School of Software, University of Technology, Sydney3 [email protected], School of Information Systems, Technology and Management, University of New South Wales, Sydney

mailto:[email protected]











Motivation and OverviewMotivation:

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

Previous Related Work and Limitations

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

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?

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)

80’s 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.

From KBS ontologies to MAS ontology centric SDLC

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

Guarino Fensel

of High Level

of Domain

of Applications

of Tasks

Generic

Representational

of Domain

of Methods & Tasks

+Generality-

Domainindependents

Domaindependents

Guarino Fensel

of High Level

of Domain

of Applications

of Tasks

Generic

Representational

of Domain

of Methods & Tasks

+Generality-

Domainindependents

Domaindependents

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

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?)

Link to classical SE models ?

M3

M2 Metamodel

M1Model

M0Data

instance_of

instance_of

instance_of

M3 (MOF) Metametamodel

M2 Metamodel

M1Model

M0Data

instance_of

instance_of

instance_of

M3

M2 Metamodel

M1Model

M0Data

instance_of

instance_of

instance_of

M3 (MOF) Metametamodel

M2 Metamodel

M1Model

M0Data

instance_of

instance_of

instance_of

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

Ontology metamodela.k.a. foundational ontologya.k.a. upper-level ontology

Generic ontology;Domain-specific ontology

= schema/model

Instances of domain-specific ontology

e.g. OMG ODM

e.g. hierarchy for banking

M2

M1

M0



= schema/model


e.g. OMG ODM




= schema/model


e.g. OMG ODM


M2

M1

M0

Ontologies are different in intent from software models ( descriptive rather than prescriptive)

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

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.

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

Their ontologies 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.

Individual PSM may be incomplete in an MAS

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

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

The rest of the system can then be developed with appropriate ontological mappings (semantic operations). – (between portions of domain ontology and local agent’s

knowledge) is required to ensure all PSM have their knowledge requirement available to their reasoning format

– (perhaps between agent’s 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.

Concluding RemarksWe 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.

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?

reflecting on ontologies: towards ontology-based agent-oriented software engineering

Documents