New Ontology Request - DISDRIV - Disease Drivers

lschriml commented 3 years ago

Use this form to register a new ontology with the OBO Foundry. Please read the instructions provided here: http://obofoundry.org/docs/NewOntologyRegistrationInstructions.html

Requesting inclusion of this new application ontology to: http://purl.obolibrary.org/obo

Ontology title

Disease Drivers

Requested ID space

DISDRIV

requesting the ID space for the purl, but will not be creating IDs, as this is an application ontology

Ontology location

GitHub repository: https://github.com/DiseaseOntology/DiseaseDriversOntology

Contact person

Name: Lynn Schriml Email address: lschriml@som.umaryland.edu or lynn.schriml@gmail.com GitHub username: lschriml

Issue tracker

https://github.com/DiseaseOntology/DiseaseDriversOntology/issues

Ontology license

CC0 1.0 Universal https://github.com/DiseaseOntology/DiseaseDriversOntology/blob/main/LICENSE

[X ] CC0 (public domain)
[ ] CC-BY (version 3 or later)
[ ] Other: please specify

Available ontology formats

developed in OWL, will produce OBO file as part of release

What domain is the ontology intended to cover?

exposure stressors specific to those associated with disease

Related OBO Foundry ontologies

This application ontology is built with the upper level structure of Exposure Ontology (ExO). The list of exposure stressors was compiled in collaboration with ExO (Cynthia Grondin, @cjgrondin) and ECTO (Lauren Chan, @laurenechan ).

The ID and purl for each term in the proposed "Disease Drivers Ontology" have been identified from OBOFoundry ontologies. Including: ExO- Exposure ontology (10), CHEBI (42), OMIT - Ontology for MIRNA Target (10), ENVO (9), DRON - The Drug Ontology (1), NCIT - NCI Thesaurus OBO Edition (36), FOODON (1), FOBI - Food-Biomarker Ontology (1), HP (3), ZECO - Zebrafish Experimental Conditions Ontology (1), GSSO - Gender, Sex, and Sexual Orientation ontology (1) and one non-OBO : EFO (1)

Terms that did not already exist in an ontology were requested for inclusion in EnvO and CHEBI.

@amalik01 - 5 new ChEBI entries now created https://github.com/ebi-chebi/ChEBI/issues/4084#issuecomment-839599186

polyfluoroalkyl substance (CHEBI:172406) perfluoroalkyl substance (CHEBI:172397) glycol ether (CHEBI:172390) brominated flame retardant (CHEBI:172368) heavy metal (CHEBI:5631)

@pbuttigieg
https://github.com/EnvironmentOntology/envo/issues/1110#issuecomment-831319913

terms requested: secondhand smoke, mother to child smoking, hurricane, heat, strobing light
[in progress]
- ECTO term exposure to cigarette smoking via maternal (ECTO:0300003)

I identified ~ 120 terms, proposed to be incorporated into the Exposure Ontology, to be used in the Human Disease Ontology as an imported ontology for defining exposures related to human diseases.

Cynthia (CTD - ExO) and I put together a spreadsheet that maps most of these terms to other OBO Foundry ontologies (CHEBI, NCIT, ECTO, etc)

ECTO is:

adding new ECTO terms to provide 'exposure to X' terms for the proposed stressors
- issue to track these needs within ECTO
- https://github.com/EnvironmentOntology/environmental-exposure-ontology/issues/182

Emails from : ExO and ECTO: After discussing with the ECTO modeling team, we agree that inclusion of these terms or any other stressor terms used as variables in ECTO as children of 'exposure stressor' would be beyond the scope of ECTO

After discussion with the rest of the CTD team that originally developed ExO, we agree with Lauren's assessment that attempting to add many individual stressors as child terms of exposure stressor would initiate the creation of a giant branch in ExO that will be difficult to manage, grow constantly, duplicate existing work, and thus go beyond the scope of ExO. The intent is to keep ExO a high level schema for modeling exposures. However, it seems that many of the terms already exist and could be imported for your modeling purposes.

Intended use/related projects

Human Disease Ontology - intended use: for defining mechanisms of disease, specific to biological, chemical, physical and psychosocial agents and ecological perturbations.

Will maintain this application ontology, with all IDs/purl from other ontologies. As the inclusion of the 'exposure stressors' was beyond the scope of collaborating ontologies (ExO, ECTO), the solution to be able to ontologically model these stressors as related to human disease, was to create this discrete (and small) list of terms.

Related Projects: Exposure Ontology ECTO: Environmental conditions, treatments and exposures ontology

Additional comments or remarks

Requesting an OBO purl, to enable re-use of this application ontology.

Metadata

id: DISDRIV
title: The Disease Drivers Ontology
contact:
  email: lschriml@som.umaryland.edu
  label: Lynn Schriml
description: Ontology for drivers and triggers of human diseases, built to classify ExO ontology exposure stressors.
domain: health
homepage: https://github.com/DiseaseOntology/DiseaseDriversOntology
products:
  - id: DISDRIV.owl
  - id: DISDRIV.obo
dependencies:
  - id: ENVO, CHEBI, ExO, ECTO, OMIT, DRON, NCIT, FOODON, FOBI, HP, ZECO, GSSO

tracker: https://github.com/DiseaseOntology/DiseaseDriversOntology/issues 
license:
  url: https://creativecommons.org/publicdomain/zero/1.0/
  label: CC0
usages:
  - user: https://www.disease-ontology.org
    description: The Human Disease Ontology will import DISDRIV to define disease drivers and triggers via logical definitions.

matentzn commented 3 years ago

Hey @lschriml

I think 2, 3 tiny things to fix: https://obofoundry.github.io/obo-nor.github.io/dashboard/index.html

