OEPI Ontology for Environmental Performance Indicators
You will find here an introduction to the ontology for environmental performance indicators. Due to its origin in the OEPI project , the ontology is referred to as the “OEPI Ontology” though it is intended to be useful beyond the scope and duration of this project .
In order to keep this article tight we provide only basic information about the ontology that is helpful to browse, understand, and possibly use or extend it on your own. For a first understanding of OWL ontologies you may read the good tutorial of Matthew Horridge . Details about installation and use of the required tools or interfaces can be retrieved from the references given at the end. Further insight into the domain of environmental performance indicators can be gained through other publications on the OEPI project website .
What is the OEPI Ontology about?
Today, there is a great variety of environmental performance indicators (EPI). Their main purposes, for example according to Jasch in , are:
- to quantify the current environmental performance of some entity,
- to track the change of environmental performance of an entity between different points in time,
- to compare or to benchmark the environmental performance of different entities,
- to utilize the environmental performance of entities in decisions, or
- to assess the achievement of quantitative goals related to environmental performance in transformation or improvement processes.
The OEPI Ontology defines the concepts that are needed to describe EPI in a formalized, computer-accessible way. The aim is to establish a common understanding of their meaning and interpretation across different organizations and applications.
The ontology establishes the “reference body of domain knowledge” for the implementation of the OEPI platform and the OEPI user portal. The OEPI platform can be regarded as a common resource of selected and preprocessed data for defined EPI from various data sources. The OEPI user portal is the single point of access for the business-oriented user who is neither an expert of the domain of EPI nor an expert of web technology. The portal relies on the OEPI platform to feed its collection of use-case-oriented services with a wealth of suitable EPI data whenever users request it.
The OEPI Ontology uses Web Ontology Language OWL  and has been built with the ontology editor Protégé 4 . Though the ontology will evolve further during the remaining course of the OEPI project, a first version is available for the interested public now through the OEPI website.
Some hints to get you going on your own exploration
When you open the OEPI Ontology in Protégé, the ontology annotations are displayed by default. They give you some information related to the current version of the ontology. In the respective functional tabs, you will find views of the asserted hierarchies of classes, properties, and individuals. Further insight can be obtained by running a reasoner (We recommend to use the Hermit reasoner  which can be selected from menu “Reasoner“ in Protégé 4.1.) to produce and display the inferred hierarchies.
Furthermore, you will see that all entities of the OEPI Ontology have comments (as annotation properties) that give up-to-date textual descriptions of the meaning and purpose of the entity. They are not replicated here for obvious reasons and will help you to explore the ontology in depth on your own.
For example, figure 1 shows a screen capture of the OEPI Ontology loaded in Protégé 4.1. We have opened the functional tab “Entities”. After running the Hermit reasoner, we have selected class EPI_Statement in the class hierarchy. Therefore, its annotations and its description can be browsed in the respective windows on the right side of the screen. On the left side below the class hierarchy, we could explore the object property hierarchy.
Some more hints to support your exploration
The OEPI Ontology contains a class hierarchy with primitive as well as defined classes, a considerable number of object properties, data properties, and individuals.
Primitive v. defined classes: The aim might be to have only defined classes in the end but in the current state primitive classes clearly indicate that their definition is considered to be incomplete. There might as well be defined classes in the current version that are still incomplete (with regard to the concept they represent) but have been converted to “defined” for reasoning purposes. They will probably need further revisions in the future.
Use of property characteristics: There has been no intense use of the characteristics of properties so far, except that for object properties inverse properties have usually been created when appropriate. Furthermore, the characteristic “functional” has been used for some object properties rather than introducing a cardinality of 1 in an object restriction.
Naming scheme: Names of classes and individuals (e. g. EPI_Statement) start with a capital letter, property names (e. g. is_Compliant_With) begin with a small letter. Names may be composed of multiple segments separated by the underline character. The first letter of the second and all further segments is a capital for all kinds of entities. Special characters other than the underline character and “white space” have not been used in names.
Roles of individuals: Some of the individuals are considered as part of the ontology (e. g. EPI_Descriptor_Aspect_Emissions) and some have been created only as example data for the purpose of demonstration. The individuals of this second kind have a name prefix “DEMO_” to make them easily recognizable (e. g. DEMO_Product_KONE_Monospace).
Two flavours of class definitions: When looking closely at class definitions, you might encounter two different approaches to class definitions. The first one, which might be called “descriptive”, aims to express the necessary defining conditions for members of the class as complete as possible within the scope of OEPI. The second one, which might be called “inferring”, exploits the reasoning mechanism to derive membership in classes by the existence of a few distinctive object properties (or even only one). There are representatives of both kinds in the OEPI Ontology and furthermore some class definitions which combine both approaches. There might be no general reason for a class to be defined in either of these ways beyond reflecting the current “state of cognition” in OEPI ontology development.
Some classes are defined in a very simple way because they are candidates to be re-used from other existing ontologies in the future, for example class Bibliographical_Information which is currently equivalent to
Thing and has_Simple_Bibliographical_Information some string
Therefore, bibliographical information is currently just represented by a functional data property linking to a character string, which is expected to hold the full bibliographical information.
In the Focus – the “EPI Statement”
In a simplified view, environmental performance indicators are different ways of expressing certain aspects of environmental performance of entities. In the OEPI Ontology, an “EPI Definition” describes all relevant characteristics of a specific EPI. If we use one defined EPI and assess it for a real entity, the result constitutes what is called an “EPI Statement” in the ontology. (See the “OntoGraf” visualization (created by the OntoGraf plugin in Protégé 4.1 which is very useful to visualize the ontology) of this class and its neighborhood). An EPI statement states quantitative information about a specific entity, which is called the “observed” entity, with all additional details that are required to make the statement compliant with its associated EPI definition.
Different kinds of EPI statements and their typical structure and content are represented in the ontology by different subclasses of EPI statements, for example EPI_Statement_ODP for statements about ozone depletion potential (ODP). An individual member of such a class would be one concrete data record matching this kind of EPI statement.
Hopefully, you are now keen to dig deeper into the OEPI Ontology on your own. This short introduction has provided you with hints where to start and how to do this. Now you may download the ontology – and an ontology editor if you don’t use one already – and jump into the water. Your feedback will be highly welcome at this website.
 OEPI Consortium, Project website http://www.oepi-project.eu/
 OEPI Consortium, Deliverable D1.3: Reference Ontology for EPIs – Requirements and Design, January 2011
 OEPI Blog, Why OEPI needs to invest in ontology development, http://oepi-project.eu/blog/2011/05/18/why-oepi-needs-to-invest-in-ontology-development/, May 18, 2011
 Christine Jasch, Environmental performance evaluation and indicators, Journal of Cleaner Production, Volume 8, Issue 1, February 2000, Pages 79-88
 OWL Working Group, OWL 2 Web Ontology Language Document Overview, W3C Recommendation, 27 October 2009, http://www.w3.org/TR/2009/REC-owl2-overview-20091027/ (accessed: May 30, 2011)
 The Protégé Ontology Editor and Knowledge Acquisition System, website http://protege.stanford.edu/ (accessed: May 30, 2011)
 Matthew Horridge, A Practical Guide To Building OWL Ontologies Using Protégé 4 and CO-ODE Tools, Edition 1.3, The University of Manchester, 2011, most recent version available for download at http://owl.cs.manchester.ac.uk/tutorials/protegeowltutorial/ (accessed: June 14, 2011)
 Hermit OWL Reasoner, website http://www.hermit-reasoner.com/ (accessed: May 30, 2011)