February 14, 2003 Tom McGlynn

The ADEC and ADEC White Paper

The HEASARC and The Virtual Observatory

Outline What problem are we trying to solve? What do we need from the HUG? The ADCCC and ADEC Current VO Activities The ADEC White paper

Draft Concepts Capabilities Approach Organization

What is the problem we are trying to solve?

Astrophysics science goals cannot be attained without coordinated use of data from multiple sources. Decadal review VO recommendation

Virtual observatory activities are underway in the US and abroad.

What is NASA’s role? Individual institutions are involved, but

there is no systematic response.

HUG contributions

Advice What is the best approach? What are the key components?

Endorsement and advocacy As representatives of the community

indicate that this is important to do. As individual astronomers make it known

that this is something you want.

Background of the ADEC

ADCCC created in mid 90’s Ad hoc organization of NASA archives

with some outside representation Keep each other informed of issues Minimize duplication of effort Address ‘boundary’ issues

EUVE archive

Creation of ADEC

ADCCC formally recognized by NASA and reorganized as Astronomy Data Centers Executive Committee (Jan 2001).

Chair rotates each year One representative from each data

center. CDS representative and potentially

others from outside NASA.

Membership of the ADEC NED – Barry Madore (chair) ADS – Gunther Eichhorn CXC – Pepi Fabbiano IPAC - Andy Boden IRSA – Bruce Berriman GLAST – David Band HEASARC – Tom McGlynn (acting) LAMBDA – Gary Hinshaw MAST – Marc Postman NSSDC - Joe King SIRTF – Lisa Storrie-Lombardi HST - Paolo Padovani CDS - Francoise Genova

ADEC Activities Interface with journals

Standards for publishing data sets used in research

FITS technical working group Build upon FITS standards

Interoperability technical working group Establish interoperable systems within

NASA centers.

ITWG Charter Provide seamless (one stop shopping)

access to all the NASA astrophysics catalog and data services regardless of where the information is located. All services will be accessible via standard

protocols Access will be via the existing user interfaces Results will appear consistent with the interface

that initiated the request. Affiliation of the data to the original site will be

clearly stated.

Existing ADEC LinksToADC ADS CXC HEASARC IRSA MAST NED

Link fromADC Obs. Row-

Abstract IMPReSS-

ArchiveVizieR-Browse

IMPReSS-Archive

CatsEye-ObjectsName Resolver

ADS ADS-Catalogs

ADS-archive

ADS-archive ADS-archive ADS-archive

ADS-Objects

CXC* Obs.-Abstracts

Name Resolver

HEASARC* Browse-VizieR

BibServer-Refs

Browse-archive

SkyView-2MASS

Browse-EUVE QLS'View/Morph-DSS2

Name ResolverBrowse-Position serv.

IRSA OASIS-

VizieR1

OASIS-SkyViewOASIS-archive

OASIS-DSS

Name ResolverOASIS-objects

MAST* MAST-Catalogs

Obs/Target-Abstract

MAST-ROSATMAST-EUVE

Name Resolver

NED NED-IMPReSSNED-VizieR

Reference-Abstract

NED-Browse NED-2MASS/IRAS

NED-archiveNED-FIRST

*Provides Astrobrowse-style service with links to all astronomy position sensitive services

Color coded link types:

position user selected parameters

target name observation

Current Links

Mostly ad hoc bilateral agreements between institutions (or reverse engineering of existing links)

Easily broken by updates from either side.

Rarely provide systematic access to remote resources.

ITWG results

Mixed… Able to develop prototype interfaces, protocols

and user services Bibcode delivery to ADS What services are available at a given

region Data set verifier services

Limited success in implementing these services over all centers or using them in operational user interfaces.

Hard to do real work for free….

SAWG Presentation Results of ADEC and ITWG activities

discussed at Science Archive Working Group (SAWG) meeting in October 2002.

SAWG requested White Paper describing the resources and approach needed to build a NASA interoperable archive.

SAWG will review and recommend action by NASA HQ. Next SAWG meeting April 22-23 ADEC meeting on March 12

Status of White Paper Two different approaches suggested:

Build single unifying interface to integrate all archive systems Master Object Directory

Agree on protocols and build systems on top of them Continuation of ITWG approach but with

actual resources. Substantial overlap in content, but major

differences in emphasis.

Master Object Directory. All archives will process data received

and provide a list of objects detected and datasets involved in a standardized way.

Lists of objects will be combined into a Master Directory of objects.

Users can query against master directory to find data in any NASA archive.

Master directory schematic

Archive

Object extractorCatalog/Arch. I/F

Archive

Object extractorCatalog/Arch. I/F

Archive

Object extractorCatalog/Arch. I/F

Archive

Object extractorCatalog/Arch. I/F

MasterDirectory

Object Info Updates

MD Interface

Object query

Requests for data associated with target

User

Requested data

Comments Clearly defined deliverables and new

capabilities for user. Complex queries on objects possible as

local queries on Master Directory. Technical concerns:

Handling non-object oriented datasets Hierarchical and extended objects

‘Political’ concerns: Is this something within the purview of NASA

centers alone? Do we want to concentrate on a single ‘master’

interface?

Interoperability Layer Approach Build thin layer of agreed interfaces to

access data. Modify existing resources to access remote

data using new layer. Data models describe resources in common

framework. Use layer as foundation for new capabilities

(perhaps including object directory) Essentially implementing a three-tier

architecture in NASA archive systems.

Interoperability Layer Schematic

Archive Archive Archive Archive

Interoperability Layer Protocols

CorrelatorRegistry

Browse Starview OASIS New Interfaces

Comments Builds upon existing systems and

provides multiple portals to data. Less explicit coupling of data centers

and services Deliverables less well defined and

more diffuse. Provides more incremental changes

to systems rather than dramatic new capabilities.

Commonalities

Common interface layer Catalog and archive access Regions covered by observations

Data models Need to agree on some common

semantic concepts, e.g., object, image, spectra, … independent of how these are stored.

Cross-correlation

What does the community need?

Common access to data and catalogs Can’t require users to know all of the

different interfaces. Ability to combine data from different

sources. Data model descriptions of data

Management

Distributed management Who does central oversight

Implications for HEASARC Substantially enhanced capabilities

for joining data in Browse, SkyView, Astrobrowse and other services.

Access to HEASARC data resources through other data portals.

Better coordination of NSF-funded and NASA sponsored NVO activities.

Need to ensure that this does not incur long term liabilities.