Food process ontology requirements

1.1. Scope of process ontology survey

A main objective of the gap analysis provided in this paper is to arrive at recommendations for a generic process modelling framework that works seamlessly within the open source Open Biological and Biomedical Ontology Foundry (OBO) [24] community of ontologies. We aim primarily to review state of the art OWL ontologies that have object properties and classes needed for an OBO process model. We identify entities required to model food processing and more general lab or manufacturing protocols sufficiently, and compare their ontology’s temporal, part-hood, input and output, participant/agent and process dependencies. These entities can then be added to or echoed in the FoodOn [15] food ontology, a hub within OBO for agricultural, health and nutrition content related to food products and food processing which is essential for food traceability and other farm-to-fork applications. FoodOn was initially created as an OWL ontology transform of LanguaL [35], a popular longstanding food composition thesaurus.

Crafting a generalized process ontology requires a wide community of domain-specific users to critique it, as well as due diligence – an examination of the objectives, capabilities, and lessons learned from existing process related ontology projects. We review the EXperimental ACTions ontology (Exact2) [56], Process and Observation Ontology (PO2) [13] and the Ontology for Biomedical Investigations (OBI) [7] planned process model, which have various degrees of OBO compatibility, as well as the PROV ontology (PROV-O) [34], the Time Ontology (OWL-Time) [28] the Sensor, Observation, Sample, and Actuator ontology (SOSA) [25] which have significant adoption momentum. Finally we discuss Schema.org’s recipe model as it has a number of process related elements. Some object properties can be reused as is (such as OWL-Time “hasTime”), while others would need equivalent OBO entities created due to OBO principles as discussed in Section 1.2.

Following the review, we synthesise a recipe food processing model from parts of the compared ontologies, and conclude by presenting a simple “boiled carrots” recipe use-case to illustrate how a generic processing model could satisfy a variety of stakeholders: consumers who simply need well-organized recipe instructions; research chefs that formally iterate end product characteristics to achieve a formulation; and food scientists who translate a batch formulation into industrialized continuous processing protocols. Our aim is to achieve a generic process model that applies to food processing, as well as laboratory, assembly line and robotics applications without having to change the language of its entities and relations. We break down the recipe into discrete steps which have a technical model able to support the needs of all three aforementioned stakeholders.

Our proposed recipe model is already being promoted in a recent paper, “Food Recipe Ingredient Substitution Ontology Design Pattern” [27], which also commits to both OBO food ontology network and OBO relations compatibility, and advances the semantic framework of ingredient substitution beyond FoodOn’s basic “has food substance analog” object property. Their work is contributed as Ontology Design Patterns (ODPs) [22] to the ontologydesignpattern.org web portal [57]. They use what appear to be provisional recipe model term identifiers that are ideally replaced by identifiers of the new terms when they are created in FoodOn or other appropriate OBO ontology.

Our gap analysis is not focused on identifying potential taxonomies or ontologies of types of material processing (for example, “heating” or “frying”) or food products or their categorization – these are mentioned only by way of example towards the end of the paper, and are left to specific agricultural, culinary, regulatory, and food science domain ontologies such as FoodOn to support. For example, the “FOod in Open Data” [46] pilot suite of food related ontologies published in 2016 provides policy-related information about Italian “Protected Designation of Origin” food items, but has no object properties pertaining to food processing and so was not reviewed. Similarly, while FoodOn has a hierarchy of over 250 food transformation processes (FOODON:00002451) which have some modelling with respect to specified inputs and outputs, we do not reference this hierarchy here except by way of a few examples. A separate project is under way to recast this hierarchical structure within the larger scope of planned (intentional) and unplanned (natural) processes organized by biological, chemical, or mechanical transformation or phenotypic objective.

We did not review Simple Knowledge Organization System vocabularies although they are a close relative of OWL ontology in the semantic vocabulary pantheon, offering more of a broader-narrower concept hierarchy. For example, Agrovoc [3], an FAO supported SKOS vocabulary which excels at a multi-lingual library science style organization of over 40,000 concepts, including process, partative and quantitative relationship object property branches which have similarities to OBO foundry ones, has been a longstanding target for OBO Foundry term mapping [36]. However, SKOS provides a looser logical framework than what we seek to utilize in OWL (there is no way to express compound term axioms for example) [6], so SKOS-based vocabularies were not reviewed.

We do not provide a comprehensive review of process model vocabularies outside of the OWL sphere, but we do reference some of their features in Section 1.3 so that the reader can generally see where our reviewed OWL ontologies excel or fall short of a generic process model. A number of these vocabularies, like the flow-chart-like Business Process Model and Notation (BPMN) [1] an ISO standard notation for modeling and depicting sequential, branching and loop processing, have been adopted by projects that evolved towards OWL ontology expression. For example, to support speedy foodborne pathogen investigation, a food supply chain traceability paper [33] focused on BPMN-based modeling of food supply chain actors and processes; this work was subsequently built upon in the Food Ontology for Traceability Purpose” (FTTO) [47] which echoes the BPMN food supply chain paper’s process branch. We were unable to obtain the FTTO ontology (no response from author, and not available online); but its published process model did not appear to offer features beyond what OBO already has.

1.2. Targeting an OBO-based process model

