Tagging usage scenarios

Workflow-Tagging Scenarios

Scenario 1:  Assigning tags to workflows stored explicitly on the file system.

1. [WORKED] Create a new workflow starting from a blank canvas. Note that the tag bar is empty.
2. [WORKED] Type a tag name into the tag entry box and hit return.  Notice that the new tag name appears in the tags bar. 
3. [WORKED] Open the tag manager from the tag bar.  Expand the 'default' ontology and notice that the newly entered tag is in the list of tags in that ontology.
4. [WORKED] Save the workflow to disk and close Kepler.
5. [WORKED] Create a new workflow with a blank canvas.  Open the tag manager and note that new tag is present.
6. [WORKED] Load the previous workflow from disk, and note that the tag is still present in the tags bar.
7. [WORKED] Create a new workflow and tag it with the same tag as the former workflow.  Then assign a new tag to that workflow, and save the workflow to disk.
8. [WORKED] Quit Kepler, restart, and open the tag manager.  Note that the two tags referred to about are present in the default ontology, and that there is no duplicate of the first tag.
9. [BUG] Delete the first tag from the ontology.
10. [?] Load the two workflows created above from disk and note the first still has the first tag assigned but that it is greyed out, and that the second has the second tag (normally colored) and a greyed-instance of the first tag.
11. [?] Assign a third tag to both workflows.  Open the ontology manager and note that the second and third tag are present in the ontology.  
12. [?] Save the two workflows to disk and restart Kepler.
13. [?] Load the two workflows and delete the greyed out tag from the first workflow's tag bar, and the third tag from the tag bar of both workflows.
14. [?] Save the two workflows to disk and restart Kepler.  Open the ontology manager and note that the second and third tag are present.  Load the two workflows and note that tags that were deleted are no longer present.    

Scenario 2: Searching for workflows stored in the local repository based on assigned tags

1. Create a new workflow and assign a new tag to it.
2. Save the workflow to the local repository and restart Kepler.
3. Type the tag name into the search bar and note the workflow saved above is present in the search results.
4. Open the workflow from the search results.
5. Create a second workflow and assign the same tag.  Save the workflow to disk (not the local repository) and close it.
6. Search for workflows with that tag again, and note that only the workflow saved to the local repository is in the search results.

Other workflow-tagging features to demonstrate with additional scenarios:

• Create new ontology de novo
• Create new ontology extending one or more existing ontologies
• Publish an ontology
• Register and unregister existing ontologies
• Rename tags
• Assign a color to an ontology.
• Assign parent-child relationship to tags
• Assign synonym relationships between tags
• Delete tags from ontologies
• Share an ontology with others
• Rename an ontology
• Activate and deactivate a registered ontology for (a) tag assignment, (b) browsing, and (c) tag-based searching.

Workflow run tagging scenarios

 The following scenarios are a bit more technically detailed than usual, as I'm trying to work out implementation approaches.

• Create a new workflow
• Add two tags, 'a,' and 'b,' to the workflow, and run it in conjunction with the workflow run manager
• The provenance will be recorded, and a workflow run will appear. In the tagging column, tags 'a' and 'b' will be shown. (These tags will be obtained by pulling the tags stored on the workflow out of the workflow MOML saved in the run. The tags are not necessarily duplicated. They can be duplicated to boost performance.)
• Add a tag 'c' to the workflow run. (This tag will be added to the provenance database record for this workflow run.)
• Tags 'a,' 'b,' and 'c' are all visible. (Note: See Concern below) (Displayed tags for a workflow run are a conjunction of tags on the workflow [pulled from workflow MOML] and tags on the workflow run [pulled from provenance DB].)
• Note that while tags 'a,' 'b,' and 'c' are all visible, they are not necessarily displayed identically. The system reserves the right to alter certain aspects of visual presentation (font size, color, weight, &c) as a cue to the user of the type of tag (what is being tagged, whether run or workflow, in this case, and as a side effect, how it is stored, MOML vs. DB).
  
• Export the workflow run to a KAR file. (Internally, the workflow MOML is copied into the KAR file, so tags on the workflow are preserved with no additional operations. Tags stored in the provenance DB record for the workflow run in question are stored in the MOML run metadata file in the KAR file.)
• Close and re-open Kepler.
• Open/Import the exported workflow run KAR created two steps earlier. (Again, tags on the workflow are pulled from the workflow MOML stored inside the KAR file. As can be expected, tags on the workflow run are pulled from the workflow run metadata MOML file. Remember presentation may vary between tags on a workflow and those on a workflow run.)

Concerns: In the tagging interface mockups, there is an indicator to the user of the context they are currently tagging in. For example, if the user clicks on the canvas, the current context is 'workflow,' and if they add a tag at this point, that is the entity that is tagged. In the future, the same will apply to actors, ports, parameters, &c. This suggests to the user, though, that the tags being displayed at that point in time are tags on the workflow. When we introduced the idea of tagging workflow runs, one of the features anticipated was the idea of having workflow runs 'inherit' tags from their workflows. If, when one clicks on a workflow run, the union of tags on the workflow run and the workflow is displayed, this could be quite confusing to the user. One possible resolution would be for the main tagging interface to show the tags of the workflow run alone, establishing a one-to-one relation between the type of tags that are shown and the type of tags that would be created were one to be created at that point. A union of the tags could still be shown, but in the Tags column of the workflow run manager.