Lessons Learned Developing an Ontology about Aeroengines Victoria Uren 1 , Fabio Ciravegna 1 , Enrico Motta 2 and Colin Cadas 3 Technical Report CS-11-02 1 Department of Computer Science, University of Sheffield, Regent Court, 211 Portobello, Sheffield, UK 2 Knowledge Media Institute, The Open University, Milton Keynes, MK7 6AA, UK 3 Rolls-Royce plc, PO Box 31, Moor Lane, Derby, DE24 8BJ, UK v.uren@dcs.shef.ac.uk, f.ciravegna@dcs.shef.ac.uk, e.motta@open.ac.uk, colin.cadas@rolls-royce.com. Abstract Ontologies have become one of the key technologies underlying industrial Knowledge Management systems. Such an ontology should provide a common language to facilitate knowledge sharing horizontally, between different parts of an organization, but requires sufficient flexibility to support the building of specialist vertical knowledge systems. We describe the development of an ontology for the aerospace domain, including design decisions made and lessons learned. The design of the ontology includes an upper ontology based on modules with very simple knowledge structures. This provides the sharable core upon which local ontology extensions can be built for communities of users with specialist expertise. The ontology has been successfully applied in Knowledge Management systems for two use cases, one dealing with issue resolution and one with experimental vibration. 1. INTRODUCTION Ontologies are recognized as a solution to some of the challenges of Knowledge Management (KM) because of their ability to support intelligent search [Fensel 1998] and to bring together distributed information resources stored in databases, file systems etc., which typically exist in large organizations [Maedche 2003]. In this paper, we report our experiences of building ontologies for Rolls-Royce, which describe jet engines and associated engineering matters, as part of a project to investigate the use of semantic annotation to support access to corporate knowledge resources stored in different media. This work is informed by a sustained programme of research led by Rolls-Royce, which has investigated the role ontologies can play in knowledge systems in large, technical organizations, e.g. [Crowder 2010] [Dadzie 2009 ESTC] [Fowler 2008]. The ontologies discussed in this paper concern the design, testing and diagnosis of jet engines. Therefore, we will begin with a brief introduction to how jet engines work, and to the two specialist use cases for which we built KM systems in the project. We will then discuss the design process, the ontologies themselves and how ontology design was tailored to the needs of different communities within the organization. We describe some of the knowledge management tools that were built to exploit the ontology. Issues associated with ontology evolution are raised before we conclude by summarising the lessons learned. 1.1 The Jet Engine Domain The principle on which a jet engine works is simple. Air is taken in at the front through a fan; this is the part with long blades that is visible from the outside of the aircraft. The air is then passed through a compressor, which has a succession of rotors that compress the air. Fuel is injected into the pressurised air and ignited in the combustion chamber. The hot gas expands, forcing its way through a second set of rotors, called the turbine, which is designed to both maximise thrust and drive the compressor. The force of the gas being pushed out of the back of the engine provides the thrust that drives the aircraft forwards. The principle is simple, but the engineering is not, as this combination of operations produces extreme operating environments. For example, temperatures range from -40 deg. C at the fan at high altitude to in excess of 1500 deg. C in the combustion chamber. The extreme conditions produced in jet engines require very sophisticated engineering design and high performance materials. An accessible introduction to the design of jet engines is provided by [Rolls-Royce 2005]. The ontologies were developed initially to provide KM services for two specific use cases. The first use case is called Issue Resolution (IR) and concerns in-service issues. When an issue is reported, for example a component is rather more worn than normal when examined during a regular service, a team will be set up to try to identify the cause of the wear and to recommend a solution. This might be a way to reduce wear or to change the service regime to pick it up sooner [Dadzie 2009 ESWC]. Issue resolution is particularly interesting from a KM viewpoint because of the very wide range of issues that may come up and because knowledge relevant to each issue may be scattered over a very wide range of repositories, and documents produced during the design, manufacturing or during service. The KM challenges of this use case are three fold. Firstly, the issue