[QUANTITY] Requirements and apology

[Ray Plante]

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