[QUANTITY] Data Model for Quantity v0.5

[Jonathan McDowell]

Assorted comments while catching up:

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.
The `higher level model' of Observation will indeed carry a lot of the
*organization*  but I think Q can do a lot of the heavy lifting.

David asked, in the context of Martin's question,
what I meant by Q and Frame as a 'common container class'.
I meant your latter thing, that we will be able to subclass FluxFrame,
SkyFrame, ShoeFrame etc., but with the strong suspicion that many
astronomical problems will not actually require us to create
new subclasses, or at least that in the early years of the
VO it will be much more important to be able to say 'what is this?'
that 'what does this do?' since we will be stitching this
data into existing software which is used to handling simple
FITS keywords...

Brian continued the discussion on whether BasicQ should
have Accuracy. 
 bt:  "This option doesn't work with the above needs 1 and 2"

I think it works fine with 2, I think 1A is a red herring and
I don't see why 1B is true (even if you want to do this
decomposition, which I wouldn't, you can always represent an n=100
CoreQ as 100 n=1 CoreQs, why is that worse than 100 BasicQs?).
But perhaps the question is, as Pat and David suggest, whether we
need to split BasicQ into 2 classes, one my way and one your way
(AtomicQuantity, with no errors, and ScalarQuantity or ScienceQuantity,
with errors?)

I'll have to reread the doc myself on the question of whether or not CoreQ
allows arrays-of-things-whose-data-type-is-Q (which is what I understand
you are asserting). In any case the text says that we probably won't
do this right away (as an interoperable thing; Brian is of course free
to do it..).

I would rather focus in the next few days mostly on Observation and on
developing a serialization for it, with the help of the Q gang to
make use of Q as appropriate, so that we can see where the problems
are and where the benefits are. I think we'll make more progress with
specific examples here. How are folks doing with reading Arnold's new STC
document?

 - Jonathan