Lessons Learned - User-Level Workflow Design: A Bioinformatics Perspective - page 137

have to be handled is also within a feasible range. As it contains a handful
of services for the creation of data “from scratch”, a couple of constraints
are required to prevent their unrestrained use by the synthesis. Some specific
constraints of the FiatFlux-P application can, however, not be expressed with
the constraint templates provided by the PROPHETS plugin and require the
definition of additional temporal logic formulae.

Application Scenario 4: Microarray Data Analysis Workflows

The domain model for the microarray data analysis workflow scenario com-
prises 27 services and is thus considerably larger than the previous two
example domains. Like FiatFlux-P, it does not apply the EDAM termi-
nology, however because the microarray-related terms in the ontology are
not precise enough for describing the services and types in this application
scenario. As microarray data analyses are typically linear sequences of ser-
vices (“pipelines”), the workflows for this example can be entirely created
by PROPHETS, which is based on a linear-time logic synthesis algorithm.
Furthermore, the workflows of this example are comparatively long, typically
comprising at least 6 principal analysis steps, which are often themselves
composed of different services. Accordingly, creating proper microarray data
analysis pipelines manually is not that easy, and their (semi-) automatic syn-
thesis achieves a considerable simplification.

As discussed in greater detail in [233], the adequacy of the synthesis so-
lutions largely depends on the domain model: the closer a domain model is
tailored to a specific application, the less effort (in terms of formulating addi-
tional constraints) is required from the user to arrive at the actually intended
workflows. In this regard, considerable differences can also be observed be-
tween the example applications:

• The EMBOSS domain model contains a large number of tools for similar

purposes (sequence analysis), but has not been designed for a particu-
lar application. Consequently, it provides more possibilities for service
combination than a user can handle, and additional knowledge has to be
incorporated in order to constrain the solution space to a manageable size.
In addition, the EMBOSS example shows that service interface annota-
tion in terms of a comprehensive domain vocabulary (EDAM) alone is
not sucient.

• In contrast, the manually defined GeneFisher-P and FiatFlux-P domain

models have been tailored to a specific application. That is, the domain
vocabulary has been designed specifically, the services provide exactly the
functionality that is needed, and additional domain-specific knowledge has
already been formalized and integrated into the domain model. This shows
that in domains with many purpose-specific services, a good amount of
the domain knowledge is often implicitly integrated in the service interface
design, and does not have to be provided via constraints explicitly.