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

for the two constrained cases, respectively. Now the number of visited nodes
per search depth increases faster, until 973,788,715 and 894,577,045 nodes
are expanded in a search depth of 20, which still took less than one hour.
Finally, Figure 7.8 confirms the expectation that also the number of vis-
ited nodes in the microarray data analysis scenario can be influenced by the
application of constraints. However, as the domain model is also more com-
plex and enables a greater variability than those of the GeneFisher-P and
FiatFlux-P scenarios, the decrease is not as striking as in the previous two
examples and the search depth that has finally been reached is not as high. In
fact, the domain constraints and the additional enforcement of a particular
data provisioning service and a particular annotation service lead to roughly
the same numbers of visited nodes, namely 9,320,707,579 and 9,148,899,935
in depth 11, respectively. Exploring them took nearly 10 hours.
The evaluation of the number of visited nodes shows that constraints can
decrease their number effectively and thus decrease the time that is required
for exploring a particular search depth. At the downside, the more constraints
are applied, the longer takes the construction of the automaton from the
constraints prior to the actual search. However, this step is usually faster
and in summary not crucial for the runtime performance of the complete
synthesis process.

7.2 Loose Programming Pragmatics

In the light of complex and evolving applications, it is impossible to provide
a semantic workflow environment that suits all application scenarios equally
well. In particular, there is no such thing as a unique “perfect” domain model,
just as there is no ultimate synthesis strategy that fits all situations. How-
ever, the experiences gained from working on the applications revealed some
rules-of-thumb for domain modeling and synthesis application that help to
approach loose programming pragmatically and exploit its capabilities as far
as possible. In the following, Section 7.2.1 discusses principles for the inte-
gration of services for workflow applications and as adequate foundations for
semantic domain models, before Section 7.2.2 focuses on pragmatics for the
actual semantic domain modeling and Section 7.2.3 presents strategies for
the pragmatic use of workflow synthesis.

7.2.1 Service Integration

Clearly, the services in a domain model should in the first place provide the
functionality that is required for realizing the envisaged application(s). How-
ever, the granularity of the services in the domain model is an equally central
and crucial aspect, especially when working towards user-level workflow de-
sign (cf., e.g., [206, 197, 261, 211, 199]).