We present Populous, a tool for gathering content with which to populate an ontology. Domain experts need to add content, that is often repetitive in its form, but without having to tackle the underlying ontological representation. Populous presents users with a table based form in which columns are constrained to take values from particular ontologies; the user can select a concept from an ontology via its meaningful label to give a value for a given entity attribute. Populated tables are mapped to patterns that can then be used to automatically generate the ontology's content. Populous's contribution is in the knowledge gathering stage of ontology development. It separates knowledge gathering from the conceptualisation and also separates the user from the standard ontology authoring environments. As a result, Populous can allow knowledge to be gathered in a straight-forward manner that can then be used to do mass production of ontology content.
Ontologies are being developed to provide controlled vocabularies for the
annotation of life science data. Annotating data with ontologies adds semantics to
the data that can facilitate data integration and enrich data analysis[
When designing an ontology it is often the case that repeating patterns occur
in the modelling. These patterns can be abstracted from the ontology and used to
specify simple templates that could be populated by domain experts [
The tabular layout provides a simple and intuitive form fill-in style of user interface for a user to populate such templates. Typically, each row corresponds to a set of related entities and each column represents the type of relationship. The intersection of row and column holds the ‘filler’ for the given entity’s relationship of that column’s type. By adopting templates ontology developers can separate the pattern from its population; this allows the domain expert to focus on the knowledge without the distraction of the knowledge representation language.
Templates are useful when data needs to be collected in a regular form. Applying constraints to the template reduces the amount of discrepancies in the input data. A common tool for collecting data in this form is the spreadsheet; spreadsheets provide a tabular interface, where columns and rows represent certain attributes, and individual cells capture the data. Tables help users to structure data in a logical way, that is useful for both its maintenance and processing. In ontology development spreadsheets can be used to gather and organise information about concepts and their relationships. Previous work in this area has focused on the transformation of data into ontologies, but little attention has been paid to supporting the population of the templates at the point of data entry and this is where Populous’s main contribution lies. 1.1
Previous work
Various tools are available to support the conversion of spreadsheet data into
statements in a knowledge representation language. Excel2RDF3, Convert2RDF4
and RDF123 [
The ExcelImporter plugin5 for Prot´eg´e 4.0 was a step up from these tools
and enabled users to transform spreadsheets content directly into OWL axioms.
It was, however, limited to only a small set of OWL constructs. The more
recent tools to support template data and pattern instantiation include Mapping
Master [
Requirements All of the previous tools developed in this area tend to focus on the transformation from the template to the ontology. They provide little or no support for populating and validating template content. Furthermore, tools like ExcelImporter, OPPL and MappingMaster are integrated into the ontology development tool, so they are aimed at users that are already familiar with ontology development. A table based tool for ontology authoring should shield the user from the underlying ontology and help guide the user when populating the template. Providing validation at the time of authorship should significantly reduce the amount of time required to debug and process the data captured in the spreadsheet. Here we list some key requirements for an ontology based table editor: 1. Concepts may be described in terms of other concepts from other ontologies.
In setting up Populous the users must be able to load and browse ontologies. 2. The contents in the column of a table need to be restricted to concepts from imported ontologies, or parts of imported ontologies. 3. To improve human comprehension the concept should be rendered using only the URI fragment, or optionally a human readable label from the ontology. 4. Each time a concept is added to a cell within the table Populous needs to check that the concept is valid according to the constraints resulting from requirement 2. 5. A cell might have multiple values; for example, when the concept being described has multiple parts. 6. Users should be free to suggest new concepts when an appropriate concept is not available. 2
Populous
Populous is an extension of RightField[21]; RightField is for creating Excel
documents that contain ontology based restrictions on spreadsheets content.
RightField enables users to upload Excel spreadsheets, along with ontologies from
their local file systems, or from the BioPortal [
Requirement 1 is already addressed using RightField functionality to upload both OWL and OBO ontologies. In order to better serve the life science community, users can also browse and load ontologies directly from BioPortal. Once the ontologies are loaded they are classified by a reasoner and the basic class hierarchy can be viewed.
Requirement 2 is met by the ability to select terms from the ontology to create validation sets. A data validation restricts the set of values that are valid for a particular cell in the table. Validations can span multiple rows and columns and be composed of classes, properties or individuals from the ontology. These data validations are stored in hidden worksheets along with additional information such as the full URI for the term, a label and the source ontology URI. These templates can also be exported as Microsoft Excel documents, which include the data validations on cells.
We address requirement 3 by allowing users to populate cells using ontology labels. Once data has been entered the default will be to render the ontology term using its label; if no label is specified the URI fragment is used. RightField 7 http://poi.apache.org already supports reading Microsoft Excel workbooks so users are free to populate the templates in external tools before importing them into Populous for validation and transformation.
By using Populous directly users will benefit from having instant validation of the input data, satisfying requirement 4, along with some advanced features such as regular expression based auto-completion as they type into annotated cells. Additionally Populous supports the addition of multiple values into a single cell that are validated individually according to requirement 5. This can be particularly useful for certain kinds of patterns where a conjunction of variables is required to construct the axiom (see Section 3 for example). Populous also allows the addition of free text values, even if the cell has an associated validation range, thus satisfying requirement 6. These values are highlighted to the user in red and can act as placeholders for new or suggested terms when no suitable candidate could be found in the validation set.
Populous supports the use of OPPL patterns in order to generate new OWL axioms from the populated template. OPPL scripts can be written directly in Populous’s design mode or imported from scripts generated in the OPPL plugin. Variables from the OPPL pattern must be mapped to columns from the table using the column name. A pattern Wizard guides the user through the generation and execution of the OPPL scripts. When the template is processed new identifiers for unknown terms can be auto-generated and exported from Populous.
We can demonstrate Populous in building a simple ontology about cell types
as described in Section 1. The pattern in the ontology states that every cell must
have a nucleation. We need to create a template with two columns, column A
is for cell type concepts, whilst column B is for nucleation concepts. Ontologies
describing cells and their nucleation already exist that we can import into
Populous. By connecting to BioPortal we can load the Cell Type Ontology (CTO) [
Figure 2 shows a part populated template. The terms in green indicate a valid term has been entered into the cell. The term in Column A5, Proximal tubule epithelial cell is red because it is not a valid term from the CTO. Cell A6 is in the process of being edited with the auto-completer offering valid suggestion for input.
The populated spreadsheet can now be transformed into an ontology. This can be done using the pattern wizard in Populous (Figure 3). The first step in the pattern wizard asks the user to select the columns and rows that contain populated data. In this example the pattern creates a restriction on each cell stating that all cells have a relationship, called hasNucleation, to an instance of the class nucleation. This pattern can be expressed in OPPL 2 with the syntax shown in Figure 4. ?cell:CLASS, ?nucleation:CLASS BEGIN ADD ?cell SubClassOf hasNucleation some ?nucleation END;
There are two variables in the pattern, ?cell and ?nucleation. These
variable are mapped to column A and B respectively. The pattern is to be
instantiated using data from rows one to six that must be specified in the Wizard. The
next step involves validating the pattern, given that Proximal tubule epithelial
cell is unknown by the validator, the user is given the option to assign a new
URI for this concept. The final step generated the full OPPL script for applying
this pattern. The Manchester OWL syntax generated for row one is shown in
Figure 5. A complete grammar for the OPPL 2 syntax is available here8.
8 http://oppl2.sourceforge.net
Class: cto:CL 0000113
SubClassOf:
hasNucleation some pato:PATO 0001407
In order to evaluate Populous in a real ontology building scenario, it has been
used to populate a template for gathering knowledge about the kidney and
urinary system. The kidney is a complex organ composed of several distinct
anatomical compartments that together enable the filtration of waste from the blood
in the form of urine. Each of the kidney compartments is formed from a wide
variety of cell types, and the specificity of the compartments relies on these
specialised cell functions. The Kidney and Urinary Pathway Ontology (KUPO) [
A simple template was designed for experts from the KUP domain to capture
the relationships between cell types, their anatomical location and their
biological functions. The template has three main columns; column A is for entering
cell type terms, column C is for anatomy terms and column D for biological
process terms. Populous was used to constrain the allowable values in columns A, C
and D to concepts from the Open Biomedical Ontology Cell Type Ontology [
In order to transform the tabular data into an OWL representation the OPPL
pattern in Figure 7 was created by the ontology engineers. This pattern states
that a cell type is equivalent to a cell that is part of an anatomy term and a
subclass of cells that participate in biological processes.10 For both restrictions
the existential (some) quantification is used. The two differentia in this pattern
for a cell genus are the anatomical location and the biological process, which
is retrieved from column A, B and C respectively in the template. The entire
KUP ontology is generated from the template data combined with the ontology
9 http://www.e-lico.eu/kupkb
10 Where possible we use the relationships from [
Using this template approach the domain experts described over 140 cell types, many of which are absent from the current CTO. Figure 9 shows the inferred hierarchy after classifying the ontology in Prot´eg´e 4.0. Note the asserted class hierarchy is simply a flat list of cell types, the partonomy of the mouse anatomy is used to drive inferences about super/sub class relationships between cell types. Leaving the reasoner to compute the class hierarchy allows the domain experts to inspect the ontology for missing or incorrect inferences. These often indicate some missing information in the template, or an error in the imported ontologies. This methodology was successful in engaging the domain experts to both contribute to the KUP ontology and generate new term requests for the imported ontologies. 4
Discussion Populous is designed for domain experts to gather knowledge that can be subsequently used to populate ontologies. Whilst previous tools have provided support for transforming templates into ontologies, they lacked basic support to help the user at the point of data entry. Populous was designed to fill this niche and meet the requirements outlined in section 1. The simple tabular interface used Pattern 1 ?cell:CLASS, ?anatomyPart:CLASS, ?partOfRestriction:CLASS = cell and part of some ?anatomyPart, ?anatomyIntersection:CLASS = createIntersection(?partOfRestriction.VALUES) BEGIN ADD ?cell equivalentTo ?anatomyIntersection END; Pattern 2 ?participant:CLASS, ?participatesRestriction:CLASS = ?cell and participates in some ?participant, ?participatesIntersection:CLASS = createIntersection(?participatesRestriction.VALUES) BEGIN ADD ?cell SubClassOf ?participatesIntersection END; in Populous is familiar to users who have already used a spreadsheet application. Populous should lower the entry requirements for domain experts to contribute to ontology development projects.
The release of Populous as presented is an early version; there remains many possible additions, some of which are: 1. Populous can handle multiple values in a cell that maps to conjunctions of properties. Extensions to Populous such that some minor syntax can be used to extend the ability to use OWL’s syntax would be useful. In particular, being able to specify numbers for cardinality and numbers and other literals for datatype properties. 2. As already described, Populous uses a row centric model. We aim to use M2 to enable more variety in how tables are mapped to templates or patterns. For example, only portions of columns may be required to be mapped to certain axiom patterns and M2 enables this sort of mapping. OPPL and M2 together should cover our mapping needs. 3. Populous currently gathers domain knowledge for the ontology, but not about the ontology. We aim to extend Populous to support various metadata such as editorial metadata and definitional metadata etc. 4. Populous is a single user application. Making Populous collaborative such that contributors may collectively add material to the same spreadsheet. 5. Feedback from the generated ontology to fix or extend data in Populous is currently ad hoc. A tighter coupling of this feedback cycle, without having to go into an axiom based editor, will increase the quality assurance aspects of Populous.
We have demonstrated how Populous can be used to develop an ontology describing cells of the kidney and urinary pathway system. This demonstration highlights how domain experts managed to generate a real application ontology without being exposed to an ontology language like OWL, or a tool like Prot´eg´e. Populous’s main purpose is for knowledge gathering and not ontologising. By shielded users from the ontology, except for review later in the process, they are left to concentrate on the biology and not worry about the axioms needed to represent it. This separation is particularly useful should the ontologist wish to change the conceptualisation or experiment with different patterns for the representation.
Our experience in developing the KUPO with domain experts provided
interesting insights into the benefits of developing an ontology in this way. Classical
approaches to ontology development in the life science have tended to focus on
building rich asserted hierarchies of concepts. The KUPO approach exploits the
expressiveness of an ontology language like OWL to describe the cells in such a
way that the class hierarchy is computed by the reasoner. This means we have
a logical explanation for all the subsumptions in the hierarchy, that is useful
for spotting erroneous or missing information. For example, there are cell types
for the vasa recta descending limb and the vasa recta ascending limb, both of
which have different functions. The imported anatomy ontology, however, only
describes a vasa recta. The domain experts were able to spot this and can now
submit a request for these two new concepts to be added to the anatomy
ontology. Building normalised ontologies that facilitate the kinds of inferences we
see in KUPO are generally considered to be harder and more time consuming
than constructing class hierarchies manually, despite offering a clear benefit [
The question now arises as to how far can you go with a tool like Populous? Populous is by no means a replacement for full blown ontology editors, nor is it intended to be. The scenarios where Populous is of benefit assume that the ontology being developed has repeating patterns in the modelling. Furthermore, specifying the patterns for new ontologies before they exist is particularly difficult and is often something that emerges later as the ontology matures. For example, it was assumed with the kidney cells that we could describe them all in terms of their anatomy, only to later find some exceptions to the pattern. Renal principal and renal intercalated cells are currently indistinguishable by anatomy and function alone. There are always going to be exceptions, especially when modelling a complex domain like biology. We hope that Populous can bring more domain experts into the ontology development process and engage them in the development process.
The template approach can be particularly advantageous in scenarios where
the modelling needs to change. [
OPPL provides an expressive language for generating OWL patterns. OPPL’s support for variables make mapping single columns from tabular data to variables convenient. The built in macros means we can create abstract pattern where the axioms can be generated dynamically depending on the number of values stored in a variable. Populous is currently limited to working with uniform spreadsheets and assumes a row-per-entity paradigm, where single columns map to a particular variable. This structure keeps the template simple and should cover the majority of use cases for populating an ontology in this way. The extension to support multi-values per cell offers some additional flexibility over existing spreadsheet based approaches. In order to accommodate more complex spreadsheets we plan to extend Populous to support more complex mappings from columns to spreadsheets. We are also exploring integrating the M2 language from MappingMaster directly into Populous, we note that templates created in Populous can already be exported as Excel document and loaded into MappingMaster for transformation should the user desire.
Populous offers a means of creating ontology content without the use of a standard ontology development tool. Just as data-entry tools exist for populating databases, so we also need such tools for populating ontologies. It is possible to separate knowledge gathering from conceptualisation and axiomatisation and Populous is one means of achieving this goal. Such a separation offers flexibility and simple form fill-in style of knowledge gathering that should make generation of axiomatically rich ontologies increasingly straight-forward.
Acknowledgements: We kindly acknowledge Mikel Egan˜a Aranguren for advice, requirements and testing Populous. This work is funded by the e-LICO project—EU/FP7/ICT-2007.4.4 and by SysMO-DB - BBSRC grant BBG0102181. 20. The Gene Ontology Consortium. Gene Ontology: Tool for the Unification of Biology. Nature Genetics, 25:25–29, 2000. 21. Katy Wolstencroft, Stuart Owen, Matthew Horridge, Olga Krebs, Wolfgang Mueller, and Carole Goble. RightField: Rich Annotation of Experimental Biology Through Stealth Using Spreadsheets. In Proceedings of the 7th Microsoft eScience Workshop, pages 117–119., Berkeley, California, 2010.