search

obi-ontology / obi

The Ontology for Biomedical Investigations
http://obi-ontology.org
Creative Commons Attribution 4.0 International
74 stars 25 forks source link

Consider putting 'has specified input' under RO 'has input' #1045

Open jamesaoverton opened 5 years ago

jamesaoverton commented 5 years ago

RO has recently made a change https://github.com/oborel/obo-relations/pull/322 after an interesting discussion https://github.com/oborel/obo-relations/issues/315. We should consider moving 'is specified input' under the revised 'has input'. OBO Core is also relevant.

We won't rush this decision.

bpeters42 commented 4 years ago

This should be tested out as part of the OBO-core migration

cmungall commented 4 years ago

Another distinction between RO usage of "input" and OBI pertains to timing. In RO inputs are required to be there at the start. Question: is this too restrictive for OBI? Are there use cases where OBI has a specified input that is not present at the start of a process? If so, then OBI has-specified-in cannot be a sub-relation of has-input. Which is fine, we just have to document this.

alanruttenberg commented 4 years ago

There's another distinction. The RO definition says that the input changes during the process. "P has input c iff: p is a process, c is a material entity, c is a participant in p, c is present at the start of p, and the state of c is modified during p."

However, consider a specified data set to a computation, such as computing the mean. In this case the input does not change during the process. There are other examples like this. For instance in a behavioral experiment on reaction times of drivers, a stop sign might be a specified input. Again, in such experiments the input does not change.

alanruttenberg commented 4 years ago

Timing and OBI has specified input: The OBI definition says the input "is not created during the process". This is slightly ambiguous, in that "during the process" might mean "as part of the process", or "when the process exists". I think the former reading is more likely, but this is worth noting.

I gave, during the RO call, an possible example of a specified input that doesn't exist when the process starts - a hypothetical just-in-tme manufacturing process. Consider the process of assembling a car. The windshield is attached late in the process, and it is conceivable that it is manufactured in a different process, arriving at the auto plant when part of the car is already assembled.

An analogous situation in bio-manufacturing might be the production for market of a vaccine that needs incubation. A specified input in the plan would be the packaging for the vaccine, and while the packaging might be specified in the plan, the packaging need not exist when the incubation starts.

@cmungall correctly pointed out that if we want to, we can tighten the timing requirement and say that in such cases that the putative inputs (windshield/vaccine packaging) are not inputs the the processes described, but rather inputs to parts of those processes. Since OBI is in the realm of human planning, we could try to find users with use cases like these and ask whether this is a natural/comfortable representation.

wdduncan commented 4 years ago

I understand the intuition that the domain for has input is intended for entities that are in some sense more "required" than merely being a participant. I avoiding characterizing inputs as "necessary" b/c in this community it may convey a stronger sense of 'necessary' than is needed. For example, human respiration has input some portion of oxygen, meaning that in some sense oxygen is required for (normal) respiration to occur.

@alanruttenberg suggested that perhaps this sense of 'require' might be captured at the class/type level (e.g., respiration requires some portion of oxygen, not a particular portion of oxygen).

Would it be too strong or vague to characterize the has input relation as holding between a process and a continuant that 1) participates in process and 2)the process depends on the continuant in order to occur?

From a pragmatic standpoint, I wonder if there are meaningful use cases in which has participant has been used to in cases in which the domain included entities that were not inputs for some reason. That is, while you can use the has participant relation to model all sorts of willy-nilly entities involved in process, do users actually do this?

I agree with @alanruttenberg regarding change being necessary for the has input relation. As for the definition of has_specified_input I would remove the language "which the process realizes the concretization of". It is confusing to non-ontologists and you can see my belabored email thread for objections regarding the notion that a plan specification can be concretized as a realizable entity.

I agree with @cmungall that depending on how the OBI community defines has_specified_input, it may not be appropriate to have it as sub-property of has input.