IVOA Architecture¶

Official bibliographic entry for published version [IVOAArchitecture2.1].

Status:: IVOAArchitecture 2.1 EN 2024-11-14

Acknowledgments¶

1 IVOA Architecture Level 0¶

Astronomy produces large amounts of data of many kinds, coming from various sources: science space missions, ground based telescopes, theoretical models, compilation of results, etc. These data are usually managed by large data centres or smaller teams and they provide the scientific community with data and/or computing services through the Internet. This is the Resource Layer.

The “consumers” of these data and computing services, be it individual researchers, research teams or computer systems, interact with the User Layer.

The Virtual Observatory (VO) is the necessary “middle layer” framework connecting the Resource Layer to the User Layer in a seamless and transparent manner. Like the web which enables end users and machines to access documents and services wherever and however they are stored, the VO enables the astronomical scientific community to access astronomical resources wherever and however they are stored by the astronomical data and services providers. The VO provides a technical framework for the providers to enable users to discover data collections and services (“Findable”) and to use them for science and public outreach (“Accessible”). To enable these functionalities in perpetuity, it defines some core astronomically-oriented standards so data from different providers can be combined (“Interoperable”) to enable new scientific discoveries (“Reusable”).

The IVOA Architecture uses terms “Finding”, “Getting”, “Using”, and “Sharing“; these are collectively equivalent to “Findable”, “Accessible”, “Interoperable”, and “Reusable”: the FAIR principles have always been the basis of the IVOA Architecture even before the term was formally coined []. The world wide astronomy community has long supported sharing and reusability of data (e.g. through standards like FITS []). Within the IVOA community, interoperability has been the cornerstone of development of standards and the concepts of reusability and interoperability go beyond metadata and data as they also guide the development of standards for applications, services, and infrastructure for research, education, and public outreach.

2 IVOA Architecture Level 1¶

Level 1 of the IVOA architecture is an extension to the Level 0, displaying more details about the functionalities and building blocks within the different layers. For completeness, part of the description is repeated from the Level 0, so the Level 1 description can be used as a self-contained block.

Astronomy produces large amounts of data of many kinds, coming from various sources: science space missions, ground based telescopes, theoretical models, compilation of results, etc. These data are usually managed by large data centres or smaller teams. These providers provide the scientific community with data and computing services through the Internet. These resources provided can be:

data collections (images, spectra, time series, theoretical models, catalogues, etc.) with their associated descriptive metadata and access services.
storage services for users and for processing
computing services to process data from data collections and from users

This is the Resource Layer.

The “consumers” of these data and computing services, be it individual researchers, research teams or computer systems, interact with the User Layer of the IVOA architecture. These interactions can be through browser based applications in a typical web browser, standalone desktop applications or scriptable applications that can be used in interactive and batch mode by a computer.

The Virtual Observatory is the necessary “middle layer” framework that connects the Resource Layer to the User Layer in a seamless and transparent manner. Like the web that enables end users and machines to access transparently documents and services wherever and however they are stored, the VO enables the astronomical scientific community to access astronomical resources wherever and however they are stored by the astronomical data and services providers. The VO provides a technical framework for the providers and the consumers to share their data and services (“Sharing”). Registries function as the “yellow pages” of the VO, collecting metadata about data resources and information services into a queryable database. Like the VO resources and services themselves, the registry is also distributed. Replicas exist around the network, both for redundancy and for more specialized collections. Access to data and metadata collections is available through Data Access Protocols, which specify a uniform way of getting data and metadata from various different providers. To allow these functionalities, the definition of some core astronomically-oriented standards (“VO Core”) is necessary. In particular, defining common formats and data models and using common semantics is required to have a uniform and common description of astronomical datasets so they can become interoperable and queryable through standard query languages to enable cross analysis amongst various datasets. Additional standards are required within the User Layer to enable user authentication to proprietary datasets and storage elements as well as interoperability amongst VO applications (“Using”).

3 IVOA Architecture Level 2¶

Level 2 of the IVOA Architecture is similar to the Level 1, but adds all the IVOA standards in their corresponding layer. Some standards have already been approved and recommended (blue boxes with an outer line) while others are still a work in progress (blue boxes without an outer line).

Note that this list (and standard status) will naturally evolve with time. Driven by science use cases and implementation experience, existing standards will be updated and new standards will be identified and added to that Fig. IVOAArchitecture:fig:architecture2.

The following sections of this document provide a summary description of each current standard, including a description of where it fits in the overall IVOA architecture along with links with other IVOA standards. The links (arrows) in the diagrams below indicate a “used by” dependency: readers wanting to understand the full scope of a standard will also need to review the other standards represented in each box of the diagrams. The standards shown in blue boxes are the subject of the section; boxes in light gray can be found in a different section/diagram. In some cases, green boxes are used to show external standards that provide an important or notable part of the IVOA standard. A white rounded box around several standards indicates a group of standards that share dependencies (to simplify the diagrams).

