Conclusion - User-Level Workflow Design: A Bioinformatics Perspective - page 191

and consistent naming to make the next generation of the framework directly
recognizable as a mature variability management framework.

9.2.2 Continuation of the Bioinformatics
Applications

The bioinformatics workflow scenarios discussed in this topic are only four
examples from the plethora of possible applications. In fact, there are already
several further Bio-jETI workflow applications originating from different con-
texts available. For instance, LC/MS analysis [158] and orthologuous ID re-
trieval [200, 128] workflows were realized in the scope of the first collaborative
projects, and functional annotation or other sequence analysis workflows were
implemented by various student projects. Furthermore, some (still experimen-
tal) projects explore the workflow integration of the Cytoscape network anal-
ysis and visualization platform [280] and the metabolic flux analysis software
OpenFlux [259], or address the realization of the DDBJ workflows [4]. So
far, however, these applications have not made use of the developed methods
for constraint-driven workflow design. Accordingly, future work will certainly
comprise to challenge and evaluate the constraint-driven workflow design ap-
proach on these (and further) bioinformatics application scenarios.
In general, two major challenges can be identified with regard to the appli-
cation of the constraint-based workflow design methods in the bioinformatics
domain: capturing domain knowledge and promoting the methodology in the
target user community. They are described in greater detail in the following.

Systematic Capturing of Domain Knowledge

As discussedabove,a gooddomainmodel is necessaryfor the successful applica-
tionof(semi-)automaticworkflowcompositionmethods, but thecrucialaspect
is how an adequate domain model should be developed. Although this aspect is
consideredfrom the Bio-jETI perspective here, it is in the same way relevantfor
other semantic workflow management systems that follow similar approaches.
As for the domain-specific vocabulary, EDAM has proved itself being an
adequate basis, and service annotations in terms of the controlled vocabulary
it defines facilitate finding possible workflows [180]. In some cases, however,
additional terminology may be needed to describe highly specialized services
or data. What is more, the workflows that are principally possible according to
the mere interface annotations are not necessarily also the actually intended
solutions. Accordingly, additional knowledge may have to be included in the
domain model or in a concrete workflow specification to constrain the search
further to the actually intended solutions. This additional knowledge can be
provided by two kinds of constraints:

• Constraints that express relationships between individual services or data

types, such as that service A must always be followed by service B ,or
that a service C must not be called before service D .