E-lico planner/DM assistant DMO Taverna WF Rapid-Miner WF 2. WFs converted to run in other applications myExperiment E-lico provenance repository WF execution Taverna Rapid-Miner Taverna provenance DB 1.Stand alone E-lico planner (who develops? Not UNIMAN) Medicel WF?? 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 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 WF Repository 3. A separate E-lico repository that harvests provenance data about executed WFs.(Not UNIMAN). WF Provenance Scenario 1 5. The DMO along with provenance data Is used to plan new Workflows

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

E-lico planner/DM assistant DMO Taverna WF myExperiment Rapid-Miner Taverna provenance 1.The DM assistant is built into Taverna, the Taverna WF is the plan. Requires the “semantification” of Taverna planned for mid Converters so Taverna WF can run in RM and vice versa Scenario 2 Taverna 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

E-lico planner/DM assistant DMO RapidMiner WF myExperiment Taverna Taverna provenance DB 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 Scenario 3 RapidMiner 5. E-lico/RapidMiner manage workflow repository and provenance databse E-lico repository E-lico provenance 3. myExperiment and Taverna provenance DB can still be utilised, but with minimal impact 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 e- lico/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)

Taverna (Next Generation) Taverna (Next Generation) E-lico planner/DM assistant DMO myExperiment RapidMiner Taverna provenance DB 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 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 Scenario 4 4. Relevant data from Taverna and myExperiment can be sent to the e-lico platform via some API E-lico repository E-lico provenance DB Medicel? Other WF systems…

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 e- lico 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)