E-lico planner/DM

assistant

E-lico planner/DM

assistant

DMODMO

Taverna WFTaverna WF

Rapid-Miner WFRapid-Miner WF

2. WFs converted to run in other applications

myExperimentmyExperimentE-lico provenance

repositoryE-lico provenance

repository

WF execution TavernaTaverna

Rapid-MinerRapid-Miner

Taverna provenance DB

Taverna provenance DB

1. Stand alone E-lico planner (who develops? Not UNIMAN)Medicel WF??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 dataIs 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

E-lico planner/DM

assistant

DMODMO

Taverna WFTaverna WFmyExperimentmyExperiment

Rapid-MinerRapid-Miner

Taverna provenanceTaverna provenance

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

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

E-lico planner/DM

assistant

DMODMO

RapidMiner WFRapidMiner WFmyExperimentmyExperiment

TavernaTaverna

Taverna provenance DB

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 repositoryE-lico repository

E-lico provenanceE-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

E-lico planner/DM

assistant

DMODMO

myExperimentmyExperiment

RapidMinerRapidMiner

Taverna provenance DB

Taverna provenance DB

2. E-lico planner and DM assistant service. This application can plan workflows andoffers services that help in the construction andediting 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 repositoryE-lico repository

E-lico provenance DBE-lico provenance DB

Medicel?Medicel? Other WF systems…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)