Not a plethora (Was: Re: A plehtora of Quantities

[Brian Thomas]

	Martin,

On Wednesday 12 May 2004 10:05 am, Martin Hill wrote:
> So now we have QuantitySet, CoreQuantity, AtomicQuantity, StandardQuantity,
> ListQuantity, CompositeQuantity, etc. So in a familiar whingy ranty voice:

	No. "QuantitySet" is Equivalent to "ComposityQuantity", and neither
	is an accepted interface at this time. Furthermore, there is no "etc"
	beyond "Frame" if you want to include that.

> This is an example of what happens when you and try and find one class to
> rule them all.  

	How is it one class? Its a set of 5 or 6 _interfaces_.. Which way are you
	arguing here man?

> We now (appear to) have a set of Quantity classes that we
> can 'pick' from to create our new objects (such as Passband) - and if we
> can't find an exactly suitable one we just have to get something close.  We
> can't model exactly what we want.
>
> Perhaps a simple example would help to sort this out.  How would we, for
> example, model a SED?

	What is an SED? 

> A first stab would be to define a Passband interface that has methods
> something like getMinWavelength(), getMaxWavelength() and
> getLimit(wavelength), the last of which returns some proportion of passed
> flux given a wavelength.  (There is more, but this is just an example). 
> Then we have SimplePassband (which is just a wavelength range with a flat
> top), a FormulaPassband (which has a formalae behind it describing the
> shape of the passband), a GraphPassband (which has a set of points behind
> it describing the shape of the passband), and we can create standard
> instances of these for standard filters.  This gives us a Passband model
> that is easy to implement (for simple passbands) and we can plug into other
> models with no fuss, as we just need to include the Passband interface
> definition.
>
> We can have an abstract Wave object, with both getFrequency() and
> getWavelength(), implemented by Wavelength and Frequency which have
> Accuracy, UCD and can return each other suitably inverted.
>
> So now we can create a Flux object (or interface?) that has a Passband and
> a total energy - perhaps subclasses might include Magnitude that can handle
> magnitudes as well as returning estimated energy values.
>
> A list of Flux objects along with a coordinate is a Spectral Energy
> Distribution.
>
> These are reasonably simple to build using the components included as part
> of the Quantity concept.  But they are much easier to build and adapt by
> themselves without having to be Quantitys themselves.  For example, it
> might be useful to have Passband implement Accuracy (though I am probably
> showing my astronomical ignorance here) as I understand they often act as
> the error on a flux.

	Yes, its easier if you go it alone, to start. But then, nobody (or only your friends)
	will be able to understand you. The core reasons for the Q are sitting in
	the document as the high-level requirements. I shall repeat the most important,
	again, just to reinforce why the Q is needed over "going it alone" :

 a quantity instance must be serializable and standardized so it can be exchanged 
[between VO users/providers/apps]

 a quantity must be flexible enough to contain/describe data from different 
 sources in a uniform way so quantities can be integrated [ability to manipulate information
to build new documents/extract portions]

 quantity must have a uniform interface that can be referenced symbolically so 
 that searching can constrain any/all components [Must be universally searchable.
 Ideally using standard technology. Ex: an XPath expression to find the value of the time
 of a measurement should work on any Q-backed DM document.]

	How do you plan to achieve any of this without the approach the Q is taking?
	Do you consider these requirements unimportant then? IF so how is the VO to
	function without requirements similar to these??

>
> How would this work with the Quantity philosophy?

	If you tell me what an SED is, I can try to model it to show you an example.

	Regards,

	=b.t.
-- 

  * Dr. Brian Thomas 

  * Dept of Astronomy/University of Maryland-College Park 
  * Code 630.1/Goddard Space Flight Center-NASA

  *   fax: (301) 286-1775
  * phone: (301) 286-6128 [GSFC]
           (301) 405-2312 [UMD]