D1.3: Reference Ontology for EPIs Requirements and Design

Transcription

1 D1.3: Reference Ontology for EPIs Requirements and Design Delivery Date: 31/01/2011 Dissemination Level: Public

2 Lead Name Organization Teemu Mätäsniemi (D1.2) VTT Elke Löschner (D1.3) Siemens SIS Contributors Name Organization Naoum Jamous Frederik Kramer Jörg Bremer Daniel Meyerholt Barbara Rapp Otto-von-Guericke Universität Universität Oldenburg Katrin Müller Siemens Siegfried Bublitz Elke Löschner Wolfgang Thronicke Ali Dada Hans Thies Teemu Mätäsniemi Hannele Tonteri Siemens SIS SAP VTT Internal Reviewer Name Organization Katrin Mueller (D1.2) Siemens Ali Dada (D1.3) SAP Disclaimer The information in this document is provided "as is", and no guarantee or warranty is given that the information is fit for any particular purpose. The above referenced consortium members shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials subject to any liability which is mandatory due to applicable law. Copyright 2010 and 2011 by Otto-von-Guericke Universität, Siemens, Siemens IT Solutions and Services, Universität Oldenburg, and VTT. OEPI_D_1_3_Final.doc Dissemination Level: Public Page i

3 Table of Contents LIST OF FIGURES... V LIST OF TABLES...VI LIST OF ACRONYMS... VII EXECUTIVE SUMMARY INTRODUCTION AND MOTIVATION A BRIEF ON THE HISTORY OF ONTOLOGY FUNDAMENTAL CONCEPTS FROM PHILOSOPHY TO COMPUTER SCIENCE MOTIVATION TYPES OF ONTOLOGIES The Temporal Dimension The Structural Dimension BENEFITS AND WEAKNESSES OF ONTOLOGY-AWARE INFORMATION SYSTEMS DEVELOPMENT METHODOLOGY OF ONTOLOGY DEVELOPMENT REQUIREMENTS PROCESS Requirements Capture Requirements Analysis Negotiation Phase Documentation Validation ONTOLOGY DESIGN PROCESS Overview of Methodologies for Ontology Development Specific Conditions of Ontology Development in the OEPI Project Approach for Ontology Development in the OEPI Project ONTOLOGY REQUIREMENTS SCOPE AND PURPOSE OF ONTOLOGY REQUIREMENTS OEPI ONTOLOGY REQUIREMENTS REUSE OF ONTOLOGIES INTRODUCTION APPROACHES OF REUSE Conservative Extension OEPI_D_1_3_Final.doc Dissemination Level: Public Page ii

4 4.2.2 Importing Extracted Modules Ontology Mapping Ontology Matching Reuse of Ideas CONSIDERATIONS FOR REUSE AND INTEGRATION Integration-oriented Considerations for Domain Experts Integration-oriented Considerations for Ontology Engineers WEB RESOURCES FOR REUSABLE ONTOLOGIES Ontology Lookup Service Ontosearch Swoogle Conventional Search Engines POTENTIAL CANDIDATES FOR REUSE Specific Ontologies or Reusable Knowledge Top-level Ontologies Related Projects ENABLING TECHNOLOGIES AND TOOLS ONTOLOGY LANGUAGES KIF RDF, RDF Schema DAML+OIL OWL Conclusion TOOLS SUPPORTING ONTOLOGY DEVELOPMENT Tool Assessment Criteria Preselection of Tools for Ontology Building Assessment of Ontology Editing Tools Tool Recommendation for OEPI Ontology Development PROGRAMMING INTERFACES FOR BUILDING SOFTWARE BASED ON ONTOLOGIES Programming Language Java Programming Language C# Conclusion A SAMPLE ONTOLOGY AND APPLICATION ( PROTOTYPE ) DESIGN AND APPLICATION OF ONTOLOGY DESIGN DECISIONS AND MAIN CONCEPTS Description Language and Representation OWL Concepts as a Foundation for OEPI Ontology Development Main Concepts of OEPI Ontology OEPI_D_1_3_Final.doc Dissemination Level: Public Page iii

5 6.1.4 Reuse of Ontologies APPLICATION OF OEPI ONTOLOGY Application Guideline Example: Automatic Ontology Concept Glossary Example: Use Case "Collaborative Design for Environment" ONTOLOGY DEVELOPMENT ROADMAP CONCLUSION AND OUTLOOK A ANNEX ONTOLOGY REQUIREMENTS B ANNEX SOURCES OF REUSABLE ONTOLOGIES C ANNEX WEB LINKS TO ENVIRONMENTAL DATA SOURCES REFERENCES OEPI_D_1_3_Final.doc Dissemination Level: Public Page iv

6 List of Figures Figure 1: Ontology relation according to Guarino (Guarino, 1997)... 6 Figure 2: OEPI Ontology Development Process - Overview Figure 3: OEPI Ontology Development Process - Requirements phase Figure 4: OEPI Ontology Development Process Ontology design phase Figure 5: OEPI Ontology Development Process Ontology design phase concept definition Figure 6: OEPI Ontology Development Process Ontology design phase iterative ontology design Figure 7: Options for reusing ontologies; modified from (Pinto and Martins, 2004) Figure 8: Illustration of ontology mapping and possible alignments between vocabularies; from (Ehrig and Staab 2004) Figure 9: Different approaches by top-level ontologies; from (Chandrasekaran et al., 1999) Figure 10: OEPI s Document concepts Figure 11: Subset of BIBO s document concepts Figure 12: A UML diagram showing the management of ontologies in OWL API (Horridge and Bechhofer, 2009) Figure 13: Existing parameterized LCA model of buildings (BEAT) at Siemens Figure 14: Existing LCA results of elevators at Kone OEPI_D_1_3_Final.doc Dissemination Level: Public Page v

7 List of Tables Table 1: Strengths and Weaknesses of Ontology-aware Information Systems Development... 8 Table 2: Methodologies for Ontology Building Table 3: Categorization of Methodologies for Ontology Building Table 4: Applicability of Methodologies for Ontology Building in OEPI Project Table 5: Attributes of requirements (Hull et al., 2002) Table 6: Main attributes of OEPI requirements Table 7: List of OEPI ontology requirements (ID / Summary) Table 8: Classifications and interrelationships of ontology requirements Table 9: Basic Formal Ontology (BFO) description Table 10: Cyc description Table 11: Dolce (a Descriptive Ontology for Linguistic and Cognitive Engineering) description Table 12: General Formal Ontology (GFO) description Table 13: PROTo ONtology (PROTON) description Table 14: Sowa's Ontology description Table 15: Suggested Upper Merged Ontology (SUMO) description Table 16: SWEET project in a nutshell Table 17: MEPI project in a nutshell Table 18: SEAMLESS project in a nutshell Table 19: SPiRE project in a nutshell Table 20: Tool Resources Table 21: Tool Assessment Criteria / Relevance for OEPI Table 22: Preselection of Tools for Ontology Building Table 23: Ontology Editing Tools Assessment Summary Table 24: Comparison of Java APIs for OWL Table 25: Overview of OWL 2 Characteristics of Properties Table 26: Overview of OWL 2 Property Restriction Types Table 27: OEPI Ontology Concepts related to Environmental Performance Indicators Table 28: OEPI Ontology Relationships (properties) related to Environmental Performance Indicators Table 29: Environmental Data Sources Summary of Characteristics Table 30: OEPI Ontology Concepts related to Environmental Data Sources OEPI_D_1_3_Final.doc Dissemination Level: Public Page vi

8 List of Acronyms API DAML DARPA DL DOLCE EPI EPL GFO GUI HTML HTTP KIF LCA / LCI MIT MPL OCML OEPI OIL OpenCyc OSGi OWL OWL-S RDF RDFS SHOE SPARQL SPEM SUMO SVN UML URI W3C WP XMI XML XOL Application Programming Interface DARPA Agent Markup Language Defense Advanced Research Projects Agency Description Logics Descriptive Ontology for Linguistic and Cognitive Engineering Environmental Performance Indicator Eclipse Public License General Formal Ontology Graphical User Interface HyperText Markup Language HyperText Transfer Protocol Knowledge Interchange Format Life Cycle Assessment / Life Cycle Inventory Massachusetts Institute of Technology Mozilla Public License Operational Conceptual Modelling Language Organizations Environmental Performance Indicator Ontology Inference Layer Open source version of the Cyc technology OSGi Alliance, Open Services Gateway initiative Web Ontology Language Web Ontology Language for Web Services Resource Description Framework RDF Schema Simple HTML Ontology Extensions Simple Protocol and RDF Query Language Software & Systems Process Engineering Metamodel Suggested Upper Merged Ontology Apache Subversion Unified Modeling Language Uniform Resource Identifier World Wide Web Consortium Work Package XML Metadata Interchange Extensible Markup Language XML-Based Ontology Exchange Language OEPI_D_1_3_Final.doc Dissemination Level: Public Page vii

9 Executive Summary The objective of OEPI work package WP 1 Ontological Reference Architecture for EPIs was to define the scope and nature of the information model for exchange and integration of environmental performance indicators (EPI) across different systems, industries, and countries. The results are represented by two deliverables: The first one D1.1 (Jamous and Müller, 2010) provided a seamless and easy-to-follow set of guidelines of environmental policies and standards and a review on existing classifications of environmental indicators and Environmental Management Information Systems. This second deliverable D1.3 1 describes the requirements and the design of a formalized description language for EPIs. An ontological approach has been chosen to achieve this goal. This decision was motivated mainly by its significance for the semantic web. The resulting reference ontology establishes a foundation and reference of the information model for the development and evaluation of the OEPI platform and services (work packages WP 2, 3, and 4). As pursuit of an ontological approach was not an evident choice from the beginning, some initial effort had to be invested in a common groundwork of understanding and motivation, which is reflected in this report. Furthermore, explorations of ontology development methodology and of technical possibilities and constraints were necessary particularly regarding ontology languages, suitable ontology design tools, and programming interfaces for ontology use. A survey of relevant existing ontologies and related research had to be undertaken in order to identify potentials for reuse. The findings of those parts of the task are included in this document not only for the benefit of the OEPI project but also for other projects that might consider a similar approach. The actual development of the reference ontology was structured in a requirements phase and a design phase. About 50 ontology requirements have been documented as result of the requirements phase. They were fed into the requirements-driven ontology design phase. This report presents the formalized description language for EPIs as a combination of the Web Ontology Language OWL 2 with a specific OEPI Ontology expressed in terms of OWL 2. This OEPI Ontology provides the first version of a common formalized description guideline for EPIs regardless of their origin and for the integration of available data sources for those EPIs. Two examples illustrate applicability of the ontology: an automatic ontology glossary and a small case study based on the OEPI use case design for environment. The most important achievement of the conducted work in retrospect is a successful proof of concept that justifies the decision for explicit capturing of EPI domain knowledge in ontology instead of a conventional solution of coding knowledge implicitly in application software. It seems easy and straight forward now to extend and refine the ontology in further incremental steps. The definition of ontology serves as an adequate, maintainable medium of knowledge transfer between domain experts and IT professionals and delivers a formalized result which can be used directly by software developers through means of existing programming interfaces like OWL API. 1 An internal deliverable D1.2 Reference Ontology for EPIs Requirements has been produced as an intermediate step towards deliverable D1.3. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 1

10 1 Introduction and Motivation This chapter points out key aspects of the term ontology and its basic concepts. A general introduction will thus comprise a brief history on the terminology as well as fundamental concepts of its methodological application. Since the term ontology has its roots in the philosophical sciences, it will also comprise a paragraph in which the transition into different fields of scientific research will be traced. The actual application of ontology technology will complete this subsection. The section about motivation contains positive reasons for the application of ontology technology as well as a summary on potential contraarguments for its application within the scope of OEPI project. 1.1 A Brief on the History of Ontology While the word ontologia is an ancient Latin word, its predecessor Etymologia is Greek and literally means to be science or in other words the philosophical study of the nature of being and existence. Its major concern is capturing an appropriate picture of the reality under investigation. This is done by answering essential questions such as: What entities do exist? How can the entities be meaningfully grouped? How can the entities be brought into hierarchy? How can entities be subdivided and separated my means of similarity and difference? How are entities linked and referenced to each other? In order to answer such questions, philosophers, such as Aristotle more than 2000 years ago, started with simple categorizations such as substance and quality that together were entitled to capture all that really is (Gruber, 2009). The first scientific evidence of the word ontologia though, appeared 1606 in Ogdoas Scholastica by Lorhard (Lorhard, 1606), who was broadly influenced by prior work of Peter Ramus on the use of diagrammatic tools in student teaching. The underlying idea has been the strong belief that the students would capture the essential ontological truth (i.e. the reality) better if supplemented by a diagrammatic formal representation. This idea together with the belief that there is a unique true ontology that reflects the world as it really is, became a quite popular dogma in higher education throughout Europe and one of the cornerstones of science during the course of the time. Lorhard was the first scholar to use the diagrammatic representation of ontology. 1.2 Fundamental Concepts Fundamental to an ontology as already pointed out is the act of grouping and connecting naturally observed (really existent) things to basically answer questions such as: What something is How something is How much it is OEPI_D_1_3_Final.doc Dissemination Level: Public Page 2

11 What its relation to other things is An ontology consists of the following six basic elements: Concept: A concept is a classification of a thing. An example could be City or Country. In the context of ontology, the terms concept and class are similar. Essential for the work with concepts is that they can be brought into hierarchy thus building a taxonomy of concepts / classes. Types: A type is an instance of a concept. An example could be: A plane is a type of the class vehicle which in turn is part of the class machine. Instance: An instance is a child node of a type. This term represents the objects in an ontology. An example would be the first Airbus A-380 of the German Lufthansa. This would be an instance of the type plane in the concept vehicle. Relations: Instances of the same type must be customized to different circumstances. The term relation in the context of ontology is similar to attribute. An example would be the base airport of an instance of the type plane. For example the first A-380 of the Lufthansa has its home base in Frankfurt, bringing the instance of the type plane and the instance of the type city into a relationship. Inheritance: Relations can be inherited. Relations are transferred to the inherited class though. Multi-inheritance is also possible. Axiom: A basic rule that always applies. An axiom basically contains knowledge that cannot be derived from other concepts. An example would be An armed military aircraft cannot be owned by a commercial airline due to international regulations Formal ontologies should comply with certain design principles. In order to craft a good ontology, the author has to consider these basic principles that according to Gruber are (Gruber, 1993): Clarity: The ontology needs to communicate the intended meaning of defined terms. Hence the definitions shall be objective. Coherence: As a minimum requirement the defined axioms need to be locally consistent. Furthermore, it shall be coherent with informal defined concepts such as natural language documentation and examples. Extendibility: While designing an ontology, the author shall anticipate different types of use of the shared vocabulary. Minimal encoding bias: The conceptualization shall only depend on the knowledge-level but not on a special symbolism. Minimal ontological commitment: Only the minimum ontological commitment shall be required to support the intended knowledge-sharing activities. In order to achieve that aim, an ontology shall make as few claims as possible to allow designers being committed to the freedom of specialization and instantiation. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 3

12 It is obvious that when designing an ontology the aforementioned design principles can be partly contradicting. This means that appropriate trade-offs must be made (Gruber, 1993). For example the ontology must match the clarity principle. That sometimes means the ontology designer has to extend the conceptualization (building more concepts means that higher commitment is needed) in order to match the clarity principle (related to the used terms). Apparently extendibility and ontological commitment seem to be in contradiction as well: An extensible ontology doesn't have to comprise all knowledge to apply the ontology to different potential tasks but instead needs to comprise representational capabilities to specialize the ontology to fulfil that aim. 1.3 From Philosophy to Computer Science With the rise of the World Wide Web, ontologies are on their way to become an important cornerstone for the representation of domain knowledge in computer science. The rapid innovation cycles in information technology delivered capabilities to go ahead from the aforementioned paper-based representation of ontologies to large tool-based ontology representation. Ontology development is quite popular in the field of artificial intelligence. It comprises methods to conceptualize the content of a seemingly complex field of knowledge in a way that makes it assessable and interchangeable not only by human beings but also and especially by software artefacts. Long before computer scientists started to use ontologies for their purposes, biologists used ontologies to conceptualize various domain knowledge representations of the living nature surrounding us. Proceeding from that macroscopic representation of the nature, biotechnologist and physicians also started to use ontologies for their specific purposes. Consequently, the underlying methodology of ontology creation while not being widely recognised as ontology development outside the expert groups matured over more than 2000 years of implicit application. Even if initially been adopted for research on artificial intelligence, computational linguistics and database theory, ontology research nowadays is spread amongst almost all fields of information systems research (Guarino, 1998). This happened due to the inherent interdisciplinary approach ontology research delivers. Ontology research allows viewing the challenge of information systems development from a very different angle, since it fundamentally leverages linguistics as well as philosophy to conceptualize a seemingly complex reality to be addressed with information systems. Guarino carefully differentiates between the term Ontology with a capital o as a special discipline of philosophy and ontology for example in Aristotle s ontology as a concrete instance thereof. He arguments that being applied in the field of philosophical sciences ontology accounts for one particular system of categories accounting for a certain vision of the world, independent from a particular language (i.e. Aristotle s ontology is independent from the language that describes it). Ontologies being applied in engineering disciplines do always comprise a special vocabulary as well as an explicit set of assumptions with regard to the intended meaning of the used vocabulary. Guarino further arguments, that in this case the set of assumptions is expressed in a first-order logic style. Words in the used vocabulary are either unary (concept) or binary (relation) predicate names. Simple ontologies usually only contain a hierarchy of concepts and respective relations, whereas more sophisticated ones do also define suitable axioms to constrain the intended interpretation (Guarino, 1998). OEPI_D_1_3_Final.doc Dissemination Level: Public Page 4

13 1.4 Motivation The motivation to use ontology research during the course of the OEPI project stems from the ambivalent understanding of the field of endeavour. One of the prevailing aims of OEPI is to define a common understanding of environmental performance indicators for organizations. The environmental reporting should be comparable across the organizational boundaries. This challenge is complex and has to be addressed by an appropriate software artefact in the end. This puts ontology research at stake. According to Guarino, ontology research can support information systems development in many ways. An information system usually consists of applications, information stores (such as databases and data warehouses) as well as user interfaces. Information systems play a peculiar role while pursuing business value creation in general. In order evaluate the actual role of ontologies throughout the course of OEPI, it is hence worthwhile to sketch the potential benefit the use of ontologies can deliver to information systems development in general and specifically to OEPI. In accordance with Guarino s article, we will thus explain what he calls the temporal and the structural dimension of ontologies in information systems development. 1.5 Types of Ontologies The Temporal Dimension The temporal dimension of ontology application describes the point in time when an ontology is actually introduced. It is important to consider an ontology as an already existing prerequisite that has been developed before crafting an information system. There are potentially two ways to apply an ontology that are not mutually exclusive. First one can use an ontology during the development phase of an information system. This is meant by the term ontology-driven information system development. An ontology can also be applied only at application run time. This is known as an ontology-driven information system. If ontologies are used in the design phase of information system development, Guarino differentiates two scenarios according to the level of specificity of a given ontology or set of ontologies. He argues that at development time one could either have a very generic ontology describing the field of discourse by domainlevel distinctions among the basic entities of the world and meta-level distinctions about kinds of classes and kinds of relations (Guarino, 1998) or one could have a set of highly reusable ontologies comprised by domain-level and task-level ontologies. In the latter case the set of ontologies will be used to create software components on their top. Hence the resulting information system is a specialization of the used set of domain and task ontologies (ontology library) and thus builds up a so-called application ontology. Figure 1 shows the relationship between a coarse top-level ontology, domain and task ontologies and an application ontology. The arrows denote a specialization. While adopting a strategy of reusing existing ontologies, one could encounter different problems. First the set of existing off-the-shelf ontologies that are reusable is very limited. Furthermore, the combination of different ontologies is not easy even if they use the same vocabulary. Following the already described design principles, an ontology A and an ontology B could use the same vocabulary but be focused on a very specific context. Ontologies do regularly only approximate models depending on their level of specificity. This in turns means that even if two ontologies use the same vocabulary and the models they intend to describe do OEPI_D_1_3_Final.doc Dissemination Level: Public Page 5

