As ontologies are developed there is a common need to transform them, especially from those that are axiomatically lean to those that are axiomatically rich. Such transformations often require large numbers of axioms to be generated that a ect many di erent parts of the ontology. This paper describes the Ontology Pre-Processor Language (OPPL), a domain-speci c macro language, based in the Manchester OWL Syntax, for manipulating ontologies written in OWL. OPPL instructions can add/remove entities, and add/remove axioms (semantics or annotations) to/from entities in an OWL ontology. OPPL is suitable for applying the same change to di erent ontologies or at di erent development stages, and for keeping track of the changes made (e.g. in pipelines). It is also suitable for de ning independent modelling macros (e.g. Ontology Design Patterns) that can be applied at will and systematically across an ontology. The presented OPPL Instruction Manager is a Java library that processes OPPL instructions making the changes to an OWL ontology. A reference implementation that uses the OPPL Instruction Manager is also presented. The use of OPPL has been demonstrated in the Cell Cycle Ontology.
The use of OWL ontologies is rapidly increasing, especially in areas such as bioinformatics. As ontologies are more widely used, more tools are needed to ful ll the requirements of new users. One of those requirements is an abstract, straight-forward, high-level language for manipulating ontologies in a re-usable and e cient way.
This is particularly necessary when many of the ontologies currently written
in OWL are axiomatically lean and increased computational inference will only
arise with increased axiomatisation. For example, in many bio-ontologies, much
of the ontology's semantics are bound up in the term names (rdfs:label)
and these need to be made explicit so that reasoners can use those
semantics. The Gene Ontology (GO) [
Another justi cation for such a language comes from the fact that there
are bio-ontologies that are built using automatic procedures (e.g. pipelines).
For example, the Cell Cycle Ontology5 (CCO) [
A general justi cation for a high level language is based in how OWL ontologies are currently manipulated by the user. OWL ontologies can be manipulated in di erent ways. The most obvious and common method is via editors such as Protege6, but such manipulations are not reusable: a user makes changes through a graphical interface, and if another user wants to recreate the changes, they will need to be applied step-by-step (Swoop7 allows for change sets to be reused by di erent users, but the ontology needs to be loaded and changes applied each time). Another method is to manipulate the ontology programmatically via APIs such as the OWL API8. When interacting with the ontology programmatically, the manipulations are reusable, but such access can only be performed by an API-familiar programmer, and each change of the ontology can represent a large amount of programming e ort. The Protege script tab9 o ers some level of abstraction but still full programming knowledge is required. Therefore a high level language for de ning reusable actions is required.
The Ontology Pre-Processor Language10 (OPPL) ful lls the requirements cited above. OPPL o ers an abstract and straight-forward syntax that can be used to manipulate OWL ontologies. The OPPL manipulation actions can be easily re-used in di erent OWL ontologies, at di erent stages and by di erent users, o ering most of the expressivity and re-usability of an API-level access to the ontology, with minimal notions of programming required. The intended 4 The Gene Ontology Next Generation (GONG) work ow does precisely that: http://www.gong.manchester.ac.uk/ 5 http://www.cellcycleontology.org 6 http://protege.stanford.edu/ 7 http://code.google.com/p/swoop/ 8 http://owlapi.sourceforge.net/ 9 http://www.med.univ-rennes1.fr/~dameron/protegeScript/ 10 http://oppl.sourceforge.net/ audience of OPPL is formed by ontology curators who need to do exible and automatic ontology building but without necessarily having a strong computational background. 2
The OPPL syntax is based in the Manchester OWL Syntax [
The central unit of the OPPL syntax is the so-called OPPL instruction. It describes one or more actions to be performed upon an entity or groups of entities11: each action, or OPPL statement, is delimited by a semicolon (;). See Fig. 1 for details.
SELECT Class: admin;ADD label "office admin";
There are two types of OPPL instructions which are explained in detail in subsections 2.1 and 2.2. This OPPL instruction is formed by only one OPPL statement that adds/removes an entity to/from an ontology. For example, if we want to add a class named undergraduate to the ontology, we would use the following instruction:
To remove a class from the ontology, we would use, for example, the following instruction:
The OWL API (which is used by OPPL to access the ontology, see section 3) only allows the addition of axioms, in conformance to OWL semantics. As a result, it is not possible to add a class per se, instead, only an axiom 11 An entity is assumed to be a named class, a named individual, or an object property.
Currently OPPL does not support data properties nor datatypes. that references the class can be added. Therefore the cited OPPL statement (ADD Class: undergraduate;), when processed, adds an axiom stating that the class undergraduate is a subclass of owl:Thing. This assumption is made to make the OPPL syntax more simple. A REMOVE statement deletes the axioms that reference entities, not the entities as such. 2.2
Multiple statements OPPL instructions This type of OPPL instruction is composed of at least two OPPL statements. The rst statement is always a SELECT/ADD statement, followed by one or more ADD/REMOVE statements.
In the case that the rst statement is a SELECT statement, it selects entities from the ontology and the following ADD/REMOVE statements add/remove axioms (semantic axioms such as restrictions or annotations) to/from the selected entities. The selection is made according to a condition, which can be a semantic axiom (e.g. having a concrete restriction like part-of some nucleus as a necessary condition) or an annotation value. Any entity that matches the condition will be selected and the next ADD/REMOVE statements will be applied to it. For example:
only (intellectual_dinner and party);
This instruction does the following: selects any class that has the necessary and su cient restriction participates_in only (intelectual_dinner and party). Then, adds the rdfs:label \professor" to it. Finally, removes the necessary restriction lives_on only (not campus) from it.
Annotation values can be used to select entities, and regular expressions support for annotation values12 is included for this purpose. In the following example, any class in which the rdfs:label matches the regular expression \(.+) (development)" (e.g. \cell development") will be selected. The selected class(es) will become subclass(es) of development, and the necessary restriction acts_on some cell will be added (<1> refers to the rst group of the matching string):
The SELECT statement need not be a condition to ful ll; a single entity can be selected: 12 The regular expressions are Java style: http://java.sun.com/j2se/1.4.2/docs/api/java/util/regex/Pattern.html
Conditions can also be de ned to select object properties:
In the case that the rst statement is an ADD statement (instead of SELECT), an entity will be added and the next ADD/REMOVE statements will be applied to it. For example:
This OPPL instruction adds a class professor rst. Then, it adds the rdfs:label \sta " to it. Finally, it adds the necessary and su cient restriction participates_in only (intelectual_dinner and party). 2.3
OPPL syntax design The development of the OPPL syntax has been driven by the authors' daily needs while working with bio-ontologies (mainly enrichment of the Gene Ontology in the GONG work ow and enrichment of CCO), and therefore some features that would make the OPPL syntax more complete have been left aside as they did not provide an immediate bene t. However, there are pointers that OPPL could follow to provide a more complete syntax. For example, more programminglike features (loops, conditional control, subroutines, etc.) would be desirable. A SET statement that simply changes axioms (instead of only removing or adding them) will probably also be part of the future OPPL syntax. Some segmentation capability is also needed: for example, the ability to extract parts of an ontology to introduce them in a new ontology.
For the same reason, there has also been an equilibrium between the needs of the authors to introduce more and more tailored instructions and the aim to keep OPPL simple and clean. Some examples of tailored instructions include the ability to distinguish between primitive/de ned classes:
Another example of such tailored instructions is the disjointWithSiblings statement, that can be used, for example, to make all the classes of a subtree disjoint with their siblings:
There are also two instructions (assertedSubClassOf and assertedSuperClassOf) that allow to query for super/subclasses without using the reasoner, which means that, for example, inconsistent classes can be selected:
The complete OPPL syntax can be learned by following the examples provided in the OPPL web site13. Other instructions not reviewed in this paper include disjointWith, differentFrom, sameAs, type, descendantOf, ancestorOf, subPropertyOf, etc. 3
The core OPPL is provided as an stand-alone Java library (OPPLInstructionManager) that can be used to write applications (Fig. 2). The OPPLInstructionManager processes each OPPL instruction that is provided to it and performs the changes in an OWL ontology chosen by the user. The changes to the ontology are made by the OPPLOWLManager class, a wrapper for the OWL API, when prompted to do so by the OPPLInstructionManager. The OPPLOWLManager performs all the actions related to OWL: accessing the model, querying the model via reasoners, changing the model, and loading or writing ontologies.
Each OPPL instruction is executed independently, therefore, if, for example, an OPPL instruction adds an axiom the following OPPL instruction can safely remove it. For the same reason, if an OPPL instruction removes an entity and a later OPPL statement of an OPPL instruction needs to operate upon it, the execution will fail, but the execution will continue with the next OPPL statements of that OPPL instruction. Similarly, if a SELECT statement is unable to select an entity, the rest of the OPPL statements in that OPPL instruction will not be executed.
The parsing of the Manchester OWL Syntax expressions is made by the parser provided by the OWL API, through the OPPLOWLManager, which returns an OWLDescription object (from the OWL API) that is used to query the reasoner. The user can choose which reasoner to use: Pellet14, FaCT++15 or any reasoner via the DIG interface16. Errors are agged at di erent levels: OPPL syntax, reasoning, Manchester OWL syntax, OWL model changes, etc.
The OPPLInstructionManager is independent of the OPPL instructions provider, which is anything that implements the OPPLInstructionsProvider interface. In 13 http://oppl.sourceforge.net/test.oppl 14 http://pellet.owldl.com/ 15 http://owl.man.ac.uk/factplusplus/ 16 http://dig.sourceforge.net/ the provided reference implementation the OPPL instructions provider is a at le parser (by convention, les with the su x .oppl are used), but it would be simple to program any other OPPL instructions provider (e.g. to include the OPPLInstructionManager in another program). In the reference implementation, .oppl at les allow comments starting with hash (#) and the OPPL instructions are divided by white lines (the OPPL instructions can be multi-line). See Fig. 3 for an example OPPL le.
OPPL file # Create object properties inmediately_precedes and inmediately_preceded_by ADD ObjectProperty: inmediately_preceded_by;ADD functional;ADD subPropertyOf preceded_by; ADD domain CCO_U0000002;ADD range CCO_U0000002; ADD ObjectProperty: inmediately_precedes;ADD functional;ADD subPropertyOf precedes;ADD inverse inmediately_preceded_by;ADD domain CCO_U0000002;ADD range CCO_U0000002; # Meiotic cel cycle: G1 -> S -> G2 -> M SELECT Class: CCO_P0000327;ADD subClassOf inmediately_preceded_by some CCO_P0000325;ADD subClassOf inmediately_precedes some CCO_P0000326;
OWL file <owl:Class rdf:about="ht p:/ www.cel cycleontology.org/ontology/owl CCO#CCO_B0000000"> <rdfs:label xml:lang="en">core cel cycle protein</rdfs:label> <oboInOwl:hasDefinition> <oboInOwl:Definition> <rdfs:label xml:lang="en">A protein </rdfs:label> <rdfs:subClassOf rdf:resource="ht p:/ www.cel cycleontology.org/ontology/owl/ CCO#CCO_U0000005"/> </owl:Class> OPPL APPLIC
ATION OPPL Instructions Provider (flat file parser)
Reasoner Instruction 1 Instruction 2 Instruction 3 Instruction 4 Instruction n
In the reference implementation, the OPPL application is executed command line: the path to the at le with the OPPL instructions to the OWL ontology are passed as arguments.
The cell cycle is the process by which a new cell comes into existence and divides into two cells, and all the steps in the middle. The cell cycle is a very important research eld of life sciences, as its malfunction is the cause of diseases such as cancer. The Cell Cycle Ontology gathers the current scienti c knowledge about the cell cycle. This system composes ve ontologies: an ontology for each considered model organism (H. sapiens, S. cerevisiae, S. pombe and A. thaliana) and a central ontology that includes the four ontologies plus relationships across proteins from the di erent model organisms. An automatic pipeline retrieves and manipulates data from di erent ontologies and databases that is nally included into the ontologies, thus, the ve ontologies are created anew each time the pipeline is executed.
OPPL is used to add new axioms to the CCO ontologies. OPPL has been chosen because it is very ine cient to manually add the axioms to ve newly created ontologies each time the pipeline is executed (they would be overwritten in the next execution) and may also be error prone. Therefore, OPPL at les have been devised with some new enriching axioms17 and the OPPL reference implementation is executed as part of the pipeline, adding the axioms to each newly created ontology (Fig. 3). The de ned axioms can be regarded as independent \modelling modules" or \modelling libraries" (e.g. Ontology Design Patterns18) to be applied or re-used.
Using OPPL in CCO also means that the design decisions become explicit (the rationale behind each added axiom is documented in the at les via comments) and exible (OPPL instructions with very complex semantics can be 17 ftp://ftp.psb.ugent.be/pub/cco/oppl/cco.oppl 18 http://odps.sourceforge.net tested and rejected/accepted by simply commenting/uncommenting lines on the OPPL at les). OPPL can also be used for querying; sample queries against CCO are stored in OPPL at les19 and executed via the OPPL reference implementation (Fig. 3).
The fact that OPPL instructions could be applied on demand has eased the development and maintenance of the Cell Cycle Ontology. CCO is automatically built monthly which implies that a careful maintenance policy is needed, not only for keeping suitable identi ers, but also for enriching the semantics via a prede ned set of OWL axioms. The implementation of that set of axioms as part of the CCO automatic building pipeline by means of OPPL has demonstrated many features of OPPL such as re-usability, modularity, and maintainability while dealing with huge and complex ontologies such as CCO. Currently, CCO has more than 54000 classes (more than 30000 proteins) which are connected by about 10 di erent types of properties resulting in a relatively highly connected network of concepts. Moreover, the le size of CCO composite ontology in OWL is over 90 MB which clearly suggests the need for a suitable tool like OPPL for modifying it automatically. 5
OPPL o ers a straight-forward syntax for manipulating OWL ontologies. Using OPPL ontologies can be manipulated in a repeatable manner (for example OPPL complex instructions can be shared amongst users), and complex modelling can be done in a one-step fashion (de ne the axioms once, apply many times); OPPL increases the e ciency of ontology maintenance and makes development time shorter. OPPL has been used in the development of the Cell Cycle Ontology and has demonstrated its utility.
In a near future, the development of a Protege plugin for enabling a userfriendly development with OPPL is expected, with functionalities such as autocomplete for writing OPPL instructions. In this way, the best of both paradigms (normal access through graphical interface and access through OPPL instructions) will be available in ontology development.
Regarding the syntax, role chains, data types and dataproperty support will be added. Regular expressions in class URIs will also be supported in the short term. In a longer term, a BNF grammar (once the syntax has become stable) and SWRL support are expected.
The provided OPPL Instruction Manager and reference implementation are licensed under the LGPL20. 19 ftp://ftp.psb.ugent.be/pub/cco/oppl/cco.query.oppl 20 http://www.gnu.org/licenses/lgpl.html
Mikel Egan~a is funded by the University of Manchester and EPSRC. Erick Antezana is funded by the European Science Foundation (ESF) for the activity entitled \Frontiers of Functional Genomics".