Ontology-Centric Knowledge
Organization

Hideaki Takeda, Michiaki Iwazume, and Toyoaki Nishidaftakeda, mitiak-i, nishidag@is.aist-nara.ac.jp

Graduate School of Information Science
Nara Institute of Science and Technology

Abstract
In this paper, we introduce ontology-centric knowledge organization approach to build engineering knowledge base systems.

Ontol-

ogy is an intermediate level of information representation between themodel and the media level representations. They also work to bridge
multiple models and multiple users. In order to realize knowledge basesystems based on this approach, we investigated ontologies from two
points of view. One is how to formalize ontologies that can represent
multiple de nitions for concepts. We propose to formalize ontologies
by aspects and discuss its nature.

The other is how ontologies canwork to deal with information. We show ontology-based information
navigation system called IICA that can collect, classify, and extract information on WWW. Ontologies here work as background knowledge
to handle enormous and heterogeneous information.

1

1 Introduction
We are surrounded by enormous information supplied by electrical ways.
Such information was once well-de ned and well-organized, but nowadays
much more ill-de ned and poorly-organized information is supplied. We
need ways to organize such information in order to obtain information related to our purpose.
One way to accomplish it is syntactical approaches like database views
and text search. Database views approach is e ective only where each information source is well-organized. Not only there is much variety of information sources, but also current information sources are themselves diverse andmessy. Text search method is powerful and robust, but it becomes dicultto get meaningful results because of growth of information sources.
Content-based approaches are, thus, needed for such information sources
instead of syntactical approaches. Ontology is a key concept for integrationof heterogeneous information, because it commits ontology and partially formalized. In this paper, we purpose ontology-centric knowledge organization
approaches for integration of enormous and heterogeneous information.
In Section 2, we examine how human organize various and heterogeneous
information according to her purpose and show an architecture for knowledge organization. In the Section 3, as theoretical background, we discuss
formalization of ontology and extend it to deal with various information
sources. In the Section 4, we discuss practical value of ontology by showing
use of ontology for information handling like collecting, classi cation, andextraction. In the last section, we summarize this paper.
2 Ontology-Centric Knowledge Organization
In this section, we discuss how human organize heterogeneous information
especially in engineering, and show an architecture for knowledge organization.

2.1 Human Activity for Knowledge Organization

Since design is one of most important goal of engineering, engineers' thought
is condensed in this process.
Design is a process of creating new artifacts, especially creation of speci cations of new artifacts for manufacture from given requirements[13]. Although it is a visible and apparent process in design, there is another, usu2

ally invisible but also important process in design, namely, reorganization ofknowledge. When a new requirement is given to engineers, they sometimes
survey their internal knowledge like experience and expertise and sometimes
collect external knowledge like books and catalogs in order to solve the given
requirement. Such introduction of new knowledge and re-interpretation ofexisting knowledge cause engineers' knowledge to reorganize to adapt current and future design tasks. In this paper we focus on this process, inparticular, process of representation of unstructured information gatheredfrom outer world.

2.2 Information Levels

Most crucial part of information organization is not in well-structured information but in unstructured one. Engineers use various kind of informationfrom physical models to natural languages. We have usually paid attention to so-called \model", e.g., 2/3D model, some mathematical model likethermodynamics and kinematics. Since models are well investigated and understood, there are many books and studies to handle them. But models are
not sources but results of knowledge organizing formed after much engineering and scienti c e ort. Individual engineers try to capture unstructured
information, and some excellent and common organization of information
can become models. Much of their work is done with unstructured information.
Figure 1 illustrates levels of information to deal with. The lowest levelis \model" level, i.e, information represented as models. The middle levelis \formalization" level, where information is represented by some formal
language. The di erence between the model and formalization levels is thatthe former has syntax and semantics, and the latter has only syntax. The
top level is \media" level where information representation is only restrictedby property of medium which is represented in.
All of these three levels are needed for engineering work, because realengineering problems are not closed in a single model but should be solvedin multiple models. In general, the lower levels can deal with only speci cdomains and can o er speci c solutions in those domains. On the other
hand, the upper level can deal with wider domains but can o er less speci csolutions. The middle level can o er interface between both levels.
Design process is performed by penetrating the media, formalization,and model levels in order (see Figure 1). When domain of design is quite
new, much e ort of design is done in the media level before going the lower
3Engineer
IntentionMedia Level
Formalization Level
Model Level
Product