14 overlap to some extent does not necessarily mean that the ontologies themselves can be combined. This is why a bottom-up approach according to Guarino may not work in most cases (Guarino, 1998). Figure 1: Ontology relation according to Guarino (Guarino, 1997) The Structural Dimension While ontologies can be used at different points in time, they can also be used for different structural elements in information system design and development as Guarino points out (Guarino, 1998). There are three major applications in which ontologies can be used: The most obvious one is using an ontology for the development of the database components of an information system. Secondly, ontologies can be used for the interface components of an information system and last but not least for the application logic of an information system. While developing a database component for example, the ontology can be of advantage for requirements analysis and conceptual modelling. Guarino further arguments that being linked to lexical resources like Word Net the ontology can help to correctly interpret informal natural language specifications (Guarino, 1998). Furthermore, there have been publicly funded projects showing the principle viability of mapping knowledge specifications (ontologies) to database schemes for different database types. At runtime there are more obvious ways in which ontologies and applications can cooperate. Ontologies that contain the domain knowledge of a certain topic can support the user to formulate a more meaningful query over a particular database or multiple databases. This largely mitigates the risk of misinterpretation. Furthermore, ontologies may provide an added value by semi-automatically mapping different conceptual schemas to a common top-level ontology in order to drive the integration of different data sources (data integration) further as Guarino points out (Guarino, 1998). Ontologies can foster the development of good interface components as well. For example by the use of web forms such as the ones that the Protégé 2 web application provides, a user can assess the ontology and acquire a deep understanding of the used concepts, relations, and semantics of the knowledge the information systems provides. This in turn helps to use the information system in the indented way. An additional and especially promising way for OEPI to use ontologies is to allow the user to semi-automatically map his natural language terms against the special 2 OEPI_D_1_3_Final.doc Dissemination Level: Public Page 6

15 vocabulary used by the ontology. Application programs and in general the business logic part of an information system usually contains a lot of domain knowledge. In principle, an application ontology could be used to semi-automatically generate classes in an object oriented development framework. Furthermore, an ontology that has been used to develop the program logic of the information system could be made accessible to the user at runtime effectively turning the information system into a knowledge base. In short ontology can be used to derive a database structure, to derive a class structure (semi-automatically), as an application dictionary, to derive components of the application logic, to derive interface specifications, to derive requirements specifications, for semi-automatically mapping into other ontologies. 1.6 Benefits and Weaknesses of Ontology-aware Information Systems Development In order to justify the use of ontologies within OEPI, we briefly summarize potential benefits and weaknesses of ontologies in information systems development. First the idea of ontologies is not easy to understand. As we could figure out during the starting period of OEPI and within the first in-depth meetings on the topic, there is no common understanding of the term ontology. Even if there are lots of publications on ontologies nowadays, the focus is still on the terminology and the principle applicability of ontologies rather than actual application in a thoroughly defined software engineering process 3. While this seems to be a major drawback at first when trying to gain an in-depth understanding of ontology development and its application in information systems development, it delivers a great amount of understanding of the field of endeavour. Especially in multinational projects with a scientifically ambitious aim such as OEPI, one of the predominant advantages of developing an ontology is a shared and common vocabulary (taxonomy) of the field of discourse. This advantage fully outweighs the effort spent on ontology development. While an ontology is developed, it needs to be revised and reshaped according to the aforementioned design principles. This process inherently assures a kind of quality management, since inconsistencies are continuously deleted and additional concepts added. An ontology is a living and flexible representation of the domain knowledge though. An ontology development framework such as Protégé also contains tools to assess the already captured domain knowledge. Furthermore, ontologies at least if coded in the same representation can be integrated and further specialized according to the specific needs. Ontology development thus inherently comprises the principle of modularity of good software design as well. Nevertheless there is a drawback in modularity as well. There is a list of already defined top-level ontologies such as Dublin Core, GFO, OpenCyc, SUMO, and DOLCE, all of 3 Good papers describing the advantages of ontologies in software engineering can be found at (Happel and Seedorf, 2006) and (Hesse, 2005). OEPI_D_1_3_Final.doc Dissemination Level: Public Page 7

16 which have different roots, complexities and even different representations and tooling. Before starting to develop an own top-level ontology from scratch a thorough revision of pre-existing ontologies has to be done. If this is done thoroughly and right from the beginning, ontology-aware information system development can increase the level of reuse and modularity and in turn decreases development as well as maintenance costs. Even if the initial effort of ontology-aware information system development is higher and more complex, the developers will profit since they are able to understand the information system under development based on a thorough domain knowledge representation rather than just from a pure implementation perspective. A clear drawback is the high initial investment into the creation of a mutual understanding of the field of endeavour and the ontology creation which paradoxically seems to lead to nothing but overhead in the first place. Looking deeper, even this is a valuable investment because it mitigates the common risk of software engineering. The lack of software engineering tools to integrate ontology development with classical software engineering in a seamless and useful way however is a clear drawback. Table 1 summarizes the mentioned strengths and weaknesses that need to be taken into account: Table 1: Strengths and Weaknesses of Ontology-aware Information Systems Development Strengths Ontology application helps to build up a common taxonomy of the field of endeavour. Ontology can be used as a flexible and up-to-date representation of domain knowledge. Ontology delivers a structured way to create modularized application systems. Weaknesses Ontology as concept is not easy to understand. There is no mature and well proven standard how to leverage ontology in the software development process. Tool integration between ontology development and software development is weak so far. Strict usage of ontology-based software development can mitigate the risk of reinventing the wheel. As it is the main objective of the ontological reference architecture for EPIs to provide a common description language for EPIs and their use across different organizations and initiatives in the domain of discourse, the effort invested into ontology development is already justified by its potential to convey a deep common understanding and a formalized expression of domain knowledge which is at the same time a valuable preparatory effort for subsequent successful development of OEPI platform and services. The mentioned weaknesses are mainly technical and may be overcome gradually. Chapter 5, for example, provides information about currently available enabling technologies and tools. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 8

17 2 Methodology of Ontology Development This chapter has two subchapters. Firstly, the tailored and applied requirements process is explained (section 2.1). After that, the approach for ontology design is outlined (section 2.2). 2.1 Requirements Process The first phase in information system development is typically a requirements process. It is alive until the system is under development and all the impacts of change requests are analysed. Requests effect quality, schedule and costs, so the impacts have to be evaluated. The purpose of the requirements process is to define a scope of system and to explore system nature. Today, there are several requirements processes available (Hull, Jackson, and Dick, 2002) because the importance of requirements management has been understood. As requirements engineering is a well established discipline, details of the different approaches will not be disussed here. Instead, we will concentrate on describing the approach for the OEPI project which is based on the observation that different requirements processes have quite similar phases. Thus, the process used in task 1.2 of the OEPI project was tailored for the needs of the project by taking into account resources, collaboration, schedule, and the nature of system to be defined (i.e. the OEPI Ontology). The applied process comprises the following phases: requirements capture, analysis, negotiation, documentation and validation. (Figure 3 on page 18 shows the corresponding activity diagram. It is presented there in the context of the overall ontology development approach.) In the sections below, the requirements process phases are introduced briefly and their application in the OEPI project is described by means of inputs, outputs, goals, steps, methods, participants, experiences, and purposes. This introduction is given in a sequential form although there are iterations, parallel progress, and feedback couplings in the process. Information about the achieved results of the ontology requirements process is summarized by chapter 3 and supplemented by annex A Requirements Capture Requirements are proposed in the requirements capture phase. The goal of the phase is to gather all the represented requirements and to document them by using terms of proposers (end users). The OEPI project uses standards and initiatives, organizational and sector specific common practices, and results of information management system analysis as input material. This material has been produced in task 1.1 of the project (Jamous and Müller, 2010). The ontology requirements were collected in several stages in a collaborative process between domain experts and requirements engineers. The following sources were used: Use Cases: The OEPI requirements in general are user-driven. Business use cases were specified in the beginning of the project and covered scenarios such as sourcing and procurement, design for OEPI_D_1_3_Final.doc Dissemination Level: Public Page 9

18 environment, network & circuit provisioning, and environmental communication 4. Among other things, these use cases specified how EPIs will be used in the business context. This view provided valuable input for ontology requirements. As a first step, we scanned the user requirements based on the use case specifications and extracted the ones that have direct ontology requirements. This ensured that the EPI language will be suitable to express the business needs. Expert interviews: It was quickly clear that the use cases are not sufficient to extract all the domain knowledge needed, primarily because they focus on EPI leverage rather than EPI specification and expressiveness. Therefore, we conducted four sets of interviews, each including a different pair of experts: one an expert in environmental assessments and indicators and another an expert in requirements engineering. The intention was that the latter captured and described the domain knowledge of the former in a way suitable for the requirements process. Different tools were used for that, from a flat list of description statement to hierarchies of EPI representations. Iterative improvements: The different sources of EPI requirements and documentation needed several iterations of improvements which were performed sequentially. Each contributor went over the latest lists of requirements by adding missing ones, deleting duplicates, merging similar ones, and passing results to the next contributor. During the process, a predefined set of attributes was added to every requirement for management and tracking purposes. Refer to chapter 3.2 for details Requirements Analysis The aim of requirements analysis is to classify and relate the captured requirements to each other in order to prepare material for a negotiation phase. In the OEPI project, requirements engineers and ontology specialists checked and classified the requirements with regard to the following criteria: clear unclear requirement The dimension describes possible missing definitions for terms used in the requirement or the requirement could not be related correctly to other requirements. abstract concrete requirement The dimension observes whether a requirement needs further specification or sub-requirements before design phase. 4 See as a reference the OEPI deliverable D3.1 Overview of design criteria for consumption channels and key requirements for OEPI Service Aggregation that is released at the same time as this report. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 10

19 quality expressive requirement Quality requirements state objectives for quality attributes of ontology (e.g. usability, maintainability, testability) and expressive requirements state needs for representation power of ontology or constraints for usage of concepts. ontology non-ontology requirement Non-ontology requirements are proposed to be discarded because they are covered already by related requirements or in duplicate requirements or because they are not related to ontology and could be forwarded to other areas of requirements capture in the project (like platform or user requirements). In addition, interrelationships of the requirements were established. Parent of and child of relationships were used to join more concrete requirements under an abstract single one. Related to relationships were added between requirements if they had some meaningful association and duplicate of relationships were used for possible similar or equivalent requirements. Some requirements were also split to smaller ones in order to enable references to other suitable entities. Also, initial phases of concept analysis (Siff, 1998) were used to collect existing objects, their properties and relationships. Objects were not classified and thus neither concepts nor concept hierarchies were identified. Concept forming and creation of concept hierarchies can only be done after specification of concepts Negotiation Phase The goal of this phase is to produce one complete, clear, consistent set of requirements that has been agreed upon by all particpating stakeholders. For ontology development in the OEPI project this meant that the project consortium had to achieve a common understanding about the semantics of ontology requirements. In order to fulfil this goal, the negotiations were initialized and organized. First, the requirements were discussed in weekly meetings among the participants of work package 1 which is responsible for this task. Results were documented directly in the captured requirements. In order to finalize the consolidated ontology requirements, the most challenging requirements were also processed at the full Consortium Meeting in Madrid (September 22 nd 23 rd, 2010) with participants of the other work packages Documentation In the documentation phase the consolidated ontology requirements and related materials are finalised for the validation phase. Observations of the analysis phase and comments from negotiation are documented and represented with familiar terms. In OEPI, requirements engineers and ontology specialists participated in this phase in order to ensure knowhow exchange. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 11

20 2.1.5 Validation The final phase in the requirements process is the validation of documented requirements and analysis results. Aim of validation is to ensure that the results are documented in a right and structured way and traceability is preserved. The OEPI project used a two step review convention. In the first step the results were reviewed by the work package partners. After that, their comments were taken into account and documents were updated. In the second phase, the results were reviewed by domain experts and business partners. See chapter 3 and annex A for details about the resulting requirements. 2.2 Ontology Design Process This chapter describes different possible approaches to build ontologies (subchapter 2.2.1), specific conditions or constraints with impact on this task in the OEPI project (subchapter 2.2.2), and the suggested approach for ontology design based on the given preconditions (subchapter 2.2.3) Overview of Methodologies for Ontology Development Due to the fact that ontology design as a discipline is not the main focus of the OEPI project, this subchapter will provide only a brief overview of different approaches for ontology development. Its purpose is to illustrate the main options and important considerations that should influence the process that will be followed in the OEPI project. Research on this topic shows that there is no standard methodology that could be applied and that there is no best-practice of ontology development. Nevertheless, it is possible to describe characteristics of different approaches, which can be used to identify the approach that is best suited for the OEPI project. A detailed analysis has been performed by (Fernández-López and Gómez-Pérez, 2002). That analysis and another paper by (Corcho, Fernández-López and Gómez-Pérez, 2003) have been evaluated to compile the summary in Table 2. Furthermore, the simple and iterative approach that is described in the often cited tutorial by (Noy and McGuinness, 2001) has been taken into consideration as well. The whole process of ontology development can be described as a lifecycle which includes creation, population, implementation, and maintenance of ontologies (Youn and McLeod, 2006). Besides the basic tasks in these phases, further tasks like ontology re-engineering, ontology learning, ontology evolution, or ontology merging are recognized. Except for ontology merging, which is useful in case of ontology reuse, those latter mentioned tasks are of minor interest for the OEPI project because it does concentrate on delilvering a first version of an ontology and will not accompany further stages of its lifecycle. While methodology describes a way to accomplish the task, there is furthermore the question how to judge and ensure that the right ontology has been created. Therefore, the chosen methodology should reflect objectives that have to be met by the ontology and it should include activities to evaluate the ontology. (Noy and McGuinness, 2001) point out that the perception of quality of a domain model that is OEPI_D_1_3_Final.doc Dissemination Level: Public Page 12

21 represented by an ontology depends on the intended application and future extensibility, but there are also methodologies that can be considered as application-independent. It will be analysed later in this chapter which perception is suited better for the OEPI project. Methodologies for building ontologies were proposed and used first in the fields of knowledge engineering and artificial intelligence. On the one hand, they were needed as a means to create knowledge bases from scratch that capture knowledge from human experts in a structured way. On the other hand, they were used as a means to extract knowledge from various existing resources like natural language documents or multiple different knowledge bases and to create formalized, computer-accessible descriptions of it. With the growing importance of the World Wide Web and the recognition of its limitations due to the lack of semantics, ontologies are expected to leverage the transition towards the Semantic Web or Web 2.0. This new purpose yields changes and advancements in the methodologies used for building ontologies, too. Table 2 summarizes methodologies for building ontologies according to (Corcho et al., 2003; Noy and McGuinness, 2001): Table 2: Methodologies for Ontology Building Methodology (Key reference) Uschold and King (Uschold and King, 1995) Grüninger and Fox (Grüninger and Fox, 1995) Summary Activities: 1. identify purpose of ontology 2. build it (capture knowledge, code it, integrate other ontologies) 3. evaluate it 4. document it Strategies for identification of main concepts: top-down most abstract first, then spezialize bottom up most specific first, then generalize middle out most important first, from there generalize and specialize Steps: identify main usage scenarios form relevant competency questions to determine scope extract concepts, properties, relationships, axioms from compentency questions and their answers formally express resulting components in Characteristics development from scratch, with or without reuse of ontologies application-independent very formal, can be used to transform informal scenarios in computable models semi applicationdependent OEPI_D_1_3_Final.doc Dissemination Level: Public Page 13

22 Methodology (Key reference) KACTUS project (Schreiber, Wielinga and Jansweijer, 1995; Bernaras, Laresgoiti and Corera, 1996) Method based on SENSUS Ontology (Swartout, Ramesh, Knight and Russ, 1997) METHONTOLOGY (Fernández-López, Gómez-Pérez, Pazos- Sierra and Pazos-Sierra, 1999) On-To-Knowledge (Staab, Schnurr, Studer and Sure, 2001) Ontology building according to: (Noy and McGuinness, 2001) Summary first order logic abstraction process ( bottom up ) based on an application knowledge base resulting ontology will be adapted to next similar application and so on for further applications leading to a more generalized ontology in each iteration top-down approach for deriving domain specific from huge ontologies framework for building ontologies, including: identification of development process (which tasks to perform?) life cycle based on evolving prototypes (which stages have to be passed through by ontology?) particular techniques to carry out activities output products of activities and how to evaluate them includes identification of goals, analysis of usage scenarios Steps: 1. Kick-off (capture ontology requirements, identify competency questions, study reusable ontologies, build first draft) 2. Refinement (produce mature and application-oriented ontology) 3. Evaluation (check requirements and competency questions, test ontology in application environment) 4. Ontology maintenance Steps: 1. Determine the domain and scope of the ontology 2. Consider reusing existing ontologies Characteristics requires existing application knowledge base as starting point application-dependent starts with huge existing ontology semi applicationdependent starting from scratch, with possible reuse or re-engineering of ontologies application-independent supported by tools WebODE, ODE starting from scratch, with or without reuse of ontologies application-dependent starting from scratch, with or without reuse of ontologies application-dependent OEPI_D_1_3_Final.doc Dissemination Level: Public Page 14

23 Methodology (Key reference) Summary 3. Enumerate important terms in ontology 4. Define the classes and the class hierarchy 5. Define the properties of classes ( slots ) 6. Define the facets of the slots 7. Create instances Characteristics based on experience with: Protégé-2000, Ontolingua, Chimaera All the methodologies that have been listed above do not cover the aspect of collaboration sufficiently. Important challenges in this area that have been named by (Lu, 2003), for example, are: communication problems that are intensified by distance, synchronization of documentation and knowledge management, and version control and the tracking of changes. In the last decade more research effort was spent in this direction. (Holsapple and Joshi, 2002) provide a general categorization of approaches to ontology development that is summarized in Table 3. Table 3: Categorization of Methodologies for Ontology Building Approach type Inspirational Inductive Deductive Synthetic Collaborational Characteristics actually not a systematic methodology, because it is based on inspiration ; usually done by an individual who should be domain expert and ontology design expert, inspired by the individual view on the intended use of the ontology multiple use cases of the domain are observed and examined; results are then applied to further use cases, which leads to evolutionary improvement of ontology general principles about the domain are described and then are applied and tailored to the specific use cases existing ontologies are identified which can be (partially) reused to build a new ontology, which might be extended by completely new parts multiple individuals or groups develop views about the domain which have to be integrated and consolidated; an initial ontology might be used as an anchor A comparison of the approach types in Table 3 with the methodologies as characterized in Table 2 lead to the impression that methodologies not necessarily match exactly one of these types completely but might be of a hybrid type, which combines characteristics of different types, as well. The multiplicity of possible approaches that are proposed and described in literature furthermore show that there is currently no standard so far and no one fits all methodology. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 15

24 In the next section, the specific conditions of ontology development in OEPI will be considered. They have to be taken into account for the decision about the development approach that shall be followed in this project Specific Conditions of Ontology Development in the OEPI Project In the course of work package 1 of the OEPI project, the following activities were identified as helpful for the process of ontology development: Requirements analysis (see chapter 2.1 for process description and annex A for results) The main origins of requirements are: o Requirements from OEPI use cases and state-of-the-art (as documented in deliverable D1.1 (Jamous and Müller, 2010)) o Requirements from the intended use in the OEPI platform and accompanying OEPI services (WP2 and WP3) Ontology example ( prototype ) a first draft of ontology. This example supports the process of requirements analysis as well as the discussion of the ontology regarding its scope, its appropriate level of detail, and regarding possible use of the ontology by other work packages. Investigation, characterization, and assessment of related projects and ontologies, respectively, that might be used as parts of the OEPI ontology The following constraints exist for ontology development in the OEPI project: Ontology development is one particular tasks in the project and not the main focus. The ontology shall serve the goals of the project and is thus not considered a principal goal itself (even though it can be regarded as a kind of project result on its own). This imposes limits on it with regard to the depth of work and to the effort that can be invested in ontology development. Resource and time constraints of the project and the respective work packages have to be met. Therefore, ontology development shall not require a high effort of additional training. The approach shall be supported by tools that are easy to learn and to use. Collaboration of the distributed project partners has to be managed during ontology development to a certain degree, yet not on a big scale as the number of contributors will be less than ten partners Approach for Ontology Development in the OEPI Project The methodologies, which were briefly characterized in chapter 2.2.1, were compared against the conditions for ontology development in the OEPI project as summarized in chapter The results are presented in Table 4 below. The names of the methodologies refer to the ones that were used in Table 2. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 16

