An essential capability of the Virtual Observatory is a means for describing what data and computational facilities are available where, and once identified, how to use them. The data themselves have associated metadata (e.g., FITS keywords), and similarly we require metadata about data collections and data services so that VO users can easily find information of interest. Furthermore, such metadata are needed in order to manage distributed queries efficiently; if a user is interested in finding x-ray images there is no point in querying the HST archive, for example. In this document we suggest an architecture for resource and service metadata and describe the relationship of this architecture to emerging Web Services standards. We also define an initial set of metadata concepts.

Status of this document

This is a Proposed Recommendation. The first release of this document was 7 June 2002.

This is an IVOA Proposed Recommendation made available for public review. It is appropriate to reference this document only as a recommended standard that is under review and which may be changed before it is accepted as a full recommendation. A list of current IVOA Recommendations and other technical documents can be found at http://www.ivoa.net/Documents/.

Acknowledgments

Many members of the IVOA Registry Working Group, IVOA Interoperability Working Group, AstroGrid project, and NVO Metadata Working Group have made significant contributions to this document.

1 Introduction. 2

2 Architecture. 3

3 Resource metadata concepts. 5

3.1 Identity metadata. 5

3.2 Curation metadata. 6

3.3 General content metadata. 7

3.4 Collection and service content metadata. 9

4 Data quality assessment 13

5 Service metadata concepts. 14

5.1 Interface metadata. 14

5.2 Capabilities metadata. 15

6 Example. 15

7 Changes from previous versions. 17

8 Acknowledgements. 19

1 Introduction

2 Architecture

In order to make it easy for astronomy information services to participate in the VO, we propose a hierarchical system for metadata management. At the top level we require a minimum amount of information, sufficient primarily to note the existence of a resource and to describe who is responsible for it. At lower levels, the metadata are more extensive and complex, allowing for the description of query syntax, access protocols, and usage policies.

A resource is a general term referring to a VO element that can be described in terms of who curates or maintains it and which can be given a name and a unique identifier. Just about anything can be a resource: it can be an abstract idea, such as sky coverage or an instrumental setup, or it can be fairly concrete, like an organization or a data collection. This definition is consistent with its use in the general Web community as “anything that has an identity” (Berners-Lee 1998, IETF RFC2396). We expand on this definition by saying that it is also describable.

An organization is specific type of resource that brings people together to pursue participation in VO applications. Organizations can be hierarchical and range greatly in size and scope. At a high level, an organization could be a university, observatory, or government agency. At a finer level, it could be a specific scientific project, space mission, or individual researcher. A provider is an organization that makes data and/or services available to users over the network.

A service is any VO resource that can be invoked by the user to perform some action on their behalf. Associated with any service is descriptive metadata about the service. Metadata generally include information the user needs to determine if a service is of interest and how the service may be invoked. Specific types of metadata are described below. Note that the service itself need not be aware of the metadata that describe it.

A query service supports a query/response protocol. The user submits a query to the service that may define characteristics of interest, and the service returns a set of information to the user. The query may be null, e.g., a current-time service may only support a null query, and some services may respond to a null query with appropriate default actions. Non-query services may also exist, e.g., services to copy or delete files on remote files systems, to mail information to other users, to kill existing jobs, to authorize actions, etc.

A registry is a query service for which the response is a structured description of resources. The resources described by a registry may be of any type. The registry may support a query that allows the user to indicate which resources might be of interest.

In our model, the hierarchy of resources is one in terms of management and curation. For example, an organization may manage a collection of one or more services and even smaller organizations or projects. For example, MAST, HEASARC, IRSA, NED et al. are all resources. Each of these manages other resources, e.g., the HST archive in MAST. They also support specific services (which are also resources) such as an HST observation log query service or a cone search service. One could in principle describe all of NASA astrophysics data holdings as a resource, or all of NVO as a resource, but aggregates of this scale circumvent the goal of being able to locate the specific resources and services of interest for a particular application.

All resources are described by metadata. Resource metadata are high-level and independent of any specific service. Resource metadata include

· Identity metadata, which gives the resource a name and an identifier,

· Curation metadata, which describe who supports the resource and its availability (i.e., version, release date), and

