Model Component Database Query and Retrieval
Author: Julien Chastang
Date: September 12, 2006
Goals
Investigate how a user could interact with a modeling component database.
Actors
Jane Modeler
Earth Curator System (ESC)
ESC Web browser (User Interface) UI
Trigger
Through the ESC Web UI, Jane wishes to search the model component DB based on certain query options. In particular, she may want to know more about the code base, grid configuration, institution where the component was developed, or many other search criteria available via the ESC interface.
Summary
ESC has a model component database available via a web UI. Jane Modeler accesses the ESC UI to query for model components based on her search options.
Preconditions
Curator system has significant metadata holdings concerning components from the modeling community.
Curator has a user interface and back-end system sophisticated enough to run and store metadata for a wide variety of modeling components.
There is a Curator metadata XML schema (or lingua franca) that has been adopted by the climate modeling community.
Jane has access to the Internet via a web browser and has a Curator account with the correct permissions.
Main Success Scenario
Jane logs into ESC system.
Navigates to the ESC component query page.
Therein is a form allowing Jane to search on the following options:
Name of component
Text description of component
Institution where component was developed and maintained
Type of component {atmosphere, atmospheric dynamics, atmospheric physics, atmospheric analysis, ocean, sea ice, land & surface, hydrology/watershed, space weather, etc.}
Contact information
Sponsor {NSF, DOD, etc.}
Coupling Potential
Development stage {Prototype, Production, etc.}
Various science parameters
Interoperability information
Grid specification {Spectral, Polar, etc.}
Codebase
Codebase Language {Fortran, C++, etc.}
Platform supported {Red Hat, Sun OS, etc. }
Intent {Climate, short-term forecast, plume dispersion, etc.}
Model scale {Mesoscale, CONUS, global}
Framework compliance {ESMF, etc.}
Jane does a search on a subset of the criteria above. For instance, she may to search for contact information for all components that adhere to the ESMF framework.
Jane clicks the Submit button in the web browser.
A few moments later a table of information returns with high-level descriptions of each component that matched the search criteria. In addition, each row may have more URL links that point to other information. For instance, there may be a link to the version control repository that houses the codebase.
Extensions
We can envisage a scenario where ESC has more significant semantic understanding of components. The search that Jane conducts could return additional information such as compatibility between components. This is one of the stated goals of curator.
Issues
Assuming ESC is housed or contained in the UCAR Community Data Portal, how will this be done in practical terms? Can a relational database be plugged into CDP? How will the middle-tier of ESC interface with CDP?
How will the component database be populated? How much of this process will be manual? How much will be automated?
What are the security issues involved here. What if our customers (Navy, DOD, etc) require certain security, and encryption protocols?
How will user permissions (Read Only, Write etc.) be assigned?
Will ESC require an active human administrator or will be mostly automated.
Obstacles
Part of the onus for the usefulness of a system like this will fall on the clients or users. How will ESC convince the (potential) user base to contribute to this community effort?
Further Use Cases
We could elaborate the component compatibility portion of Curator in another use case.
Another goal of Curator is auto-assembly of components to form a model. How would this auto-assembly tool interface with the component database?
References
http://cdp.ucar.edu/
http://www.esmf.ucar.edu/
Link to this Page