25 Table 4: Applicability of Methodologies for Ontology Building in OEPI Project Methodology 5 Uschold and King Grüninger and Fox KACTUS project Applicability of methodology in OEPI yes, there is no reason against its application yes, for the general approach but level of formality in expressing the ontology does not fit well for OEPI conditions (limited resources, easy to use approach) no because it requires an existing application knowledge base as starting point Method based on SENSUS Ontology METHONTOLOGY On-To-Knowledge Ontology building (Noy and McGuinness, 2001) no because it needs to start with huge existing ontology no because the approach is too comprehensive for OEPI yes, there is no reason against its application yes, there is no reason against its application The suitable methodologies have in common that they start from scratch and allow the reuse of existing ontologies. They can be categorized as being more or less inductive which means they are driven by the intended use cases even though this still includes the possibility to define some main abstract concepts independent from specific use cases (as in a deductive approach). Due to the conditions and constraints listed in chapter 2.2.2, no specific methodology will be implemented formally in the OEPI project. Instead the following OEPI approach is derived from the above considerations and will be followed informally. The development of the OEPI Ontology consists of two major phases, the requirements phase and the ontology design phase as shown in Figure 2. Figure 2: OEPI Ontology Development Process - Overview 6 5 referring to the methodology names used in Table 2 6 All activity diagrams follow the OMG standard Software Process Engineering Metamodel (SPEM) (Object Management Group, 2008). OEPI_D_1_3_Final.doc Dissemination Level: Public Page 17

26 The requirements phase as shown in Figure 3 comprises two parallel, yet interdependent threads: The actual requirements process with the steps as described in chapter 2.1 and an early ontology prototyping, which supports the requirements process. Figure 3: OEPI Ontology Development Process - Requirements phase The ontology design phase as shown in Figure 4 includes an activity for concept definition and an iterative process of ontology design. Figure 4: OEPI Ontology Development Process Ontology design phase The concept definition is a task that extracts all concepts from the requirements definition that have to be represented in the ontology and provides a glossary with a description for every concept. The descriptions have to be created from the OEPI use case descriptions, from the deliverable D1.1 (Jamous and Müller, 2010) and from the documented ontology requirements. They shall be independent of their later implementation in the ontology. The steps of the concept definition are shown in detail in Figure 5. The revision of the glossary is based on reviews by the sustainability domain experts. Figure 5: OEPI Ontology Development Process Ontology design phase concept definition The iterative ontology design as shown in Figure 6 repeats activities to define and to review the OEPI ontology until the documented requirements are met. For the definition of the ontology the guideline provided by (Noy and McGuinness, 2001) shall be used. The review process of the ontology has to include the domain experts as well as the developers of the OEPI platform and services. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 18

27 Figure 6: OEPI Ontology Development Process Ontology design phase iterative ontology design The methodology has been considered up to now independent of the means of expressing the ontology and independent of the tools to be used during the process. These aspects are covered in chapter 5 of this document. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 19

28 3 Ontology Requirements Whereas chapter 2.1 concentrated on the topic of performing the requirements process, this chapter deals with the subject matters of the process with regard to ontology requirements in general and in the OEPI project in particular. 3.1 Scope and Purpose of Ontology Requirements To understand what are ontology requirements, the meaning of the terms ontology and requirement has to be analysed and related to the OEPI project context. Ontology backgrounds, basic elements, and design principles have already been presented in chapters 1 and 2. Next, we focus on modelling viewpoint and a relationship between models and requirements. Especially, a relationship of ontology and requirements is considered. In the field of knowledge representation (Baader, 2007) and computer science (Hitzler, Krötzsch, Parsia, Patel-Schneider, and Rudolph, 2009) an ontology is understood as a model, information model, or information base which precisely describes and captures knowledge of a domain of interest. It is a result of an ontology design process. Note, that there exist also other kinds of models which are results of other processes. An information model contains intensional or general and extensional or case specific knowledge. Intensional knowledge describes timeless facts of a problem domain and extensional knowledge states the contingent facts or the state of a modelled world. According to the knowledge type, the model is typically divided into a terminological part and an assertional part, respectively. The terminological part provides a set of central terms, the vocabulary, and fixes their meanings by characterizing terms by possible relationships to other terms. The terminological part can also classify terms to form a taxonomy and define constraints on the usage of terms. The assertional part deals with concrete objects, also called individuals, and with values to represent an area of concern. Individuals have identities and they can be counted. Values are identified by parent individuals and they are, for example, integers, strings, lists and tuples. Requirements are statements for defining a scope of a system and representing needs of stakeholders (Hull et al., 2002). Often, they are represented in natural language which is also a challenge to tackle during the requirements process. Goals represented by requirements can be conflicting but despite of this they enable the management of changes and risks in the earliest possible stage. Requirements themselves are not a model of a problem domain. A model is an abstraction of a system. It focuses only on some aspects of a system and ignores non-relevant details. A particular model never expresses everything about a system. In contrast, requirements try to be a complete and unambiguous definition of a system. Models can be used to complete requirements but requirements cover also those aspects that are not modelled. Especially, if requirements are expressed in natural language, it is necessary as a preventive means of quality assurance to follow a formalism in their description by specifying a set of attributes that has to be covered for every single requirement. Table 5 lists possible attributes of requirements according to (Hull et al., 2002). OEPI_D_1_3_Final.doc Dissemination Level: Public Page 20

29 These attributes are used to complement the description of a requirement and are needed to support the requirements process as outlined in chapter 2.1. Table 5: Attributes of requirements (Hull et al., 2002) Attributes Identification Intrinsic characteristics Explanation / examples unique reference and/or name to summarize the subject classifications at least for basic type, quality factor and life-cycle phase, for example: functional, maintainability and development Priority and importance for example: key mandatory optional desirable; must should - could wish; or numerical rating Source and ownership Context Verification and validation Process support Elaboration Miscellaneous name of document, stakeholder and approver subject and scope selected methods, state of requirements and rationales For example: proposed qualified - satisfied - reviewed questions, responses, comments and rationales maturity, risk level, estimated/actual costs, product release As a conclusion, ontology requirements are statements to describe requirements for the central terms in the domain of interest and for the concepts representd by the terms. The requirements and their relationships form a base for exploration of the domain of interest and for achievement of a common understanding about terminology, its underlying concepts and their meaning ( semantics ). An ontonlogy designed to match these requirements captures this common and agreed understanding. It can serve as a foundation of formalized domain knowledge for implementation of different kinds of application logic systems and for information system platform development. The requirements attributes are a base for change control during development of ontology and technological solutions. 3.2 OEPI Ontology Requirements The purpose of the OEPI ontology requirements process was to capture expressive and qualitative requirements for the OEPI Ontology that had to be specified and designed in subsequent tasks. Expressive requirements concentrate on intensional knowledge and the terminological part of ontology. Qualitative requirements state needs for quality factors which can be satisfied and validated only in the later project phases. They indicate fitness of ontology for its purpose. In the project, an appropriate level for natural language statements was achieved by using the report of standards and initiatives as input material (Jamous and Müller, 2010). OEPI_D_1_3_Final.doc Dissemination Level: Public Page 21

30 Table 6 lists the main attributes that were used to describe OEPI ontology requirements. They were selected in order to foster discussion and tracking of background information and to ensure knowledge exchange within and across project phases and work packages. Table 6: Main attributes of OEPI requirements Attribute Explanation / examples ID Project Date Submitted Ontology/Platform/User requirement :23 Last Update :55 Reporter Priority Status Assigned To Summary Description Type Reason Source Links Notes name of person high normal - low proposed - assigned name of person short description full description functional - non-functional Rationale reference to external document reference to web resource Discussion In the requirements capture phase, 36 requirements were collected. At first, the project used word documents and wiki pages with a template for that purpose but usability was not sufficient. Therefore, the Mantis system 7 was utilized. It provided better features to customize the system for the project needs like linking and reporting requirements or capturing requirements in a parallel and distributed way. In the analysis phase, the requirements were classified and interrelated. In addition, they were split to usable size entities. Thus, the number of the requirements increased to 49. Table 7 shows a list of the OEPI requirements including attributes ID and Summary (sorted by ID ). 7 see OEPI_D_1_3_Final.doc Dissemination Level: Public Page 22

31 Table 7: List of OEPI ontology requirements (ID / Summary) ID Summary 1 Provide concept for definition of Environmental Performance Indicators 2 Support data source integration (semantics) 3 Support DPSIR classification of EPI definitions (Driving force, Pressure, State, Impact, Response indicator) 4 Support consumption and reduction types of EPI values 5 Support specification of covered lifecycle stage(s) for EPI values 6 Support specification of data collection method of EPI values 7 Support quality rating of EPI values by quality aspects and rating values 8 Provide references to normative documents for EPI definitions 9 Support usage directives for EPI definions 10 Support hierarchical composition of EPI definitions 11 Support classification of required / optional EPI for industrial sectors or products 12 Ensure usability for intended ontology users 13 EPI may specify deviation rate / signaling threshold 14 Support modelling of information transmission 15 Support handling of information trigger 16 Compliance with taxonomy 17 Support absolute and relative EPI values 18 Support mapping to / integration of EPI standards 19 Represent stakeholder groups (e.g. Creator, Owner, Quality rater) 20 Support guidelines for measurement 21 Support selection of measurements 22 Support specification of calculation rules for EPI values 23 Support specification of EPI-related parameters that can be used in search queries 24 Support concept for compatibility of EPIs 25 Support concept for specification of assumptions related to EPI values 26 Support impact categories with different levels (world, industry, organization,...) 27 Include related environmental aspect in EPI definition 28 Include possible EPI unit(s) matching env. aspect in EPI definition 29 Describe scope in the sense of what is included in EPI definition 30 Support specification of data origin of EPI values 31 Support specification of the creator of an EPI definition 32 Support description of the methodology how an EPI value can be determined 33 Support aggregation of EPI values in a specified time range 34 Support concept of comparability of EPI values 35 Support specification of uncertainty as part of data quality 36 Support international use OEPI_D_1_3_Final.doc Dissemination Level: Public Page 23

32 ID Summary 86 Support specification of reporter of EPI quality 87 Support description of time scope for EPI values (measurement period) 88 Support specific levels of primary data for product EPI (product, facility, organization) 89 Support different GHG scopes of organizational EPI values 90 Support specification of applied allocation principles in EPI value calculation 91 Support specification of applied allocation principles for GHG scope 3 92 Support specification of base unit of relative EPI values 93 Support relative EPI values with respect to other EPI values 94 Support material efficiency as product or process EPI 95 Provide concept to describe to which object an EPI value is related 96 Support specification of an owner of related object of EPI value 97 Support specification of input aspects of EPI (energy, water, material,...) 98 Support specification of output aspects of EPI (emissions, liquid waste, solid waste,...) The results of the analysis with regard to classification and relationships are presented in Table 8 on page 25. The number in the first column of that table indicates the requirement ID. There were two different kinds of negotiations as explained in chapter After the negotiation phase, there can still be quite abstract requirements which need further specification but unclear requirements have been clarified and requirements not related to ontology have been removed. The negotiation phase was very challenging because participants had different backgrounds and points of view related to ontology requirements. In this phase, eight requirements were classified as non-ontology requirements. In other words, they were discarded in agreement with the author or classified as system or platform requirements, respectively. The requirements were further analysed to extract the candidates for ontology concepts and their properties. The results were captured in a two-dimensional spreadsheet and used as additional input for ontology design. In the documentation phase, the consolidated ontology requirements and related materials were finalised for the validation phase. The validation phase was done according to the tailored requirements process. The full version of captured and negotiated requirements were exported from the Mantis database to be included in a printable format in annex A of this report. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 24

33 Table 8: Classifications and interrelationships of ontology requirements OEPI_D_1_3_Final.doc Dissemination Level: Public Page 25

34 4 Reuse of Ontologies The purpose of this chapter is twofold: firstly, to summarize current knowledge about possibilities of reusing ontologies and secondly, to suggest potential candidate ontologies that could possibly be utilized during creation of OEPI Ontology. It should be noted that the work presented in this chapter has been done in parallel with the requirements analysis for OEPI Ontology. Therefore, the research of relevant existing ontologies was based on common knowledge and on the documented state-of-the-art for EPIs only (see deliverable D1.1 (Jamous and Müller, 2010)). The assessment of the suggestions with regard to OEPI ontology development and the decision about actual reuse of existing ontologies were parts of the subsequent task of ontology design. Results of that phase pertaining to reuse are described in chapter as part of the Design and Application of Ontology. 4.1 Introduction A cost effective and high-quality ontology heavily relies on the reuse of existing ones and reusability of the created ontology. The reuse of already existing ontologies (or at least parts of them) not only prevents reinventing the wheel in some cases but also reduces the effort required for ontology building. Ontology engineering has meanwhile grown to a mature discipline. Different methodologies and tools for support are readily available. Nevertheless, according to Bontas and Mochol (2005) most ontologies are still a result of some ad-hoc application- and domain-dependent engineering process. Building ontologies from scratch is time-consuming and error-prone. In order to weaken this challenge for the development of new ontologies, the knowledge sources available on the Web should be harnessed. If such existing ontological knowledge is used as an input source for the creation of new ontologies, we call this process ontology reuse. The reuse of ontologies can be seen from different angles. Pinto and Martins (2000) condense them into the two aspects ontology merging and integration (see also: Bontas and Mochol, 2005): Assembling, extension, specialization and adaption of other ontologies and making them parts of one s own ontology Unifying a set of ontologies on a similar concept by merging them into a single one Consequently, the processes leading to the reuse of ontologies can be distinguished in (Pinto and Martins, 2004): Fusion (or merging): Creation of a new ontology by unifying knowledge from different sources. An ontology on a given subject is built by reusing knowledge of two or more ontologies on the same subject. Composition (or integration): Creation of a new ontology by assembling of source ontologies. An ontology on a given subject is built by reusing knowledge of two or more ontologies on different subjects. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 26

35 Figure 7: Options for reusing ontologies; modified from (Pinto and Martins, 2004). Figure 7 shows the differences in these processes and their results. Fusion usually leads to overlapping knowledge (see left side of picture) whereas composition suffers from overlap in concepts (see right side of picture) (Pinto and Matins, 2004). Chapter 4.2 provides a more detailed overview of different approaches of reuse. Besides the selection of the approach to be taken, the most important task is the identification of suitable candidates for reuse. Differences between ontologies that have to be considered may not only be found in represented content but also in formalities like representation format (OWL, RDF...) or degree (thesaurus, schema, UML structure...). Translation tools are available for some representation formats. Though, even with the help of tools human interaction or interventions usually become necessary (Bontas and Mochol, 2005). Chapter 4.3 summarizes common considerations with regard to evaluation and assessment of ontologies that have been identified as candidates for reuse or integration. The identification of potentially reusable ontologies usually starts with a search of relevant knowledge sources. Chapter 4.4 introduces publicly available sources that have been searched for potentially reusable ontologies within the OEPI project. Finally, chapter 4.5 takes a look at potential candidates for reuse in OEPI that have been found. Three different kinds of results are presented in subchapters: specific ontologies or reusable knowledge, top-level ontologies, and related projects. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 27

36 4.2 Approaches of Reuse There exist several approaches with individual advantages and drawbacks for reusing existing ontologies. In the following, we will present the most widely used approaches Conservative Extension The most straight forward way to reuse the concepts of an ontology Q within a new ontology P is to construct the logical union P Q of the axioms contained in P and Q (Cuenca Grau, Horrocks, Kazakov, and Sattler, 2008). The union of P Q is called an extension. Importing an ontology may lead to the following problem: if the designers of the new ontology are not domain experts for the reused ontology Q, they might rely on the designers of Q that they have completely specified the meaning of the reused concepts within Q. If this is the case, i.e. if the original meaning of reused symbols defined in Q are not changed while using them in the union P Q the extension is called conservative Importing Extracted Modules Ontologies can be very large especially if they are widely established and used. Therefore, it is very likely that they contain subject matters that are not needed and in which the designers of a new ontology P who want to import an available ontology Q are not interested in. If P imports Q, reasoning over or browsing the union P Q likely becomes considerably harder even if only a small subset of the symbols of the reused ontology are used. For this reason, one would like to extract and import only a (small) subset i.e. just the needed fragments. Such a fragment that contains just the concepts of interest is referred to as a module. A colloquial definition of or rather a requirement for a module (Cuenca Grau et al., 2008) Q Q is that the union of P and Q should give exactly the same answers to any arbitrary (regarding only reused concepts) query than the union of P and Q. As it is usually of no avail to extract arbitrary modules from a reused ontology, one is heading for a minimal module that is as small as possible but nevertheless contains everything that is needed. Such minimal modules by definition do not contain any sub-module as subset. A minimal module is not necessarily unique. Cuenca Grau et al. (2008) give examples for ambiguous partitions of an ontology. The construction of minimal modules for import may depend on the actual application at hand. If an axiom does not occur in a minimal module it is not essential for P as it might always be removed from Q. On the contrary, axioms appearing in any (not necessarily all) minimal modules might be essential and should thus be imported into P. One possible way to compute the set of essential axioms is to compute all minimal modules and construct the union of all of them (Cuenca Grau et al., 2008). A module of an ontology that is bound for a reuse in another ontology should in summary posses the following properties (Doran, Tamma and Iannone, 2007; Jimenez-Ruiz, Cuenca Grau, Schneider, Sattler, and Berlanga, 2008): Self- containedness: A module is a self-contained subset of a parent ontology. Consistency: of the module. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 28

37 Concept- centeredness: A module contains a description for the start concept without direct superclasses that put the start concept in context because an engineer usually already has a context in mind for the module. Compactness: of the module. Transitivity: If a module Q Q has been extracted from a module Q Q that has been previously extracted from an ontology Q, then it follows that Q is also an module of the ontology Q. What remains is the question for appropriate algorithms and methods for (semi-)automatically extracting modules from given ontologies. Doran, Tamma and Iannone (2007), for example, present a methodology for extracting modules for reuse of ontologies Ontology Mapping If one wants to reuse ontologies or selected concepts of them, it becomes often necessary to establish a semantic mapping between the different ontologies in order to achieve an alignment of differently modelled (or named) concepts. Ontology mapping is often also referred to as ontology alignment (cf. e.g. Spiliopoulosa, Vourosa and Karkaletsis, 2010) or ontology matching. The latter term is treated here in a different way since ontology matching might also be understood (cf. e.g. de Almeida Campos, Machado Campos, Dávila, Gomes, Campos, and Lira, 2009) as a separate task for reusing ontologies (cf. section about ontology matching). A comprehensive definition of ontology mapping is e.g. given by Kalfoglou and Schorlemmer: We understand ontology mapping as the task of relating the vocabulary of two ontologies that share the same domain of discourse in such a way that the mathematical structure of ontological signatures and their intended interpretations, as specified by the ontological axioms, are respected. (Kalfoglou and Schorlemmer, 2003, p. 3) If these mappings are in addition (mathematically) structure preserving they are called morphisms. A more straightforward definition regarding practical issues is given by Xu: Given two ontologies A and B, mapping one ontology with another means that for each concept (node) in ontology A, we try to find a corresponding concept (node), which has the same or similar semantics, in ontology B and vice verse. (Xu, 2002) This definition is also used by (Ehrig and Sure, 2004b) who aim at defining the necessary similarity definitions needed for finding an appropriate mapping. Figure 8 shows a simple example for the alignment of vocabulary achieved by the mapping between to ontologies. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 29

38 Figure 8: Illustration of ontology mapping and possible alignments between vocabularies; from (Ehrig and Staab 2004) Ontology Matching Some ways of reusing ontologies result in the creation of a new ontology that is based on the concepts of other ontologies. As has been seen, the reused ontologies and their concepts might also have been extended (or altered) during their reuse for creating this new and independent ontology. Ontology matching, on the other hand, produces a different result (cf. de Almeida Campos et al., 2009): instead of creating additional ontologies that might be the result from merging and combining other (reused) ontologies, this approach does not change the reused ontologies. Original ontologies are kept unchanged and are left at their original locations (usually accessible by an URL and identified by an URI). Ontology matching than generates a set of links to these original ontologies. Such links can contain information on how to achieve compatibility. Usually, such a set of links is persisted in a separate model aside the ontologies (cf. de Almeida Campos et al., 2009). Such a set of links can also be seen as a mapping between the ontologies but without exploiting this mapping information for merging and altering reused ontologies Reuse of Ideas Instead of directly using an ontology or an extracted module for inclusion into one s own ontology, it might also be indirectly used. Such an approach leads to seizing a suggestion on the knowledge capture (for example: conceptualizing, structure, relations) of missing topics. Such an approach, of course, demands for a complete reimplementation of the reused concepts. On the other hand, it might be easier to look just for stimulation than having to extract appropriate modules from a given ontology. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 30