4 Authentication and Authorization¶

Authentication is a process by which you verify that someone is who they claim they are. Authorization is the process of establishing if the user (who is already authenticated), is permitted to have access to a resource. The authentication and authorization architecture is primarily an endorsement of existing industry standards and technologies that suit the use cases of the IVOA community. The standards in this area provide some recommendations and “glue” so that participants (application developers, metadata and data providers, and resource providers) can easily implement interoperable systems.

Authentication and authorization are generally orthogonal to other standards and there are minimal direct dependencies on them. Implementors of other standards (e.g. Sec. 9 Data Access Standards and 10 Infrastructure Resource Standards) “combine” these A & A recommendations where necessary to support local policies and requirements.

4.1 SSO¶

The Single-Sign-On (SSO) [SSO2.0] profile describes authentication mechanisms. Approved client-server authentication mechanisms are described for the IVOA single-sign-on profile: No Authentication; HTTP Basic Authentication; TLS with passwords; TLS with client certificates; Cookies; Open Authentication; Security Assertion Markup Language; OpenID. Normative rules are given for the implementation of these mechanisms, mainly by reference to pre-existing standards.

4.2 CDP¶

The Credential Delegation Protocol (CDP) [CredentialDelegation1.0] allows a client program to delegate a user’s credentials to a service such that the service may make requests to other services in the name of that user. The protocol defines a REST service that works alongside other IVOA services to enable such a delegation in a secure manner. In addition to defining the specifics of the service protocol, the standard document describes how a delegation service is registered in an IVOA registry along with the services it supports. The specification also explains how one can determine from a service registration that it requires the use of a supporting delegation service.

4.3 GMS¶

The Group Membership Service (GMS) [GMS1.0] specification describes a service interface for determining whether a user is a member of a group. Membership information can be used to protect access to proprietary resources. When an authorization decision is needed (whether to grant or deny access to a proprietary resource), a call to GMS can be made to see if the requesting user is a member of the group assigned to protect the resource in question. Examples of proprietary resources are wide ranging but include: observation data and metadata and scarce or limited services and infrastructure. Because this specification details how a single group can protect multiple, potentially distributed, resources, it allows for the representation of teams with common authorization rights. The members of such teams can span multiple organizations but can be managed within a single service. In this way, GMS offers an interoperable, flexible, and scalable mechanism for sharing proprietary assets with a potentially dynamic set of team members.

5 Application and Format Standards¶

Application and Format Standards are focused on standards that support data formats and protocols that enable astronomy software tools to interoperate and communicate. IVOA members have recognised that building a monolithic tool that attempts to fulfil all the requirements of all users is impractical, and it is a better use of our limited resources to enable individual tools to work together better. One element of this is defining common file formats for the exchange of data between different applications. Another important component is a messaging system that enables the applications to share data and take advantage of each other’s functionality.

5.1 HiPS¶

Hierarchical Progressive Survey (HiPS) [HiPS1.0] is a hierarchical scheme for the description, storage and access of sky survey data. The system is based on hierarchical tiling of sky regions at finer and finer spatial resolution which facilitates a progressive view of a survey, and supports multi-resolution zooming and panning. HiPS uses the HEALPix tessellation of the sky as the basis for the scheme and is implemented as a simple file structure with a direct indexing scheme that leads to practical implementations.

5.2 MOC¶

The Multi-Order Coverage Map (MOC) [MOC2.0] is a method to specify coverage as an 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.

5.3 VOTable¶

The VOTable [VOTable1.4] format is an XML standard for the interchange of data represented as a set of tables. In this context, a table is an unordered set of rows, each of a uniform structure, as specified in the table description (the table metadata). Each row in a table is a sequence of table cells, and each of these contains either a primitive data type, or an array of such primitives. VOTable is derived from the Astrores format [], itself modelled on the FITS Table format []; VOTable was designed to be close to the FITS Binary Table format.

5.4 SAMP¶

The Simple Application Messaging Protocol (SAMP) [SAMP1.2] is a messaging protocol that enables astronomy software tools to interoperate and communicate. SAMP supports communication between applications on the desktop and in web browsers, and is also intended to form a framework for more general messaging requirements.

6 Semantics Standards¶

An interoperable data infrastructure needs common languages in many places: From common designations of units to labels for physical quantities, from common names of reference frames and time scales to mutually understandable subject categories, from relationship types between VO resources (“this service publishes images from A and spectra from B”) to fixed names for the messengers that produced the signals recorded.

The VO’s semantics standards provide the basis of forming such consensual “vocabularies”, which are, at their root, sets of labeled concepts (which in turn are sets of entities clients deal with). We also take care that, wherever possible, our vocabularies are interoperable with the rest of the semantic web by adopting the W3C’s Resource Description Framework RDF.

