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


First thoughts about the next evolution of the protocol.

Evolution

• Add a different mixin for next minor versions (2.1 and above), preserve v2.0. Send new versions to Markus for inclusion in DaCHS

• Adapt search interface to support all versions 2 separately - should only require minor changes in queries and displays

So that all v2 can run in parallel. The latest one becomes mandatory for new services, but upgrades will not require to regenerate all services.

New minor versions therefore correspond to a required change in the mixin, ie a change in the way parameters are handled (a simple extension of possible values wouldn't usually trigger a new version, unless it seriously affects existing services).

Possible updates

So far, we've considered:

  • Using ISO strings to handle time_min & time_max (instead of Julian days, which are not recommended in IVOA) - TBC, this is actually discussed (Markus advises against time stamps because of poor ADQL support)
  • Providing spectral resolution as abs(lambda / d(lambda) ) = abs( freq / d(freq) ) (instead of d(freq) in v2.0) - discussion to be finalized with SSHADE and other spectral services (Berlin mostly)
  • Fixing target_class list - need to improve interplanetary medium vs solar wind vs interplanetary dust? There seems to be a mix up between class, name and feature/region in this case, TBC.
  • Adding "none" as a possible value for spatial_frame_type (include this in mixin, it impacts q.rd files significantly).
  • Is there something new in recent versions of DaCHS? Parameters now seem to require type conversion before numerical operations - TBC
  • Add reference RA/DEC (sky) or lon/lat (surfaces) parameters for each granule whenever relevant (to make handling in Aladin easier, in particular for MOCs)
  • Add a parameter to distringuish form from dataproduct_type (ex: dynamic spectra provided as plots). Could be ganule_type (not favorite…) with a limited list of values: data, preview (or plot…), possibly also associated_data, label, etc. Associated granules with different granule_type must have the same obs_id (granule_gid can't be used for this, because it is a free string).
  • Define possible usage for new parameter datalink_url
  • Find a way to include COOSYS in service table even when this is varying inside the table…
  • Need to add keywords in the registry to identify the science theme - to be taken from the IAU thesaurus preferably, or new value if nothing exist. Several such values can be added. Define a list of EPN-TAP services
  • One of these keywords is "Event" to tag VOevents - this will make it possible to filter EPN-TAP services gathering/archiving VOevents (we expect lots of them, and we want to be able to prefilter them very easily when looking for data - not a nerd thing, please) - this filtering will be handled in the portal.
  • Replace service_title = schema name by a parameter providing the ivoID of the service (same objective: to refer to original service in derived tables) - see EPN-TAP ticket ending 20/6/2018.
  • Fix accref usage in DaCHS / mixin (see with Markus, there was a micmac)
  • Replace cube type by other_cube? This name is misleading.



  • No labels
Write a comment…