| Line 5 was replaced by line 5 |
| - The main goals of the file-management subsystem are listed below. In particular, the subsystem should provide the infrastructure for enabling scientists to: |
| + The main goals of the file-management subsystem are listed below. We use the term "Kepler item" loosely below to refer to actors, workflows, and data sets, and "annotations" to refer to metadata (like EML) and semantic descriptions. The subsystem should provide the infrastructure for enabling scientists to: |
| Lines 7-12 were replaced by lines 7-13 |
| - * Search for all known items of interest, including actors, workflows, and data sets. |
| - * Easily organize actors, workflows, and data sets of interest using the file-directory metaphor (called "actor libraries" in Ptolemy). For example, by allowing a scientist to create and persist a personal library, and to browse and search that library. Allow items to be organized into multiple local actor libraries, and in multiple locations within a library. |
| - * Persist actors, workflows, and data sets in a network-accesible repository (i.e., in the EcoGrid). |
| - * Retrieve new actors, workflows, and data sets from a network-accessible repository (from the EcoGrid) and update changes to existing items. |
| - * Track both revisions of actors, workflows, and data sets as well as new versions (off-shoots or branches) of an item. |
| - * Store semantic annotations of actors, workflows, and data sets and publish those annotations to a network repository (the EcoGrid). Retrieve annotations from the network repository. |
| + * Search for all known Kepler items of interest. |
| + * Organize Kepler items of interest using a file-directory metaphor (currently called "actor libraries" in Ptolemy). For example, a scientist should be able to create and persist a personal library, and to browse and search that library. |
| + * Allow Kepler items to be organized into multiple libraries, and in multiple places within a library. |
| + * Persist Kepler items in a network-accesible repository (i.e., in the EcoGrid). |
| + * Retrieve new Kepler items from a network-accessible repository (the EcoGrid) and update changes to local items. |
| + * Track both revisions of Kepler items as well as new versions (off-shoots or branches) of an item. |
| + * Provide similar functionality for annotations, i.e., store annotations of actors, workflows, and data sets and publish those annotations to a network repository (the EcoGrid), and retrieve new annotations from the network repository. |
| Line 14 was replaced by line 15 |
| - The figure below outlines the architectural components of the subsystem. The subsystem assumes the use of [Life-Sciences Identifiers|http://www.i3c.org/wgr/ta/resources/lsid/docs/index.asp] (LSIDs) as logical identifiers for actors, workflows, data sets, and annotations (and possibly for local "libraries"?). Thus, particular files (representing actors, workflows, data sets, or annotations) are assigned LSIDs and are accessed via LSIDs. |
| + The figure below outlines the architectural components of the subsystem. We treat annotations and Kepler items uniformly below. That is, the management subsystem does not have separate storage components for managing annotations and items. The subsystem assumes the use of [Life-Sciences Identifiers|http://www.i3c.org/wgr/ta/resources/lsid/docs/index.asp] (LSIDs) as logical identifiers for items and annotations. (QUESTION: and also for local "libraries" -- do these need to be stored in the EcoGrid, e.g.?). Thus, relevant files are assigned LSIDs and are accessed via LSIDs. We assume that an LSID will store the type of file (e.g., the type of annotation, or the type of Kepler item) associated with the ID. |
| Line 20 was replaced by line 21 |
| - The main components provide operations over a local data store of files. The remote manager provides the operations required to interact with the EcoGrid. It also may provide a local cache for performance. The LSID manager is used to assign unique identifiers for items, e.g., serving as logical identifiers for actors, workflows, data sets, and semantic annotations. The logical/physical index manager provides operations to related physical files to LSIDs, and to access files based on LSIDs. The directory/view manager provides operations for local organizations of items into libraries. |
| + The remote manager component provides the operations required to interact with the EcoGrid. It also may provide a local cache for better performance. The LSID manager creates and assigns unique identifiers for items and annotations. The logical/physical index manager provides operations to relate physical files to LSIDs, and to access physical files based on LSIDs. The directory/view manager provides operations to support the creation and retrieval of local, customized libraries. |
| Line 22 was replaced by line 23 |
| - The following are a set of possible supported operations (note that these are half-baked, if that): |
| + The following are operations (these are very half-baked!) may be provided by the Kepler file-management subsystem: |
| Line 24 was replaced by line 25 |
| - * {{Retrieve(ID)}}. Given an id, the subsystem returns the files associated with the item. |
| + * {{Retrieve(ID)}}. Given an LSID, returns the relevant files associated with the item. |
| At line 33 added 3 lines. |
| + Another feature that we may consider is support for change management. In particular, when a file within the subsystem is changed, a notification can be cached/stored of the change, for use by components within Kepler. (Isn't there already a change api in Kepler; and can we piggy-back on this?) |
| + |
| + |
