[QUANTITY] Pulling it all together

[Ray Plante]

Hi all,

First, thanks to Arnold for firing up the discussion on quantities.  I 
think we got a good summary from everyone about how this is not trivial 
(an intended outcome of my simple-minded proposal ;-).  Thanks also to 
those (David B, Gerard, Steve L., Jonathan, Brian) who posted links to 
related white papers and such.  I recommend we try to digest these so that 
we're not starting from square zero.

Second, for the benefit of those who weren't in Cambridge, the DMWG has 
identified a "work package" to develop a general, re-usable model for 
quantities.  I have created a page on the Twiki for posting materials on 
this work:

  http://www.ivoa.net/twiki/bin/view/IVOA/QuantityModel

I have posted most of the materials cited so far on this page, including
my presentation from last week.  Please feel free add other materials.  
(You must first register at 
http://www.ivoa.net/twiki/bin/view/TWiki/TWikiRegistration.)

Now that we know how complicated this can be, I want to attempt to try to 
pull the major issues together into a semi-concise listing to consider and 
use them to make progress.  

  1.  Use.   

      Important uses of this model:
        *  building a metadata schema (in XML)
	*  creating software interfaces
      When we propose model components, have some sense of how it
      might appear in these contexts.  

  2.  Simplicity vs. Complexity.  

      Scientifically, we all understand that simply quoting a flux as
      "5 Jy" or a frequency as "1.4 GHz" does not give us the entire
      story.  This is evident when we want to precisely compare, say,
      this frequency with another.  Nevertheless, in practice, we
      often render a frequency in these simple terms, normally because
      the rest of the story is somehow implied (or is not important
      for the implied level of precision).  Thus, our practice
      indicates that we need to support a simplified model too.

      The general approach we've tried to endorse within the NVO is
      provide models that can capture the complexity (or be extended
      to do so), but which reduces sensibly to the simple case.  That
      is, we should be able to just say "1.4 GHz" (with a small amount
      of mark-up).  We might call this a kind of "dumb-down" rule.

  3.  Quantity as a Building Block

      An important motivation for this model is to allow its re-use in
      creating more complicated models.  Some ramifications are:

       *  Different quantities will be used in combination.  We want
          to avoid redundancy of information.  
       *  It's appropriate that we think about and describe how a
          quantity could/should be used in the for describing more
          complex things.

  4.  Where to put things: Inside Quantity vs. Beside it.

      This is a fundemental modeling question that does not
      necessarily have one right answer.  On the one hand, we can
      encapsulate everything into a "Quantity".  This has the
      advantage that a quantity instance could potentially have
      everything one needs to know to do any kind of conversion
      properly. 

      On the other hand, we can pull some of that information out to
      be held at a higher level.  In this case, a Quantity is defined
      to be a much simpler thing, as simple as a value and a unit (as
      some have suggested).  I like to go to the flux example as it
      simpler in concept than frequency or position.

         <Photometry>
           <Flux>
	     <Value>5</Value>
	     <Unit>Jy</Unit>
	   </Flux>
	   <Freq>
	     <Value>1.667</Value>
	     <Unit>GHz</Unit>
	   </Freq>
         </Photometry>

      Here Flux & Freq are simple Quantities; however, we can define
      a higher level-object, Photometry, that carries more contextual
      information about the flux.  

      This is similar to the AIPS++ model David B. mentioned.  A
      quantity is very simple: a value (possibly a vector) plus a
      unit.  Context-blind combinations & comparisons can be done with
      quantities.  A "Measure" is a quantity + a "frame".  The frame
      provides the context for doing precise conversions for
      quantities where context is important.

      You could pull Error out of Quantity and handle it as part of
      the context.  This might be a little tricky, though, as it may
      be harder to make clear which quantity an error is associated
      with.

  5.  Scalars and Vectors.  

      We need consider both cases.  In particular, I think we need to
      be able to render Vectors in an unwieldy way when the context is
      sufficiently simple.  

Well, I left people stew & comment on these a bit.  Then what I would
like to do is pose some directed, concrete questions--perhaps some
alternate models--and try to reach some concensus on them.

cheers,
Ray