Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Biomarker Ontology #2604

Open
12 of 14 tasks
Astghik-S opened this issue May 31, 2024 · 26 comments
Open
12 of 14 tasks

Biomarker Ontology #2604

Astghik-S opened this issue May 31, 2024 · 26 comments
Assignees
Labels
new ontology - reviewer response required Reviewer of this ontology needs to respond to an update or question. new ontology Use for new ontology registration requests

Comments

@Astghik-S
Copy link

Astghik-S commented May 31, 2024

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

[email protected]

Contact GitHub Username

akodamullil

Contact ORCID Identifier

https://orcid.org/0000-0001-9896-3531

Formats

  • 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

  • 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.
@Astghik-S Astghik-S added the new ontology Use for new ontology registration requests label May 31, 2024
@nlharris
Copy link
Contributor

nlharris commented Jun 4, 2024

@matentzn @pfabry did you see this New Ontology request?

@pfabry
Copy link
Contributor

pfabry commented Jun 7, 2024

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!

@Astghik-S
Copy link
Author

Dear @pfabry thank you very much for the detailed information. I am looking forward to checking the Dashboard and proceeding with further steps.

@pfabry
Copy link
Contributor

pfabry commented Jun 11, 2024

@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.

@pfabry
Copy link
Contributor

pfabry commented Jun 17, 2024

@Astghik-S
Your ontology has passed the OBO NOR Dashboard and has been assigned to @deepakunni3 for reviewing.

@pfabry pfabry added the new ontology - reviewer response required Reviewer of this ontology needs to respond to an update or question. label Jun 17, 2024
@nlharris nlharris added the attn: OFOC call Issue to discuss on fortnightly OBO Operations meeting label Jun 25, 2024
@deepakunni3
Copy link
Member

deepakunni3 commented Jul 12, 2024

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:

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 volume
  • BMO:0000113 gray matter volume
  • BMO:0000131 N-Terminal Pro-B-Type Natriuretic Peptide
  • BMO: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 a
  • BMO:0000063 fibrinogen
  • BMO: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 biomarker
  • BMO:0000075 parmacodynamic biomarker
  • BMO: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 Triglyceride is a subclass of CHEBI:23367 Molecular Entity when in reality CHEBI:17855 Triglyceride is subclass of CHEBI: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 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.

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 ❔

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:0000070
    • BMO:0000072
    • BMO:0000073
    • BMO:0000098
    • BMO:0000100
    • BMO: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:0000009 monitoring biomarker
  • BMO:0000012 safety biomarker
  • BMO:0000015 surrogate biomarker
  • BMO:0000016 context of use
  • BMO:0000020 clinical sensitivity
  • BMO:0000022 probability of false negatives
  • BMO:0000025 companion diagnostics
  • BMO:0000037 kidney injury molecule-1
  • BMO:0000038 urine total potein
  • BMO:0000050 human epidermal growth factor receptor 2
  • BMO:0000060 d-dimer
  • BMO:0000061 Growth Differentiation Factor 15
  • BMO:0000063 fibrinogen
  • BMO:0000064 Creatine Kinase-MB
  • BMO:0000075 pharmacodynamic biomarker
  • BMO:0000083 augmentation index
  • BMO:0000091 sleep stage
  • BMO:0000092 blood glucose level
  • BMO:0000104 total cholesterol
  • BMO:0000120 amyloid deposition
  • BMO:0000130 gait unsteadiness
  • BMO:0000131 N-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

  • MUST change the term IRI from http://purl.obolibrary.org/obo/bmo.owl/BMO_ to http://purl.obolibrary.org/obo/BMO_ to match the OBO identifier scheme
  • SHOULD replace BMO:0000060 d-dimer with PR:000050369 D-dimer (human)
  • SHOULD replace BMO:0000061 Growth Differentiation Factor 15 with OMIT:0026290 Growth Differentiation Factor 15
  • SHOULD replace BMO:0000092 blood glucose level with CMO:0000046 blood glucose level
  • SHOULD look into the lexical match results and evaluate possible replacement terms from existing OBO Foundry ontologies
  • MUST add terms that overlap in scope to the respective ontologies (CMO, PRO, OPMI, OBI)
  • MUST look into the rdfs:subClassOf axioms added to imported terms to ensure that they are consistent with upstream ontologies
  • SHOULD add definition, rdfs:domain and rdfs:range information to BMO-specific object properties for better readability, interpretation and usage
  • 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.

