Registries provide a mechanism with which VO applications can discover and
select resources - first and foremost data and services - that are relevant for
a particular scientific problem. This specification defines an interface for
searching this resource metadata based on the IVOA's TAP protocol. It specifies
a set of tables that comprise a useful subset of the information contained in
the registry records, as well as the table's data content in terms of the XML
VOResource data model. The general design of the system is geared towards
allowing easy authoring of queries.
TITAN is a computer program for calculating the interactions of a dilute plane-parallel medium with electromagnetic radiation. It includes all atomic processes: absorption, recombination, diffusion, excitation, deexcitation of atoms and ions, heating and cooling of the gas, and it solves the radiation transfer, in order to obtain the spectra reemitted by the medium. It handles plan parallel slabs in non LTE steady state, for various physical conditions and various illuminations, valid in many astrophysical situations. It is specifically designed for warm-hot (8000 to 10**8 K) and thick media (till an electron scattering optical depth of several tens) emitting and absorbing in the X-ray range (density from 10**5 to 10**14 cm-3). It computes the physical parameters, ionisation degrees, temperature, density, and the spectrum of the radiated light in each point of the slab, by solving simultaneously the ionisation equations, the equations of statistical equilibrium, the thermal equations and the radiation transfer, using iteration processes.
The Multi-Order Coverage map method (MOC) is dedicated to specify arbitrary sky regions.
The goal is to be able to provide a very fast comparison mechanism between coverage maps.
The mechanism is based on the HEALPix sky tessellation algorithm.
It is essentially a simple way to map regions of the sky into hierarchically
grouped predefined cells.
Observation Data Model Core Components
and its Implementation in the Table Access Protocol
Date:
10 May 2017 08:00:00
Publisher:
IVOA
Description:
This document defines the core components of the Observation data model
that are necessary to perform data discovery when querying data centers
for astronomical observations of interest. It exposes use-cases to be carried out,
explains the model and provides guidelines for its implementation as a data access
service based on the Table Access Protocol (TAP).
It aims at providing a simple model easy to understand and to implement by data
providers that wish to publish their data into the Virtual Observatory. This
interface integrates data modeling and data access aspects in a single service and
is named ObsTAP. It will be referenced as such in the IVOA registries.
In this document, the Observation Data Model Core Components (ObsCoreDM) defines
the core components of queryable metadata required for global discovery of
observational data. It is meant to allow a single query to be posed to TAP
services at multiple sites to perform global data discovery without having to
understand the details of the services present at each site. It defines a minimal
set of basic metadata and thus allows for a reasonable cost of implementation by
data providers. As with most of the VO Data Models, ObsCoreDM makes use of STC,
Utypes, Units and UCDs. The ObsCoreDM can be serialized as a VOTable. ObsCoreDM
can make reference to more complete data models such as Characterisation DM,
Spectrum DM or Simple Spectral Line Data Model (SSLDM). ObsCore shares a large set
of common concepts with DataSet Metadata Data Model (Cresitello-Dittmar et al. 2016)
which binds together most of the data model concepts from the above models in a
comprehensive and more general frame work. This current specification on the
contrary provides guidelines for implementing these concepts using the TAP protocol
and answering ADQL queries. It is dedicated to global discovery.
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.
Shomydl shows Datalink_ documents in a web browser using the
`XSLT used in DaCHS`_. It is meant to give authors of such documents
an idea of how clients would interpret their document.
.. _Datalink: http://ivoa.net/documents/DataLink/
.. _XSLT used in DaCHS: https://github.com/msdemlei/datalink-xslt