· Content metadata, which describe what kind of information is available (types of data, sky coverage, spectral coverage, etc.). Content metadata can be either general, applying to all resources, or associated more specifically with data collections and the services that deliver data from them.

Resource metadata are typically not queryable parameters in the underlying services, but rather they encompass information that now is simply “known” to users, or must be discovered through other means. Astronomers know that the HST archive includes optical images and spectra, for example, or that Vizier provides access to catalogs and tables. Resource metadata constitute a “yellow pages” of astronomical information. Resource metadata are analogous to the UDDI (Universal Description, Discovery and Integration) Web Service, and are analogous to the high-level descriptions included in the CDS GLU.

Organizations, data collections, and services can be considered as classes of resources that may each require additional metadata to fully describe it, but which are not shared by other classes. For example, a service description would need to include its inputs, outputs, and how it can be accessed. Service metadata, therefore, can be thought of as an extension of the general resource metadata: where as the resource metadata, through its content metadata, describes what is available, the service metadata describes how to access it.

Resource metadata will be collected through resource registration services, e.g., web forms that present a resource curator with the requisite fields and enumerated lists, and construct a resource descriptor in a standard format (such as VOTable). The resource registration service should not allow fields to be left unspecified. Some metadata elements may be irrelevant, unknown, or not provided by the publisher of a resource. Since “irrelevant” conveys different information than “not provided”, we will adopt standard representations of these conditions:

“Not Applicable” irrelevant or not applicable to this resource

“Unknown” unknown, cannot be defined

“Not Provided” no information was provided by the resource publisher

Various applications based on the registry may choose to include or exclude certain resources based on these attributes. If a metadata element is “Not Provided” the application should make no assumption regarding applicability or relevance.

Similarly, some resources may provide quite large aggregations or collections, covering many bandpasses, types, or formats. It may be prohibitive to list all such options. In such cases acceptable representations for the metadata entries would be:

“Any” resource will respond to requests for any of the

available types (though some may not actually be

available)

“All” resource will respond to requests for all of the

available types, and all are actually available in some

non-zero quantity

