Model exposure receptor and exposure stressor as relations

[wdduncan]

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]

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

[cmungall]

I',m not following. These are object properties aren't they? https://github.com/EnvironmentOntology/environmental-exposure-ontology/tree/master/src/patterns/dosdp-patterns

[matentzn]

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]

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]

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]

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]

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]

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]

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]

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]

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.