Ontology Development and Evolution: Selected Approaches for Small-Scale Application Contexts

Transcription

1 : Selected Approaches for Small-Scale Application Contexts Annika Öhgren ISSN Research Report 04:7

2 : Selected Approaches for Small-Scale Application Contexts Annika Öhgren Information Engineering Group Department of Computer and Electrical Engineering School of Engineering, Jönköping, SWEDEN ISSN Research Report 04:7

3 Abstract This report presents a literature study concerning three areas, Ontology Development Methodologies, Ontology Evolution, and Ontologies in Small and Medium-Sized Enterprises. The objectives were to find out and summarize what has been done so far in the different areas, as well as to find out what has not yet been done, and thereby discover new possible research areas. Ontologies are widely used as a technique for representation and reuse of knowledge. We believe that ontologies can be used in small and medium-sized enterprises and help companies by supporting knowledge sharing, reuse of knowledge, inter-operability, and much more. The main conclusion is that a lot of work has been put into Ontology Development, many methodologies are very mature and have been used in practice. 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. In Ontology Evolution, the main focus is on keeping an ontology and its dependents consistent, and it does not concern when to make changes, or what to actually change. Ontology use in small and medium-sized enterprises is not so common, but some experiences exist. Keywords Ontologies, Ontology Development, Ontology Development Methodologies, Ontology Evolution, Ontology Use in SMEs

4 Table of Contents 1 Introduction Background Aim Outline Basic Concepts What are ontologies? What can ontologies be used for? Different types of ontologies Ontology Development The Enterprise Ontology TOVE - Toronto Virtual Enterprise Unified Methodology Ontologies for conceptual modelling METHONTOLOGY Ontology Development Methodology from Karlsruhe Summary of Methodologies for Ontology Development Ontology Evolution Definitions Why the need for ontology evolution? Different methods and approaches Automatic Ontology Evolution Ontology Versioning Ontology Use in Small and Medium-Sized Enterprises Characteristics of SMEs Applications of Ontologies NOPIK Arisem SEWASIE Conclusion... 23

5 References... 24

6 1 Introduction This report is part of a PhD project at School of Engineering, Jönköping. The area of the PhD project is ontology development and evolution with specific use in smallscale application contexts. A literature study has been carried out in the selected area to know what has been done so far, and this report is the result of it. The following subsections describe the background and context of the project followed by aim and outline of the report. 1.1 Background The PhD project is part of the research area called Information Logistics [7]. Information Logistics aims at optimising information flow, by serving the right information, in the right context, at the right time, at the right place, and through the right channel. Companies and people are overloaded with information. Take the Internet as an example, with lots of information and mailboxes that are filled with mass-sent s that do not concern all receivers. Obviously there is a need for optimising search techniques and personalise information retrieval. Information Logistics support information flow by using not only the information, but also incorporate semantics to be able to use more advanced information retrieval techniques. One solution to this is through the use of ontologies. The need for optimising information flow is especially important in networks of companies and distributed work groups. Within companies and organisations there exist lots of well-known terms and knowledge. It is often the case that the information or knowledge is not formally or explicitly defined, but mostly exists in employees minds, with the consequence that terms may be used different and no unambiguous definition exists. It might also be the case that an employee with lots of knowledge quits his/her job and the acquired knowledge is lost. To avoid this, ontologies can be used to structure and explicitly define concepts and terms, and their interrelations. The PhD project focuses especially on small-scale application contexts, meaning mainly small and medium-sized enterprises (SMEs) and networks of SMEs, and the use of ontologies to optimise information flow and knowledge handling within such organisations. 1.2 Aim This report aims at describing the state of research, what has been done so far, concerning ontology development methodologies, ontology evolution, and applications of ontologies in small and medium-sized enterprises. The goal is not only to find what has been done, but also what has not been done, and thus show possible future 1

7 research subjects. 1.3 Outline The structure of the report is as follows: First, the term ontology is explained together with its usage areas. The next section consists of a discussion of methodologies for ontology development. Section 4 describes ontology evolution and section 5 discusses characteristics of SMEs, together with applications of ontologies. The final section consists of conclusions. 2

8 2 Basic Concepts This section describes the concept Ontology, in terms of definitions, usage areas, and types. 2.1 What are ontologies? The term Ontology stems originally from philosophy and refers to the subject of existence. Ontology may also refer to a branch of philosophy that deal with the nature of reality. In computer science one of the most commonly used ontology definition is from Gruber, an ontology is an explicit specification of a conceptualisation [13]. Explicit in this context means that type of concepts and constraints are explicitly defined and conceptualisation refers to an abstract model of some phenomenon with identified relevant concepts of that phenomenon. Another definition is made by Borst as an ontology is a formal specification of a shared conceptualisation [2]. Formal means that the ontology should be machine-readable, shared reflects that it captures knowledge that is accepted by a group. Uschold and Grüninger define an ontology as a shared understanding of some domain of interest which may be used as a unifying framework [48]. According to Studer et al, ontologies aim at capturing domain knowledge in a generic way and provide a commonly agreed understanding of domain, which may be reused and shared across applications and groups [5]. A more mathematical definition is given by the same authors as [21]: An ontology structure is a 5-tuple O := {C, R, H C, rel, A O }, consisting of - two disjoint sets C and R whose elements are called concepts and relations respectively. - a concept hierarchy H C : H C is a directed relation H C C C which is called concept hierarchy or taxonomy. H C (C 1, C 2 ) means that C 1 is a subconcept of C 2. - a function rel : R C C, that relates concepts non-taxonomically 4. The function dom : R C with dom(r) := Π 1 (rel(r)) gives the domain of R, and range : R C with range(r) := Π 2 (rel(r)) give its range. For rel(r) = (C 1, C 2 ) one may also write R(C 1, C 2 ). - a set of ontology axioms A O, 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 structure O := {C, R, H C, rel, A O } is a 4-tuple L := {L C, L R, F, G} consisting of 3

9 - two sets L C and L R, whose elements are called lexical entries for concepts and relations, respectively. - two relations F L C C and G L R R called references for concepts and relations, respectively. Based on F, let for l L C, F (l) = {c C (l, c) F } and for F 1 (c) = {l L C (l, c) F }. G and G 1 are defined analogously. In general, one lexical entry may refer to several concepts or relations and one concept or relation may be referred by several lexical entries. An ontology structure with lexicon is a pair (O, L), where O is an ontology structure and L is a lexicon. As you can see, instances are not included in the definition, and therefore not seen as a part of the ontology, although other definitions differ in this concern. An ontology with its instances is seen as a knowledge base. According to Gómez-Pérez concepts can be abstract or concrete, elementary or composite, real or fictitious, anything about which something is said. Relations represent interaction between concepts of a domain and axioms are used to model sentences that are always true. [12] In the remaining part of this report, the definition by Borst [2] will be used as an explanation 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, natural language understanding, and to ease document search to mention some of them. Uschold and Grüninger specify three different categories where ontologies can be used [48]. The first one is Communication, ontologies can be used to increase and facilitate communication among people. They can be used to create a network of 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 terms in the same way, and with the same meaning and intention. A shared ontology can be seen as a standardised terminology for all objects and relations in the domain. The second usage area defined is Inter-Operability. Ontologies can serve as an integrating environment for different software tools. The third usage are is Systems Engineering, in which ontologies can play an important part in the design and development of software systems. They can help to identify requirements of a system and to explicitly define relationships among components of a system. They can also be used to support reuse of modules among different software systems. 4

10 McGuinness mentions several other application areas for ontologies, some of them are mentioned here [26]. Ontologies provide a controlled and shared vocabulary. They can be used for navigation, browsing and search support. Consistency checking can also be handled with ontologies to some extent. Ontologies can provide configuration support and support validation and verification testing of data. Within OntoWeb four different usage areas for ontologies are defined [33]. Enterprise Portals and Knowledge Management, where ontologies provide a shared conceptualisation of the application domain, and is machine-readable. The second usage area they define is E-Commerce, with two different scenarios, Business-to-Customer and Business-to-Business. Ontologies in this context represent an efficient way to access and optimise a large scale of Internet information. There is also a need for sharing information and agree on standards and definitions, where ontologies can play an important part. Information Retrieval is the third usage area defined. This means to use ontologies for understanding the concepts being search and avoid the mistake of missed positives (failure to retrieve relevant answers) and false positives (retrieval of irrelevant answers). The fourth and final usage area for ontologies are Portals and Web communities. Web communities need intelligent providing and access 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 does research within ontologies have their own opinion, with the consequence that definitions and terms are not used consistently. Obitko defines several different types of ontologies [32]. Workplace Ontology specifies boundary conditions which characterise and justify problem solving behaviour in the workplace. A Task Ontology consists of a vocabulary for describing a problem solving structure of all existing tasks, independent from the domain. Task knowledge gives roles to each object and the relations between them. A Domain Ontology can be either task-dependent or task-independent. A task-dependent ontology contains some specific domain knowledge in order to be able to solve a task. A task-independent ontology on the other hand may cover structure or behaviour of an object or theories and principles that govers a domain to mention some. A General Ontology covers general or common objects, such that things, events, time, space, etc. Descriptive terms on a general level are defined as Top-level Ontology according to Chandrasekan et al. [5]. This might be terms like flows or casuality. It may be difficult to distinguish between domain-independent and domain-specific ontologies for representing knowledge, simply because there are no sharp division between them. Mizoguchi et al. distinguish between task ontology and domain ontology [27]. 5

11 A Task Ontology characterises the computational architecture of a knowledge-based system that performs a task. The Domain Ontology characterises the domain knowledge where the task is performed. Heijst et al. [50] classify ontologies according to two different dimensions. The first one considers the amount and type of structure of the conceptualisation, and the second considers the subject of the conceptualisation. In the first dimension there are three different categories. Terminological ontologies, e.g. lexicons, specify terms used to represent knowledge in a specific domain. Information Ontologies, such as database schemata, specify the record structure of databases. Knowledge Modelling Ontologies specify conceptualisations of the knowledge, and have a richer internal structure than information ontologies. They are often specialised for a particular use of the knowledge they describe. In the other dimension they distinguish four different categories. Application Ontologies are related to a specific application, and model the knowledge required for it. Domain Ontologies are specific for particular domains. Generic Ontologies define concepts that are generic across many fields. Finally, Representation Ontologies provide a representational framework without making claims about the world. Yet another separation between different ontologies are done by Cui et al. [6], and they define three different ontology types. Resource Ontologies define the semantics that are used in software systems. Personal Ontologies define semantics of a user or a user group, and Shared Ontologies define common semantics that are shared between information systems. To summarise this, one can say that ontologies range from very general, to very application and domain-dependent. This is also connected to the level of reusability; a very application-dependent ontology is not so reusable, whereas a general ontology may be easily reused in several different projects, see Figure 1. Reusability - Application Ontologies Usability + Domain Ontologies Generic Ontologies + Representation Ontologies - 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

12 enterprises, so called Enterprise Ontologies. These should reflect the specific interest of a company, possibly its product structure, organisational structure, processes, or the domain. 7

13 3 Ontology Development There exist several different methodologies for ontology development. Some of them are mainly manual, and others use a semi-automatic approach, e.g. by using text mining, scan through documents and propose a list of concepts and relations to the user. Examples of systems that use semi-automatic approaches for ontology development are OntoLearn [28] and Text-To-Onto [24]. Several different environments for ontology construction and evolution exist, ontology editors, such as OntoEdit, Protégé, etc. For an evaluation of ontology editors see for example the work by Su and Ilebrekke [45]. The following sections consist of descriptions of methodologies for ontology development 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 consists of four phases: purpose, building, evaluating and documenting [49]. In the first phase the purpose is identified, i.e. to find out why the ontology is being built and what its intended 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 relationships, produce text definitions for the concepts and relationships, identify terms to refer to the concepts and relationships, and to agree on the above. It is necessary to review definitions and check the consistency and that no ambiguous terms exist. By coding is meant to take the result from the previous phase and to explicitly represent it in some formal language. This includes committing to a meta-ontology, choosing a representation language, and creating the code. By meta-ontology is meant the main different kinds of terms and concepts that the ontology should capture. The third and final part of the building of the ontology regards whether to use already existing ontologies, 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 requirements and that it does not contain any unnecessary things. The last phase is the documentation phase, in which the ontology should be documented in some way. There are (at least not today) no good guidelines about how this should be done. This method was used in the development of The Enterprise Ontology. It was developed to support and enable communication between different people, people and computational systems, and among different computational systems. 8