The most general resource metadata is similar in concept to the Dublin Core metadata definitions (http://dublincore.org/documents/dces/), and where possible DC metadata elements have been used. VO metadata elements that correspond directly to DC counterparts are noted. The Dublin Core elements Language and Relation are not currently used in the VO metadata.

3 Resource metadata concepts

Below we describe the concepts we believe are needed in the resource metadata. These concepts may be instantiated in a variety of standard forms, e.g. XML, UCD tags, or FITS keywords, and with a variety of mechanisms, such as Topic Maps, OWL, or RDBMSs. Consequently, the exact names and rendering of the values may depend on the particular form in which they are represented. For example, when Coverage.Spatial is rendered as a FITS keyword record, the name will need to be limited to 8 characters and the value rendered in a pure ASCII form; in contrast, when rendered in XML, it might be better to tag the different components of the value separately. It will be necessary to define standard renderings for each of these common forms.

A limited number of keywords are considered essential for a basic understanding of the resource, and are thus denoted as required. All others are optional, or may be applied to certain classes of resources only.

3.1 Identity metadata

Title (string) [Dublin Core] [Required]

Definition: A name given to the resource.

Comment: Typically, a Title will be a name by which the resource is formally known.

ShortName (string)

Definition: A short abbreviation for the name given to the resource.

Comment: The ShortName will be used where brief annotations for the resource name are required. ShortName strings are limited to a maximum of sixteen characters.

Identifier (URI) [Dublin Core] [Required]

Definition: An unambiguous reference to the resource within a given context. The syntax for Identifiers is described in IVOA Identifiers in the IVOA document collection (http://www.ivoa.net/Documents/).

Comment: The URI corresponding to the resource.

3.2 Curation metadata

Publisher (string) [Dublin Core] [Required]

Definition: An entity responsible for making the resource available

Comment: Examples of a Publisher include a person or an organization. Users of the resource should include Publisher in subsequent credits and acknowledgments.

PublisherID (URI)

Definition: The identifier for the entity responsible for making the resource available.

Comment: This item is optional; an ID for the publisher may not yet be established (e.g., if the publisher has not yet been registered).

Creator (string) [Dublin Core]

Definition: An entity primarily responsible for making the content of the resource.

Comment: Examples of a Creator include a person or an organization. Users of the resource should include Creator in subsequent credits and acknowledgments.

Creator.Logo (URL)

Definition: A URL pointing to a graphical logo, which may be used to help identify the information resource.

Contributor (string) [Dublin Core]

Definition: An entity responsible for making contributions to the content of the resource.

Comment: Examples of a Contributor include a person or an organization. Users of the resource should include Contributor in subsequent credits and acknowledgments.

Date (string) [Dublin Core]

Definition: A date associated with an event in the life cycle of the resource. Typically, Date will be associated with the creation or availability (i.e., most recent release or version) of the resource. ISO8601 is the preferred format (YYYY-MM-DD).

Version (string)

Definition: A label associated with the creation or availability (i.e., most recent release or version) of the resource.

Contact (string, e-mail address)

Definition: The e-mail address for contacting the persons responsible for the resource.

Comment: Contact is split into two components for clarity.

Contact.Name (string)

Definition: The name of the contact.

Comment: A person’s name, “John P. Jones”, or a group, “Archive

Support Team”.

Contact.Email (e-mail address)

Definition: The e-mail address of the contact.

Comment: For example, “John.P.Jones@navy.gov”, or

“archive@datacenter.org”.

3.3 General content metadata

Subject (string, list) [Dublin Core] [Required]

Definition: A list of the topics, object types, or other descriptive keywords about the resource.

Comment: Subject is intended to provide additional information about the nature of the information provided by the resource. Is this a catalog of quasars? Of planetary nebulae? Is this a tool for computing ephemerides? Terms for Subject should be drawn from the IAU Astronomy Thesaurus (http://msowww.anu.edu.au/library/thesaurus/), though in the absence of suitable terms (the IAU Thesaurus is not complete in all areas of astronomical research) the following alternate collections of astronomical research terms may be used:

Vizier keywords (CDS): http://vizier.u-strasbg.fr/doc/ADCkwds.htx

Astronomy journal keywords: http://www.edpsciences.org/journal/ statique/doc/aa_keywords.html

Description (string, free text) [Dublin Core] [Required]

Definition: An account of the content of the resource.

Comment: Description may include but is not limited to: an abstract, table of contents, reference to a graphical representation of content or a free-text account of the content.

Source (string) [Dublin Core]

Definition: A bibliographic reference from which the present resource is derived or extracted.

Comment: The present resource may be derived from the Source in whole or in part. Recommended best practice is to use the standard bibcode (see http://cdsweb.u-strasbg.fr/simbad/refcode.html), where available. If no bibcode is available, Source should use a string or number conforming to a formal identification or citation system.

ReferenceURL (URL) [Required]

Definition: A URL pointing to additional information about the resource. In general, this should be in a human-readable format.

Type (string, list) [Dublin Core] [Required]

Definition: The nature or genre of the content of the resource.

Comment: Type includes terms describing general categories, functions, genres, or aggregation levels for content. VO Types include:

Type Description

Archive Collection of pointed observations

Bibliography Collection of bibliographic references, abstracts, and

publications

Catalog Collection of derived data, primarily in tabular form

Journal Collection of scholarly publications under common

editorial policy

Library Collection of published materials (journals, books, etc.)

Simulation Theoretical simulation or model

Survey Collection of observations covering substantial and

contiguous areas of the sky

Education Collection of materials appropriate for educational use, such

as teaching resources, curricula, etc.

Outreach Collection of materials appropriate for public outreach, such

as press releases and photo galleries

EPOResource Collection of materials that may be suitable for EPO

products but which are not in final product form, as in Type

Outreach or Type Education. EPOResource would apply,

e.g., to archives with easily accessed preview images or to

surveys with easy-to-use images.

Animation Animation clips of astronomical phenomena

Artwork Artists’ renderings of astronomical phenomena or objects

Background Background information on astronomical phenomena or

objects

BasicData Compilations of basic astronomical facts about objects,

such as approximate distance or membership in

constellation.

Historical Historical information about astronomical objects.

Photographic Publication-quality photographs of astronomical objects.

Press Press releases about astronomical objects.

Organization An organization that is a publisher or curator of other resources.

Project A project that is a publisher or curator of other resources.

Registry A query service for which the response is a structured description

of resources.

Other A resource not described by any of the above types.

This list is extensible. Resources providing more than one type of content should list all relevant types.

ContentLevel (string, list)

Definition: A description of the content level, or intended audience.

Comment: VO resources will be available to professional astronomers, amateur astronomers, educators, and the general public. These different audiences need a way to find material appropriate for their needs.

ContentLevel Definition

General Resource provides information appropriate for

all users

Elementary Education Resource provides information appropriate for

grades K-4 education

Middle School Education Resource provides information appropriate for

grades 5-8 education

Secondary Education Resource provides information appropriate for

grades 9-12 education

Community College Resource provides information appropriate for

education at community colleges

University Resource provides information appropriate for

university-level education

Research Resource provides information appropriate for

professional-level research and graduate

school education

Amateur Resource provides information of interest to

amateur astronomers

Informal Education Resource provides information appropriate for

education at museums, planetariums, and

other centers of informal learning

Relationship (string)

Definition: A resource may be related to another resource in a way that is important to document, so that associated services or duplicate copies may easily be located.

mirror-of The resource is a mirror of another resource. Information

gathered from the resources is indistinguishable.

service-for The resource is a service associated with a data collection.

derived-from The resource is a derivative of another resource, e.g., a subset

selected for a particular scientific interest, or a reprocessed data

collection.

RelationshipID (URI)

Definition: The identifier of an associated resource. The relationship is described in the Relationship metadata element.

3.4 Collection and service content metadata

Facility (string, list)

Definition: The observatory or facility where the data was obtained.

Comments: Some resources are likely to hold data from multiple observatories. If just a few, this could be a list; if very many, just say “many”. Theoretical data will not originate with an observatory, but rather might be characterized by the computational facility used to create them (NCSA, SDSC, etc.).

Instrument (string, list)

Definition: The instrument used to collect the data.

Comments: Can be a specific instrument name (Wide Field/Planetary Camera 2) or generic instrument type (CCD camera). Theoretical data is produced by a computer code, and the name of the code could be specified.

Coverage (string) [Dublin Core, with modifications]

Definition: The extent of scope of the content of the resource.

Comment: The Dublin Core notion of coverage is too generic to be of much use in the VO, where we need more specific information. We propose to subset this element as follows:

Coverage.Spatial (string)

Definition: The sky coverage of the resource.

Comment: The complete syntax for the spatial coverage specification is described in the Space-Time Metadata definition document Region definition. Resource metadata may be somewhat simplified (i.e., do not give detailed spatial coverage of a large archive), but should be expressed in a syntax which adheres to the STM specification. All positions should be given in degrees unless specified otherwise. The list below suggests a basic representation of regions, but implementations should rely on the Region schema definition.

Region Name Specification

Circle circle (cframe, ξ_cen, η_cen, radius)

Ellipse ellipse (cframe, ξ_cen, η_cen,semi-major axis,

semi-minor axis, position angle)

Polygon polygon (cframe, ξ₁, η₁, ξ₂, η₂, ξ₃, η₃, …) where ξ,η

pairs give the vertices of a polygon in counterclock-

wise order. In spherical coordinates, the segments

between vertices are assumed to be great circles

unless small circles are explicitly noted.

Sector sector (cframe, ξ, η, θ₁, θ₂) where θ₁ and θ₂ are

position angles bounding the sector

Constraint constraint (cframe, x, y, z, d) where x, y, and z are

the components of a normal vector on the unit

sphere and d is the distance from the center of the

sphere. Constraint defines a spherical cap.

Convex the intersection of one or more constraints

ξ and η represent coordinates in the appropriate frame (α, δ; l, b; …). Compound regions may be constructed with unions (logical or), intersections (logical and), and negation (logical not) . The coordinate system reference frame is specified as follows (http://aladin.u-strasbg.fr/java/doctech/cds.astro.astroframe.html for additional details):

cframe Description

ICRS International Celestial Reference System

FK5 Equatorial coordinates, FK5 system (J2000)

FK4 Equatorial coordinates, FK4 system (B1950)

ECL Ecliptic coordinates (J2000)

GAL Galactic coordinates (J2000)

SGAL Supergalactic coordinates (J2000)

Coverage.RegionOfRegard (float, decimal degrees)

Definition: Both data archives and catalogs have an intrinsic scale size. For example, a source catalog created from an instrument with one degree angular resolution would have a RegionOfRegard of 0.5 degree, meaning that if one is searching for information pertinent to a given position, objects in this catalog within 0.5 degree of the position of interest would need to be included. For an image archive the RegionOfRegard corresponds to the image field of view.

Comment: RegionOfRegard corresponds to CoordArea in the Space-Time Metadata definition document.

Coverage.Spectral (string, list)

Definition: The spectral coverage of the resource.

Comment: Spectral coverage at the resource level will be in terms of general spectral regions (gamma-ray, x-ray, extreme UV, UV, optical, infrared, radio). The general spectral regions are defined specifically as follows:

Coverage.Spectral Represents

Radio l ≥ 10 mm

n £ 30 GHz

Millimeter 0.1 mm £ l £ 10 mm

3000 GHz ≥ n ≥ 30 GHz

Infrared 1 μ £ l £ 100 μ

Optical 0.3 μ £ l £ 1 μ

300 nm £ l £ 1000 nm

3000 Å £ l £ 10000 Å

UV 0.1 μ £ l £ 0.3 μ

1000 Å £ l £ 3000 Å

EUV 100 Å £ l £ 1000 Å

12 eV £ E £ 120 eV

X-ray 0.1 Å £ l £ 100 Å

0.12 keV £ E £ 120 keV

Gamma-ray E ≥ 120 keV

Resources containing data in multiple spectral regions may give a list (e.g., “Radio, Infrared”).

Coverage.Spectral.Bandpass (string, list)

Definition: A specific bandpass specification.

Comment: Some resources and services may choose to give spectral coverage in more specific terms than the general spectral regions. The list of possible bandpass names is too lengthy to enumerate here, but would include optical bandpasses (U, V, B, R, I), narrow line filters (H-alpha, [OIII]), or other specific bandpass names.

Coverage.Spectral.CentralWavelength (float)

Definition: The central wavelength of the spectral bandpass, in meters.

Comment: This should be the most representative wavelength of the bandpass.

Coverage.Spectral.MinimumWavelength (float)

Definition: The minimum wavelength of the spectral bandpass, in meters.

Comment: Implementers are encouraged to set the minimum wavelength to be as inclusive as possible, allowing all relevant resources to be discovered.

Coverage.Spectral.MaximumWavelength (float)

Definition: The maximum wavelength of the spectral bandpass, in meters.

Comment: Implementers are encouraged to set the maximum wavelength to be as inclusive as possible, allowing all relevant resources to be discovered.

Coverage.Temporal.StartTime (string)

Definition: The earliest temporal coverage of the resource.

Comment: Temporal coverage specifications will be given in ISO8601 format. An empty value field implies that there is no known earliest temporal coverage.

Coverage.Temporal.StopTime (string)

Definition: The latest temporal coverage of the resource.

Comment: Temporal coverage specifications will be given in ISO8601 format. An empty value field implies that there is no known latest temporal coverage, i.e., that information continues to be added to the resource.

Coverage.Depth (float)

Definition: The (typical) depth coverage, or sensitivity, of the resource. Coverage.Depth is specified in flux density (Jy).

Coverage.ObjectDensity (float)

Definition: The (typical) density of objects, catalog entries, telescope pointings, etc., on the sky, in number per square degree.

Coverage.ObjectCount (int)

Definition: The total number of objects, catalog entries, telescope pointings, etc., in the resource.

Coverage.SkyFraction (float)

Definition: The fraction of the sky represented in the observations, ranging from 0 to 1.

Resolution (float)

Definition: The resolution of the resource contents.

Comment: Resolution is divided into the following sub-elements:

Resolution.Spatial (float)

Definition: The spatial (angular) resolution that is typical of the observations, in decimal degrees.

Resolution.Spectral (float)

Definition: The spectral resolution that is typical of the observations, given as the ratio λ/Δλ (so that higher spectral resolution has a larger number).

Resolution.Temporal (float)

Definition: The temporal resolution that is typical of the observations, given in seconds.