[OBSERVATION] Re: Observation data model comments

[Anita Richards]

>
>  Fair enough. I'm still not totally happy with the MeasuredData name,
>  maybe DerivedData or ExtractedData?...

Sure, as long as it is unambiguous - I think that ideally class names are
unique and immediately obvious to everyone; as second best they can be
unique and either obvious or require looking up to get the meaning.
However it will undoubtedly lead to mistakes if either class names are
duplicated in different contexts - this may be fine for xml but not for
humans - or if they can be understood in different ways.

>
>  - 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.
OK, so somewhere off Location? Or a 'big' ObservationCuration class coming
off Observation which then passes some information to the Registry
Curation? Although I would want an example - e.g.
from your archives? to be sure I understand.

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

Is this something in the Quantity discussion? I see Mapping in the
Observation model but not Frames....

>
>  - 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.
What I mean, is that we need to be able to compare data in Mag's, Jy/beam,
Jy/arcsec^2 _now_, not in some idealised future. I suspect that it is
quite enough to ask, that VO tools can identify Jy/beam and then either
look for a user-provided factor (crudest method) or look in FITS data for
the beam and pixel sizes (aboujt the limit of our capabilities?) - let's
make sure we have a model which supports that, and use it! Similarly in reference
to the discussion with Alberto:

> Alberto, in his mail yesterday morning argued that Q was trying to do
> too much, and that e.g. the mapping from counts to flux
> might require exposure maps. I think that as we flesh out Observation
> we may find that we want to put the exposure map, or at
> least a reference to it, in the ObsData quantity, and Q is at least
> capable of doing that. Alternatively we may end up putting it
> in the Characterization and making a new Q which is defined as a mapping
> on the counts using the exposuremap, and we can do that too.

I am not quite sure what an exposure map is, but maybe it is analagous to
the field of view function i.e. sensitivity function (flux is degraded by
f(x)% at f arcsec..).  _However_, again, we need to start by waht we can
do and if it is just a single factor or simple magnitude conversion
function, as used e.g. in the AVO demo workflows, or the spectral indices
in NED, we should start with that.  As far as I know, starting simple
doesn;t stop us getting complicated; on the other hand if we try and
explictly include every case now we will never get started on real data.

>
>  - "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.
OK, if the people who write software are happy they can associate the
right bits - and if it will be clear to data providers where they have to
provide metadata, that is the other thing.

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

Surely they should be _funtionally_ equivalent.  THere is no point
dreaming up contrived examples for symmetry's sake (btw, the pure
mathematicians hated me when I used to teach applied maths).

> ....
>   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.
Well, it is internally important, but it only matters to the VO user if
they happen to correspond to time intervals s/he needs to know about to get a
useful product (or that VO tools need to know about).  In general that
won't be the case, the relevant time intervals will be longer (images from
sparse synthesis arrays) or shorter (rapid variability studies).  If only
specialised radio astronomy packages/humanoids can use the information
then it isn't a prioority to bloat the model with.

What I mean by functionally equivalent, is that we need to think what the
Charaacterisation matrix elements are being used *for* by VO tools, data
access tools etc.  If we make that clear, then data proviers can use
whatever dodgy fudge factors and scams they like.  Two different radio
arrays e.g. ATCA and ALMA, might actually use different limiting factors
altogether, one limited by total synthesis time , the other by coherence
time (for example).

Anyway, I thnk your points are more likely to be valid than mine, I am
basically quite happy with the column and row headings as they are or with
the minor ammendments which have been suggested and I think the
interpretation can be evolved in use.

cheers
a

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Anita M. S. Richards, AVO 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).