3. An overview of Research Objects back to ToC
Research Objects aim at providing support for the description of scientific investigations in a machine readable format.
In addition to the scholarly article that reports on the results of the research investigation, a Research Object encapsulates
other resources that enable and promote the reuse, interpretation and reproducibility of such investigation results. In
particular, a Research Object comprises the datasets used and generated during the research investigation, the workflow encoding
the experiment carried out, the provenance traces captured by running the experiments and the various annotations that describes
resources and their relationships.
Figure 2 illustrates a coarse-grained view of the Research Object model.
Here we focus on Workflow-Centric Research
Objects, i.e., Research Objects that contain at least a workflow. As illustrated in Figure 2,
a Research Object aggregates a number of resources, namely:
- A Workflow, which defines a template with the interconnected series of steps necessary to specify a given
experiment;
- The WorkflowRuns that identifies a given execution of a workflow. Workflow runs in Research Objects are
accompanied with provenance information specifying, amongst other things, the inputs used to feed the execution
of the workflow, the intermediary steps of its internal steps as well as the results obtained at the end
of the workflow execution;
- The Annotations used to describe the current Research Object, its resources and their relationships;
- Other resources used to help providing context to the research investigation, e.g., a paper describing the research,
the hypothesis of the experiment, bibliography related to the experiment, conclusions and interpretations
of the results, configuration files, etc.
The Research Object model is represented by a family of ontologies, divided into a Research Object Core
Ontology and extension modules that cater for different domain specific requirements (Research Object evolution,
scientific workflows, etc.). RO-Opt extends the Research Object Core Ontology and the ontologies used to specify
Workflow-Centric Research Objects: the wfdesc ontology (used to specify workflow templates)
and the wfprov ontology (used to capture the provenance traces of the workflow executions).
3.2. RO-Opt as an extension of the RO model
In this section we describe the different parts of an optimization, according to Figure 1.
3.2.1. Algorithm
As the fitness landscape of scientific workflows can be rugged
and contain less gradient information, meta-heuristic search
methods are convenient search algorithms (opt:Algorithm) to deal with the
optimization of scientific workflows.
Figure 3 shows the type of search algorithms we focus on this
paper: Genetic Algorithms (opt:GeneticAlgorithm), Particle
Swarm Optimization (opt:ParticleSwarmOptimizationAlgorithm) or other methods that are conceivable and can
be implemented as a plugin of the optimization framework.
The used optimization algorithms should be stored for typing and comparing aspects. Not only the type of algorithm but
also the specific parameter of the algorithm may be reused in later optimization runs.
3.2.2. Fitness
In order to automate the optimization process, workflow results are evaluated by the optimization algorithm. The workflow result is
based on an output parameter (opt:FunctionOutputParameter), which represents a specific fitness measure
(opt:Fitness). Figure 4 depicts an overview of the fitness section of the ontology. The fitness measure may
consist of one or several output parameter. Several parameters and weights are used, if the user wants to perform
a multi-objective optimization (opt:MultiObjectiveFitness) instead of a single-objective optimization
(opt:SingleObjectiveFitness). Multi-objective optimization tries to solve problems that have two or more, often
conflicting, objectives. Single-objective optimization in turn tries to solve only a single objective. The fitness function
(opt:FintessFunction) associated to the fitness measure can store not only output parameters and weights but also
a body (opt:hasBody), which may contain a piece of code representing a unique measure description.
3.2.3. Generation
During the optimization process each workflow instance of a population of size y is executed. Each of these instances is
made up of a unique parameter and component combination. After the execution and evaluation of the workflow instances,
a new generation of unique workflow set-ups is executed. To monitor the population evolvement, each individual workflow run has
a corresponding generation number (opt:hasGenerationNumber). Additionally, the population size of each generation is stored
(opt:hasPopulationSize), as this number can vary for optimization runs in general and each generation in particular.
3.2.4. Optimization Run
Results obtained during the optimization process may be of interest and required to learn from in later optimization
runs (opt:OptimizationRun). Thus the executed workflow instances and their results should be captured as well. However
we recommend against storing the entire provenance trace of a workflow run if the original trace has already been
saved. This is due to the fact that, usually, many relevant data objects (e.g. intermediate results) are already stored to
achieve reproducibility. We assume that these data objects are negligible when achieving optimization reproducibility
and especially when learning from optimization runs. The crucial values to capture are fitness values (opt:hasFitnessValue) and a
flag (opt:Flag), which depicts the origin of the fitness value. As shown in Figure 5, the flag indicates that the
fitness value may have been
calculated (opt:Original), approximated (opt:Approx) or just taken from a prior similar or identical optimization run
(opt:LinkToOriginal). The flag allows users to relate where the specific fitness value originates from. In particular, when optimizing identical
workflows it would be useful to reuse fitness values from prior optimization runs (and use the opt:LinkToOriginal flag).
3.2.5. Search Space
Each workflow adaptation represents one specific set-up and can be sampled within a specific search space
(opt:SearchSpace). The search space is spanned by the selected workflow parameters and/or structural changes. As not all parameter
values or combinations of components are valid, the number of tested workflow set-ups can be reduced by intelligently
sampling the search space by an optimization algorithm. The dependencies of the search space should be stored in order to
allow other optimization processes to reuse the search space later. As shown in Figure 6, the search space comprises
component and parameter dependencies (opt:ProcessorDependecy and opt:ParameterDependency) respectively) as
well as parameter constraints (linked with the data property opt:hasParameterConstraint).
Constraints can limit possible values for parameters. Whereas numerical parameters (double or integer) may be limited by
a minimum and maximum value, other parameter types may also be limited. As an example, a parameter can be defined
by a regular expression or by a fixed list of valid values. Parameters and components might also have specific dependencies.
For example, a parameter A can be dependent on
another parameter B by e.g. a numeric sum dependency such as A + B = 1. In a similar manner, workflow components
can be dependent on each other. Consider for example the following component dependency: a task can be performed
by component D or A and another task by component B or C. Additionally, component A can only be executed together
with component C but not with component B. These dependencies can be asserted with the opt:onParameter and
opt:hasTargetProcessor properties.
3.2.6. Termination Condition
The optimization process will stop at a certain time preferably if the algorithm has converged. However this may be a
heavy time consuming task, and thus the user often wantsto add additional termination criteria. The termination condition
(opt:TerminationCondition) should be stored due to reasons of the plausibility of the optimization run. The
termination condition precisely stores under which condition the optimization is to be terminated. This can be the maximum
number of performed workflow executions (opt:hadMaxNumberOfExecutions), the maximum number of evolutionary
steps (opt:hadNumberOfSteps), the required time for the optimization process (opt:hadMaxTime), a reached fitness
value (opt:hadFitnessReached) or a number of generations that did not improve the fitness measure (opt:noChange).
Depending on the workflow, the search space settings and how strict the termination conditions have been selected,
inferences on how valuable the final best result is, can be made.
3.2.7. Workflow
The original workflow (wfdesc:Workflow) should be stored within the Optimization Research Object to increase the optimization
process discoverability (with the opt:hasWorkflow property). The workflow may be stored in an abstract or concrete fashion to capture
the scientific experiment. Together with this resource, one representative workflow run (wfdesc:WorkflowRun) should be stored,
to capture all used input data.
3.2.8. Link to best results
To ensure a fast and eased analysis, link(s) to the best result(s) (opt:hasBestResult) should be stored. For single objective
optimization one link is stored, for multi-objective optimization several results are stored representing the Pareto Front.
Finally, Figure 7 shows a complete schema of all the classes, properties and data properties of the RO-Opt ontology, and how they are connected to the Research
Object ontologies.
Workflow optimizations can be performed by different optimization algorithms. Typically, one optimization algorithm is not best suitable for each optimization problem and another may be tested. Examples are opt:GeneticAlgorithms (GA) or opt:ParticleSwarmOptimization (PSO).