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: http://www.ivoa.net/documents/latest/IDs.html
An ivo-id validator is available at GAVO: http://dc.zah.uni-heidelberg.de/ivoidval/q/val/form
VESPA Guidelines for new
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.
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 Institute||Data Center||Naming 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.
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:
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 "
IVOA Registry Descriptor
|APIS EPN-TAP service||Auroral Planetary Imaging and Spectroscopy||OBSPM-LESIA||ivo://vopdc.obspm||ivo://vopdc.obspm/lesia/apis/epn||XML|
CHIANTI consists of a critically evaluated set of up-to-date atomic data
NASA dust catalogue TAP service
Cosmic dust catalog
|AMDA||Automated Multi Dataset Analysis||CDPP (IRAP-CNES)||ivo://cdpp||ivo://cdpp/amda||XML|
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.