We will start with the review right after the "red" is gone from the dashboard. Thank you!

lschriml commented 3 years ago

Thank you Nico !! @matentzn

Love this new feature !!

[open] I see that 'open' failed: -- Can you help me identify the issue, perhaps syntax ??

         the error message is: 
      Ontology license 'https://creativecommons.org/publicdomain/zero/1.0' does not match registry  
                       license https://creativecommons.org/publicdomain/zero/1.0'

    in disease_drivers.owl: 
  <terms:license rdf:resource="https://creativecommons.org/publicdomain/zero/1.0"/>
</owl:Ontology>

   In Metadata: 
      license:
           url: https://creativecommons.org/publicdomain/zero/1.0/
          label: CC0

[versioning] Missing version IRI

--> I don't have an IRI, as there is no purl for this ontology. For the Ontology IRI, I used: https://github.com/DiseaseOntology/HumanDiseaseOntology/tree/main/src/ontology/imports/disease_drivers.owl

Not sure how to solve this error without a 'purl' ?? I've not yet created any releases. Would including the Ontology IRI in the Ontology Version IRI solve this issue until there is a purl ?

Thanks for your help Nico !!

Cheers, Lynn

matentzn commented 3 years ago

About your issue with license: I think in your ontology, you simply need to add a slash to the end of the license to be

  <terms:license rdf:resource="https://creativecommons.org/publicdomain/zero/1.0/"/>

rather than

  <terms:license rdf:resource="https://creativecommons.org/publicdomain/zero/1.0"/>

For your other issue you should consider creating a release - it may indeed not make too much sense to create a version IRI for the edit file.

We recommend creating two releases profiles: full, and base. The linked docs show how the version IRI is added.

Let me know if you need help with ROBOT, or you could ask Becky. Once you have a (provisional) release file (does not have to be official), let me know, and I will re-run the dashboard again :)

lschriml commented 3 years ago

Thank you Nico !!

The / has been added. Updated the IRI, version IRI and made an initial release.

http://purl.obolibrary.org/obo/disdriv/releases/2021-05-18/disdriv.owl

Thank you for all of your help and coordinating the dashboard runs.

Much appreciated, Lynn

bpeters42 commented 3 years ago

Hi Lynn: This will obviously be for the broader call, but I am not sure that this falls under 'application ontology'? We really need to define that better, but for me that implies that there is a specific application (like a database, or a tool) that makes it necessary to pull things together from different ontologies. Here, it seems that you are covering a domain that re-uses other ontologies, but I don't see the application (and I may have just missed it). Anyway, I think this domain is getting very crowded, and we should be more careful than normal to not add to the confusion. Not sure how helpful this is, and I am stuck with grant writing until June, so apologies in advance for raising and not following through.

lschriml commented 3 years ago

Hello Bjoern, Thanks for the thoughts. This ontology is for a specific application. To enable annotation of exposure stressors that result in disease. We will utilize these stressors in the disease ontology. There is interest in exposure stressors in both ExO and ECTO ontologies, but not the band width to integrate them. Though no one else is defining the stressors themselves as a group of terms. Specifically, in how they are drivers and triggers of disease. Fortunately, the majority of terms are defined in their pertinent domain ontologies. Thus this application ontology sources the terms from these ontologies for a new purpose. Environmental, chemical, physical, psychosocial agents and environmental perturbations will aid in further refining the contribution of environmental (etc) contributions to disease mechanisms Alternatively, I could pull in imports from each of the source ontologies for the pertinent terms individual. However, this would be a more hodgepodge approach, and would not be sharable. As an application ontology, it is a defined space of knowledge and sharable.

Cheers, Lynn

Sent from my iPhone

On May 18, 2021, at 7:21 PM, bpeters42 @.***> wrote:

Hi Lynn: This will obviously be for the broader call, but I am not sure that this falls under 'application ontology'? We really need to define that better, but for me that implies that there is a specific application (like a database, or a tool) that makes it necessary to pull things together from different ontologies. Here, it seems that you are covering a domain that re-uses other ontologies, but I don't see the application (and I may have just missed it). Anyway, I think this domain is getting very crowded, and we should be more careful than normal to not add to the confusion. Not sure how helpful this is, and I am stuck with grant writing until June, so apologies in advance for raising and not following through.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

laurenechan commented 3 years ago

Hi, I just wanted to weigh in on this ticket. I have been working on ECTO in order to define environmental and nutrition causes of disease in Mondo for my thesis work. I have also put together an ICBO paper about our work to date on this topic. AFAIK, we have been responsive to all requests for encoding environmental stressors within ECTO. If we are missing anything, it is most helpful to document requests/needs on our tracker. Thanks!

lschriml commented 3 years ago

Thank you Lauren. You have been super helpful regarding these terms (X), adding them to ECTO’s ‘exposure to X’.

Cheers, Lynn

Sent from my iPhone

On May 19, 2021, at 5:36 PM, Lauren @.***> wrote:

Hi, I just wanted to weigh in on this ticket. I have been working on ECTO in order to define environmental and nutrition causes of disease in Mondo for my thesis work. I have also put together an ICBO paper about our work to date on this topic. AFAIK, we have been responsive to all requests for encoding environmental stressors within ECTO. If we are missing anything, it is most helpful to document requests/needs on our tracker. Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

pbuttigieg commented 3 years ago

Hi all, I saw a few ENVO classes in here and took a look at the ontology. I'm not sure about a few things:

I see ENVO classes, with the same PURLs, but different definitions which have been spliced into other hierarchies (e.g. ENVO_01000677, ENVO_00002003). This really changes the semantics of the imported ontologies and I don't think this is "right" according to the Principles or just good engineering practice
I note several hierarchy rearrangements that don't really work, like having algal blooms as a chemical agent. The upper-level alignment doesn't really seem consistent.