14 3.2 TOVE - Toronto Virtual Enterprise Grüninger and Fox define the goal of an ontology to agree upon a shared terminology and set of constraints on the objects in the ontology [14]. The development of a new ontology must be motivated according to a scenario that describes a problem and that also describes possible solutions to the problem. The motivating scenario(s) help developers not only to understand why the ontology is needed but also how it can and will be used. Based on one (or more) motivating scenario(s) a set of questions that the ontology need to be able to answer arise. These questions are in this stage called informal competency questions. These questions are used to evaluate the ontological commitments that have been made. The next thing to do is to specify the terminology of the ontology, this is done by using first-order logic. First the relevant objects are identified, then attributes of these objects are defined by unary predicates, and relations among objects are defined by n-ary predicates. The competency questions now need to be defined formally with respect to the axioms in the ontology. These questions can be used to distinguish between ontologies, by looking at what kind of problems they can solve. According to Grüninger and Fox the most difficult aspect in defining ontologies is the process of defining axioms. The difficulty lies in that the axioms must be necessary and sufficient enough to express the competency questions and their solutions. The final thing to do is to create completeness theorems for the ontology. These define the conditions under which the solutions to the questions are complete. This method was used in the development of the TOVE ontology, which was developed as part of the TOVE Enterprise Modelling project. The goal of the project 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 has looked at the two methodologies previously described (EO and TOVE) and combines the best parts in each of them into a unified method. The first step is to define the purpose of the ontology, i.e. why the ontology is being built. This can be done in several ways; to identify the intended users, or as in the TOVE project with motivating scenarios and competency questions, or a user requirements document to mention some. Next the developer should decide what level of formality the ontology has to have. In the following phase the developer needs to find the concepts that should be in the ontology and the relations among them. Uschold prefers to go the middle-out way when defining terms and relationships, meaning to start with some basic terms and specialise and generalise from there. When it comes to building the ontology the author describes four different approaches. The first one is to skip the previous steps and use an ontology editor to define terms and axioms. Second, do the previous steps and then begin a formal encoding. The third approach is to produce an intermediate document that consists of the terms and definitions that appeared in the previous 9

15 step, this document can be the final result, or be specification of the formal code or be documentation for it. The fourth and final approach is to identify formal terms from the set of informal terms. The final part that Uschold presents is the evaluation or revision cycle, where the developed ontology is compared to the competency questions or the user requirements. 3.4 Ontologies for conceptual modelling Sugumaran and Storey present a heuristics-based method for developing and creating ontologies [46]. The authors focus only on the building part, but the methodology is very detailed and easy to follow. They start by identifying all the basic terms; this is done by using use cases and then revising synonyms and related terms manually or by an online thesaurus. In the next step they identify the relationships among these terms. They define three types of relationships: generalisation, synonyms and associations. Generalisation corresponds to is-a -relationships. In this step they also consider relationships between ontologies, in order to allow the ontology to evolve. Next thing to do is to identify basic constraints, which means that terms or relationships are related, e.g. one term/relationship depends upon another, one term/relationship must occur before another, one term/relationship requires another for its existence or one term/relationship cannot occur at the same time as another. The final step takes in consideration higher-level constraints, such that domain constraints and domain dependencies. 3.5 METHONTOLOGY METHONTOLOGY is a method developed by Fernández et al in 1997 [9]. They first discuss the life cycle of an ontology and how it differs from other fields of software engineering. When building an ontology the first thing to do is to specify the purpose of the ontology, the level of formality and the scope of the ontology. Next all the knowledge needs to be collected, there are several ways to do this: brainstorming, structured and unstructured interviews, formal and informal analysis of texts, and knowledge acquisition tools. In the conceptualisation phase Fernández et al first proposes to build a Glossary of Terms with all possibly useful knowledge in the given domain. Then terms are grouped according to concepts and verbs, and these are gathered together to form tables of formulas and rules. Next thing to do is to check 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 final part consists of the documentation, if the above methodology is followed each phase results in a document that describe the ontology developed so far. 10

