instr.fov in SSAP

[Stéphane Erard]

> Le 20 juil. 2021 à 10:49, Mark Taylor <m.b.taylor at bristol.ac.uk> a écrit :
> 
> 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

This one is interesting: 
both terms are S and it is apparently useful. 

>> phys.angsize;instr.fov                    |  167

Here we have Q and S

It would make sense to accept both 
instr.fov;instr.pixel 
instr.fov;phys.angsize 
in the same order - not depending on units
The simplest way is to define instr.fov as Q, which avoids messing up existing standards


>> pos.angdistance;instr.fov                 |   16
this one looks improper

>> pos.posang;instr.fov                      |   12
And this one looks reversed to me: the main term is FoV, secondary/property is orientation
Same conclusion

Stéphane

>> 
>> (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/