Is has_input really a subPropertyOf has_participant ?

[GoogleCodeExporter]

has_input is defined as including indirect inputs - presumably these refer to 
inputs to upstream processes that provide direct inputs.  If this is the case, 
then surely has_input should not be a subProperty of has_participant.

As changing this would likely have quite major downstream effects, it would, of 
course, have to be well co-ordinated with users of this relation (e.g. GO).  To 
avoid much unwanted inference resulting, it might be best to mint a new ID for 
a redefined has_input, so forcing users to switch in order to keep up to date 
with RO.

Original issue reported on code.google.com by dosu...@gmail.com on 17 Jun 2014 at 10:39

[GoogleCodeExporter]

I have discussed this further with Ruth Lovering, Becky Foulger and Paul Denny. 
 We all agree that having has_input cover indirect (upstream) inputs (non 
participants) is unintuitive.  So, has_indirect_input should probably be 
renamed, and should certainly not be a subProperty of has_input.  If a 
superproperty is necessary, this would need a new name too.  

In annotation extensions, a different distinction is made between has_input and 
has_direct_input: a direct input to a molecular function (process) must bind 
the gene product carrying out that process.   This distinction would be hard to 
support/formalise within RO, but could perhaps be supported in a GO specific 
relation restricted to molecular function.  Alternatively, we could merge 
has_input and has_direct_input and come up with a proposal that allows 
annotators to record binding separately.

Original comment by dosu...@gmail.com on 2 Sep 2014 at 3:13