foodon ontology data specification has semantically silent min0 QCRs

[cmungall]

FOODON_00000000 foodon ontology data specification has axioms such as this:

'has component' min 0 ('categorical value specification'
 and ('specifies value of' some 'dietary use/label claim'))
'has component' min 0 ('categorical value specification'
 and ('specifies value of' some 'extent of food heat treatment'))
'has component' min 0 ('categorical value specification'
 and ('specifies value of' some 'food consumer group'))
'has component' min 0 ('categorical value specification'
 and ('specifies value of' some 'food cooking'))
'has component' min 0 ('categorical value specification'
 and ('specifies value of' some 'food datum'))
'has component' min 0 ('categorical value specification'
 and ('specifies value of' some 'food packaging'))
'has component' min 0 ('categorical value specification'
 and ('specifies value of' some 'food packing medium'))
'has component' min 0 ('categorical value specification'
 and ('specifies value of' some 'food physical quality'))
'has component' min 0 ('categorical value specification'
 and ('specifies value of' some 'food preservation process'))
'has component' min 0 ('categorical value specification'
 and ('specifies value of' some 'food product by organism'))
'has component' min 0 ('categorical value specification'
 and ('specifies value of' some 'food product contact surface'))
'has component' min 0 ('categorical value specification'
 and ('specifies value of' some 'food product organismal source'))
'has component' min 0 ('categorical value specification'
 and ('specifies value of' some 'food treatment process'))
'has component' min 0 ('categorical value specification'
 and ('specifies value of' some 'geographic location'))

these are semantically silent.

Sometimes people do this as a convention to indicate that "a food ontology specification MAY have components..."

But even this is stronger than the OWL interpretation

E.g. this is true

Homo sapiens subClassOf has-component min 0 galaxy

As the axioms are trivially feel free to close this issue with no actions, but I would recommend links to documentation about the purpose of this class and these axioms

As an aside I see a few red flags here. No action required on these:

• the class has no subclasses
• the min-0 pattern suggests we are trying to force owl to do what is better done with a closed-world schema language (linkml?)
• the definition doesn't follow genus-differentia and doesn't actually tell me what the class is
• this feels like a complicated term for what normal people might call "recipe"? are recipes in scope for foodon? will foodon include these? as individuals or classes?

[cmungall]

I'd be interested in talking about the analogy between recipes and ontological representation of pathways some time!

[ddooley]

So the above data specification entity, created during first round of our GEEM visual entity mart software project a few years ago, was meant to capture flat form data and not really build further semantics other than specifying the data structure itself. This is used to populate a Biosample form with descriptors specific to a food sample - so not a recipe. Yes it is what LinkML does and that's one of our motivators to switch to LinkML for this - except I would shift it a bit and say that the OWL version of LinkML is what we'd recode this into. I like to see standardized data views/specs able to be included in application ontologies along with lots of the entities the data views/specs depend on.

As for recipe development - definitely viewing that as a more or less detailed protocol + resource list that a "recipe process" implements - you'll see the thinking in the 2nd IFOW talk I gave (have to redo vido on, forgot to record). There's a strong potential for reverse engineering I think - creating recipe as a product of abstracting a multi-component process. Yes lets compare notes!

[ddooley]

And a recipe data model will indeed be included in foodon, but recipes themselves vary so much and so are not universals, so I don't think precomposing them would accomplish anything. But this reminds me - so foodon has two object properties - "has ingredient" and "has defining ingredient", and we're fine with moving those into RO? This was mentioned in an old https://github.com/oborel/obo-relations/issues/143 issue. I'd prefer if they were RO relations, but the 'has ingredient' relations have food products in range and domain - so one would have to bring that one "food product" entity into RO to fully define that?

[ddooley]

You can see how these data specifications get put to work in software at: https://genepio.org/geem/form.html#GENEPIO:0002083/GENEPIO:0002106 where the 'food specimen' section is driven by software that reads in GenEpiO pretty much the same thing as above. However, plan is to retool that all to LinkML.

[cmungall]

I am open to has-ingredient in RO. In some ways concrete relations with specific domain and range are preferable than trying to abstract to something hard to recognize. But in this case would something (following OBI specified inputs/outputs) like 'has-specified-part' make sense?

[ddooley]

The thing about ingredients is that they can transform, like baking soda, leading to some time t when they aren't present in the same quantity as when added or same form as with puree. So yes, "has specified part" may work for an ingredient list. But once it gets into the chemical mix, no guarantee that it is detectable.

[ddooley]

An 'ingredient list' could have 'has-specified-part', which would be an ICE semantic. Or 'has specified component'. But of course most people are familiar with 'has ingredient'.

[mateolan]

In case it helps clarify: an ingredient is part of an ingredient list, which is part of a recipe. However, as Damion mentioned, ingredients (often, if not usually) transform during recipe execution processes--so 'has-specified-part' between a food and an ingredient would be generally inappropriate, except for minimally processed foods.

