- 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.
Need to clean up current doc (2.0). Utypes are = DM fields. They are supposedly used to identify the meaning of parameters and help e.g. tools to grab required quantities - This will not work in some areas though, e. g. with spectral tools as they currently use UCD instead of Utype for this purpose (not many tools appear to actually rely on Utype in fact). See discussion here for usage (a bit old?): http://www.ivoa.net/documents/Notes/UTypesUsage/20130213/NOTE-utypes-usage-1.0-20130213.html
To handle this in practice:
- Associate each parameter to a specific Utype in EPNCore - all names need to start with the epncore: prefix/namespace.
- Then map epncore Utype to other DM (find equivalent parameter, or trace back the original templates of EPNCore parameters - often from ObsCore)
- Reuse Utype from other DM each times it makes sense - TBC: the epncore: namespace is still required (even when using Utypes from other DM)
This allows tools to handle EPNCore parameters like existing parameters from other DM, i.e., with no specific implementation
Pb is that small differences in the use of parameters may preclude reusing the same Utype (TBC: does that applies to units also?)
- Cross our fingers: known Utype (from other DMs) may be usable in existing tools (e.g. a tool supporting Provenance would grab equivalent info in EPN-TAP services transparently)
Unclear if the use of the namespace makes it more complicated in tools.