Robert - We still think we have scenario 4, but the details of where things take place need to be specified.
Alan - Not exactly
Robert - we still need a coupling between taverna and IDA. Mainly for provenance.
Alan - before we were focused on the semantics of the services, but in Juks model we are working with nested workflows, so now its the semantics of the whole nested workflow rather than its individual components
Simon - Juk sees the IDA just returning a single operator/function call to taverna that executes RM workflow that was planned by the IDA. Taverna doesn't need to know anything about how these operators are called or how the workflows are run, this happens on RM server. Taverna is simply used to gather data and interacts with the IDA to get RM workflows to execute.
Shoiab - This has less impact on taverna, can we justify the resources we have?
Robert - Yes, we still have lots of bioinformatic to do with our Kidney use case, all of which would benefit form the semantification of taverna. Plus there is the text-mining services that now all into the data gathering part rather than the data mining. We also have to out what provenance taverna will store, will it get provenance from the RM server?
Shoiab - my understanding, they do the planning taverna just gets a function call. That can be used in workflows. Someone in taverna does data gathering, go off to the IDA get the rapid miner workflows that implement that. Taverna fills in a dummy operator box that gets populated by the IDA
All - We think we have interpreted Juks scenario correctly...
Alan - This scenario restricts everything to services that are in rapidminer, looses the flexibility of taverna. No need for a converter from us, which impacts the demo planned.
Next week we want to talk about requirements fro provenance. Need a weekly infra skye call while the scenarios are being bashed out.