The vocabularies themselves are usually introduced by standards that use them and are then maintained on the VO’s repository of vocabularies [1]. In some cases, however, we go beyond RDF, usually because the labels have an intrinsic syntax. In these cases, the Semantics WG issues separate standards defining how to build and interpret these labels. Currently, this is the case for unit strings and for the Unified Content Descriptors discussed below.

6.1 Vocabularies¶

Vocabularies in the VO [Vocabularies2.1] describes how to build and use consensus vocabularies in the Virtual Observatory. It supports both “soft” vocabularies based on the Simple Knowledge Organisation System SKOS and “hard” vocabularies based on RDF schema, where the latter organise their concepts in strict trees. The “hard” vocabularies enable simple inference with relatively little effort on the side of the clients. An example could be “give me all links giving auxiliary data for the current dataset” in datalink, where vocabulary-aware clients will also return links tagged as weight maps, errors, or noise estimates.

This standard also details the maintenance of the VO’s vocabulary repository, in particular as regards adding vocabularies or concepts within them.

6.2 VOUnits¶

VOUnits [VOUnits1.1] describes how to serialise unit strings within the Virtual Observatory, in particular (but by no means limited to) in the attribute in VOTable. It hence defines the atomic units, prefixes applicable, and the syntax of expressions using such prefixed atomic units.

An important design goal was consistency with other standards (BIPM, ISO/IEC and the IAU) that are relevant in the astronomical community. The intention is that units written to conform to VOUnits will likely also be parsable by other well-known parsers.

6.3 UCD¶

Unified Content Descriptors (UCD) [UCDlistMaintenance2.0] are a way to denote astronomical data quantities. The UCD formalism first defines a list of “atoms”, in effect a controlled vocabulary with a hierarchy implied through dots (e.g., denotes positions, equatorial positions); this list is currently maintained as an Endorsed Note [UCD1+1.5].

The atoms can then be combined into more complex labels containing qualifications. For instance, denotes a magnitude in the V band, a flux in the same band. The UCD standard defines how these compound UCDs are built, and the UCD list defines restrictions as to where in complete UCDs atoms can be used: some atoms can only be “primary”, others are only available as qualifiers. For instance, can only appear at the start of a UCD, which ensures that “Error in redshift” will be encoded as rather than the other way round.

The UCD ecosystem is completed by another standard on how new atoms are adopted to the list of UCDs.

7 Registry Standards¶

The IVOA Registry provides a mechanism with which VO applications can discover and select resources that are relevant for a particular scientific problem. The VO specification defines the operation of this system. It is based on a general, distributed model composed of searchable and publishing registries. There are three components: (a) an interface for harvesting publishing registries, which builds upon the Open Archives Initiative Protocol for Metadata Harvesting. (b) A VOResource extension for registering registry services and description of a central list of said IVOA registry services. (c) A Registry of Registries as the root component of data discovery in the VO.

There are a number of standards associated with the registry to enable registration and discovery of services in the Registry. Figure IVOAArchitecture:fig:regdeps shows how various Registry standards relate to each other.

7.1 Identifier¶

An IVOA Resource Identifier (or IVOA identifier or IVOA ID for short) [IVOAIdentifiers2.0] is a globally unique reference to a resource represented in a compact, ASCII-text format. An IVOA identifier MUST always refer to a resource that has been registered with an IVOA-compliant registry; that is, it should be possible to use the ID to get a description of the resource from a compliant registry somewhere in the VO environment.

7.2 VOResource¶

VOResource [VOResource1.1] describes an encoding standard for IVOA Resource Metadata. The primary intended use of VOResource is to provide an XML interchange format for use with resource registries. A registry is a repository of resource descriptions and is employed by users and applications to discover resources. VOResource can be used to pass descriptions from publishers to registries and then from registries to applications. Another intended use is as a language for services to describe themselves directly.

7.3 VODataService¶

The VODataService ref standard makes discovery possible. It is an encoding standard that enables one to describe how the data underlying the resource covers the sky as well as their frequency and time. VODataService also enables detailed descriptions of tables that include information useful to the discovery of tabular data.

7.4 Registry Interface¶

The Registry Interface [RegistryInterface1.1] defines the interfaces that support interactions between applications and registries as well as between the registries themselves. It is based on a general, distributed model composed of searchable and publishing registries. The specification has two main components: (a) an interface for searching and (b) an interface for harvesting. Finally, the Registry Interface details the metadata used to describe registries themselves as resources using an extension of the VOResource metadata schema.

7.5 Resource Metadata¶

The Resource Metadata [RM1.1] standard represents the essential capability to describe 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.

7.6 RegTAP¶

The Registry Relational Schema for Table Access Protocol (RegTAP) [RegTAP1.1] provides 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.

7.7 SimpleDALRegExt¶

Describing Simple Data Access Services (SimpleDALRegExt) [SimpleDALRegExt1.2] is part of the registry standards that make discovery of Simple DAL services possible (e.g., SIAP, SCS, SSAP, SLAP). SimpleDALRegExt refers to an encoding standard for a specialized extension of the IVOA Resource Metadata that is useful for describing VO Simple DAL Services. By registering a VO Application in a Registry, it gets a unique IVOA Resource Identifier which then can be referred to by other applications and services.

7.8 StandardsRegExt¶

The Standards registry extension (StandardsRegExt) [StandardsRegExt1.0] is part of the registry standards that make discovery of VO Standards possible. StandardsRegExt refers to an encoding standard for a specialized extension of the IVOA Resource Metadata that is useful for describing a VO Standard. By registering an IVOA Standard in a Registry, it gets a unique IVOA Resource Identifier which then can be referred to in other resource descriptions, namely for services that support the standard.

7.9 TAPRegExt¶

The Table Access Protocol registry extension (TAPRegExt) [TAPRegExt1.0] is part of the registry standards that make discovery of VO TAP Services possible. TAPRegExt refers to an encoding standard for a specialized extension of the IVOA Resource Metadata that is useful for describing VO Applications. By registering a VO TAP Service in a Registry, it gets a unique IVOA Resource Identifier which then can be referred to by other applications and services. In the context of registering TAP services, an important role filled by TAPRegExt is the communication of supported data models to the registry.

8 Data Model Standards¶

The key element for achieving interoperability among actors sharing data is the definition of shared standard data models. Shared data models enable rich and robust information sharing between heterogeneous providers and users through a standard structure, semantics, and formats; data models are the foundation for this exchange.

8.1 VO-DML¶

The VO Data Modelling Language (VO-DML) [VODML1.0] defines a standard modelling language, or meta-model, for expressing data models in the IVOA. Adopting such a uniform language for all models allows these to be used in a homogeneous manner and allows a consistent definition of reuse of one model by another. The particular language defined here includes a consistent identification mechanism for model which allows these to be referenced in an explicit and uniform manner also from other contexts, in particular from other IVOA standard formats such as VOTable. The language defined in this specification is named VO-DML (VO Data Modelling Language). VO-DML is a conceptual modelling language that is agnostic of serializations, or physical representations. This allows it to be designed to fit as many purposes as possible. VO-DML is directly based on UML, and can be seen as a particular representation of a UML2 Profile. VO-DML is restricted to describing static data structures and from UML it only uses a subset of the elements defined in its language for describing “Class Diagrams”. Its concepts can be easily mapped to equivalent data modelling concepts in other representations such as relational databases, XML schemas and object-oriented computer languages. VO-DML has a representation as a simple XML dialect named VO-DML/XML that must be used to provide the formal representation of VO data models. VO-DML/XML aims to be concise, explicit and easy to parse and use in code that needs to interpret annotated data sets. VO-DML as described in this document is an example of a domain specific modelling language, where the domain here is defined as the set of data and meta-data structures handled in the IVOA and Astronomy at large. VO-DML provides a custom representation of such a language and as a side effect allows the creation and use of standards compliant data models outside of the IVOA standards context.

8.2 MIVOT¶

The Model Instances in VOTables (MIVOT) [MIVOT1.0] defines a syntax to map VOTable data to any model serialized in VO-DML. The annotation operates as a bridge between the data and the model. It associates the column/param metadata from the VOTable to the data model elements (class, attributes, types, etc.) of a standardized IVOA data model, expressed in the Virtual Observatory Data Modeling Language (here after VO-DML). It also brings up VOTable data or metadata that were possibly missing in the table metadata. The data model elements are grouped in an independent annotation block complying with the MIVOT XML syntax. This annotation block is added as an extra resource element at the top of the VOTable result resource. The MIVOT syntax allows to describe a data structure as a hierarchy of classes. It is also able to represent relations and composition between them. It can also build up data model objects by aggregating instances from different tables of the VOTable. Missing metadata can also be provided using MIVOT, for instance by completing coordinate system description, or by providing curation tracing. The annotation block is made of re-usable bricks that facilitate the development of tools on both client and server sides. The adopted design does not alter the original VOTable content. The backward compatibility is preserved thanks to the limited impact of the annotations on legacy clients.

8.3 CharDM¶

