Action page

When opening an action, the user is directed to the main panel of the action, which is the panel associated with the action type of the action. In the main action page and subaction pages, an action can be configured, simulation jobs can be started, and the results can be evaluated. An example is shown in Figure 7. This panel shows the following sections:

• Scope: Links to the scope-panels in which the scope entities of the action can be set (e.g., foods or substances).

• Inputs: Links are shown for panels in which the calculation inputs or selection inputs can be set (e.g., concentration models that are inputs for computing dietary exposures).

• Data source: If the action is a data action, then a form is shown in which the data source should be specified (e.g., selection of the concentration data source in a concentrations action).

• Settings: A form is shown in which the calculation and/or selection settings of the action can be set/changed (e.g., specify the exposure type, chronic/acute, of an exposure assessment).

For all modules of the toolbox, panels have the same structure. Within the panel, data sources and settings for the current action can be specified. In addition, the scope and input sub-module links that are relevant are shown. In this way, the user can follow the structure of the modular design to select the data and settings required for running the action. Besides the panels associated with a (sub)action, there is also a summary panel  in which the main settings and data of the action are summarized, an output settings panel in which more general output settings can be specified, an uncertainty settings panel  in which the uncertainty analysis options can be specified, and a results panel  that shows the running tasks and the results of the action. An alternative form of navigating from action to sub-action is provided by the navigation menu in the left sidebar that can be expanded/collapsed by clicking on the menu button on the top left in the Action bar. In this menu, all necessary modules for the complete actions are shown in one list, allowing for a linear way of navigation.

An action is valid and ready to run if all scopes and inputs are valid and all required data and settings are configured. For each subaction, the check symbol  indicates that it has been confidured correctly and is ready to run. In case the subaction has a warning symbol , some user action is required. When the main action is ready to run, then a simulation job for the action can be started by clicking the run button  on the top right in the grey action bar. Optionally, subactions can be started by clicking the run button  on the top right in the green (sub)action bar. Clicking the run button will send the simulation task of this (sub)action to the job-scheduler, and the progress of the task is shown in the results panel . When the task is completed, the output will be available in the form of a screen report and the report and downloads will be available to download the report as pdf, and the data in csv file format.

Figure 7 Screenshot of the main page of an action.

Scoping: entity selection

Selection of the primary entities so far as relevant for an action lies at the basis of each action of the toolbox. Also for other entities selection may be useful. Scoping of the action is defining the members for its primary entities, and sometimes also for other entities.

As an example, Figure 8 shows a screenshot of the substances module panel. At the top, the data source file can be selected containing the dataset of primary entity definitions. In the selection card, a selection can be made of the entities in the dataset that are relevant for the current action. Note that if no explicit selection is made, the scope is set to all entities by default. In the settings form, additional (selection) settings are shown, e.g., selection of the index substance which may be relevant for the chosen action type. In this way, the scope of the action can be specified by selection of the primary entities.

The panels for the data modules have a similar structure and selection is essentially the same. The only difference is that data actions always have a scope. I.e., data modules always relate to one or more primary entities.

Figure 8 Screenshot of the substances module panel as an example of a primary entity module panel.

Implicit versus explicit scoping

MCRA distinguishes between implicit and explicit selection of entities (scoping). By default, the selection is defined implicitly as ‘all entities’ found in all data linked to the action. For instance, the substance scope will be all substance codes found, not only in the substances data source, but also in the other data sources that link to substances (e.g., the substance codes of the concentration data or the points of departure data). Given an implicit selection, also explicit selections can be made in the specific module panel of this data type (e.g., by selecting the substances in the substances panel). Once made explicit, selections are no longer automatically expanded when new data sources are linked to the action.

For example, the substances scope shown in Figure 8 is defined explicitly, having three substances in the scope, and excluding 1626 substances that are present in the provided substances data source and/or other linked data sources. By pressing the clear filter button, the explicit scope can be cleared to become implicit again, effectively yielding a scope of all substances in all linked data sources, in this case 1626 + 3 substances.

Comparing new data to set scopes

When linking a data source to an action, MCRA checks whether the data links well to the current scope (selected entities) of the action and reports the results. For instance, when linking substance concentration data to an action which has already an implicit or explicit substance scope, it should be checked if and how the substance codes used in the concentration data match with the current substances scope. But the check is also performed when linking a primary entity substances data source to an action wich has already a set substances scope due to already selected other data sources.

When linking a data table from a new data source to an action which has already a defined scope for one of the entities in the table, there are three possible states for entity codes:

• codes included in both the scope and the data source

• codes included in the scope, but not present in the data source

• codes included in the data source, but not present in the scope

The first case represents a successful link, which requires no further action. For the second and third type of mismatch,it depends on the type of data link whether this is considered a serious problem (red flag ) or merely a point of attention (green flag ). For instance, in the case of concentration data, these may be assumed to be zero for certain substances, and therefore MCRA allows missing concentration data for part of the substances in the scope: therefore a green warning symbol will be shown. The data sources may also contain codes that are not in the scope (e.g., substance concentrations for other substances as well), and it may be desirable to extend the scope with these substances. Also this situation is flagged with a green warning symbol.

Figure 9 shows an example of a point of departure action. The substances scope has already been defined by other data in the action (in this case points of departure data), and subsequently a substances data source is selected. Here, there are 140 substances in the current scope (explicitly defined). However, 132 of these 140 substances are not present in the substances data source (not in table). Hence, we are missing the definitions of these substances. This is considered a critical linking issue that should be solved by updating the substances data source to include these substances, therefore a red warning symbol is shown. On the other hand, the substances data source also contains 3 substances that are not part of the current scope (only in table), this situation on iots own would only lead to a green warning symbol, but is overruled in this case by the red warning symbol.

Figure 9 Screenshot of checking substances data in a substances data source against an already set substances scope.

Another example is shown in Figure 10 where a points of departure data source is selected, dependent on the primary entities effects and substances. In the case of effects, we observe no linking errors, hence the data source matches perfectly with the effects scope. For substances, we see that there are 7 substances that are in the selected data source but not in the substances scope (new) and for 3 substances in the scope we don’t have a point of departure (not in table). The former is fine, but we may want to extend the scope with these 7 substances (add to scope) and the latter should not have to be a problem, but it is a point of attention. Also, one may want to choose to remove these 3 substances from the scope (remove from scope).

Figure 10 Screenshot of checking substances data in a POD data source against an already set substances scope.