[QUANTITY] The discussion so far

[DIDELON Pierre]

Hi Jonathan,

Waouh! Big work, impresive summary.
Thanks a lot, it will help to clarify things
(certainly in my head). Some small comments in text.
Pierre

> From owner-dm at eso.org Fri Oct 31 04:34:32 2003
> X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to owner-dm at eso.org using -f
> From: Jonathan McDowell <jcm at head-cfa.harvard.edu>
> Date: Thu, 30 Oct 2003 22:27:34 -0500 (EST)
> To: dm at ivoa.net
> Subject: [QUANTITY] The discussion so far
> 
> 
> 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).
> 
[snip]
> 
> 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.

Totally agree! nevertheless if not all people interested in Q can interact
in the discussion (because they are over bussy with other nonVO tasks)
discussion will be non exhaustive and result perhaps inapropriate.
But this is certainly unavoidable, unfortunatly.

> 
[snip]
> 
> 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.

Array-1D OK,  ND flattened in 1D (like pat proposal) OK.
Otherwise we are no longer speaking of simple quantity but of
complex dataset, data collections, images or whatever.
I agree with doug email about hierachical data structure
(http://www.ivoa.net/forum/dm/0219.htm) and may be we have to agree
and try to define such a common (VO-DM) hierchy of data structure.

> 
[snip]
> 
> 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.
>
Depends on the definition of both, but if we have both,
let Q simple and put errors in Measurement.
If we have only one thing... no choice, put it there. 
> 
> 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.

I am in favor of having very simple class, firstly due to a general aspect,
that very simple class are very general and can be reuse more oftenly
without too much overhead. When you only need a value and his unit
would you be inclined to use (in your code apllication or even in your
appl definition) a class which contains a lot of other things you
really don't care about? I feel that scientist (even computer ones) often use ,
perhaps implictly, the Occam blade to throw away and suppress superfluity.

Secondly, there are (or will be certainly) certain areas or high level object/concept
which will require only value or error. I have no direct illustration for value without
error (or accuracy) because even speed of light, which is very well defined,
or even PI (3.14...) are not absolutly known. But I can image some context where
errors will be linked to something else than values, so it would be great, then and there, 
to be able to use a small object already define. For example, I can think
of the data error or tolerance a process can accept. If you want to store this information
in a structured way it would be nice to be able to link (in a certain manner)
a "quantity" containing error information to a process, and not a very big object
containning value(s)/error/quality/... 

Morevover and finally, if the possibility exists, why small object have do be
forbidden by DM group, it can be usefull for some people not taking part
of the discussion today, but which can try to use VO-DM framework later on.
We can have something for free, whcih could interest futur users
and already interest some of us, why forbidden it?

> 
> 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.
>
a lot. see comment above about data structure hierchy. 
> 
> 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

No. in measurement (taking into account all my comments above)

>  
> Should Measurement inherit from Q vs use it as e.g. aggregation?
>  (Thomas yes, inherit?)
>  (Didelon no, aggregate)
>  (McDowell no, aggregate)
>  (Lemson no, "uses")
> 
[snip]
> 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.
> 
use small classes for re-usability

Regards,
Pierre