ontology development and evolution: selected approaches

Ontology Development and Evolution:Selected Approaches for Small-Scale

Application Contexts

Annika Ohgren

ISSN 1404-0018Research Report 04:7

Ontology Development and Evolution:Selected Approaches for Small-Scale

Application Contexts

Annika Ohgren

Information Engineering GroupDepartment of Computer and Electrical Engineering

School of Engineering, Jonkoping UniversityJonkoping, SWEDEN

ISSN 1404-0018Research Report 04:7

School of EngineeringJonkoping University

Ontology Development and Evolution

Abstract

This report presents a literature study concerning three areas, OntologyDevelopment Methodologies, Ontology Evolution, and Ontologies in Smalland Medium-Sized Enterprises. The objectives were to find out and sum-marize what has been done so far in the different areas, as well as tofind out what has not yet been done, and thereby discover new possibleresearch areas. Ontologies are widely used as a technique for represen-tation and reuse of knowledge. We believe that ontologies can be usedin small and medium-sized enterprises and help companies by supportingknowledge sharing, reuse of knowledge, inter-operability, and much more.The main conclusion is that a lot of work has been put into Ontology De-velopment, many methodologies are very mature and have been used inpractice. Still, not all of them cover the aspects we are interested in, e.g.reuse of already existing ontologies and covering the whole life cycle. InOntology Evolution, the main focus is on keeping an ontology and its de-pendents consistent, and it does not concern when to make changes, orwhat to actually change. Ontology use in small and medium-sized enter-prises is not so common, but some experiences exist.

Keywords

Ontologies, Ontology Development, Ontology Development Methodologies, Ontol-ogy Evolution, Ontology Use in SMEs



Table of Contents

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

2.1 What are ontologies? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 What can ontologies be used for?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Different types of ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Ontology Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1 The Enterprise Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 TOVE - Toronto Virtual Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 Unified Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.4 Ontologies for conceptual modelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.5 METHONTOLOGY .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.6 Ontology Development 101 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.7 Methodology from Karlsruhe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.8 Summary of Methodologies for Ontology Development . . . . . . . . . . . . . . . 12

4 Ontology Evolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

4.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2 Why the need for ontology evolution?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.3 Different methods and approaches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.4 Automatic Ontology Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.5 Ontology Versioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Ontology Use in Small and Medium-Sized Enterprises 20

5.1 Characteristics of SMEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.2 Applications of Ontologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2.1 NOPIK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2.2 Arisem .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.2.3 SEWASIE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23



References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24



1 Introduction

This report is part of a PhD project at School of Engineering, Jonkoping. The areaof the PhD project is ontology development and evolution with specific use in small-scale application contexts. A literature study has been carried out in the selected areato know what has been done so far, and this report is the result of it. The followingsubsections describe the background and context of the project followed by aim andoutline of the report.

1.1 Background

The PhD project is part of the research area called Information Logistics [7]. Infor-mation Logistics aims at optimising information flow, by serving the right informa-tion, in the right context, at the right time, at the right place, and through the rightchannel. Companies and people are overloaded with information. Take the Internetas an example, with lots of information and mailboxes that are filled with mass-sente-mails that do not concern all receivers. Obviously there is a need for optimisingsearch techniques and personalise information retrieval. Information Logistics sup-port information flow by using not only the information, but also incorporate seman-tics to be able to use more advanced information retrieval techniques. One solutionto this is through the use of ontologies. The need for optimising information flow isespecially important in networks of companies and distributed work groups.

Within companies and organisations there exist lots of well-known terms andknowledge. It is often the case that the information or knowledge is not formally orexplicitly defined, but mostly exists in employees minds, with the consequence thatterms may be used different and no unambiguous definition exists. It might also bethe case that an employee with lots of knowledge quits his/her job and the acquiredknowledge is lost. To avoid this, ontologies can be used to structure and explicitlydefine concepts and terms, and their interrelations.

The PhD project focuses especially on small-scale application contexts, meaningmainly small and medium-sized enterprises (SMEs) and networks of SMEs, and theuse of ontologies to optimise information flow and knowledge handling within suchorganisations.

1.2 Aim

This report aims at describing the state of research, what has been done so far, con-cerning ontology development methodologies, ontology evolution, and applicationsof ontologies in small and medium-sized enterprises. The goal is not only to findwhat has been done, but also what has not been done, and thus show possible future

1



research subjects.

1.3 Outline

The structure of the report is as follows: First, the term ontology is explained togetherwith its usage areas. The next section consists of a discussion of methodologiesfor ontology development. Section 4 describes ontology evolution and section 5discusses characteristics of SMEs, together with applications of ontologies. The finalsection consists of conclusions.

2



2 Basic Concepts

This section describes the concept Ontology, in terms of definitions, usage areas, andtypes.

2.1 What are ontologies?

The term Ontology stems originally from philosophy and refers to the subject of ex-istence. Ontology may also refer to a branch of philosophy that deal with the natureof reality. In computer science one of the most commonly used ontology definitionis from Gruber,an ontology is an explicit specification of a conceptualisation[13].Explicit in this context means that type of concepts and constraints are explicitlydefined and conceptualisation refers to an abstract model of some phenomenon withidentified relevant concepts of that phenomenon. Another definition is made by Borstasan ontology is a formal specification of a shared conceptualisation[2]. Formalmeans that the ontology should be machine-readable, shared reflects that it capturesknowledge that is accepted by a group. Uschold and Gruninger define an ontologyasa shared understanding of some domain of interest which may be used as a unify-ing framework[48]. According to Studer et al,ontologies aim at capturing domainknowledge in a generic way and provide a commonly agreed understanding of do-main, which may be reused and shared across applications and groups[5]. A moremathematical definition is given by the same authors as [21]:

”An ontology structure is a 5-tupleO := {C, R, HC , rel, AO}, consisting of

- two disjoint setsC andR whose elements are called concepts and relationsrespectively.

- a concept hierarchyHC : HC is a directed relationHC ⊆ C×C which is calledconcept hierarchy or taxonomy.HC(C1, C2) means thatC1 is a subconcept ofC2.

- a functionrel : R → C × C, that relates concepts non-taxonomically4. Thefunction dom : R → C with dom(R) := Π1(rel(R)) gives the domain ofR, andrange : R → C with range(R) := Π2(rel(R)) give its range. Forrel(R) = (C1, C2) one may also writeR(C1, C2).

- a set of ontology axiomsAO, expressed in an appropriate logical language, e.g.first order logic.

4 In this generic definition one does not distinguish between relations and attributes.

