Request for CHIRO prefix

[nicolevasilevsky]

Prefix requested: chiro Ontology title: CHEBI Integrated Role Ontology Home page: https://github.com/cmungall/chiro Contact: Nicole Vasilevsky, vasilevs@ohsu.edu, GitHub: nicolevasilevsky Tracker link: https://github.com/cmungall/chiro/issues

Description: CHEBI provides a distinct role hierarchy. Chemicals in the structural hierarchy are connected via a 'has role' relation. CHIRO provides links from these roles to useful other classes in other ontologies. This will allow direct connection between chemical structures (small molecules, drugs) and what they do. This could be formalized using 'capable of', in the same way Uberon and the Cell Ontology link structures to processes.

[bpeters42]

Sorry for the late follow up. We are working on defining clearer criteria for handling purl requests. As we had discussed with @cmungall and @jannahastings, it would be great to have a open, central effort, directly coordinated with Chebi that deals with this additional axiomatization. We should also involve gowen@ebi.ac.uk which we hope is: @G-Owen

Two other questions are:

Intended Use: Is your ontology serving the need of one or more specific projects? If so, please describe them. The OBO Foundry policy on documented users is described at http://obofoundry.org/principles/fp-009-users.html.

Data Source: Which resource, if any, was used to generate the ontology (e.g., NCBITaxon was created from the NCBI taxonomy resource; the Protein Ontology uses, in part, UniProtKB).

[cmungall]

Yes, we would love to do this with CHEBI (note when we contacted them previously they had no resources to be involved).

Projects:

• Two separate teams in the NCATS Translator project want to use this. One is my team (orange), the other is green. @cbizon can tell you more about the green use case
• We use this in the Monarch knowledge graph in order to provide navigable links from diseases and phenotypes and related chemical entities
• We will use this for our new project as part of the Illuminating the Druggable Genome project, where we will use this to influence embeddings of chemical nodes using word2vec style approaches, and then using neural networks to make link predictions.

To satisfy these use cases, we could host CHIRO via an alternate system such as w3id, but this would cause us a bit of churn. But I also think it would make the axiomatization effort less visible to the OBO world, and we want people to see this and contribute. If it were in OBO then it would be navigable from CHEBI nodes in ontobee (note that this is a nice feature of ontobee, you can see others axiomatizations about your entities), it would be accessible from a unified RDF triplestore architecture. I am also hoping we can improve metadata in OBO so that it's easier to see who is referencing who's ontology. Ideally this reference graph would involve no remote injection, but if that injection is happening I think it is best to be maximally transparent about it!

I would advocate for registering as a distinct ID space in OBO. Of course, as soon as the axioms can be folded into some kind of official CHEBI release using a CHEBI base purl, we would obsolete CHIRO. I'd hope this would be soon but in the interim we need to get some infrastructure up to start using it.

Note that another use case for this ontology is simply the fact that I strongly believe that entities in OBO should be axiomatized, this has massive advantages for formally stating meaning, consistency checking (both within an ontology and across OBO), automated classification, and navigation across concepts. Ideally providers of ontologies provide that axiomatization (and do it prospectively rather than retrospectively) but for various reasons that hasn't always panned out, and in these cases a 3rd party axiomatization (sanctioned by the source, rather than injecting without permission) is useful.

Data Source: Which resource, if any, was used to generate the ontology (e.g., NCBITaxon was created from the NCBI taxonomy resource; the Protein Ontology uses, in part, UniProtKB).

This question looks like it applies to automated translation of databases to ontologies. All of the axioms in CHIRO are manually created and maintained (I may have seeded some with NLP years ago, but I am not involved in continued maintenance, @nicolevasilevsky does the editing). The referenced entities are CHEBI (axiom subjects) and multiple OBOs (axiom objects).

[bpeters42]

My personal belief is that if the intention is to disolve this effort if ChEBI becomes responsive again, that is sufficient enough reason to grant the PURL request.

It also reveals a glaring omission: We do not currently have a process to remove ontologies such as Chebi from the 'foundry' category, even though they are clearly not responsive to user requests, and violate any number of OBO principles. How that is dealt with is a different subject matter, but in my mind, we should not hold this back.

[cmungall]

+1 from everyone on OBO operations call 2019-09-24

[nicolevasilevsky]

Great! What are next steps? Should I create a PR to create a page on the OBO Foundry site?

[matentzn]

We can do it quickly during our meeting today.

[nicolevasilevsky]

Nico and I created a PR: https://github.com/OBOFoundry/OBOFoundry.github.io/pull/1062

[pbuttigieg]

Hi @nicolevasilevsky @cmungall - is this request handled? We're trying to clear up outstanding issues by our next OBO Ops call in two weeks

[nicolevasilevsky]

Yes, I think so! I see Chiro on the OBO Foundry page. I think this can be closed.