The meeting was held at the Goddard Space Flight Center (thanks to Nick White for hosting), and was attended by the following:
The ``official'' reason for meeting was to consider the plans for transitioning the EUVE data, data products and software from the CEA to other archive/data centers as a test case for the broader objectives of the Space Science Data Systems (SSDS) concepts of interoperation and interdisciplinary access to data.
However, before addressing the specifics of the EUVE situation the
current status of the Astrophysics Data Centers was reviewed. First,
STScI has been given an expanded role to take on the UV/Optical data
sets and archives. An agreement between STScI and NASA
(Bredekamp/Riegler) for STScI to archive the IUE mission was the
driver for this decision.
With the above change, there are now three de-facto SARCs (Science Archival
Research Centers) as first defined in the Astrophysics Data System Study
Final Report (Squibb 1988) for astrophysics:
The question as to whether this archive structure should be left intact or modified to more closely follow the NASA Science Theme structure was raised. It was quickly agreed by all present that the discipline oriented structure is the correct one. These archival centers serve as an analog to software middleware, in that they provide the necessary access layers that make data accessible to thematic as well as disciplinary studies. There is a ``natural'' division of data archives according to the discipline since the form of these data, the type of data products, and even the software systems tend to have strong disciplinary dependencies. There is no corresponding thematic split since the astrophysics data is expected to be used for a variety of science studies. Indeed that's the whole idea behind broader access to these data.
The discussion turned to taking the first step in providing some form of inter-disciplinary interactions. Using AstroBrowse as a starting point was raised by the STScI (Hanisch) and HEASARC (McGlynn). They have been working on advancing the initial feasibility work on AstroBrowse into a real system. In the short time scale of months, and using CGI and Z39.50 protocols, this subgroup (along with NCSA) have begun a prototype for AstroBrowse that supports the specific function of finding data based on a position (RA, Decl) and a radius. Either a source list or a postage stamp image are examples of what might be returned.
The group discussed this approach and tried to flesh out the
requirements for such a system. The zeroth level need is ``data
discovery'' which simply provides a way to know what data is available
where. Given this information, it is possible to query a data archive
for the appropriate data. The problem of translating a data search
into the specific set of instructions for an archive is where work
needs to be done. There are two aspects to data discovery: (1)
agreeing on a ``profile'' that describes the terms used to describe
data holdings, e.g., ``bandpass'' (Gamma-ray, X-Ray, UV, etc.),
``Data type'' (image, spectrum, time series, etc.), and so forth; and
(2) providing a simple facility for translating the standard terms
from the profile into site-specific query formats. Several approaches
to (2) are being investigated including using the Z39.50 protocol,
using configuration files similar to Perl scripts, and using
configuration files based on the GLU protocol. The GLU facility was
developed by the CDS for managing a database of URLs, and is the
preferred solution for AstroBrowse at this time.
After the simple case of being able to input a position and radius and
learn about what objects or images are available, there comes the
problem of being able to combine the results. There was recognition
during the discussion that another function that needs to be provided
by the data centers is transformation functions that can be used as
required by systems such as AstroBrowse or systems that are put
together by researchers. With a good set of transformation functions,
users can put results from various archives into common formats for
combined analysis. For example when images are returned (even postage
stamps) the coordinate systems and pixelization will be whatever that
data set or system generates. Even if the user can specify some
options to the request there is no guarantee that all data can be
requested in the same format. So, some middle layer of tools is
necessary to allow the necessary transformations. The development of
these tools needs some coordination which this Council might
provide. Clearly work needs to be done to create these tools, as well
as time and resources (money). The group saw this as middle time scale
work to follow in the 1-2 year time frame.
Finally there was discussion of expanding the basic AstroBrowse to
include more thematic functions such as ``Tell Me About...'' requests
that span disciplines and are more than single oriented. such as gathering
data about a particular class of stars, or finding all the
coordinated observations (Optical, UV, IR, X-ray, etc.) for
quasars. This again will require some development work and some
additional information in the data set profiles. The group saw this
type of functionality as coming later in time perhaps in the beyond 2
years horizon.
Mixed into this discussion, which centered on the AstroBrowse approach
there was a suggestion from IPAC (Madore) and others that the
bibliographic services (NED, ADS, SIMBAD) should develop links into
the data providers. The discussion here centered upon making sure that
there was no loss of identify for the data centers. That is it was
viewed as important for the users to be aware of where these data
links were taking them. From the data center point of view, it is also
important that there be proper accounting.
The general consensus from this discussion was a plan to have a
demonstration of the prototypes for AstroBrowse available for the Jan
1998 AAS meeting in Washington DC. The Data Centers that have exhibits
(notably STScI and HEASARC) will be able to show their respective
AstroBrowse interfaces and allow people to compare them. This very
short term goal is a first step in implementing the most basic
AstroBrowse functionality of positional searches with either tabular
or postage stamp images returned. No attempt to reformat data or
coordinate the results is planned. The goal is to include as many data
sources as possible (using the AstroBrowse profiles to describe the
data access), and for anyone who wishes to develop WWW (CGI) based
user interfaces that make use of these protocols. Basically the User
Interface is the WWW page that then calls particular URLs as User
Agents for making contact with a data center, performing a search, and
returning results. This activity would be carried out within the
existing scope of the Data Centers' current funding.
Following this first step, will be efforts to standardize the data
formats via transformation and conversion functions as well as
extending the types of queries to classes of objects as well as
positions (or specific objects resolved into positions). In order to
carry out this work, the Data Center's will need to develop ADP or
AISRP proposals to NASA for funding, or find ways to perform the tasks
within existing budgets. The time scale for implementing this work is
1-2 years.
By general agreement, and with full approval by this Council, the HEASARC and STScI will be the primary access points for the EUVE data. The HEASARC will be mainly responsible for the data products and will also put a 1-D spectral browser capability on-line. STScI will have the EUVE catalog on-line with pointers into the HEASARC for the data. If the load for data is too high, STScI will also have on-line data. STScI will take responsibility for the EUVE IRAF based data analysis system. This software is currently being ported to IRAF 2.11 at CEA and when this work is completed STScI will take over the software archive and support.
The present status of EUVE is that data are being received at NSSDC
(Science Data and Data Products, but not Telemetry). These are being
placed on-line at HEASARC initially, and if need be at STScI. The
Telemetry data will be sent to NSSDC, but is not going on-line. The
software from CEA to read and locate telemetry (the ESW software
package) is not portable and will not be run at NSSDC. There are
currently 6 ADP Grants that require EUVE telemetry, it is not clear
how these data will be made available for the grants.
The group discussed the committee structure that is advising NASA on Space Science Data. There is a working group (Information Systems and Science Operations Working Group -ISSOWG) that formally advises Bredekamp and Riegler on OSF wide issues. The Space Science Data Systems Technical Working Group (SSDSTWG) is an ad hoc committee reporting to Bredekamp on implementing a service across all of Space Science, including therefore at least Astrophysics, Space Science, and Planetary. Finally, this group (also an ad hoc committee) is specific to astrophysics and is charged with improving the interoperability of data services across the astrophysics disciplines, using the EUVE experience as a ``test particle''.
The group agreed upon naming itself the Astrophysics Data Centers
Coordinating Council. The Council plans to meet quarterly for the
first year or two and then if reasonable reduce to
semi-annually. These meetings will be held at the data center sites
and will not necessary be coordinated with other astronomical
meetings. Next meeting will be the end of March or beginning of April
at JPL/IPAC. A Planetary Data Systems (PDS) representative will be
invited to the meeting to begin the process of extending the
AstroBrowse system beyond the astrophysics realm.