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

for molecular sequences and integers for amounts. Hence, the parameters
defined by the web service interface can easily be used as SIB parameters.
As contrasting examples, the EBI and BiBiServ web services considered for
the phylogenetic analyisis and GeneFisher-P scenarios (cf. Chapters 4 and
5) use custom data types in their interfaces to combine all input data into
a single input object. These are indeed easily accessible for a programmer,
but not for a non-technical user. Hence, the corresponding SIBs expose only
the application-relevant data as parameters, and handle the assembly and
evaluation of the service's input/output objects internally. The complex data
structures of the FiatFlux-P and microarray data analysis scenarios (cf. Chap-
ters 5 and 6, respectively) are completely kept within the raw data files and
those that are produced by the different services. Accordingly, the SIB pa-
rameters in these applications contain references to the files and additional
configuration information, but no actual data.

7.2.2 Semantic Domain Modeling

As detailed in Section 2.3.2, the semantic domain models of PROPHETS are
entirely based on symbolic names for services and data types, and the seman-
tic service descriptions are completely decoupled from the SIBs that imple-
ment the actual functionality. The latter is one of the central improvements
in contrast to earlier implementations of the synthesis method, where the
semantic interface annotations had to be provided by the SIB programmers
already during SIB implementation and could not be changed later. Clearly,
like this the semantic description(s) provided for a service can be freely de-
fined by the domain modeler: he can, for instance, use his own terminology,
use the same service for different purposes, or simply omit unnecessary details
in the interface description.
Nevertheless, domain modeling remains a challenging task, which has to
take into account a plethora of aspects and naturally depends massively on
the different characteristics of the various application domains. Accordingly,
each domain modeling process is different, and not too many general rules
can be laid down. As in all software engineering processes, finally a good
amount of experience is required in order to determine the adequate levels
of abstraction for components and interfaces. However, two general domain
modeling paradigms can be identified:

1. define a precise domain vocabulary ,and
2. keep the semantic service interface descriptions simple .
What this means in the context of the Bio-jETI framework is discussed in
greater detail in the following, accompanied by examples from the considered
application scenarios and other Bio-jETI and jABC applications.
Note that since also the most carefully designed domain model can not be
expected to suit all possible application scenarios equally well, loose program-
ming explicitly encourages the workflow designer to “play” with the semantic