We target OBO because we favour a prevalent strategy there of having a minimal set of data properties, a reduced set of object properties, and more emphasis on defining entity classes at either end of an object property, as a general strategy for enabling semantics to be surfaced about those entities which would otherwise be hidden in computationally opaque property names. Briefly, in this approach, rather than using a data property ‘has age’ to say “Cedar ‘has age’ 4” we create an instance of an ‘age’ data item, state that it is about an instance of an organism named Cedar. This provides a convenient way to type what kind of age it is (since conception, birth, planting, germination) and how it was measured (in years, trimesters, months, life stages, tree rings) without loading relationships with such distinctions. This structure can still be translated to other systems’ less explicit object and data property semantics.

A second motivation for OBO – though not unique to its framework – is to encourage standardization by reducing the number of semantically duplicate terms across member ontologies, thus promoting an encyclopedic comprehensiveness. OBO member ontologies are encouraged to reuse a basic grammar of relationships, supplied mainly from the Relation Ontology (RO) [38], which act like a smaller set of verbs one is allowed to construct sentences (data structures) with across OBO Foundry domains, making for a lighter learning curve. This helps achieve a second OBO commitment – that member ontologies are logically compatible with each other. The current OBO set of process-related relations is introduced in Section 3.1. The opposite paradigm is exemplified by WikiData, a federated RDF graph database which merges databases that make use of over 9,000 properties [64]. This landscape is permeated by diverse and not necessarily complete data models and datasets requiring a larger learning curve to navigate.

OPEN IN VIEWER

Fig. 1.

Micromodel linkage. Used with permission from: “Finding our way through phenotypes” [12].

Regarding logical consistency, OBO has tacitly promoted reasoning over a given ontology’s logical structure merged with the Basic Formal Ontology (BFO) [5] to expose internal inconsistencies. (Currently, it is up to individual projects to test other pertinent combinations of OBO ontologies however.) By analogy, BFO acts as a grammarian enforcing the proper use of noun and verb types. More recently an alternate compatibility starting point is with the OBO Core Ontology for Biology and Biomedicine (COB) [40], an upcoming ontology that has a handful of commonly used upper-level classes and relationships – material entity, process, characteristic, and information – combined into a single resource with a principle aim of supporting RO relations’ domain and range constraints. COB is a more agnostic semantic territory that other ontologies might establish equivalencies with. A future harmonisation question would be to see, for our proposed OBO process model, how many properties it shares with other upper-level-ontologies such as Dolce-Ultra light [39].

To fit in OBO, a process ontology and the components it imports must generally adhere to key OBO membership criteria. If useful components are not reusable as is in OBO, then they must be replaced with comparable terms that meet OBO criteria [37], examples of which are listed here:

If a term resource is not completely OBO compatible, data translation could still be accomplished by term mapping using the “has database cross reference” (oboInOwl:hasDbXref) data property, or via SSSOM mapping [30] for finer semantic tuning that can differentiate between semantic broad/narrow/exact synonymy.

Data interoperability is promoted when an ontology is developed as a set of micromodels each focused on an entity in a given context and level of abstraction [12] as illustrated in Fig. 1 which highlights Phenotypic Ontology (PATO) [18] term application; the expectation is that micromodels can plug into each other and be used for various purposes by other users outside a given curation community. This entails potentially splitting entity management across to other ontologies which is a more complex process requiring mutual understanding, a resource price tag, and stamina. On a positive note, this upfront work avoids dependence on a patchwork of reference materials written in other dialects, and the problems that such vocabulary brings in terms of comprehension and training time. Also, the more partners involved, the more easily an ontology goes from essentially a database solution for one project, to an inter-agency standard. However, the capabilities of the OBO curation model are being challenged as it evolves from its initial life science comfort zone into connected domains such as manufactured products and the built environment.

Some other ontologies or model frameworks were considered but not given in-depth review: AMALQEIA [29] captures dish roles with respect to a meal (main course etcetera), style of cooking, ingredients, and their nutritional value, and mentions food process modelling but leaves it to a future task to “express precisely which ingredients undergo which process.” Pertinent to food science recipe formulation modeling, Shimizu et al.’s study [55] defines an ecosystem of ontology design patterns that capture chemistry lab procedures and chemical interactions which parallel cooking procedures and food transformations. An abstract “semantic-trajectory pattern” specializes to a “state transition pattern” that then provides a template on which the “chemical process pattern” is defined. The research utilizes patterns such as “action”, “chemical activity”, “chemical process”, and “chemical system”. This state-change-based process model is not pursued here but can be translated to states as an expression of process inputs and outputs, and their characteristics, which are the focus of this paper’s approach.

There are various kinds of physical, chemical, biological or data transformation processes, and intentional processes that harness them. We can model unplanned processes found in the physical world, which can then be harnessed by planned processes that involve one or more objectives. For example, the ripening of fruit, a biological process, can be manipulated by artificial ripening, and/or timed harvesting and transportation that altogether meet an objective of delivering ripe fruit to customers. Planned processes have a plan or detailed protocol to achieve, and operate on inputs and outputs which are material entities or data. A planned process may involve intrinsic or extrinsic transformations:

Processes can be organized linearly or combined in more complex parallel or networked formations that collectively behave as batch or continuous operations. They can be constrained by dependencies and input availability, requiring various resource inputs and performers such as devices and people. They may have minimally necessary durations, rates of change, sub-processes, and side-effects.

An objective of a general process ontology is that it covers more specific process ontology niches – from food traceability, which calls for rough granularity of process – harvest, storage, transport, division, combination – to more specific modelling, such as how to put a recipe together. Can the same generic process model relations cover specific niche modelling, so that relations in those niches are revealed to be equivalent to generic ones?

2.1. Process objectives

