Difference between revisions of "FROST Architecture Options"
| Line 14: | Line 14: | ||
==Chaining the Dataset Level to the File Level Search== | ==Chaining the Dataset Level to the File Level Search== | ||
===Return Links to OpenSearch Description Documents=== | ===Return Links to OpenSearch Description Documents=== | ||
| + | In this option, the directory search provider would include in its response a link to OpenSearch Description Documents. For this to work, we would need to establish a convention in the Atom response element as to where it would be inside the response (a link with a rel attribute?) and what this link would be named (e.g., rel="OpenSearchDescription"?). | ||
| + | |||
===Return OpenSearch Description Documents Directly=== | ===Return OpenSearch Description Documents Directly=== | ||
In this scheme, the directory being searched would return an OpenSearch Description Document directly. Typically, this would be implemented by adding a Template field to the directory in question, and having the directory map other fields to the OpenSearch Description Document elements. GCMD might map <Entry_ID> or <Entry_Title> to <ShortName>, and <Summary> to <Description>, also populating the <Tags> field with GCMD Keywords. (The Template would be added as a Related_URL.) | In this scheme, the directory being searched would return an OpenSearch Description Document directly. Typically, this would be implemented by adding a Template field to the directory in question, and having the directory map other fields to the OpenSearch Description Document elements. GCMD might map <Entry_ID> or <Entry_Title> to <ShortName>, and <Summary> to <Description>, also populating the <Tags> field with GCMD Keywords. (The Template would be added as a Related_URL.) | ||
==Options for Distributed Dataset Search== | ==Options for Distributed Dataset Search== | ||
Revision as of 09:14, July 17, 2009
Architectural Pivot Points
Centralized vs. Distributed Search for Datasets
Options for Centralized Dataset Search
Note that the below options are not mutually exclusive.
Global Change Master DIrectory
GCMD records a vast number of datasets related to Earth Science and Global Change. In theory, it holds records for all publicly available NASA Earth Science Datasets, plus additional datasets from ESIP members, and is an ESIP partner itself. GCMD has also shown an ability to map its DIF structure to a variety of different output formats. Key question would be the cost to accommodate the OpenSearch Description documents
Mercury
Mercury is the official(?) directory for ESIP, and so in theory would make sense as the directory for any FROST implementation within the ESIP. Key questions would be:
- how much cost to accommodate the OpenSearch Description documents (should be small?)
- how up to date is Mercury for ESIP kept?
Chaining the Dataset Level to the File Level Search
Return Links to OpenSearch Description Documents
In this option, the directory search provider would include in its response a link to OpenSearch Description Documents. For this to work, we would need to establish a convention in the Atom response element as to where it would be inside the response (a link with a rel attribute?) and what this link would be named (e.g., rel="OpenSearchDescription"?).
Return OpenSearch Description Documents Directly
In this scheme, the directory being searched would return an OpenSearch Description Document directly. Typically, this would be implemented by adding a Template field to the directory in question, and having the directory map other fields to the OpenSearch Description Document elements. GCMD might map <Entry_ID> or <Entry_Title> to <ShortName>, and <Summary> to <Description>, also populating the <Tags> field with GCMD Keywords. (The Template would be added as a Related_URL.)
