The concept of ECHO has been many years in the making. The initial charter and Plan development began in June of 1998 and was called the Independent Information Management System (IIMS). The goal was to provide a tool that would allow access and search of Earth Science Metadata that would be independent of the ECS and make use of technology tools. The charter, goals, and requirements have changed since 1998 based on Earth science data community input as well as changes in the how earth science data is currently handled. Even the name has changed from IIMS to ECHO to reflect more of what the concept of the system is-a clearinghouse of Earth science Metadata under the EOS Program.
During the initial planning stages of the ECHO sysem, high-level system goals, based on original requirements of the EOSDIS Core System (ECS) drove the activity. The Independent IIMS Study Team (IIST) analyzed and refined these goals. Use Cases were developed to document the design decisions. These design decisions also communicated the goals of the system to the development team and to stakeholders (potential partners).
These goals are listed below.
- Provide well documented interfaces and protocols for others to build and plug-in user interface tools and services, alternate clients, and machine to machine interfaces to support integrated search, assessment, order, retrieval and processing without human intervention.
- Provide information management (storage and maintenance) required to support inventory and service metadata(including descriptions) and software to support the middleware.
- Provide access to fundamental inventory - the data and service servers.
- Provide archival product requests (including one-time orders, standing orders and subscriptions).
- Provide ability to place orders from non-ECHO systems.
- Provide cost estimation and account status requests, and user feedback for guest and registered users.
- Provide data request routing and tracking.
- Provide statistics collection software is built in to track usage and usability of features.
- Provide a UI that allows providers to define their data products and services in terms that relate (through possible terminology mapping) to the EOSDIS standards. Then, automatically generate a gateway or mapping layer to EOSDIS, submit their metadata (attributes and valids) mappings to the EOSDIS Metadata Configuration Manager for review, and plugs into a test IIMS system for testing search and access of the provider data and services.
- Provide capability to export information to external search services.
- Provide system access & secure on-line user registration.
- Enable graphical, keyword and freetext search (of data, documents, services and software tools).
- Enable integrated & FTP data and metadata visualization (browse images and spatial and temporal coverage maps).
- Enable content-based metadata searching.
- Enable research planning.
- Enable data acquisition planning (for any instrument described in the system), requests (DAR) and subscriptions (for supporting instruments.)
- Enable on-demand processing requests (including ODPs associated with DARs).
- Provide framework for access to data and services such as data subsetting, data subsampling, data averaging.
Deploy in 3-6-month increments for regular feedback with the community Incrementally build on previous versions with no loss of functionality unless a function is obsolete (as determined by user interest/usage) or we determine something is better done via an externally provided plug-in. Infuse as much prototype functionality as feasible in any increment.
Ease of Learning, Efficiency, Memorability, Errors, and Satisfaction.