Charac Answer

[Anita Richards]

>> 
>> Axes
>> 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. 
thanks.

So my comment about not having a velocity axis and needing one is wrong 
anyway.

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

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

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

Anita