16 3.6 Ontology Development 101 Noy and McGuinness describe a way to develop an ontology by using an example, an ontology is created for wines and terms connected to wines [31]. Their methodology is 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 domain and the scope of the ontology. Next thing to think about is whether to use already existing ontologies, and if so, how to use them. A list of all the terms that could be 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 when to introduce new classes or instances are given. Now the classes are defined, i.e. the terms 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 value type of both the classes and the class properties are defined, this includes cardinality, domain and range. Finally the individual instances are created. Noy and McGuinness also 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 the whole life cycle [40]. They define five different phases: feasibility study, ontology kickoff, refinement, evaluation and last a maintenance and evolution phase. In the feasibility study phase problem areas and solutions are identified and put into a wider organisational perspective. The kick off phase starts with a requirements specification document containing the domain and goal of the ontology, design guidelines, knowledge sources, users and user scenarios, competency questions and applications supported by the ontology. The initial draft of the ontology is refined and/or revised in the refinement phase. There is the ontology also created by formalising a description of it in a formal representation language. In the evaluation phase the ontology is compared to the requirements, and tested in the target application environment. Another valuable input here are usage patterns of the ontology, meaning the way users use the ontology to search for concepts and relations. This helps to analyse what parts of the ontology which are most frequently used and may be expanded and the correspondingly on the least frequently used parts maybe something could be deleted. The maintenance and evolution phase contains strict rules for updating/inserting/deleting processes of ontologies, who is responsible for maintenance and for example in which time interval the ontology is maintained. 11

17 3.8 Summary of Methodologies for Ontology Development The methods described above were chosen because they have been used or could be used in development of Enterprise Ontologies. Other methodologies exist, but are somewhat different, using different starting points, etc. Among the described methodologies, there are two that are more mature than the others, Methontology and the method from Karlsruhe. They both cover the whole life cycle of an ontology and are fairly detailed, but could still be further enhanced and elaborated. 12

18 4 Ontology Evolution Ontology evolution concerns maintaining an ontology, keeping it up-to-date, and to make sure it is still valid. The following sections discuss different methods for ontology evolution and start with basic definitions. 4.1 Definitions First, there is need for a discussion about the name of this section. What is meant by the term Ontology Evolution and what is the difference between other terms that appear in the literature, such as Versioning and Revision? Maedche and Volz define ontology evolution as the timely adaptation of the ontology to changing requirements and the consistent propagation of changes to the dependent artifacts [23]. According to Stojanovic et al. ontology evolution is defined as the timely adaptation of the ontology to the changed business requirements, to the trends in the ontological instances and to the way of using of the ontology-based applications, as well as the consistent management/propagation of these changes [43]. On the other hand Ferrara defines the goal of ontology evolution (in distributed environments) as to increase the knowledge of each node of an open distributed system by acquiring resource descriptions from the ontologies of the other nodes [10]. Ontology versioning is defined by Klein and Fensel as the ability to handle changes in ontologies by creating and managing different variants of it [18]. Heflin defines ontology revision as a change in the components of an ontology [16]. Noy and Klein combine ontology evolution and versioning into one concept defined as the ability to manage ontology changes and their effects by creating and maintaining different variants of the ontology [30]. They also discuss database schema evolution and versioning and differences between databases and 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 can change 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 applications that use the ontology. The difference with ontology versioning is that there are several versions of the same ontology, and the main problem is to manage the different versions and not the actual changes and the influences they can have. In the rest of this report ontology evolution will be defined according to Stojanovic et al. as the timely adaptation of the ontology to the changed business requirements, to the trends in the ontological instances and to the way of using of the ontology-based applications, as well as the consistent management/propagation of these changes [43]. Furthermore, the definition of Klein et al. for ontology versioning is used as the ability to handle changes in ontologies by creating and managing different variants of it [18]. 13

19 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 conceptualisation can change, and the user requirements can change so the ontology needs to be updated. The number of ontologies in use increase, and with them the cost for keeping them up to date. Also, it is more and more practice that an ontology is dependent on one (or more) other ontologies, which means that a change in one ontology can result in inconsistencies in the ones using the changed ontology. The applications that use the ontology may also encounter problems if the ontology is changed. 4.3 Different methods and approaches Stojanovic et al. give a number of requirements on ontology evolution [42]. These are requirements that ontology editors should support. A functional requirement specify the functionality that must be provided for the ontology development and evolution. User s supervision requirement states the mechanisms for users to manage changes resulting in a consistent state that fulfils the user requirements. Ontology evolution should also provide maximum transparency into details of each change being performed. It is also necessary that it is possible to undo all changes at the user s request. Auditing requirement involves to keep a log of the performed changes and associate meta-information with each log change (author, time, etc.). Semi-automatical discover of changes can be done by analysing the structure of the ontology, or the user s behaviour. There should also be capabilities for identifying inconsistencies in the ontology. The authors further describe ontology evolution as a complex operation that should be considered as both an organisational and a technical process [41]. The authors analyse design requirements for ontology evolution: resolve the changes and ensure consistency, allow the user to manage changes easily, and offer advice to the users for continual ontology refinement. Further they describe their proposed ontology-evolution process consisting of four elementary phases. First, to be able to resolve changes, the changes must be identified and represented in some suitable format, this is called Change Representation. For elementary changes (adding concepts, removing properties, etc.) this is not an issue, but for more complex changes, such as moving a concept from one parent to another, the intent of a change can be expressed in another way instead of a sequence of elementary changes. Therefore composite changes 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 ontology a phase called Semantics of Change is introduced, in which induced changes are resolved systematically, to ensure that the whole ontology is consistent. The system should be able to generate a list of all implications affecting the ontology so the 14

