[QUANTITY] Plea for pragmatism

Wed Oct 29 09:53:04 PST 2003

Well it is with great fear of causing an even bigger explosion of 
e-mails, but I hear a call for
use cases and if use cases are really welcome then I want to be sure 
that use cases from
the point of view of a high level query language are represented.  In 
what follows I use measurement,
quantity, data, metadata, item interchangeably so that I am not 
introducing definitional
examples of these terms.  Rather, I am simply introducing use cases, to 
be used for
requirements development of a data model, and after that we can again try to
cut up the model into working domains.  I do think that some overall DM 
has to be
agreed upon before groups can split off and work on specific domains.  
Perhaps this
is happening for a second time?  If so I apologize.
I do reserve the right to add more use cases as we go along, since I may 
have, with 10 examples,
left huge gaps. 

I. Extracting simple measurements with errors.  Ensure they have
errors and are associated to objects that may be associated with
higher level objects, clusters.

    #Obtain Iron abundances [Fe/H] for stars in M92.

II. Extracting object holders of properties.  Here we ensure
bi-directionality of above associations.  And introduce a comparison
quantity. And we need to hold intermediate arrays and
the averages of these arrays.  The output is an array of objects,
(GCs). 

#Find globular clusters whose stars have average iron abundance < 0.25.

III. Include conditional items in search.

    #Same as above but only use cases where more than 2 Iron
    lines were included in the analsys.   

IV. Extracting meta-data quantity.

    #Obtain the assumed Iron transition probabilities assumed in
    previous example.

V. Extracting line identifications, confidence level etc
    #Obtain which lines have been identified in far UV in the

VI. Extracting 2-d data.  One expects either single aperture or CCD
data, and everything should carry along errors and quality
assesments.  Of course the aperture location and pixel sizes must be
carried as well.

    #Obtain 350 micron emission data of Sgr B2 (galactic center object)
    that have resolution < 20". 

VII. Extracting 3-d data.
    #Obtain, for region XXX, microwave background data from WMAP
    in all spectral channels in regions excluding known
    galaxies (using the V=25th mag/sq" surface brightness
    contour).

VIII. Extracting vectors.
    #Obtain from N-body simulation XXX, using mass points in
    halos at the present time, the center of mass motion of each
    galaxy+recent infall components at z=5.

IX. Extracting tensors.
    #Assuming all clusters in the Abell Catalog have mass of
    1E14 solar masses, calculate how the acceleration vector
    increases with distance from the Milky Way in each of the
    3 cartesian coordinates.

X. Instrument as Objects.
    #Find a spectragraph at a major observatory dispersion <100A/px and 
throughput
    better than 20% over the region 3500-4000A.  Display the throughput 
curve for
    each of these.

Mark Cresitello-Dittmar wrote:

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