Spectral Energy Distribution (SED) Services
These services return data and information from the NASA/IPAC Extragalactic Database [NED] photometry collection. The SED service provides for three types of query. All queries are HTTP v1.1 GET requests and all responses are HTTP v1.1 RESPONSEs [HTTP]. The content of the responses are XML v1.1 conforming, with data and information expressed in IVOA VOTable v1.2 self-describing objects [IVOATABLE].
- The responses are intentionally labelled/declared XML v1.0 for practical compatibility with available parsers, and tools. (This conforms to [XML1] using [XML2].)
- The SSAP requires a capability to constrain/filter responses based on various parameters (BAND, TIME e.g.) that are not supported by the underlying data collection or search apparatus. These capabilities are not implemented.
- The SSAP requires format/feature negotiation services/queries which are not provided by this service.
- Spectral-Line-based values, upper– and lower– limit values are excluded to avoid confusion. (At present there is no clear and reliable way to express these qualifications using the standardized data models.)
- The query protocol used here was based upon IVOA Simple Spectral Access Protocol (SSAP) Recommendation Version 1.04 [IVOASSAP].
Queries (with Examples)
Note: THE HOSTNAME/URL used in the examples should be replaced with the hostname/url obtained from a VAO operational registry.
NED SED Information Discovery Request
The request uses two parameters: POS in which is delivered a string containing RA [decimal degrees, ICRF/FK5J2000] and DEC [decimal degrees, ICRF/FK5J2000]; and a SIZE param- eter which specifies the cone angle (degrees). This establishes a search volume that is a Circular Spherical Cone. Information returned includes a VOTable information object containing a list of NED Object Identifiers (Names), a count of photometric SED measurements available for this Object, and the URI (ACREF) for the SED Data Retrieval request (accessSED).
REQUEST is the IVOA SSAP queryData request type. This defines position proximity search around the position (POS), of angular radius (SIZE). The REQUEST, POS, and SIZE parameters are required. A maximum allowed value for SIZE is 0.1 degree is imposed to ensure acceptable performance (response time and size). Other parameters are accepted but ignored.
NED SED Info Availability Request
This is an extension of IVOA Simple Spectral Access Protocol Version 1.04. The request uses one parameter, ”targetname” and returns an information object containing the relevant NED Object Identifier (Name) of pho- tometric SED information from the archive, and a URI (ACREF) for the SED-Data- Retrieval query for archive data for the specified object. The NED photometric collection (the entire NED database) is organized around named astronomical objects and information associated with them. Therefore the most convenient means of specifying information to NED is by a conventional (NED conventions are used) object name.
This request type is a service specific extension to SSAP, providing a query by object- name (targetname). NOTE: This query is defined by this convention. The REQUEST parameter queryData is defined by SSAP.
NED SED Data Retrieval Request
This is an extension of IVOA Simple Spectral Access Protocol Version 1.04. The request uses a NED qualified object Identifier (TAR- GETNAME), and returns a modified IVOA Spectral Data Model Recommendation Version 1.03 [IVOASDM] data object in a VOTable. Evolution and refinement of the data object format an content should be expected.
The structure of the Data Retrieval responses are adapted from IVOA Spectral Data Model Recommendation Version 1.03 [IVOASDM].
NOTE, however, the data model requires information that are not available from the data source, these are omitted.
There are plans to elaborate an SED Data Model, within the context of a Photometric Data Model, and to expand the SSAP toward a convention for interrogating SEDs.
NOTE: getData responses are also in VOTable format, any FORMAT specification is ignored.
In the event of error conditions (including no available data), PARAM name="Error" is provided in the response data object with a VALUE that is a description of the problem encountered.
The ACREF in responses contains a URI for a data retrieval request. The URI may be absolute or relative. The intent is for the client to construct a URL in the conventional way [URI], using the URI of the queryData response as the basis for constructing the fully qualified URL for the getData query. The URI will generally be a path, to which the scheme (http:) and authority (//hostname.domain.root) used for the query are prepended.
NOTE: It is not clear that use of URI specifications as described conforms to the SSAP, however this a) seems a straightforward extension; and b) is eminently practical for responses that are not required to maintain integrity across multiple queries (the host serving the data could easily change between the time the data discovery query or response is made, and the time the data are actually requested; and c) is well documented [URI]. Thus a URI scheme seems more practical than a URL.
XML1 Extensible Markup Language (XML) 1.0 (Fifth Edition), (W3C Recommendation 26 November 2008 http://www.w3.org/TR/2008/PER-xml-20080205/
XML2 Namespaces in XML 1.0 (Third Edition), (W3C Recommendation 8 December 2009), http://www.w3.org/TR/xml-names/
This work is carried out by the California Institute of Technology (Caltech) under contract to the National Aeronautics and Space Administration (NASA).