Request for new ontology OBCI

[nataled]

Title

Ontology for Biomarkers of Clinical Interest

Short Description

The Ontology for Biomarkers of Clinical Interest (OBCI) formally defines biomarkers for diseases, phenotypes, and effects.

Description

OBCI is a reference ontology for biomarkers that formalizes biomarker-centric knowledge (terms, definitions, synonyms) under a unified framework, enriched with objects imported from related reference ontologies and designed to aid clinicians seeking to identify biomarkers useful to their purpose. Construction of OBCI observes recommendations concerning accurate formal representation of biomarkers as proposed by the FDA-NIH Biomarker Working Group and in accordance with the principles of the Open Biomedical and Biological Ontologies (OBO) Foundry to ensure ontological rigor and interoperability.

Identifier Space

OBCI

License

CC-BY 4.0

Domain

health

Source Code Repository

https://github.com/clinical-biomarkers/OBCI

Homepage

https://github.com/clinical-biomarkers/OBCI

Issue Tracker

https://github.com/clinical-biomarkers/OBCI/issues

Contribution Guidelines

https://github.com/clinical-biomarkers/OBCI/blob/main/CONTRIBUTING.md

Ontology Download Link

https://proteininformationresource.org/staff/nataled/OBCI/obci.owl

Contact Name

Darren A. Natale

Contact Email

[email protected]

Contact GitHub Username

nataled

Contact ORCID Identifier

0000-0001-5809-9523

Formats

• OWL RDF/XML (.owl)
• OBO (.obo)
• OBO Graph JSON (.json)

Dependencies

• chebi
• cido
• cl
• doid
• ecto
• gno
• go
• iao
• ncbitaxon
• ncit
• pato
• pr
• ro
• so
• uberon

Related

There is currently no active OBO Foundry ontology that covers the same domain. There is, however, a newly-submitted ontology (BMONT) that is being considered for inclusion, and we are aware of at least one other group developing a biomarker ontology. We have looked at BMONT and determined that the approach taken by the developers is inconsistent with our approach. It can best be described as an application ontology (it makes use of axiom injection). OBCI is purely a reference ontology. Indeed, by our criteria, BMONT contains mostly what we term 'biomarker assessed entities', nearly all of which (in OBCI) are imported terms. Thus, OBCI could not fit under the umbrella of BMONT without radically changing that ontology. It is unclear as yet how OBCI and the other not-yet-submitted ontology relate in terms of scope or approach, but our two groups will be initiating discussions in the near future.

Usages

No response

Intended Use Cases and/or Related Projects