The Characterisation Data Model (CharDM) [CharacterisationDM1.1a] defines the high level metadata necessary to describe the physical parameter space of observed or simulated astronomical data sets, such as 2D-images, data cubes, X-ray event lists, and IFU data. This model is an abstraction which can be used to derive a structured description of any relevant data and thus to facilitate its discovery and scientific interpretation. The model aims at facilitating the manipulation of heterogeneous data in any VO framework or portal. A VO Characterisation instance can include descriptions of the data axes, the range of coordinates covered by the data, and details of the data sampling and resolution on each axis. These descriptions should be in terms of physical variables, independent of instrumental signatures as far as possible.

8.4 ObsCoreDM¶

The Observation Data Model Core Components (ObsCoreDM) [ObsCore1.1] specifies the metadata 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 modelling and data access aspects in a single service named ObsTAP that will be referenced as such in the IVOA registries. 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 a reasonable cost of implementation by data providers. As with most of the VO Data Models, ObsCoreDM makes use of STC, Utypes, VOUnits and UCDs. The ObsCoreDM can be serialized as a VOTable. ObsCoreDM makes reference to more complete data models such as Characterisation DM, Spectrum DM or Simple Spectral Line Data Model (SSLDM). The 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.

8.5 PhotDM¶

The Photometry Data Model (PhotDM) [PHOTDM1.1] describes photometry filters, photometric systems, magnitude systems, zero points and its interrelation with the other IVOA data models through a simple data model. Particular attention is given necessarily to optical photometry where specifications of magnitude systems and photometric zero points are required to convert photometric measurements into physical flux density units.

8.6 ProvenanceDM¶

The Provenance Data Model [ProvenanceDM1.0] describes how provenance information can be modelled, stored and exchanged within the astronomical community in a standardized way. We follow the definition of provenance as proposed by the W3C, i.e. that “provenance is information about entities, activities, and people involved in producing a piece of data or thing, which can be used to form assessments about its quality, reliability or trustworthiness”. Such provenance information in astronomy is important to enable any scientist to trace back the origin of a dataset (e.g. an image, spectrum, catalog or single points in a spectral energy distribution diagram or a light curve), a document (e.g. an article, a technical note) or a device (e.g. a camera, a telescope), learn about the people and organizations involved in a project and assess the reliability, quality as well as the usefulness of the dataset, document or device for her own scientific work.

8.7 SimDM¶

The Simulation Data Model (SimDM) [SimDM1.0] describes numerical computer simulations of astrophysical systems. The primary goal of this standard is to support discovery of simulations by describing those aspects of them that scientists might wish to query on, i.e. it is a model for meta-data describing simulations. This document does not propose a protocol for using this model. IVOA protocols are being developed and are supposed to use the model, either in its original form or in a form derived from the model proposed here, but more suited to the particular protocol.

8.8 SSLDM¶

The Simple Spectral Lines Data Model (SSLDM) [SSLDM1.0] describes spectral line transitions. The main objective of the model is to integrate with and support the Simple Line Access Protocol, with which it forms a compact unit. This integration allows seamless access to Spectral Line Transitions available worldwide in the VO context. This model does not provide a complete description of Atomic and Molecular Physics, which scope is outside of this document. In the astrophysical sense, a line is considered as the result of a transition between two energy levels. Under the basis of this assumption, a whole set of objects and attributes have been derived to define properly the necessary information to describe lines appearing in astrophysical contexts.

8.9 SpectralDM¶

The Spectral Data Model [SpectrumDM1.2] describes the structure of spectrophotometric datasets with spectral and temporal coordinates and associated metadata. This data model may be used to represent spectra, time series data, segments of SED (Spectral Energy Distributions) and other spectral or temporal associations.

8.10 VOEvent¶

The VOEvent model [VOEvent2.0] defines the content and meaning of a standard information packet for representing, transmitting, publishing and archiving information about a transient celestial event, with the implication that timely follow-up is of interest. The objective is to motivate the observation of targets-of-opportunity, to drive robotic telescopes, to trigger archive searches, and to alert the community. VOEvent is focused on the reporting of photon events, but events mediated by disparate phenomena such as neutrinos, gravitational waves, and solar or atmospheric particle bursts may also be reported.

Structured data is used, rather than natural language, so that automated systems can effectively interpret VOEvent packets. Each packet may contain zero or more of the “who, what, where, when, how” of a detected event, but in addition, may contain a hypothesis (a “why”) regarding the nature of the underlying physical cause of the event. Citations to previous VOEvents may be used to place each event in its correct context. Proper curation is encouraged throughout each event’s life cycle from discovery through successive follow-ups. VOEvent packets gain persistent identifiers and are typically stored in databases reached via registries. VOEvent packets may therefore reference other packets in various ways. Packets are encouraged to be small and to be processed quickly. This standard does not define a transport layer or the design of clients, repositories, publishers or brokers; it does not cover policy issues such as who can publish, who can build a registry of events, who can subscribe to a particular registry, nor the intellectual property issues.

8.11 STC¶

The Space-Time Coordinate (STC) [STC1.3] metadata for the Virtual Observatory describes the coordinate axes of astronomical data. It details the various components, highlights some implementation considerations, presents a complete set of UML diagrams, and discusses the relation between STC and certain other parts of the Data Model. Two serializations are discussed: XML (STC-X) and ascii string (STC-S); the former is an integral part of the model.

8.12 Coordinates¶

The Coordinates Data Model [Coords1.0] covers the following concepts: description of single and multi-dimensional coordinate space and coordinates within that space, coordinate frames providing metadata describing the origin and orientation of the coordinate space, the definition of simple domain-specific coordinate types for the most common use cases, and description of the coordinate systems domain space. This model is a refactored subset of the original STC data model.

8.13 Measurements¶

The Measurements Data Model [Meas1.0] covers the description of measured or determined astronomical data to enable the association of the determined “value” with corresponding errors. In this model, the “value” is given by the various coordinate types of the coordinates data model plus a description of the error model. This model is a refactored subset of the original STC data model.

8.14 ObsLocTAP¶

The Observation Locator Table Access Protocol (ObsLocTAP) [ObsLocTAP1.0] defines a data model for scheduled observations and a method to run queries over compliant data, using several Virtual Observatory technologies. The data model builds on the ObsCore data model, removing elements associated with dataset access that are not available during the planning phase. In this way, this standard is focused on access to metadata related to the planning of a certain observatory, more than on access to the scientific data products. Also, the data model will be focused on discovery of planned observations, which is very useful information for multi-wavelength coordination observations, re-planning information propagation, follow-up of Targets of Opportunity alerts, preparation of proposals, etc. As with ObsCore, a serialisation into a relational table is defined, which allows users to run complex queries using the IVOA Table Access Protocol. The document also prescribes how to register and discover ObsLocTAP services.

9 Data Access Standards¶

The data access standards define APIs for querying and accessing data holdings. These standards are primarily implemented by data providers so that the community can use agreed and shared tools to interact with the data holdings.

As shown in Fig. IVOAArchitecture:fig:daldeps, the interconnection of data access standards is quite complicated, even without showing the general VO landscape dependencies. This is due to two main factors: older standards not yet updated to rely on DALI (Sec. 9.3 DALI) and protocols providing simple access (parametric query solutions) to relational tablesets (also supported by TAP, Sec. 9.10 TAP).

Supporting the data access standards, we also have the following standards and specific cases:

ADQL: a SQL-based language to allow querying of relational databases, including support for astronomy operations;
VTP: a specific transport protocol to broadcast VOEvent messages;
SimDAL: a dedicated access protocol, using SimDM structure and concepts to allow access to simulated data collections.

9.1 ADQL¶

The Astronomical Data Query Language (ADQL) ref has been developed based on SQL92. This document describes the subset of the SQL grammar supported for querying relational tablesets within the VO. Special restrictions and extensions to SQL92 have been defined in order to support generic and astronomy specific operations.

9.2 ConeSearch¶

The (simple) Cone Search (SCS) ref API specification defines a simple query protocol for retrieving records from a catalog of astronomical sources. The query describes sky position and an angular distance, defining a cone on the sky. The response returns a list of astronomical sources from the catalog whose positions lie within the cone, formatted as a VOTable.

9.3 DALI¶

The Data Access Layer Interface (DALI) ref defines the base web service interfaces common to all Data Access Layer (DAL) services. This standard defines the behaviour of common resources, the meaning and use of common parameters, success and error responses, and DAL service registration. The goal of this specification is to define the common elements that are shared across DAL services in order to foster consistency across concrete DAL service specifications and to enable standard re-usable client and service implementations and libraries to be written and widely adopted.

9.4 DataLink¶

The DataLink [DataLink1.1] API specification describes the linking of data discovery metadata to the data itself, further detailed metadata, related resources, and to services that perform operations on the data. The web service capability supports a drill-down into the details of a specific dataset and provides a set of links to the dataset file(s) and related resources. This specification also includes a VOTable-specific method of providing descriptions of one or more services and their input(s), usually using parameter values from elsewhere in the VOTable document. Providers are able to describe services that are relevant to the records (usually datasets with identifiers) by including service descriptors in a result document.

9.5 SIA¶

The Simple Image Access (SIA) [SIA2.0] protocol provides capabilities for the discovery, description, access, and retrieval of multi-dimensional image datasets, including 2-D images as well as datacubes of three or more dimensions. SIA data discovery is based on the ObsCore Data Model, which primarily describes data products by the physical axes (spatial, spectral, time, and polarization). Image datasets with dimension greater than 2 are often referred to as datacubes, cube or image cube datasets and may be considered examples of hypercube or n-cube data. In this document the term “image” refers to general multi-dimensional datasets and is synonymous with these other terms unless the image dimensionality is otherwise specified. SIA provides capabilities for image discovery and access. Data discovery and metadata access (using ObsCoreDM) are defined here. The capabilities for drilling down to data files (and related resources) and services for remote access are defined elsewhere, but SIA also allows for direct access to retrieval.

9.6 SimDAL¶

The Simulation Data Access Layer (SimDAL) [SimDAL1.0] protocol defines a set of resources and associated actions to discover and retrieve simulations and numerical models in the Virtual Observatory. SimDAL and the Simulation Data Model are dedicated to cover the needs for the publication and retrieval of any kind of simulations: N-body or MHD simulations, numerical models of astrophysical objects and processes, theoretical synthetic spectra, etc… SimDAL is divided in three parts. First, SimDAL Repositories store the descriptions of theoretical projects and numerical codes. They can be used by clients to discover theoretical services associated with projects of interest. Second, SimDAL Search services are dedicated to the discovery of precise datasets. Finally, SimDAL Data Access services are dedicated to retrieve the original simulation output data, as plain raw data or formatted datasets cut-outs. To manage any kind of data, eventually large or at high-dimensionality, the SimDAL standard lets publishers choose any underlying implementation technology.

9.7 SLAP¶

The Simple Line Access Protocol (SLAP) [SLAP1.0] is an IVOA data access protocol which defines a protocol for retrieving spectral lines coming from various Spectral Line Data Collections through a uniform interface within the VO framework. These lines can be either observed or theoretical and will be typically used to identify emission or absorption features in astronomical spectra. It makes use of the Simple Spectral Line Data Model to characterize spectral lines through the use of utypes. The SLAP interface is meant to be reasonably simple to implement by service providers. A basic query will be done in a wavelength range for the different services. The service returns a list of spectral lines formatted as a VOTable. Thus, an implementation of the service may support additional search parameters (some which may be custom to that particular service) to more finely control the selection of spectral lines. The specification also describes how the search on extra parameters has to be done, making use of the support provided by the Simple Spectral Line Data Model

9.8 SSAP¶

The Simple Spectral Access Protocol (SSAP) [SSA1.1] defines a uniform interface to remotely discover and access one dimensional spectra. SSA is a member of an integrated family of data access altogether comprising the Data Access Layer (DAL) of the IVOA. SSA is based on a more general data model capable of describing most tabular spectrophotometric data, including time series and spectral energy distributions (SEDs) as well as 1-D spectra; however the scope of the SSA interface as specified in this document is limited to simple 1-D spectra, including simple aggregations of 1-D spectra. The form of the SSA interface is simple: clients first query the global resource registry to find services of interest and then issue a data discovery query to selected services to determine what relevant data is available from each service; the candidate datasets available are described uniformly in a VOTable format document which is returned in response to the query. Finally, the client may retrieve selected datasets for analysis. Spectrum datasets returned by an SSA spectrum service may be either precomputed, archival datasets, or they may be virtual data which is computed on the fly to respond to a client request. Spectrum datasets may conform to a standard data model defined by SSA, or may be native spectra with custom project-defined content. Spectra may be returned in any of a number of standard data formats. Spectral data is generally stored externally to the VO in a format specific to each spectral data collection; currently there is no standard way to represent astronomical spectra, and virtually every project does it differently. Hence spectra may be actively mediated to the standard SSA-defined data model at access time by the service, so that client analysis programs do not have to be familiar with the idiosyncratic details of each data collection to be accessed.

9.9 SODA¶

The Server-side Operations for Data Access (SODA) [SODA1.0] is an API for low-level data access or server side data processing. The initial version describes operations for extracting a subsection of a data file using astronomical coordinates; Future evolution is expected to include performing various kinds of operations: transformations, pixel operations, and applying functions to the data.

9.10 TAP¶

The Table Access Protocol (TAP) ref defines a service protocol for accessing general table data, including astronomical catalogs as well as general database tables. Access is provided for both database and table metadata as well as for actual table data. This version of the protocol includes support for multiple query languages, including queries specified using the Astronomical Data Query Language within an integrated interface. It also includes support for both synchronous and asynchronous queries. Special support is provided for spatially indexed queries using the spatial extensions in ADQL. A multi-position query capability permits queries against an arbitrarily large list of astronomical targets, providing a simple spatial cross-matching capability. More sophisticated distributed cross-matching capabilities are possible by orchestrating a distributed query across multiple TAP services.

9.11 EPN-TAP¶

The EPN-TAP protocol [EPNTAP2.0] defines a service protocol for describing and accessing data related to the study of the Solar System in general, including observational, modeled, and experimental data. It consists of 1) the usual TAP mechanism; 2) the EPNcore metadata dictionary; 3) a set of rules defining table structure and parameter usage. EPN-TAP relies on the TAP standard (Sec. 9.11 EPN-TAP) with no modification. All EPN-TAP services are accessible through standard TAP clients.

