# Food Passports and Intelligent Food Recipes: The Data-Oriented Way of Producing Food
## 3 Results  
### Defining Human- and Machine-Interpretable Dynamic Recipes  
To illustrate the realization of the architecture, one uses a mock-up implementation of the proposed MAS-based architecture and a fictitious and simplified application case. The mock-up implementation is publicly available in [[https://github.com/luferi/AROMA_Project](https://github.com/luferi/AROMA_Project)]([https://github.com/luferi/AROMA_Project](https://github.com/luferi/AROMA_Project)) (accessed on 1 January 2024). In the distributed code, the use case is simple: a Food Preparator wishes to develop a dynamic recipe for sugary water. The recipe should specify the ingredients of the recipe, the preferred ratios of said ingredients, and the resources included in the execution of the recipe but also the orchestration of said resources. All of the above must be specified in a machine-interpretable format; otherwise, the recipe becomes unusable from a DRA perspective. As discussed before, Food Preparators should not be forced into learning a new programming language but at the same timeneed support in specifying all of the above in a consistent and machine-validatable way. An obvious solution is the development of a Domain Specific Language (DSL). A first proposal of the AROMA DSL is given in the grammar below (see Listing 1, where, for the sake of simplicity, the lexer rules are omitted). The grammar uses the ANTLR4 [29,30] grammar notation that is a variation of the EBNF form. A few selected production rules are highlighted and discussed next due to their relevance to the requirements discussed. ```
1 recipe:RECIPIEIDENTIFIER{'description?ingedientsresourcesflow'}';
2 description:DESCRIPTION'{'STRING_LITERAL'}';
3 ingedients:INSPEDIFIER{','ingedient+ingedient_ratiomix_function_info'}';
4 ingedient:IDENTIFIER{','range'}';
5 ingedient_ratio:DEFAULT_MATIO{'}{'IDENTIFIERNUMBER_LITERAL}(','IDENTIFIERNUMBER_LITERAL','IDENTIFIERNUMBER_LITERAL')';
6 mix_function_info:MIX_FUNCTION{'FUNCTION_JAVA_SIGNATURE'=' STRING_LITERAL','}JAVA_PACKAGE{'=' STRING_LITERAL'}';
7 resources:Resources{','resource{'}'}';
8 resource:RESources{','function*+'}';
9 function:FUNCTIONIDENTIFIER{'parameter'}';
10 parameter:(INPUT_PARAMETER[]OUTPUT_PARAMETER]IDENTIFIER{'TYPE(NUMBER|STRING|BOOL|ENWERRATION){','range}'}';
11 range:(numeric_range{'range}'interval_range{'enumerated_range}');
12 numeriThe list of resources specifies the resources (rule _resource_, in line 8) required for the execution of the recipe as well as their functions (rule _function_, in line 9). Functions have input and output parameters (rule _parameter_, in line 10), and the values of said typed parameters can be optionally constrained by ranges (rule _range_, in line 11). The next part of interest is the flow of the recipe (rule _flow_, in line 15), which specifies the syntax for declaring variables and the execution order of the functions of the recipe's resources. In a food recipe, the actions that need to be carried out do not always conform to a sequence of actions. To that end, the AROMA DSL allows the specification of sequential actions (rule _sequence_, in line 22), parallel actions (rule _parallel_, in line 25), repetitive conditional actions (rule _repetition_, in line 26) and decisions (rule _decision_, in line 27). These flow control modifiers define how other flows, or the resources' functions, are to be executed. One can obtain a better appreciation of the DSL in action by examining the recipe for the sugary water earlier mentioned (Listing 2).