UCD problem in SSA/SpectrumDM

[Keith Noddle]

Hi Doug,

To start with your last point first, "I'm not sure there's an IVOA 
position" is the honest answer. Standard practice would dictate that a 
minor revision must be backwards compatible with earlier versions whilst 
a major revision can break that rule. However, I would qualify that and 
propose that any change that breaks backwards compatibility should be 
flagged (i.e. marked as deprecated) in a preceding minor revision. Minor 
revisions would need to go through the review and recommendation 
processes but it ought to be more of a rubber stamp than anything else; 
it's no big thing, but a procedural device I believe we would do well to 
observe.

So, with that observation made, the changes that I have heard mentioned 
do seem to fall into the Minor Revision category. I would need to check, 
but I don't think Alberto's proposal breaks anything and the refactoring 
of data models etc amounts to what a good friend of mine refers to as 
"software gardening" - i.e. tidying, reorganizing, eliminating 
duplication and uncertainties etc. I'm gathering some ideas with 
Mireille and will post them soon - all suggestions welcome.

Keith.

> If we are going to be having a minor update of these documents there
> are probably some other things which should go in as well that people
> have brought up during the initial implementations and which we have
> been saving for the next version.  The fix that Alberto mentions is
> simple enough but we should be careful about broader data model changes
> (e.g. to re-align the data model with the more recent version of Char)
> as these will affect existing implementations.  If the changes are
> significant we might better defer them to a 2.0 version.  In some
> cases Spectrum did things slightly different than Char (e.g. the
> detailed usage of STC I think) for what may still be valid reasons.
> I don't think we should rule out possible minor changes to Char as
> well, since after all both are RECs.
> 
> What is the policy for minor document updates?  Can we just put out
> a 1.0x for a published recommendation?
> 
>     - Doug
> 
> 
> On Fri, 20 Nov 2009, Keith Noddle wrote:
> 
>> Hi Alberto,
>>
>> Following Bruno's recent evaluation of the SSA document highlighting 
>> among other things a disconnect between the spectrum data model 
>> defined in SSA and that of the Data Model WG, Mireille and I plan to 
>> review SSA and see what can be done to reconcile this and other 
>> issues. We will obviously include your observations below in such an 
>> exercise!
>>
>> Keith.
>>
>>>
>>> Dear DAL chair,
>>>
>>> I'd like to mention a little but annoying problem with
>>> the instrument bandpass as defined in:
>>>
>>> - Spectrum DM
>>> - SSA v1.04
>>> - ssap-keywords.xls
>>>
>>> (see below all references in those documents to the instr.bandpass UCD)
>>>
>>>
>>> The problem is that the the wrong UCD is assigned to the central 
>>> wavelength of the bandpass.
>>>
>>> All documents mention the UCD "instr.bandpass" for the field 
>>> identified by utype:
>>> Char.SpectralAxis.Coverage.Location.Value
>>>
>>> This is wrong because the central wavelength of a bandpass is a 
>>> wavelength, not a bandpass.
>>> The correct UCD should therefore be:
>>>
>>> em.wl.central;instr.bandpass
>>>
>>>
>>> and not just instr.bandpass.
>>>
>>>
>>> How easy would be to ammend the SSA document with such an easy change?
>>>
>>>
>>> (Without going into too many details, the fact that instr.bandpass is 
>>> instead used
>>> for a numeric field (central wavelength) makes the SSA validator fail 
>>> the test
>>> for the ESO SSA service, but that is a different issue that I will 
>>> address within
>>> a different forum. The problem here is that a wrong UCD is used.).
>>>
>>> Many thanks,
>>>
>>> Alberto
>>>
>>> PS: All references to instr.bandpass in the mentioned documents:
>>>
>>>
>>> Appendix D: SSA Data Model Summary:
>>> -----------------------------------
>>>
>>> DataID.Bandpass | instr.bandpass | Band as in RSM Coverage.Spectral | 
>>> char | * |
>>> Char.SpectralAxis.Coverage.Location.Value  |  instr.bandpass |  
>>> Spectral coord value |  double *** wrong UCD
>>> Char.SpectralAxis.Coverage.Bounds.Extent   | instr.bandwidth   | 
>>> Width of spectrum |  double
>>>
>>> IVOA Spectral Data Model:
>>> -------------------------
>>>
>>> Spectrum.DataID.Bandpass | instr.bandpass | Band, consistent with RSM 
>>> Coverage.Spectral | OPT | UNKNOWN |
>>> Spectrum.Char.SpectralAxis.Coverage.Location.Value | instr.bandpass | 
>>> Spectral coord value | MAN |     <PARAM ID="SpectralLocation" 
>>> datatype="double" name="SpectralLocation" ucd="instr.bandpass" 
>>> utype="spec:Spectrum.Char.SpectralAxis.Coverage.Location.Value"
>>>  value="6515.408759029946">
>>>
>>>
>>>
>>> ssap-keywords.xls spreadsheet:
>>> ------------------------------
>>>
>>> Bandpass         Spectrum.DataID.Bandpass  instr.bandpass  Band as in 
>>> RSM Coverage.Spectral   SPECBAND  char * q                   
>>> SpectralLocation Spectrum.Char.SpectralAxis.Coverage.Location.Value  
>>> instr.bandpass Spectral coord value    SPEC_VAL        
>>> double           m    q
>>>
>>>
>>
>>
>>
>> -- 
>> Keith Noddle                    Phone:  +44 (0)116 223 1894
>> AstroGrid Project manager       Fax:    +44 (0)116 252 3311
>> Dept of Physics & Astronomy     Mobile: +44 (0)7721 926 461
>> University of Leicester         Skype:  keithnoddle
>> Leicester                       Email:  ktn at star.le.ac.uk
>> LE1 7RH, UK                     Web:    http://www.astrogrid.org
>>



-- 
Keith Noddle                    Phone:  +44 (0)116 223 1894
AstroGrid Project manager       Fax:    +44 (0)116 252 3311
Dept of Physics & Astronomy     Mobile: +44 (0)7721 926 461
University of Leicester         Skype:  keithnoddle
Leicester                       Email:  ktn at star.le.ac.uk
LE1 7RH, UK                     Web:    http://www.astrogrid.org