Scenario 1

3. WFs can be loaded and executed into RM or Taverna. If user wants to Edit WF then this becomes a new workflow and is uploaded into the repository

1. Stand alone E-lico planner (who develops? Not UNIMAN)

Medicel WF?? Rapid-Miner WF Taverna WF

WF execution

E-lico planner/DM assistant

2. WFs converted to run in other applications

Rapid-Miner

Taverna

DMO
5. The DMO along with provenance data Is used to plan new Workflows

WF Repository

WF Provenance

myExperiment

E-lico provenance repository

3. A separate E-lico repository that harvests provenance data about executed WFs.(Not UNIMAN).

Taverna provenance DB
4. WF repository. WFs can be executed directly from the repository or loaded into WF editor. myExperiment will hold provenance data for WFs run from both Taverna or myExperiment

Scenario 1
Taverna acts as Target code E-lico planner generates WF that gets converted to Taverna WF WF can be stored in myExperiment Provenance stored in Taverna provenance store, harvested by e-lico repos WFs can be edited in Taverna, but will not interact with E-lico planner or ontology, edited workflows will appear as new WFs in myExperiement This scenario has low impact on current UNIMAN development Key task Write the converter Decide what provenance should be kept Potential issues Taverna needs more UI to expose polymorphic services like those from RM

Scenario 2

1. The DM assistant is built into Taverna, the Taverna WF is the plan. Requires the semantification of Taverna planned for mid 2010. 2. Converters so Taverna WF can run in RM and vice versa

DMO Taverna
E-lico planner/DM assistant

Rapid-Miner

Taverna WF myExperiment

Taverna provenance

3. Taverna and myExperiment act as a WF and provenance repository

Scenario 2
Taverna acts as source code The planner is integrated into Taverna, WFs are planned and edited within Taverna Requires Taverna to be integrated with DMO ontology so it can understand what services can be sensibly connected. WF can be stored in myExperiment with minimal impact Provenance stored in myExperiment (need requirements)
Also store information on what changes/edits were made to auto-generated WFs

This scenario has high impact on current UNIMAN development. Planned for Taverna Next Generation (mid 2010) Key task Requirements specification for Taverna Next Generation Potential issues Taverna not currently resourced enough to undertake this task

Scenario 3

1. The DM assistant is built into RapidMiner, the RapidMiner WF is the plan. 2. Converters so RapidMiner WFs can run in Taverna, however, taverna WFs do not need to run in RapidMiner

DMO RapidMiner
E-lico planner/DM assistant

Taverna

RapidMiner WF E-lico repository myExperiment Taverna provenance DB

3. myExperiment and Taverna provenance DB can still be utilised, but with minimal impact

E-lico provenance
5. E-lico/RapidMiner manage workflow repository and provenance databse

4. E-lico can harvest data from myExperiment and Taverna provenance DB

Scenario 3
RapidMiner as source code Essentially the same as Scenario 2, but planner is integrated into RapidMiner (with much less impact on UNIMAN) RapidMiner WFs are converted into Taverna WFs or they can simply just be executed within Taverna There are issues with regards to whether the workflow could be edited in Taverna, and if so how would the editing be controlled and fed back to the elico/RapidMiner system WF can be stored in myExperiment with minimal impact Provenance stored in Taverna prvenance DB (need requirements)
Also store information on what changes/edits were made to auto-generated WFs

Key task Execution of RapidMiner WFs in Taverna Potential issues Taverna UI not suitable for polymorphic services from RapidMiner (this would require some Taverna development to better expose the RM services)

Scenario 4
1. Applications can program against the E-lico service API. In Taverna terms, this would mean a plugin that would either generate whole plans, or provide the correct semantics for connecting services based on the DMO. By default the Taverna system would use the semantics of BioCatalogue to manage WF construction

Taverna (Next Generation)

RapidMiner

Medicel?

Other WF systems

myExperiment Taverna provenance DB

4. Relevant data from Taverna and myExperiment can be sent to the e-lico platform via some API

DMO
E-lico planner/DM assistant
2. E-lico planner and DM assistant service. This application can plan workflows and offers services that help in the construction and editing of workflows. 3. This system connects to its own repository, but provides APIs for other systems to submit workflows, changes to workflows and provenance

E-lico repository

E-lico provenance DB

Scenario 4
E-lico DM planner and assistant as stand alone service Provides API for generating WFs, and services for editing workflows (e.g. Give me all the services I can connect to this one) Third party Workflow systems such as Taverna, RapidMiner etc.. Can program against this API Information about provenance and edited workflows can be passed back to the elico service. Taverna Next Generation will be semantically enabled based on Semantics of services in Biocatalogue. E-lico would essentially provide its own Datamining catalogue with its own semantics based on the DMO. Key task Requirements for Taverna NG semantification and plugin architecture Potential issues Taverna UI not suitable for polymorphic services from RapidMiner (this would require some Taverna development to better expose the RM services)