| At line 46 added 1 line. |
| + Whether or not two actors or data sets are semantically compatible is an important property that we want to expose to users. For any given workflow, we want them to be able to check the semantic correctness of the workflow (semantic type checking). This allows them to see the parts of the workflow that might satisfy structural constraints (output and input both are array of floating point numbers) but that are semantically meaningless (e.g., the output is an array of rainfall values in Oregon, and the model takes as input an array of carbon soil concentrations). |
| At line 47 added 4 lines. |
| + A related aspect is being able to construct a transformation path to get between two compatible actors if they can't be linked. The semantic type checker might be able to determine that two actors are incompatible for direct linking but might be compatibel with some series of transformations that might be applied to the data stream. For a trivial example, if a data set contains species counts for individual species over a particular area and an actor requires as input the number of species present in an area, a simple transformation can be applied (filter where count > 0) to allow the data to be used. Thus, the data can be used after a simple transformation. Of course, realistic transformations would probably require multiple steps, so the challenge here is to generate the appropiate composite workflow that takes the semantic type of the original data set as input and outputs the sematic type of the original actor. |
| + |
| + An equivalent process can be applied when aggregating/integrating data such that multiple semantic and structural types incoming can result in one outgoing structural and semantic type. |
| + |
| At line 48 added 1 line. |
| + Again, this is an open question, but a few thoughts have been proposed. |
| Line 50 was replaced by line 56 |
| - !! Ontology issues |
| + For semantic type checking, it has been proposed that a buttonbe placed on the Kepler UI that can invoke the type checking algorithm, which would then color code components based on their compatibility. For example, in a workflow A - B - C - D, the link from B to C might be semantically invalid and it could be highlighted. If the operation is not computatinally complex (ie, time consuming), the type check operation could be run in the background and the results highlighted on the canvas dynamically as changes are made to the workflow (akin to the red squiggly line in word processors indicating a spelling error). This would eliminate the need for a separate button and give the user immediate feedback about their workflow composition. |
| At line 51 added 2 lines. |
| + For the transformations, we have discussed putting two actors on screen that are semantically compatible through a transformation and selecting a context menu item 'Generate transformation step'. This algorithm would generate a composite actor with the appropriate semantic types and create the workflow needed to handle the semantic transformation. In doing this, the semantic mediation system would need to know the correspondence between various types of semantic incompatibilities and how particular actors can be used in resolving those incompatibilities. For simple cases this seems tractable (e.g., convert density to occurence), but for more complex cases its an open question as to whether it is tractable -- this would essentially be an automated program generator. |
| + |
| Line 55 was replaced by lines 63-65 |
| - Different levels of abstraction...drill down... |
| + Semantic workflow design takes the semantic type checking and transformation discussion to a greater level of sophistication. Here we envision a system where a user can create workflows as an 'abstract model' which is then specified at successively more concrete levels. For example, a user might want a simple workflow that takes 'SpeciesDistribution' data, connects it to a 'SpeciesDistributionPredictionModel', which creates a 'PredictedSpeciesDistributionMap'. This high-level, abstract workflow is not in itself executable, but it constrains the world of possibilites. The user must then drill down to provide more concrete (although still possibly not executable) specifications for each of the abstract components. At some level of concreteness the semantic mediation system should be able to recognize specific executable actors that could be used to realize the abstract model. These could be suggested to the workflow designer or automatically inserted in cases where the use is unambiguously correct. |
| + |
| + The same underlying capabilities that are used in the data transformation and integration would be used to deduce the compatibility between abstract components and to suggest concrete realizations of the abstract components. |
| At line 56 added 2 lines. |
| + This model of a semantically-driven, abstract modeling approach is closely aligned to Villa's Integrated Modeling system, and we should carefully examine that system for compatibilities and synergies. |
| + |
| At line 57 added 3 lines. |
| + The GUI in Kepler is already quite amenable to this approach in that it supports hierarchy in the models now. Right now composite actors are a form of abstraction that could be the basis for abstract models. The GUI changes needed would involve being able to drag abstract components from the ontology onto the workflow and visually indicate that these portions of the workflow are abstract and need to be further specified. All of the semantic type checking and tranformation tools described above could be utilized. The semantic type checker should be able to determine if the model has been specified to a sufficiently concrete level to be executed, and that would in turn trigger a visual indication on the canvas or in the GUI that the model was ready to be executed. For example, the director icon (if such a thing were present) might change shape or color, or the 'Run' button in the toolbar might switch from deactivated to actived with corresponding visual changes. |
| + |
| + The challenge here is largely in constraining the abstract components to terms from the ontology that would represent 'useful' components and managing the multiple levels of abstract hierarchy that might be present. |
| At line 59 added 5 lines. |
| + Please add any comments to the draft that you think would improve the exposition and we will incorporate the ideas into the design. |
| + |
| + !! Name |
| + Your comment goes here. |
| + |
