GNU R is a widely used programming language and software environment for statistical data analysis and visualization. Bioconductor [1] is a collection of bioinformatics packages that extends R's standard range of functionality by comprehensive libraries of functions and meta-data predominantly for the analysis of data from high-throughput genomics and molecular biology experiments, and additionally provides several example data sets that are useful for testing, benchmarking and demonstration purposes. Reference manuals and additional manuscripts provided with the packages at the Bioconductor web site describe a variety of data analysis procedures based on the available functionality. The described bioinformatics procedures or work ows are typically referred to as data analysis pipelines, as they typically have a simple, in fact mostly linear, structure. (This is largely due to the fact that the often considerable complexity of the individual analysis steps is encapsulated by a services with a simple interface, and hence hidden from the user at the provided level of abstraction.) Thus, automatic work ow composition functionality like the method described in [6], which is based on a linear-time logic synthesis algorithm, can be easily applied here to generate the complete analysis pipelines automatically. Making use of the constraint-driven work ow composition functionality of the PROPHETS framework [5], which is based on such a linear-time logic synthesis algorithm, we created a prototype of a corresponding synthesis framework [3]. Focusing on DNA microarray analysis, this prototype comprises around 30 services and provides a framework for user-level construction of analysis pipelines based on appropriately wrapped and integrated Bioconductor functionality. It helps handling the variability that is inherent in microarray data analysis at an useraccessible level and emphasizes the agility of a model-driven and service-oriented approach to work ow design. PROPHETS is the current reference implementation of the loose programming paradigm [4], aiming to simplify work ow development in order to reach application experts without programming background. Working with PROPHETS consists of two major phases: 1. Domain Modeling, where PROPHETS is prepared for the application domain by describing services and their interfaces formally, de ning service and type taxonomies (simple ontologies with is-a) relations only) and specifying domain-speci c constraints, and
2. Work ow Design, where the actual work ow synthesis takes place in the fashion of an iterative \playing" with the speci cation, synthesis, and constraint and parameter re nement, until a satisfying solution is found.
Hence, for making new application domains accessible to work ow designers, adequate domain modeling is crucial. For the prototype application we set up the domain model manually. On the component level (i.e. when dealing with the individual services), we could largely reuse available information from the packages' documentation les. Fortunately, consistent terminology is used there for referring to data types and functions, although there is no formal ontology or taxonomy model behind that would explicitly de ne a controlled vocabulary. On the ontological level (i.e. when de ning the service and type taxonomies of the domain model), however, the process was not so straightforward. The package descriptions did not contain any explicit relation annotations, except from the hierarchical information that can be derived from the package structure itself. Hence, we had to de ne abstract semantic categories for the hierarchical grouping of services and types ourselves.
In contrast to other case studies described in [