Living With a Star Scientific Resource Access System

1. Living With a StarScientific Resource Access System Rose Daley Rose.Daley@jhuapl.edu Jacqueline Stock Elisabeth Immer David Silberberg Brand Fortner

2. LWS Resource Access Characteristics • More than just data • Tools and models should also be available • Long-term Life-cycle • Evolving mission • Integration of Diverse Data Sources • Existing (heritage) data • New (currently unknown) data • Scientist Involvement • System purpose is to facilitate science

3. Space Scientist Solar Scientist Geophysical Scientist Interdisciplinary Scientist SRAS SRAS Facilitates Discovery and Access • Enables discovery and access of data, dynamic sources of data (models, programs) • Will only be as good as the resources in it • Will likely require some tool development for new conversion, visualization, and evaluation capabilities • May need access software for some heritage data Data sources in various formats LWS PI Data Sources

4. SRAS Considerations • Insertion of new technologies will occur during the SRAS development and lifetime • SRAS required capabilities will continuously evolve • Minimal effort and no SRAS core software changes should be required for addition of new data sources • Generalized approach to variety of data sources • SRAS will be distributed, both for reliability and performance • Support multiple types of interfaces tuned for different types of science

5. Initial System Challenges • Descriptive metadata that is optimized for resource discovery • Structural metadata that enables access to diverse types of data • Binary, ASCII, images, model output, etc. • Data access that is not constrained by protocol or data format • User interface that is not constrained by data format or instrument

6. Name, Description, POC, parameters, valid dates, location… Descriptive Metadata Structural Metadata File naming conventions, access type, … Organizing the Data • Domain Model logically organizes the data • Data content of each resource is mapped to domain model • PIs don’t have to adhere to strict metadata definitions for data names and parameters • PI creates metadata to describe content and structure of each resource Domain Model Resource Mapping LWS PI Data sources in various formats

7. Scientist enters search constraints SRAS searches descriptive metadata and supplies summary descriptions of matching resources to scientist Space Scientist Solar Scientist Geophysical Scientist Interdisciplinary Scientist SRAS Scientist User Interface Scientist User Interface Scientist reviews summaries, may view detailed descriptions, then selects resources Request Manager Descriptive Metadata SRAS requests/retrieves resources from LWS PI data sites Structural Metadata Resource Manager LWS PI Data Sources How Does a Scientist Use the SRAS? PI supplies data to SRAS SRAS supplies data to scientist

8. Primary Investigator Descriptive Metadata Structural Metadata How Does a PI Supply Data to SRAS? PI registers site with SRAS (only once) PI creates/updates descriptive metadata for each resource SRAS Resource Administrator Interface PI creates/updates structural metadata for each resource Metadata Manager PI maps resource data content to domain model SRAS stores and updates metadata and domain model

9. Current Progress • Developing simple prototype to investigate: • Metadata definition • Access strategies • User interface requirements • Utilizing small set of static and dynamic data from TIMED, Iridium, SuperDARN, and DMSP (UPOS) • Developing preliminary architecture and internal data model • Engaging in discussions with SD scientists to identify requirements and development approach

10. SRAS Development Approach • Establish Scientific Advisory Panel to advise and evaluate SRAS • Develop logical, technology-free system definition to provide framework for long-term development • Develop system in incremental iterations to add and refine capabilities Update Definition Plan Iteration System Definition Develop Software Evaluate Software

11. Scientific Advisory Panel

12. SRAS System Definition • Top-level architecture • Logical model of user interactions, internal software organization, logical interfaces • Technology-free logical baseline provides framework for future development • Logical model of metadata keywords for initial data sources • Provide a framework for future flexible data discovery • High-level SRAS internal data model • Logical data organization for operational system

13. SRAS Iterations • Each iteration: • focuses on single functional area • includes user interface for scientist evaluation and feedback • May be “clunky” for early iterations • Sized for ~3-4 calendar months, ~9-12 staff-months + advisory support for planning and evaluation • May be resized depending on scope, available funding, etc. • May take longer as system matures and more user feedback is solicited • Begins with a planning phase to clearly identify: • Features to be implemented (including the user interface concept and the desired robustness of the implementation) • Development Effort • Validation Method • External information/expertise required

14. SRAS Iterations (cont.) • Five suggested iterations identified so far: • Static Data Access • Dynamic Data Access • Data Combination • User Interfaces • Formal System Interfaces • Additional iterations will be identified by the advisory panel as LWS and SRAS development progresses

15. Iteration 1: Static Data Access • Primary Focus: Static Data Source Description and Access • Develop methods to access existing files and databases • Content Description • Form of data structural definition • Access methods (e.g., ftp) • Develop metadata and establish access for heritage static data sources

16. Iteration 2: Dynamic Data Access • Primary Focus: Dynamic Data Source Description and Access • Develop methods to access data that is generated upon request • Content Description • Input requirements • Other data sources • User control input • Access methods (e.g., CGI) • Asynchronous data retrieval • Develop metadata and establish access for heritage dynamic data sources

17. Iteration 3: Data Combination • Primary Focus: Combining or Grouping different sets of data • Develop methods to logically organize different types of data with similar information content • Multiple data sets required to satisfy user’s request • Sets can be combined sequentially (e.g., organized by time) • Sets can only be grouped logically (e.g., multiple parameters requested) • Different data formats (e.g., images and raw data files)

18. Iteration 4: User Interface • Primary Focus: User Interface • Develop user-friendly interface for scientist discovery and access • Develop interface for PI data maintenance • Update metadata • Add new datasets • Utilize feedback from first 3 iterations • Perform usability and task analysis if appropriate

19. Iteration 5: Formal Interfaces • Primary Focus: Formal Interface definition • Formally define interfaces and methods needed by PIs to add their data to the SRAS • Data description • Metadata content and structure • Data access interfaces • Form of the interfaces that PIs must provide for SRAS to access their data • Use descriptions of data sets incorporated in previous iterations as examples