20 user can approve or cancel the changes, Change Implementation. If the user cancels the changes, the ontology should remain intact. In the final phase, Propagation, all dependent elements should be brought to a consistent state after the update of the ontology. This means ontology instances as well as dependent ontologies. It is also important that the ontology is valid, i.e. that it represents reality correct and fulfils the user requirements. Therefore it is important to create evolution logs to be able to back-track changes in the ontology, and reverse them if so is needed. The ontology evolution process and its phases is presented in Figure 2. The authors also discuss different evolution strategies, these are rules to guide what will happen when for example a concept is deleted. Consider a concept C that is embedded in a complex concept hierarchy. If that concept is deleted, what will happen with its sub-concepts, or properties whose domain is C? Instead of letting the user decide on this, it could be good to have a strategy for it. The authors have identified four different strategies. Structure-driven strategy resolves changes based on the structure of the resulting ontology. Process-driven strategy resolves changes according to process of changes itself. Instance-driven strategy resolves changes to achieve an explicitly given state of the instances, and finally, frequency-driven strategy applies the most used or last recently used evolution strategy. Finally, they describe The Karlsruhe Ontology and Semantic Web framework (KAON) and how ontology evolution is handled there. Figure 2: Ontology Evolution Process [41] A system that uses the ontology evolution process previously described is OntoManager [44]. The OntoManager aims at providing support for ontology management and optimising the ontology according to the users needs. A Log Ontology is used to model what happens in the ontology and why, when, by whom, and how it is performed. Maedche et al. extend their evolution strategy with two more phases, validation 15

21 and discovery in a later publication [23]. The content is not so different from what has previously been described, validation concerns that the ontology represents reality and user requirements correctly, and discovery is about refinement, changing the ontology in order to improve it. The authors describe three different ways to discover these 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 distinguished from the domain ontology [43]. The evolution ontology concerns the metadata and supports, alleviates and automates the evolution process and consists of three parts. The first part consists of mechanisms to represent changes. A top level concept, Change, is used together with its sub-concepts and its relations. For each change it is important to know the author, when the changed appeared, the cause of the change and relevance. Order is also very important in order to be able to recover from implemented changes. The evolution ontology also contains axioms that derive additional changes. The second part contains relations that represent semantic information about the domain ontology explicitly in order to deal with syntactical problems. The final part aims to support data-driven self-improvement of the domain ontology. E.g. if there are no instances of some concept, that concept should be deleted. Benefits from using the evolution ontology are that changes are formally represented, history of changes is stored, and the change-propagation problem may be approached. A method is also presented to solve the change propagation problem. The method is divided into three parts, metadata capturing, metadata analysis and generation of a proposal for modifications. The authors also present their framework, CREAM, which support the proposed approach for ontology evolution. Another guidance, or framework, for ontology evolution is described by Klein and Noy [20]. First the authors describe different formalisms for representing changes between two different version of an ontology. A structural diff is used to check for correspondences between frames in the old and new ontology. It represents the mapping between versions but not the operations that are needed to get from one version to another. A set of conceptual changes specifies the conceptual relation between frames across versions, the relation between a frame in the old ontology and the image of that frame in the new ontology. A transformation set consists of a set of change operations that specify how the old ontology can be transformed to the new ontology. A transformation set is not unique, there can be several valid transformation sets for two versions of an ontology. The kernel of their framework is a minimal transformation set, which consists of a set of operations that are necessary and sufficient to transform the old version into the new version of the ontology. Different transformations that can be done are described, such as transforming from change log to minimal transformation set, or from the two versions of the ontology to the structural diff, etc. In the framework the authors have developed an ontology of change operations, where the basis is the basic change operations, and an extension that defines complex change operations. There exist tools that provide change information 16

