|
Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.adass.org/adass/proceedings/adass00/D-06/
Дата изменения: Tue May 29 19:18:56 2001 Дата индексирования: Tue Oct 2 03:57:04 2012 Кодировка: Поисковые слова: infrared |
The National Virtual Observatory (NVO) will encompass data and functionality covering all aspects of astronomical research. No one overarching software ``system'' will ever adequately provide the range of functionality required. Rather, the NVO should be envisioned as a set of cooperative but reasonably autonomous components, each of which is designed to provide the optimum functionality in a narrow area. The key to NVO success will be to foster an environment where individual development efforts are discrete and intrinsically integrable in the face of a perpetually imperfect understanding of their future use.
As on-line archives become more and more prevalent, one area ripe for development is that of integrated multi-archive data access. Specifically, we are building a client toolkit which supports the ability to view and compose data from various sources and to use this composite knowledge to further the process of data retrieval and analysis.
This paper describes the full range of functionality planned for OASIS. A preliminary version of OASIS was released to the community at ADASS; functionality that existed then will be identified where described here. Parallel work is underway to develop a server-side toolkit with which complex inter-archive composite data access and processing requests can be managed. While these two are envisioned as complementary, with OASIS also acting as a front-end control for the request management environment, they are also independent with OASIS providing access, integration, and visualization for current archive services.
The OASIS toolkit marries the kind of functionality found in historical data display programs with the remote-access/ dynamic-data-rendering/extensibility model popularized by Web browsers, but in a form customized to the needs of astronomy archival research.
The best way to visualize this synthesis is as follows: A Web browser normally receives and renders HTML with embedded images. When it sees most other datatypes it either fires up a separate plug-in or saves the data to disk. In OASIS, if the data that it sees is an image, source table, sky drawing (like a contour plot), XY graph, etc., it is rendered (or added to an existing display) using astronomy-specific tools. As with browsers, the detailed mechanism by which a user interacts with an archive is defined by the archive (or some other third party) and can be dynamically downloaded to OASIS when needed. OASIS differs from a browser not only in that it intrinsically understands a range of astronomical datatypes but more importantly that it understands their interrelationships and how to render them in composite.
Also similar to browsers, downloaded information (in this case data files or archive access interfaces) can be cached for future reuse or installed formally as packages. There is nothing specific to archive access in this model, so tool builders who wish to add data processing functionality to the mix (e.g., aperture photometry or other image processing) as downloaded or installed components can do so using the same formalism.
The current and future functionality plans for OASIS fall into the following broad categories:
The map display/map layer overlay functionality is already complete, as is basic table display (without any DBMS functionality) and rudimentary XY graphing functionality. A major current effort involves generalizing the map layer interface and creating a ``sky drawing'' XML dialect to allow easy extension of both OASIS and the data services that feed it by any interested members of the community.
The table display currently allows for ``active'' cells: URL-like encoding of external references to specific basic data retrieval or Web-based information services. True URL (e.g., NED detailed data for a specific source) are dynamically passed to a ``peer'' browser. Data references resulting in downloaded data (in contrast to the HTML of the preceding) will be submitted through a ``request manager'' (see below) and the results handled by one of the built-in renderers (e.g., retrieved images becoming the base for the Sky Map display). A good example of this is one of the modes of the NED (NASA Extragalactic Database) interface, where the currently displayed image is used as the basis for a NED region search (which returns a table of basic source information). Columns in this table are dynamic references to detailed information on the source (detailed source information from NED, journal documentation from ADS, image download references if available, light curve information--an XY graph--from the AAVSO, etc.).
The current OASIS has a small set of custom search interfaces to several image archives (the Infrared Astronomical Satellite, IRAS; the IRAS Galaxy Atlas; the Two-Micron All-Sky Survey, 2MASS; the Hubble Space Telescope Digital Sky Survey, DSS; and the VLA FIRST and NVSS surveys). It also has custom interfaces to the IRSA catalog holdings (and in particular to the terabyte-scale 2MASS source catalog) and to the Vizier holdings at the CDS in France. As was mentioned above, we plan to generalize this interface, allowing open dynamic extension in much the same way that data providers currently build HTML forms to access their own data holdings.
Data retrieved by such services are normally low-level constructs (basic images or tables) and are identified by the return MIME type or by knowledge built into the retrieval component. For images, this is assumed to be FITS format (possibly compressed) and for tabular data will most likely be XML (though the details of this are currently under discussion). We expect that in the future there will be more complex data return structures, containing the above but with an XML ``inventory'' and possibly packaged in a JAR file. Determining precise details of this will be left to the future NVO project and are easily accommodated in OASIS.
All OASIS data external data requests will be handled through a single ``request manager'', a multi-threaded object which handles remote submissions and the flow of returning data, either into files or directly to rendering engines (at the user's discretion). A basic version of this is already in place which handles connection to current HTTP/CGI stateless data services. However, in conjunction with the server-side request management infrastructure it would also provide for reconnection to outstanding requests (e.g., when restarting OASIS after exiting and going home for the day) and reacting to asynchronous server-generated signals. This more advanced interaction scenario would be accomplished using RMI and servlet connections to server-side Enterprise Java Beans (EJBs).
One of the main reasons for integrating the various visualizations under a single umbrella is to easily support data interrelationships. For instance, a catalog subset can be retrieved based on a displayed image and rendered both as a table and as a scaled (and colored and shaped) symbol layer on top of the image (or any other image of the same part of the sky). Selecting records in the table can also result in the symbols in the overlay being highlighted (and vice versa). The same idea can be extended to highlighting points in a scatter plot based on the table or only making a scatter plot or a histogram using the sources outlined in the image.
The mechanism which makes this possible is an event registration/ broadcast mechanism (similar to that used for Java Beans) implemented through a small set of specific event types (e.g., sky location event, sky area definition event, etc.). Individual objects (e.g., map layers) can register to receive such events, though most allow this to be managed through a single ``layer control'' interface. As with Java Bean events, the event sender does not know (or care) what the receivers do with the event.
Most of this formalism is already in place. The work planned under this proposal in this area is to generalize and externalize the mechanism so that other sets of events can be defined and added by outside groups of users.
Java class loading functionality makes it simple for outside service/functionality providers to add specialized tools to OASIS (even if only for their own use). However, in order to utilize this we must first provide a set of interfaces that will allow OASIS to initiate the tools and allow the tools access to OASIS internal data (e.g., the current image or table, events, etc.).
For the most part, current information location functionality (search engines, archive home pages, resource lists, etc.) can be used to disseminate information on available extensions and assure quality control. We expect that program-friendly services in this area (along with security and information validation) will be a primary aspect of any primary NVO activity.
Much of the underlying functionality needed to build OASIS comes from other sources (FITS image readers, map projection routines, etc.). In addition, we have built and are extending libraries to handle astronomical coordinates (including precession, Besselian-Julian conversion, and proper motion) and XML table parsing.