instr.fov in SSAP

[Mark Taylor]

On Thu, 8 Jul 2021, Markus Demleitner wrote:

> Dear Colleagues,
> 
> SSAP 1.1 requires the UCD instr.fov on a few columns (cf. p.66 of
> https://ivoa.net/documents/SSA/20120210/REC-SSA-1.1-20120210.pdf).
> 
> Trouble is: By UCDList 1.4, instr.fov is a secondary UCD, so the
> UCD required by SSA is illegal by UCD.
> 
> How do we fix this?  I see two ways forward: Either we lift the S
> restriction on instr.fov. This would sound reasonable to me and
> obviously many others; here's a few counts from today's
> rr.table_columns:
> 
>  instr.fov                                 |  198
>  instr.fov;instr.pixel                     | 2475
>  phys.angsize;instr.fov                    |  167
>  pos.angdistance;instr.fov                 |   16
>  pos.posang;instr.fov                      |   12
> 
> (these are the most popular ones).
> 
> Or we write an erratum to SSAP changing the required UCD to, I think,
> phys.angsize;instr.fov .
> 
> Me, I don't have much of an opinion, though I have to admit I can't
> really say why there's the S on instr.fov.
> 
> 
> There is a similar problem in SLAP, where a UCD em.line is required,
> which also is S in the UCD list.  I'd be a lot more relaxed about
> that since I believe SLAP as a whole ought to make room for something
> closer to VAMDC.

My take: presumably somebody thought that it made sense to have
instr.fov and em.line as primary UCDs, so my first instinct would
be to change their designation from S (secondary) to Q (both) in
UCD1+, at least for 1.5, and maybe as an erratum to 1.4.
This approach would be less disruptive than a change to SSA/SLAP,
since only the validators have to change, not the services
or clients.

To assess whether that's sensible, can one of the UCD1+ authors
or other Semantics representative either agree that's reasonable
or present an argument that these ought not to be Primary?

(Context: future versions of taplint will check UCDs for validity
against the UCD1+ list, so there may be quite a few services that
see taplint errors reported against tables that are following
standard requirements).

Mark

--
Mark Taylor  Astronomical Programmer  Physics, Bristol University, UK
m.b.taylor at bristol.ac.uk          http://www.star.bristol.ac.uk/~mbt/