| Line 106 was replaced by lines 106-115 |
| - A very simple keyword-based search implementation within Kepler. |
| + *** A very simple keyword-based search we (Chad and I) implemented within Kepler. |
| + **** Integrated with the component 'quick search' frame |
| + **** Allows dynamic actor classification (for browsing) |
| + **** Allows runtime annotation and re-classification of actors |
| + **** Term expansion for individual concept queries |
| + *** Required a number of new features in Kepler: |
| + ***# ID mechanism for actors |
| + ***# 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. |
| Removed lines 108-110 |
| - Fakes out: workflow component LSIDs, an actor repository (as a |
| - ptolemy xml config file), annotation repository (xml file), LSID |
| - service. |
| Removed line 112 |
| - The "ontology" is a simple hierarchy. No rels, etc. |
| At line 113 added 1 line. |
| + __What's needed for KEPLER__ |
| At line 114 added 3 lines. |
| + * Ontologies and Ontology Tools |
| + ** There basically aren't any. |
| + ** There also aren't any tools in Kepler for creating, browsing, or editing ontologies. |
| Line 116 was replaced by lines 125-129 |
| - * What's Needed for KEPLER |
| + * Annotations |
| + ** 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. |
| Removed line 118 |
| - ** Ontologies |
| Line 120 was replaced by lines 132-135 |
| - There basically aren't any. |
| + * Basic Kepler GUI Hooks |
| + ** Like for toolbar, menus, etc. |
| + ** Checking semantic compatibility (can steal unit resolver?). |
| + ** Explanation of results (like for searching, etc.) |
| Removed lines 122-137 |
| - There also aren't any tools. No tools within Kepler. |
| - |
| - |
| - ** Repositories ... |
| - |
| - The Obj. Mngr. can help! We don't have repositories for |
| - workflows/components, ontologies, annotations, or datasets in |
| - KEPLER. |
| - |
| - For annotations, need a searchable "index" of annotations and ids |
| - (for components, datasets, etc.), and a mechanism to "retrieve" |
| - those items. |
| - |
| - For performance, I wonder though if the "index" should be in |
| - memory. |
| - |
| Lines 139-151 were replaced by lines 138-152 |
| - ** Semantic Annotation Editor |
| - |
| - This doesn't exist either ... lots of ways/approaches here. |
| - |
| - Need GUI design for this. |
| - |
| - Also, need a good way to access/browse a component/dataset and its |
| - attributes, such as is ports and their input/output types. |
| - |
| - Similar with datasets |
| - |
| - The challenges are making this tool easy to use, and accessible |
| - within Kepler. |
| + * Algorithms |
| + ** Need to understand the integration/merging algorithms |
| + ** Could today write the other types of search algorithms |
| + |
| + * Repositories |
| + ** Basically none of the repositories exist (except perhaps for Data, not sure) |
| + ** I think the Kepler Obj. Manager can help with this, what we need from it is: |
| + *** Ability to register components, data sets, ontologies, and annotations with the obj. manager |
| + *** Ability to access all LSIDs of a certain type, e.g., components, data sets, ontologies, annotations |
| + *** Ability to retrieve the object for an LSID |
| + *** Some form of ''annotation indexing'' (this is similar to metadata indexing perhaps) |
| + **** A search can be executed directly against an in-memory annotation file (e.g., obtained dynamically from all registered objects) |
| + **** In contrast to asking the obj mngr for all lsids that are annotations, and for each retrieving the annotation file, etc. |
| + *** For efficiency, probably want multiple access paths via lsids, e.g., get all the workflow components and for each, retrieve it's annotation (if there are a lot more annotations than just for components); or build an annotation index based on these lsids, etc. |
| + **** 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.) |
| Removed line 154 |
| - ** Basic Kepler Interfaces / GUI Design |
| Removed lines 156-157 |
| - Like for searching, checking semantic compatibility (can steal |
| - unit resolver), explanation of semantics (like for searching, etc.) |
