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

data types (such as PCR primers ) are contained in EDAM. In this scenario,
there is furthermore a small number of services (providing common function-
ality such as file reading and writing) whose semantic characterizations are
not specifically covered by the EDAM ontology. Usually, grouping too many
services within too generic semantic categories comes with the risk of prevent-
ing the synthesis framework to distinguish them properly. However, as the
domain model here is comparatively small, and the services in question are
quite different per se, it turned out to be sucient to use the closest, yet quite
generic, EDAM terms for their annotation. Thus, also in the GeneFisher-P
workflow scenario the taxonomies of the domain model are based on an ex-
isting ontology.
In contrast, the domain models for the FiatFlux-P and microarray data
analysis workflow scenarios do not apply EDAM terminology. Although there
are terms for the fields of metabolic flux analysis and microarray data process-
ing contained in the ontology, they are very generic and as such not adequate
for the annotation of services that perform very particular operations. Hence,
own terminology has been defined for these domain models, specifically pro-
viding the semantic categories that are relevant for the respective applications
at an adequate level of abstraction. For instance, the service taxonomy of the
FiatFlux-P application defines abstract categories for DataInput , DataOut-
put , the actual FiatFlux services and additional Helpers ,someofthesewith
further sub-categories. Similarly, in the microarray data analysis scenario the
domain model defines service categories for the different domain-specific Mi-
croarrayDataAnalysis services, as well as for common functionality such as
DataHandling and FileWriting , and further, more specific sub-classes of these.
In both applications, also the defined data types are semantically classified
accordingly.
Simple Service Interface Descriptions
The provisioning of adequate services in a domain model is already relevant
iftheservicesaretobecomposedbyahumanuser.Asdetailedabove,inpar-
ticular services of adequate granularity are needed as foundation for a good
domain model. In order to make effective use of a service, already a human
user has furthermore to know as exactly as possible what the services does.
Naturally, proper service provisioning also involves the inclusion of adequate
service documentation, so that the user can easily find all relevant informa-
tion about the service. Automatic workflow composition methods like the
synthesis algorithm of the loose programming framework require even more
precise semantic service descriptions, that is, such that are formally defined
and programmatically accessible. Technically, the required functionality for
this task is readily provided by the framework, but the actual challenge for
the domain modeler is to define adequate service interface descriptions.
As a general paradigm, service interfaces should always be as simple as
possible . More precisely, services should be “atomic” in the sense of providing