[QUANTITY] Plea for pragmatism

[Mark Cresitello-Dittmar]

All,

I'm mostly an observer to the list since my responsibilities
are mainly toward our local namespace DM.  However, I thought
I'd chime in.. perhaps stating the obvious or erroneous.

The QUANTITY/DataContainer/Phenomenon concept (that which
takes a "number" and gives it physical meaning and context)
is a fundamental element for the DM and as such, will need
LOTS of thought and discussion.  The more organized and
recorded that process is, the better.  So while there has
already been lots of discussion about QUANTITY, I don't see
where the substance of that discussion (requirements/use cases)
was captured for reference and analysis.  The effort to create a
table of requirements is definitely NOT a waste of time, and
I see no problem with that including the role the object plays.

At the same time, there is a clear need by the other working
groups and by us to have a 'big picture' model of the concepts
like OBSERVATION, COVERAGE, etc., even if these concepts have
no substance.  IMO having this picture can help keep discussions
on fundamentals like QUANTITY from getting bogged down by trying
to put too many side concepts into it.  I also think that this
big picture must remain in a fuzzy 'grey' state, because the
model as a whole must solidify from the bottom up.  After all,
it's all about the data.  Users want to get data, and they need
to know where it came from and what happened to it, but the reason
they want the data is to do something with it.  For that reason,
the QUANTITY (concept) becomes the core and everything else will
support that.

Fortunately, this group clearly has people who naturally work
from one end or the other.  From the attendance I saw at the
IVOA meeting, there are certainly enough people to pursue both
directions.  I hope to see the [OBSERVATION] thread start up
very soon, picking up where the IVOA meeting ended, putting
together a VO picture of common elements of out various local DMs.

TTFN,
Mark







David Berry wrote:
> 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
>>
>>
>>
> 
>