To me, this is pretty major stuff which could hurt a bunch of things up- and downstream

cmungall commented 3 years ago

Thanks @pbuttigieg - it looks like CHEBI classes are also being rewired in a similar way? I wonder if this is intentional?

lschriml commented 3 years ago

The definitions were initially written to be part of ExO. I appreciate @pbuttigieg and @mungall comments. Agree, definitions should be sourced from primary ontology. I will update DISDRIV definitions.

Cheers, Lynn

Sent from my iPhone

On May 25, 2021, at 12:51 PM, Chris Mungall @.***> wrote:

Thanks @pbuttigieg - it looks like CHEBI classes are also being rewired in a similar way? I wonder if this is intentional?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

pbuttigieg commented 3 years ago

Thanks @lschriml - I think the same applies to the subclass hierarchies - other axioms should be used to link, e.g., earthquakes to ecological perturbations, without changing the import hierarchies (and thus the machine-readable semantics)

lschriml commented 3 years ago

Agreed !!

On Tue, May 25, 2021 at 3:24 PM Pier Luigi Buttigieg < @.***> wrote:

Thanks @lschriml https://github.com/lschriml - I think the same applies to the subclass hierarchies - other axioms should be used to link, e.g., earthquakes to ecological perturbations, without changing the import hierarchies (and thus the machine-readable semantics)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1508#issuecomment-848199878, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBB4DN3XFNLDR3GFYW32NLTPP2OZANCNFSM45A7M5YQ .

-- Lynn M. Schriml, Ph.D. Associate Professor

Institute for Genome Sciences University of Maryland School of Medicine Department of Epidemiology and Public Health 670 W. Baltimore St., HSFIII, Room 3061 Baltimore, MD 21201 P: 410-706-6776 | F: 410-706-6756 @.***

lschriml commented 3 years ago

Axioms and definitions updated. https://github.com/DiseaseOntology/DiseaseDriversOntology/blob/main/src/ontology/releases/disease_drivers.owl

pbuttigieg commented 3 years ago

Sorry, @lschriml - I still see multiple ENVO classes with modified definitions and placed in alternative hierarchies. This doesn't really work with the OBO Principles or good practice.

Examples here, here (how can an algal bloom be a chemical agent?), and here (that ExO class should be in ENVO).

lschriml commented 3 years ago

Thank you Pier !! I have made the updates. I think you may have been looking at an older file. The updated file is at: https://github.com/DiseaseOntology/DiseaseDriversOntology/blob/main/src/ontology/disease_drivers.owl The terms are linked to ExO terms (e.g. biological agent) with 'has_role' only. Would this be acceptable ?

Algal bloom: I was listing it as a chemical agent, due to the toxin produced by the algal bloom. Perhaps this term should be 'harmful algal bloom' or 'harmful algal bloom toxin' and be moved to 'toxin' category What do you think ?

Cheers, Lyn

On Mon, Jun 7, 2021 at 12:16 PM Pier Luigi Buttigieg < @.***> wrote:

Sorry, @lschriml https://github.com/lschriml - I still see multiple ENVO classes with modified definitions and placed in alternative hierarchies. This doesn't really work with the OBO Principles or good practice.

Examples here https://github.com/DiseaseOntology/DiseaseDriversOntology/blob/f292b65c604f17961363e787bb6b4e7716f99cbd/src/ontology/releases/disease_drivers.owl#L873-L886, here https://github.com/DiseaseOntology/DiseaseDriversOntology/blob/f292b65c604f17961363e787bb6b4e7716f99cbd/src/ontology/releases/disease_drivers.owl#L990-L1004 (how can an algal bloom be a chemical agent?), and here https://github.com/DiseaseOntology/DiseaseDriversOntology/blob/f292b65c604f17961363e787bb6b4e7716f99cbd/src/ontology/releases/disease_drivers.owl#L1109-L1125 (that ExO class should be in ENVO).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1508#issuecomment-856075710, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBB4DKM5WA5UCTERBPP5JLTRTWHTANCNFSM45A7M5YQ .

-- Lynn M. Schriml, Ph.D. Associate Professor

Institute for Genome Sciences University of Maryland School of Medicine Department of Epidemiology and Public Health 670 W. Baltimore St., HSFIII, Room 3061 Baltimore, MD 21201 P: 410-706-6776 | F: 410-706-6756 @.***

pbuttigieg commented 3 years ago

@lschriml

Using the link above, I'm still seeing modifications and re-arrangements in the hierarchies, e.g. here

lschriml commented 3 years ago

@Pier Luigi Buttigieg @.***> -- thank you !! Fixed.

Cheers, Lynn

On Mon, Jun 14, 2021 at 6:20 AM Pier Luigi Buttigieg < @.***> wrote:

@lschriml https://github.com/lschriml

Using the link above, I'm still seeing modifications and re-arrangements in the hierarchies, e.g. here https://github.com/DiseaseOntology/DiseaseDriversOntology/blob/main/src/ontology/disease_drivers.owl#L1146-L1159

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1508#issuecomment-860572542, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBB4DISMNU4BMW2EQF57EDTSXJVPANCNFSM45A7M5YQ .

-- Lynn M. Schriml, Ph.D. Associate Professor

Institute for Genome Sciences University of Maryland School of Medicine Department of Epidemiology and Public Health 670 W. Baltimore St., HSFIII, Room 3061 Baltimore, MD 21201 P: 410-706-6776 | F: 410-706-6756 @.***

pbuttigieg commented 3 years ago

Thanks @lschriml looks like the original definitions are now in play, but I don't know how to evaluate the rewiring bit - the terms seem to still be reshuffled, which messes with the semantics from the ENVO side.

