Registering your VESPA EPN-TAP Server

EPN2020-RI

EUROPLANET2020 Research Infrastructure 

H2020-INFRAIA-2014-2015 

Grant agreement no: 654208

Document: VESPA- WP6-2-007-TD-v 0.5

Registering your VESPA EPN-TAP Server

Date: 2023-02-15

Responsible WP Leader: OBSPARIS / Stéphane Erard

Table of Contents

1. Introduction

This document presents the configuration procedure of the VESPA service installed during the first part of the tutorial. We propose here to set up the Registry configuration (Section 2), as well as a test TAP service (Section 3). 

In order to prepare the installation, here is a table to be filled with the parameters of you installation:

creator_name (2)

logo_url (3)

authority_creationDate (4)

2014-06-03T08:59:09.697573Z

authority_title

authority_shortname

authority_description

authority_url

organization_title

organization_description

organization_url

(1) This ivo-id is that of your naming authority. If your institution is not registered you should put ivo://<<authority_name>>/org (see Tutorial Part 1).
(2) May be different from the maintainer_email. Contact Name is the Data Center contact person, whereas the Creator Name is the contact for this specific server.
(3) The logo must have the following maximum dimensions: width = 120px and height = 60px.  
(4) This date must be formatted in ISO-8901, see the example caution on format. 

2. DaCHS Registry Configuration

The Registry is the Information System of the Virtual Observatory (the yellow pages where all the services are registered). We describe a way to register your "authority ID" (description of the authority managing your resources) and the services provided by DaCHS. The procedure described here (initial metadata declaration and RofR) only needs to be done once.  The registration of data services/collections is described below.

First you need to create an identifier for your naming authority ID (ivo://authority_name)

Then open the configuration file:

sudo pico /var/gavo/etc/defaultmeta.txt

...and edit it with the following lines (see Tutorial Part 1 for some keywords):

publisher: <<authority_name>>
publisherID: <<authority-ivoid>>
contact.name: <<contact_name>> 
contact.address: <<contact_address>>
contact.email: <<contact_email>>
contact.telephone: <<contact_telephone>>
creator.name: <<creator_name>>
creator.logo: <<logo_url>>
authority.creationDate: <<authority_creationDate>>
authority.title: <<authority_title>>
authority.shortName: <<authority_shortname>>
authority.managingOrg: <<my_datacenter-ivoid>>
authority.referenceURL: <<authority_url>>
authority.description: <<authority_description>>
organization.title: <<organization_title>>
organization.referenceURL: <<organization_url>>
organization.description: <<organization_description>>
site.description:<<description of your site (data centre)>>

Then you have to update the userconfig.rd file in the same directory. This file does not exist yet on a fresh installation, so you have to create it. You first need to switch to the root user, and then create the file: 

cd /var/gavo/etc/
su #root password is asked
gavo admin dumpDF //userconfig > userconfig.rd
exit

Then open the registry-interfacerecords section of the userconfig.rd file for editing

sudo pico userconfig.rd

And in the file, remove the {UNCONFIGURED} text, so that the content is:

[...]
<!-- ================================ Registry Interface ============ -->
        <STREAM id="registry-interfacerecords">
                <doc>
                        These are services and registry records for the registry interface
                        of this service.
                        Even if together with defaultmeta, this will just work, keep
                        these elements in your etc/userconfig.rd.
                        The metaString macros in here generally point into defaultmeta.
                        Replace them with whatever actual text applies to your site;  we
                        will work to do away with defaultmeta.txt.
                </doc>
                <resRec id="authority"> <!-- ivo id of the authority is overridden in
                        nonservice.NonServiceResource -->
                        <meta>
                                creationDate: \\metaString{authority.creationDate}              
                                title: \\metaString{authority.title}              
                                shortName: \\metaString{authority.shortName}          
                                subject: Authority
                                managingOrg: \\metaString{authority.managingOrg}             
                                referenceURL: \\metaString{authority.referenceURL}                 
                                identifier: ivo://\getConfig{ivoa}{authority}
                                sets: ivo_managed
                        </meta>
                        <meta name="description">
                                \\metaString{authority.description}
                        </meta>
                </resRec>

[...]

Once this is done, we can publish your registry interface, by issuing the following command:

dachs pub //services

You will probably see warning to the effect of

** WARNING: Not reloading services RD on server since no admin password available

This will declare your publishing registry, you can verify the content using  http://<<dachs-server-address>>/oai.xml

Since this is speaking a protocol (OAI-PMH) and gets it wrong, there is an error message: 

But if you click “All identifiers defined here“, you will see links to the records you will be publishing: 

At this stage, you will see a lot fewer links on your band-new publishing registry; what you should see at this point, however, are your equivalents of ivo://padc.obspm.helio – that is your claim of the authority – and the ugly identifier ending in services/registry – that is your publishing registry itself.

Read http://docs.g-vo.org/DaCHS/opguide.html#defining-basic-metadata for more details

3. Registering the DaCHS server in Registry of Registry

Go there: http://rofr.ivoa.net/regvalidate/

Enter the URL: http://<<dachs-server-address>>/oai.xml

First step on registry validation result on failed tests have to be None Found

Then a "Step 2: Register your Registry" will be proposed on the web interface with a button Register

Once your registry is inside the list of publishing registries, you have to wait at least one day for the information to be harvested and to see your service available in clients such as TOPCAT

4. Publish your TAP service data collections

Each EPN-TAP table you define is a “data collection“ to the VO; it is such data collections that people will discover when they look for data relevant to them in the VO Registry.  To make this work, you need to inform the Registry about your data collections.  Each of these data collection will refer to the TAP service, which is what clients actually talk with.

Hence, first publish your TAP service (this only needs to happen once):

dachs pub //tap

The record for the TAP service should now be visible from http://<<dachs-server-address>>/oai.xml as ivo://<your-authority>/tap.

Each of your Vespa service need to be published to be visible in Topcat, Aladin, Taphandle ....
For each service you may have in the q.rd file, into the <table> tag

<publish sets="local,ivo_managed"/>

from the directory where the q.rd is use the following command

dachs pub q
dachs serve restart

each collection will appear at http://<<dachs-server-address>>/oai.xml

5. Unregistering a service

In case you build a test service and you register it by mistake, we describe how to set this service as inactive so it will no longer be visible in the registry.

In the q.rd file defining your service, remove the line

<publish sets="local,ivo_managed"/>

make under user dachsroot the command  

dachs pub q.rd
dachs serve restart

to be sure that the declaration have been removed go to

http://<<dachs-server-address>>/oai.xml/verb=ListIdentifiers&metadataPrefix=ivo_vor

Your collection will appear in strike characters. 

6. Assessing your dataset

Depending on your dataset (just a series of files, number for data processing levels, presence of metadata, format of data, existing relational database...) various processing may be required. In order to prepare the sharing with EPN-TAP, here is a check list of what you need:

• Public access to the data files you want to share: either on your server, or on a remote server with a publicly accessible URL (e.g., at NASA/PDS or ESA/PSA).
• Metadata (relevant for EPNcore) for each file
• Preview image for each file

Select a suitable data format if the current format is recommended by VESPA.

To be Continued...