Ontologies as Vehicles for Reuse: a mini-experiment

I. Laresgoiti1, A. Anjewierden2, A. Bernaras1, J. Corera3, A. TH. Schreiber2, B. J. Wielinga2

1LABEIN, Parque Tecnologico, Ed. 101, 48016 - Zamudio Bizkaia, Spain. E-mail: {lares,amaia}@labein.es

2University of Amsterdam, Department of Social Science Informatics, Roetersstraat 15, NL-1018 WB Amsterdam, The Netherlands. E-mail: {anjo,schreiber,wielinga}@swi.psy.uva.nl

3IBERDROLA, Gardoqui, 8, 48008 - Bilbao, Spain. E-mail: jose.corera@iberdrola.es

1 Introduction

1.1 Context: The KACTUS project

KACTUS is a European ESPRIT project in which a group of industrial and academic partners set out to work on methods and tools to enable reuse and sharing of technical knowledge. The technical basis of this project was founded on insights in knowledge-engineering research, where the emphasis has shifted over the last few years from modeling reasoning processes to modeling "ontologies": reusable pieces of domain knowledge. In the view of KACTUS the area of reusing and sharing knowledge and complex data will become a prime focus of software-engineering practice in the near future. To be able to build a new generation of intelligent, interacting IT systems, it is necessary to get some grip on a number of standard ways of "viewing the world'', albeit in a limited and pragmatic, engineering-oriented fashion. KACTUS is trying to provide a link between CIME (Computer-Integrated Manufacturing and Engineering) research on standard product models for engineering (the ISO STEP standard) and emerging standards in knowledge engineering, in particular the CommonKADS approach.

From a practical point of view, the objective of the KACTUS project is to develop a number of reusable ontologies for technical systems, together with methods and tools for using these ontologies in practical applications. Application domains in this project included ship design, oil platforms, and electrical service networks. The project was driven by the user needs of the application partners involved. The application tasks involved were typically complex knowledge-intensive ones such as service-recovery, procedure generation, simulation, design etc.

1.2 Overview of the paper

In this paper we try to give an overview of the approach taken in KACTUS towards knowledge reuse, together with a short example application in which the approach is used.

In Section we briefly discuss data models and their limitations in the context of reusing complex technical information found in the domains we have tackled. We see ontologies as a "natural next step" in the increasing complexity of data models, and propose in Section a framework for knowledge reuse, that can be used as an add-on to existing system development approaches such as CommonKADS or STEP. One central theme in the KACTUS approach is the construction of libraries of ontologies. We briefly discuss the organization principles of such a library based on the library we constructed within the project.

Section describes a small experiment we performed to test the KACTUS approach in the electrical network domain. This experiment involved the construction of a demonstrator within the time scale of one week, reusing an existing ontology of an electrical network. This experiment shows how a shared ontology can be used for interoperability. In this case existing databases about the static and dynamic structure of the network could be integrated in the application in a principled way. Section reflects on the results of this experiment and discusses related work.

2 Data Models and Ontologies

2.1 Data models

Data models are important elements of any information system. A data model describes the logical structure of the data of an application. Data models have their origins both in the type constructs in early programming languages such as ALGOL, and in the organization schemes for databases (e.g. the hierarchical model). One can see a gradual process in the development of data models from simple data definitions to data modeling languages of increasing complexity. A landmark was the introduction by Chen (1986) of the Entity-Relationship (ER) model. An ER model is a schematic description of the "instances" of the model. These data model instances are the actual data used and manipulated by an application.

Since then, many extensions have been proposed to the ER scheme. All these extensions aim at providing more powerful ways of capturing the meaning ("semantics") of the data described by the model. A common extension is the use of sub-class hierarchies of entity classes, capturing commonalities between entities in different classes. There is currently a whole literature on semantical constructs that could be used in data models ("semantic data modeling", "extended ER modeling", "hyper-semantic data modeling").

A good example of a contemporary extended ER data modeling scheme can be found in the OMT approach (Rumbaugh et al., 1991). OMT provides, amongst others, the following data modeling primitives:

2.2 Limitations of data modelling

Data modeling essentially takes a single-level view of the world. The data model describes in a schematic way the "objects" or "instances" that are of interest. For example, a data model for a database of oil platform components would contain types such as "heat exchanger" together with related attributes and relations/associations. Instances of this type are particular heat exchangers. Although subclass hierarchies can be used to define more abstract properties of a "heat exchanger", data modeling typically allows only one possible interpretation of "heat exchanger".

However, if one wants to reuse a notion like "heat exchanger", it quickly becomes clear that this term can have different meanings in different contexts (see Figure 1). For example, from an oil-platform design perspective the physical properties will be the main emphasis: physical dimensions, types of connections, etc. In a diagnostic setting functional properties such as the difference in temperature between the different inputs and outputs are likely to be the prime focus of attention. For dynamic simulation applications, behavioral properties such as mathematical properties of the heat exchange process would need to be modeled in association with "heat exchanger".

Figure 1: Some example viewpoints on the concept "heat exchanger" see from various applications in an oil production process application

