Why predicates are important¶

This notebook is intended as an explanatory guide to the importance of edge types (predicates) in ontologies.

Citric acid and its ion forms¶

For this guide, we are going to look at citric acid and it's conjugate forms such as citrate(3-). These chemical entities are very similar and in fact are readily interchangeable in cells.

Biologists and biochemists may talk of "citric acid" and "citrate" interchangeably.

We can see the corresponding CHEBI entries:

Citric acid¶

CHEBI:30769

Citrate(3-)¶

CHEBI:16947

Accessing CHEBI through OAK¶

There are different ways to access CHEBI, we will use the sqlite adapter. See also part 7 of the tutorial.

We will use the selector sqlite:obo:chebi to access CHEBI.

We will be using the command line interface via Jupyter for this tutortial, but the equivalent operations can be done via Python.

First we will set up a Jupyter alias.

If we wanted to do the equivalen on the command line, we would do:

alias chebi="runoak -i sqlite:obo:chebi"

Basic lookup¶

Next we will do some basic lookup. The first time you run this may take some time, as the sqlite file is downloaded. Subsequent operations will be faster.

Term metadata¶

To check we have the right term, let's look at all of the CHEBI metadata, including mappings and chemical formulae:

We can do the same thing for the same chemical in a different protonation state, citrate(3-):

Computing similarity¶

There are various ways to measure chemical similarity.

Here we are using an ontology library, not a chemical library like RDKit, so we can measure similarity with respect to their shared parentage.

We will use the similarity command that measures semantic similarity.

Like many OAK operations, it is parameterized by a predicates option. For example:

• --predicates rdfs:subClassOf

This can be shortened to:

• -p i

This instructs OAK to use only the is-a relationship when computing parentage.

Note that many libraries don't provide any option here, and only allow is-a relationships

The similarity command takes two term lists separated by @ - here we just want to do a simple pairwise comparison, we specify one term either side:

What is this telling us?

• the jaccard similarity is 0.25, which is very low
• the most recent common ancestor is the very general and abstract sounding heteroatomic molecular entity, which has a low information content of 1.8

Why is the score so low?

Remember at the start of this guide we looked at the chemical structures, which are almost identical. And biologically these are interchangeable. Why is the similarity so low?

Investigating ontological oddities is one of the strengths of OAK. We can take a number of different approaches, but the easiest is to start by just visualizing the terms and their ancestors:

As can be seen, the is-a graphs of these two terms are almost completely separated. You have to go all the way up to heteroatomic molecular entity to find the common ancestor, just like the similarity output told us.

So what's going on?¶

So what's going on here? is there something missing from CHEBI?

In fact, CHEBI is like this by design, and we see the same pattern/template repeated for all acids.

But all is not lost, CHEBI has other relationships we can use here.

Which leads us to one of the main lessons when using ontologies:

Always make use of the full range of edge types¶

CHEBI has many other edge types we can use here.

Currently OAK doesn't have a quick way of summarizing edge statistics, but we can do this easily with a SQL query on the sqlite database we downloaded earlier, querying the Edge table:

CHEBI mostly uses it's own relationship types, and a few from RO, we can query what these are:

Next let's try again, using the viz command, but this time adding a different predicate.

We can specify a list of predicates separated by , with the --predicates option on most commands:

This time the terms are much closer together. However, they are not "next" to each other, which brings us to another lesson:

Number of hops is often meaningless with ontologies¶

A common metric with graph operations is counting number of hops. However, for knowledge graphs, this metric can be misleading or meaningless. It may be tempting to do something like "weighting" predicates but this is always ad-hoc.

With ontologies, predicates have meaning and we want this to be take into account.

Calculating similarity using all predicates¶

In OAK the default is usually to use all predicates

Thus if we simply ask for the overall similarity between citric acid and the 3- form, i.e via:

This is much better than before, reflecting the true biochemical similarity between these.

