Adding 'realizes' ('realises') to the NBO object property hierarchy

[DitchingIt]

@matentzn If you would be so kind...

[pmidford]

There don't seem to be a lot of details here. Does this property have a definition or maybe it's being pulled from somewhere else. I think some sense of 'realizes' would be a good addition, but what exactly are you proposing to add?

[matentzn]

BCIO (cc @jannahastings) is using https://www.ebi.ac.uk/ols4/ontologies/ro/properties/http%253A%252F%252Fpurl.obolibrary.org%252Fobo%252FBFO_0000055, but we need to be a bit careful it is applied correctly.

[matentzn]

@DitchingIt can you add two examples to this issue of how you plan to use the relationship?

[DitchingIt]

Thanks for the feedback.

This was just a technical request to add an object property to the already vast list NBO has access to. It doesn't have to be used if either a better alternative exists or the context is misguided. The context to this request is fully explained in the paper I uploaded yesterday. I have cut and pasted a snippet: "No current relationships in the NBO take this form. Taking a lead from the BCIO, I would like to introduce this object property for any classes which put a parent class into effect, are caused by it, deliver it, achieve it, follow it, reify it, function as it, or respond to it. This allows for more or less functional relationships dependant on relative terms rather than predefining particular ‘function’ or ‘action’ classes."

Of the hundreds of examples in my paper, two are:

1. NBO:0000372 directional control of locomotion realizes NBO:0000013 locomotory behavior
2. NBO:0000100 exploration behavior realizes NBO:0000097 response to novel environment

Is this helpful? @pmidford @dosumis @aclark-binghamton-edu @jannahastings @matentzn

[jannahastings]

Unfortunately I think there may be a challenge in that the realizes relation as it is understood in BFO and as we use it in BCIO links a process (behaviour) to a function (disposition). Thus, you would not ordinarily use it to connect two different behaviours. I think you are introducing here a much broader relationship between behaviours and that as such we should use a different name for this relationship to avoid confusion with the (narrow) realizes relationship. I will look at the list of examples in your paper in detail before making a suggestion.

[DitchingIt]

Looking forward to that. I have used realizes in my ROBOT sheet just uploaded at #184 but only as a stand-in until a more appropriate term is found.

[DitchingIt]

After our Zoom conversation @jannahastings I can see that this is not the correct relation for two processes.

1. We talked about linking processes via RO:0002411 causally upstream of. I can see this working for BCIO but I have yet to find even one place I could use it in a renewed NBO.
2. We talked about the contexts I was keen to highlight when I originally proposed realizes. I am now wondering whether RO:0000052 characteristic of might be what I need, as it appears to allow processes to be linked and picks up on my clumsy attempts to explain what I was after; I think I would retain my meaning if I paraphrased my August 2023 paper to say, "I would like to introduce this object property for any classes which are characteristic of their parent class." (ORIGINAL: I would like to introduce this object property for any classes which put a parent class into effect, are caused by it, deliver it, achieve it, follow it, reify it, function as/to it, or respond to it.) For example:
   • Locomotor behavior (NBO:0000013) and posture (NBO:0000355) are characteristic of kinesthetic behavior (NBO:0000338)
   • Directional control of locomotion (NBO:0000372) is characteristic of locomotor behavior (NBO:0000013) but aquatic locomotion (NBO:0000371) and aerial locomotion behavior (NBO:0000366) are not, although they remain simple subclasses
   • Similarly, feign death (NBO:0020199) characterises (or is characteristic of) posture (NBO:0000355) but body posture (NBO:0000356) and limb posture (NBO:0000357) do not, although they are its subclasses

What does anyone think? And does this take us too close to traits/phenotypes (characteristics in a different sense)? @pmidford @aclark-binghamton-edu @matentzn @dosumis

[jannahastings]

@DitchingIt Apologies for not responding with more detail sooner. Your summary of our discussion agrees well with what I remember, many thanks!

Really unfortunately, however, the relationship 'characteristic of' is also constrained to not be used between two process classes in the way you would like. The key information is in the definition of the relationship: a relation between a specifically dependent continuant (the characteristic) and any other entity (the bearer), in which the characteristic depends on the bearer for its existence.

This means that this relationship relates a dependent continuant to the entity that it is a 'characteristic' of. Thus it is intended to be used for e.g. relating the weight of a mouse to the mouse, or the fragility of a vase to the vase. I think this is indeed characteristic in a different sense to how you want to use it.

It is a well known problem that we have a smaller shared vocabulary for talking about processes than for continuants. Moreover, the relationships you are wanting to capture are at the class level rather than the instance level. My recommendation is that you just create the relationships you need. You can then use the language that is most natural for the particular type of connection you want to capture, and that will also be the easiest to understand for the users of the ontology, and finally will not create any logical problems in the way that it will create logical problems if you re-use a RO: relationship in a way that violates the domain and range constraints.

What do you think?

[cmungall]

Strong endorse of @jannahastings's recommendation!

[DitchingIt]

Sorry for the delay. No problem. I don't see any other ways to approach the action/function conundrum so I shall close this issue.