It is safe to say that reuse of complex, knowledge-intensive data is impossible without taking these different viewpoints into account. This means that we want to be able to look at a data type like "heat exchanger" in different ways. This idea is partially present in the ANSI/SPARC architecture of databases (see Figure 2). This architecture consists of three levels:

  1. The conceptual schema is the intermediate level and the anchor point of this architecture. It describes the logical structure of the data in the database.

  2. The internal database representation describes how the conceptual schema is realised in terms of implementation objects: files, indices, hash tables, etc.

  3. On top of the conceptual schema one can define multiple "external views". Such external views consist of selections and combinations of elements of the conceptual schema, and represent a viewpoint of a specific user. For example, a database containing administrative data of university students might have two different views on those data: for the financial department and for the tutors.

Figure 2: ANSI/SPARC architecture

The ANSI/SPARC external views can be used to some extent for the representation of the different viewpoints, such as those on a "heat exchanger". The main limitation is that the viewpoints themselves do not add new information: all basic information is already present in the conceptual schema. This is not the case in most realistic situations: each viewpoint on an object adds its own context-specific information items, and there is not one universal unified representation for all the viewpoints. Such a unified representation is impossible because the number of viewpoints one can take is in practice unlimited. In other words, objects like "heat exchanger" can be used in so many different contexts that it is impossible to develop in advance a complete, unified description of a "heat exchanger" that will prove to be sufficient for every possible situation.

This observation about viewpoints on real-world objects lies at the heart of the KACTUS project. We have formulated this as a major principle underlying the KACTUS approach:

Principle 1: The representation of real-world objects always depends on the context in which the object is used. This context can be seen as a "viewpoint" taken on the object. It is usually impossible to enumerate in advance all the possible useful viewpoints on (a class of) objects.

This principle has important consequences for an approach to reusing knowledge-intensive information items. It means that it is not feasible to strive for one unified representation, that can be used in multiple application settings. Typically, one would expect that application descriptions can be partially reused in another setting, namely exactly those descriptions that share a common viewpoint. For example, in the electrical network domain, the functional model of the network built for a diagnostic application might also be useful for a service recovery application, whereas some other knowledge items are likely to be application-specific for a diagnostic context.

It should have become clear by now that in the KACTUS view the key to reuse lies in explicating the underlying viewpoints of a representation. This can be seen as the second principle underlying the KACTUS approach:

Principle 2: Reuse of some piece of knowledge requires an explicit description of the viewpoints that are inherently present in this knowledge. Otherwise, there is no way of knowing whether, and why this piece of knowledge is applicable in a new application setting.

For arriving at such an explicit description of viewpoints, the notion of "ontology" is introduced.

2.3 The notion of ontology

In KACTUS we use the notion of ontology to describe the underlying structure of pieces of knowledge. One can see ontologies as a natural "next step" in the increasing complexity of data models. There is no hard borderline between complex semantically-rich data models and ontologies. Ontologies specify what is called a "conceptualization": a way to view the world. Every ontology thus incorporates a particular viewpoint. An ontology contains definitions that provide us with a vocabulary to talk about a domain of discourse. How these definitions look like depends on the language that we have chosen to represent ontological definitions.

Two features are typical of ontologies: the fact that there can be multiple ontologies (= viewpoints) on the same domain, and the fact that we can identify abstraction levels of ontologies on top of each other. We discuss both features in more detail:

Multiple ontologies Assume we have some artifact such as a ship. One can define multiple viewpoints on a ship. Well-known examples of such viewpoints are the physical structure ("what are the parts of a ship?") and the functional structure ("how can a ship be decomposed in terms of functional properties?"). Although these two viewpoints often partially overlap, they constitute two distinct ways of "looking" at a ship. The purpose of an ontology is to make those viewpoints explicit. For a design application, such as a CAD application, one would typically need a combined physical/functional viewpoint: a combination of two ontologies. For a simulation application (e.g. modeling the behavior of a ship) one would need an additional behavioral viewpoint. Many other viewpoints exist such as the process type in the artifact (heat, flow, energy, ...). Each ontology introduces a number of specific "conceptualizations, that allow an application developer to describe, for example, a heat exchange process. As stated earlier, the main observation that lies at the heart of KACTUS is the observation that for reuse it is necessary to make these viewpoints explicit.

Levels of ontologies Ontologies are not just a flat set of descriptions of conceptualizations. Typically, one can identify several levels of abstractions on which ontologies can be defined. For example, in an electrical network domain we could have a set of ontologies of an electrical network in the Basque country in Spain, describing how the various sub-stations and their sub-parts together make up a network. We can first try to generalize from this "Basque" ontology, and try to come up with ontologies for electrical networks in general. A second generalization step would be to define for those ontologies describing electrical processes in the network a general ontology for electricity processes, independent of whether it is a electrical network or some other artifact in which the process takes place. Yet another level up, we can think about general categories of knowledge structures. What are the general characteristics of things that we can structurally divide up in parts? Or of connections between components?