The NIH CFDE funded BiomarkerKB (https://glygen.ccrc.uga.edu/frontend/home/) was built using early versions of OBCI as a guide for approach and organization. In turn, OBCI will largely--but not solely--ontologically represent many of the biomarkers collected there.

Data Sources

The main definition source for upper level terms in OBCI is the FDA-NIH Biomarker Working Group (see NCBI:books/NBK402285 and PMID:29405771). Many of the specific biomarkers in OBCI will derive from the collected data found in the aforementioned BiomarkerKB.

Additional comments or remarks

• Approach: Many current and previous treatments of biomarkers use the term 'biomarker' to refer to what we call an 'assessed entity'. For example, some particular gene would be called a biomarker for some disease if a perturbation of the gene (such as a sequence variant) is found to cause or correlate with that disease. Thus, one often sees 'BRCA1' called a biomarker. This is not the case in OBCI. Instead, the presence of the variant is a biomarker, or overexpression of the gene is a biomarker (after all, everyone has a copy of some form of 'BRCA1'). Another example is 'blood sugar'. By itself, 'blood sugar' is not a biomarker--its level above or below normal (for an individual, or using a population average) is what indicates some condition of interest.
• Reasoning: OBCI was built to take extensive advantage of reasoning for proper placement of terms within the hierarchy. We recommend the Hermit reasoner for this purpose.
• Relations: It is possible that there are relations proposed here that have existing analogs elsewhere, or that can be composed using property chains. We are partway through the process of identifying these and will make additional replacements as necessary. Any relations not covered elsewhere will be submitted to the Relations Ontology.
• Repository: Ultimately the ontology will be available via GitHub. For now, however, it is publicly available in a folder managed by the submitter.
• ID space registration: In anticipation of this submission, we submitted this prefix to the Bioregistry already: https://bioregistry.io/registry/obci. It later came to our attention that this is not the preferred method, but mentioning it here because the existing Bioregistry term is NOT a different resource, it is this ontology being submitted.
• Axiom injection: There is a single case of axiom injection, on an NCIt term ("Expired air"). There are currently no terms in UBERON that represent the same entity. There are, however, two related terms in UBERON ("bodily gas" and "air in respiratory system"), but the definitions of those terms rule out their use for our case. We will be requesting addition of the needed term (likely to be termed "exhaled breath") and will replace the NCIt term with the new one upon its availability.
• Scope: While it is very likely that many of the biomarker terms pertain to humans, this is not a taxonomic restriction. That is, biomarkers pertinent to the clinical care of animals are in scope. Markers that identify foods (such as presented in FOBI) are not in scope.
• COB alignment: It is likely that the best upper level term for this ontology will be COB:characteristic. However, we have not made that assertion for two reasons: 1) COB:characteristic is not yet defined; 2) as COB is greatly in flux, there is a possibility that another upper level term will be a better fit; and 3) for the initial visualization we have left 'biomarker' as the top term.
• Top level term: We have it as 'biomarker' since that is the official terminology of the FDA-NIH Biomarker Working Group. However, we would be willing to change it to something like 'clinical biomarker' if other types of entities are commonly called 'biomarkers'. However, to our knowledge, that term is already restricted solely to the clinical domain.

OBO Foundry Pre-registration Checklist

• I have read and understood the registration process instructions and the registration checklist.
• There is no other ontology in the OBO Foundry which would be an appropriate place for my terms. If there were, I have contacted the editors, and we decided in mutual agreement that a separate ontology is more appropriate.
• My ontology has a specific release file with a version IRI and a dc:license annotation, serialised in RDF/XML.
• My identifiers (classes and properties IRIs) are formatted according to the OBO Foundry Identifier Policy
• My term labels are in English and conform to the OBO Foundry Naming Conventions
• I understand that term definitions are key to understanding the intentions of a term, especially when the ontology is used in curation. I made sure that a reasonable majority of terms in my ontology--and all top level terms--have definitions, in English, using the IAO:0000115 property.
• For every term in my ontology, I checked whether another OBO Foundry ontology has one with the same meaning. If so, I re-used that term directly (not by cross-reference, by directly using the IRI).
• For all relationship properties (Object and Data Property), I checked whether the Relation Ontology (RO) includes an appropriate one. I understand that aligning with RO is an essential part of the overall alignment between OBO ontologies!
• For the selection of appropriate annotation properties, I looked at OMO first. I understand that aligning ontology metadata and term-level metadata is essential for cross-integration of OBO ontologies.
• If I was not sure about the meaning of any of the checkboxes above, I have consulted with a member of the OBO Foundry for advice, e.g., through the obo-discuss Google Group.
• The requested ID space does not conflict with another ID space found in other registries such as the Bioregistry and BioPortal, see here for a complete list.

[pfabry]

@nataled OBCI is in the NOR dashboard. Is there a plan to bring the owl file to the github? We could discuss the reviewer at the next OFOC call.

[nataled]

@pfabry that's the hope at least. We need a better indication of how large OBCI might get, as I'm aware of size limitations for github (I already cannot have the Protein Ontology there for that reason). I believe I'll have a better assessment of potential size within the next few months.

[nataled]

@pfabry I checked the NOR results and it appears there was some processing error on my part that caused a duplication of term identifiers. I fixed that and have re-uploaded a new version for testing.

[nataled]

