Spectrum data model
amsr at jb.man.ac.uk
Wed Sep 13 01:32:25 PDT 2006
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
> 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...
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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).
More information about the dm