As we will see in the next section, these generalization levels provide us with a useful typology of ontologies, that can be used an organizational principle for a library of ontologies. If we characterize ontologies using the multiplicity and abstraction features we end up with a whole network of ontologies, with many interrelations. At this point one might think that we are becoming overly ambitious here. It is clearly not feasible to try to describe the whole physical world in terms of ontologies. Philosophers have tried to do this for ages, and have not come up with complete categorizations of the world. As will become clear, KACTUS solves this problem by taking a pragmatic, bottom-up approach to ontology identification, in which use and reuse of an ontology in applications is the main criterion. Also, limiting ourselves to technical artifacts makes life a bit easier.

2.4 Types of ontologies

We have identified four major types of ontologies. The generalisation level is the dimension on which this typology is based. We discuss each of the ontology types briefly.
Application ontology
An application ontology is simply an ontology used by an application. We use the term in a similar fashion as Gennari et al. (1994). It contains the information structures we use for building a software system. It can be very specific for this application, or also have general features. In KACTUS we are interested in the question how one can flash out the meaning of parts of an application ontology for future reuse, and how we can construct (part of) an application ontology from existing ontologies.

Domain ontology
Domain ontologies are ontologies that are specific for a particular type of artefact. Example domain ontologies could be ontologies for ships, oil platforms, and electrical networks. A domain ontology generalises over particular application tasks in that domain. Thus, a domain ontology for ship design would need to be independent of both a design assessment application, and of a design construction application.

Basic technical ontology
Basic technical ontologies generalise over particular artefacts, and describe general features of artefacts. Basic technical ontologies usually define a viewpoint related to some physical process type: flow, heat, energy, power, electricity. Such processes reappear in many different technical domains. For example, flow processes occur in both oil platforms and in electrical networks.

Generic ontology
A generic ontology describes a "top-level category". One can see a generic ontology as a basic mechanism for "carving up the world". It is related to the Aristotelian notion of categories. The main difference is that in KACTUS we are not aiming at a complete set of generic ontologies, but are only interested in those categories that frequently occur. Example top-level categories that were identified are notions like physical, functional, and behavioural entities, connectedness, part-whole, and topology.

2.5 Ontology specification languages

Ontology specification languages are tools for writing down ontologies. In principle, we could use any language for describing an ontology: a traditional data modeling language, a programming language, etc. But one often notices that such languages are "blunt" tools for describing ontologies: they lack the required expressivity for writing down what we want to say. Ontology specification languages are specialized tools. They are usually derived from traditional data modeling languages, but contain additional constructs that make them appropriate for writing down knowledge-intensive conceptualizations.

Typical additional language primitives include:

In KACTUS we selected three ontology specification languages for usage in the project, namely the STEP modeling language EXPRESS (Spibey, 1991), the CommonKADS modeling language CML (Schreiber et al., 1994), and the Ontolingua language (Gruber, 1993) developed in the context of the US knowledge sharing effort. This choice was based on the following grounds:

The choice for these three languages is thus primarily pragmatic. Other languages including advanced data modeling languages such as the proposed in the "Unified Method" of Rumbaugh and Booch could serve a similar purpose. The key lies in the content of what is represented in an ontology, not in the representational syntax used[1].

