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.

Sign up for GitHub

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

Jump to bottom

New Ontology Request - DISDRIV - Disease Drivers #1508

Closed
2 tasks
lschriml opened this issue May 17, 2021 · 49 comments
Closed
2 tasks

New Ontology Request - DISDRIV - Disease Drivers #1508

lschriml opened this issue May 17, 2021 · 49 comments
Labels
new ontology Use for new ontology registration requests

Comments

@lschriml
Copy link
Contributor

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: [email protected] or [email protected]
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
ebi-chebi/ChEBI#4084 (comment)

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

@pbuttigieg
EnvironmentOntology/envo#1110 (comment)

  • 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
- EnvironmentOntology/environmental-exposure-ontology#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: [email protected]
  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.
@lschriml lschriml added the new ontology Use for new ontology registration requests label May 17, 2021
@matentzn
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor Author

lschriml commented May 19, 2021 via email

@laurenechan
Copy link

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
Copy link
Contributor Author

lschriml commented May 19, 2021 via email

@pbuttigieg
Copy link
Contributor

pbuttigieg commented May 25, 2021 •
edited
Loading

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:

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

  2. 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
Copy link
Contributor

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

@lschriml
Copy link
Contributor Author

lschriml commented May 25, 2021 via email

@pbuttigieg
Copy link
Contributor

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
Copy link
Contributor Author

lschriml commented May 25, 2021 via email

@lschriml
Copy link
Contributor Author

lschriml commented Jun 4, 2021

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

@pbuttigieg
Copy link
Contributor

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
Copy link
Contributor Author

lschriml commented Jun 7, 2021 via email

@pbuttigieg
Copy link
Contributor

@lschriml

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

@lschriml
Copy link
Contributor Author

lschriml commented Jun 28, 2021 via email

@pbuttigieg
Copy link
Contributor

pbuttigieg commented Jun 29, 2021 •
edited
Loading

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:

image

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
Copy link
Contributor

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

image

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

image

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

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

image

has-role axioms are injected onto ENVO processes:

image

@lschriml
Copy link
Contributor Author

lschriml commented Jun 29, 2021 via email

@pbuttigieg
Copy link
Contributor

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
Copy link
Contributor Author

lschriml commented Jun 29, 2021 via email

@pier
Copy link

pier commented Jun 29, 2021 via email

@lschriml
Copy link
Contributor Author

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
Copy link
Contributor

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

  1. 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
  2. create shadow classes that represents the stressor aspect
  3. 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
Copy link
Contributor

ddooley commented Jul 13, 2021 •
edited
Loading

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
Copy link
Contributor

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

@cthoyt cthoyt mentioned this issue Aug 21, 2021
Closed
@nlharris nlharris added the new ontology - submitter action needed New ontology requests that have been reviewed and need changes in order to be accepted label Aug 23, 2021
@lschriml
Copy link
Contributor Author

lschriml commented Aug 25, 2021 via email

@lschriml
Copy link
Contributor Author

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

@nlharris nlharris removed the new ontology - submitter action needed New ontology requests that have been reviewed and need changes in order to be accepted label Sep 29, 2021
@cmungall
Copy link
Contributor

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

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

There is still some injection happening:

image

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
Copy link
Contributor Author

lschriml commented Sep 29, 2021 via email

@balhoff
Copy link
Contributor

balhoff commented Sep 29, 2021

I opened an issue with FOODON: FoodOntology/foodon#161

@lschriml
Copy link
Contributor Author

And noting here the injection of terms Issue noted on the above FoodOn ticket
#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
Copy link
Contributor

cmungall commented Oct 1, 2021

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
Copy link
Contributor Author

lschriml commented Oct 1, 2021 via email

@balhoff
Copy link
Contributor

balhoff commented Oct 19, 2021

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
Copy link
Contributor

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:

  1. Find or define a good relation to describe the relation between the disease and the ontology
  2. 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.
  3. 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
Copy link
Contributor Author

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:
oborel/obo-relations#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
Screen Shot 2021-10-29 at 1 21 38 PM
tached.
Screen Shot 2021-10-29 at 1 21 54 PM

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
Copy link
Contributor

matentzn commented Nov 1, 2021

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:

  1. 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)
  2. The driver aspect of alcohol (alcohol disease driver), i.e. the aspect of the entity that is causally responsible for the disease.
  3. 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
Copy link
Contributor Author

lschriml commented Nov 1, 2021 via email

@matentzn
Copy link
Contributor

matentzn commented Nov 1, 2021

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
Copy link
Contributor Author

lschriml commented Nov 2, 2021

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
Copy link
Contributor

matentzn commented Nov 3, 2021

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:

  1. 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.
  2. 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
Copy link
Contributor

cmungall commented Nov 3, 2021 via email

@laurenechan
Copy link

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
Copy link
Contributor

cmungall commented Nov 4, 2021 via email

@lschriml
Copy link
Contributor Author

lschriml commented Nov 5, 2021 via email

@jamesaoverton
Copy link
Member

  1. PURL request is complete and working: New PURL config for DISDRIV purl.obolibrary.org#799
  2. the registry entry is complete Create disdriv.md #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

@pbuttigieg pbuttigieg mentioned this issue Apr 27, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
new ontology Use for new ontology registration requests
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests