| Removed line 38 |
| - When composing workflows scientists can create new composite actors that wrap up other actors into a functional unit that performs a typical task. They can also create new atomic actors that are introduced into Kepler using the [KSW file format|http://kepler-project.org/Wiki.jsp?page=KSWEncapsulationSpecification] that is being designed. We want scientists to be able to label these new actors with the proper terms from the topical and signature ontologies so that they can be saved and then discovered later using the semantic techniques outlined above. When annotating these new actors, the scientist may have a need for new terms in the ontology to properly classify their new actor. These could be topical terms or new semantic data types that are not yet represented. In addition, the ontology may not capture any particular scientists views and knowledge of the domain area accurately, so they may wish to reorganize the ontology to better reflect their semantic worldview. In both of these cases the Kepler GUI needs to accomodate modification of the ontologies. |
| Line 40 was replaced by line 39 |
| - Data that are created by executing a workflow will be saved locally and possibly remotely and will need to be semantically labeled as well to maximize its utility. We hope that part of the semantic annotation may be propagated through the workflow automatically, but in the absence of this advanced feature the scientist would need to be able to annotate the derived data with its appropriate semantic type. This operation is closely related to annotating the ports of a new actor. |
| + When composing workflows scientists can create new composite actors that "wrap up" other actors into a functional unit that performs a typical task. They can also create new atomic actors that are introduced into Kepler using the [KSW file format|http://kepler-project.org/Wiki.jsp?page=KSWEncapsulationSpecification], which is currently being designed. We want scientists to be able to label these new actors using topical and signature annotations so that they can be saved and then discovered later using the semantic techniques outlined above. When annotating these new actors, the scientist may have a need for new terms in the ontology to properly classify their new actor. These could be topical terms or new semantic data types that are not yet represented. In addition, the ontology may not capture any particular scientists assumptions and knowledge of the domain area accurately, so they may wish to add to or reorganize the ontology to better reflect their semantic worldview. In both of these cases, the Kepler GUI needs to accomodate modification of the ontologies. In addition, basic capabilities are needed for scientists to browse and search the ontologies themselves, e.g., to determine whether appropriate terms exist for annotation. |
| At line 41 added 2 lines. |
| + Data that are created by executing a workflow will be saved locally and possibly remotely and will need to be semantically labeled as well to maximize its utility. Under certain conditions, signature annotations can be propagated through the workflow automatically (see Bowers and Ludaescher, 2005), but in the absence of this advanced feature, the scientist may also desire to annotate the derived data with its appropriate semantic type. This operation is closely related to annotating the ports of a new actor. |
| + |
| Line 43 was replaced by lines 44-45 |
| - How exactly this would work is an open topic. In the current Kepler GUI the topical ontology is represented as a tree control on the left side of the window. Each category shows up in the tree in all of its parent categories, and actors that have been annotated show up i the tree node for each ontology temr that applies. Thus, actors may show up in one, two, or more parts of the tree. To annotate a new actor, we envision being able to drag a composite actor from the canvas and drop it onto the ontology category in the tree. It could then be dragged again to add it to another category as well. This operation adds the new actor to the subsumption hierarchy at the appropriate place(s). If the ontology ends up representing more than just subsumption, we will need an GUI ability to create these additional relationships. One of our concerns is that the folder view that currently is shown in the tree conveys a much more informal representation of the ontology than is appropriate. So, we have considered changing the icons from folders to another 'container' icon that might reduce some implications of a folder. Strictly speaking, one physical item can not be in more than one folder at a time, so the folder metaphor isn't really appropriate for our case. The tree itself isn't really accurate as the ontology is a graph, so we could and should consider whether we want to use a more appropriate representation of the ontology in the left pane. Of course, switching to a graph representation could be very confusing and so any benefits in accuracy of the visualization would need to be weighed against the cost of using a less familiar and more complicated representation. |
| + |
| + The best approach for presenting ontologies to Kepler users remains an open topic. In the current Kepler GUI, the topical ontology is represented as a tree control on the left side of the window. Each category shows up in the tree in all of its parent categories, and actors that have been annotated show up in the tree node for each (most specific) ontology term that applies. Thus, actors may show up in one, two, or more parts of the tree. To annotate a new actor, one can currently interact with the tree control to insert an actor under the desired term. The current implementation uses a highly simplified ontology (i.e., a single hierarchy with no part-of relationships.) If the ontology becomes more complex, we may need extensions to display and represent, e.g., these additional relationships or multiple hierarchies. |
| Line 45 was replaced by line 47 |
| - An alternative approach might be to right click on an actor and be shown a dilaog for classifying the actor. This dialog would both show the ontology and show the actor and its ports and allow the components of the actor to be annotated with the terms from the ontology. |
| + Another addition we have implemented is the ability to add new concepts dynamically to the tree control. One of our concerns is that the folder view currently shown in the tree conveys a much more informal representation of an ontology than is appropriate. An ontology structure significantly differs from a folder structure. For example, in a folder structure, a physical item can not be in more than one folder at a time, whereas an object can be classified by multiple concepts. Another major difference is that folders do not transitively associate their elements, whereas in an ontology, concept subsumption is transitive. In other words, a file in a folder is not a file in a parent folder. However, an object that is an instance of a concept B is also considered an instance of all concepts A that subsume B. Additionally, an ontology with part-of relationships, i.e., a graph, is cumbersome to represent using a tree structure. |
| Line 47 was replaced by line 49 |
| - Another alternative proposed by B. Ludaescher is to allow the user to enter Sparrow expressions in a text box for describing actor annotations. This is simpler to implement but has significant usability questions, partly because it assumes that the user has detailed knowledge of the terms and relationships between terms inthe ontology. |
| + The following lists some possible ways to handle these discrepencies and provide better support for annotation and ontology GUIs in Kepler: |
| Line 49 was replaced by lines 51-55 |
| - In many ways, annotating the semantic tpye of the ports (the actor's I/O signature) involves a different set of operations in the GUI than annotating what the actor is 'about' in terms of its function and algorithm. |
| + * Replace the current tree widge with a graph widget. Switching to a graph representation, however, could be very confusing and so any benefits in accuracy of the visualization would need to be weighed against the cost of using a less familiar and more complicated representation. |
| + * Change the icons from folders to another 'container' icon. The goal of switching icons is to signal a different user model than folders. |
| + * Permit right-click actions on an actor that display an annotation dilaog. This dialog would both show the ontology and show the actor and its ports and allow the components of the actor to be annotated with the terms from the ontology. |
| + * Allow the user to enter text-based (e.g., Sparrow) expressions in a text box for providing actor annotations. This is simpler to implement but has significant usability questions, partly because it assumes that the user has detailed knowledge of the terms and relationships between terms inthe ontology. |
| + * Providing signature annotations may involve a different set of operations in the GUI than providing topical annotations. Thus, separating these tasks may be required. |
| At line 53 added 1 line. |
| + |