22 using basic changes, but not for identifying and presenting complex operations. The authors contribute to this by giving two different approaches to find complex operations, 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 single ontology evolution is to maintain ontology consistency, meaning to satisfy a set of invariants defined in the ontology, and all used concepts need to be defined. In dependent ontology evolution there is need to take into account the inclusion relationships between ontologies within one node. If an included ontology is changed, the dependent ontology may be inconsistent. There are two ways of propagating changes from an ontology to the ontologies that include it. Changes may be propagated to the dependent ontology as they happen, or propagated only at the dependent ontologies explicit request. Ontologies need to be topologically sorted according to their inclusion relationship in order to be able to propagate correctly. Change filters are introduced to prevent ontologies to receive the same change multiple times. Distributed ontology evolution occurs if an ontology depends on an ontology residing at a different node on the network. This means consistency must take into account the replications of the ontology, as well as the included ontologies. The key to solve this is to log all changes in an evolution log ontology. They present an infrastructure for management of ontology changes, consisting of an ontology register for locating existing ontologies, means for reusing distributed ontologies and support evolution of distributed ontologies. The infrastructure has been implemented within KAON [51]. Differences between ontology evolution and database schema evolution is described in detail by Noy and Klein [30]. Main differences are that ontologies are 17

23 data themselves, and they also incorporate semantics. Also, ontologies are often reused and dependent on each other in a way that database schemas are not. Ontology development is a de-centralised and collaborative process, meaning that there is no centralised control over who uses a particular ontology. The authors distinguish between traced and untraced evolution. Traced evolution is a series of changes in the ontology, whereas untraced means that we have two versions of an ontology and no knowledge of the intermediate steps between them. A more formal approach for ontology evolution is described by Sindt [38]. The author defines a knowledge base and then different knowledge base change operations. Examples of change operations are createconcept, which stores a new concept without any relation to other concepts, and deriveconcept, which creates a new concept on top of an already existing one. 4.4 Automatic Ontology Evolution Several automatic, or semi-automatic, approaches exists for ontology evolution. Ding and Foo give an overview of existing methodologies [8]. Other work have been done by Navigli et al., Hahn and Kornél, and Brewster et al. [28], [15], [3]. 4.5 Ontology Versioning SHOE (The Simple HTML Ontology Extensions) is an ontology-based knowledge representation that is embedded in web pages. SHOE has knowledge-oriented tags, that provide structure for knowledge acquisition. Each web page commits to one or more ontologies and associates meaning with these knowledge oriented tags to permit discovery of implicit knowledge. Since the ontologies are supposed to be on the Web, there is need for considering changes of dependent objects when changing one ontology. SHOE has a versioning mechanism that maintains each version of the ontology as a separate web page and an instance must state which version it commits to. If a change occurs in SHOE, the ontology designer first copies the original ontology file and assigns it a new version number, and adds or removes elements as needed. If the main changes are additions, the ontology can be specified to 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]. A versioning mechanism needs to guide how to reuse existing ontologies in new situations, without invalidating the current usage. Ontology changes can be caused by changes in the domain, changes in the shared conceptualisation or changes in the specification, where the first two frequently happen. A versioning mechanism also needs to take care of succeeding revisions of one ontology, the ontology itself and its 18

