Kepler Tagging
Proposed approach for unifying and extending the Kepler (semantic) tagging interfaces
Status
Currently, the following works:
- Tagging workflows with concepts contained in any of the immutable ontologies Kepler knows about, or new concepts created in a default user ontology
- Using the Tag Manager to add new ontologies, either standalone or importing a parent ontology, to alter the visibility of the ontological concepts in the tag input bar and/or the library search pane, and to alter the color representing the ontologies in the tag input bar
- Automatically populating the tag display area with any tags on a workflow
Things I need to do:
- Move the tag display area to a separate toolbar or other GUI component to give it more room
- Allow the importing of existing local or non-local ontologies into Kepler (they would remain immutable)
- Allow the ability to remove ontologies
- Make it possible to tag additional types of Kepler objects
- Make it possible to tag REAP runs
Current UI
The current tagging approach in Kepler allows a user to assign one or more "semantic types" (classes drawn from OWL ontologies) to actors and actor ports. The user interface for tagging is opened by right-clicking on an actor. When opened, the semantic annotation editor provides separate tabs for selecting the object to annotate (either an actor/component, the input ports, or the output ports). Semantic types (i.e., OWL classes) are assigned (i.e., used as annotations, or "tags") by selecting one or more classes and adding them to the list of semantic types for the object. Here we propose a simpler and more uniform user interface for tagging a wider range of components, including actors, ports, workflows, workflow runs, and reports.
New interface implementation
Here are some screenshots of the current implementation of the tagging interface. The first screenshot is how a new canvas appears. The second screenshot is how the interface appears with the combo box open. The third is what one sees when a tag is selected and the menu re-opened.
Note: There is a slight bug apparent in the third screenshot, as the "Create new tag Blast..." entry should not be in the menu. I'll re-upload the third screenshot once I fix that.
Feature walkthrough
After I've tested the code more fully, I will put instructions in trying out the new tag interface here.
New interface design
The figure below describes the proposed UI design.
Items are tagged using the proposed tagging text box on the toolbar. The tagging toolbar allows multiple class names to be entered and performs in-place search of class names as a user types. If no class name is found, the user can choose to create it as a class. The class is entered into the user's "default" ontology. Selected class names in the toolbar serve to tag the selected item (i.e., the selected actor, port, run, workflow, or report).
In addition, the toolbar provides access to the tag manager. The tag manager allows users to create and register ontologies (from which classes used in tagging are selected from), create new classes, and organize class hierarchies within ontologies.
The tag manager provides the following ontology-related operations:
- New. This creates a new ontology (OWL) file (possibly extending an existing registered ontolgy) and registers this file with the tag manager. The ontology file is stored in the user's .kepler directory (until published). The user provides a name for the ontology.
- Register. This registers an existing ontology (that can be accessed via a physical URL) with the tag manager. The user provides a physical URL to the ontology. If the ontology does not have a name (i.e., an rdfs:label property), the user is prompted for a name to use for the ontology.
- Unregister. This unregisters the selected ontology. The user is warned if the ontology being unregistered has been modified (i.e., is a new, unpublished ontology). Tags that use classes from the unregistered ontology will still be available, however, the system will not be able to leverage class hierarchies or other information about the ontology. Note that the default user ontology cannot be unregistered. Also, unregistering an ontology does not delete it.
- Publish. This saves the current version of the ontology in a user-specified location (physical URL) and assigns the ontology an optional user-specified URI. If no user-specified URI is given, then the physical URL is used. This also registers this version of the ontology with the tag manager. If the default user ontology is published, the user is also prompted for a name to assign the published ontology. A new (empty) default ontology is also created.
Each registered ontology can be further configured by specifying whether it should be displayed in the actor library, whether its classes should appear in the tagging toolbar, and the color that should be used for displaying tags. When a user publishes a new ontology, the published version of the file is used in place of the local version (i.e., the one stored in the .kepler directory) which may also be removed from the .kepler directory.
Infrastructure support
In addition to changing the tagging user interface above, we also intend to update the underlying infrastructure to make it easier to create and register ontologies with the Kepler system, and also to modify ontologies for tagging.
These new features will require updating the current semantic type / ontology infrastructure in Kepler.
Proposed APIs
Basic utility operations
org.kepler.tagging.Tagging
- ...
- ...
- ...
- ...
- ...
- ...
- ...
- ...