This document walks through a number of stereotypical interactions with a future version of Taverna that reflect a suggested integration approach making use of the InformationModel.

Authors/contributors: Chris Greenhalgh, Kevin Glover, Nedim Alpdemir

++ Configuration

1. Administrator adds user to the system (mIR) (Person, Organisation, …)
   • Probably using some bootstrap scripts and/or command line interface and/or web admin interface ++ Getting started
2. User (Person) starts Taverna
3. User performs one-time configuration to associate Taverna with mIR
   1. Specifies SOAP end-point for mIR
   2. Specifies their own Person LSID as provided by the Administrator
4. User (Person) authenticates for this session with the mIR
   • Provides a password or responds to some other challenge from the mIR or other authentication component ++ Browsing
5. User opens the mIR Browser Taverna Component
   • Which shows a default hierarchical view of Programmes that they participate in and Organisations which they are associated with
   • Which also allows for dynamic query-based construction of sub-views
6. User browses their study Programmes
   1. in which they participate (via StudyParticipation^?)
   2. via their own StudyParticipation^?: hasLabBooks (LabBookViews^?), each with its own selectedStudies
   3. recursively, via Programme: contains (Study)
7. User browses the contents of their Programmes
   1. ExperimentInstances^? as a kind of Study, via Programme: contains and LabBookView^?: selectedStudies
   2. any Resource, via Programme: usesResources
8. User creates a query to construct a new dynamic view over the mIR (Progammes, Resources, etc.)
9. User creates a new Programme (a) as a sub-programme (Programme: contains) or (b) as a top-level Programme (requires new StudyParticipation^?)
10. User selects a Programme as their current working context ++ Find workflow
11. User opens the View Client Taverna Component [Soton]
12. User articulates requirements for workflow
    • View Client finds candidate workflows
13. User selects a found workflow
    • dragging it to the Workflow Explorer Component to become the current workflow ++ Edit workflow
14. User edits workflow using Taverna…
15. User finds service using View Client Component and adds to workflow ++ Run workflow
16. User opens the Run Workflow Taverna Component [Kevin]
17. User specifies workflow inputs
    1. by direct entry
    2. by drag and drop from external applications
    3. by drag and drop from previous results panels
    4. by drag and drop from Programme Resources in the mIR Browser view
18. User starts the workflow
    1. If configured, the workflow instance is reflected by the (automatic) creation of a new ExperimentInstance^? in the mIR Browser view
    2. If configured, the workflow script is reflected by the (automatic) creation of a ExperimentDesign^?, linked to the ExperimentInstance^? via inverse of hasInstances and (optionally) linked to the current Programme via usesResources
    3. If configured, the workflow inputs are reflected by the (automatic) creation of LSDocuments linked to the ExperimentInstance^? via (?) hasInput and (optionally) linked to the current Programme via usesResources
    4. If configured, the workflow provenance is stored as part of the ExperimentInstance^?
    5. If configured, the workflow intermediate results are stored as LSDocuments linked to the ExperimentInstance^? via (?) hasIntermediateOutput
    6. If configured, the workflow final results are stored as LSDocuments linked to the ExperimentInstance^? via (?) hasOutput
    7. If configured, the template RDF statements are stored MetadataAnnotations^? (?) of the corresponding outputs
19. User monitors the workflow’s progress using the Workflow Status Taverna Component and/or
20. User receives a notification of the workflow’s completion/failure from the Notification Client Taverna Component [Soton]
21. User (optionally) explicitly adds the ExperimentInstance^? to one of their LabBookView^?(s) in the mIR Browser ++ View results
22. User uses/opens the Workflow Execution Taverna Component [Kevin]
    • Currently created only when the workflow is first run
23. User browses the various named results, and their sub-components in the case of collections
    • The output document is a map of named result parts
    • Each result part is assumed to be written separately to the mIR
    • Are individual elements within a collection-typed part separately stored and available from the mIR?
    • Primitive-valued elements are viewed via the Renderer and Facetiser plug-in frameworks
    • Primitive-valued elements and/or collections may be dumped to disk
    • Primitive-valued elements may be dragged to external applications
    • Primitive-valued elements and/or collections may be dragged to the input(s) of other workflows
    • LSID(s) may be dragged to external applications (e.g. Haystack, Lauchpad)
24. User (optionally) explicitly adds one or more result values as explicit Resources to their Programme via usesResources ++ Annotation
25. User uses a context menu to request an annotation dialog
    • Context menu may be on a data element, collection, item in mIR view, etc.
26. User provides an annotation
    • Stored in mIR as MetadataAnnotation^? ++ Workflow publishing
27. User drags the current workflow to the View Component [Soton]
    • Workflow is (optionally) persistently stored in mIR and an LSID allocated for it
28. User provides any required annotation
    • Workflow is published and available for others to find

-- ChrisGreenhalgh - 30 Apr 2004