A process objective can be expressed simply by referring to an output entity, for example, “tenderized meat” as a primary objective – a desired product. A variety of processes may be known to achieve such an output, but choosing one may be constrained by available devices or inputs (for example, tenderizing hammer, vinegar), or time constraints (for example, mechanical tenderizing is the fastest), or skillset issues (for example if a related plan specification / instruction is missing or an agent is unable to comprehend it). More generalized modelling is achieved by describing what the output entity is such that the process can be recognized as a means to that end. Having defined “tenderised meat” as “meat which has its muscle fibre and connective tissue severed into shorter segments”, then any process which has a similar output can be inferred to be a potential substitution.

Process objectives can also be expressed by referencing functional capabilities of devices. In BFO a function inheres in a device or material, and a process “realizes” or carries out the transformation that a function characterizes (Fig. 2). A “meat tenderizing function” inheres in a meat tenderizing hammer. A mechanical meat tenderizing process “realizes” the tenderizing function. A plan including step by step instructions may be involved – it is “executed” by the process.

OPEN IN VIEWER

Fig. 2.

Specialization of planned process and plan specification.

There is a philosophical distinction about functionality that exists as a result of evolutionary or intentional design, and a looser semantic of potentially unintended device capabilities that can be evaluated with respect to achieving some goal. A creative approach to process modelling sees overall process objectives satisfied by a selection of devices based on capability regardless of what they were intentionally designed for, but the challenge then becomes how to recognize (enumerate) such capabilities. Other research [8] has been done on the challenge of having plan specifications include “objective specifications” (IAO:0000005) in a language that both humans and robots can interpret, such as “... the goal of having the pancake mix in the hand”; this is not addressed here.

2.1.1. Process modularity variations

There are a few kinds of process model approaches and capabilities which ideally an ontology-driven model can satisfy. A holistic model would capture both autonomous behavior of agents free to roam an environment, actively seeking or waiting for contextual information which they are designed to react to; as well as models limited to describing steps in a workflow, implicitly controlled by a more abstract layer.

Autonomous-oriented process models can express the conditions under which a process is activated – a set of criteria about the required environmental context, input material, energy, time constraints, device(s) and operators. Control-oriented process models can have a parallel layer of controlling processes that supply input signals such as “start”, “pause”, and “stop”, alongside the agent-oriented conditions for activation. For example, the Data Documentation Initiative (DDI) [62] and recent variant DDI Cross-Domain Integration (DDI CDI) [11] provide a process model, partially illustrated in Fig. 3, that exhibits this approach based on W3C PROV provenance specification of which PROV-O is a part [61].

Both kinds of model can be connected in a plug and play fashion to create process dependencies and overall process transformation of material / phenotype from an initial to a final state. Rule engines enact the autonomous approach by monitoring an environment’s state. An autonomous process begins to resemble a control-oriented process the more that its environment is reduced to a narrow set of stimuli / inputs (inputs which cause reactions become more apparent.)

OPEN IN VIEWER

Fig. 3.

