In this paper we propose a method for effective building of lightweight ontologies, applying the principles of eXtreme Programming. The method is based on a multi-layered approach, which combines the advantages of maximum monotonic extensibility with clarity of the desired terms. The method aims to make it easy to develop a simple ontology, being careful to avoid deviation between the user's expectations and the produced output. We emphasize on capturing system requirements and consider the intended use of the ontology by analyzing the userprovided competency questions. The method is illustrated with the domain of Value-Added Publishing, which can be represented as a multi-agent system, where different types of information extraction agents deal with various aspects of processing information.
Agent-based systems are advancing in many different directions
and the number of multi-agent solutions keeps increasing.
Heterogeneity and diversity of the agent communication
languages, protocols and building techniques give freedom and
flexibility in developing, but at the same time create a major
difficulty in communication between agents within a system and
between different multi-agent systems [
There are a number of issues covered in [
221 Bouverie Str.
Carlton 3010, Vic., Australia development of multi-agent systems will necessitate building a number of small, domain-specific ontologies.
Various methodologies have been developed for building ontologies. However, most of these emerged from projects whose final goal was building the ontology itself. All that we are aware of are based on alteration and improvement on the produced output and even if the initial details and scope are well-defined an evolving prototype is the central core. But while visualizing and navigating ontologies are two relatively simple processes (due to the increasing number of ontology browsers), practical modification of an ontology, including improvement, expansion and updating, remains a very complex task. Removing classes or changing the structure (relationships) is a complex process that even the most intelligent agents lack capabilities to perform satisfactorily, i.e. without compromising the reliability of the conceptual model. Integration and maintenance of an existing ontology could also bring to the surface unconsidered difficulties. For these reasons maintaining a global ontology has so far been unsuccessful. On the other hand small lightweight methodologies for ontology-building that are easy to follow, with only a few rules and practices, have not become wide spread yet. Agent-systems developers keep building small domain-specific ontologies ignoring the guidelines and instinctively moving away from heavyweight methodologies. Most are moving back toward an earlier, simpler time of lightweight methodologies when a few rules were enough. The existing ontology-development methodologies, though, offer processes and rules that by simplifying can significantly advance the creation of reliable and quick small ontologies. In this paper we propose a method for effective building of extreme lightweight ontologies that maintain the balance between developing an ontology from scratch without any rules and practices, constantly updating the structure and on the other hand long-term specification, prototyping and maintenance. We will do this by introducing some few rules and practices that are light, concise, and effective, mainly based on the eXtreme Programming practices. The method is based on a multilayered approach, utilising the advantages of monotonic extensibility and clarity of the desired terms. The method aims to avoid deviation between the user's expectations and produced output, by focusing on capturing system requirements as well as considering the intended use of the ontology by analyzing the competency questions, provided by the users.
As a use case we take the domain of Value-Added Publishing. VAP can be represented as a multi-agent system, where different types of agents deal with different aspects of processing documents.
The rest of the paper is structured as follows. In section 2 we give
a basic overview of eXtreme Programming principles. More
details and descriptions are given in [
EXtreme Programming (XP) has been developed on the basis of the results of many observations of what makes computer programming faster and what slows down it. As almost any other lightweight discipline of software development the main focuses of XP practices are simplicity, communication and feedback. The main XP rules that will be mentioned very briefly here and used for the purpose of this paper are: The Planning Process. It allows the customer to define the business value of desired features and uses cost estimates provided by the programmers to choose what needs to be done and what can be deferred. Small Releases. A simple system is released early, and updated frequently on a very short cycle. Metaphor. A common "system of names" and a common system description are used that guide development and communication. Simple Design. The program meets the current requirements. Instead of building "for the future", the focus is on providing business value. Testing. Focuses on validation at all times. Firstly the tests are developed and then software that fulfils the requirements. Customers provide acceptance tests that enable them to be certain that the features they need are provided. Refractoring. Improvement of the design throughout the entire development. Collective Ownership, Continuous Integration. Integration of the software system multiple times per day.
Ontologies may be distinguished by the requirements which they are able to solve; that is, one ontology may be able to represent and solve a different set of requirements to another ontology. Even if two ontologies are in the same domain, in different environments there is no guarantee that both will be interchangeable or reusable.
We propose to build the ontology at the end of the process of developing the system, after all the requirements have been specified, needs determined and specifications written. One might argue that the whole system will be dependent on what the user has specified initially, but the change of requirements won't affect much on the whole system, since rebuilding the ontology won't be time-consuming and there won't be a need to change the structure of the other modules. Its internal model can be well specified in the beginning and added to the other details of the specification. Making the ontology the last step of a software development cycle will reduce the development time, in addition to the benefits that come from building small, light-weight ontologies, instead of deep, broad and complex ones which are slow to parse and eventually retrieve information from.
The difference in the approach is the emphasis on the user. Rather than compiling all the existing knowledge in an ontology and teaching the system to browse it, fetch the valuable information and present it in a convenient way, the user's system plays a significant role in the initial process of developing the ontology. We are considering a multi-agent system, in which different types of agents exist each performing different task or service.
1. Fetching the requirements of the system. In the traditional
process this could be considered as scoping. The collected data
will be used to create a baseline ontology. Baseline or input
ontology [
Structural and
Concept
Requirements
the optimal depth and width and answering questions such as
"How much information should be encoded in the relations and
how much in the hierarchy itself?", since ontologies with different
structure perform differently even if they produce the same result.
6. After all the planning and estimations have been done the next
step in the process is Continuous Integration. Ultimately any
methodology needs to be customized to the circumstances and
environment. No methodology is just a collection of rules to be
performed in rote fashion. During the process of integration it is
very important to explore how the ontology will react with the
other modules of the environment. If for example there is a
converter in the system that parses the ontology, it has to produce
correct class structure output. If the purpose of the ontology is to
fill up a database it must be checked for consistency and structure.
The result and the benefit of the continuous integration is a clean
and simple ontology without duplications.
7. Acceptance tests. One of the key tasks to be done (some might
argue that they should be created even before the planning) is to
define the acceptance tests. It is very important for the user to
know in
advance what
the system Baseline Ontology
should do and (Small releases)
to understand
it. Tests
should be
created for ReCqounirceempetnt ReSqturuircetmureanlts
each iteration s
step. For each
question and
validation test
there is a level
of acceptance Middle Agent
of the result. (Collective Ownership)
As in TOVE
[
This method does not include maintenance as a final stage of the ontology development. The main reason is that since the requirements are carefully specified in the initial stage, once an ontology is created it is guaranteed that it meets the specific needs of the current application. All the inconsistencies or potential problems with the developed ontology are avoided during the testing and planning stages. A situation commonly encountered during software development is that of changing requirements. Drawing on the principles of XP, the eXtreme Ontology method handles changes by focusing on keeping ontologies lightweight and highly adaptable. Frequent iterations and continuous integration ensure that any necessary changes are identified immediately, and no unnecessary changes are made. The fact that the ontology is developed after the system is specified indicates that the requirements will be much more stable during the ontology development phase. In this way, the problems are avoided that traditional methods face when the ontology is frozen long before any prototypes can be presented to the client for initial feedback (the point at which the client usually realises that their initial requirements are not what they really want). Also in case of adding new modules of components to the system, due to the semi-automated tools, the process of building the ontology is easy and quick.
Following the described method at the moment we are developing a prototype to test the usability and effectiveness of the process. The final purpose is to measure and compare the extreme ontologies approach to other traditional ontology-development methodologies in terms of success of using the provided tools, techniques and integration of the produced ontology in a complex organization. The prototype is still in development but the draft version of its architecture is given in Figure 1.
the 'full' knowledge of the Management Assistant Acceptance system achieves (Planning) Test the Collective Ownership principle. The way Redundancy Test we propose that (Metaphor) this be done is by using one or more middle agents Validation Test [c4o,l1le1c,1t2] agetnhtast' capabilities.
Capabilities briefly Competency Questions define the purpose of an agent, for example finding the rating of an author. In a multiagent system whenever agents 'come' into a system they register their capabilities to the middle agent by sending to it a basic description of their input and output. There are a number of ways this can done, generally by using an interface description language, or an agent description language. Another comparison to XP is the fact that the requirements are extracted from some form of system by one module and further processed by another module. We consider the second stage to be performed by humans and the requirements are expressed in a primitive and simple enough way to act as tokens. So far the existing methodologies suggest that ontology engineers create the baseline ontology manually. In our case it is done semi-automatically - the middle agent provides concepts and attributes, but engineers define the structure. For example, based on the description of agent’s capabilities, a middle agent will suggest concepts such as ‘author’ and ‘paper’, the type of the output, i.e. ‘list of papers’ [and maybe other information, depending on what is provided by the information extraction agent] but the relationship between them ‘writes’ - will be defined manually.
The validation test module ensures small releases of the ontology.
For example in the case of VAP a competency question might be:
"Provide a list of books written by this author?". If the question
can be answered using the current ontology the ontological
commitments are valid and the next question is tested. Otherwise
the redundancy test checks if the competency question contains
words similar to the already existing concepts in the ontology. At
this stage the comparison is mainly syntactic, based on pattern
matching, but further it could be extended to semantic mapping
[
In [
After reviewing some of the existing methodologies for ontology development, in this paper we have proposed a new approach for developing lightweight ontologies. We are combining some of the beneficial characteristics of the existing methods, but avoiding the attitude that "ontologies are the core element" of the systems being developed. EXtreme Ontologies approach involves humans to create the baseline ontology, but all the consequent changes are only guided by the user, while the internal processes are performed by automated tools. The method ensures that development effort is not spent on unnecessary implementation of classes and relations. The derived ontology only meets the requirements that match the validation rules and test cases. Despite the fact that our project is still in an initial phase, and tools that reduce risk and gain benefit from the validation tests and rules before the actual implementation of an ontology have not yet been developed, we believe that it will significantly contribute to this area. Additionally, the evaluation of the method and subsequent experiments will reveal the effectiveness of applying the eXtreme Programming principles and rules to ontology design and development. The final purpose is to explore and compare the extreme ontologies approach to other traditional ontology-development methodologies in terms of success of using the provided tools, techniques and integration of the produced ontology in a complex organization.