FoodOn recipe model

[ddooley]

We are iterating a model of a flexible food recipe that has a fair bit of detail in it about the ingredients, devices, processes, and actions/steps that go into it. It is designed to be plug-and-play with OBO Foundry. It will be described in detail in an upcoming paper. For now, here is a preview diagram (which shows a simplification from the paper diagram in that a simple 'has part' connects from food recipe to its ingredient and other specifications; this was from OBI curation group feedback):

As well there is the possibility of gathering each kind of part of the recipe plan specification:

So the ingredient set is basically a shopping list. Possibly each of the sets can have subsets (so e.g. the ingredients for the dressing, vs those for the salad).

Finally, each ingredient specification may indicate an amount of the food material, as a number or a proportion.

This builds on COB data framework being finalized in: https://docs.google.com/document/d/1Cds-u9icTkS4kN7Mcn8P5D01WgIyMIqFz4YzhCYzg0k/edit#

Feedback appreciated.

[ddooley]

FoodOn has minted ids for this model. A remaining question is whether we really need "step specificaiton" or if we can make do with IAO "action specification"? The IAO term doesn't explicitly state that an action can be a process which is generalized to a discrete step.

and

Thoughts about "action specification"?

[maweber-bia]

This needs clarification but I do not think that we have to make a distinction between action specification and step specification : what would be the difference ?

I think we can have an action specification attached to each step of the process ?

[ddooley]

If in fact the action specification and step specification are the same, or if action specification can take on what we want to do with step specification, then I need to deprecate step specification in favour of action specification (which I only recently learned about). IAO action specification as a subclass of "directive information entity" is vague - but because of that we could reuse it to our own purpose. We could have it itself take on all the properties of a plan specification, performed by a process and with objective and action parts. I'm ok with using "action specification" that way, if you are, Magalie!

[ddooley]

But this means we no longer mention "step specification" in the ontology, except as a synonym for action specification.

[ddooley]

I have deprecated step specification in favour of action specification.

[StroemPhi]

There are two questions I have about the graphic in #208 (comment).

1. Why do you use the "component of" relation (which I couldn't find in RO) and not just "bfo:part of"?
2. Why is the setting datum not also part of (component of) the device specification, when the definition of the latter is: "A directive information entity which specifies a device and its settings for use within a plan specification."?

I can see that in the context of a food recipe the setting datum is a part of an action to be taken and thus part of the action specification. But when we have a context in which the device specification is part of an "iao:protocol" that is described in the experimental section of a paper (e.g. We set the laser power to 300 mW.), the setting datum would imho rather be a part of the device specification, as the action was performed in the past. I'm asking this, as I need to model such information in a research data management context. And I'd love to not just relate the "iao:setting datum" to the "obi:assay" via "obi:has specified input" but also via a "foodon:device specification" that is part of an "iao:protocol".

[ddooley]

Hi Philip,

Thanks for feedback!
On no. 1, we've backed off using "component of" for parts diagrammed above, and now just intend to use "part of". "Component of" was thought of as the inverse of "has component". (Had thought earlier of wanting it to specify cardinality - e.g. "has 1 device set", but realizing we don't really need cardinality restrictions).

BTW happy to see if OBI or COB or a new material processing ontology will take on "ingredient / device / instruction set and ingredient and device specification", they aren't specific to food, or for biomedical devices either.

Also, I get why some process modelling had a device be an input to a process. A process can be done to a device itself, for example, calibrating it, or changing its state (e.g. opening its door). Aside from that, there are a few OBI relations to connect a device to some process it fully or partly enables ("capable of part of"/"capable of"/"enables") which facilitate plug-and-play device selection.

On no. 2, that's challenging - it illustrates the interconnection between process actions and objectives. "Setting datum" ("reflecting the configuration of an instrument") can be a bit ambiguous in a temporal world. A calliper is immediately at a given setting. An oven door open/closed is too, but oven temperature isn't, and so the setting translates to more of an objective it takes time to achieve! I've seen protocols often contain either of these expressions:

• The imperative "set oven temperature control to 190C" which may involve moving a knob or sending a digital message to a device, which seems like an action specification.
• The precondition "oven temperature at 190C" (or "bring oven up to 190C") be satisfied before a process can proceed, which seems like a precursor process objective specification. This might even take a sensor to measure, and could take time to achieve after action specification setting is performed. (In reality, and something that would ultimately be modeled for robots etc., miscalibration, or other settings such as an open oven door can confound intent.)

Can we have a "device specification" (or some new class?) be limited to the set of features and range of capabilities a device has (e.g. oven temp range 0 to 500 degrees, 1000W max energy consumption, 20L capacity, etc.). Then find a way to express settings/conditions for a device (or class of them) with respect to a process that utilizes it.

Under the hood, I think a plan specification "action specification" often entails a sub-process + objective(s)? Here are 3 protocol step examples:

• "Preheat oven to 350F"
  -> set oven to 350F (irreducible action).
  -> Here device is input to a "setting" process that involves the setter too?
  -> a waiting process until objective: oven thermometer is at 350F.

• "1/2 hour before baking, set oven to 425F"
  -> set oven to 425F.
  -> a waiting process with objective: duration of 1/2 hour.

• "At time t, open door and remove sample"
  -> a waiting process with objective: duration time t
  -> a device open door process
  -> a remove sample process (dependent on both device and operator physicality (hot thing requires gloves etc.))

Framing it this way suggests we should just treat preconditions and "setting datums"/action steps within a protocol in the same way. Setting datums that need to be done initially (and which may or may not have immediate effect) could be organized in a "setup" section of a protocol / action specification. Generally, setting datums that are invoked during a process are likely tied/compartmentalized into subprocesses that are optionally modelled further.

[ddooley]

But maybe that still leaves some confusion between a device specification - about what a device provides - and a specification of what a process itself needs for a device that performs some function.

[StroemPhi]

Hi @ddooley,
Thank you for the quick and thorough reply! Great examples and thoughts. I agree that having these classes in OBI or COB might be better to keep the pattern graspable. I have some further thoughts and questions on this, but unfortunately, no time atm to write them up. I will try to come back to this next month. Please ping me, if I forget.