On Fri, Sep 17, 2021, 03:06 Damion Dooley @.***> wrote:

And a recipe data model will indeed be included in foodon, but recipes themselves vary so much and so are not universals, so I don't think precomposing them would accomplish anything. But this reminds me - so foodon has two object properties - "has ingredient" and "has defining ingredient", and we're fine with moving those into RO? This was mentioned in an old oborel/obo-relations#143 https://github.com/oborel/obo-relations/issues/143 issue. I'd prefer if they were RO relations, but the 'has ingredient' relations have food products in range and domain - so one would have to bring that one "food product" entity into RO to fully define that?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/FoodOntology/foodon/issues/159#issuecomment-921674814, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMZGIZH2VC5BCBZJNWG4A3UCMHKJANCNFSM5EFHWU5A .

[ddooley]

So this thread is kind of on a new topic but anyhow, this new diagram shows how we could get by with existing relations: Separately we already have in FoodOn a 'has substance added' > 'has ingredient' > 'has defining ingredient' hierarchy of object properties that attach between food products, but that is separate from above.

[maweber-bia]

Hi there!

Just an additional comment : in the recipe you will have the ingredient list, the device list, but also the description of the tasks, including appropriate parameters (time, temperature, speed...) that together make up the protocol or procedure.

I was also thinking about the definition of a "formulation process". Formulation is the selection/incorporation of the appropriate ingredients (i.e. the list of ingredients which is part of the recipe).

[ddooley]

Indeed! We need to account for recipes that have steps - and sections too! Thinking of the recipe plan as a kind of document with sections. Shall I add:

• a "recipe plan section" which is part of a "recipe".
• a "recipe step" part? With respect to the plan, a recipe step sounds like an information part (e.g. could be free text, or could reference a data structure of process parameters). So it references a process, but is primarily an ICE. I'll try that out.

[maweber-bia]

yes, we can view a recipe as an Information Content Entity I like the idea of having a section referencing the recipe steps in free text or structured/tabulated file!

[mateolan]

It wouldn't hurt to take some hints from, and perhaps concordance with (for easy conversion), https://schema.org/Recipe

On Fri, Oct 15, 2021 at 9:32 AM Magalie WEBER @.***> wrote:

yes, we can view a recipe as an Information Content Entity I like the idea of having a section referencing the recipe steps in free text or structured/tabulated file!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FoodOntology/foodon/issues/159#issuecomment-944437742, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMZGI3ONWIPZ32O64OPLL3UHBJSRANCNFSM5EFHWU5A .

[ddooley]

Yes we'll want to cover key schema.org terms, at the same time our model should primarily couple tightly with a process model. This is a newer iteration that takes on recipe section and step:

[mateolan]

Why using 'part of' instead of 'has part' akin to 'has member', 'has ratio', 'has measure'', 'has quantity', 'has characteristic', etc.? And what are the dataset relationships in your diagram?

On Fri, Oct 15, 2021 at 12:32 PM Damion Dooley @.***> wrote:

Yes we'll want to cover key schema.org terms, at the same time our model should primarily couple tightly with a process model. This is a newer iteration that takes on recipe section and step: [image: image] https://user-images.githubusercontent.com/4000582/137543661-cb3b73ed-2b53-42da-b1e4-48ecb121980d.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FoodOntology/foodon/issues/159#issuecomment-944610648, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMZGI5AVXO4P5ETYBPSUKLUHB6VTANCNFSM5EFHWU5A .

[ddooley]

The relations sometimes have cardinality 0, i.e. they aren't always required. I'll use 'has part' vs 'part of' to convey that more, though truthfully I don't always adhere to it in diagrams, knowing that the OWL file will be more precise. When you say x 'has part' some y, in OWL that means necessarily. Does every recipe have an "ingredient list", "device list" and "recipe section"? Many don't have a device list explicitly. And I just made a martini from free text paragraph that didn't mention an ingredient list separately. Above though, it implies an ingredient list is part of some recipe. But ingredient lists in a simple fashion - a list of ingredients, no quantities even - could just be for shopping I guess, or the stuff in the fridge, so a generalized sense. So might need cardinality of 0 in either direction.

As for "data set" this is an IAO term (http://purl.obolibrary.org/obo/IAO_0000100) and it very simply means a class of data items of the same kind, e.g. all food products, or all devices.

[ddooley]

So 'has ingredient' could have a property chain:

'specified output of' o 'has specified input'

if we could ensure that the entity in the middle was a process - food transformation process or similar, because other kinds of things like shampoo can have ingredients too. That becomes the hard part, the common use of "ingredient" involving some but not all types of transformation.

[ddooley]

I will close this now, with a few adjustments to indicate in label and definition what it is about, and noting a future plan to convert this to a LinkML way of expressing the specification.

label: food item specification description: "A data representational model which includes optional facets or axes of food compositional database descriptors to describe a food item."@en