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

[Martin Hill]

Can't spell Plates Or A...

Brian Thomas wrote:

>>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?

ie, the attempt to fine one class is failing, causing lots of extra types to be 
generated.  They are not interfaces - you can use that notation on your diagrams 
and call them that, but they are really container classes.

> 	What is an SED? 

I apologise for that; I kind of assume that anyone else on this list knows a lot 
more about everything to do with astronomy than me.  I forgot that I've picked 
up some little bits here and there. Jonathon's answered this I think.

Basically it's a set of fluxes, each at a different wavelength (or more strictly 
speaking, at a different passband).  So if you measure through a blue filter, 
then a red one, then a (green?) one, then take some radio measures and X ray, 
and line up the fluxes along the wavelength you get a Spectral Energy 
Distribution. Apparently some people then do wonderful things with this, but in 
my case I just think they make quite pretty diagrams.


> 
> 	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" :

Gaaah (to coin a phrase!) No no no, etc.  I'm demonstrating that it's not hard 
for us to agree a Spectral Energy Distribution model, built around the 
components in the Quantity *concept*, but it would be very hard to build one 
around the Quantity *object*.

The core reasons to model objects together, to agree object models, is to make 
sure we have interoperability between our services.   Modelling a Quantity is 
not agreeing anything that will help interoperability - because, for example, 
there is no way of making sure that the values/objects that are in a Quantity 
used to store a Spectral Energy Distribution at one place are the same as those 
at another.  We have to model an SED at some point; if we say that an Passband 
can only be a Quantity, we have to 'pick' the nearest XxxxQuantity and make the 
most of it, and if we want to have Passbands that are also Accuracys, then 
suddenly our object model becomes very nasty with multiple inheritance issues.

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

Yes, of course we must be able to pass our object models around.  This does 
*not* require them to be abstracted so far that they can't be validated.  As a 
quick example, the tag:

<SimplePassband>
     <Min>
        <Wavelength>12</WaveLength>
     </Min>
     <Max>
        <Frequency>0.12</Frequency>
     </Max>
</SimplePassband>

can be shared between any bit of code that shares the object model and 
serialisation that we agree.  It can also be *validated*; schemas that describe 
Wave, Passband, Flux, SED can be written and built on top of each other and will 
*work* whereas basing everything on Quantity loses all that.

> 
>  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]

No.  This is the VOTable argument: if you make one thing that does everything, 
suddenly everything will interoperate.  This does not happen - instead you get 
one thing that has to be modified/described in so many ways, you're back to 
where you started but with your own special VO-way of doing it.

>  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.]

You can write a much neater, easier to read and debug XPath statement on the 
above example than a generalised one.

> 	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??

I agree with you with the requirements!  It's the process to get there is 
already delaying our efforts (not that it's bad to have a think) and will make 
it much much harder to work out later.   I like the Quantity concept, I just 
think that when we come to building the real models, we should use the Quantity 
components, not try and make the Quantity do everything.

> 
>>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.

Yes please!  I think it would help understand more about how Quantity would be used.