39 4.3 Considerations for Reuse and Integration Pinto and Martins (2000) describe a detailed process of ontology integration that is general enough to be applied in conjunction with different methods of ontology building. In particular, they provide two valuable lists of concrete considerations that should be performed on an ontology that is a candidate for integration. The first one shall be applied by domain experts as an integration oriented evaluation, the second one by ontology engineers as an integration oriented assessment. These questions are summarized here in the following two subchapters with the intention of being considered to a reasonable extent within OEPI, too, if a decision is made to use existing ontologies. The same considerations may be applied if not an ontology but just knowledge is adapted from external sources Integration-oriented Considerations for Domain Experts Domain experts should evaluate candidate ontologies according to the following questions (Pinto and Martins, 2000): What knowledge is missing? Missing knowledge (for example: concepts, classification criteria, relations) has to be identified. What knowledge should be removed? Knowledge that will not be used because it is either not important, not relevant, or usually not used to describe a certain domain (superfluous) should be removed. The same holds true for knowledge that is not needed for the use of the new ontology. What knowledge should be relocated? Pieces of knowledge (like concepts or relations) might become broader in meaning so that they should be relocated; i.e. a relation distributed-by might be shifted up in hierarchy in order to be applied between more classes as before. Which knowledge sources should be changed? Parts of the sources that are not reputable or up-todate enough might be substituted by better sources. Which documentation should be changed? Sometimes, only the documentation of the domain is incorrect, incomplete, or not up-to-date. In this case, the documentation has to be updated. Which terminology should be changed? Parts of the used terminology that do not reflect usually accepted terminology in a certain field of expertise or that are not compliant to a given standard must be replaced. Which definitions should be changed? Definitions that are not usually accepted or are composed of unusual characteristics (relation Member-of-club within the definition of person) are to be changed. Which practices should be changed? If the used procedures for knowledge acquisition during ontological engineering of the ontology in question (for inclusion) are not correct or do not follow accepted practices within the domain of this ontology, the ontology might have to be revised or changed in order to enforce best practises. For example, if information has been gathered from different sources this is not acceptable e.g. in the chemical sector. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 31

40 4.3.2 Integration-oriented Considerations for Ontology Engineers Ontology engineers should assess candidate ontologies according to the following questions (Pinto and Martins, 2000): General structure of the ontology: For an assessment of the general structure Pinto and Martins (2000) give the following six criteria: o Adequacy of the structure (one or several hierarchies, a graph, well-balanced) o Modularity, i.e. is the ontology split-up into adequate (natural parts and with appropriate quantity and quality) modules or sub-ontologies? o Are the needed concepts and their specializations adequately represented? o Correct use of inheritance o Is the diversity high enough for an easier introduction of new concepts? o Are similar concepts close to another and vice versa for more distinct concepts in order to minimize the semantic distance between sibling concepts? Basic distinctions: All relevant and required basic distinctions, i.e. classification criteria made of the concepts, should be already represented in the ontology in quantity and quality. A change of the basic distinctions (represented at the upper level) upon which the ontology is based usually implies a huge revision. Structuring relation: The privileged relation (e.g. is-a, part-of, etc.) upon which the ontology is structured should be the required one. Changes here would lead to major revisions because a complete new organization of the knowledge (according to the other relation) would have to be introduced. If a ontology has to be restructured according to a e.g. is-a relation instead of a part-of relation, it might be simpler to start from scratch. Naming convention rules: This relates to the question whether knowledge pieces (like concepts or relations) follow standardization rules. Wherever possible, such naming conventions should be enforced for increased usability. Definitions of knowledge pieces: should follow a unified pattern, be clear and unambiguous, concise, consistent, complete, lexically as well as syntactically correct, precise and accurate. Moreover, the definition should be efficient. Documentation: The documentation should be clear and helpful. Unfortunately, documentation is probably still the most neglected component although it is a principal constituent in the case of ontology. Represented knowledge pieces: All and only the necessary knowledge pieces should be represented. Missing or superfluous knowledge pieces must be added or deleted respectively. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 32

41 4.4 Web Resources for Reusable Ontologies One important question is where to get candidate ontologies for reuse. Although nowadays many ontologies are available in the Web, there is no central point for getting information about available ontologies and their concepts. This section lists some possible points of reference that were used to get preliminary information on candidates for reuse in the OEPI project Ontology Lookup Service The Ontology Lookup Service (OLS 2010) 8 resulted from a spin-off of the PRIDE (PRIDE 2010) project. The service provides a centralized query interface for ontology and controlled vocabulary lookup. A web service interface is provided (besides the opportunity of web-based querying) for querying multiple ontologies (Cote, Jones, Apweiler, and Hermjakob, 2006). Unfortunately, only ontologies that are already in the repository of this search engine can be found by the help of this tool Ontosearch According to the homepage of the project (Ontosearch2, 2010) it explains ontosearch as follows: ONTOSEARCH2 is a search and query engine for ontologies and ontological data on the Semantic Web. It allows ad-hoc queries across hundreds of OWL files using the SPARQL query language. It is made possible to perform adhoc SPARQL queries over their own repository of different OWL data. OWL is reduced to DL-Lite what leads to a reduction of complexity and faster queries. Unfortunately, only ontologies that are already in the repository can be found by the help of this tool Swoogle The Semantic Web Search Engine Swoogle (Swoogle 2007) provides an online means for searching (according to their own statement) over different ontologies. Actually ontologies, documents, terms as well as data published on the web are crawled and can be searched for. In addition, the results are ranked according to an algorithm similar to the page rank algorithm (Ding, Finin, Joshi, Pan, Cost, Peng, Reddivari, Doshi, and Sachs, 2004) Conventional Search Engines Although not tailored to the particular needs for searching for or rather within ontologies, traditional search engines (e.g. Google) provided the richest source of information on candidate ontologies. Search engines can be exploited in two ways: Conventional Web search Direct search within ontologies 8 The corresponding URL is listed under the indicated short name in annex B. This is done in the same way for all web references in this chapter. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 33

42 Harnessing special query keywords like filetype: or inurl: in addition to the actual search phrases enables narrowing the results for example to certain types of documents. To give an example: measuring unit filetype:owl only looks up OWL-files within the Web for measuring units. Currently, there are about OWL files that are indexed by the search engine Google. 4.5 Potential Candidates for Reuse Research for ontologies or ontological knowledge that could possibly be used within OEPI was conducted in three areas: specific ontologies or reusable knowledge, top-level ontologies, and related projects. The results are presented in the following subchapters 4.5.1, 4.5.2, and 4.5.3, respectively Specific Ontologies or Reusable Knowledge A search of the resources presented in chapter 4.4 lead to the results presented in this section. Unfortunately, the majority of publicly available ontologies are often lacking a proper documentation. This fact makes it an error-prone task to preselect proper candidates for reuse. Nevertheless, some interesting assets which may serve as sources of ideas for certain concepts or aspects that are needed in OEPI have been identified: UncertML (Williams, Cornford, Bastin, and Pebesma, 2009) provides concepts (defined in XML- Schema) for the description and communication of uncertainty (in data). As environmental performance data is likely to at least partly rely on uncertain or derived or extrapolated data, a concept for describing this data quality will be usefull. QUDT - Quantities, Units, Dimensions and Data Types in OWL and XML. The QUDT Ontologies, and derived XML Vocabularies, are being developed by TopQuadrant (2010) and NASA (2010) as part of the NASA Exploration Initiatives Ontology Models (NExIOM) project, a Constellation Program initiative at the AMES Research Center (ARC) (QUDT 2010). The project pursues two objectives: o Provision of a unified model for measurable quantities and their numerical values o Population with instance data United States Environmental Protection Agency (EPA standards 2010): The United States Office of Environmental Information provides a set of standards regarding environmental data and information. Among these is for example a data standard compliance to regulatory issues. The standards have not yet reached the level of maturity of provided ontologies. Hence, concepts may be derived from their experiences at most. In addition, the agency provides taxonomies and thesauri on environmental terms, their relationships, definitions, and relevant metadata (e.g., synonyms) (EPA SoR 2010). EnvO Environment Ontology: This project provides an ontology with the focus of supporting the annotation of the environment of any organism or biological sample. (EnvO 2010) Therefore, this ontology will maybe prove useful for OEPI in the case that the need for describing environment in the senses of habitat arises. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 34

43 Open Source Business Management Ontology (BMO 2010): An open source project that claims to bring together business process design, project management, requirements management, and business performance management (in the form of balanced scorecards) (BMO 2010). Unfortunately, the provided ontology seems to be broken or to be in an outdated format, so hence this will be a source of knowledge reuse at most. The World Resources Institute (WRI 2010) provides sources of knowledge on environmental performance indicators. Among them is the following publication: (Ditz and Ranganathan 1997) on a common framework for tracking corporate environmental performance Top-level Ontologies As already mentioned, ontologies are mostly created for a specific purpose. For OEPI, this purpose is the creation of an ontology for environmental performance indicators. Apart from these specific ontologies, there are also general ones that are called top-level or upper ontologies. They serve as a kind of superstructure above specific domain, task and application ontologies. Their purpose is to provide the possibility to integrate specialized ontologies into a generic semantic context that is levelled above them. Examples for such ontologies are those that provide proper integration of concepts into the earth system, common time and space knowledge or just proper mapping to a multilingual dictionary or thesaurus. Most of the available top-level ontologies agree on several top-level issues (Chandrasekaran, B. and Josephson, J.R. and Benjamins, 1999): There are objects in the world. Objects have properties or attributes that can take values. Objects can exist in various relations with each other. Properties and relations can change over time. There are events that occur at different time instants. There are processes in which objects participate and that occur over time. The world and its objects can be in different states. Events can cause other events or states as effects. Objects can have parts. In the following, an overview of seven top-level ontologies that have been found in our research will be given. Apart from the common agreements mentioned above, the presented top-level ontologies differ in their further structure and hierarchy of things. Figure 9 gives an impression of the fundamental differences in different top-level ontologies concepts of things. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 35

44 Figure 9: Different approaches by top-level ontologies; from (Chandrasekaran et al., 1999) Regarding possible use of an existing top-level ontology for OEPI there are several points to consider: Most top-level ontologies are very abstract. Some of them are geared toward usage in special types of domain ontologies like for example biomedical ontologies. Is the usage of a top-level ontology is really needed? It poses some overhead in general ontology development because during the development of the own ontology the concepts of the top-level ontology need to be considered. When not using a top-level ontology, it is possible that during the ontology engineering process of OEPI an own top-level ontology is created without noticing it. When noticed, the development of that OEPI top-level ontology requires significant time as well. And the created top-level ontology may not be as universal, powerful and consistent as an existing one. Descriptive Properties of Top-level Ontologies Describing top-level ontologies is a challenging task because most of them are very comprehensive. For that purpose, several key properties have to be defined in which they can be compared. Apart from technical comparison criteria, Mascardi, Cordì and Rosso (2007) suggest the following general descriptive properties in their comparison to get a common impression of ontologies: Homepage Developers Description History Dimensions Implementation language(s) OEPI_D_1_3_Final.doc Dissemination Level: Public Page 36

45 Modularity Applications Alignment with WordNet Licensing Most of these properties like homepage, developers, or history provide general information of the ontologies while others like the implementation language or modularity strive after a technological categorization. Application examples of a particular ontology allow judging its usability and possible application domains to some level. In the overview done by Mascardi et al. (2007), the alignment with WordNet seems to be confusing at first as WordNet can be seen as a top-level ontology as well but it in most applications it should be seen as a pure lingual ontology. WordNet is an effort to create a comprehensive lexical database for the English language. It provides categorization of words in different groups and provides services like synonyms for its content. Many of the described top-level ontologies provide mappings of their terms and concepts to the WordNet. That makes sense as it allows aligning the concepts of different ontologies to a well known and widely accepted lexical database. The mapping of OEPI s terms and concepts may be taken as an additional step that links them to additional descriptive possibilities. The licensing issue may be of particular interest with regard to the utilization of a specific ontology in OEPI as well, as some ontology developers charge a fee for the usage of their work. The following descriptions of top-level ontologies are taken from the survey done by Mascardi et al. (2007). In addition to their assessment of the properties described in the previous section, they tried to get their findings validated by a responsible person for the respective ontology. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 37