24 instance data, related ontologies, and related applications. Ontology versions need to be compatible, both in the prospective use, and in the retrospective use. Prospective use means that data sources conform to a previous version of the ontology via a newer version of the ontology, and retrospective is the other way around. In current practices the authors have seen several scenarios for ontology changes, the ontology can be silently changed, visibly changed with only the new version accessible, visibly changed with both versions accessible or visibly changed with both versions available and an explicit specification of the relation between concepts in the two versions. The general goal for a versioning methodology is that it should provide mechanisms and techniques to manage changes to ontologies, while achieving maximal interoperability with existing data and applications. This means that it should retain as much information and knowledge as possible, without deriving incorrect information. Further, a versioning framework should be able to identify each version of an ontology, it should make the relation of one version of a concept or relation to other versions of that construct explicit, and automatically translate and relate the versions and data sources. Klein et al. define a version relation as a relation between the definitions of concepts and properties in the original version of the ontology and those in the new version [19]. A version relation has several properties, transformation is a set of change operations, conceptual relation is the relation between constructs in the two versions of the ontology, descriptive meta-data describes the when, who and why of 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 domain is interpreted, and explication change, a change in the way the conceptualisation is specified. The packaging of changes is also discussed, the way in which updates are applied to an ontology. One dimension is the granularity, the level of a single definition or the level of file. Another dimension is the method of specification, a list of change operations, a replacement of a concept, or mapping between the original ontology and the new one. The authors describe OntoView, which is a versioning system used to compare ontologies. The functions in the system are: reading changes and ontologies, identification, analysing effects of changes and exporting changes. Ontologies can be compared at a structural level, and it is possible to distinguish between non-logical changes, logical definition change, identifier change, addition of definitions and deletion of definitions. 19

25 5 Ontology Use in Small and Medium-Sized Enterprises The following section describes small and medium-sized enterprises together with its characteristics, and experiences with ontology use in this area. The next section gives examples of applications where ontologies are used. 5.1 Characteristics of SMEs Most definitions of small- and medium-sized companies depend on the number of employees. An example is that small companies have less than 100 employees and medium-sized companies have between 100 and 299 employees. There are slight variations in the numbers depending on the source. There are a number of characteristics 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 the ability to satisfy customers specific demands [35]. SMEs have a weak management structure, where one individual or a small team makes the decisions [17], meaning a fast decision process [25] and possibility to operate flexibly and adapt to changes in the market [34]. SMEs have simple structures and systems that facilitate flexibility and short reaction times and form the basis for quick adaptation to changes in their environment. Though, these systems are often based on one persons experience and not on objective reasons, and thus may remain unchanged even if other structures and systems could be required. [34] SMEs have limited financial resources and are often time-pressured [17]. This means they spend little on technology, and cannot afford to hire expensive IT consultants. It is important to minimise cost of projects [4]. SMEs prefer simple and familiar solutions over complex, formal methods of project management [17]. SMEs are dependent on a limited number of people, and it is not uncommon for employees to have several roles in the company. The smallness of the company also gives high commitment [34] and selected and motivated employees [35]. An SME is often more people-dependent than process-dependent, and there is need for capturing knowledge in business rules and processes [17]. SMEs are often owner-manager driven [17], and the owner s time is very valuable [39]. The top person spends lot of time on doing routine tasks [17]. 20

26 5.2 Applications of Ontologies Within OntoWeb there has been a number of successful scenarios where ontologies have played a central role [33]. Two of them are described in the next section together with another one NOPIK NOPIK (Personal Information and Knowledge Organizer Network) is an on-going joint project with actors from Italy, United Kingdom, Greece, Germany and Portugal [29]. The aim is to support personal information and knowledge management needs by building a distributed environment and to structure an underlying methodology to implement relevant knowledge management changes. The project considers especially small and medium-sized enterprises. For the modelling and navigation of information and knowledge resources an ontology-based approach is used. The system consists seven different components, two of them are an Ontology Editor and a Problem Solving Manager. The ontologies are used for information and knowledge management, documents can be added and attached to appropriate categories Arisem Arisem is a company that provides knowledge management solutions [1], [33]. They use ontologies to construct a Semantic Web system of navigation, which organises skill and knowledge management within a company. This is to improve collaboration, interactivity and information sharing. They contribute to the field of Information Logistics by sending the entering informational flow directly to the correct projects and people, and thereby reduce thousands of hits in conventional searches to only a few but relevant documents instead. Ontologies are also used to represent the organisational dimension of information SEWASIE SEWASIE (Semantic Webs and AgentS in Integrated Economies) is a project within the Semantic Web Action Line of the European IST Programme [37], [36]. It focuses on enhancing information management capabilities in networks of small and medium-sized enterprises. The project approach consists of the use of Semantic Web technology together with Agent Systems to achieve their goal. A number of data sources are used, together with intelligent agents and domain ontologies to build up a network of intelligent information sources. These information sources are used by a query manager which combines results from different sources and presents it to the user via a user interface. This user interface also considers the users personalised 21