Connects back to the need to have more clear policies and types of OBO artifact

There is still a content-level issue with statements like this:

An algal bloom (a process in ENVO, now just a Thing) having a role of chemical agent doesn't really work. Similar with fire - it has a role "ecological perturbations" coming from ExO, but that's just a "Thing" in Exo (it seems). Not sure what's going on.

cmungall commented 3 years ago

This still injects via inference, e.g copper (CHEBI) is a subclass of deficiency:

It also injects that some CHEBI structures are subclasses of CHEBI roles:

This will cause unsatisfiable classes when this is combined with other ontologies

it looks like equivalence axioms are being injected into CHEBI roles:

has-role axioms are injected onto ENVO processes:

lschriml commented 3 years ago

Thank you Pier !!

How should it be structured ? Should I be pulling in the upper level hierarchy for each term ?

Cheers, Lynn

Sent from my iPhone

On Jun 29, 2021, at 12:46 PM, Pier Luigi Buttigieg @.***> wrote:

Thanks @lschriml looks like the original definitions are now in play, but I don't know how to evaluate the rewiring bit - the terms seem to still be reshuffled, which messes with the semantics from the ENVO side.

Connects back to the need to have more clear policies and types of OBO artifact

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

pbuttigieg commented 3 years ago

How should it be structured ? Should I be pulling in the upper level hierarchy for each term ?

I'm not sure - it depends on OBO policy in general: if this is more a flat list of terms, then the evaluation criteria would be different from an ontology proper. But we don't have categories of semantic artifact with different criteria, so I don't really know what to do.

lschriml commented 3 years ago

I see your points.

What is the best solution forward ?

Is it not allowed to infer roles that are beyond the scope of the initial ontology ?

On Jun 29, 2021, at 12:56 PM, Chris Mungall @.***> wrote:

This still injects via inference, e.g copper (CHEBI) is a subclass of deficiency:

It also injects that some CHEBI structures are subclasses of CHEBI roles:

This will cause unsatisfiable classes when this is combined with other ontologies

it looks like equivalence axioms are being injected into CHEBI roles:

has-role axioms are injected onto ENVO processes:

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

pier commented 3 years ago

Folks, you have the wrong "Pier" in this thread.

Cheers

Pier Kuipers

On Tue 29 Jun 2021, 18:08 lschriml, @.***> wrote:

I see your points.

What is the best solution forward ?

Is it not allowed to infer roles that are beyond the scope of the initial ontology ?

On Jun 29, 2021, at 12:56 PM, Chris Mungall @.***> wrote:

This still injects via inference, e.g copper (CHEBI) is a subclass of deficiency:

It also injects that some CHEBI structures are subclasses of CHEBI roles:

This will cause unsatisfiable classes when this is combined with other ontologies

it looks like equivalence axioms are being injected into CHEBI roles:

has-role axioms are injected onto ENVO processes:

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1508#issuecomment-870769751, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAGGWRSYOJ6X2YY7VV53E3TVH4XXANCNFSM45A7M5YQ .

lschriml commented 3 years ago

has role: see: http://www.ontobee.org/ontology/ECTO?iri=http://purl.obolibrary.org/obo/CHEBI_15407

has role some xenobiotic has role some vasoconstrictor agent has role some plant metabolite has role some bacterial metabolite

cobalamin http://www.ontobee.org/ontology/ECTO?iri=http://purl.obolibrary.org/obo/CHEBI_30411

has role some B vitamin

cmungall commented 3 years ago

see: http://www.ontobee.org/ontology/ECTO?iri=http://purl.obolibrary.org/obo/CHEBI_15407

yes, these axioms come from CHEBI

see: http://www.ontobee.org/ontology/CHEBI?iri=http://purl.obolibrary.org/obo/CHEBI_15407

CHEBI has two hierarchies - structures and roles. The has-role relation generally connects material entities to roles - I haven't seen second order roles (roles with roles) or processes with roles before. These aren't allowed by BFO, but RO is less restrictive

What is the best solution forward ?

I would take one of three paths. just describing briefly now as am on a call

similar to what you are doing but with a new relation
- this would be very broad such that the domain could be processes, roles, material entities
- you would still be injecting by inference but only to your own hierarchy which would stand apart from bfo/cob
create shadow classes that represents the stressor aspect
just make a standard module using robot extract
- you won't get a hierarchy that places things under stressor etc, but is this really required?

Either way, I would make a release version that is pre-inferred. Right now if you open the owl file without reasoning it will look like a flat list. Some ontology browsers will not pre-reason, and this will look like a flat list to users

ddooley commented 3 years ago

Will iterate on some structural changes for deficiency structure etc.
Call discussion about policy around application ontologies, passing dashboard at a minimum, and beyond that OBO policy on subclass satisfiability. Discussed importation of concepts from ontology B to ontology A. Problematic scenario where B isn't itself satisfiability. Onus is not on ontology A to fix that.

nlharris commented 2 years ago

What is the status of this? Are we waiting for submitter action, or are they waiting for feedback from OBO Foundry?

lschriml commented 2 years ago

We are waiting for me (the submitter) to complete the requested revisions. Please mark this request as in progress. Cheers, Lynn

On Sat, Aug 21, 2021 at 3:08 PM Nomi Harris @.***> wrote:

What is the status of this? Are we waiting for submitter action, or are they waiting for feedback from OBO Foundry?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1508#issuecomment-903162708, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBB4DPMXXYCCNY6K3T4HHDT572TVANCNFSM45A7M5YQ .

-- Lynn M. Schriml, Ph.D. Associate Professor

Institute for Genome Sciences University of Maryland School of Medicine Department of Epidemiology and Public Health 670 W. Baltimore St., HSFIII, Room 3061 Baltimore, MD 21201 P: 410-706-6776 | F: 410-706-6756 @.***

