UCD problem in SSA/SpectrumDM

[Douglas Tody]

Hi Keith -

I also think that a minor revision is warranted - mostly minor fixes
(we have only a couple so far including Alberto's) and clarifications
to text that was found to be insufficiently precise during the
implementation phase.  We have been saving some of these up for the
next doc update.

The issue Alberto flags (I agree the UCD is wrong) is unlikely to
have significant impact on existing implementations, although it will
require code changes to fix.  There may be other minor changes like
this required to either SSA or the SSA verifier as we get further
into running the two against each other.

"Refactoring" the data model, e.g. to resolve differences made in the
past 1-2 years between SSA/Spectrum and Char (they were aligned back
at the time SSA went to REC), could have much greater impact and if
so might want to be deferred to a 2.0.  I don't think we know yet;
the first thing to do would be to assess how things have diverged,
as you suggest below.  With SIAV2 and ObsTAP coming soon I agree it
is a good time to take an inventory.  Certainly we want to update and
realign the data models eventually, it is just a question of when
this happens for SSA if the changes are not backwards compatible.
It seems to me that if the changes are great enough this would require
a major version change to 2.0.

 	- Doug


On Fri, 20 Nov 2009, Keith Noddle wrote:

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