Figure 1: Levels of Information Representationlevels. On the other hand, when domain is well investigated, the media levelis relatively less important and much work is done in the model level.
The same situation happens when engineers communicate to each other(See Figure 2 ). They are sometimes devoted to communication in the modellevel, and sometimes wandering from the model level to the media level.

2.3 Role of Ontology in Knowledge Representation

We discuss the formalization level as \ontology" in this paper. Although
ontology cannot capture all functions of the formalization level, it can o er
one way to connect the media and model levels.
Ontology is a term in philosophy and de ned as \the branch of metaphysical enquiry concerned with the study of existence itself" [3]. In AI community, an ontology is de ned as \an explicit speci cation of conceptualization"[5]which is intended to use as base for knowledge representation. Ontology isrepresented as systems of symbols in computers, i.e., symbols and theirrelations represents concepts and their relations. Ontology commits only
declarative nature of systems of concepts because its purpose is to provide
consent for knowledge representation, e.g., identi cation of concepts. Therefore ontology is adequate as representation for the formalization level.
4Engineer

EngineerMedia Level
Formalization Level
Model Level

Figure 2: Levels of Information Representation for Communication

2.4 An Architecture for Ontology-Centric Knowledge Organization

The above discussion leads us an approach for knowledge based systems
called ontology-centric knowledge organization. In this approach, roles of
ontologies are bridges between multiple models, between the model and the
media level representation, and multiple users.
Figure 3 shows an architecture for engineering knowledge and communication bases called ICoB (Intelligent Corporate Base) which is based on
ontology-centric knowledge organization approach.
There are servers which contains shared documents and communication
messages, and clients each of which an engineer uses. Users can retrieve or
submit documents or communication messages by using shared and private
ontologies. The ICoB servers organize documents and messages by using
ontologies which consist of shared and users' ontologies. At the same time,they can extend and their ontologies by referring and comparing sharedand other private ontologies. The latter process corresponds organization of
information we discussed in the previous section. ICOB clients and servers
can have some facilities to assist users' information organization.
There are some projects and studies related to this approach. For example, PACT Project[1] is a good example for integration of engineering
5

ICOB Client
ICOB ServerDocument/
Message
Browser

Message Server

Ontology
Broswer/
EditorNagivation
AgentsDocument Server
Network
Texts/Semistructured texts
Ontologies
Organizig Agents
Other ICOB
servers

Figure 3: Architecture for Intelligent Corporate Baseprocess with multiple engineers. Ontolingua Server Project at Stanford[2]is studying an testing collaborative ontology construction. Enterprise modeling (e.g., Ref. [9]) is partially related to it. While these systems expect
knowledge engineers who are di erent from engineers, our aim is to provide
environments for engineers which can be evolved by activities of engineers
themselves.
We investigated this architecture mainly from two points of views. One
is how ontology is de ned and used, i.e., ontology is formally discussed andde ned in logical and syntactical ways. We discuss this in the next section.
The other is how ontology can be used to deal with real information sources,
e.g., WWW information, which we discuss in Section 4.
3 Ontology as Multiple Aspects
In this section, we introduce aspect as component of ontology in order torealize multiple ontologies.

3.1 Aspects

As we mentioned in the previous section, an ontology is related to a conceptualization. Building a large single ontology means that we can model alarge domain by a single conceptualization. It is one of reasons that building
6TempleTemplechief priest

founded year
sectfounderbranch temples
parishioners
doctrine

Temple historical eventsstyle of architecture

namehistorical value

locationarea

events of the year

representative

Templecultural assets

Figure 4: What is Ontology for Temple?
large ontologies is not easy in fact.
We often confuse and force to unify concepts from di erent conceptualization when we try to build large ontologies. For example, Figure 4 shows
how concept \temple" is modeled di erently. One may think temple as itemin textbook of history, so \founded year", \sect", \historical events", andso on are used with \temple". One may think temple as place for religion,
so \doctrine", \parishioners", \branch temples", \chief priest" are concepts
related to \temple". Of course, some concepts are appeared in more than
one aspect like \name" and \location".
Mixture of concepts from di erent conceptualization often confuse us.
Some di erent concepts in di erent aspects may denote the same fact, forexample \chief priest" in aspect-for-temple-as-religious-place and \representative" in aspect-for-temple-as-public-organization may be the same. On theother hand, concepts used in more than one aspect may denote di erent
facts, for example \name" is used in common, but its meaning is either religious name or historical name or ocial name with according to aspect it
is used. In such cases, the more concepts are collected, the less clear are
meanings of concepts.
Each concept is meaningful if and only if concept is used in proper way,that is, concept is used with concepts which come from the same conceptu7