lschriml commented 2 years ago

A revised file is ready for review: https://github.com/DiseaseOntology/DiseaseDriversOntology/blob/main/src/ontology/releases/disdriv.owl

cmungall commented 2 years ago

Thanks!

Just some quick comments

The ontology is much smaller - is this intentional? is it intended as an exemplar of a future approach or were things omitted unintentionally

Here is a visualization:

The injection issue is vastly reduced: there are no longer any ENVO classes.

There is still some injection happening:

CHEBI:alcohol is-a FOODON:beverage is-a disease-driver

I am not sure this is consistent with either the CHEBI meaning (a small molecule is not a beverage) or the foodon one (every beverage is a disease driver)

lschriml commented 2 years ago

Thank you Chris !! This is an exemplar, to see if this structure is what the committee wanted.

Regarding the injection: alcohol is_a (child of) alcoholic beverage in FoodOn and In ECTO, moving up the tree for alcoholic beverage are several FoodOn parents (up to FoodOn's 'food material'), with an EnvO parent class 'environmental material' at the top. In EnvO 'food material' is not a child of 'environmental material'

I've attached a screen shot. https://www.ebi.ac.uk/ols/ontologies/ecto/terms?iri=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FCHEBI_30879

In the Experimental Condition Ontology (XCO), alcohol is a child of 'chemical with specified structure' XCO:0000323 https://www.ebi.ac.uk/ols/ontologies/xco/terms?iri=http%3A%2F%2Fpurl.obolibrary.org%2Fobo%2FXCO_0000323

Is there a different or more appropriate way to include terms, such as alcohol, where the parent term is not a ChEBI term ?

I see that sometimes, when a term is reused from another ontology, the entire hierarchy up to a common parent term ? In other ontologies, the term is a child of a new parent term.

Is the FoodOn - EnvO example also a case of 'injection' ??

Is there some guidance about injecting or re-using of classes from one ontology while asserting different parent classes in another ontology ?

Cheers, Lynn

On Wed, Sep 29, 2021 at 12:58 PM Chris Mungall @.***> wrote:

Thanks!

Just some quick comments

The ontology is much smaller - is this intentional? is it intended as an exemplar of a future approach or were things omitted unintentionally

Here is a visualization:

[image: image] https://user-images.githubusercontent.com/50745/135314313-9d0a48ae-f82c-44b2-a0ab-707bc169601b.png

The injection issue is vastly reduced: there are no longer any ENVO classes.

There is still some injection happening:

[image: image] https://user-images.githubusercontent.com/50745/135314664-60fb6373-b82e-4a86-ad0d-d85bbfdf16f0.png

CHEBI:alcohol is-a FOODON:beverage is-a disease-driver

I am not sure this is consistent with either the CHEBI meaning (a small molecule is not a beverage) or the foodon one (every beverage is a disease driver)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1508#issuecomment-930359584, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBB4DJZH3TLDT3V35WESODUENATFANCNFSM45A7M5YQ .

-- Lynn M. Schriml, Ph.D. Associate Professor

Institute for Genome Sciences University of Maryland School of Medicine Department of Epidemiology and Public Health 670 W. Baltimore St., HSFIII, Room 3061 Baltimore, MD 21201 P: 410-706-6776 | F: 410-706-6756 @.***

balhoff commented 2 years ago

I opened an issue with FOODON: https://github.com/FoodOntology/foodon/issues/161

lschriml commented 2 years ago

And noting here the injection of terms Issue noted on the above FoodOn ticket OBOFoundry/OBOFoundry.github.io#1443

So my question is: how do we properly reuse terms from ontologies to continue to build knowledge in new ontologies ?

Second: Can DISDRIV be given a PURL as this issue is discussed ?

cmungall commented 2 years ago

This is an exemplar, to see if this structure is what the committee wanted.

I see. This helps me a bit, but I am struggling a bit to see what the intended path forward is, because the new ontology is so small. Will future versions include more chebi terms beyond 'alcohol' and how will they be placed? Will it include ENVO, as previous versions did?

Can DISDRIV be given a PURL as this issue is discussed ?

I suggest this is discussed at the next OBO call - does that seem OK?

My questions here don't constitute a vote for or against, just trying to understand more. Hopefully others in OBO will comment here

I believe on the last call when this was discussed, some thought this seemed similar to a standard "robot extract" that many ontologies do (my option "3" further above). (sorry, don't have notes handy, going by recollection). If so then you could have a purl under the DO namespace which you control. I know Becky is off but others members of the TWG should be able to help here.

lschriml commented 2 years ago

Thank you Chris.

There are other terms to add. There will be around 100 terms in DISDRIV. The intent is to include the full list of disease drivers.

Before I do that, I need input from the committee first on how to proceed. Specifically, Can I include terms, as mentioned above, as 'injections'?? See XCO and FoodOn examples in previous posts.

     Can other ChEBI terms be 'siblings' of 'alcohol' ?

If yes, then I will proceed to add other disease drivers.

If not, then I ask how am I able to reuse terms from other ontologies in this ontology ? As the OBO Foundry encourages term reuse. Or is it anticipated that I will need to create new terms, rather than reuse terms ??

Cheers, Lynn

On Fri, Oct 1, 2021 at 11:58 AM Chris Mungall @.***> wrote:

This is an exemplar, to see if this structure is what the committee wanted.

I see. This helps me a bit, but I am struggling a bit to see what the intended path forward is, because the new ontology is so small. Will future versions include more chebi terms beyond 'alcohol' and how will they be placed? Will it include ENVO, as previous versions did?

Can DISDRIV be given a PURL as this issue is discussed ?

I suggest this is discussed at the next OBO call - does that seem OK?

My questions here don't constitute a vote for or against, just trying to understand more. Hopefully others in OBO will comment here

I believe on the last call when this was discussed, some thought this seemed similar to a standard "robot extract" that many ontologies do (my option "3" further above). (sorry, don't have notes handy, going by recollection). If so then you could have a purl under the DO namespace which you control. I know Becky is off but others members of the TWG should be able to help here.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1508#issuecomment-932352891, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBB4DLY4H4TFIJU6LUOQOLUEXLCXANCNFSM45A7M5YQ .

-- Lynn M. Schriml, Ph.D. Associate Professor

Institute for Genome Sciences University of Maryland School of Medicine Department of Epidemiology and Public Health 670 W. Baltimore St., HSFIII, Room 3061 Baltimore, MD 21201 P: 410-706-6776 | F: 410-706-6756 @.***

balhoff commented 2 years ago

Discussed in the operations call on 2021-10-19: it would be preferred if the hierarchy were modeled using existential restrictions, rather than the is_a relation. Could you define your classes in this way?

(I made up the 'driven by' object property; the specific one to use is up for discussion)

DISDRIV:'carbon monoxide disease driver' EquivalentTo DISDRIV:'disease driver' and ('driven by' some CHEBI:'carbon monoxide')

This design pattern is similar to those being used in ECTO—maybe there is room for collaboration there also.

matentzn commented 2 years ago

I was not part of the discussion, but do I understand it correctly that you want to annotate and analyse disease drivers in DO? SO basically, you want to say:

DO:001 has_driver CHEBI:001?

In that case, I would suggest the following:

Find or define a good relation to describe the relation between the disease and the ontology
Create a simple DOSDP or ROBOT template that captures a few analytic classes like "chemical disease driver" and define them along the lines of what @balhoff suggests. That way you can group them and analyse them. I am not sure whether "CHEBI:001 disease driver" is necessary - danger of shadow class bombing.
Align this a bit with the ECTO patterns. Would you say that a disease driver is somehow analogous to a "stimulus" in ECTO? How does it differ?

Sorry for barging in. Hope this is not causing additional confusion..

lschriml commented 2 years ago

Thank you all for the constructive feedback for DISDRIV.

Feedback: it would be preferred if the hierarchy were modeled using existential restrictions, rather than the is_a relation. Could you define your classes in this way? DISDRIV:'carbon monoxide disease driver' EquivalentTo DISDRIV:'disease driver' and ('driven by' some CHEBI:'carbon monoxide'). This design pattern is similar to those being used in ECTO—maybe there is room for collaboration there also.

--> Yes, agreed, following the ECTO design pattern is a good approach.

I have revised disdriv.owl, pushed to our GitHub, https://github.com/DiseaseOntology/DiseaseDriversOntology/blob/main/src/ontology/disdriv.owl

I think this aligns with @balhoff suggestions. Example: for 'alcohol driver', EQ: 'chemical driver' and ('causes condition' some alcohol)

I used the relation 'causes condition' until a new relation can be created.

To complete these revisions, I am requesting a new relation,(as suggested by @matentzn ) to use instead of 'causes condition'.

--> I am proposing a new relation, (following how 'has allergic trigger' has been defined in RO.)

  New Relation: 'has disease driver' 
   Definition: A relation between a material entity and a disease of a host, in which the material entity is not part of the host itself, and the condition results in pathological processes.

I have submitted a RO ticket: https://github.com/oborel/obo-relations/issues/506

for reference: RO: 'causes condition': Definition: A relationship between an entity (e.g. a genotype, genetic variation, chemical, or environmental exposure) and a condition (a phenotype or disease), where the entity has some causal role for the condition.

screen shots at

tached.

Feedback: Align this a bit with the ECTO patterns. Would you say that a disease driver is somehow analogous to a "stimulus" in ECTO? How does it differ? --> Thank you @matentzn -- I have aligned DISDRIV to ECTO design patterns.

A disease driver is analogous to the 'agent' in the ExO 'exposure stressor' definition. ExO's 'exposure stressor' (ExO:0000000) used in ECTO: An agent, stimulus, activity, or event that causes stress or tension on an organism and interacts with an exposure receptor during an exposure event.

-- 'disease driver' is utilized to describe epidemiological mechanisms, (https://www.ncbi.nlm.nih.gov/labs/pmc/articles/PMC4517741/)

in DISDRIV: defn: an environmental or genetic mechanisms driving the occurrance of complex diseases.

-- a driver differs from a stimulus, as the driver defines a 'cause and effect' mechanism -- a stimulus is a catalyst, a stimulus can trigger a change. e.g. in allergic asthma, the asthma attack is 'triggered' by specific allergens. In this case, the 'allergen' is the stimulus

       However, 'allergens' do not drive the occurrence of asthma. 
            Chronic asthma results from specific pathophysiological mechanisms.

Driver: the thing that made the disease (contribution to disease state, not reversible) Trigger: the thing that triggers an exacerbation/attack; reversible

Cheers, Lynn

matentzn commented 2 years ago

Thank you @lschriml . Almost there, hope you don't mind the back and forth about this. This is a hugely important topic to align on, and it would give me great happiness if we did. Please email/slack me if you feel this is getting too much in the weeds, but I think this is the right direction, and I would like to solve it in a way that we can all make use of. Just some questions for my own understanding:

Ontologically, we care about three things:

The driver (alcohol), i.e. the entity that is causally responsible for the emergence of the disease (thank you for distinguishing driver and stimulus, this was very useful for me to know)
The driver aspect of alcohol (alcohol disease driver), i.e. the aspect of the entity that is causally responsible for the disease.
The disease (fetus alcohol syndrome)

Would you say that this here is a reasonable characterisation of what you are proposing (I changed the relation names a bit):

fetus alcohol syndrome ---[condition caused by]--->alcohol disease driver-->[aspect of]-->alcohol

In this case, there is one other option we should consider (to align, I mean, if that is of interest).

What we say usually when we want to express the above, is:

fetus alcohol syndrome ---[realised in response to]--->exposure to alcohol-->[has exposure stimulus]-->alcohol

This looks almost like what you want here, apart from the fact that it fails to distinguish the trigger aspect from the causal driver aspect.

However, if we were to strengthen the realised in response to relationship just a tiny bit, we could get exactly what you need (if I understand this very difficult thread here correctly I mean):

fetus alcohol syndrome ---[condition caused by]--->exposure to alcohol-->[has exposure stimulus]-->alcohol

Now, you can use your "has disease driver" relation like this:

'has disease driver' subPropertyChainOf: 'condition caused by' o 'has exposure stimulus'

In Protege, you then simply say something like:

fetus alcohol syndrome --[condition caused by]-->exposure to alcohol

Then you run the reasoner, and you get:

fetus alcohol syndrome --[has disease driver]-->alcohol

Obviously, you can also just assert

fetus alcohol syndrome --[has disease driver]-->alcohol

The advantage of doing it this way is:

avoiding another round of shadow classes (alcohol disease driver, chemical disease driver, etc) alongside exposures (alcohol exposure, chemical exposure), which are weaker, but can be strengthened to your use case using object properties. All these different "aspect" classes are becoming a bit of a problem for downstream curators, that get this list: alcohol, alcohol disease driver, alcohol exposure, alcohol consumption, and many more, and do not know what to use anymore.
you could start collaborating on common patterns through ECTO

In any case, even if you disagree with my suggestion, which is fair, this was a very good exercise for my mind to think about aspects, design patterns and so on, and I learned quite a bit thinking it through. In that case (you disagree and want to use your modelling), the only thing I think that remains is find the appropriate relationship between the driver class and the entity that is doing the driving (assuming that "has disease driver" connects the disease with the entity).

lschriml commented 2 years ago

Thank you Nico !! It is very helpful to go through this thought process. I’m curious, how are stimulus, exposure stimulus and ‘aspect of’ defined ? Looking forward to further discussions !!

Cheers, Lynn

Sent from my iPhone

On Nov 1, 2021, at 4:57 AM, Nico Matentzoglu @.***> wrote:

Thank you @lschriml . Almost there, hope you don't mind the back and forth about this. This is a hugely important topic to align on, and it would give me great happiness if we did. Please email/slack me if you feel this is getting too much in the weeds, but I think this is the right direction, and I would like to solve it in a way that we can all make use of. Just some questions for my own understanding:

Ontologically, we care about three things:

The driver (alcohol), i.e. the entity that is causally responsible for the emergence of the disease (thank you for distinguishing driver and stimulus, this was very useful for me to know) The driver aspect of alcohol (alcohol disease driver), i.e. the aspect of the entity that is causally responsible for the disease. The disease (fetus alcohol syndrome) Would you say that this here is a reasonable characterisation of what you are proposing (I changed the relation names a bit):

fetus alcohol syndrome ---[condition caused by]--->alcohol disease driver-->[aspect of]-->alcohol In this case, there is one other option we should consider (to align, I mean, if that is of interest).

What we say usually when we want to express the above, is:

fetus alcohol syndrome ---[realised in response to]--->exposure to alcohol-->[has exposure stimulus]-->alcohol This looks almost like what you want here, apart from the fact that it fails to distinguish the trigger aspect from the causal driver aspect.

However, if we were to strengthen the realised in response to relationship just a tiny bit, we could get exactly what you need (if I understand this very difficult thread here correctly I mean):

fetus alcohol syndrome ---[condition caused by]--->exposure to alcohol-->[has exposure stimulus]-->alcohol Now, you can use your "has disease driver" relation like this:

'has disease driver' subPropertyChainOf: 'condition caused by' o 'has exposure stimulus' In Protege, you then simply say something like:

fetus alcohol syndrome --[condition caused by]-->exposure to alcohol Then you run the reasoner, and you get:

fetus alcohol syndrome --[has disease driver]-->alcohol Obviously, you can also just assert

fetus alcohol syndrome --[has disease driver]-->alcohol The advantage of doing it this way is:

avoiding another round of shadow classes (alcohol disease driver, chemical disease driver, etc) alongside exposures (alcohol exposure, chemical exposure), which are weaker, but can be strengthened to your use case using object properties. All these different "aspect" classes are becoming a bit of a problem for downstream curators, that get this list: alcohol, alcohol disease driver, alcohol exposure, alcohol consumption, and many more, and do not know what to use anymore. you could start collaborating on common patterns through ECTO In any case, even if you disagree with my suggestion, which is fair, this was a very good exercise for my mind to think about aspects, design patterns and so on, and I learned quite a bit thinking it through. In that case (you disagree and want to use your modelling), the only thing I think that remains is find the appropriate relationship between the driver class and the entity that is doing the driving (assuming that "has disease driver" connects the disease with the entity).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

matentzn commented 2 years ago

Great :)

Exposure stimulus seems to be roughly defined as: Any agent, entity, activity, or event that causally effects an organism and interacts with an exposure receptor during an exposure event..

aspect of is my own invention which we should get back to when we get agreement on the rest. I just could not think about an appropriate relationship connecting your notion of disease driver with alcohol. Perhaps, characteristic of is better, and driver could be modelled as a quality.

lschriml commented 2 years ago

No objections raised. If @lschriml decides to move forward with DISDRIV. Will apply disease driver pattern. Will work with ECTO. Will submit request for PURL.

matentzn commented 2 years ago

For the future, a more detailed summary of our great discussion during the call.

The concern we discussed in great detail and all agreed on is that the concept of "disease driver" and "exposure stressor" are extremely close together, and the introduction of a new shadow hierarchy of "alcohol disease driver" alongside "alcohol exposure" will complicate the situation for users that find suitable terms to model their data. The reason we stuck hard to this discussion was that we acknowledge that user confusion is something that we all want to avoid.

Basically, @lschriml now has to make a decision:

She withdraws the request for DISDRIV and works with the ECTO team to get exposure terms that she needs to model disease drivers in the way I suggested in my last post, using something like fetus alcohol syndrome --[condition caused by]-->exposure to alcohol, from which she will be able to infer directly fetus alcohol syndrome --[has driver]-->alcohol. This way, we do not need another set of terms at all.
She decides that modelling using the exposure terms does not reflect her intention well enough, and goes ahead building a shadow hierarchy of disease driver terms, as outlined by @balhoff above. In DO, she can then use fetus alcohol syndrome --[condition caused by]-->alcohol disease driver, which will, again, enable her to infer the fetus alcohol syndrome --[has driver]-->alcohol in much the same way as the other proposal.

The OFOC decided that either way is fine to go. If @lschriml decides to go with 2, she will add the yaml and markdown files, and here ontology is considered accepted.

cmungall commented 2 years ago

Thanks for the summary. I would also recommend that if there is intent to submit an ontology for a concept like disease driver we open an issue on the COB repo to place this new high level concept somewhere

On Wed, Nov 3, 2021 at 9:33 AM Nico Matentzoglu @.***> wrote:

For the future, a more detailed summary of our great discussion during the call.

The concern we discussed in great detail and all agreed on is that the concept of "disease driver" and "exposure stressor" are extremely close together, and the introduction of a new shadow hierarchy of "alcohol disease driver" alongside "alcohol exposure" will complicate the situation for users that find suitable terms to model their data. The reason we stuck hard to this discussion was that we acknowledge that user confusion is something that we all want to avoid.

Basically, @lschriml https://github.com/lschriml now has to make a decision:

She withdraws the request for DISDRIV and works with the ECTO team to get exposure terms that she needs to model disease drivers in the way I suggested in my last post, using something like fetus alcohol syndrome --[condition caused by]-->exposure to alcohol, from which she will be able to infer directly fetus alcohol syndrome --[has driver]-->alcohol. This way, we do not need another set of terms at all.

She decides that modelling using the exposure terms does not reflect her intention well enough, and goes ahead building a shadow hierarchy of disease driver terms, as outlined by @balhoff https://github.com/balhoff above. In DO, she can then use fetus alcohol syndrome --[condition caused by]-->alcohol disease driver, which will, again, enable her to infer the fetus alcohol syndrome --[has driver]-->alcohol in much the same way as the other proposal.

The OFOC decided that either way is fine to go. If @lschriml https://github.com/lschriml decides to go with 2, she will add the yaml and markdown files, and here ontology is considered accepted.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1508#issuecomment-959667676, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOJUHIAAUJEVMIMTYP3UKFP7DANCNFSM45A7M5YQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

laurenechan commented 2 years ago

This has been a lot of good conversation regarding the use cases for this ontology. From an ECTO perspective, we are very happy to collaborate and assist how we can to support modeling of both exposures leading to disease onset as well as exposures exacerbating existing disease. ECTO is intended to be applicable in both of those use cases of disease causality and attacks as were stated as the differentiation between a driver and a stimulus. ECTO is working on incorporating some of the exposures requested for use in DO and we will continue to chisel away at that list to support the use case if still needed.

cmungall commented 2 years ago

On Thu, Nov 4, 2021 at 2:25 PM Lauren @.***> wrote:

This has been a lot of good conversation regarding the use cases for this ontology. From an ECTO perspective, we are very happy to collaborate and assist how we can to support modeling of both exposures leading to disease onset as well as exposures exacerbating existing disease. ECTO is intended to be applicable in both of those use cases of disease causality and attacks as were stated as the differentiation between a driver and a stimulus. ECTO is working on incorporating some of the exposures requested for use in DO and we will continue to chisel away at that list to support the use case if still needed.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1508#issuecomment-961438354, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOIUILC7HWAHSAVOBIDUKMB5XANCNFSM45A7M5YQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

lschriml commented 2 years ago

Thank you Lauren, I look forward to working together and thank you for your efforts to include the exposures in ECTO.

Cheers, Lynn

On Thu, Nov 4, 2021 at 5:25 PM Lauren @.***> wrote:

This has been a lot of good conversation regarding the use cases for this ontology. From an ECTO perspective, we are very happy to collaborate and assist how we can to support modeling of both exposures leading to disease onset as well as exposures exacerbating existing disease. ECTO is intended to be applicable in both of those use cases of disease causality and attacks as were stated as the differentiation between a driver and a stimulus. ECTO is working on incorporating some of the exposures requested for use in DO and we will continue to chisel away at that list to support the use case if still needed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/1508#issuecomment-961438354, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBB4DKOE3HUGPBOGD2SHKDUKMB5XANCNFSM45A7M5YQ .

-- Lynn M. Schriml, Ph.D. Associate Professor

Institute for Genome Sciences University of Maryland School of Medicine Department of Epidemiology and Public Health 670 W. Baltimore St., HSFIII, Room 3061 Baltimore, MD 21201 P: 410-706-6776 | F: 410-706-6756 @.***

jamesaoverton commented 2 years ago

PURL request is complete and working: https://github.com/OBOFoundry/purl.obolibrary.org/issues/799
the registry entry is complete #1645

So I'll close this issue. The results will be visible on the obofoundry.org site as soon as this PR is merged #1652

OBOFoundry / OBOFoundry.github.io