A lexicon for the ontology structureO := {C, R, HC , rel, AO} is a 4-tupleL :={LC , LR, F,G} consisting of

3



- two setsLC andLR, whose elements are called lexical entries for concepts andrelations, respectively.

- two relationsF ⊆ LC × C andG ⊆ LR × R called references for conceptsand relations, respectively. Based onF , let for ` ∈ LC , F (`) = {c ∈ C |(`, c) ∈ F} and forF−1(c) = {` ∈ LC | (`, c) ∈ F}. G andG−1 are definedanalogously.

In general, one lexical entry may refer to several concepts or relations and one con-cept or relation may be referred by several lexical entries. An ontology structure withlexicon is a pair(O,L), whereO is an ontology structure andL is a lexicon.”

As you can see, instances are not included in the definition, and therefore notseen as a part of the ontology, although other definitions differ in this concern. Anontology with its instances is seen as a knowledge base.

According to Gomez-Perez concepts can be abstract or concrete, elementary orcomposite, real or fictitious, anything about which something is said. Relations rep-resent interaction between concepts of a domain and axioms are used to model sen-tences that are always true. [12]

In the remaining part of this report, the definition by Borst [2] will be used as anexplanation of what an ontology is, if more details are wanted on the technical parts,we refer to Maedche [21].

2.2 What can ontologies be used for?

Ontologies are used for many different areas, Obitko has mentioned some of them[32]; they can be used for expressing domain-general terms in a top-level ontology,for knowledge sharing and reuse, for communication in multi-agent systems, naturallanguage understanding, and to ease document search to mention some of them.

Uschold and Gruninger specify three different categories where ontologies canbe used [48]. The first one is Communication, ontologies can be used to increaseand facilitate communication among people. They can be used to create a networkof relationships, to keep track of what is linked, and use this to navigate and explore.Ontologies provide unambiguous definitions of terms, meaning that people use termsin the same way, and with the same meaning and intention. A shared ontology can beseen as a standardised terminology for all objects and relations in the domain. Thesecond usage area defined is Inter-Operability. Ontologies can serve as an integratingenvironment for different software tools. The third usage are is Systems Engineer-ing, in which ontologies can play an important part in the design and developmentof software systems. They can help to identify requirements of a system and to ex-plicitly define relationships among components of a system. They can also be usedto support reuse of modules among different software systems.

4



McGuinness mentions several other application areas for ontologies, some ofthem are mentioned here [26]. Ontologies provide a controlled and shared vocab-ulary. They can be used for navigation, browsing and search support. Consistencychecking can also be handled with ontologies to some extent. Ontologies can provideconfiguration support and support validation and verification testing of data.

Within OntoWeb four different usage areas for ontologies are defined [33]. Enter-prise Portals and Knowledge Management, where ontologies provide a shared con-ceptualisation of the application domain, and is machine-readable. The second usagearea they define is E-Commerce, with two different scenarios, Business-to-Customerand Business-to-Business. Ontologies in this context represent an efficient way toaccess and optimise a large scale of Internet information. There is also a need forsharing information and agree on standards and definitions, where ontologies canplay an important part. Information Retrieval is the third usage area defined. Thismeans to use ontologies for understanding the concepts being search and avoid themistake of missed positives (failure to retrieve relevant answers) and false positives(retrieval of irrelevant answers). The fourth and final usage area for ontologies arePortals and Web communities. Web communities need intelligent providing and ac-cess of information, ontologies could be used to support this as a semantic basis.

2.3 Different types of ontologies

A number of different types of ontologies exists, it seems as if everyone who doesresearch within ontologies have their own opinion, with the consequence that defini-tions and terms are not used consistently.

Obitko defines several different types of ontologies [32]. Workplace Ontologyspecifies boundary conditions which characterise and justify problem solving be-haviour in the workplace. A Task Ontology consists of a vocabulary for describinga problem solving structure of all existing tasks, independent from the domain. Taskknowledge gives roles to each object and the relations between them. A DomainOntology can be either task-dependent or task-independent. A task-dependent ontol-ogy contains some specific domain knowledge in order to be able to solve a task. Atask-independent ontology on the other hand may cover structure or behaviour of anobject or theories and principles that govers a domain to mention some. A GeneralOntology covers general or common objects, such that things, events, time, space,etc.

Descriptive terms on a general level are defined as Top-level Ontology accordingto Chandrasekan et al. [5]. This might be terms likeflowsor casuality. It may be dif-ficult to distinguish between domain-independent and domain-specific ontologies forrepresenting knowledge, simply because there are no sharp division between them.

Mizoguchi et al. distinguish between task ontology and domain ontology [27].

5



A Task Ontology characterises the computational architecture of a knowledge-basedsystem that performs a task. The Domain Ontology characterises the domain knowl-edge where the task is performed.

Heijst et al. [50] classify ontologies according to two different dimensions. Thefirst one considers the amount and type of structure of the conceptualisation, and thesecond considers the subject of the conceptualisation. In the first dimension there arethree different categories. Terminological ontologies, e.g. lexicons, specify termsused to represent knowledge in a specific domain. Information Ontologies, such asdatabase schemata, specify the record structure of databases. Knowledge ModellingOntologies specify conceptualisations of the knowledge, and have a richer internalstructure than information ontologies. They are often specialised for a particular useof the knowledge they describe. In the other dimension they distinguish four differentcategories. Application Ontologies are related to a specific application, and modelthe knowledge required for it. Domain Ontologies are specific for particular domains.Generic Ontologies define concepts that are generic across many fields. Finally, Rep-resentation Ontologies provide a representational framework without making claimsabout the world.

Yet another separation between different ontologies are done by Cui et al. [6], andthey define three different ontology types. Resource Ontologies define the semanticsthat are used in software systems. Personal Ontologies define semantics of a useror a user group, and Shared Ontologies define common semantics that are sharedbetween information systems.

To summarise this, one can say that ontologies range from very general, to veryapplication and domain-dependent. This is also connected to the level of reusability;a very application-dependent ontology is not so reusable, whereas a general ontologymay be easily reused in several different projects, see Figure 1.

Representation Ontologies

Generic Ontologies

Domain Ontologies

Application Ontologies

Reusability Usability

-

- +

+

Figure 1: Different types of ontologies and their reusability [11]

In the following parts of this report, focus is on building ontologies for specific

6



enterprises, so called Enterprise Ontologies. These should reflect the specific interestof a company, possibly its product structure, organisational structure, processes, orthe domain.

7



3 Ontology Development

There exist several different methodologies for ontology development. Some of themare mainly manual, and others use a semi-automatic approach, e.g. by using text min-ing, scan through documents and propose a list of concepts and relations to the user.Examples of systems that use semi-automatic approaches for ontology developmentare OntoLearn [28] and Text-To-Onto [24]. Several different environments for on-tology construction and evolution exist, ontology editors, such as OntoEdit, Protege,etc. For an evaluation of ontology editors see for example the work by Su and Ile-brekke [45].

The following sections consist of descriptions of methodologies for ontology de-velopment that could be used when developing an ontology for an enterprise.

3.1 The Enterprise Ontology

The method for development of ontologies proposed by Uschold and King consistsof four phases: purpose, building, evaluating and documenting [49]. In the first phasethe purpose is identified, i.e. to find out why the ontology is being built and what itsintended uses are. Here should also be considered who will use the ontology and how.The second phase is the building of the ontology itself and is divided into three parts:capture, coding and integrating. Capture means to identify the key concepts and rela-tionships, produce text definitions for the concepts and relationships, identify termsto refer to the concepts and relationships, and to agree on the above. It is necessary toreview definitions and check the consistency and that no ambiguous terms exist. Bycoding is meant to take the result from the previous phase and to explicitly representit in some formal language. This includes committing to a meta-ontology, choosing arepresentation language, and creating the code. By meta-ontology is meant the maindifferent kinds of terms and concepts that the ontology should capture. The third andfinal part of the building of the ontology regards whether to use already existing on-tologies, and if it is decided to use an existing ontology then how should this be done.In the evaluation phase it should be checked that the ontology fulfils the requirementsand that it does not contain any unnecessary things. The last phase is the documenta-tion phase, in which the ontology should be documented in some way. There are (atleast not today) no good guidelines about how this should be done. This method wasused in the development of The Enterprise Ontology. It was developed to support andenable communication between different people, people and computational systems,and among different computational systems.

8



3.2 TOVE - Toronto Virtual Enterprise

Gruninger and Fox define the goal of an ontology toagree upon a shared terminologyand set of constraints on the objects in the ontology[14]. The development of a newontology must be motivated according to a scenario that describes a problem andthat also describes possible solutions to the problem. The motivating scenario(s) helpdevelopers not only to understand why the ontology is needed but also how it can andwill be used. Based on one (or more) motivating scenario(s) a set of questions thatthe ontology need to be able to answer arise. These questions are in this stage calledinformal competency questions. These questions are used to evaluate the ontologicalcommitments that have been made. The next thing to do is to specify the terminologyof the ontology, this is done by using first-order logic. First the relevant objectsare identified, then attributes of these objects are defined by unary predicates, andrelations among objects are defined by n-ary predicates. The competency questionsnow need to be defined formally with respect to the axioms in the ontology. Thesequestions can be used to distinguish between ontologies, by looking at what kind ofproblems they can solve. According to Gruninger and Fox the most difficult aspectin defining ontologies is the process of defining axioms. The difficulty lies in that theaxioms must be necessary and sufficient enough to express the competency questionsand their solutions. The final thing to do is to create completeness theorems for theontology. These define the conditions under which the solutions to the questions arecomplete. This method was used in the development of the TOVE ontology, whichwas developed as part of the TOVE Enterprise Modelling project. The goal of theproject was to create an Enterprise Model that could deduce answers to queries.

3.3 Unified Methodology

Uschold presents a unified methodology for development of ontologies [47]. He haslooked at the two methodologies previously described (EO and TOVE) and combinesthe ”best” parts in each of them into a unified method. The first step is to define thepurpose of the ontology, i.e. why the ontology is being built. This can be done in sev-eral ways; to identify the intended users, or as in the TOVE project with motivatingscenarios and competency questions, or a user requirements document to mentionsome. Next the developer should decide what level of formality the ontology has tohave. In the following phase the developer needs to find the concepts that should bein the ontology and the relations among them. Uschold prefers to go the middle-outway when defining terms and relationships, meaning to start with some basic termsand specialise and generalise from there. When it comes to building the ontology theauthor describes four different approaches. The first one is to skip the previous stepsand use an ontology editor to define terms and axioms. Second, do the previous stepsand then begin a formal encoding. The third approach is to produce an intermedi-ate document that consists of the terms and definitions that appeared in the previous

9



step, this document can be the final result, or be specification of the formal code orbe documentation for it. The fourth and final approach is to identify formal termsfrom the set of informal terms. The final part that Uschold presents is the evalua-tion or revision cycle, where the developed ontology is compared to the competencyquestions or the user requirements.

3.4 Ontologies for conceptual modelling

Sugumaran and Storey present a heuristics-based method for developing and creatingontologies [46]. The authors focus only on the building part, but the methodology isvery detailed and easy to follow. They start by identifying all the basic terms; this isdone by using use cases and then revising synonyms and related terms manually orby an online thesaurus. In the next step they identify the relationships among theseterms. They define three types of relationships: generalisation, synonyms and associ-ations. Generalisation corresponds to ”is-a”-relationships. In this step they also con-sider relationships between ontologies, in order to allow the ontology to evolve. Nextthing to do is to identify basic constraints, which means that terms or relationshipsare related, e.g. one term/relationship depends upon another, one term/relationshipmust occur before another, one term/relationship requires another for its existence orone term/relationship cannot occur at the same time as another. The final step takesin consideration higher-level constraints, such that domain constraints and domaindependencies.

3.5 METHONTOLOGY

METHONTOLOGY is a method developed by Fernandez et al in 1997 [9]. They firstdiscuss the life cycle of an ontology and how it differs from other fields of softwareengineering. When building an ontology the first thing to do is to specify the purposeof the ontology, the level of formality and the scope of the ontology. Next all theknowledge needs to be collected, there are several ways to do this: brainstorming,structured and unstructured interviews, formal and informal analysis of texts, andknowledge acquisition tools. In the conceptualisation phase Fernandez et al firstproposes to build a Glossary of Terms with all possibly useful knowledge in thegiven domain. Then terms are grouped according to concepts and verbs, and theseare gathered together to form tables of formulas and rules. Next thing to do is tocheck whether there are any already existing ontologies that can and should be used.The result of the implementation phase is the ontology codified in a formal language,that can be evaluated (verified and validated) according to some references. The finalpart consists of the documentation, if the above methodology is followed each phaseresults in a document that describe the ontology developed so far.

10



3.6 Ontology Development 101

Noy and McGuinness describe a way to develop an ontology by using an example, anontology is created for wines and terms connected to wines [31]. Their methodologyis iterative, starting with a rough concept and then revising and filling in the details.The first step in their suggested methodology consists of determining the domainand the scope of the ontology. Next thing to think about is whether to use alreadyexisting ontologies, and if so, how to use them. A list of all the terms that couldbe needed or used is then produced. The class hierarchy should represent an ”is-a”relation, cycles should be avoided, siblings should have the same level of generality,multiple inheritance could lead to some problems and also guidelines regarding whento introduce new classes or instances are given. Now the classes are defined, i.e. theterms and the relations and also the properties of the classes need to be specified(attributes). Here it is important to check whether some relations are inverse or not,and whether a default value for an attribute could be useful. After this, the valuetype of both the classes and the class properties are defined, this includes cardinality,domain and range. Finally the individual instances are created. Noy and McGuinnessalso describe some naming conventions and why this is important.

3.7 Methodology from Karlsruhe

Sure and Studer describe a methodology for ontology development which cover thewhole life cycle [40]. They define five different phases: feasibility study, ontologykickoff, refinement, evaluation and last a maintenance and evolution phase. In thefeasibility study phase problem areas and solutions are identified and put into a widerorganisational perspective. The kick off phase starts with a requirements specifica-tion document containing the domain and goal of the ontology, design guidelines,knowledge sources, users and user scenarios, competency questions and applicationssupported by the ontology. The initial draft of the ontology is refined and/or revisedin the refinement phase. There is the ontology also created by formalising a descrip-tion of it in a formal representation language. In the evaluation phase the ontologyis compared to the requirements, and tested in the target application environment.Another valuable input here are usage patterns of the ontology, meaning the wayusers use the ontology to search for concepts and relations. This helps to analysewhat parts of the ontology which are most frequently used and may be expandedand the correspondingly on the least frequently used parts maybe something couldbe deleted. The maintenance and evolution phase contains strict rules for updat-ing/inserting/deleting processes of ontologies, who is responsible for maintenanceand for example in which time interval the ontology is maintained.

11



3.8 Summary of Methodologies for Ontology Development

The methods described above were chosen because they have been used or couldbe used in development of Enterprise Ontologies. Other methodologies exist, butare somewhat different, using different starting points, etc. Among the describedmethodologies, there are two that are more mature than the others, Methontologyand the method from Karlsruhe. They both cover the whole life cycle of an ontologyand are fairly detailed, but could still be further enhanced and elaborated.

12



4 Ontology Evolution

Ontology evolution concerns maintaining an ontology, keeping it up-to-date, andto make sure it is still valid. The following sections discuss different methods forontology evolution and start with basic definitions.

4.1 Definitions

First, there is need for a discussion about the name of this section. What is meantby the term Ontology Evolution and what is the difference between other terms thatappear in the literature, such as Versioning and Revision? Maedche and Volz defineontology evolution asthe timely adaptation of the ontology to changing requirementsand the consistent propagation of changes to the dependent artifacts[23]. Accordingto Stojanovic et al. ontology evolution is defined asthe timely adaptation of the ontol-ogy to the changed business requirements, to the trends in the ontological instancesand to the way of using of the ontology-based applications, as well as the consistentmanagement/propagation of these changes[43]. On the other hand Ferrara definesthe goal of ontology evolution (in distributed environments) as toincrease the knowl-edge of each node of an open distributed system by acquiring resource descriptionsfrom the ontologies of the other nodes[10]. Ontology versioning is defined by Kleinand Fensel asthe ability to handle changes in ontologies by creating and manag-ing different variants of it[18]. Heflin defines ontology revision as achange in thecomponents of an ontology[16]. Noy and Klein combine ontology evolution and ver-sioning into one concept defined asthe ability to manage ontology changes and theireffects by creating and maintaining different variants of the ontology[30]. They alsodiscuss database schema evolution and versioning and differences between databasesand ontologies in that context.

As can be seen there are rather small distinctions between ontology maintenance,evolution and revision. The main idea is that one small change in an ontology canchange and/or corrupt other parts of the ontology itself, instances of the ontology,other ontologies that are dependent on the one being changed, and/or applicationsthat use the ontology. The difference with ontology versioning is that there are sev-eral versions of the same ontology, and the main problem is to manage the differentversions and not the actual changes and the influences they can have. In the restof this report ontology evolution will be defined according to Stojanovic et al. asthe timely adaptation of the ontology to the changed business requirements, to thetrends in the ontological instances and to the way of using of the ontology-based ap-plications, as well as the consistent management/propagation of these changes[43].Furthermore, the definition of Klein et al. for ontology versioning is used asthe abil-ity to handle changes in ontologies by creating and managing different variants ofit [18].

13



4.2 Why the need for ontology evolution?

Ontologies are dynamic and must be able to evolve over time due to several reasons;the domain can change (new concepts, new business rules, etc.), the shared concep-tualisation can change, and the user requirements can change so the ontology needsto be updated. The number of ontologies in use increase, and with them the costfor keeping them ”up to date”. Also, it is more and more practice that an ontologyis dependent on one (or more) other ontologies, which means that a change in oneontology can result in inconsistencies in the ones using the changed ontology. Theapplications that use the ontology may also encounter problems if the ontology ischanged.

4.3 Different methods and approaches

Stojanovic et al. give a number of requirements on ontology evolution [42]. Theseare requirements that ontology editors should support. A functional requirementspecify the functionality that must be provided for the ontology development andevolution. User’s supervision requirement states the mechanisms for users to man-age changes resulting in a consistent state that fulfils the user requirements. On-tology evolution should also provide maximum transparency into details of eachchange being performed. It is also necessary that it is possible to undo all changesat the user’s request. Auditing requirement involves to keep a log of the performedchanges and associate meta-information with each log change (author, time, etc.).Semi-automatical discover of changes can be done by analysing the structure of theontology, or the user’s behaviour. There should also be capabilities for identifyinginconsistencies in the ontology.

The authors further describe ontology evolution as a complex operation thatshould be considered as both an organisational and a technical process [41]. Theauthors analyse design requirements for ontology evolution: resolve the changes andensure consistency, allow the user to manage changes easily, and offer advice tothe users for continual ontology refinement. Further they describe their proposedontology-evolution process consisting of four elementary phases. First, to be able toresolve changes, the changes must be identified and represented in some suitable for-mat, this is called Change Representation. For elementary changes (adding concepts,removing properties, etc.) this is not an issue, but for more complex changes, such asmoving a concept from one parent to another, the intent of a change can be expressedin another way instead of a sequence of elementary changes. Therefore compositechanges are introduced to represent a group of elementary changes applied together.Since a change in the ontology can induce inconsistencies in other parts of the on-tology a phase called Semantics of Change is introduced, in which induced changesare resolved systematically, to ensure that the whole ontology is consistent. The sys-tem should be able to generate a list of all implications affecting the ontology so the

14



user can approve or cancel the changes, Change Implementation. If the user cancelsthe changes, the ontology should remain intact. In the final phase, Propagation, alldependent elements should be brought to a consistent state after the update of theontology. This means ontology instances as well as dependent ontologies. It is alsoimportant that the ontology is valid, i.e. that it represents reality correct and fulfilsthe user requirements. Therefore it is important to create evolution logs to be able toback-track changes in the ontology, and reverse them if so is needed. The ontologyevolution process and its phases is presented in Figure 2.

The authors also discuss different evolution strategies, these are rules to guidewhat will happen when for example a concept is deleted. Consider a concept C thatis embedded in a complex concept hierarchy. If that concept is deleted, what willhappen with its sub-concepts, or properties whose domain is C? Instead of lettingthe user decide on this, it could be good to have a strategy for it. The authors haveidentified four different strategies. Structure-driven strategy resolves changes basedon the structure of the resulting ontology. Process-driven strategy resolves changesaccording to process of changes itself. Instance-driven strategy resolves changesto achieve an explicitly given state of the instances, and finally, frequency-drivenstrategy applies the most used or last recently used evolution strategy. Finally, theydescribe The Karlsruhe Ontology and Semantic Web framework (KAON) and howontology evolution is handled there.

Figure 2: Ontology Evolution Process [41]

A system that uses the ontology evolution process previously described is On-toManager [44]. The OntoManager aims at providing support for ontology manage-ment and optimising the ontology according to the users needs. A Log Ontology isused to model what happens in the ontology and why, when, by whom, and how it isperformed.

Maedche et al. extend their evolution strategy with two more phases, validation

15



and discovery in a later publication [23]. The content is not so different from what haspreviously been described, validation concerns that the ontology represents realityand user requirements correctly, and discovery is about refinement, changing theontology in order to improve it. The authors describe three different ways to discoverthese changes, by analysing the ontology’s structure, analysing the existing instances,or analysing the users’ behaviour when using the ontology.

Stojanovic et al introduce the concept of Evolution Ontology which is distin-guished from the domain ontology [43]. The evolution ontology concerns the meta-data and supports, alleviates and automates the evolution process and consists ofthree parts. The first part consists of mechanisms to represent changes. A top levelconcept,Change, is used together with its sub-concepts and its relations. For eachchange it is important to know the author, when the changed appeared, the cause ofthe change and relevance. Order is also very important in order to be able to recoverfrom implemented changes. The evolution ontology also contains axioms that de-rive additional changes. The second part contains relations that represent semanticinformation about the domain ontology explicitly in order to deal with syntacticalproblems. The final part aims to support data-driven self-improvement of the do-main ontology. E.g. if there are no instances of some concept, that concept shouldbe deleted. Benefits from using the evolution ontology are that changes are formallyrepresented, history of changes is stored, and the change-propagation problem maybe approached. A method is also presented to solve the change propagation prob-lem. The method is divided into three parts, metadata capturing, metadata analysisand generation of a proposal for modifications. The authors also present their frame-work, CREAM, which support the proposed approach for ontology evolution.

Another guidance, or framework, for ontology evolution is described by Kleinand Noy [20]. First the authors describe different formalisms for representing changesbetween two different version of an ontology. A structural diff is used to check forcorrespondences between frames in the old and new ontology. It represents the map-ping between versions but not the operations that are needed to get from one versionto another. A set of conceptual changes specifies the conceptual relation betweenframes across versions, the relation between a frame in the old ontology and theimage of that frame in the new ontology. A transformation set consists of a set ofchange operations that specify how the old ontology can be transformed to the newontology. A transformation set is not unique, there can be several valid transforma-tion sets for two versions of an ontology. The kernel of their framework is a minimaltransformation set, which consists of a set of operations that are necessary and suf-ficient to transform the old version into the new version of the ontology. Differenttransformations that can be done are described, such as transforming from change logto minimal transformation set, or from the two versions of the ontology to the struc-tural diff, etc. In the framework the authors have developed an ontology of changeoperations, where the basis is the basic change operations, and an extension that de-fines complex change operations. There exist tools that provide change information

16



using basic changes, but not for identifying and presenting complex operations. Theauthors contribute to this by giving two different approaches to find complex op-erations, combination rules and adding uncertainty. See Figure 3 for more details.

Figure 3: Schematic Representation of the Framework [20]

Maedche et al. distinguish between three different kinds of ontology evolution,single, dependent and distributed ontology evolution [22]. The main essential in sin-gle ontology evolution is to maintain ontology consistency, meaning to satisfy a setof invariants defined in the ontology, and all used concepts need to be defined. Independent ontology evolution there is need to take into account the inclusion rela-tionships between ontologies within one node. If an included ontology is changed,the dependent ontology may be inconsistent. There are two ways of propagatingchanges from an ontology to the ontologies that include it. Changes may be propa-gated to the dependent ontology as they happen, or propagated only at the dependentontologies explicit request. Ontologies need to be topologically sorted according totheir inclusion relationship in order to be able to propagate correctly. Change filtersare introduced to prevent ontologies to receive the same change multiple times. Dis-tributed ontology evolution occurs if an ontology depends on an ontology residing ata different node on the network. This means consistency must take into account thereplications of the ontology, as well as the included ontologies. The key to solve thisis to log all changes in an evolution log ontology. They present an infrastructure formanagement of ontology changes, consisting of an ontology register for locating ex-isting ontologies, means for reusing distributed ontologies and support evolution ofdistributed ontologies. The infrastructure has been implemented within KAON [51].

Differences between ontology evolution and database schema evolution is de-scribed in detail by Noy and Klein [30]. Main differences are that ontologies are

17



data themselves, and they also incorporate semantics. Also, ontologies are oftenreused and dependent on each other in a way that database schemas are not. Ontol-ogy development is a de-centralised and collaborative process, meaning that there isno centralised control over who uses a particular ontology. The authors distinguishbetween traced and untraced evolution. Traced evolution is a series of changes in theontology, whereas untraced means that we have two versions of an ontology and noknowledge of the intermediate steps between them.

A more formal approach for ontology evolution is described by Sindt [38]. Theauthor defines a knowledge base and then different knowledge base change opera-tions. Examples of change operations arecreateConcept, which stores a new con-cept without any relation to other concepts, andderiveConcept, which creates a newconcept on top of an already existing one.

4.4 Automatic Ontology Evolution

Several automatic, or semi-automatic, approaches exists for ontology evolution. Dingand Foo give an overview of existing methodologies [8]. Other work have been doneby Navigli et al., Hahn and Kornel, and Brewster et al. [28], [15], [3].

4.5 Ontology Versioning

SHOE (The Simple HTML Ontology Extensions) is an ontology-based knowledgerepresentation that is embedded in web pages. SHOE has knowledge-oriented tags,that provide structure for knowledge acquisition. Each web page commits to oneor more ontologies and associates meaning with these knowledge oriented tags topermit discovery of implicit knowledge. Since the ontologies are supposed to be onthe Web, there is need for considering changes of dependent objects when changingone ontology. SHOE has a versioning mechanism that maintains each version ofthe ontology as a separate web page and an instance must state which version itcommits to. If a change occurs in SHOE, the ontology designer first copies theoriginal ontology file and assigns it a new version number, and adds or removeselements as needed. If the main changes are additions, the ontology can be specifiedto be compatible with previous versions using a field in the<ONTOLOGY> tag.[16]

Requirements for a versioning mechanism are given by Klein and Fensel [18]. Aversioning mechanism needs to guide how to reuse existing ontologies in new situ-ations, without invalidating the current usage. Ontology changes can be caused bychanges in the domain, changes in the shared conceptualisation or changes in thespecification, where the first two frequently happen. A versioning mechanism alsoneeds to take care of succeeding revisions of one ontology, the ontology itself and its

18



instance data, related ontologies, and related applications. Ontology versions needto be compatible, both in the prospective use, and in the retrospective use. Prospec-tive use means that data sources conform to a previous version of the ontology via anewer version of the ontology, and retrospective is the other way around. In currentpractices the authors have seen several scenarios for ontology changes, the ontol-ogy can be silently changed, visibly changed with only the new version accessible,visibly changed with both versions accessible or visibly changed with both versionsavailable and an explicit specification of the relation between concepts in the twoversions.

The general goal for a versioning methodology is that itshould provide mech-anisms and techniques to manage changes to ontologies, while achieving maximalinteroperability with existing data and applications. This means that it should retainas much information and knowledge as possible, without deriving incorrect informa-tion. Further, a versioning framework should be able to identify each version of anontology, it should make the relation of one version of a concept or relation to otherversions of that construct explicit, and automatically translate and relate the versionsand data sources.

Klein et al. define a version relation as a relation between the definitions of con-cepts and properties in the original version of the ontology and those in the newversion [19]. A version relation has several properties, transformation is a set ofchange operations, conceptual relation is the relation between constructs in the twoversions of the ontology, descriptive meta-data describes the when, who and whyof the change, and finally, scope describes the context in which the update is valid.The authors distinguish between conceptual change, a change in the way a domainis interpreted, and explication change, a change in the way the conceptualisation isspecified. The packaging of changes is also discussed, the way in which updates areapplied to an ontology. One dimension is the granularity, the level of a single ”defi-nition” or the level of ”file”. Another dimension is the method of specification, a listof change operations, a replacement of a concept, or mapping between the originalontology and the new one. The authors describe OntoView, which is a versioning sys-tem used to compare ontologies. The functions in the system are: reading changesand ontologies, identification, analysing effects of changes and exporting changes.Ontologies can be compared at a structural level, and it is possible to distinguish be-tween non-logical changes, logical definition change, identifier change, addition ofdefinitions and deletion of definitions.

19



5 Ontology Use in Small and Medium-Sized En-terprises

The following section describes small and medium-sized enterprises together withits characteristics, and experiences with ontology use in this area. The next sectiongives examples of applications where ontologies are used.

5.1 Characteristics of SMEs

Most definitions of small- and medium-sized companies depend on the number ofemployees. An example is that small companies have less than 100 employees andmedium-sized companies have between 100 and 299 employees. There are slightvariations in the numbers depending on the source. There are a number of character-istics for SMEs, some of them are listed below:

• SMEs focus on a small range of products or services in a niched market [25].This means close relationships to customers and business partners, and theability to satisfy customers specific demands [35].

• SMEs have a weak management structure, where one individual or a smallteam makes the decisions [17], meaning a fast decision process [25] and pos-sibility to operate flexibly and adapt to changes in the market [34].

• SMEs have simple structures and systems that facilitate flexibility and shortreaction times and form the basis for quick adaptation to changes in their en-vironment. Though, these systems are often based on one persons experienceand not on objective reasons, and thus may remain unchanged even if otherstructures and systems could be required. [34]

• SMEs have limited financial resources and are often time-pressured [17]. Thismeans they spend little on technology, and cannot afford to hire expensive ITconsultants. It is important to minimise cost of projects [4].

• SMEs prefer simple and familiar solutions over complex, formal methods ofproject management [17].

• SMEs are dependent on a limited number of people, and it is not uncommon foremployees to have several roles in the company. The smallness of the companyalso gives high commitment [34] and selected and motivated employees [35].An SME is often more people-dependent than process-dependent, and there isneed for capturing knowledge in business rules and processes [17].

• SMEs are often owner-manager driven [17], and the owner’s time is very valu-able [39]. The top person spends lot of time on doing routine tasks [17].

20



5.2 Applications of Ontologies

Within OntoWeb there has been a number of successful scenarios where ontologieshave played a central role [33]. Two of them are described in the next section togetherwith another one.

5.2.1 NOPIK

NOPIK (Personal Information and Knowledge Organizer Network) is an on-goingjoint project with actors from Italy, United Kingdom, Greece, Germany and Portu-gal [29]. The aim is to support personal information and knowledge managementneeds by building a distributed environment and to structure an underlying method-ology to implement relevant knowledge management changes. The project considersespecially small and medium-sized enterprises. For the modelling and navigation ofinformation and knowledge resources an ontology-based approach is used. The sys-tem consists seven different components, two of them are an Ontology Editor and aProblem Solving Manager. The ontologies are used for information and knowledgemanagement, documents can be added and attached to appropriate categories.

5.2.2 Arisem

Arisem is a company that provides knowledge management solutions [1], [33]. Theyuse ontologies to construct a ”Semantic Web” system of navigation, which organisesskill and knowledge management within a company. This is to improve collabora-tion, interactivity and information sharing. They contribute to the field of InformationLogistics by sending the entering informational flow directly to the correct projectsand people, and thereby reduce thousands of hits in conventional searches to only afew but relevant documents instead. Ontologies are also used to represent the organ-isational dimension of information.

5.2.3 SEWASIE

SEWASIE (Semantic Webs and AgentS in Integrated Economies) is a project withinthe Semantic Web Action Line of the European IST Programme [37], [36]. It fo-cuses on enhancing information management capabilities in networks of small andmedium-sized enterprises. The project approach consists of the use of Semantic Webtechnology together with Agent Systems to achieve their goal. A number of datasources are used, together with intelligent agents and domain ontologies to build upa network of intelligent information sources. These information sources are used bya query manager which combines results from different sources and presents it to theuser via a user interface. This user interface also considers the users personalised

21



information. The authors claim that their resulting systems helps SMEs to find theright information at the right time, in a multinational environment.

22



6 Conclusion

Ontologies are a rather new research area, but still some parts of it are well re-searched. Below are some reflections on each of the three different areas of inter-est in this report: methodologies for ontology development, ontology evolution andapplication of ontologies in SMEs. The reflections concerns mainly what has beendone, and possible future research areas.

The area of Methodologies for Ontology Development seems at a first glancerather well researched, but when going into details of the methodologies, much workcould still be done. Most of the methodologies previously described has a part calledIntegration, but does not give any extensive guidelines of how this should be car-ried out, such as where to find ontologies to integrate with, or how to do the actualintegration. Not every methodology described covers the whole life cycle of the on-tology and most of them are not so very detailed. There are no guidelines regardingwhen to use one specific methodology, they seem to be general and not context ordomain-dependent. It should be possible to further elaborate the methodologies, inorder to reduce the development time, say for example for a specific type of ontology,for a specific domain, or for a specific usage area. In that way the introductory phasecan be eliminated or at least shortened significantly. There are no good guidelines inthe methodologies of how to evaluate an ontology. Some guidelines on this exist, butthis is also a subject of further research.

Concerning the area of ontology evolution it is not as well researched as the areaof methodologies. Fewer approaches exist and they focus mainly on keeping anontology (and its dependents) consistent after making changes. An open questionhere is how to knowwhento make a change in the ontology, as well as how to knowwhat to change. It is obvious if the necessary information is not in the ontology, thenit should be added. But how does an ontology engineer know if there is need fordeletion of concepts, or if the whole ontology should be re-designed? How to knowwhen the ontology is out-of-date? One solution is to look at usage patterns of theontology and base the decisions on this. A number of interesting and open questionsexist in this area.

The area of applications of ontologies in small and medium-sized enterprisesis not so very well-explored. Some solutions exist, but no real insight is given onhow ontologies are used, and also not its benefits compared to other techniques.For example when to use ontologies, and not just a database, or something else? Itwould also be interesting to see the actual benefit from usage of ontologies, doesit simplify work processes, or just complicate things? It might seem obvious thatSMEs can benefit from use of ontologies, but is it obvious that the solutions reallyare beneficial?

23



References

[1] Arisem. Arisem homepage. Available at http://www.arisem/com/en/.

[2] W. N. Borst. Construction of Engineering Ontologies for Knowledge Sharingand Reuse. PhD thesis, University of Twente, Enschede, 1997.

[3] C. Brewster, F. Ciravegna, and Y. Wilks. User-Centred Ontology Learning forKnowledge Management. InProceedings of the 6th International Conferenceon Applications of Natural Language to Information Systems-Revised Papers,2002.

[4] J. Caussanel and E. Chouraqui. Model and methodology of knowledge capi-talization for small and medium enterprises. In12th Workshop on KnowledgeAcquisition, Modeling and Management (KAW’99), Banff, Alberta, Canada,1999.

[5] B. Chandrasekaran, John R. Josephson, and V. Richard Benjamins. What AreOntologies, and Why Do We Need Them?Intelligent Systems, V. 14, pp. 20 -26, 1999.

[6] Z. Cui, D. Jones, and D. O’Brien. Issues in Ontology-based Information Inte-gration.E-Business & the Intelligent Web, IJCAI – Seattle, USA, 2001.

[7] W. Deiters, T. Loffeler, and S. Pfennigschmidt.Cross-Media Service Deliv-ery, chapter The information logistics approach toward a user demand-driveninformation supply, pages 37–48. Kluwer ACAD, 2003.

[8] Y. Ding and S. Foo. Ontology Research and Development, Part 2 - A Reviewof Ontology Mapping and Evolving.Journal of Information Science, nr 25, pp.375-388, 2002.

[9] M. Fernandez, A. Gomez-Perez, and N. Juristo. METHONTOLOGY: FromOntological Art Towards Ontological Engineering. InSymposium on Ontolog-ical Engineering of AAAI. Stanford (California), 1997.

[10] Alfio Ferrara.Methods and Techniques for Ontology Matching and Evolution inOpen Distributed Systems. PhD thesis, Universita degli Studi di Milano, 2004.

[11] A. Gomez-Perez. Ontological Engineering. Presentation, available athttp://www.ontology.org/main/presentations/madrid/theoretical.pdf.

[12] A. Gomez-Perez. Ontological engineering: a state of the art.Expert Update,2(3), 33-43, 1999.

24



[13] Thomas Gruber. Toward Principles for the Design of Ontologies Used forKnowledge Sharing. InInt. Journal of Human-Computer Studies, Vol. 43,pp.907-928, 1995.

[14] Michael Gruninger and Mark S. Fox. Methodology for the Design and Evalua-tion of Ontologies. InProceedings of IJCAI’95, Workshop on Basic OntologicalIssues in Knowledge Sharing, 1995.

[15] U. Hahn and G. M. Kornel. An integrated, dual learner for grammars andontologies.Data & Knowledge Engineering, vol. 42, pp. 273-291, 2002.

[16] J. Heflin and J. Hendler. Dynamic Ontologies on the Web. InProceedingsof the Seventeenth National Conference on Artificial Intelligence (AAAI-2000),2000.

[17] Rajesh Jain. Tech Talk: Software SMEs: SME Characteristics. Downloadedfrom http://www.emergic.org/archives/indi/002184.php, 2004-09-08.

[18] M. Klein and D. Fensel. Ontology versioning on the Semantic Web. InPro-ceedings of the First International Semantic Web Working Symposium, 2001.

[19] M. Klein, A. Kiryakov, D. Ognyanov, and D. Fensel. Ontology versioning andchange detection on the Web. In13th International Conference on KnowledgeEngineering and Knowledge Management (EKAW02), 2002.

[20] M. Klein and N. F. Noy. A Component-Based Framework for Ontology Evolu-tion 2003. InWorkshop on Ontologies and Distributed Systems at IJCAI-2003,2003.

[21] A. Maedche. Ontology Learning for the Semantic Web. Kluwer AcademicPublishers, Norwell, 2003.

[22] A. Maedche, B. Motik, L. Stojanovic, R. Studer, and R. Volz. An Infrastructurefor Searching, Reusing and Evolving Distributed Ontologies. InProceedingsof the twelfth international conference on World Wide Web, 2003.

[23] A Maedche, B Motik, L Stojanovic, R Studer, and R Volz. Ontologies forEnterprise Knowledge Management.IEEE Intelligent Systems, 2003.

[24] A. Maedche and R. Volz. The Ontology Extraction & Maintenance Frame-work Text-To-Onto. InThe 2001 IEEE International Conference on Data Min-ing Workshop on Integrating Data Mining and Knowledge Management, 2001,November.

[25] Antoine Mansour. Trade and Environment Challenges and Opportuni-ties for SMEs. Downloaded from http://lnweb18.worldbank.org/mna/mena.nsf/Attachments/Hi+Level+Mansour+27+$June/$File/27+June-b-Antoine+Mansour+SMEs+.pdf, 2004-09-08.

25



[26] Deborah L. McGuinness. Ontologies Come of Age. InSpinning the SemanticWeb: Bringing the World Wide Web to Its Full Potential. MIT Press, 2002.

[27] R. Mizoguchi, K. Kozaki, T. Sano, and Y. Kitamura. Construction and Deploy-ment of a Plant Ontology. In12th European Workshop on Knowledge Acquisi-tion, Modeling and Management, 2000.

[28] R. Navigli, P. Velardi, and A. Gangemi. Ontology Learning and Its Applicationto Automated Terminology Translation.IEEE Intelligent System, vol. 18, nr. 1,pp. 22-31, 2003.

[29] NOPIK. NOPIK Home page. Available at http://www.nopik.com/.

[30] Natalya F. Noy and Michel Klein. Ontology Evolution: Not the Same asSchema Evolution.Knowledge and Information Systems, 2004.

[31] Natalya F. Noy and McGuinness Deborah L. Ontology Development 101: AGuide to Creating Your First Ontology’. Technical report, Stanford KnowledgeSystems Laboratory and Stanford Medical Informatics, 2001.

[32] Marek Obitko. Ontologies - Description and Applications. Technical report,Gerstner Laboratory for Intelligent Decision Making and Control, Czech Tech-nical University in Prague, 2001.

[33] Ontoweb. Ontology-based information exchange for knowledgemanagement and electronic commerce. Downloaded from http://www.ontoweb.org/download/deliverables/ 2004-10-05.

[34] Dagmar Recklies. Small and Medium-Sized Enterprises and Globalization.Downloaded from http://www.themanager.org/Strategy/global.htm, 2004-09-08.

[35] Dagmar Recklies. Small Business - Size as a Chance or Handicap. Downloadedfrom http://www.themanager.org/resources/Small%20Business.htm, 2004-09-08.

[36] M. Schoop, A. Becks, C. Quix, T. Burwick, C. Engels, and M. Jarke. EnhancingDecision and Negotiation Support in Enterprise Networks Through SemanticWeb Technologies. InWorkshop of XML Technologies for the Semantic Web,(XSW 2002), Berlin, Germany, 24/25 June 2002.

[37] SEWASIE. SEWASIE Home Page. Available at http://www.sewasie.org.

[38] Thomas Sindt. Formal Operations for Ontology Evolution. InProceedings ofthe International Conference on Emerging Technologies, 2003.

26



[39] Ministry of Economic Development Small Business Advisory Group, Industry& Regional Development. Section 2: Characteristics of SMEs. Downloadedfrom http://www.med.govt.nz/irdev/inddev/sbag/ar/2004/2004-03.html, 2004-09-09.

[40] S. Staab, R. Studer, H.-P. Schnurr, and Y. Sure. Knowledge Processes andOntologies.IEEE Intelligent Systems, vol. 16, nr. 1, pp. 26-34, 2001.

[41] L. Stojanovic, A. Maedche, B. Motik, and Stojanovic N. User-driven Ontol-ogy Evolution Management. InEKAW02, 13th International Conference onKnowledge Engineering and Knowledge Management, 2002.

[42] L. Stojanovic and B. Motik. Ontology evolution within ontology editors. InProceedings of the OntoWebSIG3 Workshop at the 13th International Confer-ence on Knowledge Engineering and Knowledge Management (EKAW), 2002.

[43] L. Stojanovic, N. Stojanovic, and S. Handschuh. Evolution of the Metadata inthe Ontology-based Knowledge Management Systems. InExperience Manage-ment 2002, German Workshop on Experience Management, 2002.

[44] N. Stojanovic, J. Hartmann, and J. Gonzalez. OntoManager - a system forusage-based ontology management. InProceedings of FGML Workshop.Special Interest Group of German Information Society (FGML - FachgruppeMaschinelles Lernen der GI e.V.), 2003.

[45] X. Su and L. Ilebrekke. A Comparative Study of Ontology Languages andTools. InProceedings of the 14th International Conference on Advanced Infor-mation Systems Engineering, 2002.

[46] V. Sugumaran and V. C. Storey. Ontologies for conceptual modeling: theircreation, use, and management.Data & Knowledge Engineering, 2002.

[47] M. Uschold. Building Ontologies: Towards A Unified Methodology. InPro-ceedings Expert Systems 96, Cambridge, 1996.

[48] M. Uschold and M. Gruninger. Ontologies: Principles, Methods, and Applica-tions. Knowledge Engineering Review, 11(2), 93–155, 1996.

[49] Mike Uschold and Martin King. Towards a Methodology for Building Ontolo-gies. InProceedings of IJCAI95’s Workshop on Basic Ontological Issues inKnowledge Sharing, 1995.

[50] G. van Heijst, Th. Schreiber, and B. J. Weilinga. Using Explicit Ontologiesin KBS Development.International Journal of Human and Computer Studies,46(2-3, pp. 183-292, 1996.

27



[51] R. Volz, D. Oberle, S. Staab, and B. Motik. KAON SERVER - A Semantic WebManagement System. InAlternate Track Proceedings of the Twelfth Interna-tional World Wide Web Conference, WWW2003, Budapest, Hungary,, 2003.

28

ontology development and evolution: selected approaches

Documents