alization. We call this unit aspect. We can say that an aspect is a consistentview for conceptualization. Then ontology can be composed of some aspects.
We use various aspects, for example in engineering we use aspects likedynamics aspects, kinematics aspects. To model the common-sense worldof traveling, we may use aspects like trac aspect or geography aspect.
There are two issues on aspect. One issue is what should be in aspect.
Aspect should have a vocabulary to describe phenomena in its domain. Itshould also have a theory which associates concepts in its vocabulary. And
the theory should be consistent. In the other words, aspect is what we canconceptualize the world without inconsistency1.
The other issue is how to compose aspects from other aspects.
We provide two types of basic connections among aspects. One is combination aspect. This is just integration of aspects for di erent domains. For
example, one of the ways to build aspect-for-travel is to combine aspect-forhotel and aspect-for-trac. In this case, concepts like \railway" which is in
aspect-for-trac do not exist in aspect-for-hotel, because domain of modeling is di erent from each other. In aspect-for-travel, concepts like \tour"
are de ned using concepts from both aspects.
The other is category aspect. This is collection of aspects which sharedomains but come from di erent conceptualization.
When a temple is modeled di erently we have just shown, we can assume
there is a category-aspect-for-temple. This aspect has some speci c aspects
for temple like aspect-for-temple-as-history-textbook and aspect-for-templeas-religious-place as component. Since component aspects share domains, it
is reasonable (but not mandatory) that there are relations among concepts
in di erent component aspects. Such relations are contents of the category
aspects.
Since combination and category aspects can use other combination or
category aspects as component, we can construct large aspects from relatively small aspects. We call such relatively large aspects as ontologies.
Figure 5 is an example how di erent ontologies can be de ned withsharing aspects.
Two aspects can share aspects in their constitution, or be connected bycategory aspects. We call these two aspects are compatible. That is, they
may share or transfer information to each other.
The other important content of aspect is intention, because aspect is abstraction of
the target world by some intention. But intention itself is seldom written explicitly. We
have tried to represent intention of aspect of object modeling as function[14].
18sight-seeing tour

sight-seeing hotel

sight-seeing point

charge withtwo meals

templehotel
itinerary

hotel chargeplacecharge withoutmealbusiness hotelbusiness tour

: category aspect: combination aspect

Figure 5: Multiple and Sharable Ontologies

9In the following sections, we rst describe aspect in a logical framework,and then in a programming framework brie y. Detail discussion is done in
Ref. [12].

3.2 A Logical Formalization of Aspect

Since our basic policy is to de ne aspects constructively, we start from de ning atomic aspect and then de ne more complicated aspects.
We assume a rst-order language LE , and predicate aspect of LE . L isa rst-order language which is the same to LE except predicate aspect isremoved.
3.2.1

Aspect Theory

First we de ne atomic aspect, aspect which does not depend on any otheraspects.
De nition 1 An atomic aspect A with a consistent theory T (A) of a rst
language L and with a unique name aspect(A) satis es the following formula.

aspect(A) $ T (A)aspect(A) is an identi er of aspect which has a similar e ect to the second
argument of predicate ist in Ref. [7], and a modal operator in Ref. [10].
Then, we introduce LmE and Lm as modal extension of LE and L respectively. Here we assume domain of individuals are always the same regardlessof possible worlds. In the following discussion, we assume this language LmE .
A combination aspect is simply de ned as follows.
De nition 2 T (ACOM (A1 ; : : : ; An )), aspect theory of combination aspect
for aspect

