Simple Cone Search
Version 1.0
IVOA WG Internal Draft 08 September 2006
- Working Group:
- http://www.ivoa.net/twiki/bin/view/IVOA/IvoaDAL
- Editor:
- Raymond Plante
- Authors:
-
Roy Williams
Robert Hanisch
Alex Szalay
This is an IVOA Working Draft for review by IVOA members and other
interested parties.
It is a draft document and may be updated, replaced, or obsoleted by
other documents at any time. It is inappropriate to use IVOA Working
Drafts as reference materials or to cite them as other than "work in
progress."
This document was originally published as a document of the US National Virtual Observatory (NVO), available at http://us-vo.org/pubs/files/conesearch.html. This IVOA version is essentially a transcription of that document into the IVOA standards document format. Minor changes have been made sharpen the specification description where needed and to otherwise fit it into the IVOA standards context; these changes are enumerated in Appendix A. It is the intention of this document that all existing services compliant with the original NVO document will be compliant with this specification. Similarly, all future service implementations that are based on this specification are expected to be compliant with the spirit of the original NVO document and practices in the VO current at the time of this writing; thus, existing client applications should work with the new implementations without change.
Comments on this document can be sent to the Data Access Layer Working Group via dal@ivoa.net.
A list of current IVOA Recommendations and other technical documents can be found at http://www.ivoa.net/Documents/.
Cone Search represents the first and arguably the most successful "standard protocol" developed within the Virtual Observatory movement. The editor, therefore, gratefully acknowledges the work of the original authors of the Cone Search specification as well as the numerous data providers who have implemented and continue to support this protocol.
This document has been developed with support from the National Science Foundation's Information Technology Research Program under Cooperative Agreement AST0122449 with The Johns Hopkins University.
The words "MUST", "SHALL", "SHOULD", "MAY", "RECOMMENDED", and "OPTIONAL" (in upper or lower case) used in this document are to be interpreted as described in IETF standard, RFC 2119 [RFC 2119].
The Virtual Observatory (VO) is general term for a collection of federated resources that can be used to conduct astronomical research, education, and outreach. The International Virtual Observatory Alliance (IVOA) is a global collaboration of separately funded projects to develop standards and infrastructure that enable VO applications.
A Cone is a circular region on the sky defined by a sky position and a radius around that position. A Cone Search is a query for information related to a Cone. The Cone Search Protocol refers to the protocol described in this document. A Cone Search Service is a service implementation that complies with this standard.
This specification describes how a provider of an astronomical source catalog can publish that catalog to the Virtual Observatory in such a way that a simple cone search can be done. The data remains in the control of the data provider, served through a web server to the world, but the query profile and response profile are carefully controlled, as described below. It is intended that setting up this web service be simple enough that data providers will not have to spend too much time on it (their funding to support such services is typically small). At the same time, the service implementation and the data it provides can serve as a basis for more sophisticated tools.
This specification does not specify how Cone Search services are implemented, or how the data are stored or manipulated. The concern of this specification is how the data are exposed to the world through well-defined requests and responses.
This specification assumes that the data provider has already selected a catalog of astronomical sources. This catalog can be presented as a single table; it is expected that the table contains several columns.
A base URL of the form:
http://<server-address>/<path>?[<extra-GET-arg>&[...]]
where <server-address> and <path> are URI-compliant components indicating the domain address and local location path where the service is deployed. The <server-address> may end with one or more locally supported URL arguments, <extra-GET-arg>; these arguments are not recognized parts of the Cone Search protocol and thus are treated opaquely by clients of the service as part of the base URL.
Note that when it contains extra GET arguments, the base URL ends in an ampersand, &; if there are no extra arguments, then it ends in a question mark, ?.
|
Every query to a given cone search service uses the same base URL.
Constraints expressed as a list of ampersand-delimited
GET arguments of the form:
<name>=<value>
where <name> is a parameter name specified by this specification and <value> is its value. The constraints represent the query parameters which can vary for each successive query. The order of the name-parameter pairs is not significant.
The baseURL and constraint list are concatenated to form the query.
The set of query constraints must include the following parameters and interpreted by the service with stated meaning:
|
VERB is an optional parameter whose value is an integer indicating verbosity that specifies how many columns are to be returned in the resulting table, with 1 meaning the bare minimum and 3 being the full width of the resulting table, which may be hundreds of columns.
There may be other parameters in the query, but this document does not specify their meaning or usage. If a query includes an optional parameter, either one specified by this document or not, that is not supported by the service implementation, the service should must ignore that parameter.
The service must respond with an XML document in the VOTable format, that represents a table of astronomical sources whose positions are within the cone. There may also be other sources outside the cone -- the service implementor may decide on the exact search criterion used internally to the service to select the sources.
The MIME-type of the HTTP response should be text/xml. The XML content of the response must be compliant with VOTable schema, version 1.0 [VOTable v1.0].
The VOTable MUST comply with these conditions:
There must be a single RESOURCE in the VOTable, and that contains a single TABLE.
The TABLE must have FIELDS where the following UCD [UCD] values have been set. There must only be one FIELD with each of these UCDs:
Exactly one FIELD must have ucd="ID_MAIN", with the type string (fixed or variable length), representing an ID string for that record of the table. This identifier may not be repeated in the table, and it could be used to retrieve that same record again from that same table.
Exactly one FIELD must have ucd="POS_EQ_RA_MAIN", with type double, representing the J2000 right-ascension of the source.
Exactly one FIELD must have ucd="POS_EQ_DEC_MAIN", with type double, representing the J2000 declination of the source.
The VOTable may include an expression of the uncertainty of the positions given in the above mentioned fields to be interpreted either as a positional error of the source positions, or an angular size if the sources are resolved. If this uncertainty is not provided, it should be taken to be zero; otherwise, it may be set for all table entries with a PARAM in the RESOURCE which has a UCD that is set to OBS_ANG-SIZE and has a value which is the angle in decimal degrees. Alternatively, a different value for each row in the table can be given via a FIELD in the table having a UCD set to OBS_ANG-SIZE.
There may be other FIELDs in the table. Their specification should include a description, data-type, and UCD.
The service must respond with a stubbed version of the VOTable in the case of error. This must happen if the three required parameters (RA, DEC, SR) are not all present, or if their values cannot be parsed to floating-point numbers, or if the numbers are out of range (DEC=91.0, for example). The service may also make an error return if the search radius (give by the SR parameter) is larger than the MaxSR parameter of the Resource Profile (see Section 3).
In the case of error, the service MUST respond with a VOTable that contains a single parameter called Error, where the corresponding value should contain some explanation of the nature of the error.
- Editor's Note:
- It has been recognized that this requirement, as described in the original NVO specification, is ambiguous about the location of the ERROR parameter. The VOTable standard allows PARAM elements to appear as direct children of either a RESOURCE element or a DEFINITION element (below the root VOTABLE element). Since in practice, both locations have been used by Cone Search service implementations, no attempt is made in this version to correct this ambiguity. Either location should be considered legal, and Cone Search service clients should be prepared to look in both places for an ERROR parameter.
Other conditions may NOT be considered erroneous, for example if a query cone is in the Southern hemisphere and the catalog coverage is in the Northern hemisphere. This type of query is different from an error return; it should return a VOTable as described above, with metadata, but no data records. In particular, a zero value of Search Radius should not return an error condition. This is because an application may be more interested in the metadata than the data, and send a fixed query (for example RA=0&DEC=90&SR=0) simply to discover the fields delivered by the service.
A Cone Search service MUST be described with a Resource Profile that includes the following information. The Profile is composed of named metadata listed below. The format used to encode the profile should be compliant with the publishing standards of the IVOA throughout the time the service is supported by the data provider. The metadata names and values used in the profile encoding should match those given below as closely as possible; where they do not match exactly, they should be consistent with the IVOA metadata conventions in place at any given time and the mapping of names and values actually used and those given below should be well documented.
- Editor's Note:
- The original NVO specification pre-dates the IVOA standard for resource metadata [RM], and so, obviously, some inconsistencies with that standard exist. To deal with this, the wording of this section has been altered to allow profiles to be constructed according to the latest practices in the IVOA. Appendix B outlines the mapping of the metadata listed below to that in the RM as well as the XML Schema used to render the metadata within a Registry.
Several of the metadata listed below can have values that are hierarchical; this hierarchy should be represented in a manner most appropriate to the format used. When the format does not provide any such mechanism, it is recommended that the value be represented as a strings delimited by dots with the root domain of the value appearing first.
The resource profile consists of the following metadata with the stated definitions:
ResponsibleParty: The data provider's name and email.
ServiceName: The name of the catalog served by the service, for example "IRSA.2MASS.ExtendedSources".
Description: A couple of paragraphs of text that describe the nature of the catalog and its wider context.
Instrument: The instrument that made the observations, for example STScI.HST.WFPC2.
Waveband: The waveband of the observations, with ONE selected from this list: radio, infrared, optical, ultraviolet, xray, gammaray.
Epoch: The epoch of the observations, as a free-form string.
Coverage: The coverage on the sky, as a free-form string.
MaxSR: The largest search radius, given in decimal degrees, that will be accepted by the service without returning an error condition. If there is no restriction a value of 180.0 if there is no restriction.
MaxRecords: The largest number of records that the service will return.
Verbosity: True or false, depending on whether the service supports the VERB keyword in the request.
BaseURL: The base URL for the service as described in Section 2.
The service will considered published to the VO if the profile has been added to an IVOA Registry according to the IVOA standards and conventions at the time the service is made available, TOGETHER with maintaining the web service that is described by the profile in compliant order.
As mentioned in an Editor's Note in Section 3, the original NVO specification pre-dated the IVOA standard for resource metadata known as the RM [RM]. This section indicates how the resource profile metadata defined in this specification maps to the metadata defined in the RM.
1The notion of the epoch the observations is captured in the RM as the temporal coverage. The notion of the equinox of the observational positions is captured part of the RM's Coverage.Spatial.
Cone Search Metadatum RM Metadatum ResponsibleParty Publisher,
Contact.EmailServiceName Title Description Description Instrument Instrument Waveband Coverage.Spectral Epoch Coverage.Temporal.StartTime,
Coverage.Temporal.StopTime1Coverage Coverage.Spatial MaxSR Service.MaxSearchRadius MaxRecords Service.MaxReturnRecords Verbosity n/a2 BaseURL Service.BaseURL
2As this concept is not covered by the RM, it should be considered service-specific capability metadata.
Just prior to the adoption of IVOA standard for registry interfaces, v1.0 [RI], resource descriptions were encoded using the VOResource XML Schema, v0.10 and its family of extension schemas. The extensions used to specifically describe Cone Search services were VODataService, v0.5 and ConeSearch, v0.3. See the embedded documentation in each of these schemas for the precise definitions and usage of the metadata encodable through them.
The following table enumerates the mapping of resource profile metadata defined in this specification with those defined in the XML schemas.
1The notion of the epoch the observations is captured in the schema inside coverage/temporal. The notion of the equinox of the observational positions is captured within coverage/spatial/region, such as in coverage/spatial/region[@xsi:type='vs:Circle']/coordFrame.
Cone Search Metadatum VOResource Metadatum Schema Name XPath Name ResponsibleParty VOResource curation/publisher,
curation/contact/emailServiceName VOResource titleDescription VOResource content/descriptionInstrument VOResource instrumentWaveband VODataService coverage/spectral/wavebandEpoch VODataService coverage/temporal/startTime,
coverage/temporal/stopTime1Coverage VODataService coverage/spatial2MaxSR ConeSearch capability/maxSRMaxRecords ConeSearch capability/maxRecordsVerbosity ConeSearch capability/verbosityBaseURL VOResource interface/accessURL
2the coverage/spatial element encodes its information as a complex set of child elements.
With the expected adoption of the IVOA standard for Registry Interface [RI], resources are described using the VOResource schema, v1.0 [VOR] and its family of extensions. Cone Search services are specifically described using the VODataService, v1.0, and ConeSearch, v1.0, extension schemas. Coverage information is encoded using the Space-Time Coordinates (STC) schema [STC].
The following table enumerates the mapping of resource profile metadata defined in this specification with those defined in the XML schemas.
| Cone Search Metadatum | VOResource Metadatum | |
|---|---|---|
| Schema Name | XPath Name | |
| ResponsibleParty | VOResource | curation/publisher, curation/contact/email |
| ServiceName | VOResource | title |
| Description | VOResource | content/description |
| Instrument | VOResource | instrument |
| Waveband | VODataService | coverage/waveband |
| Epoch | VODataService | coverage/stc:STCResourceProfile/stc:AstroCoordArea1 |
| Coverage | VODataService | coverage/stc:STCResourceProfile/stc:AstroCoordArea1 |
| MaxSR | ConeSearch | capability/maxSR |
| MaxRecords | ConeSearch | capability/maxRecords |
| Verbosity | ConeSearch | capability/verbosity |
| BaseURL | VOResource | capability/interface[@role='std']/accessURL |
Subsequent versions of this document should include the ConeSearch extension schema as a formal part of the specification.
http://www.ietf.org/rfc/rfc2119.txt http://www.ivoa.net/Documents/REC/VOTable/VOTable-20040811.html.
http://www.ivoa.net/Documents/REC/ResMetadata/RM-20040426.htm
http://www.ivoa.net/Documents/WD/SIA/sia-20040524.html.