[QUANTITY] Requirements and apology

[Ed Shaya]

Ray,

    What you describe here is very close to the AtomicQuantity in Pat's 
diagram plus,
since you say it can hold a "set of numbers", it is also the composite 
or tuple quantity.
Except that you also say that it is not a requirement that the values 
that make up the quantity are different type or unit, so that limits it 
essentially to the vector type tuples (perhaps one can squeeze in 
complex tuples (a+ib) since the a and b are of the same type).
    OK.
     We can adjust our diagrams in a few minutes and establish such a 
model.  We can now claim that this quantity effort is completed and we 
can move on.
    Now, that it is done, it needs to be extended.
    Why? Because this specific choice of atomicQuantities will rarely be 
needed.
     
Astronomers rarely query for a single number.  The first query that 
brings back multiple AtomicQuantitys will be inefficient and confusing 
if it is a bunch of atomicQuantities.
Not only is it inefficient to create many small objects, but
 one immediately desires a new class that can keep track of what is 
different about each of the individual atomicQuantities. So, someone 
extends quantity, but we need a new name.  Shall we call it 
QuantityWithOneArgument?
   Now someone asks for a property over  a region of the sky or for a 
set of objects with a certain time interval.  Need 
QuantityWithTwoArguments now.  We can go on to other attributes that are 
generally needed as well.

Part of the issue here is that you need to really look at the use cases 
and see if where you
are drawing your circle encompasses most usage.  It doesn't.   
Basically, you are finding
a logical stopping point but not a practical one.
Another issue is the idea that we extend quantity as needed for each 
physical phenomenon.
That is dangerous, because then one might get what you ask for, many 
very specialized extensions of quantity.
Such as, a quantity_extension class that holds a sensitivity class. 
Would it not be better to have a flux class that includes a component 
sensitivity class which is in turn a  quantity.
Looking at Jonathan's flux model.   One can see the various components 
that are needed
and they are all not atomicQuantity, but they are, each one, well 
represented by  a mutidimensional quantity.
    If you were willing to call extensions to Quantity by the same name, 
I might see
how we can slowly develop Quantity into what we  want.   But I  know you 
don't like that
so that removes that avenue for us.

Ed

I might
Ray Plante wrote:

