| Line 4 was replaced by line 4 |
| - |
| + |
| Line 17 was replaced by line 17 |
| - Our proposed Kepler semantics demonstration paper submitted to SSDBM 2005 also describes some of this material: see [Incorporating Semantics in Scientific Workflow Authoring|http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/kepler/docs/pubs/kepler-SSDBM2005.pdf?rev=1.1&content-type=application/pdf]. |
| + Our proposed Kepler semantics demonstration paper submitted to SSDBM 2005 also describes some of this material: see [Incorporating Semantics in Scientific Workflow Authoring|http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/kepler-docs/pubs/kepler-SSDBM2005.pdf?rev=1.1&content-type=application/pdf]. |
| Line 23 was replaced by line 23 |
| - We intend to use ontology-driven search capabilities to improve discovery capabilities for both data and actors that have been annotated with terms from formal ontologies. For both actors and data, there are two levels of annotation that we will make use of. The first level of annotation addresses the general topic of the data or function of the actor. We can call this style of annotation the "topical ontology annotation". The second level of annotation describes the semantic "signature" of the data or actor. (By signature we mean a data-structure definition, e.g., a database schema.) We can call this style of annotation the "signature ontology annotation". In the case of data, signature annotations describe the semantic type of each attribute within the data and (possibly) how the attributes relate to one another. For actors, signature annotations describe the semantic type of each input and output port and (possibly) how the ports relate to one another. The topical annotation is meant to describe generally what something represents or does, while the signature annotation describes how such semantic information is encoding (i.e., realized) by the data or actor. In some cases, the signature annotation may be used to "infer" the topical annotation. |
| + We intend to use ontology-driven search capabilities to improve discovery capabilities for both data and actors that have been annotated with terms from formal ontologies. For both actors and data, there are two levels of annotation that we will make use of. The first level of annotation addresses the general topic of the data or function of the actor. We can call this style of annotation the "topical ontology annotation". The second level of annotation describes the semantic "signature" of the data or actor. (By signature we mean a data-structure definition, e.g., a database schema.) We can call this style of annotation the "signature ontology annotation". In the case of data, signature annotations describe the semantic type of each attribute within the data and (possibly) how the attributes relate to one another. For actors, signature annotations describe the semantic type of each input and output port and (possibly) how the ports relate to one another. The topical annotation is meant to describe generally what something represents or does, while the signature annotation describes how such semantic information is encoded (i.e., realized) by the data or actor. In some cases, the signature annotation may be used to "infer" the topical annotation. |
| Line 63 was replaced by line 63 |
| - 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. |
| + A related case is when two actors (or a data set and an actor) are semantically compatible but structurally incompatible. For this case, we want to help the user construct a transformation path that allows the two actors to be connected structurally (while maintaining the semantic compatibility). An example of a transformation path is a series of transformation (or "shim") actors that sit between the two actors and re-structure the output data stream to be structurally compatible with the input 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. Our goal is to use the signature annotations, existing actors, and simple expressions to help generate these transformation paths. Of course, realistic transformations may require multiple and complex steps. In general, we may only be able to provide a partial transformation path requiring the user to provide additional "shims" to perform the needed conversions. |
| Line 65 was replaced by line 65 |
| - 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. |
| + A similar process can be applied when aggregating/integrating data for "binding" data to a workflow or for merging semantically compatible datasets. |
| At line 67 added 1 line. |
| + |
| Line 70 was replaced by line 71 |
| - 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. |
| + For semantic type checking, it has been proposed that a button be 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 (i.e., 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 or the infamous, somersaulting paper clip). This approach would eliminate the need for a separate button and give the user immediate feedback about their workflow composition. |
| Line 72 was replaced by line 73 |
| - 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. |
| + For the transformations, we have discussed putting two actors on the 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 77 was replaced by lines 78-79 |
| - 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. |
| + |
| + 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. |
| Removed line 84 |
| - 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. |
| At line 85 added 2 lines. |
| + The GUI in Kepler is already amenable to this approach in that it currently supports hierarchical models. 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 then be utilized. The semantic compatibility 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. |
| + |
| Line 90 was replaced by line 93 |
| - |
| + |
