Many individual missions have augmented their data search capabilities by storing much of their metadata in Relational Data Base Management Systems (RDBMS). This significantly enhances the value of the data. JHU/APL has done this on several of its missions including Midcourse Space Experiment (MSX), Near Earth Asteroid Rendezvous (NEAR), and Thermosphere Ionosphere Mesosphere Energetics Dynamics (TIMED). This helps the situation a great deal but there are several problems with it. It is not standard. Not everyone is using the same RDBMS. There is very little or no cross-RDBMS search capability. It is not integrated with the Web in any standard way.

When the missions were limited to in situ measurements, comparisons between instruments on the same satellite or comparisons between instruments on different satellites was straightforward. An ephemeris of spacecraft location and time and instrument operation status was all that was required to find coincidences between measurements. With the inclusion of a large number of remote sensing instruments or in fact entire missions with exclusively remote sensing instruments the searching for coincident data has become more complicated. Each instrument may have its own look-point; in fact some instruments may look in opposite directions. A good example of this is the NASA TIMED mission. In this mission, there are four remote sensing instruments, the Global UltraViolet Imager (GUVI), Sounding of the Atmosphere using Broadband Emission Radiometry (SABER), TIMED Doppler Interferometer (TIDI), and Solar EUV Experiment (SEE). GUVI is a cross-track and limb viewing imager, SABER is a limb viewing radiometer, TIDI is a Doppler imager with four telescopes each with separate look-directions, and SEE is a solar irradiance monitor. Finding cross comparisons between instruments is more difficult because we must be concerned not just with spacecraft location, but also with multiple look-points for the instruments. In addition, with remote sensing instruments, particularly limb-viewing instruments, we must be concerned with another spatial dimension, the altitude of interest. Finding data, particularly for people who are outside investigators, not on the instrument teams, becomes much harder. Currently catalogs of metadata do not include all of the types of information required for some cross-instrument studies. Certainly no central catalog exists which will allow you to perform these detailed types of cross-mission data queries.

Currently a typical approach to cross-mission data searches will be to identify your primary data source noting the time and location. Then you will query another catalog to search for the existence of your corollary dataset by time and location. This process is then iterated for multiple data coincidence searches. Find your data of interest then search for corollary data by time, and then look by location. Your ability to do "What if?" type analyses is limited. During the TIMED Science Data System Preliminary Design Review it was asked if the following type of query could be performed where each selective specification further subdivided the data of interest, in the same manner as a Web search engine query.

Example 1:	Select GUVI data
	Select over a certain geographic location
	Select nighttime only
	Select certain Kp range
Example 2:	Select GUVI and TIDI data
	Select a specific 48-hour period
Example 3:	Select TIDI data
	Select ten-minute time interval
	Select geographic location
	Select Kp range

If you wished to add another satellite such as Polar or IMAGE and directly ask the question of "Can I determine when the UltraViolet Imager (UVI) instrument on Polar observed the auroral region at the same time as the GUVI instrument on TIMED?" you would find that there is no single place to go to make this sort of query.

The reasons that there is no central data cataloging or data query system are many-fold. They mostly come down to cost and complexity. To keep the cost of individual missions low, cataloging facilities have largely been excluded or only basic catalogs produced. Another reason is that there is no single standard for what metadata should be included in a catalog and what structure the metadata should take. The development and adoption of XML represent an opportunity for the standards to be developed and widely used allowing Commercial Off The Shelf (COTS) software to replace the custom applications used in the past.