Ontology structure

OntoTrek reads, parses and visualizes an OWL ontology file directly, either from an example selection of OBO Foundry ontology files that sit in OntoTrek’s data folder, or by dynamically fetching one from a user-provided URL. This allows new or in-development ontologies to be viewed. OntoTrek renders class-subclass relations starting from parent-less entities (e.g. owl:Thing or “entity”, from BFO). Many OWL ontologies explicitly use the single owl:Thing “root node” as the top class/node of an umbrella-shaped tree. An ontology can have other top level nodes which have no superclass connection to owl:Thing explicitly stated. OntoTrek shows these (including bfo:Entity) as “stand alone” nodes, disconnected from owl:Thing.

If a class has multiple superclasses, only the first one listed (as an owl:subClassOf parent node) will be used in the hierarchy. As well, OntoTrek doesn’t render other kinds of relations that axioms reference, nor will it show classes which only appear in axioms and not in the class hierarchy. OntoTrek’s design objective is primarily to focus on an informative display of the class hierarchy itself; we have not embarked on the very careful work required to display other kinds of relations in a limited / local way that does not overwhelm the visual interface. One can foresee an object-centric display involving the engineering of templates, each focusing on an ontology term class that represents a type of object, and edges emanating from it to other objects and data properties as required by relevant axioms.

The visible structure drawn must be largely deterministic, placing nodes consistently in the same region relative to each other on each fresh generation of the visualization, thus keeping the location of terms consistent. Most force graph algorithms can be set to be deterministic, and OntoTrek uses 3d-force-graph this way. If an ontology is loaded into OntoTrek, and its class structure is identical to a previous loading, then its visual structure will be identical. Of course, modifications to an ontology’s class structure likely result in visual changes over time, sometimes radically, depending on how high up the hierarchy that term additions or deletions occur. A few strategies described below ameliorate this inconsistency.

OntoTrek allows an upper-level ontology (such as BFO 2.1’s 34 terms) to have nodes whose positions are fixed (so-called “pinned” nodes), such that a force-directed algorithm which is positioning underlying nodes (classes of other subordinate ontologies) iterates from that fixed upper-level node constellation. This is key to providing a recognizable and semantically relevant layout from the summit of the term landscape, in which for example one branch or pole from the root node holds upper level ontology continuants or endurants, and another holds occurants or perdurants, and so on. Consequently, even high-level restructuring of underlying ontology hierarchies doesn’t radically change the shape of the overall visualization. A configuration file (the “/js/lookup_tables.json” layout object) holds pinned nodes, which are automatically referenced by any loaded ontology.

Ontology rendering

At least one rendered view should reflect an ontology’s stated or inferred class hierarchy, so there can be a “top” and a “bottom” in 3D space for aligning this hierarchy in. Navigation through the viewport should give visual clues as to where the “top” is, and it should be easy to reestablish an “up” perspective on ontology contents after navigating around them from any orientation. OntoTrek orients each top-level node’s hierarchy in the viewport in the same vertical direction. The depth of a node from its root(s) is apparent by placing nodes of a given degree of depth (n = 1,2,3, …) in a correspondingly deep horizontal plane, yielding a stratified appearance. Top level terms—which OntoTrek’s demo ontologies often refer to—represent upper level ontology terms of the Basic Formal Ontology, and are given a larger size, enabling them to be discerned while substantially zoomed-out from the graph. A bright yellow color also enhances their visibility, and pinning provides stability.

For most ontologies listed in the Search tab’s pulldown list menu, performance of the initial force graph rendering phase would be slower if done from scratch, but these ontologies are assisted by a cache file containing the coordinates of a previous graph rendering.

Force graph solutions often encounter problems with an initial state of (pseudo)randomly positioned nodes and connecting edges which undergo the force algorithm’s attraction and repulsion kinetics. With larger node count, “ostracised” nodes are often trapped in territory that their long edges can’t contract them out of. The OntoTrek solution is, starting with the root node(s), to dynamically add generations of child nodes as the algorithm runs, allowing it to settle on the positions of each generation before advancing to the next, which encourages the local positioning of primary subclass nodes. Subsequent generations are spawned on lower tiers pseudo-randomly with respect to their parents. The algorithm basically builds mountains of terms from the top-down, with lower-tier nodes pulling away from each other to help reduce density in the hierarchy, while pinned top level nodes ensure that underlying nodes follow the same topology.

