The Web Ontology Language (OWL) [1] is a commonly used standard for creating ontology artifacts. However, its capabilities for reusing existing OWL artifacts in the creation of new artifacts is limited to the import of whole ontologies, even when only a small handful of classes, object properties, and so on (which we refer to generically as \OWL components") are relevant. This situation can result in extremely large and unwieldy, or even broken, ontologies. To address this problem while still promoting ontology reuse, the OBI Consortium [2] has elucidated the Minimum Information to Reference an External Ontology Term (MIREOT) [3]. We provide a suite of plugins to the Protege [4] editor that greatly simpli es the use of MIREOT principles during ontology creation and editing.
Dealing with the ever-increasing amount of data being generated has been an extremely di cult problem. Researchers have spent a lot of time categorizing this information and the semantic web is one response to this problem. Ontologies, in particular, are one of the technologies that the semantic web uses to help organize information. To make ontologies the basis of semantic integration across multiple data sources, we need to facilitate re-use of ontologies { and representational units from those ontologies { across communities.
However, the semantic-web standard for ontologies, the Web Ontology
Language (OWL) [
For this reason, the Ontology for Biomedical Investigations (OBI)
Consortium [
While the speci c issues we want to resolve are linked to the OWL language, our primary aim is to provide a simple MIREOT solution for the user community of Protege. For that purpose, we present a cohesive suite of plugins built for Protege 4.1 to simplify the use of basic MIREOT principles. 2
The OWL language is designed to fascilitate data sharing on the web in a
machine readable way through the creation of ontologies. All OWL ontologies can be
expressed as an RDF [
Protege is a popular, open-source ontology editor built and maintained by
researchers at Stanford. It provides a graphical interface that uses the OWL
API [
A plugin [
The OBI Consortium has de ned a set of principles { which we refer to
generically as \MIREOT principles" { for importing only one or more OWL
components from another ontology. These principles specify the minimum unit of
import as follows: the IRI of the source ontology, the IRI of the source
component being imported (e.g., class, object property, etc.), and the IRI of the new
parent component in the target ontology. Additionally, the Consortium de ned a
new annotation property in the Information Artifact Ontology (IAO)[
We have implemented crucial parts of the MIREOT speci cation in a suite of Protege plugins. Our implementation of the MIREOT speci cation di ers in the following ways: 1. It pulls every annotation of the source component, not just \rdfs:label" and \iao:de nition". 2. It saves all relevant axioms in the target ontology instead of external les.
Additionally, we made the following assumptions: 1. Only the most recent source ontology is preserved in the "iao:imported from" annotation property. Any similar annotations are stripped from the component to avoid confusion about which ontology was the direct source of a class. 2. If an ontology lacks an IRI, then the URL from where it was loaded is used instead. 3. If an annotation property that is not found in the target ontology is imported, then its \rdfs:label" is transferred as well, if it exists. 4
The suite of plugins includes one tab plugin that contains three view plugins. A tab plugin tends to be simple; it contains multiple views that should work together to accomplish some overarching purpose. A view plugin represents the building blocks of a tab plugin and implement most of the actual functionality within a tab plugin. The tab plugin does not manage any additional state.
The rst and most novel of the three view plugins is the \MIREOT Additional Ontology View". It allows users to load an additional ontology and search it for classes or object properties. The search algorithm matches the query against a con gurable set of annotations on each component. The currently searchable annotation properties are \rdfs:label", \rdfs:comment", and \iao:de nition". All loading and searching is done in a separate thread to keep the user interface uid and stable.
The other two view plugins represent the active ontology loaded by Protege. They display the hierarchy of either the classes or the object properties of the active ontology. Additionally, they allow a user to drag a component from the results panel of the \MIREOT Additional Ontology View" and drop it under the new parent of the component in the target ontology.
A short video demonstrating a subset of the features of the suite can be found online at http://vimeo.com/46860781. The suite and installation instructions can be found online at http://bitbucket.org/sohj/mireot-protege-plugin. 5
We have developed a suite of Protege plugins that implements crucial parts of the MIREOT speci cation de ned by the OBI Consortium. To our knowledge, this is the rst Protege plugin to do so. Although other tools such as OntoFox also implement MIREOT, our plugins place the work ow directly into the most commonly used ontology editor, and thus are more likely to facilitate MIREOT in practice. Although it has face validity, veri cation of this conjecture requires further study.
Our implementation of the MIREOT principles di er from the approach taken in the OBI speci cation in several notable ways: { We import all of the annotations of an imported component. We do this because vital information about some components are included in annotations other than \rdfs:label" and \iao:de nition". { We keep the axioms in the main ontology. This decreases the friction of development for Protege users while still maintaining necessary provenance information for editors, consumers, and users. { We report only the most recent source ontology information. This will prevent confusion based on multiple \iao:imported from" annotations that do not allow one to distinguish from which ontology a component was imported directly. { We save the ontology URL as the IRI in the case of ontologies that do not have an IRI. We feel, it is important that the provenance of the imported component is preserved somehow.
One of the major reasons that OBI separates the imported terms from the main ontology is to allow for automated updates. For this reason, we intend to develop a tool which will allow users to update the terms while still keeping them in the main ontology using the saved provenance information. 6
This work was funded by award R01GM101151 from the National Institute for General Medical Sciences. This paper does not represent the views of NIGMS or the National Institutes of Health.