[QUANTITY] Plea for pragmatism

[David Berry]

I tend to agree with Alberto that the requirements for the underlying data
container model (be it called QUANTITY or something else) will probably
become apparent as we consider further the higher level OBSERVATION model
which we started to put together at Strasbourg.

Having said that, I think it would be useful to have a simple overview of
what a candidate data container may look like, just so that we can check
if it is able to meet the requirements which emerge as we develope the
OBSERVATION model, and change it as needed. I'm thinking here of something
as simple as the following:

A Data Container (purposefully avoiding the potentially overloaded
word "QUANTITY") has one mandatory component called "DATA" which
contains (somehow - details to be decided) the actual data values. In
addition, it can have any or all of the following optional components (all
details to be decided):

ERROR - gives an estimate of the random error on each value in the DATA
component.

QUALITY - gives a set of flags and/or enumerated values for each value in
the DATA component.

LABEL - identifies the phenomenon measured by the DATA component (maybe a
UCD?). Having a component to identify the contents like this avoids the
need for a separate sub-classes for each of the potentially large number
of phenomena which we may be interested in.

UNITS - identifies the units of the values in the DATA component

WCS - Contains a collection of world coordinate systems in which
positions within the DATA component can be described, together with
Mappings which describe how to transform positions between different world
coordinate systems.

TITLE - A descriptive title for human readers


Obviously, there are many details missed out in the above, but I suggest
this list as a target to be shot at as the OBSERVATION model is developed
further. We made some good progress on OBSERVATION - whereas we seem to be
getting bogged down on QUANTITY.

David



On Wed, 29 Oct 2003, Alberto Micol wrote:

>
> Dear All,
>
> At this point my feeling is that we are going nowhere.
> All these discussions about quantities  are too phylosophical for me.
>
> We need to focus on what we want to achieve, provided that it is clear
> to everybody what the goal is. I might be wrong, but I do not think that
> the goal is well identified within the group. (After all, this is why I
> called
> for user cases).
> I do not believe that defining a generic thing call quantity will bring us
> anything immediately useful. It is too generic.
>
> For example, sorry Brian, I do not understand the requirements in
> http://nvo.gsfc.nasa.gov/cgi-bin/view_requirements.pl
> Most of them in my opinion are not requirements, but definitions.
>
> Requirements should describe what is to be achieved, and not
> which class is associated with what, or who inherits from who.
> And too generic requirements (quantity will be used to facilitate
> search, etc)
> bring nowhere either.
>
> In all cases, I do not find useful to start from the Quantity level.
>
> Let's concentrate on the top level things we need to solve for the VO,
> eg, how to describe coverage (bandpasses, regions, time intervals,  depths)
> of existing data products, how to describe images, spectra, light curves,
> exposure maps, visibilities, etc, how to package products, etc.
>
> Those should be the starting points, because that is what we have to
> describe
> in the 99% of the cases.
>
> In the process of developing a data model to cope with these (already
> complex)
> aspects, we will find the needs to define other things like Quantity,
> Phenomena,
> or anything else that WILL RESULT USEFUL in the process. Not the other way
> around!
>
> I thought that it was decided that we start with Observational Data Model,
> and not with Quantities. That is certainly a much more pragmatic point
> of view,
> am I wrong ?
>
> Alberto
>
> --
> Alberto.Micol at eso.org                         Tel: +49 89 32006365
> HST Science Archive       ST-ECF              Fax: +49 89 32006480
> ESA/RSSD/SN               c/o ESO             Karl Schwarzschild Str.2,
> http://archive.eso.org/   No ads, thanks.     Garching bei Muenchen,
> http://www.stecf.org/     HTML emails         D-85748 Germany
>
>
>