1 of 33

Reusing tools and infrastructure from OWL ontologies in KGs

Chris Mungall

DRAFT/Request for Comments

dc:created: 2020-12-09

​

2 of 33

OBO is a success

  • Shared datamodel/serialization: OWL
  • Common tooling: ROBOT
    • Mix and match
    • QC/reasoning
    • Ontology construction
    • Much more
  • Common registry and metadata: OBO
  • Community of portals
  • Interoperation, reuse
  • Towards a common upper ontology
  • Decent amount of common mindshare
  • Community

3 of 33

What is the scope of OBO?

Original vision (Ashburner/Lewis):

‘Database’ World

‘Ontology’ World (OBO)

descriptor

Named entity

described by

Many of these ‘databases’ are actually knowledgebases (MODs, Uniprot, ENSEMBL, biogrid, …)

‘flat’

hierarchical

gene

protein

allele

Clinical trial

person

4 of 33

What is the scope of OBO?

View from ‘philosophical realism’

Instances

Classes (OBO)

class

instance

type

Anything that can be instantiated

Any instance (tracked or not)

Can be relatively ‘flat’

gene

protein

allele

Clinical trial

person

5 of 33

Challenge: there are many possible OWL classes

​

Drugs 10k

Chemicals 4tn?

Species

~9 million

Diseases and

Phenotypes

10-50k/species

Cells

scSeq revealing huge numbers of clusters

Many other omics entities

?? exabytes

Genes 65bn in IMG/M

Also: exons, introns, enhancers, transcripts, base pairs, …., ...

​

Genetic variants

3m in human alone

​

6 of 33

Challenge: there are many possible OWL classes

  • Many ‘database entities’ represented repeatable entities
    • Mostly molecular: Genes, proteins, exons, base pairs, pathways, small molecules, complexes, …
    • Also: diseases, taxa
    • For want of a better term: Database Entities as Classes (DEaC)
  • Realist perspective:
    • No problem. These are all classes
  • Pragmatist perspective:
    • The technical solutions we have built for ontology classes won’t scale to billions of classes
      • IMG database at LBNL has > 60bn distinct microbial genes
    • We already struggle with the sizes of:
      • PRO (even though it represents a tiny fraction of protein space)
      • NCBITaxon (big yet still not sufficient for many microbial use cases)
      • CHEBI (tiny fraction of chemical space)
    • Why make it an ontology if it’s just a huge flat list???

7 of 33

Challenge: who owns the DEaC ontological rendering?

  • Most ontologies: not claiming an existing databases space
    • Thought often ‘affiliated’: MP<=>MGI; GO<=>Curated gene/protein DBs
  • Existing DEaCs are kind of OK:
    • PRO: the team were already the authorities (but still complexities re uniprot)
    • NCBITaxon: we just went ahead and squatted this. Bad us. 100% automated translation. We decided the rules/axiomatization unilaterally. No one has complained too loudly.
    • CHEBI: they are authorities, it is already a ‘database’ anyway
  • What are the OBO rules if:
    • Random person auto-translates all ENSEMBL GFF to classes, mints class PURLs for genes, transcripts, exons, CDSs, base pairs, families, … plus relationships
    • Do we allow into OBO?
    • If not, why not?
    • If we allow, what happens if someone does the same for NCBI? (‘same’ entities different IDs)
    • What if source database has a different translation? [we already have this: uniprot rdf vs PRO]

8 of 33

Challenge: ontologies injecting axioms into DEaCs

Many bioinformatics databases consist of relationships between DEs

  • E.g. a PPI database will reuse e.g. uniprot, ensembl IDs, and link these
  • Ditto for say gene-gene homology. Also ‘annotation’ databases (e.g. HPOA)

What happens if:

  • I submit my ‘ontology’ of PPIs or homologies to OBO?
  • Let’s say I use PRO PURLs and ‘inject’ axioms
  • Say I choose a reciprocal existential pattern:
    • P1 SubClassOf (has-disposition some (realized-by interaction and has-participant some P2)))
    • There are many other possibilities...

​

​

9 of 33

Challenge: ontologies injecting axioms into DEaCs

What happens if:

  • I submit my 100% automated translation ‘ontology’ of PPIs to OBO?
    • Say I use PRO PURLs and inject axioms into them
  • I choose a reciprocal existential pattern:
    • PR:P1 SubClassOf (has-disposition some (realized-by interaction and has-participant some PR:P2)))

Is this OK?

  • Is this useful? Scalable? Can OBO take terabyte files?
  • Do the OBO principles remotely apply?
  • What if someone else has an alternate translation?
  • Who owns the PPI space in OBO? First come first served? What does PRO say?

