OBOFoundry
Biomarker Ontology
Title
Biomarker Ontology
Short Description
The Biomarker Ontology comprises a comprehensive knowledge involving a variety of fields of medical and biological aspects.
Description
The Biomarker Ontology (BMONT) is a comprehensive knowledge representation involving a variety of fields of medical and biological aspects. BMONT is built in line with Basic Formal Ontology (BFO) and Open Biological and Biomedical Ontology (OBO) principles. Entities and definitions are added by reviewing the old biomarker terminology that was created by Fraunhofer SCAI 10 years ago and was used for mining biomarker information in biomedical literature. In addition, related terms were collected from scientific publications and books capturing various disease fields.
The ontology is proposed to be used for improving biomarker identification tasks, as well as a supportive integratable tool for abundant AI techniques, such as Machine Learning (ML) and Large Learning Model (LLM).
Identifier Space
BMO
License
CC-BY 4.0
Domain
health
Source Code Repository
OBOFoundry.github.io
Homepage
https://github.com/SCAI-BIO/BiomarkerOntology
Issue Tracker
https://github.com/SCAI-BIO/BiomarkerOntology/issues
Contribution Guidelines
https://github.com/SCAI-BIO/BiomarkerOntology/blob/main/CONTRIBUTING.md
Ontology Download Link
https://github.com/SCAI-BIO/BiomarkerOntology
Contact Name
Alpha Tom Kodamullil
Contact Email
Contact GitHub Username
akodamullil
Contact ORCID Identifier
https://orcid.org/0000-0001-9896-3531
Formats
- [X] OWL RDF/XML (.owl)
- [ ] OBO (.obo)
- [ ] OBO Graph JSON (.json)
Dependencies
-doid -chebi -mondo -cto -efo
Related
DOID MONDO CHEBI CTO EFO
Usages
No response
Intended Use Cases and/or Related Projects
A biomedical ontology to classify biomarkers and apply semantic technologies in the domain of various diseases, analyse biomarker discovery workflows. Annotation of medical texts.
Data Sources
Several sources from domain experts assembled by Fraunhofer SCAI.
Additional comments or remarks
No response
OBO Foundry Pre-registration Checklist
- [X] I have read and understood the registration process instructions and the registration checklist.
- [X] 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.
- [X] My ontology has a specific release file with a version IRI and a
dc:licenseannotation, serialised in RDF/XML. - [X] My identifiers (classes and properties IRIs) are formatted according to the OBO Foundry Identifier Policy
- [X] My term labels are in English and conform to the OBO Foundry Naming Conventions
- [X] 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.
- [X] 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).
- [X] 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!
- [X] 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.
- [X] 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.
- [X] 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.
Dear @Astghik-S ,
Thank you for your submission. The review will be executed as a two stage process:
First, you will have to pass OBO NOR Dashboard. Pass means that no check apart from Users and Versioning may be red. In addition, a new check is currently implemented: it consists in a lexical match of your original terms with those already existing in OBO Foundry published ontologies. The goal is to prevent the duplication of terms with similar meanings (cf. Review SOP). A list of terms that are potential duplicates will be provided soon.
After you have successfully passed the Dashboard you will be assigned an OBO Operations committee member to review the ontology. The assigned reviewer is to be considered the final arbiter of requirements; look to that reviewer's guidance regarding which suggestions made by other reviewers must be done, which suggestions are simply good to do but not required, and which should not be done.
Usually, the review will result in an opportunity for you to improve the ontology. When the reviewer believes the ontology is ready for presentation to the OBO Operations Committee, they will present your ontology during an OBO Operations Call. This gives other members of the committee the opportunity to assess your work.
When a decision is reached by the committee you will be informed here on the issue tracker. The process can take any number of weeks or months, depending on the case at hand. Please let us know about any reasons you might have for increased urgency.
You will be informed once your ontology is loaded in the OBO NOR Dashboard.
Good luck!
Dear @pfabry thank you very much for the detailed information. I am looking forward to checking the Dashboard and proceeding with further steps.
@Astghik-S Your ontology has been added to the OBO NOR Dashboard. In addition, the lexical matching hasn't find any duplicate in your ontology.
@Astghik-S Your ontology has passed the OBO NOR Dashboard and has been assigned to @deepakunni3 for reviewing.
Manual review of Biomarker Ontology
1. Ontology scope
The submitter describes Biomarker Ontology (BMO) as an ontology for classifying biomarkers, improving biomarker identification and facilitating tools used in machine learning and large language models. Upon closer inspection of the ontology, it looks like the ontology adds new terms and extends existing terms from CHEBI, CTO, CMO, OMIT, PR with additional axioms. The domain is 'health' which is consistent with the description and the terms defined within BMO.
The submitter states that several domain experts from Fraunhofer SCAI were involved in the development of BMO. But it is not clear who they are. The terms in BMO do not have any attribution so as to who contributed it. In addition, there are 36 terms in the ontology that have IAO:0000119 definition source as "ChatGPT". This seems to indicate some level of automated term extraction and creation. The submitter does make a reference to an older "biomarker ontology" developed 10 years ago by Fraunhofer SCAI. That means this iteration of BMO is meant to be an updated version which has been prepared for open-source sharing and contribution.
2. Terms with the new ontology prefix ❗
Do the terms follow the OBO identifier scheme?❗
The Base IRI for terms in BMO is http://purl.obolibrary.org/obo/bmo.owl/BMO_. It would be appropriate to remove the bmo.owl from the IRI to match the OBO identifier scheme.
Are there terms with the same meaning available in another OBO Foundry ontology? Yes❗
Yes, after reviewing terms from BMO, there are cases where a term from another ontology could be used instead. Following are some of the terms that could be replaced with an existing term:
- The term
BMO:0000060 d-dimercan be replaced with PR:000050369 D-dimer (human) - The term
BMO:0000061 Growth Differentiation Factor 15can be replaced with OMIT:0026290 Growth Differentiation Factor 15 - The term
BMO:0000092 blood glucose levelcan be replaced with CMO:0000046 blood glucose level
Is there another OBO Foundry ontology whose scope covers any of the new terms? ❗
Yes, after reviewing terms from BMO, there are cases where another ontology would cover some of the new terms. Following are BMO terms that could be added to another OBO Foundry ontology:
Clinical Measurement Ontology (CMO)
CMO contains terms that are specific to clinical measurements and thus could cover the following terms defined within BMO:
BMO:0000110 cerebral blood volumeBMO:0000113 gray matter volumeBMO:0000131 N-Terminal Pro-B-Type Natriuretic PeptideBMO:0000103 blood lipid level
Protein Ontology (PRO)
PRO contains terms that represent proteins and thus could cover the following terms defined within BMO:
BMO:0000062 lipoprotein aBMO:0000063 fibrinogenBMO:0000064 Creatine Kinase-MB
Ontology of Precision Medicine and Investigation (OPMI)
OPMI already defines several biomarkers and thus could cover the following terms defined within BMO:
BMO:0000076 therapeutic biomarkerBMO:0000075 parmacodynamic biomarkerBMO:0000077 digital biomarker
Ontology for Biomedical Investigations (OBI)
OBI already defines several terms for devices and thus could cover the following terms defined in BMO:
BMO:0000078 digital device
Note: The ontology submitter must make efforts to coordinate and add these terms to the suggested ontologies. If the terms are rejected or deemed as out of scope by the target ontologies then an exception can be made for those terms.
3. Correct use of imported terms ❗
If the ontology reuses terms from other OBO ontologies, are they used accurately? ✅
The BMO ontology imports several terms from CHEBI, OBI, SIO, EFO, OMIT and extends these terms using object properties to indicate whether the terms are a predictive, prognostic, diagnostic biomarker for a disease (via OWL restrictions). The imported terms have sufficient metadata.
Are imported terms in appropriate hierarchies, and do they preserve the term’s upper-level alignment? ❗
There are certain cases where an imported term does not have the parent class from the upstream ontology as its parent. Rather it is an ancestral class which is ambiguous.
- For example, in BMO,
CHEBI:17855 Triglycerideis a subclass ofCHEBI:23367 Molecular Entitywhen in realityCHEBI:17855 Triglycerideis subclass ofCHEBI:35741 glycerolipid
Are any additional axioms used for these terms correct in both a technical (e.g. passes reasoning) and substantive sense? ❗
There are other cases where an imported term is defined as a subclass of a term from an entirely different ontology.
- For example, BMO imports
MONDO:0007915 systemic lupus erythematosusand states that this term is subclass ofDOID:417 autoimmune diseaseeven though according to MONDO,MONDO:0007915is subclass ofMONDO:0004670. It is not clear why a new subClassOf axiom was added to an imported term.
4. Basic review of axiomatic patterns ✅
Are axioms generally stated simply or are they highly complex? (Highly complex axioms will require extra scrutiny.) ✅
The axioms are simply and appropriately constructed.
Are existential restrictions used correctly? ✅
Yes, existential restrictions are used correctly.
5. Appropriate use of object properties ✅
BMO defines 7 BMO-specific object properties and they are used in a consistent manner throughout the ontology.
One thing to note is that the object properties have a label but no additional information such as definition, domain or range that further describe these properties and their usage.
BMO also re-uses object properties from RO and their usage are consistent as well.
6. Responsiveness to suggested changes :grey_question:
This is the first iteration of feedback. Will evaluate the responsiveness in the next iteration.
Additional Questions/Suggestions
- The BMO repository (https://github.com/Astghik-S/BMO) is located within a GitHub user account. Ideally, this should be moved to a GitHub organization to ensure sustainability.
- It looks like the repository itself is fairly new (2 months since creation). There is no community interaction or history to see. If this is a new ontology then that is expected. But there does seem to references to a historical version of BMO.
- The README (https://github.com/Astghik-S/BMO?tab=readme-ov-file#maintenance) has a statement that indicates that BMO will be maintained for at least 3 years. It would be good for the submitters to set up their repository for better community engagement to empower open-source contributors to continue the development and maintenance of BMO.
- Favoring PATO (an OBO Foundry ontology) over SIO for terms that represent quality such as 'normal', 'abnormal', 'increased', 'decreased', etc.
- There are terms in BMO that do not have a parent class. It would be clearer to give these an appropriate parent class:
BMO:0000070BMO:0000072BMO:0000073BMO:0000098BMO:0000100BMO:0000132
Lexical Matching
After running lexical match on term labels in BMO with terms from OBO Foundry ontologies (excluding NCIT), following are the results:
BMO:0000009monitoring biomarkerBMO:0000012safety biomarkerBMO:0000015surrogate biomarkerBMO:0000016context of useBMO:0000020clinical sensitivityBMO:0000022probability of false negativesstato:0000220false negative rate (0.778)
BMO:0000025companion diagnosticschebi:3479cefadroxil (0.521)
BMO:0000037kidney injury molecule-1BMO:0000038urine total poteinBMO:0000050human epidermal growth factor receptor 2BMO:0000060d-dimerBMO:0000061Growth Differentiation Factor 15ogg:3000009518GDF15 (0.778)
BMO:0000063fibrinogendron:00018213Fibrinogen (0.762)go:0005577fibrinogen complex (0.556)go:0008001obsolete fibrinogen (0.556)
BMO:0000064Creatine Kinase-MBgo:0004111creatine kinase activity (0.556)
BMO:0000075pharmacodynamic biomarkerBMO:0000083augmentation indexncbitaxon:8831Aix (0.743)vto:0030587Aix (0.743)
BMO:0000091sleep stageBMO:0000092blood glucose levelcmo:0000046blood glucose level (0.778)vt:0000188blood glucose amount (0.556)
BMO:0000104total cholesterolBMO:0000120amyloid depositionmpath:34amyloid deposition (0.778)
BMO:0000130gait unsteadinesshp:0002066Gait ataxia (0.549)hp:0002317Unsteady gait (0.772)mp:0001393ataxia (0.556)
BMO:0000131N-Terminal Pro-B-Type Natriuretic Peptide
Note: The above list is a suggestion and it is up to the discretion of the ontology submitter to check for consistency before considering a term as a potential replacement.
Robot Report
After running the robot report command on BMO:
java -jar robot.jar report --input BMO-merged.owl
Following are BMO-specific issues as reported by robot:
Rule Name Subject Property Value
duplicate_exact_synonym obo:bmo.owl/BMO_0000015 oboInOwl:hasExactSynonym
duplicate_label_synonym obo:bmo.owl/BMO_0000063 oboInOwl:hasExactSynonym fibrinogen
equivalent_class_axiom_no_genus obo:bmo.owl/BMO_0000070 obo:bmo.owl/BMO_0000066 DOID:4
equivalent_class_axiom_no_genus obo:bmo.owl/BMO_0000072 obo:bmo.owl/BMO_0000067 DOID:4
equivalent_class_axiom_no_genus obo:bmo.owl/BMO_0000073 obo:bmo.owl/BMO_0000065 DOID:4
equivalent_class_axiom_no_genus obo:bmo.owl/BMO_0000074 obo:bmo.owl/BMO_0000071 DOID:4
equivalent_class_axiom_no_genus obo:bmo.owl/BMO_0000098 obo:bmo.owl/BMO_0000097 DOID:4
equivalent_class_axiom_no_genus obo:bmo.owl/BMO_0000100 obo:bmo.owl/BMO_0000099 DOID:4
equivalent_class_axiom_no_genus obo:bmo.owl/BMO_0000132 obo:bmo.owl/BMO_0000057 DOID:4
missing_definition obo:bmo.owl/BMO_0000048 IAO:0000115
missing_definition obo:bmo.owl/BMO_0000057 IAO:0000115
missing_definition obo:bmo.owl/BMO_0000065 IAO:0000115
missing_definition obo:bmo.owl/BMO_0000066 IAO:0000115
missing_definition obo:bmo.owl/BMO_0000067 IAO:0000115
missing_definition obo:bmo.owl/BMO_0000070 IAO:0000115
missing_definition obo:bmo.owl/BMO_0000071 IAO:0000115
missing_definition obo:bmo.owl/BMO_0000072 IAO:0000115
missing_definition obo:bmo.owl/BMO_0000073 IAO:0000115
missing_definition obo:bmo.owl/BMO_0000074 IAO:0000115
missing_definition obo:bmo.owl/BMO_0000097 IAO:0000115
missing_definition obo:bmo.owl/BMO_0000098 IAO:0000115
missing_definition obo:bmo.owl/BMO_0000099 IAO:0000115
missing_definition obo:bmo.owl/BMO_0000100 IAO:0000115
missing_definition obo:bmo.owl/BMO_0000132 IAO:0000115
missing_superclass obo:bmo.owl/BMO_0000070 rdfs:subClassOf
missing_superclass obo:bmo.owl/BMO_0000072 rdfs:subClassOf
missing_superclass obo:bmo.owl/BMO_0000073 rdfs:subClassOf
missing_superclass obo:bmo.owl/BMO_0000074 rdfs:subClassOf
missing_superclass obo:bmo.owl/BMO_0000098 rdfs:subClassOf
missing_superclass obo:bmo.owl/BMO_0000100 rdfs:subClassOf
missing_superclass obo:bmo.owl/BMO_0000132 rdfs:subClassOf
Checklist
- [x] MUST change the term IRI from
http://purl.obolibrary.org/obo/bmo.owl/BMO_tohttp://purl.obolibrary.org/obo/BMO_to match the OBO identifier scheme - [x] SHOULD replace
BMO:0000060 d-dimerwithPR:000050369 D-dimer (human) - [x] SHOULD replace
BMO:0000061 Growth Differentiation Factor 15withOMIT:0026290 Growth Differentiation Factor 15 - [x] SHOULD replace
BMO:0000092 blood glucose levelwithCMO:0000046 blood glucose level - [ ] SHOULD look into the lexical match results and evaluate possible replacement terms from existing OBO Foundry ontologies
- [x] MUST add terms that overlap in scope to the respective ontologies (CMO, PRO, OPMI, OBI)
- [x] MUST look into the
rdfs:subClassOfaxioms added to imported terms to ensure that they are consistent with upstream ontologies - [ ] SHOULD add definition,
rdfs:domainandrdfs:rangeinformation to BMO-specific object properties for better readability, interpretation and usage - [x] CONSIDER moving BMO repository from a GitHub user account to a GitHub organization
- [ ] SHOULD set up their repository for better community engagement to empower open-source contributors to continue the development and maintenance of BMO
- [ ] SHOULD add an appropriate parent class to BMO terms that are missing a parent class
@Astghik-S Please take time to go through the above review and the subsequent checklist. You can use this issue thread to keep us up to date regarding progress. If you have any questions or concerns then please don't hesitate to reach out.
@deepakunni3 Thank you for the review and comments. I shall check all mentioned points, address all, and come back to you!
@deepakunni3 sorry for the late reply. We checked all comments and below I am addressing all of those.
-
First of all , I would like to mention that we changed the acronym to BMONT in order to to avoid ambiguity, and corrected the base IRI for it. As well as, upon your suggestion we have stored the ontology.
-
Names of contributed people are added.
-
For the completeness of the ontology we added definitions for the newly defined terms. In cases when no other definition source was found we manually checked and added the definitions suggested by ChatGPT. Meaning, that no automated term extraction and creation is done.
-
The submitter does make a reference to an older "biomarker ontology" developed 10 years ago by Fraunhofer SCAI. That means this iteration of BMO is meant to be an updated version which has been prepared for open-source sharing and contribution.
-- We changed the ontology description as 10 years ago our colleagues created not an ontology but rather a terminology and we have only used it to extract relevant terms. The BMONT was built from scratch. I hope this resolves the ambiguity.
- Following are some of the terms that could be replaced with an existing term
-- The mentioned terms that were mistakenly defined as new ones despite the fact they already exist are replaced.
- Following are BMO terms that could be added to another OBO Foundry ontology:
-- Trying to guess which OBO ontology could include the suggested term is very demotivating and time consuming. If the term is not in other ontologies then simply we should define it as we are applying for OBO approval. We can of course check if BMONT terms that could be added to another OBO Foundary ontology, for example CMO, PRO, and OBI asking them to check if they are willing to have the terms in their ontology. But why are we making efforts to create a valuable ontology?
Moreover, we do not think that "BMO:0000076 therapeutic biomarker", "BMO:0000075 parmacodynamic biomarker" "BMO:0000077 digital biomarker" are more in scope of Ontology of Precision Medicine and Investigation (OPMI) than of our BMONT.
- Considering your comment that there are certain cases where an imported term does not have the parent class from the upstream ontology as its parent. Rather it is an ancestral class which is ambiguous. We would like to consider the example yo provided: In BMO, CHEBI:17855 C is a subclass of CHEBI:23367 Molecular Entity when in reality CHEBI:17855 Triglyceride is subclass of CHEBI:35741 glycerolipid.
We would like to mention that, it is not ambiguous at all and we do not have to include all ancestral classes if it is not necessary otherwise we will include the whole CHEBI which is nonsense. “Triglyceride” is a “molecular entity” so “is a” relationship is there so no obligation or violation.
- Considering another cmment of you mentioning that there are other cases where an imported term is defined as a subclass of a term from an entirely different ontology: For example, BMO imports MONDO:0007915 systemic lupus erythematosus and states that this term is subclass of DOID:417 autoimmune disease even though according to MONDO, MONDO:0007915 is subclass of MONDO:0004670. It is not clear why a new subClassOf axiom was added to an imported term. Here we would like to note that the class "autoimmune disease" is in both MONDO and DOID OBO ontologies, so if it is already imported from DOID practically it is not possible to rearrange, remove and add classes each time. So if there is a term with exactly the same name we just took it as appropriate upper class.
-As you mentioned there are terms in BMO that do not have a parent class. It would be clearer to give these an appropriate parent class: BMO:0000070, BMO:0000072, BMO:0000073, BMO:0000098, BMO:0000100, BMO:0000132
The mentioned classes do not have parent classes because they are for text mining purposes which also is given in their name to avoid confusions.
@deepakunni3 just wondering if you've had a chance to circle back to this?
@pfabry Following the first round of reviews, the name of the ontology has been changed from BMO to BMONT. The repository location has also changed from https://github.com/Astghik-S/BMO/ to https://github.com/SCAI-BIO/BiomarkerOntology. It would be great if you could update the NOR Dashboard entry for BMO with the newer metadata.
@Astghik-S Thank you for the response to the comments in the review.
After discussing about BMONT (née BMO) during the OBO Foundry Operations Committee meeting (2024-09-17), there were a few concerns raised with the scope of this ontology.
- Is the ontology specific to biomarkers in humans or all species? The ontology and the users of the ontology would benefit from this being specified via taxon constraints.
- The submitter describes BMONT as an ontology of biomarkers but it is not clear what the extent of this ontology is. Does it focus on particular area like cell biomarkers, diagnostic biomarkers, prognostic biomarkers, molecular biomarkers or all of them? It would be good to clarify in the ontology description.
- Additionally, it would be great if the submitter could clarify if BMONT is a reference ontology or an application ontology. The repository (https://github.com/SCAI-BIO/BiomarkerOntology) does not provide sufficient clarification.
@deepakunni3 Thank you for your comments and suggestions. We tried to address each of those:
- Is the ontology specific to biomarkers in humans or all species? The ontology and the users of the ontology would benefit from this being specified via taxon constraints.
- The BMONT currently comprises only human related biomarkers. That is why we do not need any taxon constraints yet. It is a good idea and maybe we shall consider other species later, but for now and for the near future our ontology includes only biomarkers related to humans.
- The submitter describes BMONT as an ontology of biomarkers but it is not clear what the extent of this ontology is. Does it focus on particular area like cell biomarkers, diagnostic biomarkers, prognostic biomarkers, molecular biomarkers or all of them? It would be good to clarify in the ontology description.
- As you fairly noticed, we did not specify any specific focus because it is an initial attempt to collect within one ontology all the related concepts and relationships. To group specific biomarker types and facilitate usability we are using the predefined BINs. Of course it is a sophisticated field and it is challenging to summarize all the biomarker related information but after some efforts it will give an opportunity to retrieve related information and to solve important problems.
- Additionally, it would be great if the submitter could clarify if BMONT is a reference ontology or an application ontology. The repository (https://github.com/SCAI-BIO/BiomarkerOntology) does not provide sufficient clarification.
- Like all the ontologies we built before (COVID-19, EPIO, ADO) the BMONT is a “hybrid” ontology, meaning that it is actually a reference ontology but it also includes BINs that prepare the ontology for specific applications. Currently we consider several use cases and the details will be included in the publication that will follow afterwards.
Thank you for taking the time to go through the comments above and for your response.
Following are observations made after a second round of review:
1. Ontology scope
The submitter states that BMONT contains only human-related biomarkers with the possibility of considering other species in the future. Similarly, the submitter states that the extent of the ontology is open-ended on purpose to allow for flexibility and incremental development of BMONT according to use cases.
Thank you @Astghik-S for the clarification. It would be good to put this clarification in the description of the ontology so that it is clear to the users of BMONT.
2. Terms with the new ontology prefix ❗
Do the terms follow the OBO identifier scheme? ✅
Response from submitter: First of all , I would like to mention that we changed the acronym to BMONT in order to to avoid ambiguity, and corrected the base IRI for it. As well as, upon your suggestion we have stored the ontology.
The ontology prefix and IRI has been updated. All terms now have IRIs that conform to the OBO identifier scheme.
Are there terms with the same meaning available in another OBO Foundry ontology? ✅
Response from submitter: The mentioned terms that were mistakenly defined as new ones despite the fact they already exist are replaced.
The authors have replaced the terms for which there exists an exact replacement.
Is there another OBO Foundry ontology whose scope covers any of the new terms? ❗
Response from submitter:
Trying to guess which OBO ontology could include the suggested term is very demotivating and time consuming. If the term is not in other ontologies then simply we should define it as we are applying for OBO approval. We can of course check if BMONT terms that could be added to another OBO Foundary ontology, for example CMO, PRO, and OBI asking them to check if they are willing to have the terms in their ontology. But why are we making efforts to create a valuable ontology? Moreover, we do not think that "BMO:0000076 therapeutic biomarker", "BMO:0000075 parmacodynamic biomarker" "BMO:0000077 digital biomarker" are more in scope of Ontology of Precision Medicine and Investigation (OPMI) than of our BMONT.
The goal of this section is to promote discussion and cross-talk between existing OBO Foundry ontologies and a new prospective ontology. The objective is not to discourage or demotivate ontology developers, but rather to prevent the proliferation of terms with similar meaning across different OBO Foundry ontologies.
To that end, the request is not to place all possible terms from BMONT into another ontology, but rather to see if the ontology submitter and maintainers are willing to engage in collaboration with other OBO Foundry ontologies.
The relevance, scope, choice and decision of whether to add terms to an existing OBO Foundry ontology is left to discretion of the ontology maintainers. But we do want to see efforts made by the ontology maintainers. And if the target ontology does not respond to the ontology maintainers then we would like to know that as well.
3. Correct use of imported terms ❗
Response from submitter:
Considering your comment that there are certain cases where an imported term does not have the parent class from the upstream ontology as its parent. Rather it is an ancestral class which is ambiguous. We would like to consider the example yo provided: In BMO, CHEBI:17855 C is a subclass of CHEBI:23367 Molecular Entity when in reality CHEBI:17855 Triglyceride is subclass of CHEBI:35741 glycerolipid.
Understood and thank you for the clarification.
Response from submitter:
Considering another cmment of you mentioning that there are other cases where an imported term is defined as a subclass of a term from an entirely different ontology: For example, BMO imports MONDO:0007915 systemic lupus erythematosus and states that this term is subclass of DOID:417 autoimmune disease even though according to MONDO, MONDO:0007915 is subclass of MONDO:0004670. It is not clear why a new subClassOf axiom was added to an imported term. Here we would like to note that the class "autoimmune disease" is in both MONDO and DOID OBO ontologies, so if it is already imported from DOID practically it is not possible to rearrange, remove and add classes each time. So if there is a term with exactly the same name we just took it as appropriate upper class.
The explanation does not clarify why a new subClassOf axiom was injected. My previous observation was in regards to scenarios where a term from an ontology does not preserve its parent class after it is imported. One example was MONDO:0007915 systemic lupus erythematosus whose parent is MONDO:0004670 and not DOID:417. But there are other such examples:
MONDO:0004335 digestive system disorderwhose actual parent isMONDO:0700096 human disease. But in BMONT it states thatMONDO:0004335is a subClassOfOGMS:0000045MONDO:0005002whose actual parent isMONDO:0002267but in BMONT it states thatMONDO:0005002is a subClassOfDOID:850
These could be artifacts introduced by the ontology authoring tools. It would be good for the submitter to look into this.
Note: When an ontology introduces a new parent for an imported term that is different from the original upstream ontology, this is called as axiom injection. The distinction of whether BMONT is a reference ontology or an application ontology matters here. If BMONT is a reference ontology then injecting new axioms to imported terms is discouraged. See the ongoing discussion regarding this topic.
4. Basic review of axiomatic patterns ❗
Are axioms generally stated simply or are they highly complex? (Highly complex axioms will require extra scrutiny.) ✅
The axioms are simply and appropriately constructed.
Are existential restrictions used correctly? ❗
Yes, existential restrictions are used correctly.
But there are scenarios where restrictions are added to imported terms from CHEBI, HP, MAXO, NCIT, OMIT, PR
For example,
- CHEBI:17929 (https://github.com/SCAI-BIO/BiomarkerOntology/blob/main/BMONT-merged.owl#L5261-L5280)
- HP:0004934 (https://github.com/SCAI-BIO/BiomarkerOntology/blob/main/BMONT-merged.owl#L7695-L7702)
- MAXO:0000972 (https://github.com/SCAI-BIO/BiomarkerOntology/blob/main/BMONT-merged.owl#L8030-L8037)
- NCIT:C106407 (https://github.com/SCAI-BIO/BiomarkerOntology/blob/main/BMONT-merged.owl#L8847-L8854)
- OMIT:0006913 (https://github.com/SCAI-BIO/BiomarkerOntology/blob/main/BMONT-merged.owl#L11216-L11229)
- PR:000003035 (https://github.com/SCAI-BIO/BiomarkerOntology/blob/main/BMONT-merged.owl#L12115-L12152)
The distinction of whether BMONT is a reference ontology or an application ontology matters here. If BMONT is a reference ontology then injecting new axioms to imported terms is discouraged. See the ongoing discussion regarding this topic.
5. Appropriate use of object properties ✅
6. Responsiveness to suggested changes ✅
The submitter is response to suggested changes.
Additional Questions/Suggestions
Great to see BMONT moved to the https://github.com/SCAI-BIO organization. The renaming to BiomarkerOntology (BMONT) is appropriate and consistent. The base IRI, ontology IRI and prefix for all terms in the ontology looks correct.
The submitted is encouraged to consider the distinction between a reference and an application ontology and decide what would suit best for BMONT.
Dear @deepakunni3 thank you for responses. I am sorry for the late reply. So I am adding our responses below in bold.
- Is there another OBO Foundry ontology whose scope covers any of the new terms? ❗
The goal of this section is to promote discussion and cross-talk between existing OBO Foundry ontologies and a new prospective ontology. The objective is not to discourage or demotivate ontology developers, but rather to prevent the proliferation of terms with similar meaning across different OBO Foundry ontologies.
To that end, the request is not to place all possible terms from BMONT into another ontology, but rather to see if the ontology submitter and maintainers are willing to engage in collaboration with other OBO Foundry ontologies.
The relevance, scope, choice and decision of whether to add terms to an existing OBO Foundry ontology is left to discretion of the ontology maintainers. But we do want to see efforts made by the ontology maintainers. And if the target ontology does not respond to the ontology maintainers then we would like to know that as well.**
- I am reaching out to the groups responsible for OBO Foundry ontologies to inquire whether BMONT terms can be incorporated into other OBO Foundry ontologies, such as CMO, PRO, and OBI. I am asking them to review these terms and let me know if they are willing to include them in their respective ontologies. Hopefully, we will receive responses in the coming days.
-
The explanation does not clarify why a new subClassOf axiom was injected. My previous observation was in regards to scenarios where a term from an ontology does not preserve its parent class after it is imported. One example was MONDO:0007915 systemic lupus erythematosus whose parent is MONDO:0004670 and not DOID:417. But there are other such examples:
MONDO:0004335 digestive system disorder whose actual parent is MONDO:0700096 human disease. But in BMONT it states that MONDO:0004335 is a subClassOf OGMS:0000045 MONDO:0005002 whose actual parent is MONDO:0002267 but in BMONT it states that MONDO:0005002 is a subClassOf DOID:850
These could be artifacts introduced by the ontology authoring tools. It would be good for the submitter to look into this.
Note: When an ontology introduces a new parent for an imported term that is different from the original upstream ontology, this is called as axiom injection. The distinction of whether BMONT is a reference ontology or an application ontology matters here. If BMONT is a reference ontology then injecting new axioms to imported terms is discouraged. See the https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1443 regarding this topic.**
- Let’s review the issue: First, I integrated the class “Lung disease (DOID:850)”. Later, I needed to include the class “chronic obstructive pulmonary disease (MONDO:0005002)”. However, in MONDO, the equivalent term is "lung disorder (MONDO:0005275)". So, what should be done in this case? Naturally, you might suggest replacing "Lung disease (DOID:850)" with "lung disorder (MONDO:0005275)". But what happens if I need to integrate another term that is a subclass of “Lung disease (DOID:850)”? In this situation, we’ve decided to replace DOID classes with their MONDO equivalents, since many DOID terms are included as synonyms in analogous MONDO classes. However, a challenge remains. For example, “neurodegenerative disease” exists in both MONDO and DOID. Which should be chosen, especially when some subclasses are defined in MONDO but not in DOID, and vice versa? This is crucial for making consistent decisions during future ontology development.
- Are existential restrictions used correctly? ❗
Yes, existential restrictions are used correctly.
But there are scenarios where restrictions are added to imported terms from CHEBI, HP, MAXO, NCIT, OMIT, PR
For example,
CHEBI:17929 (https://github.com/SCAI-BIO/BiomarkerOntology/blob/main/BMONT-merged.owl#L5261-L5280)
HP:0004934 (https://github.com/SCAI-BIO/BiomarkerOntology/blob/main/BMONT-merged.owl#L7695-L7702)
MAXO:0000972 (https://github.com/SCAI-BIO/BiomarkerOntology/blob/main/BMONT-merged.owl#L8030-L8037)
NCIT:C106407 (https://github.com/SCAI-BIO/BiomarkerOntology/blob/main/BMONT-merged.owl#L8847-L8854)
OMIT:0006913 (https://github.com/SCAI-BIO/BiomarkerOntology/blob/main/BMONT-merged.owl#L11216-L11229)
PR:000003035 (https://github.com/SCAI-BIO/BiomarkerOntology/blob/main/BMONT-merged.owl#L12115-L12152)
The distinction of whether BMONT is a reference ontology or an application ontology matters here. If BMONT is a reference ontology then injecting new axioms to imported terms is discouraged. See the https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1443 regarding this topic.
- BMONT is both a reference and application ontology. Our primary goal is to consolidate all biomarker-related terms into a single ontology. However, this is a complex task that spans multiple fields. For instance, numerous diseases require descriptions using both established and candidate biomarkers, many of which are still under discussion.
For preventive, transnational, and personalized medicine, it is crucial for clinicians to have tools that enable easy access to existing knowledge. To achieve satisfying results, we plan to implement our ontology within our SCAIView text mining machine. This is why we are also adding restrictions to the imported classes, allowing us to create text mining BINs. We have applied this approach to other OBO-approved ontologies, particularly the Epilepsy Ontology (see Epilepsy Ontology GitHub OBO Issue #1514).
We aim to enhance BMONT by defining biomarkers for various diseases, fostering improved dialogue between clinicians and researchers.
As we integrate classes from existing OBO ontologies, we must inject those axioms for practical application.
Dear @deepakunni3,
I wanted to follow up regarding the current status. I recently responded to the comments provided addressing your suggestions. It has been about two weeks since my response so I wanted to check in to see if there is any further feedback or if there are additional steps I should take to move the process forward.
Hi @Astghik-S! Apologies for the late response. Took some time to circle back to this ticket.
Response from submitter:
I am reaching out to the groups responsible for OBO Foundry ontologies to inquire whether BMONT terms can be incorporated into other OBO Foundry ontologies, such as CMO, PRO, and OBI. I am asking them to review these terms and let me know if they are willing to include them in their respective ontologies. Hopefully, we will receive responses in the coming days.
Fantastic! Glad to hear that the discussions are ongoing. If possible, please provide link(s) to the tickets/issues created at the respective OBO Foundry ontologies to make it easier to follow the discussion.
Response from submitter:
First, I integrated the class “Lung disease (DOID:850)”. Later, I needed to include the class “chronic obstructive pulmonary disease (MONDO:0005002)”. However, in MONDO, the equivalent term is "lung disorder (MONDO:0005275)". So, what should be done in this case? Naturally, you might suggest replacing "Lung disease (DOID:850)" with "lung disorder (MONDO:0005275)". But what happens if I need to integrate another term that is a subclass of “Lung disease (DOID:850)”? In this situation, we’ve decided to replace DOID classes with their MONDO equivalents, since many DOID terms are included as synonyms in analogous MONDO classes. However, a challenge remains. For example, “neurodegenerative disease” exists in both MONDO and DOID. Which should be chosen, especially when some subclasses are defined in MONDO but not in DOID, and vice versa? This is crucial for making consistent decisions during future ontology development.
Thank you for the detailed breakdown.
My assumption is that if you are importing DOID:850 Lung disease then its parent class would be DOID:0050161 lower respiratory tract disease and this information would be included via MIREOT.
Later, when you import MONDO:0005002 chronic obstructive pulmonary disease, then its parent class would be MONDO:0002267 obstructive lung disease and this information would be included via MIREOT.
You do not have to specifically add all the parent (and ancestral) terms of an imported term. A tool like Robot would take care of this. In fact, if the term MONDO:0005002 chronic obstructive pulmonary disease was imported using MIREOT then MONDO:0005275 lung disorder would also be imported.
You can have both DOID:850 Lung disease and MONDO:0005275 lung disorder co-exist in the ontology.
When you need to integrate another term that is a subclass of DOID:850 Lung disease then you can state that the term is a subclass of DOID:850, provided that the term is either a DOID term or a BMONT term.
The MONDO:0005002 rdfs:subClassOf DOID:850 axiom is what is confusing here. Neither MONDO nor DOID states this axiom. What the axiom is saying seems harmless because it makes sense to say that 'chronic obstructive pulmonary disease' is a type of 'lung disease'. It is the cross-ontology terms involved in the axiom that is confusing.
Note: This scrutiny is applied because BMONT is stated to be a reference ontology. Instances of axiom injection are highly discouraged as it affects interoperability of BMONT with other ontologies.
Also to clarify, the goal here is not to decide whether to import terms exclusively from MONDO or DOID. In the case of 'neurodegenerative disease', the choice of the term to import depends on your evaluation of which ontology gives you the right hierarchy of terms for your use-case.
Response from submitter:
BMONT is both a reference and application ontology. Our primary goal is to consolidate all biomarker-related terms into a single ontology. However, this is a complex task that spans multiple fields. For instance, numerous diseases require descriptions using both established and candidate biomarkers, many of which are still under discussion.
Given the stated goals, I would recommend looking into and coordinating efforts with OBCI (https://github.com/OBOFoundry/OBOFoundry.github.io/issues/2643).
Hi Astghik, We meet again! Speaking of meetings, OBCI developers will be meeting with the developers of yet another biomarker ontology in two days, Wednesday Nov 6, at 8am US Eastern Time (the time zone for New York City and Washington, DC). I don't know anything about this third ontology. Indeed, this initial meeting was intended to see if our scopes and/or approaches aligned, and we intended to have a follow-up meeting with your group (our two groups are US-based and thus easier to coordinate meeting times). In any case, I think our time ended up being early enough that you might be able to join?
By the way, OBCI and BMONT have very different approaches to biomarkers. BMONT appears to be an application ontology while OBCI is not. That being said, it might be quite difficult for us to get OBCI into the OBO Foundry without us changing something fundamental. Perhaps us three biomarker ontology developers can come up with something that will work! In that spirit, please let me know if you are able to join that rather informal meeting.
Hi Darren,
Sure, we can meet and discuss. November 6 at 8 AM works for me.
Hi @deepakunni3 ,
- After discussing the issue we decided to have BMONT as an application ontology,
- Also I wanted to inform you that we already contacted CMO, PRO, OPMI, and OBI ontology maintainers regarding the terms they would like to integrate. I will inform you about the results ASAP.
@Astghik-S Thank you for clarifying about BMONT as an application ontology.
Glad to hear that the discussions are ongoing with CMO (https://github.com/rat-genome-database/CMO-Clinical-Measurement-Ontology/issues/14), PRO (https://github.com/PROconsortium/PRoteinOntology/issues/338), and OPMI (https://github.com/OPMI/opmi/issues/15).
We will discuss about BMONT on the next Operations Committee call (2024-11-26).
@pfabry I notice this ontology failed FP11 "Authority" despite having what appears to be proper contact information. Is it possible that the dashboard configuration file needs to be edited? I notice that the 'orcid' entry is given as 'https://orcid.org/0000-0001-9896-3531' instead of just '0000-0001-9896-3531'. Other NOR dashboard configurations lack the https...prefix. Can you fix, or, if you prefer, I can make a pull request to fix.
Final review of BMONT
1. Ontology scope
The submitter describes Biomarker Ontology (BMONT) as an ontology for classifying biomarkers, improving biomarker identification and facilitating tools used in machine learning and large language models. Upon closer inspection of the ontology, it looks like the ontology adds new terms and extends existing terms from CHEBI, CTO, CMO, OMIT, PR with additional axioms. The submitter states that BMONT contains only human-related biomarkers with the possibility of considering other species in the future. Similarly, the submitter also states that the extent of the ontology is open-ended on purpose to allow for flexibility and incremental development of BMONT according to use cases.
2. Terms with the new ontology prefix ✅
Do the terms follow the OBO identifier scheme? ✅
The name of the ontology was changed from BMO to BMONT. The ontology prefix and IRI has been updated to account for this change. All terms now have IRIs that conform to the OBO identifier scheme.
Are there terms with the same meaning available in another OBO Foundry ontology? ✅
After review, the authors have replaced the terms for which there exists an exact replacement.
Is there another OBO Foundry ontology whose scope covers any of the new terms? ✅
After reviewing terms from BMO, there are cases where another ontology would cover some of the new terms. The submitter has made new term requests for CMO (rat-genome-database/CMO-Clinical-Measurement-Ontology#14), PRO (PROconsortium/PRoteinOntology#338), and OPMI (OPMI/opmi#15).
3. Correct use of imported terms ✅
If the ontology reuses terms from other OBO ontologies, are they used accurately? ✅
The BMO ontology imports several terms from CHEBI, OBI, SIO, EFO, OMIT and extends these terms using object properties to indicate whether the terms are a predictive, prognostic, diagnostic biomarker for a disease (via OWL restrictions). The imported terms have sufficient metadata.
Are imported terms in appropriate hierarchies, and do they preserve the term’s upper-level alignment? ✅
Yes, the imported terms are in appropriate hierarchies and preserve the term's upper-level alignment.
4. Basic review of axiomatic patterns ✅
Are axioms generally stated simply or are they highly complex? (Highly complex axioms will require extra scrutiny.) ✅
The axioms are simply and appropriately constructed.
Are existential restrictions used correctly? ✅
Yes, existential restrictions are used correctly.
But there are scenarios where restrictions are added to imported terms from CHEBI, HP, MAXO, NCIT, OMIT, PR.
Given that BMONT is an application ontology, the addition of such restrictions are expected and does not negatively impact the review.
5. Appropriate use of object properties ✅
BMO defines 7 BMO-specific object properties and they are used in a consistent manner throughout the ontology.
BMO also re-uses object properties from RO and their usage are consistent as well.
6. Responsiveness to suggested changes ✅
The submitter is response to suggested changes.
Dear @deepakunni3 thank you very much for the final review of the BMONT. What are the next steps now?
@Astghik-S The above final review was mostly for the benefit of the OBO Foundry Operations Committee.
The review for BMONT is still under discussion. We will be bringing it up again on the next call on 10.12.2024
We decided to resume discussions about this on Jan 7th, 2025 due to the low attendance at the meeting in the holiday season. In the meantime, please feel free to update the version with the fixes to the issues we let you know @Astghik-S .
Dear @deepakunni3 and @handemcginty do you have any updates on the BMONT? A decision was originally expected on 10 December 2024 but was postponed to 7 January 2025. As of 12 January 2025, I still have not received any updates. Thank you in advance!
We need feedback from @deepakunni3 before we can proceed, and are reaching out. Will try to have further info in 2 weeks.
@rays22 was assigned as the second reviewer to evaluate the ontology on Feb 4th, 2025.
