| Line 10 was replaced by line 10 |
| - * The goal is to "tag" (annotate) data and workflows (and their components) using ontology terms |
| + * The goal is to "tag" (annotate) data and workflows (and their components/actors) using ontology terms |
| Line 29 was replaced by line 29 |
| - *** ''Workflows and components'': A workflow, a workflow component, or some portion (parameters, ports, substructures of a port type, etc.). |
| + *** ''Workflows and components'': A workflow, a workflow actor, or some portion (parameters, ports, substructures of a port type, etc.). |
| Line 32 was replaced by line 32 |
| - *** Can be as simple as an LSID, e.g., that identifies an entire component or dataset |
| + *** Can be as simple as an LSID, e.g., that identifies an actor or dataset |
| Line 49 was replaced by line 49 |
| - *** Categorize workflows, components, datasets according to their position in the ontology concept hierarchy. |
| + *** Categorize workflows, actors, datasets according to their position in the ontology concept hierarchy. |
| Lines 51-52 were replaced by lines 51-52 |
| - *# Find "compatible" workflow components |
| - *** Given a workflow component (an actor), find components that can be connected to it (either as input or output) based on semantic annotations. If the annotations are "compatible" according to the ontology(ies), the component is returned. |
| + *# Find "compatible" workflow actors |
| + *** Given a workflow actor, find actors that can be connected to it (either as input or output) based on semantic annotations. If the annotations are "compatible" according to the ontology(ies), the actor is returned. |
| Line 57 was replaced by line 57 |
| - *** Given a workflow of connected components, check that each connection (input/output) is semantically compatible. |
| + *** Given a workflow of connected actors, check that each connection (input/output) is semantically compatible. |
| Lines 59-61 were replaced by lines 59-61 |
| - *# Workflow-component structural integration |
| - *** Given two components that are semantically compatible, determine one or more transformations (either by inserting new components or deriving transformation "code") to make them structurally compatible. |
| - **** In general, component integration is a planning-style search problem (and still research) |
| + *# Workflow actor structural integration |
| + *** Given two actors that are semantically compatible, determine one or more transformations (either by inserting new actors or deriving transformation "code") to make them structurally compatible. |
| + **** In general, actor integration is a planning-style search problem (and still research) |
| Line 74 was replaced by line 74 |
| - *# Workflows and Workflow Components (or metadata, etc.) |
| + *# Workflows and Actors (or metadata, etc.) |
| Lines 91-92 were replaced by lines 91-92 |
| - *** Annotation propogation (reasearch) |
| - *# Component integration reasoning |
| + *** Annotation propogation (research) |
| + *# Actor integration reasoning |
| Line 106 was replaced by line 106 |
| - *** Integrated with the component 'quick search' frame |
| + *** Integrated with the actor 'quick search' frame |
| Lines 112-114 were replaced by lines 112-113 |
| - **# Repositories |
| - **** Fakes out: component repository (as a ptolemy xml config file), annotation repository (xml file), ontology (simple is-a hierarchy, no rels, etc.) |
| - **# Provides a very naive local ID service (like for LSIDs). Hand-coded. |
| + **# Repositories: Fakes out component repository (as a ptolemy xml config file), annotation repository (xml file), ontology repository (simple is-a hierarchy, no rels) |
| + **# Provides a very naive, hand-coded, local ID service (like for LSIDs) |
| Lines 121-122 were replaced by lines 120-121 |
| - ** There basically aren't any. |
| - ** There also aren't any tools in Kepler for creating, browsing, or editing ontologies. |
| + ** Need more example ontologies. |
| + ** There also aren't tools within Kepler for creating, browsing, or editing ontologies (coupling tools within Kepeler? import OWL files?, etc). |
| Lines 125-128 were replaced by lines 124-129 |
| - ** Need to extend the annotation "language" |
| - ** Desperately need an annotation editor/browser |
| - *** Need a reasonable/practical GUI design |
| - *** Need a good way to access/browse a component/dataset and its attributes, such as is ports and their input/output types. |
| + ** Need to formalize/finalize the annotation language |
| + ** Annotation interface for Kepler |
| + ** Also, may want: |
| + *** GUI design |
| + *** A uniform way to access/browse a component/dataset and its attributes, such as ports and their input/output types. |
| + *** Perhaps SCIA can help with specifying annotations? |
| Removed line 130 |
| - |
| Line 135 was replaced by lines 135-136 |
| - |
| + ** Joined development with Ptolemy group for customizable menus, etc. |
| + ** Use a personal ontology. Swap out default ontologies. |
| Lines 138-140 were replaced by lines 139-141 |
| - ** Need to understand the integration/merging algorithms |
| - ** Could today write the other types of search algorithms |
| - |
| + ** Need to understand the integration/merging algorithms better (working on examples/test cases currently ...) |
| + ** Could today write the other types of search algorithms (compatible actors/datasets) |
| + |
| Line 151 was replaced by lines 152-153 |
| - **** What types of indexing exactly needing should be driven by development/testing, but we may consider an obj. mngr. architecture that can easily support "extensible" indexing strategies (e.g., through listeners, etc.) |
| + **** The types of indexing needed should be driven by development/testing |
| + **** We may consider an obj. mngr. architecture that can easily support "extensible" indexing strategies (e.g., through listeners, etc.) |
