Page tree
Skip to end of metadata
Go to start of metadata

Accessing the registry through TOPCAT

The use of TOPCAT is preferred. 

In TOPCAT, click on VO Menu and select the TAP Query item. 

In the TAP URL text box (bottom of the window) : http://voparis-rr.obspm.fr/tap -> Use Service. 

Then it is possible to issue ADQL queries in the next page.

How to identify a TAP service

Previous (dirty) solution

Look for tables names ending with epn_core

SELECT ivoid FROM rr.res_table WHERE table_name LIKE '%.epn_core'

This query returns 192 results, but there are duplication and redundant results. This query is thus not optimal.

Recommended solution

Search for table utypes old version (e.g., ivo://vopdc.obspm/std/epncore#schema-2.0).

It is possible to filter on the EPNcore version. This helps to avoid out-dated services, but it could be problematic at the time of minor EPN-TAP version changes. This implies that providers must upgrade their resource regularly (as well as on clients). This is to be discussed.

A query including the EPNcore version would be one of the following:

SELECT ivoid FROM rr.res_table WHERE table_utype = 'ivo://vopdc.obspm/std/epncore#schema-2.0' 

27 results

This utype is deprecated.


With DaCHS 2, the utype of epn-tap services is filled automatically with the value 'ivo://ivoa.net/std/epntap#table-2.0'

SELECT ivoid FROM rr.res_table WHERE table_utype = 'ivo://ivoa.net/std/epntap#table-2.0' 

133 results


A query matching all EPNcore versions would be: 

SELECT ivoid  FROM rr.res_table WHERE table_utype LIKE 'ivo://vopdc.obspm/std/epncore%' OR table_utype LIKE 'ivo://ivoa.net/std/epntap#table%'

which returns with 178 results at the time of writing.

For both examples, we retrieve in the same table the TAP access point (e.g., ivo://vopdc.obspm/tap/maser), as well as EPNcore services (e.g., ivo://vopdc.obspm/lesia/maser/expres/epn). The TAP servers must be removed. We can filter TAP access points out with the tr:tableaccess capability. 

Checking if services are correctly registered 

Using the previous queries, including the filter to remove TAP endpoints, we get the following query:

SELECT rr.res_table.ivoid FROM rr.res_table WHERE table_utype LIKE 'ivo://ivoa.net/std/epntap#table-2.%' AND ivoid NOT IN (SELECT rr.capability.ivoid FROM rr.capability WHERE cap_type = 'tr:tableaccess')

We obtain 93 results:


Hints for clients

Retrieve the service infos:

SELECT rr.res_table.ivoid, access_url, table_name, short_name, res_title, res_description, reference_url FROM rr.res_table NATURAL JOIN rr.resource NATURAL JOIN rr.interface WHERE table_utype = 'ivo://vopdc.obspm/std/epncore#schema-2.0' OR table_utype = 'ivo://ivoa.net/std/epntap#table-2.0' AND ivoid NOT IN (SELECT rr.capability.ivoid FROM rr.capability WHERE cap_type = 'tr:tableaccess')


Retrieve also the publisher/contact/creator/contributor: 

SELECT rr.res_table.ivoid, access_url, table_name, short_name, res_title, res_description, reference_url, role_name, base_role AS rol_name FROM rr.res_table NATURAL JOIN rr.resource NATURAL JOIN rr.interface NATURAL JOIN rr.res_role WHERE table_utype = 'ivo://vopdc.obspm/std/epncore#schema-2.0' OR table_utype = 'ivo://ivoa.net/std/epntap#table-2.0' AND ivoid NOT IN (SELECT rr.capability.ivoid FROM rr.capability WHERE cap_type = 'tr:tableaccess')
  • No labels

6 Comments

  1. There are 13 services with table_utype = ivo.//vopdc.obspm/std/epncore#schema-2.0 (with . instead of :)

    18 services with table_utype = ivo://vopdc.obspm/std/epncore/schema-2.0

    And at least one with no table_utype (ESA)

  2. Then, there is a special issue with the way tables are registered in voparis-tap-planeto: some tables do not appear, but refer to (some) other tables in the server. Searching by table name provides no answer in this case (eg, look for vvex).

    TOPCAT is able to sort this out, no idea how

  3. Even more basic: 

    Start by cleaning up the declaration of all VO services in ObsParis - must contain 'PADC'

  4. From recent EPN-TAP doc (Markus section), the correct query should be

    SELECT TOP 1000 * FROM rr.res_table where table_utype ='ivo://ivoa.net/std/epntap#table-2.0'

    Although few services are declared this way - that was previously: ivo://vopdc.obspm/std/epncore#schema-2.0


    A correct query is therefore:

    WITH epntables AS ( SELECT ivoid, table_name, table_utype FROM rr.res_table WHERE
     table_utype='ivo://vopdc.obspm/std/epncore#schema-2.0' OR table_utype LIKE 'ivo://ivoa.net/std/epntap#table-2.%')
    SELECT DISTINCT table_name, access_url, table_utype FROM epntables
    NATURAL JOIN rr.capability
    NATURAL JOIN rr.interface WHERE
    standard_id LIKE 'ivo://ivoa.net/std/tap%' AND intf_role='std'

    Which yields 33 answers as of today: some missing servers (tap-helio and tap-planeto, but also Sendai, IRAP and more, which have one of the typos in the first comment) and some services should not be there (M3 in Jacobs…)

  5. Now that the registering of tap-planeto and tap-helio is made with dachs2, associated epn-tap services are now findable using this query

  6. SELECT DISTINCT table_name, access_url, table_utype FROM ( SELECT ivoid, table_name, table_utype FROM rr.res_table WHERE
     table_utype like 'ivo://vopdc.obspm/std/epncore%' OR table_utype LIKE 'ivo://ivoa.net/std/epntap#table-2.%') as epntables
    NATURAL JOIN rr.capability
    NATURAL JOIN rr.interface WHERE
    standard_id LIKE 'ivo://ivoa.net/std/tap%' AND intf_role='std'


    to cover former versions and the ones with characters replaced