We present a technique for separating knowledge representation from application specific views that are currently often conflated within bio-ontologies. Many ontologies contain information for two tasks; one to represent the knowledge of some field of interest and another to support an application through providing views over ontologies that present the terms in a useful way for an application. We analyse this phenomenon in some bio-ontologies and suggest this separation of layers as a solution. We leave dedicated ontology languages like OWL and OBO to represent the knowledge of a field of interest, and use a more lightweight vocabulary, namely SKOS, to capture application specific views. We use this technique to encode a number of views inside the Experimental Factor Ontology. Each of these views serves a special purpose to different user communities; however, it does ensure the underlying ontology can remain for the annotation and integration of biological data. OWL and SKOS together provide a powerful, standards based, mechanism to reconstitute annotated biological data for many different application domains.
Bio-ontologies have become important in the life sciences through
their provision of identifiers for biomedical concepts that are defined
and managed by community processes
A significant use of bio-ontologies and annotations is to support the users of applications that wish to view, browse and search what can be complex and high-dimensional data. The key parts of bio-ontologies that support this form of use are the hierarchical structures formed by ‘is a’ and often ‘part of’ relationships between the concepts, as well as their labels and definitions. Applications use these components to drive a presentation that allows users to inspect annotated data using criteria (concepts) with which they are most familiar. The labels within the ontology support the interaction between the user and the interface; a simple ontology-driven autocomplete function in a search box can transform an opaque dataset into a useable life science application. The hierarchical structure of bio-ontologies enables query expansion—when querying with x we also retrieve x and all the children of x as described in the ontology (e.g. medline / mesh). Bio-ontologies often include other non-hierarchical relationships between concepts that are specific to their scope that can also help applications to guide users to data or content that is semantically related to their query.
Applications that use bio-ontologies and data annotations to drive their presentation are faced with knowledge representation and presentation issues. First, when faced with a large ontology, the proportion of concepts that are relevant to (the users of) an application will be low enough that it would detract from the usability of the application if all of the concepts in the vocabulary were exposed. Thus applications need a mechanism to indicate whether or not a particular concept should be available. Second, applications will often use concepts that cover multiple biological aspects of a dataset, intersecting parts of several existing vocabularies. In order to collect, manage and use the concepts relevant to an application, developers would often like to have an ontology that only contains those concepts in which they are interested, or else have a mechanism by which they can annotate the original ontology so that their application only processes the relevant content. In this paper we refer to these kinds of collections of concepts as a ‘view’.
We consider a view to be analogous to an ontology module, in that
the goal is to reuse a subset of concepts from an existing ontology
in a particular setting
The challenge for the developer is how to represent this information in line with existing standards and methods. Ideally, such annotations and mechanisms of annotation would also be available outside of a particular application.
In this paper we present an example of the above challenges
as faced by the iKUP Browser, a web application for querying
multi-omics data held in the Kidney and Urinary Pathway
Knowledgebase
The development of a kidney and urinary pathway knowledge base
clearly demonstrates the need for a separation of the applications
view of the ontology from the underlying knowledge representation.
The Kidney and Urinary Pathway Knowledge Base (KUPKB) is a
Semantic Web application being used by biologists in the study of
kidney disease
The KUPO and the ontologies it imports provides a rich underlying model for the KUPKB, where OWL semantics can be exploited for powerful query answering. In order to ask complex queries of the KUPKB, technical knowledge of the underlying ontologies, and Semantic Web query languages like SPARQL are needed. This kind of interaction is reserved for experts in the field, thus excluding a wide range of potential end users. To address this the iKUP browser (http://www.kupkb.org) was built to provide a user friendly interface to the KUPKB data. The iKUP browser uses the underlying ontologies to integrate and query the data. The ontological axioms allow for query expansion and the class hierarchies are exploited to provide faceted browsing of search results. However, the ontologies and their imports are not suitably organised for presentation in a user friendly interface such as the iKUP for several reasons:
Classes towards the top of the hierarchy are often sufficiently abstract that they have little meaning to the user. For example, upper level classes in the CTO such as ’cell in vivo’ and ’experimentally modified cell’ were not useful to iKUP users. Some ontologies provide too many levels of granularity. For example, the NCI taxonomy contains twelve intermediate categories between humans (taxied:9606) and mammals (taxid:40674), which are unnecessary to view in iKUP where users only require a simple classification of species.
Multiple concepts in the ontology may be suitable root concepts for navigational purposes. For example, cell type, disease, species, function are useful root concepts for navigation, but may not necessarily be default roots within an ontological context.
Concepts that a user might expect to be organised hierarchically do not have true parent/child relationships in the ontology. For example, displaying partonomy and developmental relationship as part of the class hierarchy.
In the case of iKUP, each of these issues were handled in the user interface code. User feedback was used to determine which concepts from the ontology should be presented. This approach proved difficult to maintain and also means the view logic is hidden in the iKUP code and cannot be exposed in other tools, such as Prote´ge´, outside of the iKUP applications.
To address some of these issues, the Open Biomedical Ontology
(OBO) community have adopted an annotation mechanism which
they use to generate subsets or ‘slims’ to mark up concepts in
the ontology that belong to a particular view. The Gene Ontology
provides slims of the ontology that are designed for specific
communities or applications. The GO slims give a broad overview
of the ontology content without the detail of the fine grained
concepts. They are useful in applications such as over expression
analysis
We have in the KUKPB a scenario where two tasks can be easily conflated: representing entities ontologicallly and also adding information that aids presentation, navigation and searching within the application setting. This suggests separating out these two needs into separate ontology layers and user layers. We have languages 1 http://ontodog.hegroup.org for the ontology layer, such as OWL and OBO format, that are widely used to author ontologies. However, a standard method for capturing this user layer is needed if we want to share these views between applications. This standard must meet the following basic requirements: 1. To identify one or more views within an ontology; 2. Assign concepts in the ontology to one or more of the internal views; 3. Assert semantic relationships between concepts in the ontology that provide alternative navigational paths around the ontology; 4. Assert anchors in the ontology that indicate root concepts for presentation.
We propose that the W3C Simple Knowledge Organisation System (SKOS) provides a minimal model for capturing these views within an OWL ontology. Unlike OWL, the emphasis of SKOS is not so much on the formal (logical or ontological) representation of the information, but instead provides a schema in which concepts can be organized in a lightweight fashion for concept schemes, cataloguing, indexing and information retrieval tasks. SKOS models concepts as instances of one OWL class - skos:Concept. By modelling concepts as instances rather than classes, SKOS shifts the knowledge representation strategy to a different meta-level. SKOS provides hierarchical properties in broader and narrower, as well as the non-hierarchical related property. These semantic relationship lack any formal definition, however, their semantics are sufficiently defined by the W3C in order for applications to make assumptions on how they should be interpreted computationally. One of the major advantages of SKOS is that it provides a significant amount of support for describing the annotation components of an ontology, including labels, definitions and multiple languages, major desirable components of most biomedical ontologies. Although SKOS concepts cannot be (logically) defined as extensively as OWL classes, they can be (usefully) described just as well for most user-facing applications.
One of the major improvements of OWL2 was the removal of the constraint that a named OWL entity must be assigned one ’role’ in an ontology. This ’punning’ strategy means that it is now permitted to specify, for example, that an entity is both an OWL class and also an individual - thereby introducing a basic meta-modelling capability into the Semantic Web suite of specifications. Figure 1 illustrates how we can use meta-modelling to make assertions between classes in our ontology. In the way that we described OWL and SKOS above, it initially seems that they are mutually exclusive, different interpretations of the same thing. Infact we can exploit OWL2 punning to integrate both types of representation into one. We can keep the formal axiomatic view as an OWL ontology and by punning specify a set of SKOS concepts that happen to have the same name. In doing this, we can now start to refer to the SKOS individual representations of concepts in a vocabulary as if they were items in a dataset rather than defined entities as part of a formal theory.
SKOS also provides one other key modelling component when we are considering views: the concept scheme. A concept scheme is an entity to which SKOS concepts can be mapped with the skos:inScheme property. It can be used as a way of grouping together a set of concepts, and the annotation of the concept scheme can be used to add a description of why those concepts are part of that concept scheme. We can define anchors within our views using the skos:topConceptOf property. skos:topConceptOf can be used to assert that a particular concept should be viewed at the root of a particular concept scheme.
This ability to do some meta-modelling in OWL allows us to use the SKOS vocabulary to make additional assertions on our ontology. SKOS can be used to index concepts in our ontology, and to define alternate navigational hierarchies around the ontology. These SKOS ”views” are not intended as a replacement for the OWL, but rather an extension to the underlying knowledge representation that supports the application setting. Capturing this information using a standard vocabulary like SKOS means we can begin to exploit generic SKOS tooling to support how the views are created, maintained and used. SKOS can satisfy our previous requirements as follows: 1. For requirement one, we use the skos:ConceptScheme to represent a particular view within an ontology 2. For requirement two, for each class that is to be included in the view from the ontology, we add them as an instance of skos:Concept. These concepts can then be associated to a particular view, i.e. the skos:ConceptScheme via the skos:inScheme property. 3. For requirement three we use a combination of SKOS broader, narrow and related properties to provide the appropriate structure to the view. 4. For requirement four we use the skos:hasTopConcept property to assert that particular concepts are anchors, or root concepts in a particular view. 3
To demonstrate the technique we attempt to extract a subset of
views that are encoded with the Experimental Factor Ontology
(EFO). The EFO is an application ontology developed to describe
experimental variables used in transcriptomics data
In constructing the EFO application ontology several expedient representational compromises were made. EFO includes two annotation properties that are used as ‘flags’ to indicate that a class should be either hidden from view in the application or that it should be used as an anchor, i.e. a starting point at which to begin browsing the hierarchy. Hidden flags are often used on classes such as upper level ontology classes such as those from the basic formal ontology (BFO), which are alien to a biologist user. Anchor flags are used on classes such as cell line and disease, these indicate common starting points of interest to users navigating the ontology in an application scenario.
New applications adopting the approach of EFO, such as the Genome Wide Association Study (GWAS) browser 2 and the European Nucleotide Archive (ENA) 3 each require subsets of classes within EFO, but viewed in bespoke ways to suit their application needs. We have, therefore, a situation where two tasks have been conflated in the EFO: representing entities in transcriptomics experiments and also adding information that aids presentation, navigation and searching within the application setting. In order to avoid duplicating and minting of new terms to serve specific application requirements, these additional views are embedded within the ontology using both logical OWL axioms and specialised annotation properties. To demonstrate the applicability of SKOS we extracted three separate views from the EFO OWL file and represented them in SKOS. We then show how these views can be visualised alongside the original EFO ontology using a generic SKOS tool called SKOSEd. 3.1
We converted the various views in EFO to SKOS using bespoke scripts that extract the views based on existing annotations and convert them into SKOS concept schemes. These scripts are written with the Java OWL API (version 3) and SKOS API (version 3). These views are available to download from BioPortal under the EFO ”views” section. These views can be views in any valid SKOS aware application. The Prote´ge´ 4.1 4 SKOSEd plugin 5 was used to view and evaluate the SKOS conversions.
For each view we follow the basic pattern:
Classify EFO with the HermiT 6 reasoner
All classes that are flagged as organisational classes are discarded All classes flagged as part of a the current view are converted to SKOS Concepts and added to the Concept Scheme. As the same URI is used for Class and Concept, all annotations such as labels are preserved.
All superclasses of the flagged classes up to hidden organisational classes are added as skos:broader assertion (corresponding skos:narrower assertions are also added Any classes flagged as branch or anchor classes are asserted as top concepts using skos:hasTopConcept in the current concept scheme Any flagged properties are mapped to SKOS semantic relationship. If a property is mapped to a skos relationship then class restrictions along the mapped property get translated to the appropriate skos relationship e.g. If part of is mapped to skos:broader then (subClassOf (X, part of some Y) becomes (X skos:broader Y).
The first view extracted is the EFO basic view. This view is currently used to serve both the ArrayExpress and gene expression atlas query expansion and results summary view applications. In this conversion all classes apart from organisation classes were converted for the view. Additionally, the part of relationship was mapped to skos:broader in order to incorporate the partonomy views into the concept hierarchy.
The second view represents a view generated for the GWAS catalogue terms. By capturing our view in a standard language like SKOS we can begin to exploit existing SKOS aware tools to visualise the GWAS view in EFO for the first time. Figure 2 shows a portion of the GWAS viewed in the generic SKOSEd extension for Prote´ge´, no special configuration was required for this view to be exposed. The terms present in this view are selected by GWAS annotators for the annotation of studies submitted to the GWAS catalogue. These terms are currently used to populate a drop down list, but will soon form part of a more sophisticated information retrieval system. Only classes flagged as ”gwas” and their parent classes were converted to SKOS concepts; all organisation classes were ignored.
The third view represents a subset of terms from the European Nucleotide Archive (ENA) 7. These terms are used to annotate submission to the ENA, these annotations are used to describe submitted datasets which are used by other databases, such as ArrayExpress. The ENA currently only requires few terms and have little in the way of hierarchy. They have their own categories for terms, these categories have no natural place within EFO. In the case of ENA we define some additional concepts within our view in order to categorise some of the terms from EFO for the ENA application. 4
Bio-ontologies are primarily used to represent domain knowledge from areas of interest to the community, however, the application of such ontologies to data and data providing services is of increasing importance. In the case of applications, we need to separate the concerns of knowledge representation and user presentation—a classic software engineering approach. We leave the ontology as an ontology (in OWL or OBO format) and capture application knowledge in a SKOS representation, a simple transformation which is suited to the needs of an application or for local problem solving. Such a separation also means we can have different application specific user layers for the same knowledge layer or
ontology, without undermining ongoing work to make domain ontologies interoperable.
The problems encountered developing applications around the KUPO and EFO highlight a scenario that will emerge many times over as more bioinformatics tools move to exploiting ontologies in user facing applications. Whilst other similar patterns may emerge, the approach outlined in the paper demonstrates how aligning to a standard vocabulary language like SKOS allows us to exploit existing infrastructure. The views extracted from EFO allow the application developers to visualise the application views in ways that were not previously possible in standard ontology editing environments. SKOS provides one means to share these views across communities and applications, and is an attractive solution for the scenarios outlined in this paper. 5
The SKOS vocabulary has some adoption in the life science ontologies—in particular the labelling and mapping properties. However, the notion of concept schemes and semantic relationships have been less well adopted, and these are components that fulfil our requirements. By taking standard approaches we allow existing tools that consume SKOS access to the terminological information of bio-ontologies. There is now a need for better tool support to enable life scientists to work with SKOS more easily. This paper demonstrates how separating the concerns of knowledge representation and user presentation into layers and adopting standards such as SKOS offers new possibilities for data sharing and re-use.
AG is supported by the BioRange programme of The Netherlands Bioinformatics Centre (NBIC; http://www.nbic.nl), supported by a BSIK grant through The Netherlands Genomics Initiative (NGI) and the research programme of the Netherlands Consortium for Systems Biology (NCSB), which is part of the Netherlands Genomics Initiative/Netherlands Organization for Scientific Research. We acknowledge funds from EMBL (JM, HP) and The National Center for Biomedical Ontology, one of the National Centers for Biomedical Computing supported by the NHGRI, the NHLBI, and the NIH Common Fund under grant U54-HG004028 (SJ).