[QUANTITY] The discussion so far

[Jonathan McDowell]

Quantity Discussions Oct 2003

I've been drowning in email but I think I'm almost caught up. Phew!
Here's my understanding of the issues so far, as represented
in both dm at ivoa,net and off-list discussions, with a few of my own
spins. Forgive me if I have misrepresented opinions and been sloppy
about credit (e.g. the Dowler:: namespace should really be
Dowler-Lemson::?; I use Foo:: to indicate an object introducted into the
discussion by person Foo in some email).

What should Q be called? Is Quantity an OK name?
 Thomas yes, but it means what we want it to mean
 Dowler yes, but it means what CS people mean
 Berry no, use Data Container
 McDowell yes.

Should we do Q now, or wait until we've done O (Observation)?
 Alberto - wait
 Everyone else writing emails, - presumably, now
 McDowell: I think O is a higher priority, but no reason not to
  forge ahead with Q too.

Is the name of the (phenomenon, variable, etc) part of Q?
 (Dowler::Property name in a separate place)
 (Berry::DataContainer: yes, include name and/or label)
 McDowell: I would like to see a name as part of Q - then scalar Qs
  can serialize as a FITS keyword.

Does Q support arrays? Multi-dim arrays?
 (Dowler: yes)
 (Thomas Oct 25 0845: yes)
 (Didelon Oct 28 no: model something simple)
  Reason: same unit for many samples, commonalities
McDowell: I say yes, because we will need such a multi-dim object,
and it will be exactly the same as Q except for the multi-dimensionality.
So why do the same work twice? So much of astronomical life
is N-dim array based. We might as well put it in at the basic level.

Does Q support multi-dim arrays with links to other Q's as axes?
 example: Flux(Wavelength)
 Thomas Oct 29: yes
 Plante: no, higher level object to connect data Q with axis Qs
 McDowell: I agree with Ray, this should be a higher level object.
  Q should be the values associated with a single UCD (not counting
  modifiers like error, quality), and anything connecting two UCDs
  should not be in Q.
 (admittedly our CfA DataContainer object does do this WCS stuff, 
  but I think we are trying
  to keep Q a little simpler.)

Does Q support complex types?
 Dowler::Type = Ellipse2D, Oct 27
 Dowler, polygon types (Oct 29) 
 McDowell: suggest we not rule this out, but an initial implementation  
   would only support basic datatypes.

Should array quantity and a scalar quantity be separate
classes?
 (Dowler::AtomicQuantity, Dowler::ArrayQuantity;
 McDowell - My view:
    Not a separate class, simply the case n = 1
    Failing that, at least a class inheriting via restriction
    from Array, not a separate derivation from Q.
 Dowler's view (Oct 29): "really dislike the array of length 1..."
    (but I think this is just for the serialization, not
    the internal class representation, so perhaps reconciliation possible)

Should Q include heterogenous arrays? (with different UCD, units etc)
  (Thomas::QuantitySet table row construct)
  Most people: No
  Dowler: No, but consider representation issues (ISO date, numerical error)
  McDowell: Probably no, at least for rev 1

Should units be in Q?
 Everyone (I think!): Yes

Should errors be in Q or in Measurement (aggregation with Q)?
 Dowler::Measurement: not in Q
 Dowler: lots of things in VO are not physical measurements and do not have errors
 Thomas: data fusion requires errors in Q.
 Thomas (Oct 30): suggest that
                  Dowler::Measurement maps to Q (and Dowler::Quantity does not)
 Berry::DataContainer should include them
 McDowell: yes, but don't model the Error object fully yet.


If errors are in Q, should there be a simpler class similar to Dowler::Quantity
which does not contain errors?
 Didelon yes, (Oct 30)
 Thomas: implicitly no (Oct 30?) but didn't address Didelon's request for
  a name to talk about Dowler::Quantity (the object with no errors)
 McDowell: I think no, there's no need for a 'Simple-Q' with no errors
 (as opposed to a Q with a null error), it doesn't add significant
 weight to the class (and in the XML serialization doesn't have to add any weight?)
 Lemson (Oct 30): Dowler::Quantity is individual pixels - but errors
  may be correlated. Whole image is a Lemson::Result and not a Dowler::Quantity.
 McDowell: I like the idea that a single pixel can be a Quantity on its own,
  and an array of pixels can be a Quantity. Much fun will be hidden in the
  Error model. In particular, even in an image where the errors are
  correlated, one sometimes asks 'what is the absolute error on this pixel?',
  or 'what is the relative error on this pixel?', information that really
  is meaningful for just that pixel alone. Sometimes in contrast one asks:
  'what is the error on the flux extracted from this group of pixels'
  in which case the array's Error is the thing you need to use. The
  fact that errors are correlated doesn't mean it's meaningless to
  ask a pixel what its error is, and so doesn't mean Quantity shouldn't
  have an Error object.

Is there an intermediate astronomy/container-type object
between O and Q? 
 Tody: Adding quality etc to Q makes it no longer Q, but Tody::Dataset
 McDowell: I introduce this question because of Doug's comment;
  one can perhaps recast the continuum of opinions into a divide between
  those who want Q really simple (scalar value + unit, no array, no
  name, no error) and those who (like me) want Q to be the basis for containing
  everything except the astronomy (array values, unit, quality, errors,
  perhaps even coords). Maybe that's an indication there are two
  objects to be modelled, even if some of us think that using the
  extra, simpler object will mean more difficulty in writing properly
  general application code.


Should quality be in Q?
 Berry::DataContainer, yes (specific flags, not overall Obs quality)
 Thomas: Yes, as part of Accuracy
 Tody: No, keep Q simple
 Micol: No, keep Q simple
 Others: my impression is tending no
 McDowell:  yes, I think it would be good to have this
 
Should Measurement inherit from Q vs use it as e.g. aggregation?
 (Thomas yes, inherit?)
 (Didelon no, aggregate)
 (McDowell no, aggregate)
 (Lemson no, "uses")

Should Q support string values?
 (Thomas, Oct 25 0845, yes)
 (Plante, Oct 29, no)
 (McDowell, strongly yes)

Should Q also be used for metadata?
 (Thomas Oct 25 0845, yes)
 Didelon says Dowler separation (in fact, layering) of concept
 and Q is good. Thomas seems to think he is arguing for separation
 of data and metadata. I don't see the connection but perhaps
 I missed something. 

Should Q describe its datatype?
 Most people: yes? and I agree
  Dowler::Type can be things like Ellipse2D, or things like Double.
  
Should Q include coverage, completeness?
 Everyone: no, belongs in Observation

Should Q describe everything in a FITS file or VOTable
 Everyone (?): No! Maybe this is true for Observation

Should Q talk about transform/mappings?
 (Didelon no)
 (Thomas details should be at higher level)
 (Thomas no astronomical concepts like astro coord transforms) 
 (Berry: yes, since need to know why pixel 3 and pixel 4 are distinct)
 (Plante no)
 (McDowell: no, this should be the next higher level object)

Should Q have methods to describe quantity arithmetic?
 (Barnes yes?)
 (Everyone else: maybe but not yet?)

Should things be attributes or pointers?
 (Dowler: start off with everything as classes)
 (Plante: can refer to quantity without it having a value)
 McDowell: I argue everything should be classes as long as possible,
 allows for interfaces to hide special cases.


 - Cheers, Jonathan