@Astghik-S
Copy link
Author

Astghik-S commented Jul 12, 2024

@deepakunni3 Thank you for the review and comments. I shall check all mentioned points, address all, and come back to you!

@addiehl addiehl added new ontology - submitter action needed New ontology requests that have been reviewed and need changes in order to be accepted and removed attn: OFOC call Issue to discuss on fortnightly OBO Operations meeting new ontology - reviewer response required Reviewer of this ontology needs to respond to an update or question. labels Jul 22, 2024
@Astghik-S
Copy link
Author

Astghik-S commented Aug 7, 2024

@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.

@bpeters42 bpeters42 added new ontology - reviewer response required Reviewer of this ontology needs to respond to an update or question. and removed new ontology - submitter action needed New ontology requests that have been reviewed and need changes in order to be accepted labels Aug 20, 2024
@nlharris
Copy link
Contributor

nlharris commented Sep 3, 2024

@deepakunni3 just wondering if you've had a chance to circle back to this?

@deepakunni3
Copy link
Member

@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.

@deepakunni3
Copy link
Member

@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.

@Astghik-S
Copy link
Author

@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.

@deepakunni3
Copy link
Member

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 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 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,

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.

@deepakunni3 deepakunni3 added new ontology - submitter action needed New ontology requests that have been reviewed and need changes in order to be accepted and removed new ontology - reviewer response required Reviewer of this ontology needs to respond to an update or question. labels Oct 7, 2024
@Astghik-S
Copy link
Author

Astghik-S commented Oct 21, 2024

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 #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 #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.

@Astghik-S
Copy link
Author

Astghik-S commented Nov 2, 2024

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.

@deepakunni3
Copy link
Member

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 (#2643).

@nataled
Copy link
Contributor

nataled commented Nov 4, 2024

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.

@Astghik-S
Copy link
Author

Hi Darren,

Sure, we can meet and discuss. November 6 at 8 AM works for me.

@nataled
Copy link
Contributor

nataled commented Nov 6, 2024

@Astghik-S I need an email to send the meeting link.

@Astghik-S
Copy link
Author

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.

@deepakunni3
Copy link
Member

@Astghik-S Thank you for clarifying about BMONT as an application ontology.

Glad to hear that the discussions are ongoing with CMO (rat-genome-database/CMO-Clinical-Measurement-Ontology#14), PRO (PROconsortium/PRoteinOntology#338), and OPMI (OPMI/opmi#15).

We will discuss about BMONT on the next Operations Committee call (2024-11-26).

@nataled
Copy link
Contributor

nataled commented Nov 21, 2024

@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.

@pfabry
Copy link
Contributor

pfabry commented Nov 21, 2024

@nataled Yes, this is a problem in the config file. I will fix it. Thanks!

@nlharris nlharris added new ontology - reviewer response required Reviewer of this ontology needs to respond to an update or question. and removed new ontology - submitter action needed New ontology requests that have been reviewed and need changes in order to be accepted labels Nov 24, 2024
@deepakunni3
Copy link
Member

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.

@Astghik-S
Copy link
Author

Dear @deepakunni3 thank you very much for the final review of the BMONT.
What are the next steps now?

@deepakunni3
Copy link
Member

deepakunni3 commented Nov 26, 2024

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new ontology - reviewer response required Reviewer of this ontology needs to respond to an update or question. new ontology Use for new ontology registration requests
Projects
None yet
Development

No branches or pull requests

7 participants