>Hi,
>
>First, I apologize for launching this little monster and walking away.  
>Under some definitions, the Quantity DM could qualify as a computer virus.  
>I should probably be locked up under the Patriot Act or something.  
>
>I agree that requirements are necessary: they set the scope of the 
>project.  When you throw out requirements, you narrow the scope of what is 
>to be accomplished, and hopefully your life is easier.  That doesn't mean 
>you won't deal with those out-of-scope things later; it's just a divide 
>and conquer approach.
>
>I note also that one possible conclusion of a requirements analysis is 
>that a generic Quantity model is not useful or not worth pursuing (given 
>other priorities).  
>
>I agree with Alberto that the many of the requirements posted at 
>http://nvo.gsfc.nasa.gov/cgi-bin/view_requirements.pl are not 
>requirements, and others are a bit too vague to be useful.  (I'll add some 
>specific comments and suggestions on that sight.)
>
>I feel an obligation to contribute to this effort; I just hope that I
>haven't fallen too far "out of the loop" to be helpful.  So to get
>started, here's a definition for the purpose of the discussion below,
>based on one found in the Amer. Heritage Dictionary:
>
>   A quantity is a measurable, countable, or comparable property of 
>   a physical phenomenon that can be represented as a set of numeric 
>   values.  
>
>My interest in this model has always been on simplicity and that be
>extended and built upon.  This is reflected in my requirements:
>
>HOW IT WILL BE USED:
>
>  1.  The model should provide a common way to express quantities
>      associated any physical phenomenon so to:
>        a. aid users and developers who might see instances of the model 
>           in recognizing the concept as a quantity, 
>        b. enable the use of common software for manipulating quantities
>           independent of the physical phenomenon they represent.
>
>  2.  The model should be reusable by other models--either via
>      extension (i.e. inheritance), containment, or association--to
>      build more complex models.  In particular, it should be possible
>      to extend it to create a model for a specific physical phenomenon.
>
>  3.  It should be possible to straight-forwardly derive from the model an 
>      XML schema for representing instances of the model.  Multiple 
>      compliant schemas may be possible.
>
>  4.  It should be possible to encode simple instances of a model
>      simply with a minimum number of model components.  
>
>        Comment: this means, for example, that if the quantity does not
>        have an associate unit because it's dimensionless, then we
>        shouldn't require a lot of markup related to units to express
>        this.  If there isn't an error (because it's not known) there
>        shouldn't be a lot of error-related baggage.  
>
>  5.  Applications should be allowed to demand the level of complexity
>      that appears in data model instances that it handles.  
>
>        Comment: this is a correlary to above.
>
>  6.  It should be possible to render a model instance in a form that
>      is naturally readable and recognizable by scientists.
>
>        Comment: when combined with the previous requirement, this
>        means an example of a simple human-readable model instance
>        could be "10.3 mJy".  
>
>WHAT IT DOES AND DOES NOT INCLUDE:
>
>  7.  The supported numeric types should include integer, (scalar)
>      floating-point number, and complex floating-point number.
>      Multiple computer language types will fall into the above
>      catagories (e.g. float and double are both floating point).  The
>      supported types should *not* include string or boolean.  
>
>  8.  The model must include an indication of the values' type.  It is
>      *not* a requirement that the values that make up a quantity have
>      different types.  
>
>  9.  It should be possible to use a quantity instance to refer to a
>      measurement of a physical phenomenon in the abstract without
>      actual values (i.e. values are optional).  This allows one to
>      use the instance to request specific quantity data ("give me
>      fluxes in this unit") or describe data stored outside the
>      model instance (e.g. in a table column, database, or image).  
>
>  10. It should be possible to associate a quantity with the physical
>      phenomenon it measures.  This is association is not required to
>      appear in model instances.  
>
>  11. The model must be able to associate a measurement unit with the
>      numeric values representing the quantity.  It is *not* a
>      requirement that the values that make up the quantity may have
>      different units. 
>
>  12. The model component representing a unit must be separable so
>      that it can be assocated with a varity of sets of values,
>      including a single scalar, a vector, and a multi-dimensional
>      array.  
>
>  13. The unit model component *may* allow dimensional analysis that
>      enables various tranformations on the quantity, such as scaling, 
>      unit conversion, and quantity arithmetic; however, it is *not*
>      required to.  
>
>        Comment: This is meant to set the scope on the complexity of
>        the unit model.  It allows simple instances to be handled
>        simply, and it means we don't have to solve this problem
>        within the scope of the Quantity data model.  
>
>        I recommend an extendable model for units with a base that 
>        contains only a simple string for display purposes.
>        Extensions (defined outside the scope of this model!) can be
>        rich enough to support dimensional analysis.  Alternatively,
>        the unit component might include an optional pointer to a full
>        unit model that enables dimensional analysis.  
>
>  14. It must be possible to associate with a quantity a description
>      of the error in the quantity.  The error model component must be
>      extensible to allow different ways of expressing an error.  It
>      is *not* a requirement that this model define all (or any)
>      specific ways to describe an error.
>
>        Comment:  This is another scoping requirement: it's not
>        necessary to define all the different error model types at
>        this time.
>
>  15. It must be possible to associate other properties with a
>      quantity (e.g. quality, measurement conditions, interpretation);
>      however, definition of those properties should be outside the
>      scope of this model.  
>         
>So the picture I paint here might be summarized as follows:
>  *  a quantity has value(s), a unit, and an error description; all
>     optional. 
>  *  values are only numeric.
>  *  values can be scalar or multi-dimensional
>  *  anything more complicated than that is largely handled in 
>     extensions or other associated models DEFINED ELSEWHERE, including:
>       o  dimensional analysis
>       o  quantity arithmetic
>       o  quality flags
>     The model should define the necesary hooks that allow these to be
>     attached on.  
>
>Big diagrams and complex capabilities are fine, but we need to be willing 
>to draw a line around the subset that will define the "Quantity Data 
>Model".  
>
>cheers,
>Ray
>
>
>  
>