​

​

​

10 of 33

What about ABox axiomatizations

Alternate PPI ABox representation:

[a PR:P1] ro:interacts-with [a PR:P2]

Could also be seen as a ‘some-some’ TBox axiom

If the all-some TBox PPI ontology is fair game for OBO, what about the some-some?

11 of 33

Opinion: OWL is a difficult language for large semantic databases

  • Just because OWL TBoxes are philosophically justified for many omics databases/knowledgebases it doesn’t mean it’s the most practical
    • Forces ontological commitment that creates churn/conflict for no reason
    • OWL stack is not designed for big data
  • Poor ROI in reasoning compared to ‘true’ ontologies
    • Exceptions: GO-CAM ABox
  • Multiple things suck
    • E.g. RDF reification used in RDF* but OWLAPI silently loses RDF reification

12 of 33

Is any (semantic) data warehouse fair game?

Long history of data warehouses, e.g bioMART, InterMine

‘Semantic data warehouses’:

  • Bio2rdf
  • Monarch

Some reuse existing PURLs

Most inject links

Are these ‘ontologies’?

13 of 33

What would the PURLs look like?

Options

  • Make ‘shadow’ OBO PURLs (we did for NCBITaxon)?
  • If born semantic (e.g. uniprot)
    • Use their PURLs
    • But what about differences in ontological commitment?
  • Else

14 of 33

identifiers.org

  • 4 distinct IRIs for each ID
    • http[s]://identifiers.org/DATABASE{/,:}LOCALID
  • Use in PRO
    • Uses identifiers.org for HGNC (but not MODs)
    • ​

15 of 33

PRO

16 of 33

CL

17 of 33

Paths forward

Proposal A: Extend OBO (infrastructure, QC, principles, community, tools)

Proposal B: Make a parallel to OBO for this kind of thing

​

Could be a hybrid (we already have ‘A’ e.g. for NCBITaxon)

18 of 33

Proposal A: extend OBO

  • Allow any number of TBoxifications of databases into OBO
  • Create specific guidelines/principles pertinent to these
    • Ownership of DEaC PURLs + ‘buy in’ of source database (who don’t care about OWL)
    • Ownership of injected axioms
    • Orthogonality: relax? Multiple flowers blooming?
    • Axiom patterns (e.g. using dispositions to avoid untrue axioms)
    • Rules for synchronicity etc
  • Clearly separate these on the website
  • Make ROBOT scale to ‘ontologies’ that may be terabytes in size

Question:

  • Is OWL (and particularly TBoxes) the optimal representation for large omics databases?
    • OWLAPI in particular not scalable

19 of 33

What would this look like on the OBO site?

List 1:

  • Pretty much the current list, minus a few ‘application ontologies’

List 2:

  • Application ontologies? + databases translated to OWL
    • Chembl.owl (how does it related to CHEBI)?
    • Chris’ ppi.owl (munging biogrid, string, GO, .. using uniprot PURLs)
    • Darren’s ppi-pr.owl (using PRO IDs, subset, rich TBox axioms)
    • Nico’s homologous-genes.owl (auto-translation of panther)
    • Alliance’s homologous-genes.owl (auto-translation of diopt, which is itself a warehouse)
    • Potentially 1000s more… all of bio2rdf?
  • Some browsers choose not to load these to avoid scale issues
  • Robot handles list 2 differently?

​

20 of 33

What would scaling ROBOT look like

  • Adding bindings to the OWLAPI to scalable datastores
    • OWLAPI is already so complex….
    • BASF funding this for Neo4j?
  • Bypass the OWLAPI
    • We sometimes do this anyway, using Jena more directly? E.g robot query and tdb
    • James’ experiments with sqlite
    • General trend: E.g. GO minerva
    • Pros: OWLAPI is actually bad for when RDF is the appropriate level of abstraction (particularly RDF*); see https://github.com/ontodev/robot/issues/785
    • Cons: RDF is poor level of abstraction for ‘complex’ TBoxes (even simple existentials are confusing)
  • But is even working in a non-OWLAPI Jena environment scalable enough
  • At what stage is this a rewrite?
  • Is it really worth it for things that are not really ‘ontologies’

21 of 33

Additional concern: ontological commitment

Source databases don’t make ontological commitments

There could be multiple alternate class or instance interpretations of each ID in source database

E..g if you ask MGI you will get different answers about whether an ID represents a gene, a gene product, a database record, ...

