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

Model exposure receptor and exposure stressor as relations #64

Open
wdduncan opened this issue Nov 21, 2019 · 11 comments
Open

Model exposure receptor and exposure stressor as relations #64

wdduncan opened this issue Nov 21, 2019 · 11 comments
Assignees

Comments

@wdduncan
Copy link
Member

The intent of exposure receptor/stressor seem better modeled as object properties. You have an entity that causes stress to an entity. This seems like a specialization of interacts_with (relation). The inverse of the stressor relation would then be a receptor relation. I think this will make things easier in the long run.

@diatomsRcool
Copy link
Contributor

We need to remain in line with ExO. The whole receptor/stressor thing is inherited from them.

@cmungall
Copy link
Member

@matentzn
Copy link
Contributor

Here is a good example: exposure_to_chemical_medium_route.yaml

You can see:

  • 'has exposure stimulus' some %s
  • 'has exposure medium' some %s
  • has exposure route' some %s

So yes, these are modelled as object properties. @wdduncan can you give us an example where you think our use of relationships does not work?

@wdduncan
Copy link
Member Author

The axioms for exposure event include:

'has part' some 'exposure receptor'
'has part' some 'exposure stressor'

Based on the definition of exposure stressor:

An agent, stimulus, activity, or event that causes stress or tension on an organism and interacts with an exposure receptor during an exposure event.

This may be an occurrent or continuant, which will not comply with OBO core.

@matentzn
Copy link
Contributor

This is true, I agree. These axioms live in EXO though, not ECTO. This needs to be changed there! I think we should make a ticket on EXO to use the correct relations here.. has part ist definitely wrong!

@matentzn
Copy link
Contributor

matentzn commented Nov 22, 2019

In your email @wdduncan you say:

My comment about receptor/receptor was concerning ontological matters. It seems to me that these are better modeled as relations, if we are not obligated to ExO.

I am a bit confused, because we actually do not model receptors at all, anywhere (and when I say anywhere I mean in our, not the imported_ logical axioms). None of our definitions contain receptors (afaik, @diatomsRcool)!

Maybe the best would be if you would review the file called "ecto-base.owl".. It contains all the axioms we can actually do something about!

@wdduncan
Copy link
Member Author

If you don't use receptors then perhaps you shouldn't import them.
I'm not sure what the confusion is about. If ExO has problematic entities or relations then decisions need to be made about how committed you are to that model. The same decisions apply to NCIT, UBERON, etc.

I am merely pointing out that the classes exposure receptor and exposure stressor are problematic. One approach I was suggesting to deal with the problems is to use relations. Then you can stipulate (via equivalence axioms) that X is a stressor if stands in a stressor relation to some other entity. This way the entities in the relation still conform to OBO core, but the defined class is recognized as being a useful way to group things that stand in the stressor relation together.

Another option is to go down the ontological rabbit hole and model all the dispositions, roles, and processes that define being a stressor/receptor. IMHO, this doesn't seem worthwhile for this project.

You can also just use the ExO classes and axioms and accept that ECTO will not be OBO core compliant. Such decisions are above my pay grade :) (or at least I think they are.)

@diatomsRcool
Copy link
Contributor

From discussion:
There are a few options to be OBO Core compliant. The way we deal with stressor doesn't allow it to fit in OBO Core because it contains ME and processes.

  1. GCI
  2. exposure stressor class
  3. separate stressor for material entities and processes.

We may wait on this for more OBO Core development. Let's not worry about this for the moment.
Make defined classes for the different stressor categories.

@wdduncan
Copy link
Member Author

This issue hasn't been discussed in while. Since we discussed taking over ExO and/or using COB as the top-level ontology, perhaps we should revisit this.

@wdduncan
Copy link
Member Author

wdduncan commented Apr 6, 2022

Update from meeting:

  • make a defined class that groups processes and/or material entities under exposure stressor/receptor.
  • see if we can add exposure stressor/receptor to COB
  • @wdduncan will create ticket on COB to add the exposure event class.

@wdduncan
Copy link
Member Author

wdduncan commented Apr 6, 2022

Requested exposure event in COB (ticket), and requested that RO change the label of exposure event or process to be simply exposure event (ticket).

Once these tickets are address (hopefully, it won't take too long), we can focus on making exposure stressor and exposure receptor logically defined classes for purposes of grouping via inference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants