The VESPA infrastructure uses the IVOA registry to declare VESPA services. Each VESPA data provider has to be registered with this Registry and declare a naming authority. The naming authority is the entity responsible for declaring and maintaining declaration of services that are done under its naming authority. The ivo-id (IVOA Identifier) is a URI starting with ivo:// followed by the naming authority short name. Data services are then declared after a "/" character appended after the naming authority using a path-like structure you decide. The recommended data center framework (DaCHS) includes the procedure required to register your naming authority and your data services.

Detailed informations and guidelines on ivo-id are available on the IVOA website:

An ivo-id validator is available at GAVO: 

VESPA Guidelines for new ivo-ids

Team new to the VO concepts may find difficult to decide how to forge their first identifiers. We propose here guidelines to build your identifiers. These guidelines should help you to declare and organize future data services.

Naming Authority

The naming authority is the formal entity that is declaring and maintaining its identifiers. It is usually the data center of an institute or university. Hence, it is advised to use the data center acronym, possibly coupled with that of the hosting institute. Some examples:

Hosting InstituteData CenterNaming Authority ivoid
Observatoire de Paris-Meudon (OBSPM)Paris Astronomical Data Center (PADC)ivo://vopdc.obspm
National Aeronautics and Space Administration (NASA)High Energy Astrophysics Science Archive Research Center (HEASARC)ivo://nasa.heasarc
Instituto Nazionale di Astrofisica (INAF)Italian Center for Astronomical Archive (IA2)ivo://ia2.inaf
(several)Centre de Données de la Physique des Plasmas (CDPP)ivo://cdpp

This naming authority ivo-id will appear on all data service provided in the VO. This construction will also simplify the search of resource coming from a specific institution or project, so take some time to construct it.

Data Services

The construction of an ivo-id rely upon the naming authority it depends on. We suggest here a construction rule that is aiming at facilitating the addition of new data services, as well as facilitating there discovery.  We propose to follow a hierarchical (path-like) structure, starting from the naming authority, and cascading down to the service itself. For instance, if you want to declare an EPN-TAP service sharing data from a database called "my_database" in a "my_group" team from a "my_lab" laboratory, you would have: ivo://my_authority/my_lab/my_group/my_database/epn.

The last section of this ivo-id example (epn) indicates that you declare the EPN-TAP service for that database. This allows you to have other interfaces on that database, such as a SIAP (Simple Image Access Protocol) on, using "sia" as a final element instead of "epn".

Existing examples:




Naming Authority


IVOA Registry Descriptor

APIS EPN-TAP service Auroral Planetary Imaging and SpectroscopyOBSPM-LESIAivo://vopdc.obspmivo://vopdc.obspm/lesia/apis/epnXML


CHIANTI consists of a critically evaluated set of up-to-date atomic data





NASA dust catalogue TAP service

Cosmic dust catalog





AMDAAutomated Multi Dataset AnalysisCDPP (IRAP-CNES)ivo://cdppivo://cdpp/amdaXML
  • No labels

1 Comment

  1. As a general rule, VESPA service providers should publish from the Dachs server in their institute. This provides an ivoID automatically for each service, based on the directory structure and naming authority.
    Only in some places the process is different, namely in ObsParis (and perhaps CDPP); in such cases the naming can be ajusted arbitrarily, e.g. to follow a generic scheme that encompasses more than simply VESPA.