E-lico planner/DM assistant

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

2. 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

3. Scenario 2 • 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 Rapid-Miner E-lico planner/DM assistant Taverna WF myExperiment Taverna provenance 3. Taverna and myExperiment act as a WF and provenance repository

4. 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

5. Scenario 3 • 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 Taverna E-lico planner/DM assistant RapidMiner WF myExperiment E-lico repository Taverna provenance DB E-lico provenance 5. E-lico/RapidMiner manage workflow repository and provenance databse 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

6. 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)

7. 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 DMO 4. Relevant data from Taverna and myExperiment can be sent to the e-lico platform via some API 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

8. 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)