• The jaccard similarity is 0.65, still not great
• the MRCA is the more meaningful citrate anion which has a higher IC of 12.88

So how did OAK calculate this?

Here OAK made use of all edge types in the CHEBI relation graph. This is in contrast to many methods that only make use of is-a relationships. This might be a good baked in assumption if you are only doing similarity on HPO (but even then it can be limiting).

For other ontologies, we need to make use of other predicates.

At this stage you may be thinking: "Ah! All ontologies are DAGs, so OAK is using the CHEBI DAG here!"

This brings us to our next point

Ontologies are not DAGs¶

This is a common misconception. Ontologies are not DAGs, no matter what you may have previously heard.

And in general avoid baking in assumptions generalized from a few cases when it comes to ontologies

Often ontologies will be released in a form that is guaranteed to be a DAG because so many tools mistakenly assume an ontology is a DAG. But if you are using one of these dumbed down forms of an ontology you are missing useful information.

Let's take a look at CHEBI again. This time we will use two different relationship types (predicates), and exclude is-a:

This is definitely not a DAG.

In fact there is no reason to assume that for an ontology or a knowledge graph the structure will be a DAG. A lot of relationships in real life are inherently cyclic, and this definitely holds for chemistry, we have cyclic structures and cyclic relationships, and chemicals cycle through these different protonation states.

So how do we handle these?¶

At this point you might be thinking it makes no sense to use measures like semantic similarity over cyclic graphs. Or that it may be necessary to include ad-hoc measures like maximim distance. But this isn't the case

Because ontology graphs are existential graphs over concepts, where the existence of the subject depends on the existence of the object, you can still use algorithms designed with concepts of "ancestors" and "descendants". The overall structure of the relation graph will still (in general) follow a pattern of narrowing down to more general concepts.

There are two broad approaches:

1. naive graph walking, with cycle checks
2. use the relation graph

The first is trivial to implement, just implement traversal as you normally would, but remove the assumption of acyclicity.

The OAK sqlite adapter uses the 2nd approach, making use of relation graph

Relation Graph¶

Relation graph is a tool for calculating the closure of ontology relationships. Unlike naive graph walking, it takes into account the semantics of the ontology and of predicates as intended by the producers of these ontologies

More formally, RG materializes the entailment of all SubClassOf axioms, including those axioms that have existential restrictions on the right hand side.

Relation graph can be obtained and installed from its github repo.

SemSQL Builds have relation-graph pre-computed¶

If you access an ontology via the sqlite method, it will make use of an ontology loaded in using the SemSQL schema, which has relation-graph precomputed.

We can take a look first at the CL

The OAK relationships command will query all relationships (by default "outgoing") for an entity.

If you pass in --include-entailed it will include entailed (inferred by reasoner) relationships, here coming from RG:

The size of a RG can be large so we will explore it with pandas:

These are all guaranteed correct (according to the semantics of classes and object properties in the ontology)

They are not guaranteed useful. There are many trivial edges, eg.

• every astrocyte is part of some material entity
• every astrocyte is a subtype of a continuant

But these less useful ones will "fall out in the wash" when we use them in methods like semantic similarity

We can query the EntailedEdge table more directly:

OAK uses Relation Graph in semantic similarity¶

The OAK SQL backend will use RG when calculating semantic similarity.

• there is no need to worry whether the structure is a DAG or a tree
• no need to implement "hops" or ad-hoc mechanisms

All semantic similarity measures then become trivial operations on RG, parameterizable by a semantic predicate

• Jaccard is simply the intersection of common ancestors in the RG divided by the union of ancestors
• MRCA, IC etc work as expected

Relation Graph is only as good as its inputs¶

Garbage in, Garbage out

• if ontologies include false axioms, RG will give false results
• if ontologies are incomplete, RG will give incomplete answers

Usually for most ontologies we care about in a project like Monarch, we have decent QC in place, and in general most methods should be resilient to this.