A1 ; : : : ; An, is a consistent theory de ned as follows;
T (ACOM (A1 ; : : : ; An)) = aspect(A1 )^ : : : ^ aspect(An ) ^ I (A1 ; : : : ; An )I (A ; : : : ; A )where
1
n is a set of formula of language m [fwhich means inter-aspect theory among 1n.

A ;:::A

L

aspect(A1 ); : : : ; aspect(An )g,

Apparently, it would cause unexpected results if some of aspect theories
share predicates. We ideally assume that if the same predicates appear in10

some aspects, there should share some concepts in them2. In such cases, it
should be represented by category aspects.
On the other hand, a category aspect is more complicated because it
does not imply that both of aspect theories are always true. In order torepresent a category aspect, we introduce modal operators 2 (necessity)and 3 (possibility) and assume S4 modal system. Then a category aspect
for two aspects is de ne as follows.
De nition 3 T (ACAT (A1 ; : : : ; An )), aspect theory of category aspect for aspect

A1 ; : : : ; An, is a consistent theory de ned as follows;

T (ACAT (A1 ; : : : ; An)) = 3aspect(A1 )^ : : : ^ 3aspect(An ) ^ I (A1 ; : : : ; An )I (A ; : : : ; A )where
1
n is a set of formula of language m [fwhich means inter-aspect theory among 1n.

A ;:::A

L

aspect(A1 ); : : : ; aspect(An )g,

I (A1 ; : : : ; An) is again an inter-aspect theory among A1 ; : : : ; A2 .

Since we can use combination and category aspects as component ofaspects, we can de ne hierarchical aspects using combination and category
aspects. In other words, An aspect A is represented A = f (A1; : : : ; An )where A1; : : : ; An are aspects and function f is composed by ACOM and
ACAT .
3.2.2

Inter-aspect Relations

Then we can de ne relations between aspect, inclusion and strict inclusion.
De nition 4 An aspect A is included in aspect B if and only if aspect(B ) `3aspect(A).
De nition 5 An aspect A is strictly included in aspect B if and only if

aspect(B ) ` aspect(A).

Note that there are two reasons for these relations, i.e., one is composition or
category relations among aspects and the other is logical implication. Strict
inclusion corresponds weaker-than relation in Ref. [10].
Similarly, relations between formula and aspect are de ned.
Of course, it is too strict in practise. In programming approach we allows the same
predicates in di erent meanings.
2

11

De nition 6 A formula f is included in aspect A if and only if aspect(A) `3f .

De nition 7 A formula f is strictly included in aspect A if and only if

aspect(A) ` f .

These de nitions mean that there are two types of interpretation of aspect theories. One is represented as strict inclusion which is traditional way
of inter-theory relation. The other is inclusion which takes account of allalternatives of theories. By having two types of interpretation, we can deal
with both strictly a single representation and variety of representations.
Theorem 1 If aspect A is strictly included in aspect B , then A is included
in aspect

B.

Another relation is compatibility which is criteria two aspects are related to each other3.
De nition 8 Aspect A and B is compatible if one of the following con-dition is satis ed;
1.

A and B is the same aspect,

2. there exists aspect

C which has both A and B as component,

3. there exist compatible aspect
respectively.

A and B are components of A and B00

De nition 9 Formula f is compatible with aspect A if and only if there
exists aspect

B in which f is and B is compatible with A.

Compatibility assure neither consistency nor translatability between aspect theories, but denotes existence of connection between aspects.

3.3 ASPECTOL: A Language for Aspects

Here we show a language of aspects called ASPECTOL (Aspect-based Ontology Description Language), which is an extension of Ontolingua-like ontology de nition (see [4]). Syntax of ASPECTOL is shown in Figure 6.
3

Term compatible is borrowed from Ref.[6].

12(de ne-category-aspect aspect-name(:use componet-aspct1, ...)(:category-type category-type)(:rename (aspect!predicate . newname) ...)(de ne-translation aspect-name(=atmoic-formula1 atmoicformula2)((:query-procedure nil or t
:inform-procedure nil or t

(de ne-aspect aspect-nameOntoligua de nitions are here

)

...

>

(a) atomic aspect(de ne-aspect aspect-name(:use componet-aspct1, ...)(:rename (aspect!predicatename) ...))

translation-rule

.

...
))
...
)
(de ne-translation ...)
...

new-

Ontoligua de nitions are here...

)(b) combination aspect

Ontoligua de nitions are here(c) category aspect

Figure 6: De nition of aspect
De nition of an atomic aspect consists of declaration of aspect name andde nitions of classes, relations, and functions. De nition of a combination
aspect is de nition of an atomic aspect and declaration of including aspects.
De nition of a category aspect consists of a set of translation formulae. A
translation formula is de ned between two aspects in a category aspect, andis de ned as define-translation which describes logical relation between
concepts in both aspects. It can represent a class of direct relations between
formulae in two aspects which we have discussed in the previous section. A
left hand side of an implication formula is a formula of the aspect of the rst
argument and a right hand side is a formula of of the aspect of the second
argument.

13

4 Ontology for Information Navigation
The other view of ontology we discuss in this paper is how it can contributeto organize real unstructured information. We built a system called IICA
(Intelligent Information Collector and Analyzer) that can gather, classify,
and extract information on the Internet by using ontologies.

4.1 Ontology-Based Approach for Information Navigation

Information on the Internet, in particular, WWW information is various,
enormous and furthermore totally de-centralized, so that there need services to guide such information. But existing approaches are insucient toorganize information because they treat information without knowledge.
There are mainly two types of services to guide information on the Internet. The rst is so-called \WWW spider" that collects and indexes WWW
pages periodically so that users can ask pages by keywords, e.g., Lycos andInfoseek. The second is directory service that provides hierarchical categories of WWW pages, e.g., YAHOO!. The former is useful when users can
express what they want by keywords, but it is dicult to use when they
have only vague goals. On the other hand, in the latter approach, users cannd their goals just by choosing categories repeatedly so that it is possible
to nd their goals even if their goals are vague. But it depends on how
categories are well maintained.
Ontology-based information navigation proposes a new way of information navigation because information is treated as knowledge. In our approach, users can de ne their goals by browsing ontologies, and then thesystem collects and classi es WWW pages, and furthermore extract information in them. All information in these processes are provided in ontologies(See Figure 7).

4.2 Roles of ontologies

Basically ontologies represent background knowledge that human use consciously or unconsciously when they read pages. For example, suppose
searching information on arti cial intelligence. If you nd a page on expert
systems, you may think this pages is related to your goal even if there are
no descriptions on arti cial intelligence, i.e., string \arti cial intelligence"
or \AI" directly. It is because there is ontological relation between concept arti cial intelligence and concept expert systems, probably the former
14

Internet
WWW
restaurant

1 search/collecttemple2 classify

set of WWW pages

URL name ingredient effecthotspring
3 extract

extracted information

classified WWW pages

As taxonomy
As heuristics for pruning

As features of concepts

ontology

Figure 7: Roles of ontologies in IICA

15

is superclass concept of the latter.
In IICA, there are four roles of ontologies, i.e., ontologies plays di erent
roles in each step in information navigation, i.e., guide for users for choosing
goals, heuristics for pruning search in information gathering, categories in
information classi cation, and features of concepts in information extraction.
We adopt a simple structure to represent ontologies to achieve aboveroles. It is dicult to use strict representation like logical formula because
information sources are not strict either. There are two types of concepts,
i.e., class and attributive concepts, and interclass and class-attribute relations. A class concept has a name and keywords that are used as keywords
in search and classi cation, and attributive concepts which are connectedby class-attribute relation. Class concepts can be connected by interclassrelation which is super-sub relation with weight to represent similarity between two concepts. There are some types of class-attribute relations likehas-some which indicate how many values attributive concepts should hold.
Attributive concept represents one which has one or more values and isrepresented as pattern of words or concepts.

4.3 Processes of Information Navigation

Firstly, users can browse concepts in ontologies and choose some of them as
goals they want. Here ontologies plays guide for de ning goals (See Figure
8).
Then, IICA collects keywords of concepts speci ed by users and thoseof concepts related to these concepts. Then IICA collects links whose titles
include these keywords. It is because concepts close to the given concepts
in ontological relations are also important to nd information, e.g., theirsuperclass or subclass concepts may be used in pages. Ontologies are usedas heuristics for pruning search secondly.
Thirdly, IICA evaluates full texts of the collected pages and classi esthem into concepts in ontologies. In classi cation process, TFIDF method[11] is used. It is e ective when there may be many pages found by search
process (see Figure 9). ontologies are used as categories to classify pages.
Finally, IICA extracts information from pages by consulting attributive
concepts of the given class concepts. Each concepts can have attributive concepts which are represented by patterns of texts and concepts. For example,
concept hot-spring can have four attributive concepts;(define-pclass16

TravelHousing
Hotel(Japanese)
Hotel(Western)
LeisureRecreation Ground
TheatreTheme Park
Zoo
Sea
Excursion Ship
Bay Area
Aquarium
SpringSpring Name
Visiting Place
Type of BathIngredient
EffectSightseeing

Figure 8: Ontology as Interface

Traffic

Sea

Classified
URLs

Sightseeing

Festival
Walk

History
SpringFigure 9: Results of Information Classi cation17

(hot-spring((has-at-least name)(has-some types-of-bath)(has-some ingredient)(has-some effect))))Concept e ect which is one of attributive concepts of \hot-spring" isrepresented as follows;(define-concept(effect(is disease with (or ">" "" "(define-concept(disease(is (or "+ >" "+ >" "+ 痛 >")))")))The rst rule represents that concept e ect is concept disease whichappears with string \"(\ecacy" in Japanese) or string \"(noun\e ect" in Japanese) or string \"(verb \e ect" in Japanese) in a single
sentence. The second is that concept \disease" is a word ending either
character \ " (illness) or \ "(injury) or \ "(ache). As results, IICA canbuild a table as summary of some di erent pages for a concept (See Figure10). In this gure, each row contains values of attributive concepts extracted
from a single page, and each column contains an attributive concept and its
values in those pages. Here ontologies are used as features of concepts when
IICA extracts information form pages.
Some evaluations of this system are found in Ref. [8].
5 Summary
We discussed ontologies from two points of view in order to realize ontologycentric knowledge organization. One is how to formalize ontologies that canrepresent multiple de nitions for concepts. We propose to formalize ontologies by aspects and discussed its nature in a logical framework. The other is
how ontologies can work to deal with information. We show ontology-based
information navigation system called IICA that can collect, classify, and extract information on WWW. Ontologies here work as background knowledge
to handle enormous and heterogeneous information.
It is important how we can represent and handle various information ina uni ed way, as we have shown, but it is merely the rst step to organize
information according to our intention. Further research should be done
to identify how we can externalize new organization of information from18

