instr.fov in SSAP

[Mireille LOUYS]

Hi all,
I'll be away from professional emails till August 22nd and answer your 
email after this date .

Best regards and have a good summer,
Mireille

Le 22/07/2021 à 17:18, Stéphane Erard a écrit :
>
>> 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/

-- 
--
Mireille Louys,  MCF (Associate Professor)
Centre de données CDS		IPSEO, Images, Laboratoire Icube
Observatoire de Strasbourg	Telecom Physique Strasbourg
11 rue de l'Université		300, Bd Sebastien Brandt CS 10413
F- 67000-STRASBOURG		F-67412 ILLKIRCH Cedex
Tel: +33 3 68 85 24 34