[OBSERVATION] Re: Observation data model comments

[Jonathan McDowell]

Anita,
 Thanks for your reply to my comments.

 - combining MeasuredData and ObsData being too logically pure:
    
 Fair enough. I'm still not totally happy with the MeasuredData name,
 maybe DerivedData or ExtractedData?...

 - what I mean by curation; internal curation not relevant to VO

 I think it worth providing a way to interoperably communicate
 various levels of curation: who curates the dataset in the archive
 (as per Registry curation); but also, who you go to ask if you want to understand
 the calibration; and who originally owned the data. The ObsDM curation
 should include but extend the Registry curation data.

 - Mapping; nice to know what coordinate system you are in...

 Let's distinguish between the coordinate system (J2000, etc) 
 (a Frame in the Q model)
 and the parameters of the pixel to coordinate mapping
 (a Mapping in the Q model)
 In Obs Characterization, we essentially have Frames to tell
 you what the coord system is in. The pixel size is given in
 the sample precision, but the detailed mapping is down in the
 mappings in the ObsData. I still feel this is a reasonable
 approach as it keeps the Char simple.


 - Jy/beam stuff

 I agree that we should support data in Jy/beam. I'm just saying
 the way to do it isn't to consider Jy/beam as just a funny unit.

 - "Plan is too generous"

 Hmm, point taken. Does "scam" cover all possible cases?

 - "However if we adopt a separate Char'n for catalogues of MeasuredQ.."

 I'm not actually suggesting that. I'm suggesting in fact that any two datasets
 (whether MeasuredQ or ObsData) may have somewhat different 
 Char'ns. Or rather, that Char'n is a flexible thing that doesn't
 necessarily have the same axes in any two instances.


 - SensitivityFunction.Temporal; chopping into smaller time chunks

  I agree the thing you talk about is a useful thing, but it's
  *not* the analog of the things we have called sensitivity in
  the other domains. For a given row (e.g. SensitivityFunction)
  the column entries are not meant to be *vaguely* analogous things 
  but precisely mathematically equivalent things that are 
  just projections onto the different axes of (in this case)
  a general sensitivity (efficiency of photon detection) as a function
  of time, space, spectral coord, etc. (which function may happen to be 
  separable along the axes if you are lucky). 

  In your case what you are talking about is something that is very
  dependent on the source, as you point out: the chunk size for 
  a given piece depends on the flux or the piece. We do this in Xray
  all the time, and in that context it's just (approx) root N counts.
  So I guess your thing is my sensitivity function folded through a
  particular source spectrum. I'll have to think how that could
  be made a row of the Characterization table.

 - Support.Temporal 

  Support.Temporal would include both the things you mention:
  it would be a series of stop/start times. In the radio case
  the problem is that you lump multiple pointings (sources) in
  a different file, right? So spatial and temporal support are
  correlated rather than separable: you would have a series of stop/start
  times for each pointing direction if you want the
  Characterization to cover multiple pointings. This is an important
  use case we should look at.

  Jonathan