The use of multiple languages has made life more difficult for the KACTUS tools. The toolkit constructed within KACTUS had to have facilities to cope with this variety of languages in a consistent and transparent way. A discussion on the tools is however outside the scope of this paper (see http://www.swi.psy.uva.nl/projects/void/roadmap.html for a description of the functionality of the toolkit).

3 Application Construction

The purpose of KACTUS is to supply a set of methods and tools, that can act as an "add-on" to existing software-development approaches. Figure 3 shows a graphical overview of the KACTUS approach. In this figure, the overall software-development approach is CommonKADS, but this could have been any other approach as well.

Central is the role of a library of ontologies. This library contains a number existing definitions organized along the levels of abstraction described before. Three types of ontologies are placed in the library: domain ontologies, basic technical ontologies and generic ontologies. As application ontologies are considered specific for a particular application, these are not stored in the library. shows the features that were used to index the ontologies in the library. The KACTUS toolkit supports searching for ontologies using these features, and also supports searches for names of individual definitions.

Figure 3: Application construction with the help of KACTUS. KACTUS methods can be used as an add-on to system-development techniques. In this figure, CommonKADS is the sample development technique. The thick arrows are the denote activities in the development process supported by KACTUS.

In KACTUS we have constructed a library containing the ontologies used in the technical domains the project is concerned with. However, we do not assume that there should be just one large library. Typically, companies/organizations will want to set up their own shared set of ontologies.

KACTUS sets out to support four types of activities (see the four arrows in Figure 3):

Ontology construction
How can one split up an application ontology in a set of ontologies that characterise the main viewpoints taken by the application on the domain? KACTUS tries to provide a number of design guidelines for ontologies which ensure that the ontologies resulting from the application can (partly) be placed in a library.

Ontology reuse
Assuming an ontology library is available, how can one select ontologies from this library that are potentially useful for a new application.

Typically, application development is in fact a combination of ontology construction and reuse. Some ontologies already exist and can be taken from a library. Other required conceptualisations might not be provided by the library, and have to be constructed from scratch.

Library maintenance
How should a library of ontologies be organised and maintained? The KACTUS library is organised in a hierarchical fashion, using the four types of ontologies as the basic structuring principle. The notion of ontology mapping is used to define relationships between ontologies, for example that a decomposition of ship elements adheres to the semantics of a generic ontology describing part-of decompositions of physical elements. See for a more detailed description of ontology mappings Benjamin et al. (1996).

The KACTUS toolkit provides facilities for importing, organising, merging, editing, and exporting ontologies in the three languages used in KACTUS (EXPRESS, CML and Ontolingua). In addition, knowledge bases containing "instances" of the definitions present in an ontology can be imported, stored and exported.

Application code generation
Application code generation is a feature of the KACTUS toolkit. When an application developer decides to use an ontology and/or an associated knowledge base, he can use an application programmers interface (API) to generate application code. Currently, the toolkit has an API for Prolog, C and C++. In the experiment described in the next section the Prolog API was used in building the application.

Index feature

possible values
used in application
<application name>
used by task type
diagnosis, design, configuration, assessment, planning, scheduling, prediction, assignment, ...
used by problem-solving method
systematic diagnosis

propose-and-revise

......

used in domain
oil production process

ship design

electrical network

Table 1: Indexing features for ontologies in the library

One feature of the approach is that it provides a principled way for supporting interoperability of applications through exchange of knowledge or complex (semantically rich) data. This type of interoperability is shown schematically in Figure 4. If one can assume that two applications share the same ontology (which is typically a sub-part of the overall application ontology of an application), then the two applications can exchange information that is based on this shared ontology. The exchange procedures can be very simple or elaborate, depending on the differences in implementation-specific representation choices, but the application developer can be sure that information exchange is always technically feasible. A number of examples of exchange based on shared ontologies exist. For example, in the Sisyphus-VT experiment (Schreiber & Birmingham, 1996) several contributors were able to reuse an existing knowledge base of elevator components and constraints in their application, even if their application was written in an entirely different implementation language. Typically, each application added its own application-specific conceptualizations, based on the different ways in which the design task was realized. Ontologies served the role of explicating which parts of an application knowledge base can be shared, and which parts cannot.

In the ship-design domain in KACTUS this "shared ontology" approach is used to enable the exchange of ship-design data between the ship designers and the ship assessors, although designers and assessors have quite different ways of "looking" at a ship design. More details on this application can be found in Martil et al. (1995). In the next section an experiment is described in which a small application is built in a short time-frame (one week), in which data/knowledge exchange based on a shared ontology is the key issue.

Figure 4: A schematic description of how interoperability between applications can be achieved. The two applications use the same set of ontologies in their application analysis model (e.g. a CommonKADS expertise model or a STEP application protocol). Each application typically also has additional ontologies, but uses the shared ones to exchange data between applications.

4 Experiment

The experiment presented here was set up to illustrate the use of the KACTUS framework for reuse and how interoperability between applications can be achieved, in a real-world and running application. The application task was suggested by Iberdrola, one of the Spanish electricity companies. The application involved designing and building a system to generate, automatically, procedures to test equipment at fault in electrical networks. This is a real-world task which is currently done by the Iberdrola operators. The goal of the experiment was to show that with the aid of the KACTUS approach and toolkit, it was possible to build an application for this problem within one week.

4.1 Problem description

The transmission of electricity through an electrical network is a highly dynamic process characterized by a continuous change of state. This change of state may be due, amongst other reasons, to automatic network reconfigurations due to the occurrence of disturbances. This automatic network reconfiguration is done by the protective equipment set up in the network to isolate the equipment causing a fault, as fast as possible, and minimizing the number of equipment isolated. Still, this automatic reconfiguration might not be enough to avoid overloading of other equipment and/or failure to supply energy to a subset of consumers. In these situations, a second kind of reconfiguration needs to be performed (currently by an operator) to eliminate the overloads and provide service to all customers. Sometimes, this is not possible without putting into service the equipment considered to be at fault.

To perform the reconfiguration, operators first need to know whether the fault is temporal or permanent. If a fault is permanent, the equipment at fault is damaged and it requires sending a maintenance crew into the field in order to repair it. As a consequence, the equipment cannot be used during reconfiguration. If, on the other hand, a fault is temporal it disappears after a while, and no equipment is damaged. In this case the equipment at fault can be put into service again and the state of the network previous to the fault can be recovered.

Figure : Duero area 132 kV network. Ovals denote substations (e.g., Ricobayo at the top-center), squares with a twiddle and a number denote generators and their number, lines between ovals denote electrical lines, and the small circles hanging from the substations denote transformers

At the point in time when an operator has to decide whether a fault is temporal or permanent, the equipment at fault has been isolated automatically by the protective equipment in the network. This means that the operator does not get information about the state of the equipment from the data acquisition system SCADA (Supervisory Control And Data Acquisition system). Also, information about loads has been lost. In this situation, there are only two ways to find out know what the actual state of the equipment is. One way is to send a crew into the field to inspect the equipment and report back. The time and advanced planning required to do this makes this solution unattractive. The second solution involves assuming that the fault is temporal, and putting the equipment (previously at fault) into service again. If, after putting it into service, the protective equipment isolates the faulty equipment again, it means that the previous fault was permanent and the equipment cannot be used for reconfiguration. Although more risky because of potential additional damage, this second solution is sometimes considered feasible by the electrical companies, and it is the one generally adopted. When putting the equipment into service, the electrical utilities have established a strategy to minimize the risk of damaging the equipment or endangering the stability of the network. This strategy has to be followed by the operators when generating procedures for testing damaged equipment.

Figure 6: Exact reproduction of the display that operators get on their screen when requiring details of the Duero 132 kV network. Anecdotally, this display covers not just the 132 kV Duero network (shown on the middle-left side of the display) but also part of a 132 kV area not belonging to Duero (right side of the display). Black squares are closed breakers, and white squares are open breakers. The numbers are values of voltage and power flow. Thicker lines are bus-bars, and thinner ones are electrical lines. Circles with a G inside are Generators, and arrows going out of breakers are loads (or consumers).

The objective of the system built in this experiment is to automate the generation of procedures for testing equipment at fault, following the strategy established by the electrical utilities. The output of the system should be the actions an operator has to follow to perform the test.

Once a suitable problem was identified, the next step was to restrict the scope of the problem, such that it would still be a real-world problem and at the same time feasible to tackle within a limited period of time. In terms of the electrical network controlled by Iberdrola, the scope of the system is the 132 kV network in the Duero region (see Figure 5). This network is spread over 72.000 km2 (one seventh of the Spanish territory). In terms of size, it is approximately 5% of the high voltage network controlled by Iberdrola. This is a real network, and we have taken into account real power measurements (although they are not taken on-line). Figure 6 shows a display with further details of substations and equipment in this network area.

The system implements the strategy established by the electrical utilities to test equipment at fault and generates testing procedures for operators to follow. This strategy is described in Appendix A. Figure 7 shows the inputs and outputs of the system.

The system should get three inputs:

Figure 7: System inputs, output and interoperability with other systems. The structural ontology is used by the diagnosis system as well as the generator of testing procedures (see the next section for a description of the ontology and how it is used by the application).

1. Equipment at fault
This the equipment for which a testing procedure has to be generated. Under operating conditions, the equipment at fault would be the output of the diagnosis system (an existing knowledge-based system which, given a set of alarm messages, outputs the equipment most likely to be at fault). In this demonstrator, however, it is given by the user of the system.

2. Static network data
The static network data is the configuration of all the equipment in the area. These data are extracted from the Iberdrola's company database. In this demonstrator, it is a file automatically generated from the input data files provided by IBERDROLA but limited to the 132 kV Duero area. The data files were not pre-processed, but constituted the original company

3. Current network situation
The current network situation is the dynamic situation of the network, which contains information about the connectivity of the network and its loading conditions, at a certain instant of time. This information is acquired by the SCADA system.

The system has three outputs: the testing border[2] candidates, i.e., the nodes from which energy could be supplied to the faulty equipment during the test; the best testing border, i.e., the node from which energy should be supplied to the faulty equipment during the test to minimize the risk of damaging other equipment or endangering the stability of the network; and the testing procedure, i.e., the opening and closing operations that have to be performed by the operator during the test to supply energy to the faulty equipment and see if the equipment is operational again.

Figure 8: The set of ontologies build for the service recovery and diagnosis applications. These ontologies reside in the KACTUS library.

4.2 System construction process

The assumption behind the system construction process was that we could reuse an existing ontology of the electrical network developed in the context of two earlier applications. The full set of ontologies for this domain that, in the KACTUS ontology library are shown in Figure 8. The "structural-ontology" provided the baseline for the experiment (to which we will refer in the sequel as "the ontology"). Figure 9 shows the steps followed during the system construction process.

First, a mapping was developed from the ontology to the static network data (the first input to the system). The static network data resided in a Iberdrola company database, and used the Spanish language. The two translate processes at the left of Figure 9 transform the data from the database format into the ontology instance format: first from the database format to Prolog (the chosen implementation language) and then from Spanish to English. The instantiate process maps the instances produced by the translate steps onto the ontology. This process generates a number of new instances that can be derived from the axioms in the ontology. For example, the ontology defined how equipment could be associated with other equipment: background knowledge which is relevant for the application. These new data are in fact data that were implicit in the original database. Subsequently, the dynamic network data (the second and third inputs) are read in. These data are obtained from the SCADA system and are also mapped into ontology instances. The full set of input data, now represented as ontology instances, is then read into the application.

Figure 9: Steps taken to design and build the application reusing the structural ontology from the KACTUS library. Inputs to the system are signaled by an I on their left hand side, and outputs by an O underneath.

Figure 10 shows the contents of the "structural-ontology" which has been renamed to "electrical-structural-ontology". The hierarchy shows the different kinds of "static-equipment" used by the application and the drawing shows the relations between "bus-bar" and other concepts. The relation "connected-to" means that a "bus-bar" can be physically connected to another equipment. The relation "current-connection" means that there can be an energy flow to other equipment.

In Appendix B excerpts from the original data and the way these are processed can be found, to illustrate the transformation process described in Figure 9.

Once all aspects related to the input of static and dynamic network data were implemented and installed (with the help of the KACTUS toolkit as mediator), the rest of the system was implemented and tested. This implementation contains two parts: a simple graphical user interface and the implementation of the two main algorithms: (i) choosing the best border from which the equipment at fault should be energized, and (ii) the generation of the testing procedure. A snapshot of the running system is shown in Figure 11.

The system was developed in XPCE-Prolog and it was tested until the results obtained were considered satisfactory. Satisfaction in this case, means that having tested 80% of the data, all the testing borders and procedures given by the system are correct. It should be pointed out, however, that further testing by users from Iberdrola is required to tune the values of the constants that are used in the algorithm (i.e., the "magic numbers" drawn from experience, see Appendix A).

Figure 10: This figure shows the theory browser of the KACTUS toolkit. The browser displays the contents of the "structural-ontology" which has been renamed to "electrical-structural-ontology". The hierarchy shows the different kinds of "static-equipment" used by the application and the drawing shows the relations between "bus-bar" and other concepts. The relation "connected-to" means that a "bus-bar" can be physically connected to another equipment. The relation "current-connection" means that there can be an energy flow to other equipment.

4.3 Results

The output of the experiment has been a prototype of a real application for testing equipment at fault in electrical networks, which has been tested and debugged using real data from Iberdrola[yen]s network. This prototype, together with the translators, etc. required for the correct representation of the real data were designed and implemented in one week, and took approximately 12 days of effort by three people.

An important point to make is that the prototype had two main purposes. The first purpose (highlighted in this paper) is to illustrate the use of the KACTUS framework for reuse. The other, important purpose from Iberdrola[yen]s point of view, was to develop a prototype that could be used as a workbench to tune the testing procedure before implementing it as a final on-line application. The result met both objectives.

Re-using the structural electrical ontology for this experiment highlighted the distinction between static and dynamic knowledge. In this application, the concept node, which is a subtype of a compound structure according to the static definition of the network in the structural ontology, is a dynamic entity, and therefore it makes no sense to include it in the static definition of the network. This is why the static input data from Iberdrola[yen]s database do not include instances of the concept node. However, this conceptual mismatch has severe consequences for the reasoning process in this application (and probably others since this is a concept used in several applications).

KACTUS methods, and in particular methods to reuse an ontology from the ontology library, were used as an add-on to system-development. The electrical network domain ontology was reused to generate the application knowledge base. However, during the system development we did not generate an application ontology, mainly due to time constraints. This does not mean that an application ontology would not have been useful. Concepts such as testing border, procedure, source of energy, permanent fault or temporal fault would be part of such an application ontology. This ontology could have been a possible reusable ontology constructed from the application and to be included in the library.

Interoperability was also illustrated in this experiment. Five applications (Diagnosis, Service Recovery Planning, the Database, the SCADA, and the Generation of Testing Procedures) share the same structural ontology of the electrical network. Each application also has additional ontologies, but uses the shared ones to share data between the applications.

5 Discussion and Related Work

In this work we have shown an example of reusing ontologies by reusing a previously developed domain ontology in a new application. The reuse of this ontology allowed us to save a considerable amount of effort in implementing the application, because most of the knowledge about the network which was needed by the application was made available by other applications.

There are two important aspects to consider within an ontology based framework for reuse. Firstly, a clear organization of an ontology is needed. The ontology may be used by persons that do not know very well the knowledge it contains. In this case, the use of a clear methodology in its derivation is essential to make the knowledge understandable to non experts in the field.

Secondly, reuse is almost never complete. Re-use of any ontology, for different purposes than those for which it was built, will always require modifications or tuning for the new purposes. If these modifications are not performed in a systematic way, reuse of the new ontology is likely to turn out to be difficult.

The approach in which data and/or knowledge are exchanged through a shared ontology has also been applied by some contributors to the Sisyphus-VT experiment. This paper shows in fact another example in which this method for interoperability proves to work. Although the method is simple, the users (in this case, the Iberdrola people) were surprised by the efficiency in which data from other applications could be used in a new application.

The idea of generating an application ontology from other, more reusable ontologies is also present in the PROT...G...-2 approach (Gennari et al., 1994). In their approach, the application ontology is generated from a mapping between a domain ontology and a "method ontology": the representations required by the problem-solving method chosen to solve the task. The main difference is that KACTUS is focused on specifying on the nature of domain ontologies: organizing these ontologies in a library, and in levels of abstraction. In this sense the approaches are complementary, similar to the relation between KACTUS and CommonKADS.

This work also differs from other work on ontologies such as Guarino et al. (1994), because the approach towards ontologies is much more pragmatic. The scope of the KACTUS library is limited to technical domains. Also, the generic ontologies in KACTUS(not discussed in this paper, but see Benjamin et al., 1996) have a different status: these are not meant to provide a more or less complete set of categories to carve up the world. but rather act as useful abstractions of phenomena encountered in technical domains.

Figure 11: Snapshot of the demonstrator. Bus-bar A in Ricobayo (top-center in Figure 5 and bottom-left in Figure 6), named RICOBAYO13B_A, is at fault, the system provides as testing border candidates RICOBAYO13B_B_1 (node containing bus-bar B in Ricobayo), BENAVENT13B_B_1(node containing bus-bar B in Benavente), and VILLAL_I13B_A_1 (node containing bus-bar A in Villalcampo I), all of which are connected to RICOBAYO13B_A_1 Out of these, the system selects as the best testing border BENAVENT13B_B_1. At this point the dynamic connections in the network are the following: the connections of bus-bar A in Ricobayo with the lines that go to the other substations (Benavente and Villalcampo I) are open because the protective equipment has opened them to isolate the fault detected in bus-bar A ("open" means that no energy flows through the connection). The connections of Benavente and Villalcampo I with Ricobayo are closed (energy flows though the connection) because the fault is already isolated in Ricobayo. The testing procedure, thus, involves allowing energy to flow only from the best testing border, BENAVENT13B_B_1, to the equipment at fault, RICOBAYO13B_A, and not from Villalcampo. The procedure only requires one operation in this case: "close connection RICOBAYO13L_BNV_C" which closes the connection between Ricobayo and Benavente to allow the flow of energy from Benavente to Ricobayo.

Acknowledgments We are grateful to all participants in the KACTUS project for the many discussions about the ontologies and reuse, which provided the basis for the work described in this paper. The research reported here was carried out in the course of the KACTUS project. This project is partially funded by the ESPRIT Programme of the Commission of the European Communities as project number 8145. The partners in the KACTUS project are ISL (UK), LABEIN (Spain), Lloyd's Register (United Kingdom), STATOIL (Norway), Cap Programmator (Sweden), University of Amsterdam (The Netherlands), University of Karlsruhe (Germany), IBERDROLA (Spain), DELOS (Italy), FINCANTIERI (Italy) and SINTEF (Norway). This paper reflects the opinions of the authors and not necessarily those of the consortium.

References

Benjamin, J., Borst, P., Akkermans, J. M., and Wielinga, B. J. (1996). Ontology construction for technical domains. In N. R. Shadbolt, K. O'Hara and A. Th. Schreiber (eds.) Advances in Knowledge Acquisition: Proceedings Ninth European Knowledge Acquisition Workshop EKAW'96, pp. 98-114, Lecture Notes in Artificial Intelligence, volume 1076, Berlin/Heidelberg, Germany, May 1996. Springer Verlag.

Bernaras A., Laresgoiti I., BartolomÈ N. and Corera J. (1996a). An ontology for fault diagnosis in electrical networks. In O.A.Mohammed & K.Tomsovic (eds.) .Proceedings of the International Conference on Intelligent Systems Applications to Power Systems, pp. 199-203, Florida, USA.

Bernaras A., Laresgoiti I. and Corera J. (1996b). Building and reusing ontologies for electrical network applications. In Proceedings of the European Conference on Artificial Intelligence, pp. 298-302, Budapest, Hungary.

Chen, P. P. S. (1976). The entity relationship model -- toward a unified view of data. ACM Trans. on Database Systems, 1:9--36.

Gennari, J. H., Tu, S. W., Rotenfluh, T. E. and Musen, M. A. (1994). Mapping domains to methods in support of reuse. Int. J. Human-Computer Studies, 41:399-424.

Gruber, T. (1993).A translation approach to portable ontology specifications. Knowledge Acquisition, 5:199--220.

Guarino, N., Carrara, M. and Giaretta, P. (1994). Formalizing Ontological Commitments. Proceedings AAAI'94, Seattle, Morgan Kaufmann.

Martil, R., Turner, T., and Terpstra, P. (1995). Knowledge Reuse in Technical Domains: The KACTUS Project. In Proceedings of The Impact of Ontologies on Reuse, Interoperability and Distributed Processing, Unicom Seminar, London.

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W. (1991). Object-Oriented Modeling and Design. Englewood Cliffs, New Jersey, Prentice Hall.

Spibey, P. (1991).Express language reference manual. Technical Report ISO 10300 / TC184/SC4/WG 5, CADDETC.

Schreiber, A. T., Wielinga, B. J., Akkermans, J. M., Van de Velde, W., Anjewierden, A. (1994a). CML: The CommonKADS conceptual modeling language. In Steels, L., Schreiber, A. T., Van de Velde, W., editors, A Future for Knowledge Acquisition. Proceedings of the 8th European Knowledge Acquisition Workshop EKAW'94, volume 867 of Lecture Notes in Artificial Intelligence, pages 1--25, Berlin/Heidelberg. Springer-Verlag.

Schreiber, A. Th., Wielinga, B. J., Akkermans, J. M., Van de Velde, W., and de Hoog, R. (1994b). CommonKADS: A comprehensive methodology for KBS development. IEEE Expert, 9(6):28-37, December.

Schreiber, A. Th. and Birmingham, W. P (1996). The Sisyphus-VT initiative. Int. J. Human-Computer Studies, 44(3/4):275-280, March/April. Editorial special issue.

Appendix A: Strategy for testing equipment at fault

An equipment at fault is tested only if its recovery is essential to provide service to customers. Transformers, generators, and loads are not tested due to the economic impact that any damage to such equipment would produce. Under these restrictions the strategy for testing, also implemented in the system, is as follows:

1. Identify all the energised borders surrounding the equipment at fault.

2. Choose for testing, those borders that do not cause the loss of loads or generators.

3. If rule 2 does not apply, choose a border with hydraulic generators.

4. If rules 2 and 3 do not apply, choose the border that may cause the loss of the minimum industrial loads in MW.

After classifying the energized borders according to these criteria, the following preference rules are used to choose between equivalent options:

< Choose the border with the minimum short-circuit power.

< Choose for testing the border that connects the equipment at fault with the line of highest impedance (longest), if the equipment at fault is a bus-bar.

< Choose the border that is equipped with quick reacting protective relays.

After classifying the borders according to the criteria, their preference is established taking into account the existing configuration:

a) Choose for testing those borders whose configuration is of the type breaker and a half and test the equipment by closing the lateral breaker.

