instr.fov in SSAP
Stéphane Erard
stephane.erard at obspm.fr
Thu Jul 22 17:18:22 CEST 2021
> 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/
More information about the semantics
mailing list