A DDI process control schema. (From: CC-BY 4.0 license: “Using the process pattern” — DDI 4.0 dev documentation, n.d., https://ddi4.readthedocs.io/en/latest/userguides/processpattern.html, accessed November 12, 2021).

Workflow specifications and their computational frameworks that enable a network of processes are the backbone for data processing and experimental reproducibility. Workflow configuration is often a process of manual configuration, but many systems such as CyVerse [31], and Galaxy [2], are providing user interfaces for workflow development that show required inputs and context-sensitive options. Ontology-driven process modelling should be able to fulfill this more control-oriented approach by way of “process-control” classes dedicated to adding informatic control of processes.

2.1.2. Process and object centric models

A representational distinction can be made about whether data is being modeled from a process or an object perspective, or both. A process-and-object perspective directly supports a provenance trail – the information about how an entity or its context has been changed in the environment, or some supply chain (Fig. 4). Transformation processes – whether they be assays, data processing methods, or agricultural, storage, shipping or manufacturing methods, link past, present and future states of an entity, which can all be captured in a knowledge graph. This aligns well with product traceability ledgers that document how products are created or transformed in their life cycle by various agents.

OPEN IN VIEWER

Fig. 4.

A combined process-and-object model.

OPEN IN VIEWER

Fig. 5.

A combined process-and-object model can be transformed into an object-only model or a process-only model.

An object-only perspective of entities and their characteristics at some moment in time (Fig. 5) may cover the contextual who / what / when / why / where of a situation but lacks a framework for describing the “how” – what processes led to the synthesis of an entity from its constituent parts in a supply chain. The story of an entity’s past may be abbreviated by way of a shortcut relation like “derives from”, an OBO Relations Ontology (RO) term linking a material entity to its precursor(s). An object perspective is derived from a process-and-object model by replacing any given process with a generalized and therefore less informative “derives from” or “is about” (between information and an entity) linkage between inputs and outputs as shown in (Fig. 5). Similarly, a process model that details input and output entities can be reduced to a “process-only perspective” dependency linkage between processes by replacing the i/o entities with an RO “directly provides input for” relation (Fig. 5). In this view one loses all the details about any characteristics that might have been associated with the objects that processes were subjected to.

2.1.3. Process steps, parts, dependencies and abstraction OPEN IN VIEWER

Fig. 6.

The steps or sub-processes of a main process.

Various process models have a “step” entity, which from a process-control perspective is a convention for naming an abstracted process view and ordering it within a workflow. A step conveys semantics of a process which can be isolated as a controllable event and that either discretely fails or succeeds, and may have states like pause, or restart. A step captures some level of process modularity and control granularity. It must be completed before proceeding to a subsequent dependent step. On closer inspection a process step can usually be broken down into sub-processes (Fig. 6) which may be a network of interdependent components. This level of detail is usually needed for automation or reproducibility. An elegant process model would be able to offer different levels of granular view on a path or hierarchy or network of processes, such that components could have their ordering inferred (as steps) as constrained by input dependencies.

The necessary inputs of an initial subprocess can be associated with its parent process from a flowchart perspective, and likewise for final subprocess output. This generalization might enable all subprocesses to be hidden from view (Fig. 7).

OPEN IN VIEWER

Fig. 7.

A generalized process connected to ultimate inputs and outputs.

The connections between material entities, characteristics, processes and information at some time instant are often taken together to provide the framework for describing possible “states” of a “system”. A system state is described by a snapshot (at some moment in time or across some interval) of the system’s material or information or process entities and their characteristics or roles. While some frameworks only express actions to perform on entities (such as “boiling”), the expression of input and output qualities allows expression of changes in states of a system, and conditions that must be met for processing to continue, such as “wait until the water is boiling”.

Some frameworks also allow processes themselves to have or influence characteristics (for example, BFO “process profile” or RO “regulates characteristic”) that can be observed or controlled, for example the speed of a mixer’s perturbations described by PROCO’s “stir rate profile” (PROCO:0000043).

Characteristics involving input supply rates – such as frequency or energy supply magnitude or rate of material supply have one thing in common – a time variable which is specific to one or more particular process inputs (for example, supplying a faster digital clock frequency, or more energy or catalyst per unit of time). Attaching a controlled or monitored quality to a process is a shortcut for modeling qualities that pinpoint process input or output – a level of detail required for industrial automation.

OPEN IN VIEWER

Fig. 8.

Schematic comparing simple 2 variable observational and experimental study designs (for example dietary pattern and weight).

Experimental study designs make a distinction about which material entity or process characteristics are being treated as controls (or settings), independent variables, or dependent variables. As a prerequisite for success, an experiment’s actual control or independent variable levels must match the experimental design or plan, so a quality control step involves the accurate calibration (measuring) of control device setting levels. Consequently control, dependent and independent designations each depend on a simpler underlying semantic concept of measurement of variables. We can remove explicit naming of which measurements fall into control / independent / dependent variable categories within a study dataset directly, and instead document this distinction in the study design. Figure 8 shows the use of OBO study design related terms in this regard. In the experimental study, drawn with dashed lines, a process is hypothesized to exist directly or indirectly (by proxy) between quality A and B. A study design can take on the delineation of independent and dependent variables. The same data collection structure can then be reused for both experimental and observational studies, and in routine production environments where inputs undergo sampling and/or calibration.

2.1.4. Process model nomenclature

An ontology term label may cater to a specific ontology domain and its expert users, which may seem limiting if repurposed outside that community, but a solution is to augment it with a synonym used by a given application user interface. A “has quality” relation could have an exact synonym “has characteristic” for use within a particular community. Such moves attempt to preserve semantic web data exchange objectives by maintaining database views that can be queried using a reduced set of relations under-the-hood.

A more difficult challenge semantically is to see how much one can rely on the more abstract “glue” or grammar of a generalist ontology – especially its relationships – in order to express specialist ontology concepts. If a generalist ontology suffices, then the chances of plug and play data harmonization across disciplines is increased. The more that specialist grammar is required, the more expensive, sizable, error prone, and ephemeral the learning curve, and the more likely that a semantically fractured data landscape is encountered. However, the core of a generalist vocabulary has a smaller set of relations (like RISC instruction sets in computer science) and so potentially greater sentence complexity (data structure). The focus or granularity of process modelling aims will shape the structures that need to be built out, but ideally one does not have to shift languages or paradigms to construct and maintain a cross-disciplinary knowledge graph.

Terms that may seem semantically interchangeable within a speech community usually require more precise definitions in an ontology, so here we define our use of terms within the context of a generic process model developed within this paper, and avoid the subject of homonym semantics.

A plan: in common language “procedure”, “protocol”, “plan specification” and “workflow” are used to reference informatic (document) constructs that guide process execution. An abstract sense of plan allows steps to be expressed as objectives. In this paper we avoid that challenge, instead focusing on using plan specification for organizing concrete process steps.

A planned process: “operation”, “action”, “activity”, or “procedure” often appear to be equivalent to a generic planned process. If a planned process cannot be broken down into finer-grained “steps”, then it is called a unit operation.

A characteristic: a “characteristic”, “feature”, “quality”, “attribute” or “phenotype” are often used to describe an observable property of an object. Within OBO, BFO uses “quality” rather than characteristic for an observable object property, and so we also frequently use that term and sense below. (In food science “quality” may be used as a value judgement of a product, like a “good quality” ripe peach.)

A measurement: a data item record of a categorical, numeric, or numeric and unit value. The term “measurement” adds a sense of a real-world object being measured. Measurements may be simulated or predicted, and subject to precision and accuracy, and may be the result of faulty or miscalibrated equipment. This paper takes the position that a measurement itself does not include time, place, or sensor “aboutness” information.

An observation: As a noun, an observation is intended as an output data structure of an invasive or non-invasive observation process effectively at an instant or duration of time, and includes at least one measurement that (semantically) “is about” a characteristic of an entity (for example Jane Doe’s weight). Other aspects of an observation may be documented: the particular time and context it happened in, and the sensor (device or human or other organism organ) that was involved. This sense is similar to the Extensible Observation Ontology (OBOE) [45] observation and related terms.

Some use “observation” for qualitative description of phenomena while reserving “measurement” for quantitative recording of underlying characteristics of phenomena; our use has “observation” allow both as components. An observation data item requires a data structure to encompass the contextual information about the time and place etc. of a measurement. A data set composed of these observations could adopt the characteristic values they have in common, for example, if all of a dataset’s observations were made at the same location, then that location can become a characteristic of what the dataset is about, and is inherited rather than repeated at the observation level.

Process ontology implementation can reuse the above relations and terms directly into graph database representation (OWL ontologies provide the sentence structure for writing statements directly into RDF graph databases). For other kinds of databases, ontology terms can be used at a more basic level via lookup tables that name categorical variables and their choices, and numeric or date variables. From a data import/export perspective, the ontology structures discussed so far can translate into native relational database records and vice versa, though knowledge graph querying is most flexibly done in a native graph format. Object and data properties for holding values and units are important (examples are shown in Fig. 9), and vary widely between OBO Foundry ontologies and other ontologies and RDF schemes like Schema [53] and GS1 [19]; their potential harmonization is not covered here.

OPEN IN VIEWER

Fig. 9.

Examples of abstract measures, object and data properties for recording them, and instance data.

3.1. OBO process model

OBO offers a general-purpose process model based on more abstract object properties from a handful of ontologies, which will be reviewed here.

Ontology for Biomedical Investigations (OBI) [7] introduced “planned process”.

3.1.1. Planned versus unplanned processes

A basic distinction is drawn between an “unplanned” physical, chemical or biological process, and a “planned process” (OBI:0000011) that “executes” (COB:0000086) a “plan specification” (IAO:0000104), which is a kind of “directive information entity” (IAO:0000033). This can be for example a word-of-mouth or printed recipe, or in a digital data structure. A chemical reaction process has no such plan specification, only a behavior described by chemical equation. The focus in this paper is on processes that involve plan specifications. It is expected that planned processes can in effect control the behavior of unplanned ones by controlling their environmental conditions and inputs.

RO adopts generic process ontology terms for a number of its relations, such as “has input” and “has output”; OBI extends these with “has specified input” and “has specified output” that pertain to planned process, and which have material entities (for assays) or information (for data transformations) as their targets. Figure 10 shows these relations as well as others that optionally connect to a given planned process.

OBI’s model’s input and output relations and the “has performer” relation (all children of RO “has participant”) can be qualified by a role as shown in pink in Fig. 10, if there is a need to disambiguate participant entities further. For example, the OBI “performing a clinical assessment” process has for input an organism carrying a patient role. It could also have a doctor as a performer, that is, a person carrying a doctor role.

Process parthood is covered by the “has component process” relation connecting to a sub-process; OWL cardinality [43] can be used to mark them as optional; the upstream dependencies of component processes can be specified by way of their input and output entities; this allows for modelling down to an arbitrary level of granularity. Parallel processing constraints are offered by the suite of RO “temporally related to” (RO:0002222) Allen relations which impose restrictions on how processes align with each other – starting or ending at the same time, or in linear fashion (for example see the “starts with”, “ends with”, “preceded by”, “immediately preceded by” relations).

OPEN IN VIEWER

Fig. 10.

OBO + OWL-time process modelling. Inputs and outputs can have qualities (or characteristics) attached to them which can change from input to output.

OBO lacks a generic “step” planned process entity, although the member candidate PROcess Chemistry Ontology (PROCO) [49] has “unit operation in chemical processing” (PROCO:0000051) which looks promising for food applications (Fig. 11), and appears equivalent to PO2’s step described below. Note however that the definition and comment in Fig. 11 goes beyond chemistry domain, so a revision of the label or definition scope is needed. The term “step” (NCIT:C48176) can be found in OBO Foundry member NCIT Thesaurus vocabulary [59] but this vocabulary has not been harmonized with the upper-level COB or BFO classes. These issues illustrate curational dilemmas that occasionally occur within OBO.

OPEN IN VIEWER

Fig. 11.

Protégé view of PROCO unit operation.

Additionally, the OBO plan specification could benefit from an ordered list construct such as the Semanticscience Integrated Ontology’s “list” (SIO:000150) within which to organize steps. As well although there are many matches for an OBO Foundry search on “observation” as a process or data item, none provides a micromodel containing participants, measurements, and time, so this needs to be developed to record process step features. The PO2 review illustrates work in this area.

3.2. OWL-time

A few basic time components are needed in a process ontology model:

Most of this functionality can be supplied by OWL-Time [60], which is in widespread use. Illustrated in Fig. 12, its overarching time:TemporalEntity could be connected to any entity using the “time:hasTime” object property. TemporalEntity is either a time:Interval with a different start and end time, or a time:Instant (where start and end time are the same). Interval specializes into time:ProperInterval, backed up by Allen “algebra of binary relations on intervals” [4] to establish temporal proximity of intervals.

OPEN IN VIEWER

Fig. 12.

OWL-time temporal entity subclasses.

A BFO process could naturally connect with time:hasTime to a ProperInterval, thus gaining access to time:hasBeginning and time:hasEnd object properties for specifying corresponding time:Instant objects (which in turn are specified with xsd:date or xsd:dateTimeStamp datatypes). A ProperInterval also gets a time: TemporalDuration (Fig. 13) which has a variety of value formats. Note that unless a process is explicitly triggered by specific calendar dates (for example a Remembrance Day ceremonial process), modelling can occur entirely with reference to durations, and temporal dependencies between processes can be later calculated or reasoned based on instance data that includes process start or stop times.

OPEN IN VIEWER

Fig. 13.

Using OWL-time to express duration.

One modelling choice is whether to utilize the time:ProperInterval class to structure dependencies between processes. The alternative is to attach statements about process dependency directly to the processes themselves. In that scenario, RO is used to state that process B “ends with” process C, or process A “immediately precedes” B, as in the boiling carrots recipe model below. It would seem like a more intentional design to express dependencies on the processes themselves, and leave reasoning to infer impacts on associated OWL-Time namespace objects.

This raises the question of whether or not any completed process can be reasoned to be a type of time:ProperInterval, since such a process has exactly one beginning and end time, and a duration. If so, that would mean the arm’s length “process hasTime some ProperInterval” relation would no longer be needed, and RO’s Allen relations and OWL-Time’s Allen relations would have equivalent domains and ranges – and therefore could be unified. However, this simplification assumes that a process only inhabits a proper interval, rather than a time:Interval (or BFO one-dimensional-temporal region) that may have gaps or breaks in a timeline. Further work on modelling aggregated processes, for example smoking sessions that occur over time (a focus area of the Human Behaviour Change Project [32]) will be needed for clarity here. Either way, a rule engine (driven by SWRL rules for example) can use OWL-Time to calculate Gantt chart interval dependencies and time points within a process network.

The Exact 2 ontology [56], a prototype designed with reuse of OBO terms, describes the process steps of an experimental protocol in order to enable reproducible experiments. As OBI “protocol” refrains from defining how it might detail necessary steps / processes especially as they involve time modelling (see OBI “waiting” term curator note), Exact 2 defines an intermediate level of process model which contains general “equipment” and “biochemical entity” terms, and over 90 “experimental actions” one finds in a laboratory context. Besides OBI input and output relations (Fig. 14), Exact2 introduces a general “has proposition” object relation that connects an action to various contextual objects such as expressing a condition for an action to proceed, a duration, or a “protocol method” to follow.

OPEN IN VIEWER

Fig. 14.

The Exact2 process model.

Exact 2 has a few OBO Foundry related differences:

Exact 2 avoids investing in a detailed ontology process model because of the problem of maintaining identity of process inputs and outputs mentioned in the OWL logic discussion section. Instead, the Exact 2 project proposes incorporating Petri net modelling terminology that allows discrete state changes, and is often used in computer science and engineering modelling. What we foresee is that the same functionality can be achieved by modelling processes as the loci of state change, with input and output materials, energy, time, and participating devices and agents as factors whose characteristics can be stated to change as a result of a process. Instances of these can then be networked together via input/output relations. In either case rule engines or other transformative queries are introduced to document or simulate the properties of instances of a process model and its transformed materials over time, as noted in Section 2.1.5.

Exact 2 uses PATO to describe typical qualities like volume, speed, temperature that are measured or manipulated in an action. Crucially, the model has been validated on real-world experimental protocols, recognizing 83–95% of protocol actions.

PROV-O, a W3C standard OWL ontology is often examined for process modelling because of its stated ambition of providing “the core concepts of identifying an object, attributing the object to person or entity, and representing processing steps” in order to represent physical or digital object origins. PROV-O aspires to capture provenance information contained in plans (such as workflows or instructions) “which contain descriptions of the entities and activities involved in producing and delivering or otherwise influencing a given object” [50]. This close resemblance to a generic process ontology has drawn many projects to use PROV-O as one despite the absence of key process model features.

An example book publishing model [16] (Fig. 15) describes key PROV-O relations. An overall entity reference is created for the document that links to its various “specialization” states. Anonymous (blank) nodes encapsulate short statements that connect the document in its state before and after being published. PROV-O advocates point out that such nodes could be typed if desired, so we could have instances of classes like “draft book” or “printed book”. Figure 16 offers a brief OBO process-oriented comparison, where the book publishing process is performed by a publisher (Fig. 16). A particular draft book is input to a publishing process with both input and output book entities tracked informatically by book identifier. Note however an RO issue: if the draft book is in digital form, the shortcut “derives from” relation does not apply – it only attaches between material entities. Technically, using BFO “inheres in” might work but is problematic if editing has substantially changed the end product.

OPEN IN VIEWER

Fig. 15.

A PROV-O book publishing model. Credit: Fig. 1 of https://www.w3.org/TR/2013/NOTE-prov-dc-20130430 Copyright © 2013 W3C^® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.

OPEN IN VIEWER

Fig. 16.

An OBO book publishing model.

Introduced in 2018, the Sensor, Observation, Sample, and Actuator (SOSA) ontology [20] is “designed to provide a flexible but coherent perspective for representing the entities, relations, and activities involved in sensing, sampling, and actuation”. SOSA approaches modelling the process of observations with a lower-level set of relations detailing “observations” or “sampling” of features of interest, and the sensors that generate them (Fig. 17).

OPEN IN VIEWER

Fig. 17.

The SOSA model. Credits: https://www.researchgate.net/publication/325644558.

SOSA is the core of an updated Semantic Sensor Network (SSN) ontology which covers the organization of sensors and actuators into systems, and the detailing of their operating characteristics. In the revision of SOSA/SSN observations are now conceived as acts or events. The core, consistent with observation models in other ontologies, provides a common pattern for observation, actuation and sampling which is aligned with PROV-O [25]. However, it represents a break with the original SSN ontology that built upon the SSO pattern in which an observation was effectively a record or description of an observation context (a kind of dul:Situation), rather than an activity in the world (a dul:Event). For further reading on using events versus records for observations, refer to [25].

OPEN IN VIEWER

Fig. 18.

Comparison of SOSA observation and OBO time-enhanced process.

By design, sosa:FeatureOfInterest sidesteps the direct naming of the thing whose feature is being sensed (a domain-specific entity and its qualities), leaving it up to 3rd party ontologies to do so. A “sosa:Observation sosa:hasFeatureOfInterest some sosa:FeatureOfInterest” translates to OBI “assay and has_specified_input some (material entity and has role some evaluant role)” where the material entity is mereologically related to some entity of interest, or has qualities of interest. OBO process model keeps general relation names in play rather than specializing them with “observation/sampling/actuation”.

OBO measures an entity’s quality, but how detailed the location of the quality (e.g. hair color, top of head = grey, sideburns = brown) is similarly left to implementers to structure. If in the life sciences, OBO likely has more capability amongst its member ontologies for describing entities and their qualities (mainly via PATO). Loose equivalencies between SOSA and OBO models are shown to left and right of the dotted grey line in Fig. 18. Time relations on the OBO side are tentative as OBO has no recommendation about such usage.

SOSA “sosa:Result” and IAO “measurement datum” are comparable as they both allow the output of an observation process to be a measurement or computation. “sosa:phenomenonTime” pertains to the (OWL-Time) instant or duration that the characteristic measurement was true of the FeatureOfInterest, rather than the observational process. OBO may benefit from a similar distinction where the end of an observation process doesn’t coincide with the time the measurement is accurate for. As a kind of assay, OBO would also benefit from an explicit “observation” micromodel pattern of observation time and other contextual information.

OPEN IN VIEWER

Fig. 19.

Main classes of PO2 and the relationships between them.

Based partly on the Sensor, Observation, Sample, and Actuator (SOSA) ontology [25], but also situated within the BFO hierarchy, PO2 is designed to monitor industrial food processing, and describe food formulation.

PO2 can represent a food transformation process described by a set of experimental observations available at different scales and evolving in time through the different unit operations of a production process. The initial model called MS2O (Multi-scale Multi-step Ontology) was built to represent a bioprocess of yeast production and stabilization [14] and further developed to fit the need of dairy gel manufacturing and the integration of heterogeneous data [23,44]. Finally, the core model of PO2 was reengineered with SOSA/SSN to be able to adapt to any transformation process.

The design of PO2 ontology meets three essential needs:

Therefore, the ontology is designed in two layers: a core layer and a domain layer. The core ontology PO2 is dedicated to the generic modeling of both transformation processes and characterization processes (called transformation process observations). PO2 core model reuses various existing ontologies: BFO, SOSA, IAO, Time Ontology and QUDT. PO2 Dairy gel [48] and biorefinery [9] domains are publicly available, and other private and public domains representing the characteristics of foods during manufacturing are complete or in development.

Figure 19 shows the main classes of PO2 and the relationships between them, including:

4.1. Process relation comparison

Harmonizing the language of semantic web content such that queries can traverse it without needing translation is a future ideal to incrementally progress towards. Having more participants agree to use stand-alone components like OWL-Time helps this effort. Ideally a single set of general process ontology design patterns that work across domains could be adopted, but so far none of the design choices have universal appeal so they must be hashed out to achieve greater consensus. Table 1 surfaces various classes and relations that our compared ontologies have for process modelling. Discussion and our recommendations for consideration by the OBO community are provided below.

4.2. Prototype FoodOn recipe model

FoodOn will incorporate a general food-related process model so that food processing methods can be detailed in a series of micromodels specific to each kind of food or process ranging from the apparently simple act of cooking or boiling, to following a consumer or industrial recipe process. Because of reasoning limitations, the emphasis here is more on finding value in data structures that conform to ontological distinctions about the world, rather than achieving reasoning prowess over the data itself. The design patterns below are mostly prototyped in diagram form to generate discussion about needed entities and relations, but a portion of them are currently being added to FoodOn.

OPEN IN VIEWER

Fig. 20.

Types of FoodOn ingredient.

OPEN IN VIEWER

Fig. 21.

A FoodOn recipe model prototype.

Currently FoodOn has extensive vocabulary for single source ingredient composition – the taxonomy and anatomy of organism ingredients. For multi-component food composition, FoodOn allows food product classes and instances to refer to ingredients (themselves food products including additives) by way of “has ingredient” and “has defining ingredient” (Fig. 20), the latter pointing to an ingredient that a food product can’t do without, for example potato leek soup must minimally have those two ingredients. Ingredients are considered intentional additions; if a process unintentionally adds a substance to a food, the “has substance added” relation applies.

These ingredient relations alone might suffice for a shopping list but recipe ingredients are usually associated with steps, and must be ordered in product labelling, so we need an ingredient set to be transformable into ordered lists with quantities conveyed by rank, proportion or absolute value. Often a recipe also needs devices – even a simple layout table or spoon must be accounted for as a resource – which reveals the potential complexity of even small processes from a machine comprehension perspective. At the same time, vocabulary reuse at different scales of modeling – from kitchen to laboratory to robotics – hopefully falls into patterns of reuse, such that fewer relationships are needed as a generic process model develops, with the focus being more on defining new subclasses of process, material entity, device and information.

The proposed FoodOn recipe model in Fig. 21 has a number of new components (shown with dashed borders) including an “ingredient set”, a “device set” and an “instruction set” of step specifications which respectively allow reference to food materials, devices, and the planned processes they feed into. These sets will be subclasses of IAO data set (IAO:0000100) which is simply a set of things of the same kind. Some amount of instruction set recursion is needed where recipes have overall stages or steps, with each step itself potentially having an instruction set component. Each ingredient specification references a food material (product, intermediary product, or additive, or choice thereof) but also a proportional, count or scalar measurement of it. Device capabilities are stated by the device specification (pot, pan or bowl size, dish oven temperature rating etc.). Free text commentary or instruction can potentially be linked to any of the class entities by using annotations such as “dc:description” or “rdfs:comment”. The recipe model currently does not include serving procedures or portions, or derived nutrition or cooking duration information.

One example of the IAO “mentions” object property is shown (between instruction set and planned process) as an optional shortcut, in the case where an ingredient, device or step specification is skipped. A hierarchy of “capable of part of”, “capable of”, and “enables” relations allows itemizing which devices (or tool or equipment) can partially or completely enable a planned process to produce output. The “has performer” object property references a person or other kind of agent/robot which operates devices and is accountable for the task.

OPEN IN VIEWER

Fig. 22.

Partial boiled carrots recipe plan specification.

We see how an OBO-centric model fares with a simple “boiled carrots” recipe example shown partially in Fig. 22, essentially “boil a pot of water, clean and chop carrots, add to the pot, cook for 5 minutes”, with a diagram shortcut insofar as it references already cleaned and chopped carrots. Volume and mass of ingredients and containers can be specified, and all inputs to processes.

OPEN IN VIEWER

Fig. 23.

Basic input/output model for putting water in a pot, and an instance-level example.

Focusing in on the first step, Fig. 23 shows the general input/output of an “adding liquid to container” process, and then details about putting 0.5 litres of drinking water into a 3-litre pot, a process measured to last 1 minute. Instance-level statement entities are shown with a dotted border – these are specific parameters, settings, measurements of ingredients or devices or process inputs or outputs that can be referenced directly in the specification elements of Fig. 22.

The result of the process is shown towards the right where x_water2, an instance of water, is located in x_pot2 an instance of container. In this case x_water2 appears one and the same as x_water1, and x_pot2 appears to be the same as x_pot1. However, if the state has changed – say from a “x_water1 not located in x_pot1” state, to a “x_water1 located in x_pot1” state, then such states have to be isolated to avoid being unsatisfiable. For material tracking purposes, attaching tracking identifiers to these instances, for example an identifier which points to both x_pot1 and x_pot2, may suffice, as described in the OWL reasoning section.

A research question is to what extent axioms and reasoning could be applied so that relations surrounding inputs such as x_water1 could be selectively inferred to outputs such as x_water2 as a result of attaching a common identifier to both. For example, can it be inferred that x_water2 is also drinking water, or that x_water2 volume is the same as the added volume? Additionally, a plan specification may dictate process durations and device specifications (like the 3-litre pot), but these values can also be added to instance parts of a process as observed measurements, thus providing an opportunity for reasoning over the satisfiability of real-world or simulated recipe experiments.

As shown in the Fig. 24 Protégé screenshot, process classes can have axioms about specified inputs, outputs, and devices. Here “adding liquid to container” class mentions “food (liquid)” in its axioms.

OPEN IN VIEWER

Fig. 24.

Axioms indicate valid inputs and outputs and devices of the “adding liquid to container” process.

OPEN IN VIEWER

Fig. 25.

Heating liquid in container.

The next step involves heating the pot until its water is boiling (Fig. 25). Here we need to acknowledge different ways of sensing the process end state – either by hearing the rumble of bubbles or whistle of a kettle, or by sight, or a thermometer. Measuring temperature is actually more complicated because of the varying boiling temperature based on atmospheric pressure, water salinity, et cetera. We can forestall that modeling challenge by just expressing that the output of the process should be a boiling water entity, and define that separately.

Similar steps follow, in adding carrots, bringing the pot back to a boiling state, keeping it “on the boil” – a process of adjusting heat input while counting down a duration – and draining. Figure 26 illustrates how the entities from the various steps could plug together. Since each process needs to stand on its own, in a plug-and-play fashion, it must define all its input and output entities, and connect to its peer processes on those entities. Note that while OBI “has specified input” or output relation pertains only to planned processes, RO’s “has primary input” and output relations can pertain to both planned and unplanned processes. This is still a broad impression of a full-automation itinerary – the “unit operations” here would be broken down into many more steps for a robot to accomplish.

The above recipe use-case yields an additional list of proposed entities and object properties the authors of this paper recommend for FoodOn or OBO inclusion.

Information content entity data sets:

OPEN IN VIEWER

Fig. 26.

Boiled carrots recipe process-oriented view, and the more detailed input / output view.

Plan specification types:

Object properties:

Kitchen utensils and equipment as well as an extensive list of food processes will also be required, but can be added incrementally to FoodOn or the Environment Ontology [10] (which houses manufactured products) or other ontology as needed.

This model can be advanced in a number of directions – by linkage to ingredient information such as nutrition, allergenic risk, ingredient substitutions, and ecological footprint assessment. Cultural practice and image elements could be included and device settings can be demonstrated. Another research task is to determine what logic or information is required to infer steps – clusters of one or more processes – from a recipe model dependency graph. Similarly, the development of more abstract recipe summaries may be possible by a transform that yields top-level processes and all underlying ingredients. Validation of the model could be achieved by testing against the content of recipe database projects.