b) If rule "a" does not apply, then choose a double bus-bar configuration.

c) If rules "a" and "b" do not apply choose a single bus-bar configuration.

All the criteria can be compiled into the following formula:

TB = Kgl * (1000 * Thermal + 3 * hydraulic + 5 * SUM(loads)) + Ksip * ( (Pcc-1) + INV(line impedance) + 0 (for a border with a 0 zone type of protection) + 3 (for a border with a 2 zone type of protection) + 5 (for a border with other type of protection)) + Kc * (0 (for a Breaker and a half configuration) + 0.5 (for a double bus-bar) + 1 (for a single bus-bar))

where:

Kgl = Constant factor for Generation and Load.

Ksip = Constant factor for Short-circuit power, Impedance and type of protective relay.

Kc = Constant factor for substation Configuration.

The values of loads, short-circuit powers, and impedances are normalized, and the constants and coefficients are drawn from experience.

Appendix B: The original Iberdrola data and their processing

Orginal data

The instances of the ontology as generated by existing Iberdrola software are shown below. For example, "BARRA" is Spanish for "bus-bar" and "CONEXIONES" is Spanish for "connection" (i.e. the "connected-to" relation in the ontology).

BARRA 246

NOMBRE: AGAVANZA0GB___A_

CONEXIONES:

32 #AGAVANZA0GG_1321_C

33 #AGAVANZA0GG_1322_C

2463 #AGAVANZA0GTM1321_C

NIVEL_TENSION: 12 #AGAVANZA0G

SUBESTACION: AGAVANZA

#TIPO_DE_BARRA: BARRA_REAL

#TENSION_NOMINAL: 6.6

#AREA: 1

BARRA 247

NOMBRE: AGAVANZA13B___A_

CONEXIONES:

1810 #AGAVANZA13LT1CB__C

2462 #AGAVANZA13TM1321_C

NIVEL_TENSION: 13 #AGAVANZA13

SUBESTACION: AGAVANZA

#TIPO_DE_BARRA: BARRA_REAL

#TENSION_NOMINAL: 132

#AREA: 1

Readable data

A small script translates the Spanish to English and reformulates the contents such that it can be read by the application. The first line should be read as: "something with the identifier 246 is an instance of the concept "bus-bar". The second line should be read as: "the current instance (246) has an attribute called name with the value AGAVANZA0GB___A_".

concept('bus-bar', 246).

attribute(name, 'AGAVANZA0GB___A_').

relation('is-connected-to').

relate(32, 'AGAVANZA0GG_1321_C').

relate(33, 'AGAVANZA0GG_1322_C').

relate(2463, 'AGAVANZA0GTM1321_C').

attribute('part-of-VP', 12, 'AGAVANZA0G').

attribute(obsolete, 'AGAVANZA').

concept('bus-bar', 247).

attribute(name, 'AGAVANZA13B___A_').

relation('is-connected-to').

relate(1810, 'AGAVANZA13LT1CB__C').

relate(2462, 'AGAVANZA13TM1321_C').

attribute('part-of-VP', 13, 'AGAVANZA13').

attribute(obsolete, 'AGAVANZA').

Current connections

The current connections are read as a simple database:

'current-connection'(32, 246).

'current-connection'(33, 246).

'current-connection'(2463, 246).

'current-connection'(1810, 247).

'current-connection'(2462, 247).

Current loads

The current loads are read as a simple database:

'current-active-power'(135, 4.000000).

'current-active-power'(136, 5.200000).

'current-active-power'(137, 10.600000).

'current-active-power'(138, 9.700000).

[1] "Representational promiscuity, but ontological chastity"!

[2] Borders are substations from where the equipment at fault can receive energy.