Ontologies in BioCypher

[jdreo]

BioCypher relies on loading several RDF ontology files to build up a configurable taxonomy. That's kind of a killer feature, compared to its competitors.

Ontologies

Ontologies are complex beasts, with a lot of (layers of) standards and approaches. OWL (one of the most successful standards) alone provides several "flavors" with subtle differences. OWL is somehow compatible with RDFSchema, but not completely, and it depends on which flavor. Biolink claims to "inherit features" from OWL, but is not fully compatible with it, having a slightly different model for associations. And so on and so forth.

So far, BioCypher only really uses the taxonomy part of ontologies, does not consider the axioms that come with it and does not enforce one specific modeling approach (apart from having nodes, edges, and properties).

Why Ontologies?

The classical rationale behind the use of ontologies in biological applications is that they provide two interesting things:

1. A common vocabulary, with words (and descriptions) carefully chosen to be as unambiguous as possible, and following the definitions of the field experts.
2. A modeling approach (that is how to represent the information) that's appropriate for the domain needs.

As both features are difficult to come up with for a naive user, expert-made ontologies should be welcomed as ready-to-use jackknife for any applications in a given field.

Drawbacks

However, several people are starting to question this premise. Having played with knowledge graphs (KG) to solve a couple of real problems, it seems that some drawbacks are met:

1. Ontologies often come from the idea that it is possible to "model the whole world" with a single tool.
2. Modeling the whole world is insanely complex, and leads to the use of the need to model atomic pieces of information. One ends with classes for the tiniest possible information, aggregated into sub-graphs that represent an object of interest, across several layers (similar to the composition over inheritance approach in object-oriented modeling). This, in turn, generates two issues:
   1. The taxonomy, being split into several (sub)trees, is shallow. And that is a problem when the end user issues queries on the KG, because they cannot leverage a sound type hierarchy to refine/generalize their search.
   2. Experts are ahead of their time. And access to actual data is difficult. Thus there is no single application where it is possible to fill in all the atomic pieces of the model. The resulting graph is very sparse, and it is hard to fill in the (intermediate) nodes for which we have no data, but that are nonetheless at a crucial location in the model.
3. Ontologies may be so detailed that it is difficult to make them scale if one has large datasets.
4. And scaling reasoners is even more difficult.
5. Finally, ontologies that would be made with an application in mind, will not fit another one.

These considerations have led some people to think that we'd be better of with building up simple taxonomies for KGs, without bothering with ontologies.

Advantages

However, ontologies also come with some advantages:

1. The common vocabulary is useful to integrate data from several sources.
2. An ontology made by an expert in modeling may very well scale easily regarding the application. In any given application, it is often the case that one starts with a simple question, and then evolves to reach more complex ones. Modeling is hard and often requires a lot of refactoring iterations to scale with the increasing complexity of the questions. In a sense, a modeling expert knows that, and probably has proposed a model that, while seeming complex at first, allows scaling.
3. Axioms bring information into the model:
   1. By providing constraints such as domains and ranges, they help understand the modeling approach and are a useful tool for debugging the use of the taxonomy.
   2. By providing logical predicates on the model, they allow reasoners to fill in missing data, a task that would sometimes require large efforts if it was to be done explicitly during the KG building step (àla BioCypher).
4. Last, but not least, designing an ontology (even just a vocabulary) is a task that already comes with tooling from several communities. Betting on yet another fancy new simpler approach would reduce the toolset available, and thus adds more frictions. And probably the "simpler" approach would end following the same path than ontologies in terms of scaling anyway.

Ontologies in BioCypher

BioCypher imposes some constraints on the input ontology, which prevents it from being able to use any ontology in the wild (see this discussion). However, it is still possible to export in self-contained populated RDF files (see that discussion).

The emphasis that Biocypher puts on assembling taxonomy trees shows that the initial thoughts were related to leveraging deep type hierarchies. I guess to allow for versatile queries on the produced KG.

But I think that BioCypher could —with a bit of refactoring— allow for two additional features:

1. Use the type axioms to double-check that edges are used the way the model intends.
2. Use reasoners to add missing pieces of information on the fly. Probably not feasible for very large uses-cases, if the reasoner needs to have everything in-memory, but some features (e.g. symmetric edges creation) are definitely possible.

BioCypher already has a complete internal representation of the ontology it uses, thanks to rdflib, and thus already knows axioms. One just has to use them.

Additionally, I would advocate for decoupling all the ontology manipulation steps. So far, BioCypher only rearranges the input taxonomies in a single tree. But it would be possible to propose more fixes on existing ontologies, to allow for their use. By having a clearly identified (albeit optional) step, it would be possible to have more control on what an advanced user could do, hence allowing for better scaling on modeling issues (e.g. automatically allowing for an OWL input using object properties as edges).

[slobentanzer]

Fully agree, thank you @jdreo! What you outline was part of the roadmap from the beginning, but seemed very complex, so has taken a backseat. Particularly the reasoning in the backend has been around since inception (https://github.com/biocypher/biocypher/milestone/5), inspired by the issues we have in integrating several related ontologies that are used side-by-side with no clear synchronisation (e.g., the multiple disease ontologies in play). Symmetric completion or propagation of properties are a recurring topic, but very hard to solve (not that that would stop me, but we need to find the time / priority).

I would like to evaluate which of the suggestions are relatively quick to implement and which could take ages, and draw that up against the resulting benefits. I feel what you say about decoupling and IRI handling can indeed be done quite quickly; the reasoning probably less so. About intended use I am not sure, I have not used that feature of ontologies yet.