[QUANTIT] Use-cases, role in larger scheme (Was: Re: [QUANTITY] Quantity "arguments")

[DIDELON Pierre]

> From owner-dm at eso.org Mon Nov 17 10:15:43 2003
> X-Authentication-Warning: mercury.hq.eso.org: majordomo set sender to 
>     owner-dm at eso.org using -f
> Date: Mon, 17 Nov 2003 09:05:10 +0000 (GMT)
> From: David Berry <dsb at ast.man.ac.uk>
> To: Doug Tody <dtody at nrao.edu>
> cc: Brian Thomas <brian.thomas at gsfc.nasa.gov>, dm at ivoa.net
> Subject: Re: [QUANTIT] Use-cases, role in larger scheme (Was: Re: [QUANTITY]
>     Quantity "arguments")
> 
> Doug,
> 
> > Probably it will be difficult to make any real progress on 'quantity'
> > until the architecture it fits into has been clarified so that we know
> > how it will be used.  To continue with this now the best strategy might
> > be a simple prototype of some sort that is usable as a component (i.e.,
> > the bottom-up approach).
> 
> By "bottom up" do you mean looking at features of a Quantity which we know
> will be needed, even without looking at any use-cases? Here I'm thinking
> of things like the need for a Quantity to contain some form of definition
> of what its data values represent (i.e. does the Quantity contain a
> list of flux values, positions, ccd counts, or what). It's hard to see how
> a Quantity could be used if you cannot tell what it contains. So we do not
> need to spend a long time working through a set of use cases to decide
> that this is a requirement.
> 
> Also, it seems obvious to me that a Quantity will need to carry around
> information about the location of the data values in any relevant
> coordinate systems (i.e. "WCS" in the broadest sense). Without this how
> are we going to compare Quantities (for instance, to re-project a set of
> images onto a common projection)?
> 
> Do we really need to spend a long time working through a list of use case
> to decide that these are requirements? I'm with Doug when he says that we
> should work from the bottom up as well as from the top down (albeit Doug
> may disagree with my previous two paragraphs - particularly about WCS).
> 
Hi,
just to mention that in Pat's model, Quantity is linked to a ReferenceSystem,
which certainly solve this.
Isn'it?
just one more argument in favor of my favorite Quantity model (pat's one),
but let's try to be more complete and explicit.

I prefer VERY SIMPLE object instead of complex ones, 
mainly considering a bottom-up approach, because :
- they are easier to define 
- they will be better defined 
- they will be easier to understand by future DM and code devellopers 
- they are easier to reuse in DM, via composition, agregation or inheriting,
to build complexity progressively 
- they are easier to use in applications, to exchange simple data containing
what is needed and not too much additional unnecessary informations

In a top-down approach you can construct very complex and usefull object,
because you are supposed to have catch all the "outside real world" complexity
into the project by the mean of use-cases, requirements... Then it is a good thing
to handle complex objects.
In a bottom-up approach, you build basic bloc/stone (to construct later on walls, 
houses...) for reuse with uncomplete apriori knowledge of what is the ultimate 
complexity. 
As already stressed in one of my previous mails claiming for very simple quantity, 
VO (as a whole, not only DM group) has already complex structure at disposal to 
exchange "elaborated" data, like VOTable, and packaging using VOTable is forseen, 
if not already used by some groups. Reflexion and modelling must go on I admit it,
but a more urgent thing is the ability to exchange fully described parameters
(one or few values) to exchange atomic data or very small amount of data,
for query definition or other purposes of data exchange.
Moreover, it has been admitted that quantity is forseen to be a basic block,
describing small data part, to be reused in higher level and more complex
component of DM. So it can not be used as a general container for any kind
of astronomical data (this is a top down approach).

>From above one basic requirement for quantity I would like to be discussed is,

an object usefull to exchange small data part (scalar or vector)
with informations needed for it's interpretation an usage.

one of it's advantage is that it has a meaning for Computer Scientist
as well as for Astronomers (or am i wrong?).

Pat's model seems to me a very god step in this direction, 
and a good starting point, as illustrated by position (quantity)
and position error (ellipse, another quantity) gather together in measurement.

My opinion only, don't shoot too fast if you don't agree.
As I am a limited english spoker, 
small technical responses are easier to handle 
than Sheakspeearean exhaustive ones ;-).

Sincerely,  

Pierre