9.12 VTP¶

The VOEvent Transport Protocol (VTP) [VOEventTransport2.0] formalizes a TCP-based protocol for VOEvent transportation that has been in use by members of the VOEvent community for several years and discusses the topology of the event distribution network. It is intended to act as a reference for the production of compliant protocol implementations.

10 Infrastructure Resource Standards¶

Infrastructure resource standards define or sanction APIs and formats to support for access to shared resources: computing, storage, and science platforms. These standards borrow from or sanction industry standards or provide a common abstraction for users that can be implemented on top of industry standard infrastructure.

10.1 PDL¶

The Parameter Description Language (PDL) [PDL1.0] defines a language where parameters are described in a rigorous data model. With no loss of generality, we will represent this data model using XML. It intends to be a expressive language for self-descriptive web services exposing the semantic nature of input and output parameters, as well as all necessary complex constraints. PDL is a step forward towards true web services interoperability.

10.2 UWS¶

The Universal Worker Service (UWS) [UWS1.1] pattern defines how to manage asynchronous execution of jobs on a service. Any application of the pattern defines a family of related services with a common service contract. Possible uses of the pattern are also described.

10.3 VOSI¶

This VO Service Interface (VOSI) [VOSI1.1] describes the minimum interface that a web service requires to participate in the world-wide network of VO services. Note that this is not required of standard VO services developed prior to this specification, although uptake is strongly encouraged on any subsequent revision. All new standard VO services, however, must feature a VOSI-compliant interface.

10.4 VOSpace¶

The VOSpace [VOSpace2.1] API defines an interface to distributed storage. This specification presents the second RESTful version of the interface. It specifies how VO agents and applications can use network attached data stores to persist and exchange data in a standard way.

11 Acronym Lookup Table¶

Acronym	Expansion
ADQL	Astronomical Data Query Language - standard
API	Application programming Interface
CDP	Credential Delegation Protocol - standard
CharDM	Characterisation Data Model - standard
ConeSearch	Cone Search - simple positional search service standard
Coords	Coordinates - astronomical coordinates standard
DALI	Data Access Layer Interface - common components standard
DataLink	Data Link - linking metadata to data standard
EPN-TAP	Solar System Table access protocol
GMS	Group Membership Service - standard
HiPS	Hierarchical Progressive Survey - standard
Identifier	Identifier standard for URI(s) with the “ivo” scheme
IVOA	International Virtual Observatory Alliance
Meas	Measurements - astronomical measurements standard
MIVOT	MIVOT - model instances in VO tables
MOC	Multi-Order Coverage - metadata standard
ObsCoreDM	Observation Core Data Model - standard
ObsLocTAP	Observation Locator (relational model) for TAP - standard
PDL	Parameter Description Language - standard
PhotDM	Photometry Data Model - standard
PR	Proposed Recommendation - the “proposed” status for standards
ProvenanceDM	Provenance Data Model - standard
REC	Recommendation - the final “recommended” status for standards
Registry Interface	Registry Interface - standard
RegTAP	Registry (relational model) for TAP - standard
Resource Metadata	Resource Metadata - model/serialisation standard
SAMP	Simple Application Messaging Protocol - standard
SIA	Simple Image Access - standard
SIAP	Simple Image Access Protocol - see SIA
SimDAL	Simulation Data Access Layer - standard
SimDM	Simulation Data Model - standard
SimpleDALRegExt	Simple Data Access Layer Registry Extension - standard
SLAP	Simple Line Access Protocol - standard
SODA	Server-side Operations for Data Access - standard
SpectralDM	Spectral Data Model - standard
SSAP	Simple Spectral Access Protocol - standard
SSLDM	Simple Spectral Line Data Model - standard
SSO	Single Sign On - standard
StandardsRegExt	Standards Registry Extension - standard
STC	Space Time Coordinates - standard
TAP	Table Access Protocol - standard
TAPRegExt	Table Access Protocol Registry Extension - standard
UCD	Universal Content Descriptor - standard
URI	Universal Resource Identifier - standard
UWS	Universal Worker service - standard
Vocabularies	Vocabularies standard for the IVOA
VODataService	Virtual Observatory Data Service service metadata - standard
VO-DML	Virtual Observatory Data Modelling Language - standard
VOEvent	Virtual Observatory Event - standard
VOResource	Virtual Observatory Resource - metadata standard
VOSI	Virtual Observatory Support Interfaces - common components standard
VOSpace	Virtual Observatory Space - user storage standard
VOTable	Virtual Observatory Table - standard
VOUnits	Virtual Observatory Units - standard
VTP	VOEvent Transport Protocol - standard
WD	Working Draft - early “draft” status for standards