amsr at jb.man.ac.uk
Thu Sep 1 10:50:48 PDT 2005
>> What is 'cinematic' - is this the temporal+spatial analogy of a
>> spectral+spatial data cube?
> No, no ; for us kinematic was just the velocity axis.
Ah! Because to Brits cinematic with a c is like cinema! Now I understand.
So my comment about not having a velocity axis and needing one is wrong
> We are aware that "spectral transition" and "radial velocity"
> information are mixed on the wavelength axis. Probably we had in mind
> simple cases where the relationship between lambda and the velocity is
> simple and unique (single emission line for example). The overlapping
> case you are adressing is "strange" because one single data dimension
> (the "spectrum") is described by two independant axis: wavelength and
> velocity. But if you present this kind of data as a velocity spectrum,
> how much do you need ? one per spectral structure ?
In the first example I can think of, yes, but I would welcome input from other
> We also remember that Jonathan was in defavour of having two
> different axes. Jonathan, could you argument that?
> Ok, we agree. BTW Are the channel width and channel spacing the same
> with Visibility data?
The minimum available is determined by what is in the visibility data but you
can average together an arbitrary No of channels, e.g. if you start with a
visibility data set with 240 good channels you can squash them all together for
a continuum image; you can squash together every 3 for an 80-channel cube, you
can make an unsquashed 240 channels ube (and you can apply spectral smoothing
so that yu end up with e.g. 240 channels with a separation of 1 kHz but an
effective FWHM of 1.4 kHz...)
>> etc. etc.) in enough detail for extraction and processing. As far as
>> I can see some of the top layers of the Characterisation model could
>> map to the Registry model but I would like to see this done explicitly
>> with cut-offs.
> We do not totally catch you here, what is "cut-off" for here?
Sorry, I am not entirely sure what I meant either but I think what I meant was
that the Registry shuold be kept simple, so the finer-grained detail from
Characterisation is not necessary for the registry - but where they desribe the
same concepts theys should be consistent.
> Well: that's a tricky point:
> 1) Registry RM is dealing with "Resources"
> and Characterization with individual (but also collections of) DataSets.
> This may intersect in some cases, but generally not: not all
> Observations or even collections will gain a "Resource" status.
> 2) Characterization is layered while Registry RM is not.
> Anyway that would have been nice if Characterization level 1 and RM
> could have shared the same formalism. Historically it was not possible, but
> a mapping should be done. The actual values will differ of course.
>> I also think that we should see VOs in general and Characterisation in
>> particular as being mainly aimed at providing data which will be
>> passed between other VO tools. Thus 'Characterisation ... is necesary
>> .. but not sufficient .. also requires details of observing...'
>> worries me. In many cases I hope that the Characterisation model will
>> be sufficient because we should be encouraging data providers to
>> supply data with instrumetal signatures already removed, so that other
>> VO tools can tackle the images etc. Observational details should be
>> provided as part of giving the data a history, and we do already have
>> that in the Observation DM, but they are only directly relevant to
>> Characterisation if we have tools to use them (e.g. a special tool to
>> convert Chandra counts or 2MASS magnitudes to physical units).
> Hmmm! Does VO have to be a data "police" ? What about "old data"? What
> about reprocessing of raw data? Potential use of the data is different
> according to the level of available description. Eg: Uncalibrated spectra
> are usefull to study line ratio in the same spectral domain, no ?
I agree entirely and as you know I am very against data police... just that we
should reword the emphasis - e.g. 'Characterisation should be sufficient to
allow the user to do science directly (e.g. using other VO tools) on
well-calibrated data. For data which requires further instrument-specific
reduction, the data model should also give a pointer to the origin of the data
or other sources of necessary information'. I still want to _encourage_ people
who work in non-physical units to provide a translation, but not to _force_
them to. One of the biggest problems which has come up in almost every science
case I have worked with users on, is needed to convert optical or IR magnitudes
to physical units. In some cases the conversion is well-known (to an accuracy
of <1 - few %) but often also well-hidden.
Actually your last example about uncalibrated spectra sort of supports my point
because in order to measure a line ratio, you don't need flux calibration - so
the spectrum might be immediately tractable in e.g. SpecView, which can
subtract a baseline and measure a ratio...
>> Fig. 2
>> I was amused to see Observatory Location under Coverage_SPATIAL
> This class comes from the re-use of the STC classes for coordinates.
> it appears in the diagram because we show the STC subclasses , and not
> one big STC blackbox.
> Is this misleading?
Um, it confused me but maybe that is just me!
I agree with your other points.
More information about the dm