[QUANTITY] Do we need it? Some quantities

[martin hill]

Having had a nice long bath...  I'm worried that since so many things are a
quantity, we're going to try and make a model that has to describe so many
things.  We're likely to end up with something so general it won't really define
anything, or alternatively will restrict the way we describe things.  

How about we look at specifics: Error and Quality will be useful I would think,
but also Passband, er... suggestions?  I guess Co-ordinate and Brightness might
be a bit ambitious at this stage?

Quoting martin hill <mchill at dial.pipex.com>:

> Being a bit radical here, but what is quantity for?  I've read the list
> (honest)
> but it strikes me that really a quantity is simply a number.  A range for
> example presumably consists of two quantities.  So perhaps we should start
> further back and look at what kinds of quantities we want to describe -
> personally I suspect we'll end up with a bunch of different 'quantity
> models'
> some of which are not necessarily related...  
> 
> So as a non-astronomer, we might have:
> 
> Value: simple number (integer or real)
> 
> Error: 
>    simple (+/- absolute)
>    percentage (+/- percentage)
>    normalised* (sigma?)
>  
> Range: Min Value + Max Value
>    might have errors attached to range or to values?
> 
> Value & Range might have a unit attached, but only a simple error will.  
> 
> *not sure of the right term here
> 
> Including quality is a scary topic (for me as an implementer!). Can we make
> it a
> separate [Quality] model altogether?  It will get attached to all kinds of
> things, including presumably complete data sets?
> 
> Martin
> 
> Quoting Brian Thomas <brian.thomas at gsfc.nasa.gov>:
> 
> > 
> >         Hi all,
> > 
> >         I came away from the ADASS/IVOA meeting being encouraged that some
> >         progress could be made at data modeling as long as we tried to
> side
> > step
> >         semantic issues of naming and coding specifics, and instead
> started
> > at
> >         the most general level of needs (or requirements). This means no
> > attempts
> >         to produce "the" UML diagram with all specifics and trying to
> hammer
> > each
> >         of our models home. The details in each are too much for the
> others
> > to
> >         generally comprehend, or even, in general, want to spend time
> > studying.
> > 
> >         Hence, I propose that we attempt to gather requirements for the
> > quantity, to
> >         better define what it is we all want. These requirements would be
> > *then* used
> >         to create a consensus UML diagram *later*. I would hope that for
> this
> > discussion,
> >         we can just debate the requirements of "quantity", perhaps with
> > points illustrated
> >         via a UML diagram or a use-case, but no "overall" UML diagram
> being
> > produced
> >         until we all largely feel the "fundamental" requirements have been
> > generally
> >         agreed to.
> > 
> >         If this experiment is successful, I would hope that the DM group
> > will
> >         recommend a draft of these requirements as part of the greater
> > "Observation"
> >         whitepaper that I understand Jonathan wants to prepare, or perhaps
> as
> > a
> >         separate IVOA note.
> > 
> >         So, to start the ball rolling, here's some requirements that I saw
> >         in the various models (all requirements start with the "="),
> and/or
> > popped
> >         up the the informal discussion at IVOA/ADASS. I have attempted
> >         to arrange these in order of general acceptance, rather than
> > "importance":
> > 
> > <requirements>
> > 
> > 
> >    = Quantity is a container class that holds scientific, engineering
> > information.
> > 
> >    = Components of the observation model will inherit, as needed, from the
> > quantity.
> > 
> >    = The quantity has an associated class, "coordinate transform/mapping",
> > which is
> >      used to transform one quantity into another (dimensionality of the
> two
> > quantities
> >      is the same).
> > 
> >    = The information in quantities, in order to make it valuable and
> machine
> > readable
> >      requires that it be described by meta-data that include type of
> units,
> > type of data
> >      format (such as "long", "float", "string", etc) and its accuracy
> (which
> > includes
> >      things like "quality" flags and "statistical/systematic errors").
> > 
> >    = The quantity may be multi-dimensional (this is _almost_ a universal
> > feature of extant models).
> > 
> >    = The quantity may hold information which comprises scalars, vectors or
> > other quantities (tuples).
> > 
> >    = Primary/top requirement: The quantity will be used to facilitate the
> > search,
> >      exchange and data fusion in the VO. [The "data fusion" part leads to
> the
> > 3rd requirement
> >      in the list]
> > 
> >    = The quantity will be able to completely describe all the information
> > (data or
> >      meta-data) in a FITS file or VOTable.
> > 
> >         which (I think) leads to..
> > 
> >    = The quantity is a container class for _meta-data_ as well as _data_.
> > 
> > </requirements>
> > 
> > 
> >         So there is a "starting" list. Nothing "official", but perhaps it
> can
> > lead to
> >         some consensus document that is.
> > 
> >         Thats all for now,
> > 
> >         Regards,
> > 
> >         =b.t.
> > 
> > -- 
> > 
> >   * Dr. Brian Thomas 
> > 
> >   * Code 630.1 
> >   * Goddard Space Flight Center NASA
> > 
> >   *   fax: (301) 286-1775
> >   * phone: (301) 286-6128
> > 
> > 
> > 
> > 
> 
> 
> -- 
> Martin Hill
> 07901 55 24 66
> www.mchill.net
> 
> 


-- 
Martin Hill
07901 55 24 66
www.mchill.net