instr.fov in SSAP

[Mireille LOUYS]

Hi Mark , Hi everyone,

I discussed  with Sebastien and Andrea about this usage of "instr.fov" .

I added some preliminary checks we did in /slanted font /for each line 
in the table provided  to understand the origin of the error usage.
( see below).

We did find "instr.fov;instr.pixel" in Vizier due to an error in a 
mapping table between UCD1 and UCD1+.
This will be corrected.

In the SSAP rec, 'instr.fov' is misused 2 times in page 66.
"instr.fov", represents an instrument characteristics projected on the sky.
It does not exist /per se/ as a physical quantity, with units etc.

It is suitable to be a qualifier,  to some measurement like
E phys.angSize  --> phys.angSize;instr.fov
Q phys.angArea --> phys.angArea;instr.fov

Other errors appear for several other fields .
we 'll check the other UCD in SSAP and propose some updates to the spec 
as an errata very soon.


Le 20/07/2021 à 10:49, Mark Taylor 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/spectra services/  appling SSAP
>>   instr.fov;instr.pixel      | 2475/most are Vizier tables : error in a translation script UCD1--> UCD1+/
>>   phys.angsize;instr.fov     |  167/appropriate usage/  and suggested by cds assigning toolhttp://cdsweb.u-strasbg.fr/UCD/cgi-bin/descr2ucd  <http://cdsweb.u-strasbg.fr/UCD/cgi-bin/descr2ucd>
>>   pos.angdistance;instr.fov  |   16/correct ucd syntax but semantically ambiguous with instr.fov : 
>> distance is not size /
>>   pos.posang;instr.fov       |   12/correct ucd syntax but check context /  
>>
>> (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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/semantics/attachments/20210901/70adacaf/attachment.html>