Spectrum data model

[Anita Richards]

Hi Jonathan,

Thanks for your very rapid reply and your patience with some stupid 
questions. As I said, I don;t want to reopen old wounds or delay the 
release but there are a couple of issues which I would at least like to 
store at the back of people's minds as possible causes of any problems 
encuntered with the take-up and use of Version 1.0, and a couple of issues 
which I thnk need clarifying in the document.

>> include default ucd1+ for the most basic elements in the templates.
> ? I thought I have provided those in the document...
Sorry, yes of course you have, what I meant was that they should be 
automatically filled in for the data providers (who could optionally edit 
them, of course) - sounds obvious but we need to be as clear as possible 
in what we ask!

> The Target.Name is mostly for humans and for by-object-name queries.
> The DataID.DatasetID is really the parent dataset. I guess I don't
> necessarily see the name for a separate ID for the VO version
> of the dataset.

Ach, what I actually thought you meant was the parent collection (e.g. if 
the particular instance of Spectrum was describing one spectrum out of a 
collection of 20 Markarin galaxies....). Shows how some idiot will always 
get the wrong end of the stick however carefully it is worded!

I guess what would help most with these ambiguities is a tabulated (i.e 
human readable) example for a specific spectrum.

>> Spectrum.Char.SpatialAxis.Coverage.Bounds.Extent: Bounds is box
>> corners in Char; I can see confusion if it is a diameter in Spectrum -
> Well, the idea is that Bounds.Extent is an alternate representation
> of the same information in Bounds.Min/Bounds.Max. It's more appropriate
> for spectra, but you can convert it.

Sorry, I don't agree, I think that it will confuse both data providers and 
software.  If I have data in Char with a box described by square Bounds, 
with data in the corners, I have to take the radius along the diagonal to 
convert it to Spectrum Bounds.  Then if I convert the Spectrum Bounds back 
to Char I end up with a box twice the area....
If things have the same name they should be the same thing.

> Hmm. I'd like to introduce a concept of 'must' which means 'must, if can 
> be defined'.

= 'should'? - we ahve to start from the premise that data providers are 
doing their best as long as they can see our logic and it is not too much 
trouble.  But I see what you mean! Maybe in the user's intro we should 
stress that 'should' really means it!

>> Spectrum.Char.TimeAxis.Coverage.Location.Value and .Bounds.Extent
>> Unless the data are time series, these should be 'should' not 'must'
> You usually know the date to within at least a decade.
Yes, I know, but if it is not recorded with the data, providers have to 
fill it in manually, I don;t want to deter people who e.g. have 1000 
spectra taken between 1850 and 1950.... - I still prefer a forceful 
'should' but no big deal.

>> Spectrum.Char.SpectralAxis.Coverage.Location.Value and .Bounds.Extent
>> Unless the data are spectra, these should be 'should' not 'must' ...
> The VOSpectrum authors disagreed.
Maybe we should give up trying to make this model evenhanded for data 
which do not have the main axis in the e-m spectrum. What do time 
series/VOEvent people think? Are they catered for well enough with Char 
and the specific time domain models, for data which the present version of 
Spectrum does not fit?

>> I have a conceptual problem with this section, and with the
>> example on p40 - surely the model is supposed to describe the data,
>> not 'be' the data!
>
> We distinguish in the companion SSA protocol document between 'foreign'
> data and VOSpectrum serializations.  The problem is that "the input
> formats expected by spectral tools" currently encompass many dozens of
> different input formats, even  within FITS. This is very different from
> the image case, where everyone can interpret a FITS image. We felt that
But there are now many VO-enabled  tools which handle spectra with varying 
degrees of speciality (SpecView, VOSpec, TopCat, SPLAT....) which can read 
a wide variety of formats (and contrariwise, image FITS can be quite 
perverse...)

> We provide standard formats in ascii XML, ascii VOTABLE and in
> FITS binary table. I believe that unless we can evolve towards
> such standards, spectra will NOT be interoperable. At first, not
> everyone will do such conversion, and you'll have to hope that
> your software can consume them. But if it catches on, the pressure
> to provide the conversion will increase.

Apologies for misunderstanding; if I have now got it straight, then " 
Spectrum.Data.SpectralAxis.Value " etc. are only compulsory if you are 
using the xml format for your data.  I think that somewhere early on e.g. 
in the Intoduction the preferred ('should' ?) formats should be described. 
My experience so far is that some very large data providers won't bother 
to convert to even usable formats (e.g. they serve tarballs) and very 
small ones can't (e.g. there is no funding left, just a server being kept 
on-line by the grace of the system manager) whilst tool writers can often 
solve the problem in hours as long as the metadata are adequate and 
accessible.  Of course, I hope that future data providers do adhere to 
standards and we should promote this but I think that the document 
currently gives the impression that the VO is only for data in xml, which 
will not work.

Thanks again for everything, I hope that my comments were useful even when 
I misunderstood some of the original intentions, in pointing to parts of 
the model which might need to be clarified for data providers further
removed from the VO than me...

Best wishes

Anita

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AstroGrid Astronomer
MERLIN/VLBI National Facility, University of Manchester, 
Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K. 
tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).