I have made a few updates and reviewed various errors. To ensure that the version that will be reviewed will be the same as the version tested, I will not upload a new version prior to review, so this update is just for information.

• Four of the previously-undefined relations have now been defined, leaving four relations (OBCI:100000008, OBCI:100000013, OBCI:100000014, OBCI:100000018) and three classes (OBCI:000000075, OBCI:000000077, OBCI:000000078) yet to be defined. All of the undefined classes are leaf nodes.
• Not assessed by ROBOT, but there are four relations (OBCI:100000011, OBCI:100000012, OBCI:100000014, OBCI:100000018) that are not in RO and also do not map to a RO parent. I suspect two of them *might have* suitable RO replacements, but I am unsure enough about it that I prefer to address them possibly in an upcoming RO call.
• The INFO cases are all of the 'missing superclass' type. Only one of these--the OBCI top level term--is actually missing a parent term (for reasons given in an earlier comment). All the rest have parent terms indicated via an 'intersectionOf' assertion and will thus have a parent indicated as 'subClassOf' only after reasoning is applied. It is unclear to me why ROBOT (and other ontology tools) fail to recognize these as legitimate parents without reasoning first.
• The one term with axiom injection ('Expired air', from NCIt) has been requested of UBERON as 'exhaled breath'. There actually was that precise term requested previously by another user (exhaled breath (what is collected during a breath test) obophenotype/uberon#2863), so I added my thoughts on the request in hopes that it will move forward. If accepted, there will be no need for any axiom injection in OBCI.

[pfabry]

@balhoff has been assigned to review this ontology.

[cmungall]

What's the relationship to terms in OBA? Cc @matentzn

[nataled]

@cmungall currently no relation. It is possible that some terms in OBCI could be composed using terms from OBA. For example, one possible biomarker could be something like elevated blood glucose, which could refer to the OBA term 'blood glucose amount'. A potential complication for doing so is the way that OBA terms are defined. Continuing with the above example, 'blood glucose amount' is equivalent to:
amount
and ('characteristic of' some
(glucose
and ('part of' some blood)))

instead of something more direct like:
amount_of some (glucose and part_of some blood)

So it is unclear to me how that extra layer would be interpreted in the context of biomarkers. I suspect it reflects the difference between a biomarker (a perturbation away from whatever is normal for a given person) and a phenotype (the normal for a given person).

[cmungall]

yes, OBA=traits (e.g. blood glucose amount), phenotypes (e.g. elevated blood glucose) would go in HP/MP/etc for species specific, upheno for species-neutral

[nataled]

I think you mean that hyperglycemia would go in a phenotype ontology. Elevated blood glucose is one biomarker of that condition.

[matentzn]

From the uPheno perspective, this is how things are separated:

1. Phenotypic characteristics (weight, height, amount) live in PATO
2. Biological traits (body weight, glucose level in blood, increased rate of cell division) live in OBA
3. Phenotypic effects (abnormal glucose level in blood, increased glucose level in blood) live in uPheno (which includes HPO and MP etc). Hyperglycemia is a phenotype in HPO, and synonymous with elevated blood glucose level (or "high" blood glucose level).
4. Diseases are special kinds of "phenotype data" as they are strongly associated with sets of phenotypes (aka phenotypic profiles).

We have never quite thought the "biomarker" problem all the way to the very end. So far, biomarker for us is mostly a role that a phenotype takes in a certain context; Hyperglycemia would be one such phenotype that could play the role of biomarker.

If you are interested, read up on our way of thinking on phenotype here (our recent course on phenotype data). Relevant docs:

• Basic phenotype data model (this describes which phenotype concept lives in which ontology)
• Different kind of phenotype data
• Integration of phenotype data

I understand that the precise way of doing phenotype data is a bit contentious, some people do not like the idea of representing them as precoordinated at all - but for the sake of evolving as a community I would recommend for the review of OBCI to take this way of thinking into account while doing the review. (I personally have not looked at OBCI and cant at the moment)

[matentzn]

One word of caution from my end - I would not use an ontology submission to challenge the way we do phenotype modelling in dozens of OBO ontologies for more than 12 years:

https://www.biorxiv.org/content/10.1101/2024.09.18.613276v1
https://link.springer.com/article/10.1007/s00335-023-09992-1

The EQ model is widely established since 2009, we have hundreds of design patterns, for example, the one for "increased level of glucose" is https://raw.githubusercontent.com/obophenotype/upheno/master/src/patterns/dosdp-dev/abnormallyIncreasedLevelOfChemicalEntityInLocation.yaml. This has been reviewed by many members of the phenotype ontology community (meetings are biweekly and ongoing if you like to join), and the logical modelling is, while not ideal in all cases (especially when it comes to "absence"), pretty much set in stone now..

[cmungall]

Both. Most phenotype ontologies treat these as synonyms or distinctions of degree eg https://www.ebi.ac.uk/ols4/ontologies/mp/classes/http%253A%252F%252Fpurl.obolibrary.org%252Fobo%252FMP_0005559

…

On Sun, Nov 3, 2024 at 3:51 PM Darren A. Natale ***@***.***> wrote: I think you mean that hyperglycemia would go in a phenotype ontology. Elevated blood glucose is one biomarker of that condition. — Reply to this email directly, view it on GitHub <#2643 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMMOJJJVVBM4CRLFSDGMDZ62LH7AVCNFSM6AAAAABQCNPIFGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJTGYYDMOJSGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[nlharris]

It is not clear to me what the status of this is. Are we waiting for the reviewer to do something, or the submitter to do something?

[balhoff]

@nlharris we are waiting for the reviewer (me) to do something. Sorry for the delay, I am actually looking at it right now.

[nlharris]

Ok, thanks! I didn't mean to suggest that you should work on this on a Sunday!🙂

[balhoff]

Here is my submission review:

Review criteria

• Ontology scope
  • Do the terms fall within the ontology’s stated target domain of knowledge?
  • Was the ontology developed for a very specific purpose or community?
• Terms with the new ontology prefix
  • Do the terms follow the OBO identifier scheme?
  • Are there terms with the same meaning available in another OBO Foundry ontology?
  • Is there another OBO Foundry ontology whose scope covers any of the new terms?
• Correct use of imported terms
  • If the ontology reuses terms from other OBO ontologies, are they used accurately?
  • Are imported terms in appropriate hierarchies, and do they preserve the term’s upper-level alignment?
  • Are any additional axioms used for these terms correct in both a technical (e.g. passes reasoning) and substantive sense?
• Basic review of axiomatic patterns
  • Are axioms generally stated simply or are they highly complex? (Highly complex axioms will require extra scrutiny.)
  • Are existential restrictions used correctly? (Typical mistakes include “R some (A and B and C)” to mean “(R some A and R some B and R some C)”).
• Appropriate use of object properties -
  • Are object properties used in a manner consistent with their definitions, domain, and range? (Examples of incorrect usage include those based on some interpretation of the label of the object property but not actually fitting the property definition or domain and range.)
• Responsiveness to suggested changes -
  • Have the developers been willing to fix any identified issues during the review?

Technically I don't find any issues with the ontology. The developers are already active in OBO and make correct use of identifiers as well as imported content. The axioms are created using consistent modeling patterns. One thing that would be nice, but I don't think is part of the review criteria, is to provide the production workflow source code (e.g., on GitHub), if there is anything besides Protege.

The one criterion I left un-checked above has to do with scope. As demonstrated in the discussion above, I think there are some differences of opinion on what a biomarker is as compared to a phenotype (or possibly concepts broader than just phenotype that follow the same EQ model). It seems to me that these are all basically the same kinds of structures, just differing in their choice of relations and model. I think biomarkers may sometimes include more information about how they were measured, rather than just the state of things, but maybe this could be done in a way that meshes with EQ?

@nataled @cmungall @matentzn is there any way to come to an alignment?

[pfabry]

The result of the lexical matching is available here: OBCI lexmatch 20241125.txt