See this proposal: https://docs.google.com/document/d/1TvOERSc8rO8yXGFbnLvJjRHy6kApkvG3Gv98sLj43TE/edit

Scientific linked data web and PURLs for bioentities

22 of 33

Proposal B: make on OBO analog for ‘KGs’

This is essentially what we have been evolving towards

  • Formalism: ‘KG’/PGs or plain RDF, not direct OWL
  • Instead of OBO registry: KG hub concept
  • Instead of COB: Biolink-model
  • Instead of ROBOT:
    • https://github.com/biolink/kgx kgx cli tool

Question:

  • Is this bad? Competing? Duplicative?

23 of 33

Example: PPIs in KG-COVID-19

  • We represent each interaction as an edge
    • Annotated with provenance, also properties like strength
      • <<P1 interacts-with P2>> provided_by StringDB: ; ...
    • Defer on OWL TBox semantics (also potentially ABox some-some representation)
  • We use UniProtKB IDs as node IDs
  • In theory there could be many PPI ‘spokes’ in KG-Hub
    • Different databases: STRING, IntAct, BioGrid; derived from GO etc
    • Different representations
    • This is OK! Consumers can select, merge

24 of 33

Example: drugs and small molecules

  • Automatic translation of DrugBank, DrugCentral, ...

25 of 33

Biolink model

TODO link to Deepak presentation

Predates COB

Should eventually align

Different concerns:

  • Property graph model where edges are central
  • it’s a datamodel. Closed world constraint checking
    • e.g. a gene must have exactly 1 symbol
    • A gene to phenotype association has at most one severity modifier
  • Instance of biolink classes may be OBO classes

26 of 33

KG-Hub

Mostly a concept so far

https://github.com/Knowledge-Graph-Hub

Developing

  • Monarch KG
  • KG-COVID-19
  • KG-Microbe

​

27 of 33

KGX CLI: tool for working with KG files

  • Originally a converter for property-graphs in Translator
  • Bindings to Neo4j (most groups in NCATS using this at the time)
  • Also: merge, then validation (according to closed-world schema)

Differences to ROBOT

  • Not based on OWLAPI
    • Design to work with fast scalable graph libraries
    • No need for complex TBox axioms; ontologies serialized as owlstar
  • Native formalism is a LPG (roughly: RDF*)
  • Python
    • Exploring rust bindings for native graph representation (ensmallen)

28 of 33

Downside: duplication in functionality w ROBOT

29 of 33

Downside: duplication

subset/extract is a common use case for KGs. We often need a fraction of a source as KG

  • subset of chembl relevant to covid
  • Subset of ncbitaxon for kg-microbe

ROBOT provides extract (MIREOT or SLME). Given seed set (all IDs referenced) extract a covering set

  • For KGs we want a graph walk startegy
  • (actually robot may want this too)

30 of 33

Downside: duplication

31 of 33

Another option: Yet Another Tool to Rule Them All

Ugh. Feels like groundhog day. Not keen but laying it out here

Not possible without dedicated funding

But hypothetically it could be done

  • Python for maximal developer uptake
  • Fast stuff in rust
  • Bindings for multiple databases: sql, graph dbs, triplestores, redis graph, …
  • JVM bridge for connection to reasoners
  • Funowl python lib (Harold Solbrig)
  • Unification of:
    • Robot, ontopilot, kgx, kltg, ….

32 of 33

Summary

  • OWL stack doesn’t work well with large databases
  • Implicit assumption: ontology TBoxes are small. SNOMED is considered ‘large’, but really it’s tiny compared to bio KBs
  • OBO has implicit assumptions (maybe not universally shared) about what an ‘ontology’ is
    • Most(?) would balk at an ontology of nucleotides, where each base pair in every genomes gets a class PURL, even though this is completely justified under OBO realism
    • Most(?) would balk at an ontology submitted to OBO of gene homologies for every single gene in NCBI
  • Do we try and reuse or make a separate stack for working with ontologies that are translations of databases?
    • Reuse is good… But hard if initial requirements don’t fit
    • Is it worth it for things that are only questionably ‘ontologies’ anyway?

33 of 33

My proposal: B (parallel stacks) - If it ain’t broke don’t fix it

​

ROBOT is great, OBO is great

Don’t try and overload the concept of ontology in the name of realism

Keep OBOs small within pragmatic limits

For big ontologies make defined subsets that are what usually gets imported anyway

We have some duplication but I think it’s OK

There are some unknowns but that’s OK

E.g I think a future CHEBI should cover all chemical entities. I don’t know if this is database world or ontology world