[QUANTITY] The discussion so far

[Ed Shaya]

All,

I will put some of what Jonathan is summarizing in graphical form.  
Hopefull it will be a bit more easy to take in.  Here is how one evolves 
from the proposal of Brian and me to that of Pat passing through 
something that may satisfy Jonathan.  There are a few other paths that 
could be taken as well.

I. C holds several different types of Q (I don't want to bring up the 
actual Q word yet).  Each Q sets up axes by arguments that takes Q.  The 
argumentRef on C aligns various Qs, but this is a structural detail that 
I  drop from the discussion.

    * C
          o  argumentRef+
          o Q+
                + argument+
                      # Q
                + value*
                + units
                + error*


II. Separate argument from Q and introduce a new element D.
Each D handles a single multivalued Q and its axes/dependencies.

    * C
          o  D+
                +  argument+
                      # Q
                + Q
                      # value*
                      #  units
                      # error*

   
III. Introduce Q' as Q without error.   Now Q is called, by Pat, a 
"measurement".

    * C
          o D+
                + argument+
                      # Q'
                + Q
                      # Q'
                            * value*
                            * units
                      # error*


In model I and II one could also have a Q' for use outside of a D. In
each model one could have a Q1 for a Q that takes single value not value*.
Finally, in all cases, value may take more than one number to allow for
tuples.  So to really get to Pat's proposal, one creates a separate Qt 
for tuples,
then substitute (Q'|Q't) for Q'.  Ray's requirements split Qt into 
several more classes,
one for all components having the same units and type and perhaps, later on
we develop one or two more where this is not the case.  As for the type, 
I would
think that sometimes one would want a Q/@ucd and sometimes one would
subclass Q into something like Mass and that would also have @ucd if it were
further subdivided by UCDs.  Hopefully one only sees Q show up in rare 
cases of a
quantity that noone has examined yet for deciding how to properly subclass.

It is probably worth mentioning that from the XML point of view these
are all quite interchangeable.  The schemas are all about the same 
difficulty
to create and understand and one to one transformation would be trivial.

I believe that all of these could be made into working systems that
would take care of all of our use cases and total requirements (some
slightly more easily than others).  All of these cases cover the same 
generalized
concepts.  The issue of class hierarchy is purely the programmer's 
worry, so if we can
settle on one of the above, the non-programmers (should I say high level
designers) can get on with high level design and the programmers can
hash out which way will save them a few thousand lines of coding.


Ed



Jonathan McDowell wrote:

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