46 Basic Formal Ontology (BFO) Table 9 summarizes main facts about BFO. Table 9: Basic Formal Ontology (BFO) description Property Homepage Developers Description History Dimensions Implementation Languages Modularity Applications Alignment with WordNet License Description B. Smith, P. Grenon, H. Stenzhorn, A. Spear (IFOMIS, Saarland University) BFO consists in two sub-ontologies: SNAP a series of snapshot ontologies (O ti ), indexed by times and SPAN a single videoscopic ontology (O v ). An O ti is an inventory of all entities existing at a time, while an O v is an inventory of all processes unfolding through time. Both types of ontology serve as basis for a series of sub-ontologies, each of which can be conceived as a window on a certain portion of reality at a given level of granularity. The theory behind BFO has been developed and formulated by Smith and Grenon in a series of publications starting in Its current implementation in OWL has been developed by Stenzhorn with contributions from Spear. BFO contains 1 top connecting class ( Entity ), 18 SNAP classes, and 17 SPAN classes for a total of 36 classes which are, in version 1.0 of the implementation, connected via the is_a relation. The forthcoming version of BFO will incorporate relations between classes too. OWL BFO is divided into the SNAP and SPAN modules. BFO has been applied to the biomedical domain and it is currently used in building an ontology for clinic-genomic trials on cancer ( Not supported. BFO is freely available; its OWL implementation may be downloaded from OEPI_D_1_3_Final.doc Dissemination Level: Public Page 38

47 Cyc Table 10 summarizes main facts about Cyc. Table 10: Cyc description Property Homepage Developers Description History Dimensions Implementation Languages Modularity Applications Alignment with WordNet License Description Cycorp The Cyc Knowledge Base (KB) is a formalised representation of facts, rules of thumb, and heuristics for reasoning about the objects and events of everyday life. The KB consists of terms and assertions which relate those terms. These assertions include both simple ground assertions and rules. The Cyc KB is divided into thousands of microtheories focused on a particular domain of knowledge, a particular level of detail, a particular interval in time, etc. The Cyc project was founded in 1984 by D. Leant as a lead project in the Microelectronics and Computer Technology Corporation (MCC). In 1994, Cycorp was founded to further develop, commercialize, and apply the Cyc technology. Cycorp offers a no-cost license to its semantic technologies development toolkit to the research community (ResearchCyc). Additionally, it has placed the core Cyc ontology (OpenCyc) into the public domain. The Cyc KB (including Cyc s microtheories) contains more than 300,000 concepts and nearly 3,000,000 assertions (facts and rules), using more than 15,000 relations. Cyc is represented in the CycL formal language ( The latest release of Cyc includes an Ontology Exporter that allows to export specified portions of Cyc to OWL files. The microtheory approach supports modularity. Cyc has been used in the domains of natural language processing, in particular for the tasks of word sense disambiguation [4] and question answering [5], of network risk assessment [19], and of representation of terrorism-related knowledge [6]. The last release of Cyc (as well as of OpenCyc and ResearchCyc) includes links between Cyc concepts and about 12,000 WordNet synsets. Cyc is a commercial product, but Cycorp also released OpenCyc ( the open source version of the Cyc technology, and ResearchCyc ( namely the Full Cyc ontology, but with a research-only license. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 39

48 Dolce Table 11 summarizes main facts about Dolce. Table 11: Dolce (a Descriptive Ontology for Linguistic and Cognitive Engineering) description Property Homepage Developers Description History Dimensions Implementation Languages Modularity Applications Alignment with WordNet License Description Researchers from the Laboratory for Applied Ontology, headed by N. Guarino. DOLCE is the first module of the WonderWeb Foundational Ontologies Library. It has a clear cognitive bias, i.e. it aims to capture the ontological categories underlying natural language and human commonsense. According to it, different entities can be co-located in the same space-time. The authors describe DOLCE as an ontology of particulars, which they explain as an ontology of instances, rather than an ontology of universals or properties. The taxonomy of the most basic categories of particulars assumed in DOLCE includes e.g. abstract quality, abstract region, agentive physical object, amount of matter, non-agentive physical object, physical quality, physical region, process, temporal quality, temporal region. DOLCE has been developed as part of WonderWeb, a project funded as a shared-cost RTD under the European Commission IST programme. WonderWeb ran from 2002 to Although the project has already ended, DOLCE is actively maintained and used. Around one hundred of terms, and a similar number of axioms. First Order Logic, KIF, OWL. The intended use of DOLCE is within a modular library of foundational ontologies, but it is not currently divided into modules. According to the DOLCE around the world web page ( there are many projects that use DOLCE, e.g. the LOIS Project (international research on multilingual information retrieval from legal databases), SmartWeb (a centre of excellence in research on intelligent computing technologies and their application to web-based systems), AsIsKnown (a semanticbased knowledge flow system for the European home textiles industry, funded by the EC), and the projects of the Laboratory for Applied Ontology. The OntoWordNet Project aims to align the toplevel of WordNet to DOLCE to obtain an ontologically sweetened lexical resource, meant to be conceptually more rigorous, cognitively transparent, and efficiently exploitable in several applications. Download of beta version (v0.72) of the OWL alignment of WordNet 1.6 Noun Synsets to the DOLCE-Lite-Plus ontology library is available from Free download of the OWL version of DOLCE: OEPI_D_1_3_Final.doc Dissemination Level: Public Page 40

49 General Formal Ontology (GFO) Table 12 summarizes main facts about GFO. Table 12: General Formal Ontology (GFO) description Property Homepage Developers Description History Dimensions Implementation Languages Modularity Applications Alignment with WordNet License Description The Onto-Med Research Group ( GFO includes elaborations of categories like objects, processes, time and space, properties, relations, roles, functions, facts, and situations. Work is in progress on an integration with the notion of levels of reality in order to more appropriately capture entities in the material, mental, and social areas. Work on GFO has started in 1999 in the context of the GOL project (General Ontological Language). Meanwhile, several directions of research have been recognised and divided the initial project, such that GFO is now one component of a larger framework. Work on GFO remains in progress, because the development of top-level ontologies is a long-term research effort. The OWL version of GFO consists of 79 classes, 97 subclass-relations, and 67 properties. The FOL axiomatization of GFO and a KIF implementation of it are forthcoming. An OWL-DL version also exists. GFO exhibits a three-layered meta-ontological architecture consisting of an abstract top level, an abstract core level, and a basic level. The foundational ontology GFO is structured into several ontological modules including a module for functions and a module for roles. One of the aims of the group Onto-Med is the application of the GFO in the field of biomedical science. GFO has been used to represent knowledge about biological functions in the Gene Ontology, the Celltype Ontology, and the Chemical Entities of Biological Interest (ChEBI) Ontology, and GFO-Bio ( is based on GFO and is a core ontology for biology. Another area of application is the ontological foundation of conceptual modelling. Not supported. The OWL version of GFO is released under the modified BSD License ( and can be downloaded from OEPI_D_1_3_Final.doc Dissemination Level: Public Page 41

50 PROTON Table 13 summarizes main facts about PROTON. Table 13: PROTo ONtology (PROTON) description Property Homepage Developers Description History Dimensions Implementation Languages Modularity Applications Alignment with WordNet License Description Ontotext Lab, Sirma ( PROTON is a basic upper-level ontology covering the general concepts needed for a wide range of tasks e.g. semantic annotation, indexing, and document retrieval. Its design principles are (i) domain-independence (ii) light-weight logical definitions (iii) alignment with popular standards (iv) good coverage of named entities and concrete domains (i.e. people, organizations, locations, numbers, dates, addresses). PROTON has been developed in the scope of SEKT ( ), a project co-funded by the EU 6th Framework programme. It is a development of the KIMO ontology, which had been created and used in the scope of the KIM platform for semantic annotation, indexing, and retrieval. Currently, KIMO does not exist anymore; it is replaced by PROTON, KIMLO (ontotext.com/kim/2005/04/kimlo#) and KIMSO (ontotext.com/kim/2005/04/kimso#). PROTON contains about 300 classes and 100 properties. A fragment of OWL Lite. PROTON is organized in three layers including four modules: 1. System ontology module (basic layer): technical concepts substantial for the operation of any ontology-based software, e.g. semantic annotation or knowledge access tools. 2. Top ontology module: basic philosophically-reasoned distinctions between entity types, e.g. Object, Happening, Abstract. 3. Upper module and Knowledge Management module: two independent ontologies defining much more specific classes. Concepts are e.g. Mountain, a specific type of Location, and ResourceCollection, a subclass of InformationResource. As shown by many publications (ontotext.com/publications/), PROTON has been used in several domains for different purposes, e.g. semantic annotation within the KIM platform and knowledge management systems in legal and telecommunications domains. It has been used as a basis for domain ontologies in media research (project MediaCampaign) and in research intelligence (project ISTWorld) and for Business Data Ontology Not supported. The four modules of PROTON are freely accessible from OEPI_D_1_3_Final.doc Dissemination Level: Public Page 42

51 Sowa s Ontology Table 14 summarizes main facts about Sowa s Ontology. Table 14: Sowa's Ontology description Property Homepage Developers Description Description J. F. Sowa The basic categories and distinctions have been derived from a variety of sources in logic, linguistics, philosophy, and artificial intelligence. To keep the system open-ended, Sowa s ontology is not based on a fixed hierarchy of categories, but on a framework of distinctions, from which the hierarchy is generated automatically. For any particular application, the categories are not defined by drawing lines on a chart, but by selecting an appropriate set of distinctions. These categories include Object, Process, Schema, Script, Juncture, Participation, Description, History, Structure, Situation, Reason, and Purpose. Each of these categories may be either Physical or Abstract (and in both cases, it can be either Continuant or Occurrent), and it may also be either Independent, Relative, or Mediating. For example, Process is Physical, Occurrent and Independent. History Sowa s ontology dates back to The two major influences on it are the semiotics of C. Sanders Peirce and the categories of existence of A. North Whitehead. Dimensions Implementation Languages Modularity Applications Alignment with WordNet License The KIF encoding of Sowa s ontology contains about 30 classes, 5 relationships among classes, and among classes and instances (has, instance-of, subclass-of, temp-part-of, spatial-part-of), about 30 axioms. Sowa s ontology uses a first-order modal language, i.e., a first-order language with the modal operators nec and poss. A version written in KIF also exists. Sowa s ontology is not explicitly divided into modules, although each of the top-level categories can be intended as a module by its own, connected to the other ones by means of relations. Sowa s ontology inspired many existing implemented upper ontologies, and thus its exploitation in the development of second-generation upper ontologies may be seen as one, and probably the most relevant, of its practical applications. Not supported. The KIF encoding of Sowa s upper ontology can be freely downloaded from OEPI_D_1_3_Final.doc Dissemination Level: Public Page 43

52 Suggested Upper Merged Ontology (SUMO) Table 15 summarizes main facts about SUMO. Table 15: Suggested Upper Merged Ontology (SUMO) description Property Homepage Developers Description History Dimensions Implementation Languages Modularity Applications Alignment with WordNet License Description The SUMO starter document was created at Teknowledge by I. Niles and A. Pease, with a contribution by C. Menzel. SUMO and its domain ontologies form one of today s largest formal public ontologies. They are used for research and application in search, linguistics, and reasoning. SUMO is extended by many domain ontologies and a complete set of links to WordNet. SUMO was first released in December It was created at Teknowledge Corporation and was proposed as a starter document for the Standard Upper Ontology Working Group, an IEEE-sanctioned group of participants from engineering, philosophy, and information science. SUMO was created by merging publicly available ontological content into a single, comprehensive, cohesive structure. This content included e.g. Sowa s upper level ontology, the ontologies available on the Ontolingua server, and various mereotopological theories. SUMO contains about 1000 terms and 4000 axioms; if counting also the terms and axioms of its domain ontologies, it reaches the dimension of 20,000 terms and 60,000 axioms. The first-order logic language SUO-KIF ( OWL. SUMO consists of SUMO itself (the official latest version on the IEEE web site can be downloaded from suo.ieee.org/suo/sumo/sumo_173.kif), the MId-Level Ontology (MILO), and ontologies of Communications, Countries and Regions, Distributed Computing, Economy, Finance, Engineering Components, Geography, Government, Military, North American Industrial Classification System, People, Physical Elements, Transnational Issues, Transportation, Viruses, World Airports. Ontologies of terrorism are available on request. SUMO applications are documented by nearly 100 papers describing its use. The largest user community is in linguistics but other kinds of applications include pure representation and reasoning. Applications range from academic to government, to industrial ones. SUMO has been mapped to all of Wordnet v2.1 by hand. Download possible from: SUMO is free and owned by the IEEE. Download of its SUO-KIF implementation: sigmakee.cvs.sourceforge.net/*checkout*/sigmakee/kbs/merge.kif, download of the OWL implementation from ontologyportal.org/translations/sumo.owl.txt. The ontologies that extend SUMO are available under GNU General Public License. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 44

53 4.5.3 Related Projects The capturing of requirements for developing a suitable OEPI Ontology was done in parallel to the research regarding reusable ontologies. Therefore, the identification of concepts or whole ontologies for import or reuse in OEPI was quite challenging. Related projects were examined in order to get a general idea of what is publicly available. Four projects will be introduced in the following that offer several possibilities to leverage the work done within those projects: 1. SWEET may provide basic earth system related concepts to be used. 2. MEPI provides a well developed set of indicator concepts. 3. SEAMLESSprovides also a indicator system and supports the concept of scenario assessment. 4. SPiRE may serve as framework for the development of semantic web applications. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 45

54 SWEET Table 16 summarizes main facts about the SWEET project. Table 16: SWEET project in a nutshell Property title (acronym): title (extended): website: Description SWEET Semantic Web for Earth and Environmental Terminology funded by: NASA Earth Science Technology Office, Advanced Information Systems Technologies Prototyping System Earth Science Information Partner (ESIP) Federation SEEDS Prototype Grant project duration: consortium: n/a n/a output/core deliverable: upper-level ontology for Earth system science provides common semantic framework for various Earth science initiatives abstract: kind of ontology: common semantic framework for finding and using earth science data top-level ontology language: OWL 1 references: Raskin (2004) The Main Ontology Concepts The SWEET ontology is made up of 150 modular ontologies (organized by subject) and covers 4600 concepts. The primary ontologies are subdivided into faceted (i.e. concepts are divided into orthogonal dimensions) and integrated ontologies. The faceted ontologies provide a basis for superior use cases. (Non-) Living substances, physical properties and processes, earth realm, units, numerics as well as space and time constitute the faceted ontologies. On top, integrative ontologies like physical phenomena (e.g. El Niño) or human activities can be formulated. Relation to OEPI SWEET enables OEPI to build its ontology on top of readily available concepts for natural science (like math, biology, chemistry, physics, geology and the like). The existing SWEET concepts could be used for defining EPIs like the atmospheric input of x. Some ontology modules like physical properties (physical quantities or qualities with unit) could be reused in particular. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 46

55 MEPI Table 17 summarizes main facts about the MEPI project. Table 17: MEPI project in a nutshell Property title (acronym): title (extended): website: funded by: Description MEPI Measuring Environmental Performance of Industry 4th Framework Programme (Environment and Climate) of DG Research of the European Commission project duration: completed in July 2000 consortium: SPRU - Science and Technology Policy Research, University of Sussex Department of Economics and Production, Politecnico di Milano Institut für Ökologische Wirtschaftsforschung (IOeW) Institute for Environmental Studies, Vrije Universiteit Amsterdam Centre Enterprise-Environement (CEE), Université Catholique de Louvain Centre for Environmental Strategy (CES), University of Surrey IPTS Institute for Prospective Technological Studies output/core deliverable: develop quantitative indicators for the environmental performance of manufacturing firms collect data for a large number of European firms (six industrial sectors in eight countries) analyse the patterns, dynamics and drivers of performance (causes of changes in industrial environmental performance) abstract: kind of ontology: ontology language: n/a n/a n/a references: Berkhout et al The Main Ontology Concepts The MEPI project does not deliver an ontology but an indicator framework that is of interest for OEPI. Relation to OEPI The publications of the MEPI project document generic and sector-specific indicators. Some of them may be suitable for reuse in OEPI use cases. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 47

56 SEAMLESS Table 18 summarizes main facts about the SEAMLESS project. Table 18: SEAMLESS project in a nutshell Property title (acronym): title (extended): Description SEAMLESS System for Environmental and Agricultural Modelling; Linking European Science and Society website: project: follow-up: The SEAMLESS Association funded by: EU Framework Programme 6 (Global Change and Ecosystems); Integrated Project project duration: 2005 till March 2009 consortium: output/core deliverable: too many to list (29 scientific partners from 13 European countries, Mali and USA) Integrated Framework (name: SEAMLESS-IF), which uses a set of ontologies for server side services abstract: "integrated assessment of agricultural systems at multiple scales (from field, farm, region to EU and global)" (van Ittersum et al. 2008, p. 152) scenario assessment "through a set of indicators that capture the key economic, environmental, social and institutional issues" (van Ittersum et al. 2008, p. 153) kind of ontology: ontology language: references: task or application ontology OWL Van Ittersum et al and project documentation (deliverables) The Main Ontology Concepts The SEAMLESS ontology was split up to eleven files, each covering distinct aspects. Some of them contain basic concepts like crop, crop product and grouping of crop related concepts, concepts on farms, their regions, soils and climate. The sophisticated ones specify scenarios and integrated assessment problems, management activities or concepts on rotations and farmers choices in production. In addition an ontology for the CAPRI-model (Heckelei & Britz, 2001) exists. Relation to OEPI Within the scope of SEAMLESS, indicators for scenario assessment of sustainability and institutional aspects of agricultural systems were developed. In the OEPI project, environmental performance indicators will be used to assess or compare different, competing supplier within the sustainable procurement use case. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 48

57 SPiRE Table 19 summarizes main facts about the SPiRE project. Table 19: SPiRE project in a nutshell Property title (acronym): title (extended): website: funded by: project duration: Description SPiRE Semantic Prototypes in Research Ecoinformatics NSF Award , ITR: Science on the Semantic Web -- Prototypes in Bioinformatics September 1, 2003 till May 31, 2011 (estimated) consortium: UMBC CSEE department, University of Maryland MindSwap Laboratory, University of California Davis Division of Environmental Studies Rocky Mountain Biological Lab NASA Goddard Space FLight Center output/core deliverable: develop a framework to facilitate science research and education on the semantic web abstract: prototype tools and applications for use in the biocomplexity and biodiversity domains kind of ontology: ontology language: domain ontology ontology language: OWL-DL references: The Main Ontology Concepts The SPiRE project provides different ontologies, each split up conceptually into separate documents. The most important SPiRE ontology is called SpireEcoConcepts. It allows for specifying food webs (predator-prey relationships) of different habitats (e.g. abyssal, urban, etc.). Relation to OEPI The ontologies provided by SPiRE could not be reused directly. However, the SpireEcoConcepts ontology can be used as source of inspiration, inasmuch as supply chains are alike to food chains in principle, just differing in focus. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 49

58 5 Enabling Technologies and Tools This chapter covers two main areas of work: Development of the OEPI Ontology and use of the OEPI Ontology in further work packages for the development of the OEPI Platform (WP2) and possible OEPI solutions or services (WP3). Regarding the first area, the objective is to define a tool-supported approach that allows for comfortable development of an ontology matching the requirements that are elaborated in chapter 3 of this document. The resulting ontology shall be delivered in a representation which is suitable for its intended use within the project as well as for publication as a stand-alone project result. Tool-supported approach is to be understood here as a consistent combination of ontology language and editing tool. Subchapters 5.1 and 5.2 discuss the related topics. Considerations about the underlying methodology, independent of language and tools, have been presented in chapter 2 of this document already. Regarding the second area of work, the objective is to outline possible means to support the process of building software for work packages WP2 resp. WP3 in conformance with the OEPI Ontology. The topics related to this area of work are covered in subchapter Ontology Languages Only a brief summary shall be given here. A rather detailed overview of the history of ontology languages can be found for example in (Corcho et al., 2003). Development started in the area of artificial intelligence at the beginning of the 1990s. Those early languages were, for example, KIF 9, Ontolingua, OCML 10, FLogic, or Loom. The second wave of ontology languages after 1995 was driven by the aim to improve the exploitation of the World Wide Web. These languages were called web-based ontology languages or ontology markup languages. They include SHOE 11 (first based on HTML 12, then on XML 13 ), XOL 14, and RDF 15. Resource Description Framework was developed by the World Wide Web Consortium (W3C). It was extended by RDF Schema (RDFS). Further developments have been based on RDFS: OIL 16, DAML+OIL 17, and finally OWL 18. The development and evolution of OWL began in 2001 and is strongly related to the idea of the Semantic Web. The most recent version is OWL 2 of October, Knowledge Interchange Format 10 Operational Conceptual Modelling Language 11 Simple HTML Ontology Extensions 12 Hyper Text Markup Language 13 Extensible Markup Language 14 XML-based Ontology Exchange Language 15 Resource Description Framework 16 Ontology Inference Layer 17 language combining features of DARPA Agent Markup Language (DAML) and OIL 18 Web Ontology Language OEPI_D_1_3_Final.doc Dissemination Level: Public Page 50

59 The following subchapters present basic information about the most important languages mentioned in the short overview above KIF Knowledge Interchange Format (KIF) from Stanford University (Genesereth and Fikes, 1992) is mentioned here as the most important representative of the earlier ontology languages. It is based on first order logic and was intended mainly to serve as an interchange format for different knowledge representation systems RDF, RDF Schema The Resource Description Framework (RDF) is a general-purpose language for representing information in the Web. It was developed by the World Wide Web Consortium (W3C) (Beckett, 2004). RDF Schema (Brickley and Guha, 2004) extends RDF with frame-based primitives, which allow to describe specific vocabularies for different domains of resources. The combination of both RDF and RDF Schema is known as RDFS. RDFS allows the representation of concepts, concept taxonomies and binary relations DAML+OIL The language DAML+OIL is the result of the combination of two approaches that were both based on RDFS: Origin of Ontology Inference Layer (OIL) was the European IST project On-To-Knowledge, whereas DAML (DARPA Agent Markup Language) was developed in the DARPA 19 initiative with the same name. In 2000, DAML was upgraded by a joint committee from the US and the EU to include OIL. The resulting language was called DAML+OIL (van Harmelen, Patel-Schneider and Horrocks, 2001). It adds frame-based knowledge representation primitives to RDFS and its formal semantics are based on descriptive logics. The language allows representing concepts, taxonomies, binary relations, functions and instances. DAML+OIL can be considered as being obsolete today because it was taken up as the foundation for the development of OWL OWL Since 2001, a working group Web-Ontology (WebOnt) of W3C worked on a new ontology markup language for the Semantic Web: Web Ontology Language (OWL 20 ). The main input for OWL was the language DAML+OIL which was based on RDFS. OWL 1 became available as a W3C Recommendation in 2004 (McGuinness and van Harmelen, 2004). Main characteristics of OWL are: built on top of RDFS, written in XML intended for processing information on the Web 19 Defense Advanced Research Projects Agency 20 This is no typo. OWL is not meant as an acronym for Web Ontology Language. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 51

60 designed to be interpreted by computers not for being read by people Web standard (W3C Recommendation) more facilities for expressing meaning and semantics than XML and RDF alone OWL defines three increasingly expressive sublanguages: OWL Lite: for users needing a classification hierarchy and simple constraints. For example, while it supports cardinality constraints, it only permits cardinality values of 0 or 1. OWL DL: for users who want the maximum expressiveness while retaining computational completeness (all conclusions are guaranteed to be computable) and decidability (all computations will finish in finite time) OWL Full: for users who want maximum expressiveness and the syntactic freedom of RDF with no computational guarantees In 2009, OWL 2, which is backwards compatible to OWL 1, was finished as a W3C Recommendation (W3C OWL Working Group, 2009). OWL 2 ontologies provide classes, properties, individuals, and data values and are stored as Semantic Web documents. OWL 2 ontologies can be used along with information written in RDF, and OWL 2 ontologies themselves are primarily exchanged as RDF documents Conclusion OWL seems to be the appropriate ontology language to be used within the OEPI project for the following reasons: OWL is the recommended standard for Web ontology representation, and the OEPI project is strongly web-oriented. Tool support is available for OWL. Due to popularity of OWL, opportunities of reuse of existing ontologies within OEPI as well as reuse of the OEPI Ontology in other projects are given. A decision between OWL 1 and OWL 2 has been made on the OEPI Consortium Meeting in Madrid in September, It was decided to refer to OWL 2, mainly because it is more expressive than OWL 1, but also because it is the most current version. At the same time, the OEPI project is still able to make use of ontologies represented in OWL 1, if this is desired, because OWL 2 is backwards compatible. New features of OWL 2 with respect to OWL 1 are, for example: keys property chains richer data types, data ranges qualified cardinality restrictions asymmetric, reflexive, and disjoint properties enhanced annotation capabilities The Chapter Relationship to OWL 1 in the OWL 2 Document Overview (W3C OWL Working Group, 2009) provides further advice on this question. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 52

61 5.2 Tools Supporting Ontology Development The development of ontology is a complex task comparable to the development of a software system. Therefore, this task requires a systematic approach that should be supported by adequate tools. The development process to be followed in the OEPI project has already been considered in chapter 2. This chapter deals with tools that can be used during the construction of the ontology. The main sources that have been searched for tools that might be suitable for ontology building were the articles as well as the websites that are listed in Table 20 below. At first glance, it seems that there are a big number of tools available. It is thus important to define criteria that can be used to identify a smaller subset of tools that might be suitable. Furthermore, it is necessary to weight those criteria with regard to their relevance for the OEPI project. The results of this task are summarized in chapter and have been taken into account further on in the process. While looking closer into the tool references, it became evident that the current availability and state of development of the tools are the most critical issues beside the selection of the ontology description language. Based on the assumption that OWL will be the ontology language of choice for the OEPI project, an overview of the remaining tools that might be suitable for use in the OEPI project is given in chapter The final assessment is presented in chapter and a concluding recommendation is given in chapter Table 20: Tool Resources Name, Type of Source W3C Semantic Web Development Tools, website listing current Semantic Web tools (2010) Ontology Development Tools for Ontology-Based Knowledge Management, article Ontology Tools Survey, article Ontology editor survey results, comparison table with categorical descriptions of 94 ontology editors (2004) Reference (Youn and McLeod, 2006) (Denny, 2004) Ontology_Editor_Survey_2004_Table_- _Michael_Denny.pdf Methodologies, tools and languages for building ontologies: where is their meeting point?, article WonderTools? A comparative study of ontological engineering tools, article Index of WonderTools, website with decision support for selection of ontology building tools (2000) (Corcho et al., 2003) (Duineveld, Stoter, Weiden, Kenepa and Benjamins, 2000) OEPI_D_1_3_Final.doc Dissemination Level: Public Page 53

62 5.2.1 Tool Assessment Criteria The tool assessment criteria that were provided in the resources listed in Table 20 were consolidated to one common list of criteria. There are two main groups of criteria: those related to the actual topic of ontology building and those related to more general characteristics of a tool. This list was evaluated regarding the relevance of the criteria for the OEPI project. The results are summarized in Table 21. Further criteria, which are important for the OEPI project but have not been covered by the mentioned sources, have been added at the end of the table. Table 21: Tool Assessment Criteria / Relevance for OEPI Criteria Comments Relevance for OEPI Ontology related criteria 1. Expressiveness of the tool knowledge model; modelling features, limitations Representational and logical qualities that can be expressed in the built ontology at least partially implied by preference for OWL; degree of support for OWL features? 2. Base language Native or primary language used to encode the ontology 3. Web support Support for Web compliant ontologies (e.g., URIs 21 ) 4. Import/export formats Languages in which ontology data can be read in, and/or the built ontology can be written out should match expressiveness of OWL, not as important as the import/export formats implied by OWL preference minimum: RDF/XML (exchange syntax for OWL), OWL 5. Inference services / consistency checks for example: constraint and consistency checking mechanisms, type of inheritance, automatic classifications, exception handling and execution of procedures; automatic verification of syntactic, referential and/or logical correctness of the ontology basic checking mechanisms should be supported 6. Merging Support for easily comparing and merging independent built ontologies (partial) reuse of existing ontologies might be required; this could also be achieved by import mechanism 21 Uniform Resource Identifier OEPI_D_1_3_Final.doc Dissemination Level: Public Page 54

63 Criteria Comments Relevance for OEPI 7. Lexical support Capabilities for lexical referencing of ontology elements (e.g., synonyms) and processing lexical content (e.g., searching/filtering ontology terms) 8. Information extraction Capabilities for ontology-directed capture of target information from content and possibly subsequent elaboration of the ontology 9. Methodology support Is there a specific development methodology assumed or supported? might be interesting but relevant only if other critera are not sufficient might be interesting but relevant only if other criteria are not sufficient must not prescribe strict methodology; adaptable to OEPI needs? Tool architecture / implementation related 10. Software architecture / installation / use of tool Use of the software over the Web (e.g., browser client) or local installation... web application would be nice though local storage of data would be preferred due to IP issues 11. Usability Easy to learn and to use? important for OEPI because resource are limited 12. Graphic view Extent to which the built ontology can be created, debugged, edited and/or compared directly in graphic form should be provided 13. Multi-user support / Collaboration Features that allow and facilitate concurrent development of the built ontology at least basic support should be provided Additional criteria relevant for OEPI 14. Current state of tool development Terminated or still ongoing? Community or support available? development should be ongoing, active user community would be helpful 15. Availability / License model How / where to get SW? Conditions of use acceptable? preferably web download / free of charge / open source OEPI_D_1_3_Final.doc Dissemination Level: Public Page 55

64 5.2.2 Preselection of Tools for Ontology Building Table 22 provides an overview of possibly suitable tools that were found in the mentioned resources (see Table 20). A preselection was performed to restrict the tool list to those tools that seem to be OWL compatible (see chapter 5.1 for the discussion of ontology languages) and that appear to be currently available for use. The list is ordered alphabetically by name of tool. Table 22: Preselection of Tools for Ontology Building Name (Source) of tool COE / CmapTools (Florida Institute for Human & Machine Cognition) Model Futures OWL Editor (Model Futures Limited) NeOn Toolkit (NeOn Integrated Project EU-IST ) OntoStudio (ontoprise GmbH) Description and reference for further information Cmap COE is a project whose goal is to develop an integrated suite of software tools for constructing, sharing and viewing OWL encoded ontologies based on CmapTools, a concept mapping software used in educational settings, training, and knowledge capturing. Concept maps provide a human-centered interface to display the structure, content, and scope of an ontology. more information: Model Futures offers a free OWL Editor Tool. The editor is tree-based and has a navigator tool for traversing property and class-instance relationships. It can import XMI (the interchange format for UML) and Thesaurus Descriptor (BT-NT XML), and EXPRESS XML files. It can export to MS Word. more information: The NeOn Toolkit is the ontology development environment developed by the NeOn Project. It focuses on providing support for the complete life cycle of networked ontologies. The NeOn Toolkit is built on the code-base of OntoStudio, the commercial ontology engineering environment of ontoprise. The NeOn Toolkit is driven by the NeOn partners who provide lots of plug-ins with unique functionalities. more information: OntoStudio is a widespread commercial modelling environment for the creation and maintenance of ontologies. It combines modelling tools for ontologies and rules with components for the integration of heterogeneous data sources. As ontology languages OntoStudio supports W3C-standards OWL, RDF, and RDFS, and F-Logic for the logic-based processing of rules. OntoStudio provides many connectors to databases, documents, filesystems, applications and web-services. more information: OEPI_D_1_3_Final.doc Dissemination Level: Public Page 56

65 Name (Source) of tool OntoTrack (University of Ulm Dept. for Artificial Intelligence, Germany) Protégé (Stanford Center for Biomedical Informatics Research) Collaborative Protégé (Stanford Center for Biomedical Informatics Research) SWOOP (University of Maryland) SemanticWorks (Altova) TopBraid Composer (Free Edition) (TopQuadrant, Inc.) Description and reference for further information OntoTrack is designed to be an authoring tool for ontology languages with an expressivity comparable to (the most rational fraction of) OWL Lite. more information: Protégé is a free, open source ontology editor and knowledge-base framework. The Protégé platform supports two main ways of modelling ontologies via the Protégé-Frames and Protégé-OWL editors. Protégé ontologies can be exported into a variety of formats including RDF, RDFS, OWL, and XML Schema. Protégé is based on Java, is extensible, and provides a plug-and-play environment that makes it a flexible base for rapid prototyping and application development. Examples are a visual editor for OWL (called OWLViz), storage back-ends to Jena and Sesame, as well as an OWL-S 22 plugin, which provides some specialized capabilities for editing OWL-S descriptions of Web services. more information: Collaborative Protégé is an extension of the existing Protégé system that supports collaborative ontology editing as well as annotation of both ontology components and ontology changes. more information: SWOOP is a tool for creating, editing, and debugging OWL ontologies. It was produced by the MIND lab at University of Maryland, College Park, but is now an open source project. more information: commercial visual RDF and OWL editor for the Semantic Web more information: TopBraid Composer is a professional (commercial) development environment for W3C's Semantic Web standards RDF Schema, the OWL Web Ontology Language and the SPARQL 23 Query Language. The Free Edition is an entry-level tool for creating and editing RDF/OWL files and running SPARQL queries over them. more information: 22 Web Ontology Language for Web Services 23 Simple Protocol and RDF Query Language OEPI_D_1_3_Final.doc Dissemination Level: Public Page 57

66 5.2.3 Assessment of Ontology Editing Tools The preselected tools that are listed in Table 22 were input for this assessment. Due to additional effort regarding time and money that would be associated with the selection of a commercial tool, the use of commercial tools was not considered any further. All non commercial tools were checked for their availability at the current time and for their state of development. Tools that seemed to be up-to-date and available for download were further assessed. The results of this process are summarized in Table 23. Table 23: Ontology Editing Tools Assessment Summary Name of tool OntoTrack COE / CmapTools Model Futures OWL Editor NeOn Toolkit Recommend ation 24 Assessment results outdated (latest release apparently around 2004!) no further evaluation performed complete download not possible due to possible server problems (state of September, 2010) no further evaluation performed no OWL import or export beta version, no warranty, support, or community only executable (no open source), no documentation no further evaluation performed comprehensive toolkit that includes ontology editor (based on Eclipse) suitable OWL Editor tool with functionality similar to Protégé; supports OWL 2 user documentation is available reasoner is somewhat difficult to comprehend latest versions: of May, 2010 (no plugins yet); of February, 2010 (all plugins) NTK Beta is based on the OWL API 3.0 license (basic configuration): Eclipse Public License (EPL) ( download: user documentation: 24 Legend: : recommended : possibly suitable : not recommended OEPI_D_1_3_Final.doc Dissemination Level: Public Page 58

67 Name of tool OntoStudio Protégé Collaborative Protégé SWOOP SemanticWorks Recommend ation 24 Assessment results commercial tool no further evaluation performed up-to-date, still under development free, open source well-known, broad use user community license: Mozilla Public License ( download: user documentation: would be helpful resp. required as an extension of the Protégé system if concurrent editing of the same ontology is necessary compatible with Protégé 3.x only (so far) more information / download etc: no further evaluation performed latest version: swoop-2.3beta4, August 2007, development possibly discontinued does not support OWL 2 no separate user documentation found, see (Kalyanpur, 2004) license: MIT 25 License ( download: no further evaluation performed commercial tool no further evaluation performed 25 Massachusetts Institute of Technology OEPI_D_1_3_Final.doc Dissemination Level: Public Page 59

68 Name of tool TopBraid Composer (Free Edition) Recommend ation 24 Assessment results The Free Edition is rather limited in its features in comparison with the commercial editions, for example no graphical editor, no import/export etc. Other editions: commercial tool no further evaluation performed Tool Recommendation for OEPI Ontology Development Research and assessment of tools for ontology development in the OEPI project have been presented in the above subchapters. The conclusion is that two possible tools can be recommended as OWL editors for OEPI: the OWL Editor of the NeOn Toolkit and Protégé. The tools might even be interoperable to some extent as the ontologies might be exchanged between them probably. With regard to training effort and cooperation in the project team, it would probably be preferable to make a clear decision for one of the tools that should be used by all partners involved in ontology development. There seems to be some advantage for Protégé because it has a broader user community and is developed independent of a related research project (in contrast to the NeOn Toolkit). Nevertheless, it might be interesting to have a closer look at other features of the NeOn Toolkit which could be used even on an ontology that has not been edited by the NeOn OWL Editor. As there are different versions of Protégé, the guideline Choosing between versions of Protégé 26 provides information for supporting the selection of the appropriate version for application in OEPI. It looks like Protégé 4.x is the better choice for OEPI than Protégé 3.x due to the following characteristics: lightweight, pure OWL framework support of OWL 2 use of open source, Java-based OWL API direct connection to FaCT++, Pellet and other DL 27 reasoners for optimum speed of classification imports resolution from a common folder, user repositories or the web plugins based on OSGi 28 There are also some drawbacks of Protégé 4.x which might be resolved by upcoming versions: Descriptive Logics 28 OSGi Alliance, Open Services Gateway initiative OEPI_D_1_3_Final.doc Dissemination Level: Public Page 60

69 no multi-user support yet (Collaborative Protégé is not compatible with Protégé 4.x yet) A cross-check of this matter with regard to the actual work plan indicated no major problem as only few core people had to actually edit ontology files. The problem was mimized by using a revision control system for ontology files. no database storage yet Storing the ontology in ordinary files should be sufficient if supported by a revision control system. It is intended to use an Apache Subversion (SVN) repository during development in the OEPI project anyway. 5.3 Programming Interfaces for Building Software Based on Ontologies This chapter deals with interfaces (APIs) to access and manipulate.owl files or OWL ontologies. In total, five APIs will be compared, three for Java and two for C# but with strong focus on the Java APIs and especially on OWL API. Each API s description begins with one or two sentences copied from their corresponding websites, followed by further information and some evaluation Programming Language Java Table 24 compares the three Java OWL APIs which were tested. The table shows the most important evaluation criteria, such as level of documentation, OWL support and the size of the libraries. The concrete functionality, for example the supported methods to load an ontology or ways of manipulating them, is not further described here. This is because all three Java APIs do not differ significantly with regard to functionality, except for the support of OWL 2 functionality which is only provided by OWL API. Table 24: Comparison of Java APIs for OWL Criteria OWL API Protégé OWL API Jena 2 Documentation complete API complete API complete API very good tutorial reasonable tutorial reasonable tutorial (can be used as (only for RDF(S)) construction kit) OWL Version Functionality support for OWL-DL OWL-Full support support for OWL-DL Specific features plug-ins are based on partly based on Jena, mainly for RDF(S) OSGI, successor of predecessor of OWL-API Protégé-API, with a little less functionality OEPI_D_1_3_Final.doc Dissemination Level: Public Page 61

70 Criteria OWL API Protégé OWL API Jena 2 Refresh period / support up-to-date (last update ) / mailing list, issue tracker Last update Last update / mailing list URL for further information net/ d.edu/wiki/protegeowl_ net/ API_Programmers_Guid e Size one jar file (1,8 MB) comes with Protégé only (installer is 98,6 MB), jar files 83,4 MB 14 jar files (11,1 MB) Protégé OWL API The Protégé-OWL API is an open source Java library for the Web Ontology Language (OWL) and RDF(S). The API provides classes and methods to load and save OWL files, to query and manipulate OWL data models, and to perform reasoning based on Description Logic engines. This is the predecessor of OWL API and only supports OWL 1. The only known way of getting the API is to download Protégé 3.4.4, which contains the java libraries. It has a lot of similarities with OWL API but as it is outdated it should be of no further interest. Website: Jena Jena is a Java framework for building Semantic Web applications. It provides a programmatic environment for RDF, RDFS and OWL. It also provides a full Javadoc specification and some example code files. Jena only supports OWL 1 and consists of 14 jar-files. It should be easy to use but has no noticeable advantages compared to OWL API. Website: OWL API The OWL API is a Java API and reference implementation for creating, manipulating and serialising OWL Ontologies. It supports OWL 2 and is very easy to use. For this API a full Javadoc specification and a great number of tutorials and sample code files exist. Furthermore it is open source (under LGPL license) and it simply consists of one jar-file. (The download does contain two jar-files but one of them is the source code and is not needed for implementation) For nearly every use case for interaction with ontologies there is an example code file. Furthermore it is commented very well and every project which uses this API solely has to import one small jar-file. It is the only tested library that supports OWL 2 and can be easily integrated into any java project. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 62

71 The following tutorials are for example available online (excerpt from Loading Ontologies Saving Ontologies Adding axioms Deleting entities Restrictions Reasoning Annotations Merging Ontologies Every code example is commented. Additionally these tutorials can be used as a construction kit for nearly every desired OWL function. Website: Programming Language C# All information about the following APIs was gathered from the corresponding websites. ROWLEX ROWLEX stands for Relaxed OWL EXperience. But compared to the Java APIs it is rather far away from this claim. To work with.owl files you have to manually transform the ontology with a provided tool which creates some other files that are needed. Then you have to import them into your.net project and can finally access the ontology. Additionally the documentation consists of only four tutorials about serializing business objects into rdf-documents, building rdf-documents, browsing them and how to use ROWLEX in a web service scenario. All in all: a poor documentation and an unnecessary complex way of working with ontologies. Website: Linq to RDF LinqToRdf is a Semantic Web framework for.net. It provides an easy way to integrate Semantic Web queries into your software. But it is not an API to work on ontologies directly. It rather translates queries to SPARQL queries which can operate on.owl files. It even restricts to the use of Visual Studio 2008 and.net 3.5. LinqToRdf comes in two parts. First there is an installer which delivers the core functionality for the OWL queries and secondly a designer which integrates into Visual Studio It seems as if this framework would be the best choice for C#. Websites: OEPI_D_1_3_Final.doc Dissemination Level: Public Page 63

72 5.3.3 Conclusion There were five APIs considered. The three interfaces supporting Java as the programming language and OWL as ODL seem to satisfy the needs of the OEPI Project. One of them, OWL API, supports OWL 2 which has been selected as the preferred ODL for OEPI. This API for the Java programming language is easy to use, well documented resp. commented and uses memory efficiently. In case of programming language C#, LinqToRdf is the leading project but it does restrict the programming environment. 5.4 A Sample Ontology and Application ( Prototype ) As a first test case for the ontology development and application programming, a small example has been implemented. Protégé (version 4.0.2) has been used to describe an OEPI Ontology based on a preliminary set of ontology requirements. Then as a website with environmental information the site "carma.org" was selected. This site delivers energy and carbon output information, as well as the location of power plants world wide. The aim was now to create a simple Java application that allows querying information of "carma.org" in terms of the (prototype) ontology defined in OEPI. This has been implemented successfully using "OWL API" that has been described in the subchapter above. Experience gathered with this example is available for the further development of the actual OEPI Ontology and for development of the OEPI platform in work package WP 2. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 64

73 6 Design and Application of Ontology This chapter presents the results of designing a formalized description language for EPIs. The main result is the first version of OEPI Ontology accompanied by guidance regarding its use and further evolution. It is based on previous work of WP 1 as documented in deliverable D1.1 State-of-the art for EPIs and in internal deliverable D1.2 Reference Ontology for EPIs Requirements (represented by chapters 1 to 6 of this document D1.3) and on project-internal descriptions of OEPI use cases. There are three subchapters: The first one, chapter 6.1, describes design decisions and main concepts of the chosen description language OWL 2 and the OEPI Ontology which together form the description language for EPI. The second one, chapter 6.2, provides basic, general guidance and a simple example for usage of OEPI Ontology as well as the specification of a case study illustrating how to draw advantage of OEPI Ontology within use case Design for Environment. The third subchapter, chapter 6.3, outlines the ontology development roadmap within the OEPI project and possible development directions. 6.1 Design Decisions and Main Concepts Description Language and Representation The objective of the description language for EPIs is to provide means and concepts to describe environmental performance indicators with all their relevant aspects in a common, formal, machinereadable way and thus to enable the proper access, interpretation, and use of quantitative EPI data originating from different data sources by ontology-aware applications. The standardized description language that was selected for this purpose is Web Ontology Language OWL 2 29 of World Wide Web Consortium. (The selection process for the language is documented in detail in chapter 5.1.) As OWL 2 is a general purpose ontology description language, the specific domain knowledge regarding EPIs has to be provided additionally. This is done by means of OEPI Ontology. This ontology is defined in terms of OWL 2 and is represented in.owl format as created by the ontology editor Protégé 4. (Details about the selection process for this tool can be found in chapter 5.2.) Besides Protégé, the web-based ontology-browser 30 of the University of Manchester has been used by project members who were not involved in ontology building to review ontology. The current version of OEPI Ontology can be accessed through this browser instance 31, too. (No software installation is required on the user s site.) 29 see reference (W3C OWL Working Group, 2009) 30 see OEPI_D_1_3_Final.doc Dissemination Level: Public Page 65

74 Subsequent sections introduce the main features of OWL 2 that were used to define OEPI Ontology, the design principles and central concepts of OEPI Ontology, and concrete considerations about reuse of ontologies in OEPI Ontology. It should be noted that the current OEPI Ontology, which is delivered in.owl format in combination with this document, is not to be understood as complete or final but as the first, highly extendible version in an evolutionary approach towards a common, general OEPI Ontology (see also section 6.3 about an ontology development roadmap) OWL Concepts as a Foundation for OEPI Ontology Development Chapter 1.2 in the introductory part of this document outlined the fundamental concepts and basic elements of ontologies in general regardless of the specific means used to describe and represent a specific ontology. This section introduces the essential concepts of description language OWL 2 that were used to define OEPI Ontology. The description, which is based mainly on a tutorial (Horridge, 2009), shall facilitate the understanding of OEPI Ontology rather than give a comprehensive overview of the features of the language OWL 2. Classes and individuals The most basic means of describing an ontology in OWL 2 is to create a class hierarchy, which is also called a taxonomy. A class in OWL 2 is a concrete representation of a concept. It describes formally the conditions for being a member of the class. Concrete members of a class are called individuals. They might also be called instances of a class. An ontology does not need to include any individuals. A class hierarchy is built by specification of super- and subclasses of classes. In terms of OWL 2 a subclass is a specialization of its superclass(es). This implies necessarily that all members of the subclass are also members of all superclasses of that class. The necessary conditions for being a member of a particular class can be described by specification of named superclasses of that class. An additional way is by specification of anonymous classes, which are also called restrictions in OWL 2. An anonymous class describes a class based on the relationships that members of the class participate in. The class contains all individuals that satisfy such a restriction. These relationships are modelled by so-called properties in OWL 2. Properties Two main kinds of properties are distinguished in OWL 2: object properties and datatype properties. An object property represents a binary relationship between two individuals (members of classes). A datatype property represents a binary relationship between an individual and a data value of some datatype. Furthermore, there are annotation properties known in OWL 2 that can be used to annotate ontology elements with metadata. Annotation property comment has been used in OEPI Ontology to provide OEPI_D_1_3_Final.doc Dissemination Level: Public Page 66

75 textual descriptions for all classes and properties. These descriptions can be extracted to generate a concept glossary that always reflects the actual state of the ontology. Besides the mere existence or absence of some relationship described by a property, a number of characteristics can be used to enrich semantic information of a property and thus support automatic reasoning. Table 25 provides an overview of characteristics that are supported for properties in OWL 2. Table 25: Overview of OWL 2 Characteristics of Properties Characteristic Description Applicable for Example 32 functional A functional property is limited to object property, hasbiologicalmother relates have a single value. datatype someone to his or her single property biological mother. inverse Indicates that the inverse property object property isbiologicalmotherof relates a functional of the property is functional. mother to her biological children (not functional) but the inverse property hasbiologicalmother is functional. reflexive A property is reflexive when the object property knowsbirthdayof may relate property must relate an individual an individual to individuals to itself (among possible other whose birthdays he or she individuals). knows. As an individual is supposed to know his or her own birthday, the property is reflexive. irreflexive A property is irreflexive when the object property isbiologicalmotherof is property must not relate an irreflexive because someone individual to the same individual. cannot be his or her own biological mother. symmetric If a property is symmetric, the object property hassibling is symmetric property can be applied to two because if individual A has B as individuals in both directions. a sibling, B has A as a sibling, too. 32 The examples are taken from daily life rather than from the domain of environmental performance indicators as they can be understood intuitively without deeper knowledge of the matter. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 67

76 Characteristic Description Applicable for Example 32 antisymmetric If a property is antisymmetric, the object property ischildof is antisymmetric property can be applied to two because if individual A is a child individuals only in one direction of B, B cannot be a child of A. and not in the reverse direction. transitive If a property is transitive, the object property hasancestor may relate an existence of such a relationship individual to one of his or her between individuals A and B and ancestors regardless of the the existence of such a number of generations between relationship between B and C them. This property is transitive. imply that the same kind of relationship exists between A and C. inverse If a property describes one object property hasbiologicalmother and direction of a relationship between isbiologicalmotherof are two individuals, the inverse inverse properties. property describes the reverse direction of the relationship between the same individuals. Properties can be used to describe restrictions for the membership of classes. Table 26 provides an overview of the restriction types that are supported by OWL 2. Table 26: Overview of OWL 2 Property Restriction Types Restriction types Description Example 33 quantifier, existential (some) A member of the class that is described by the restriction has at least one relationship of the given property to a member of the class specified in the restriction. hasancestor some Person To fulfil this restriction, an individual has to have at least one relationship of property hasancestor to a member of class Person. 33 The examples are taken from daily life rather than from the domain of environmental performance indicators as they can be understood intuitively without deeper knowledge of the matter. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 68

77 Restriction types Description Example 33 quantifier, universal (only) cardinality, min cardinality, exactly cardinality, max has value If a member of the class that is described by the restriction has any relationships of the given property, then these are relationships to members of the class specified in the restriction only. A member of the class that is described by the restriction has a relationship of the given property to at least the given number of individuals (or values). A member of the class that is described by the restriction has a relationship of the given property to exactly the given number of individuals (or values). A member of the class that is described by the restriction has a relationship of the given property to at most the given number of individuals (or values). If a member of the class that is described by the restriction has a relationship of the given property, then it is related to an individual or a value that is specified in the restriction. hassister only Woman To fulfil this restriction, an individual has to have only relationships of property hassister that relate it to a member of class Woman (or no such relationship at all). hasemployer min 1 To fulfil this restriction, an individual has to have at least one relationship of property hasemployer. hasbiologicalmother exactly 1 Woman To fulfil this restriction, an individual has to have exactly one relationship of property hasbiologicalmother to a member of class Woman. hasparticipant max 15 To fulfil this restriction, an individual has to have at most 15 relationships of property hasparticipant. isofvintage value 2005 To fulfil this restriction, an individual has to have a relationship of property isofvintage to the value Restrictions may be combined to build more complex conditions by using set operators and (intersection), or (union), or not (negation). For example: Restriction hasparticipant min 8 and hasparticipant max 15 can be used to specify that a member of class Training Course must have at least eight but not more than 15 participants. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 69

78 6.1.3 Main Concepts of OEPI Ontology Design Principles and Overview This section summarises design principles that have been applied during the development of OEPI Ontology and provides an overview of the main ontology concepts. These concepts will be described in more detail in two subsequent sections, and Design principles The overall objective of the OEPI Ontology is to provide common, general concepts to describe the wide range of environmental performance indicators (EPI) with all their relevant aspects and to support the proper access, interpretation and use of quantitative data related to these EPIs. The basic design principles for ontologies have been introduced in chapter 1.2 already. They are clarity, coherence, extendibility, minimal encoding bias, and minimal ontological commitment. These principles have been observed while deriving OEPI Ontology from the ontology requirements that are stated in chapter 3 and annex A of this document. The process that was applied for OEPI Ontology development has been described in chapter Within this process, the strategy was to concentrate on the most fundamental concepts in the beginning and to employ more sophisticated concepts for stepwise refinement of the class hierarchy and the class definitions gradually. This strategy corresponds to a top-down approach of capturing the domain knowledge for OEPI. As it is impossible to fulfil all requirements of all present and future EPIs including their origins, possible assessments, and circumstances of usage at once in one effort, an incremental, evolutionary approach was taken that implied a high priority for the design principle of extendibility. Thus the delivered first version of OEPI Ontology is highly extensible by means of: refinement of existing classes by further or more complex restrictions, addition of further subclasses to the class hierarchy to represent a higher degree of specialization, refinement of concepts by reuse of more refined concepts from existing other ontologies (refer to section for further consideration of this matter), provision of predefined individuals (instances of classes) to describe well known, commonly available EPI definitions and data sources. A rough outline of a development roadmap for this evolutionary approach is provided in chapter 6.3. The ontology review during and at the end of the iterative design phase was performed by walk-through using an ontology browser, by a small application ( automatic glossary ), and by a case study based on a concrete OEPI use case (refer to sections and for more information). OEPI_D_1_3_Final.doc Dissemination Level: Public Page 70

79 Overview of main ontology concepts OEPI Ontology currently represents two main clusters of concepts: Concepts related to environmental performance indicators (EPI) and concepts related to data sources of environmental performance data. The first cluster defines the concepts of EPI Definition and EPI Statement, the second one defines the concept of EPI Data Source. EPI Definition: specifies the definition of one specific performance indicator including its meaning and the rules for its assessment. EPI Statement: provides one concrete quantitative statement about a specific observed entity according to the definition of the corresponding performance indicator. The statement includes information that qualifies how the definition has been applied and fulfilled to support the appropriate interpretation and use of the quantitative data. This concept cluster is introduced in more detail in subsection EPI Data Source: describes a specific source of EPI statements to support access and appropriate use of the data. Details about this concept cluster can be found in subsection Environmental Performance Indicators Before describing the concepts related to environmental performance indicators as they are formalized in the first version of OEPI Ontology, the following paragraphs summarize the underlying perception of environmental performance indicators. This perception has been derived from the assessment of the stateof-the-art in D1.1 (Jamous and Müller, 2010) and from the requirements analysis for the description language for EPIs as documented in chapter 3 and annex A. A performance indicator (PI) defines a specific kind of quantitative statement about the performance of an entity under observation. Such a quantitative statement is expressed by a numeric value with a corresponding unit of measurement. The value is either measured or computed or otherwise obtained according to defined rules. The range and scope of possible entities the PI may relate to and the information required for their adequate description is determined in the definition of the PI. A PI has an associated meaning within its domain of application which is described within the terminology of this domain. Main purposes of performance indicators are: to record the current performance of some entity, to record the change of performance of an entity between different points in time, to compare the performance of different entities, to utilise the performance of entities in decisions, and to assess the achievement of quantitative goals in transformation or improvement processes. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 71

80 An environmental performance indicator is a performance indicator within a domain of discourse that is the environment on earth. It defines a specific kind of quantitative statement about the environmental performance of an entity. Table 27 provides textual descriptions of the concepts that have been introduced as classes in OEPI Ontology to represent environmental performance indicators. Table 27: OEPI Ontology Concepts related to Environmental Performance Indicators Concept (class) Description Core concepts: PI Definition, EPI Definition It specifies the definition of one specific performance indicator including its meaning and the rules for its assessment. (It is a specialization of a general PI definition.) It covers: the normative reference for the definition or a special purpose reference like a company-specific guideline, a formalized representation of the meaning of the PI by means of a concept called performance descriptor. the range of possible observable entities to which the definition can be applied, the rules or methods of obtaining and expressing values for the PI by means of a concept called PI definition element, related stakeholder interest references. PI Statement, EPI Statement It provides one concrete quantitative statement about a specific observed entity according to the definition of the performance indicator. The statement includes information that qualifies how the definition has been applied and fulfilled to support the appropriate interpretation and use of the quantitative data. (It is a specialization of a general PI statement.) Such a statement consists of: a reference to the EPI definition it complies with a reference to the observable entity that has been assessed the numeric data item representing the quantitative value of the statement a temporal reference corresponding to the time when the quantitative value has been obtained resp. the time period which has been observed fulfillment of further variable parameters of the definition by means of a concept called PI statement qualifier, for example: o information about how value has been obtained (collection method etc.) OEPI_D_1_3_Final.doc Dissemination Level: Public Page 72

81 Concept (class) Description o o information about the quality of the value verification of the compliance of the statement with the definition Supporting concepts (in alphabetical order): Authority Bibliographical Information Conversion Factor Data Item Document The concept Authority describes different bodies that have some legal or standardizing authority, particularly: Standardization authority: is an authority that issues normative references. It is not necessarily a standardization organization in the strict sense like ISO but could also be some GO, NGO, initiative etc. Registration authority: is an authority which is legitimized to register other authorities for a purpose that is defined in a corresponding normative reference. Verification authority: is an authority which is registered by some registration authority (or authorities) according to some normative reference to fulfill some purpose of verification. Example: An environmental verifier who verifies the quality or compliance of EPI statements in sustainability reports is a verificaton authority. An authority should be established based on some normative reference. This concept desribes bibliographical information that is associated with a document. In the current class description, bibliographical information is represented by datatype property "has Simple Bibliographical Information" (see Table 28 for a list or properties). It should be replaced by a more sophisticated concept probably from another existing ontology. Conversion factor is a specialization of a data item. It is a concept to specify some value conversion or weighting. It consists of a some information about a defining reference and a numeric value. Data item is a general concept for all kinds of more or less complex items containing some kind of data that is to be considered to be part of quantitative statements. Specialised data items are: conversion factor, numeric data item, and temporal data item. A "document" is a general concept for all kinds of collections of information provided for perception by human beings. A document has bibiliographical information describing the document. The purpose of the document shall be used implicitly to distinguish different kinds of documents. Specialised documents are reference document and report. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 73

82 Concept (class) Normative Reference Numeric Data Item Observable Entity Description A normative reference is a document (like a standard, a law, a protocol, etc.) issued by an authority (like a standardization organization, a GO, a NGO, an initiative etc.) providing the normative definition of some issue (like the computation rules for a PI, the defining boundaries of an entity, application rules for specific conversion factors, etc.) within an application scope which is defined in the reference document, too. A numeric data item is a data item that consists of a numeric value and a corresponding unit of measurement. Different representations of numeric data items are possible which might require fulfillment of additional requirements which are specified in the respective subclasses, particularly: Absolute data item: is a numeric data item that can be used as it is. No further information is required for its correct interpretation. Indexed data item: is a percentage expressed as a multiple resp. fraction (100 % = 1) related to one other compatible numeric data item. The following information has to be provided additionally: reference to the related numeric data item. Relative data item: is a numerical data item that is a ratio obtained by dividing an absolute value by a related quantity. The following requirements have to be fulfilled: o the related quantity has to be identified uniquely, o the unit of measurement of the numerical data item has to be compliant with the used related quantity. "Observable entity" is a concept to describe an entity that can be observed to assess its performance with regard to some aspect according to the definition of a performance indicator. An observable entity shall have an "owner". Specializations of a general observable entity are: Geographical entity, examples: o "the World" or "the Earth" o a continent of the earth o a country in geographical sense o a region described by some geographical information Operational entity, example: o a production site or facility Organizational entity, examples: o an industry sector o a company OEPI_D_1_3_Final.doc Dissemination Level: Public Page 74

83 Concept (class) Description o o a governmental organization a non-governmental organization Political Entity, examples: o a country or state in a political sense like "Federal Republic of Germany", "United States of America" o a politically defined part of a state like "North Rhine- Westphalia" or "Ohio" o an institutional federation of countries like the "European Community" Product Entity is is a concept to describe products on different abstraction levels. Examples: o a general kind of a product like "a car" o a more specific kind of general product like "compact car" or "SUV" o a brand or make of a product like "a car built by Volkswagen" o a product line that might be described more or less specific like "a VW Golf" or "a VW Golf Type xyz produced in 2005" o a specific individual instance of a product like "the VW Golf type... with the chassis number " Technical Entity is a concept to describe observable entities according to technical considerations, particularly: a production process (different abstraction levels are possible like a "generic" process described in some scientific publication vs. a concrete production process implemented in an existing production facility) a product life cycle or product life cycle phase Performance Descriptor A performance descriptor is a concept used to describe the associated meaning and relevance of a performance indicator in terms of its domain of discourse. An environmental performance descriptor is a specialization that relates to the environment on earth as a domain of discourse. Possible environmental performance descriptors (among others) are: DPSIR category Environmental aspect OEPI_D_1_3_Final.doc Dissemination Level: Public Page 75

84 Concept (class) PI Definition Element Description PI definition element is a concept to describe different elements contributing to a PI definition. The idea behind this is to break down the definition of a performance indicator as it is given in its normative reference into atomic elements that are formalized by means of the PI definition elements. The different kinds of elements shall be specialised in subclasses of the concept. Examples: Method(s) of measurement Calculation method or formula PI Statement Qualifier Reference Document The concept of PI statement qualifier shall be used to qualify different aspects of a PI statement. It is used to describe details about how the statement has been obtained which help to understand the quality of the statement and to decide how to use the represented data adequately. The following kinds of qualifiers have to be distinguished: Data collection method qualifier: is a concept to describe relevant information about the collection method that has been applied for the data represented in a PI statement. This concept has to distinguish between organizational and product-related (or product-life-cyclerelated) accounting. Data collection method shall include whether the method is validated/certified externally. Data quality qualifier: is a concept to describe different kinds of quality aspects of PI statements. Data calculation method qualifier: is a concept to describe characteristics of the calculation(s) that has/have been performed to obtain a PI statement. It shall be refined to deal with: o average values (specification of used sample should be given) o weighted values (a conversion factor has been applied to express importance) o aggregated values (figures of the same kind have been aggregated according to some rule or formula) A "reference document" is a document that is referenced somewhere instead of being included inline, for example. The implied necessary condition that a reference document has to have bibliographical information associated with it, assures that the reference is stored somewhere and can be retrieved if necessary. Specializations of a reference document are: normative reference and special purpose reference. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 76

85 Concept (class) Report Description A "report" is a document that is compiled for a specific reporting purpose. Reports may have common characteristics but further characteristics might be subject to specializations of this concept like: Sustainability report Environmental product declaration Special Purpose Reference Stakeholder Stakeholder Interest Reference Temporal Data Item A special purpose reference is a reference document created by someone for a defined use case or application. There is no offical normative reference (yet). Example: a company guideline. A stakeholder is a concept to represent some kine of defined interest and purpose within the domain of discourse. It might either be a natural person or a legal person. A stakeholder interest reference is a special purpose reference which defines interests of a stakeholder in a specific matter. A temporal data item represents a data item related to time, particualarly: Duration: is an amount of time measured in some unit of time like minutes, hours, days, years or possibly a combination like for example 1 year, 3 months, 2 days, 10 hours, and 23 minutes. Temporal Reference Temporal Reference A temporal reference specifies either a specific reference period or a specific referenced point in time. Point in time: is described by a date and a time and a timezone. Time period: is a period of time beginning at a defined point in time and ending at a defined point in time. Specializations include: business year, calendar year, month of year. In addition to classes, a number of object properties have been defined to represent relationships between members of classes as well as some datatype properties. Table 28 provides a list of relationships in OEPI Ontology with their descriptions. Inverse properties are listed together in one entry. Table 28: OEPI Ontology Relationships (properties) related to Environmental Performance Indicators Relationship (property) Description Object properties (in alphabetical order): OEPI_D_1_3_Final.doc Dissemination Level: Public Page 77

86 Relationship (property) has Authority has Bibliographical Information inverse: is Bibliographical Information Of has Conversion Factor has Definition inverse: is Definition Of has EPI Statement has Normative Reference inverse: is Normative Reference Of has Numeric Data Item has Observable Entity has Observed Entity has Owner has PI Statement Qualifier has Performance Descriptor has Reference Period has Reference Point In Time has Related Numeric Data Item Description relates a thing 34 to an authority that is responsible for some kind of legitimazation of the thing. associates a thing with its corresponding bibliographic information (a member of the class Bibliographical Information ). relates some thing to a conversion factor to be applied. uniquely relates some thing to its definition. The definition describes all necessary characteristics of a thing in the scope of this ontology. relates a thing with an EPI Statement. relates some thing to a normative reference which is a standard, law etc. that sets a norm or a standard for the thing. relates a thing to an associated numeric data item. relates a thing to things that can be the object of observation (assessment, measurement, etc) by the first thing. relates a thing (like some kind of statement or report etc.) to the specific entity that has been assessed to provide the statement. relates a thing to its owner. relates a thing (usually a PI statement) to a qualifier that describes a relevant characteristic of the thing. relates a thing (presumably a PI definition) to a performance descriptor that contributes to describe the meaning or relevance of the PI. relates some thing (like a PI statement) to a specific period of time. relates some thing (like a PI statement) to a specified point in time. is used to express an "indexed" data item which is a multiple/fraction of another numeric data item. The relationship connects the specified factor to the value to which it has to be applied to calculate the absolute value. 34 The class Thing is the common general superclass of user defined classes in Protégé 4. It represents any member of all its subclasses. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 78

87 Relationship (property) has Related Operational Entity has Related Product Entity has Related Quantity has Related Stakeholder Interest has Special Purpose Reference has Stakeholder Interest inverse: is Stakeholder Interest Of has Temporal Reference has Verification Reference is Compliant With is Numeric Data Item is Registration Authority Of is Standardization Authority Of is Verification Authority Description relates some thing (like an operational process) to an operational entity which implements the process. relates some thing (like a production process) to a product entity which is produced by the process. identifies uniquely the kind of quantity that has been used to calculate a "relative" data item. relates some thing with an associated defined stakeholder interest reference. relates some thing to a reference document like a company-specific guideline which is not a normative reference in the strict sense but valid for a special purpose or use case. relates a stakeholder to a specification of his/her interest(s). relates some thing to a specific temporal reference. The property is designed as a "value partition": the temporal teference is either a referenced point in time or a reference period. relates a verification authority to normative references according to which the authority is legitimized to perform verifications. relates a thing to another thing which sets some kind of standard or rule which the first one claims to fulfil.this claim might or might not be true or might be true to some extent. specifies a value partition for numeric data items (currently: absolute, relative, indexed). These values are disjoint and provide an exhaustive list. relates a registration authority to a thing that is registered by the authority. relates a standardization authority to a normative references that has been issued by the authority. relates an authority to some thing that has been verified by the authority. Datatype properties (in alphabetical order): has Narrative Description has Numeric Value can be used to associate a flat narrative description (e. g. a string) with some thing. can be used to associate a single numerical value (e. g. a double) with some OEPI_D_1_3_Final.doc Dissemination Level: Public Page 79

88 Relationship (property) Description thing. has Simple Bibliographical Information has Unit Of Measurement is Certified Externally is Operational is Reference Value can be used to represent a complete bibliographical information of a document in one data value (e. g. a string). can be used to asscociate a simple representation of a unit of measurement (e. g. a string) with some thing. indicates whether some thing has been certified by an external authority or not (should link to a boolean). indicates whether some thing like a process or a life cycle shall be understood as a concrete implementation in an operational entity or not (should link to a boolean). A process or life cycle etc. which is not operational can be considered as a reference process or process specification. indicates whether some thing shall be understood as a reference value or not (should link to a boolean) Sources of Environmental Performance Data One of the main objectives of the OEPI project is to enable utilization of the wide spectrum of available sources of environmental performance data. The ontological reference architecture for EPIs shall contribute to this objective by provision of concepts for the formalized description of the data sources of interest. Ideally, it should be possible to derive and deploy access methods for environmental data sources directly at runtime from data source descriptions if the data sources in question comply with the assumptions and standards defined in OEPI Ontology. Analysis of currently available environmental data sources, which were identified as relevant for the OEPI project by participating domain experts, though showed that this goal cannot be achieved in one single effort but only gradually and in the long term. The most important reasons are: Existing data sources do not comply to any kind of common standard so far with regard to data representation, access methods, and last but not least semantics of the provided data. They are often provided as printable documents (unstructured contents). Existing data sources are not generally accessible through open channels like the World Wide Web due to technical reasons as well as due to reasons of intellectual property. Technologies for semantic web applications required for the ideal approach are still under development and in their very early stages with regard to practical experience. This section presents the results of work package WP1 of the OEPI project towards the accomplishment of the objective stated above. They consist of a first classification and analysis of the selected environmental data sources and the initial design of the concept for the description of environmental data sources in OEPI Ontology. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 80

89 Classification of Environmental Data Sources Data about environmental performance exists in many sources that differ in content and data structure as well as exposed technical interfaces. Currently, each data source calls for an individual description of the process for data access, interpretation, and possibly also transformation before the data may be used. Data sources that have been considered in OEPI can be partitioned into the following classes: documents, online data bases, spreadsheets ( excel ), conventional data bases, and web services. Documents: Information often comes in form of documents (mostly portable document format, PDF). Although with state of the art procedures this kind of data source is commonly used, it entails a number of drawbacks for a proper integration of contained data when invoking the OEPI approach. Usually, in such documents there is no (known or machine readable exposed) structure of the contained data. Searching for certain information calls for human capabilities of understanding content. Hence, such data sources need a detailed description of structure and content as well as for the individual procedure for parsing and extracting the data. Data within documents is often not just contained within textual descriptions but also as images. Then additional capabilities are necessary to extract data from an image (e.g. a flow chart, a diagram, a pie chart etc.). It is to be expected that such a task may not be fulfilled technically within the OEPI project. Examples of how to describe the extraction of data from a chart may currently only be possible for image formats that contain enough additional meta information and not just the pixel data. Online data bases: These data sources are not data bases in the classical meaning. They comprise web sites that offer some dynamic interaction such as querying for sought after content. The interface of such data sources usually uses the HyperText Transfer Protocol (HTTP). Thus access is possible for users through web browsers but also by programs that use the GET or POST methods defined for http. The retrieved content is usually again embedded within a document. If it is embedded in an HTML or XML document, appropriate parsing can be quite easily described within the data source description as these encodings are usually sufficiently structured. If the retrieved content is embedded in other documents (or images), the problems already mentioned for documents as data sources hold. Spreadsheets: Often, data is contained in spreadsheets (usually Microsoft Excel) or can at least be exported to this format. The tabular format of the data allows for an easy description of the data as well as of functional relationships between the data. Databases: Databases (conventional relational data bases, object oriented data bases etc.) have the edge over other data sources that the structure of the data is already properly described by a data base scheme. If the scheme is publicly available, it eases the description of the data source significantly. Access of the data can usually be described and done in an abstract (data base technology independent way) by object relational mapping for example by Hibernate (Bauer and King, 2006). Web services: Web services would provide the most comfortable way of accessing data from the OEPI platform. With the web services description language (WSDL), a means of properly describing exposed OEPI_D_1_3_Final.doc Dissemination Level: Public Page 81

90 services and methods (e.g. for querying) as well as of the format of the retrieved content (not of the contained data). As mentioned already, it is essential for OEPI to enable the combination of data from different sources. Considering the results of the classification above, it can be expected that for some cases data from different classes of sources has to be integrated in order to gain the required information. Therefore, a concept for defining extraction from different (kinds of) sources including relations between data from different sources is necessary. Analysis of Example EPI Sources Table 29 summarises the analysed characteristics of environmental data sources that have been identified as relevant for OEPI with high priority. The table includes information about name of the data source 35, the provided data content, about its interface for data access and format, and an indicator whether the access method can be considered as structured. Structured access would be a prerequisite for computersupported data extraction. Table 29: Environmental Data Sources Summary of Characteristics Data source: Interface Data types and Structured Data content format access? European Commission Joint Research Centre (EU ILCD database): Web based browsing, search / download Data: XML / Images: Flow yes LCI 36 data from front-running business zipped XML charts associations, for materials, energy carriers, transport, and waste management Timberjack Green Forest Machines (John Deere): http / download from company website Text/Images: PDF document no Environmental Declaration, life-cycle oriented E75 mobile phone (Nokia): Example of Product Eco-Declaration: used http / download from company website Text: PDF document no materials, energy usage etc. Ruukki: Environmental product declarations for most http / download from company website Text/Images: PDF documents no commonly used steel products; use of resources: energy (transport, processes) feedstock energy of raw materials; 35 The web links corresponding to the listed data sources are available in annex C of this document. 36 LCI: Life cycle inventory OEPI_D_1_3_Final.doc Dissemination Level: Public Page 82

91 Data source: Interface Data types and Structured Data content format access? emissions to air, water and process waste. Outokumpu stainless steel manufacturer Web based data Html (asp) tables / yes, partly (Outokumpu): navigation / login PDF documents Data about chemical, mechanical and required physical properties of stainless steel for product designers to select most suitable steel Ecoinvent Centre: Web based database Data/Metadata: yes General LCA database of Swiss Centre of Lifecycle Inventories search (GET) / login required EcoSpold, not freely available, Text: PDF documents The Plastics Portal (APME): http website / zipped Text/Image: no Flowcharts / eco-profiles of process steps for plastics content for download PowerPoint / zipped PDF documents International Aluminium Institute (IAI): http website Text/Image: PDF no Inventory data for primary aluminium document industry Global Emission Model for Integrated Freely available Data/metadata: yes Systems (GEMIS): software, relational data base specific LCA program and database for energy, material, and transport systems. Data about database accessible by standard interfaces numerical values products/materials and processes (efficiency, power, capacity factor, lifetime; direct air pollutants like SO2, NOx, halogens, particulates, CO, NMVOC; greenhouse-gas emissions (CO2, CH4, N2O, SF6, all other Kyoto gases); solid wastes (ashes, overburden, FGD residuals, process wastes); liquid pollutants (AOX, BOD5, COD, N, P, inorganic salts) and land use.) included Field of need oriented analysis of see above as for see above as for yes material flows within scenarios BASiS: GEMIS / free only for GEMIS OEPI_D_1_3_Final.doc Dissemination Level: Public Page 83

92 Data source: Interface Data types and Structured Data content format access? Extension to GEMIS that adds data for the research demand side concerning mainly building and living. The model is dynamically based on time series for demand and provisioning technologies. Concept of Environmental Data Source in OEPI Ontology The results obtained from the analysis of existing environmental data sources did not suffice as the only foundation for the design of a common, sustainable concept for describing environmental data sources in OEPI Ontology. It was necessary to consider further requirements mainly with regard to aspects related to semantics of data and to data quality. They result from the state-of-the-art assessment in deliverable D1.1 (Jamous and Müller, 2010) as well as from the requirements analysis (chapter 3 and annex A). Table 30 provides an overview of the general concept that has been introduced to describe environmental data sources. This concept has to be further refined based on feedback and experience related to its practical application. When data sources compliant with this descriptive concept become available gradually, more advanced access methods ( services ) will be applicable. Table 30: OEPI Ontology Concepts related to Environmental Data Sources Concept (class) Description Core concept: PI Data Source, EPI Data Source It describes a specific source of environmental performance indicator statements 37 to support access and appropriate use of the data. (It is a specialization of a general PI data source.) The description covers: access information (like URI, protocol, formats, etc.) legal information (like owner, terms of use, etc.) assessment of predefined quality parameters of the data source like: o o o o o How long does the data source exist already? How long has its provider been in business? How extensively has the database been used? How frequently is the database updated? Can uncertainties be estimated for the data and are the metadata available? references to the performance indicators (resp. their definitions) 38 represented in the data source 37 This refers to the concept called (E)PI Statement as presented in chapter (see Table 27). OEPI_D_1_3_Final.doc Dissemination Level: Public Page 84

93 Concept (class) Description general description of the scope of the quantitative statements for the represented PIs based on PI statement qualifiers 39 (observed entities, geographical coverage, temporal coverage, etc.) The federation of technically different sources that would allow treating such a federated source as one single source transparently is a very complex task which is currently not covered within OEPI Ontology. Though, the current low level of detail of the concept of EPI Data Source does not inhibit such an approach Reuse of Ontologies As it has been described in chapter 4 of this document, one major advantage of an ontology-based approach is the option to reuse existing ontologies. This technique will be applied during further evolutionary development of OEPI Ontology. As the research of existing environmental ontologies has shown, there is no ontology currently available that could be used for the representation of environmental indicators for OEPI. Thus the core concepts of OEPI Ontology, which were introduced previously, have been created from scratch based on stated requirements. Nevertheless, several supporting concepts required by OEPI Ontology can benefit from reuse of existing ontologies and harness efforts spent by others already. The result will be a more comprehensive and powerful OEPI Ontology. The following paragraphs will explain one specific example of reuse within OEPI Ontology. At the end some more concepts will be named which are practical candidates for reuse of existing ontologies. As the core concepts of OEPI Ontology include references to documents like standards for sustainability reporting or for the definition of environmental performance indicators, it makes sense to include an existing ontology for the purpose of describing the bibliographical information of referenced resources. (See concepts Reference Document and Bibliographical Information in Table 27.) Some recommendations how to describe resources using the popular Dublin Core metadata with Resource Description Framework (RDF) have already been provided by the Dublin Core Metadata Initiative itself 40. Built on top of the recommendations provided by the Dublin Core Metadata Initiative, the very popular Bibliographic Ontology (BIBO) has evolved 41. That ontology is a community effort in creating a specification, the ontology itself, examples for its use and maintaining a network of community members who contribute to the development process. The Bibliographic Ontology is based on and extends the existing Dublin Core Metadata standard. The corresponding namespaces are included and used for building the Bibliographic Ontology which is mainly based on RDF. Additionally, some concepts of the popular Friend Of A Friend Ontology (FOAF) 42 have been 38 This refers to the concept called (E)PI Definition as presented in chapter (see Table 27). 39 This refers to the concept called PI Statement Qualifier as presented in chapter (see Table 27). 40 see 41 see 42 see OEPI_D_1_3_Final.doc Dissemination Level: Public Page 85

94 mapped into the ontology as well. Here a short overview of the Bibliographic Ontology s concepts will be given and a concrete mapping to OEPI s concepts will be shown as well. The related parts of the current OEPI ontology are shown below in Figure 10: Figure 10: OEPI s Document concepts The corresponding subset of BIBO s concepts is shown in Figure 11: Figure 11: Subset of BIBO s document concepts BIBO s approach to specify bibliographic information is using specific class properties that are inherited accordingly. These bibliographic properties include for example: authorlist citations contributors distributors identifiers, for example: Digital Object Identifier (DOI), International Standard Serial Number (ISSN) and International Standard Book Number (ISBN) OEPI_D_1_3_Final.doc Dissemination Level: Public Page 86

95 So the approach to link the Bibliographic Ontology with the OEPI Ontology is to provide a simple equivalence between the two document classes. As a result, OEPI s document concept will inherit the possibility to specify the bibliographic properties using BIBO s concepts. Additionally, OEPI s document class will then also be equivalent to the document concept of the FOAF Ontology with addition to the Dublin Core concepts as well. An additional mapping of OEPI s supporting concept of Natural Person is also possible to provide proper integration into BIBO s and FOAF s person classes. Additional extensions of parts of the OEPI Ontology are possible and can be evaluated during further ontology evolution: Usage of the physical unit concepts of the SWEET ontology 43, as it is a rather complete and complex ontology describing also conversions between units and a taxonomy of units in general, reuse of existing organizational ontologies to reduce the refinement effort in the OEPI Ontology, reuse of general property-value concepts like those found in many top level ontologies, inclusion of existing time/space concepts, or further extension of OEPI s person concepts using for example the FOAF Ontology. Although the shown example is rather simple, it emphasizes the power of reuse of existing ontologies during OEPI s ontology engineering process. Many existing ontologies like the BIBO concepts already provide proper integration of other ontologies so OEPI s ontology will integrate itself as well into the existing network of existing ontologies that are already in use and are proven to work well. 6.2 Application of OEPI Ontology Application Guideline This section explains how to deploy the ontology developed within OEPI in a broad spectrum of applications. Let us first depict the starting situation: The first version of OEPI Ontology has been developed. As explained in chapter 6.1, it was decided to use OWL 2 as modelling language. For the modelling phase we therefore used an ontology editor that is able to store the resulting ontology in an OWL file which is just a file in OWL format. Protégé 4 was used as the ontology editor here. Apart from being the most widely used ontology editor, it has the additional benefit of being able to store the resulting ontology in an OWL file as well as to load it from such a file (for example: OEPI-Ontology.owl ). Our goal is to provide a bridge to applications that want to incorporate the ontology in a fancy way. This means that these applications should be able to access and manipulate the elements that define the ontology. (See chapter for the main elements of OWL 2 use to create OEPI Ontology.) Such an application has to be coherent with the explicit and inferred rules of the ontology without being forced to implement this coherency in the application itself. From another point of view this means to make the application thin by providing a thick infrastructure. In detail, the following features are requested from such an API as outlined in (Bechhofer, 2007)): 43 see chapter for information about SWEET OEPI_D_1_3_Final.doc Dissemination Level: Public Page 87

96 Modelling: Provision of data structures that represent OWL ontologies/documents, Parsing: Conversion of some syntactic presentation, e.g. OWL-RDF, into some useful internal data structure, Serializing: Producing a syntactic presentation, e.g. OWL-XML, from a local data structure, Manipulation/Change: Ability to manipulate the underlying objects, Inference: Providing a representation that implements/understands the formal semantics of the language. One could deduce that for further application development, only the OWL representation of the ontology alone would be sufficient. It should though be remembered that new or changing requirements with regard to the concepts that are covered by the ontology shall always be dealt with by extending or adapting the original ontology. This would be done most efficiently probably by means of the ontology editor again. A properly implemented application would then be able to deal with the enhanced ontology seamlessly. As there are several programming interfaces available for the described purposes, they have been evaluated in the OEPI project and the findings have been documented in chapter 5.3. The most promising one, which was recommended at the end of that comparison, is OWL API 44. This is supported additionally by the recommendation regarding its importance that is explicitly given by W3C in (Hitzler et al., 2009). (Horridge and Bechhofer, 2009) and (Bechhofer, Volz, and Lord, 2003) are further references that contain detailed material with regard to OWL API. The important technical information shall be summarized here again: According to the community web page, the Ontology Web Language Application Programming Interface (OWL API) is a Java API and reference implementation for creating, manipulating and serialising OWL Ontologies. It is published under the Lesser General Public License (LGPL) which is an Open Source license. This special license allows developers to use it even in proprietary software distributions because it only contains a weak copyleft 45. The download does contain two jar-files but one of them is the source code and is not needed for implementation. For nearly every use case for interaction with ontologies there is an example code file. Furthermore it is commented very well and every project which uses this API solely has to import one small jar-file. It is recommended to have a look at the provided tutorials which are available online 46. Among others, they cover the following tasks: Loading Ontologies: read an owl file into memory to make the ontology available. The file can be local or accessed via a URI. Saving Ontologies: store an ontology in an OWL file. This can be used to generate different formats of the ontology, if this is required. Entities: Shows how to obtain references to entities (classes, properties, individuals etc.). Adding axioms: populating an ontology with new rules (axioms) 44 see 45 see 46 see OEPI_D_1_3_Final.doc Dissemination Level: Public Page 88

97 Deleting entities Restrictions: handling of subclass restrictions Reasoning: interacting with a reasoner Annotations: providing annotations to the ontology itself Merging ontologies Every code example is commented. Additionally these tutorials can be used as a construction kit for nearly every desired OWL function. Especially the interaction with the reasoner is an important point, as it allows addressing logical questions and inferences as provided by OWL 2 to the specific ontology Example: Automatic Ontology Concept Glossary This chapter demonstrates the use of OWL API by a simple example for the automatic creation of a concept glossary for OEPI Ontology from the ontology representation in an OWL file. OWL API provides a central point of entry by the Java class OWLOntologyManager. The UML diagram in Figure 12 on page 89 shows the relationship of the OWLOntologyManager class with its subclasses. The subsequent example shows how OWL API can be used inside a Java software project to derive a simple glossary consisting of the concepts of an ontology and their corresponding annotations. It is partly to show that using the ontology-driven as well as ontology-aware application development method motivated in this deliverable is able to deliver a great deal in avoiding redundant work. According to these methods, an ontology cannot only be used to derive Java classes to develop the application ( ontology-driven application development ) but also to create an ever updated user glossary for users of the OEPI platform under development ( ontology-aware application ). Figure 12: A UML diagram showing the management of ontologies in OWL API (Horridge and Bechhofer, 2009) OEPI_D_1_3_Final.doc Dissemination Level: Public Page 89

98 This example just uses OWL API to access and parse the OEPI Ontology. Obviously, use of the API offers a lot more possibilities. For example, update of annotations in the ontology through an application or service could be implemented. However, even that simple example shows how the ontology can be leveraged. The following code fragment shows how an ontology can be loaded from a web resource specified by the java object IRI. public OWLOntology loadontology() { try { OWLOntologyManager manager = OWLManager.createOWLOntologyManager(); // Let's load an ontology from the web IRI iri = IRI.create(ONTURL); OWLOntology ontology = manager.loadontologyfromontologydocument(iri); return ontology; } catch(exception e){ e.tostring(); return null; } } The following code fragment shows how the loaded ontology is parsed into a multidimensional array to be able to transform it into every intended output format. public String[][] getglossary (OWLOntology ontology) { try { String outputarray[][] = new String [ontology.getclassesinsignature().size()][2]; int counter = 0; for (OWLClass cls : ontology.getclassesinsignature()) { String output = cls.tostring(); output = output.replaceall(ontclassprefix, ""); output = output.replaceall(ontclasspostfix, ""); output = output.replaceall(ontclassseparator," "); if (cls.tostring().contains("owl:thing") == false) { outputarray[counter][0] = output; } } else { } } return outputarray; } catch (Exception e) { System.out.println(e.toString()); return null; } for (OWLAnnotation annotation : cls.getannotations(ontology)) { if (annotation.getvalue() instanceof OWLLiteral) { OWLLiteral val = (OWLLiteral) annotation.getvalue(); outputarray[counter][1] = val.getliteral(); } } counter++; In order to be able to integrate the created glossary into official documents, such as printed and branded user manuals, we use the Open Document Format (ODF) and a Java library called ODFToolkit 47 to derive an editable document. ODFToolkit is licensed under an Apache License which is an Open Source License that 47 OEPI_D_1_3_Final.doc Dissemination Level: Public Page 90

99 has no copyleft. Software components that use this library can hence be integrated into proprietary software projects. The following code fragment shows how the aforementioned array is transformed into that ODF document. public class ODFWriter { private String FILEURI = "File.odt"; private OdfTextDocument odf = null; } protected ODFWriter () throws Exception { this.odf = (OdfTextDocument)OdfTextDocument.newTextDocument(); } protected ODFWriter (String url) throws Exception { this.odf = (OdfTextDocument)OdfTextDocument.newTextDocument(); this.fileuri = url; } public void writearraytodocument (String[][] input) { try { if (input!= null) { for (int z = 0; z < input.length; z++) { this.odf.newparagraph().addstyledcontent("heading 1",input[z][0]); this.odf.newparagraph(); this.odf.newparagraph().addstyledcontent("default",input[z][1]); this.odf.newparagraph(); } this.odf.save(this.fileuri); } } catch (Exception e) { System.out.println(e.toString()); } } This rather simple example shows how the OWL API and some additional Open Source Software libraries can be used to transform the knowledge that is represented by a well-defined ontology into a more common yet in this case only partial knowledge representation. We were also able to show how the added complexity of developing an ontology beforehand can be greatly benefiting further steps of software development and software usage. If we add user interaction by assuming that interested users could add new annotations to distinct concepts or update them and this expert knowledge is brought back to the central knowledge representation (the ontology), it is immediately obvious that this hits the point of creating a single information space in Europe (SISE). This can be even reinforced by the interactivity of expert stakeholders. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 91

100 6.2.3 Example: Use Case "Collaborative Design for Environment" For requirements analysis as well as for later evaluation of results, use cases have been described for the OEPI project. The use case, which is concerned with collaborative design for environment, has been considered here as an example for the applicability of the OEPI Ontology. In this chapter, a specific use case scenario will be described as well as its problems in the current situation and the expected contribution of the OEPI Ontology to the solution. Finally, a very limited setting for a concrete case study is deduced from the use case scenario. According to this specification, the case study has been launched as a parallel activity to foster transition of results from WP 1 to the software development work in WP 2 and 3. Findings of the case study will be presented separately Use Case Scenario: Design of a New Building A customer intends to establish a new building and wants to include environmental performance issues in the design process besides other important issues like cost and quality. There is a consultant who provides life cycle models for selected types of buildings which can be adapted to specific customer requirements by a set of variable parameters which reflect design decisions for the building to be created. Models are designed to report a predefined set of environmental performance values for the type of building, which is represented in the model, with a specific set of parameter values. The consultant may vary the selection of the building type by using different models and may change the parameter settings for the model within the given boundaries in cooperation with the customer. By inspecting the resulting reports, they can assess the impact of the design decisions on the reported environmental performance data and thus find the most sustainable design of the building within given boundaries. Figure 13 illustrates an example of such a model and part of its output report. Figure 13: Existing parameterized LCA model of buildings (BEAT) at Siemens The specific, limited models that are available through the consultant have been created by some supplier of environmental models by means of life cycle assessments. The supplier uses highly sophisticated software for modelling and simulation and has access to a wide variety of environmental performance data which are used to perform the life cycle assessments. The assumptions and design decisions taken by the model supplier (also known as the system boundaries ) while creating customized models for the consultant have OEPI_D_1_3_Final.doc Dissemination Level: Public Page 92

101 to be stated together with the delivered model because they determine the domain of applicability of the model. The applicability of the model is important for the consultant who has to decide whether a customized model and its inherent set of parameters represent the situation and intended purpose of the customer adequately. It might even be required to specify and quantify the extent of adequacy or deviation The Devil is in the Details Difficulties of the Current Solution For the concrete use case, it is assumed that customized models available through Siemens Building LCA (called BEAT ) shall be used as the basic models within a design-for-environment process for a new building. The customer though demands to include life cycle data of elevators in the calculation of the environmental performance data for the building which are not considered in the customized model of BEAT so far. However, there are similar customized models for LCA of elevators available through other consultants and model suppliers, for example LCA models made by VTT that report life cycle performance data of elevators supplied by Kone as illustrated in Figure 14. Figure 14: Existing LCA results of elevators at Kone At first glance, it should be easily possible to extract corresponding performance data from the LCA reports provided by the building model and the elevator model and to combine them to get accumulated values that represent the summary environmental impacts of a building with elevators. Looking more closely, it is not as easy as it seems because the two kinds of models and thus their reported performance data usually do not relate to exactly the same system boundaries. This implies that the reported performance data even for equivalent performance indicators might be incompatible with regard to the selection of the concrete data values that have been used as input for calculation. In the concrete use case, for example, the values for impact category global warming potential over the complete life cycle, though both measured the same way in kg of CO 2, might be incompatible with regard to the assumed life time of the building or elevator, respectively, or with regard to the geographical region where the building resides or where the elevator is installed, respectively. Currently, it is the sole responsibility of the user, for example a consultant, to check the applicability and compatibility of performance data supplied by different models and to compensate mismatches if necessary. OEPI_D_1_3_Final.doc Dissemination Level: Public Page 93