The consistent color coding of term nodes is key to illustrating the interconnectedness of 3rd party ontologies. A lookup table assigns colors to most of OBO Foundry’s ontology prefixes so that any of an ontology’s nodes receives the same color, enabling easier visual recognition, although ontology term reuse can involve upwards of 30 prefixes and their colors (for example, OBI, the Ontology for Biomedical Investigations, imports terms having over 20 different prefixes [7]).

Increased foreground detail, including textual legibility, enables us to navigate to places in the hierarchy visually according to other cues besides text. The 3D landscape also allows structure to be “stored” in plain view at scale, which is a kind of data compression as long as some user memory of its content is accessible, which currently is achieved by mouseover identification of distant node entities. Currently we present only the matched entity label on that event, but this could be modified to show a node’s upper level ontology category or content as a summary view.

OntoTrek actually has a hybrid 3D and 2D view, available by toggling the “Underlying ontology branches rendered as vertical slice(s)” setting, which illustrates benefits of both combined by showing an upper level ontology in 3D, and underlying ontologies in vertical planes of 2D hierarchies. This option provides a fly-through view that separates out the labels which is quite effective with a medium sized ontology like AGRO or GenEpiO. The algorithm, like the general 3D one, could be improved to add more space to lower level nodes and their labels.

Term labels and synonyms can be searched in the OntoTrek interface (specifically on the side bar, in the Term Search and Term Context boxes in Fig 1) in order to locate and travel to the term node of interest. A pull-down list of all terms available in the ontology is given, but this also contains the usability feature that as one types, both term label and synonyms can be searched, so that ‘dog’, though not present in the label, will return term ‘Cannis lupus familiaris’. This enables people to use colloquial vocabulary to access information a formal ontology can provide. A matching term is displayed along with its parent(s) and children, and its definition and ontology lookup service links for OntoBee.org and EMBL-EBI Ontology Lookup Service shown in Fig 1. Clicking on a node link or dashboard “children” menu selection triggers a focus on the child node.

Download:

• PPT
  PowerPoint slide
• PNG
  larger image
• TIFF
  original image

Fig 1. Example of the user interface of Ontotrek while selecting the AGRO term “conflagration”.

Here we demonstrate the dashboard which presents the term definition as well as ontology service lookup links.

https://doi.org/10.1371/journal.pone.0286728.g001

There are a few Settings tab options that can improve rendering performance. These should be turned on or off before starting to render a selected ontology.

1. Show labels: By default, OntoTrek renders both a node label, AND a semi-transparent background box slightly behind it, to help with legibility. This feature is costly, but it can be turned off with the “Show labels” toggle.
2. Show a wireframe view: By default, OntoTrek renders heavier edges the higher up one goes in the hierarchy, with lower level edges past a certain depth having just 1 unit of thickness, which doesn’t invoke polygon rendering. This option sets edges to have the fastest 1 unit of thickness for any edge, aside from the top-level ontology ones, which are untouched. (This option also eliminates transparency on the default labels shown with “Show labels” set to true).
3. Render from top down to this node depth: This option allows display of only upper levels of more massive ontologies if desired.
4. Show deprecated terms: By default deprecated terms are hidden from display to reduce clutter for ontologies that include these terms as parent-less top-level nodes.

Users can rotate, zoom, or pan the display. Clicking on any node in the Ontotrek viewport causes the node to be highlighted in red, and also triggers a transition animation that moves the viewport camera perspective to an angled view close to and above the node. This built-in force-graph-3d feature is problematic because the “rollercoaster” transition animation doesn’t keep the viewport itself oriented vertically, so it is up to a user to try to realign the view after the transition has finished.

OntoTrek is hosted at http://genepio.org/ontotrek/. A user guide is provided at https://github.com/cidgoh/ontotrek/wiki. Users can also build and run OntoTrek on their own computer. OntoTrek source code is available at https://github.com/cidgoh/ontotrek.