Spring
name

NearestStationTraffic
MethodType of
Bath

Ingredient

By BusKanaketa JR
Sankaku
Spa
Station

Aerated,chalybeate

On foot

No Special
Ingredient

YoshioSpa

JRYoshioStationFigure 10: Results of Information Extraction
existing information. For example, it is to be solved how to integrate multiple ontologies especially built by multiple users. The other problem is how
knowledge organization by communication can be represented.
We are going to apply our approach to real engineering domains to know
how it can contribute knowledge organization.
References[1] M. R. Cutkosky, R. S. Engelmore, R. E. Fikes, M. R. Genesereth, T. R.
Gruber, W. S. Mark, J. M. Tenenbaum, and J. C. Weber. PACT:
An experiment in integrating concurrent engineering systems. IEEE
Computer, January 1993:28{38, 1993.
[2] A. Farquhar, R. Fikes, W. Pratt, and J. Rice. Collarborative ontology
construction for information integration. Technical Report KSL 95-63,
Knowledge Systems Laboratory, Stanford University, 1995.
[3] A. Flew, editor. A Dictionary of Philosophy. Pan Books, 1979.
[4] T. R. Gruber. Ontolingua: A mechanism to support portable ontologies. Technical Report KSL 91-66, Stanford University, Knowledge Systems Laboratory, 1992.

19

[5] T. R. Gruber. Toward principles for the design of ontologies used forknowledge sharing. Technical Report KSL 93-04, Knowledge Systems
Laboratory, Stanford University, August 1993.
[6] N. Guarion, M. Carrara, and P. Giaretta. Formalizing ontological commitments. In Proceedings of AAAI-94, pages 560{567, 1994.
[7] R. V. Guha. Contexts: A Formalization and Some Applications. PhD
thesis, Department of Computer Science, Stadford University, Stanford,
CA, 1991. (Available as Report No. STAN-CS-91-1399-Thesis).
[8] M. Iwazume, H. Takeda, and T. Nishida. Ontology-based information
capturing from the internet. In Proceegins of the fourth International
Conference on the International Society of Knowledge Organization,
pages 261{272, 1996.
[9] J.Fraser and A.Tate. The enterprise tool set { an open enterprise architecture. In Proceedings of the IJCAI96 Workshop on Intelligent Manufacturing Systems, 1995.
[10] P. P. Nayak. Representing multiple theories. In Proceedings of AAAI94, pages 1154{1160, 1994.
[11] G. Salton and M. McGill. Introduction to Modern Information Retrieval. McGraw-Hill, Inc., 1983.
[12] H. Takeda, K. Iino, and T. Nishida. Agent organization and communication with multiple ontologies. International Journal of Cooperative
Information Systems, 4(4):321{337, December 1995.
[13] H. Takeda, P. Veerkamp, T. Tomiyama, and H. Yoshikawa. Modelingdesign processes. AI Magazine, 11(4):37{48, 1990.
[14] Y. Umeda, H. Takeda, T. Tomiyama, and Y. Yoshikawa. Function,
behaviour, and structure. In J. Gero, editor, Applications of Arti cialIntelligence in Engineering V, volume 1, pages 177{194, Berlin, 1990.
Springer-Verlag.

20