A plehtora of Quantities

[Ed Shaya]

>I understand the concept and the starting point.  I just don't see a case for 
>defining a new 'type' that all things must derive from. I can see a case for 
>a 'Measure' but even that is a bit high.  For example, are there any 
>programming languages that define such things?  No - they give you the 
>components to assemble your own structures, because building root types like 
>this hinder later.
>  
>
I don't think of quantity as a root type.  Ontologically there are 
objects (Things) and quantities (properties).  Observation is a Thing 
not a property, an SED is a property.
We are not building a programming language, we are building a huge 
application.

>It's the 'experimental science' and 'most' that are enough to make me want to 
>avoid an 'Everything' object.  What about same-unit ratios (eg ellipse 
>characteristics)?  Heirarchical Triangular Mesh? Enumerations? pi?
>
>  
>
ellipse characteristics are quantities.  Enumerations is a Thing that 
lists objects or quantities.  Well, pi is a matter of opinion right now, 
but as I see it, as a matter of practicality it should be under quantity 
because "number of" is a property and pi is a number.
I don't know what an HTM will ultimately look like right now, but I will 
speculate that we will think of it as the Sky and thus an object.

>>Since a list of one 
>>is still a list then we can temporarily combine both sides of the OR.  
>>    
>>
>
>This is trueish, but I'm not keen on forcing people to deal with 'int[0]' 
>when 'int' is what they mean and want.  We lose typing information.
>
>  
>
It is no loss to lose it off of UML or Schema diagrams which is where we 
are working right now.
The atomicQuantity will be coded with int and the ListQuantities will be 
coded with int[n].  But if someone does not want to code an 
atomicQuantity, their StandardQuantity will handle both.

>>But, if we have a list then we also need to provide information on what 
>>is changing with index value.  Are we jumping from one object to another 
>>or from one wavelength to another?  Therefore, the index becomes an axis 
>>with a quantity associated with it, so one can give accuracy and units 
>>on those values as well.  An example would be an SED which is composed 
>>of fluxes with units and errors and with each flux is an associated 
>>wavelength which has units and an error or bin size (actually both, 
>>since there is an error in the central location of the bin (and 
>>additionally there is an error in the bin size).  So we start off with a 
>>StandardQuantity which allows for such things in a standardized way.  
>>    
>>
>
>So now we have to make sure that Quantity can handle equations too?!  Consider 
>an SED constructed from a number of combined passbands... The work to model 
>this belongs with modelling SEDs...
>
>  
>
I don't follow. A SED looks like  a spectrum with gaps in it.

>>You can create any Quantity subtype by making restrictions to the 
>>StandardQuantity and thereby carve exactly the component that you need.  
>>    
>>
>
>Hmmm that's not really the 'restrict' meaning I normally associate with 
>subtyping! It's not the way most software languages define it; few have 
>facilities to 'hide' methods on supertypes.
>
That may be but both Ontologies and XML Schema do, and these are the 
proper tools to be modeling these abstract concepts.  The code will just 
have to be a bit more complex to accomplish what we envision.  Just get 
used to it.

>  
>
>>Want a quantity with errors but no units?  Go right ahead.  And by the 
>>way, if you want some shortcuts to commonly used restrictions there is 
>>AtomicQuantity. ListQuantity and CoreQuantity to help you along.  Use 
>>them if you want or don't. 
>>    Next we want to combine quantities, but we want to do this keeping 
>>some relationship between the index values of both quantities.  This is 
>>commonly the case when the nth element in each quantity refer to the 
>>same object.  QuantitySet provides for a standard way to get your ducks 
>>in a row.
>>    And SED is a Quantity, but you are free to create more complex 
>>things using Quantity and QuantitySet that are not themselves Quantities 
>>(like Observation or STC).  The intent was to make the more complex 
>>things easier to design by allowing  use of these two powerful component 
>>parts.
>>    The whole thing is intuitively obvious.  N'est pas?
>>    
>>
>
>Yes, and I understand the reasoning behind it.  Being intuitvely obvious 
>however doesn't mean it will be good for us...
>
>I like the Quantity concept as a basis for discussion, but using it in our 
>actual object models is going to make it harder, not easier, to interoperate 
>and build models.  
>
>  
>
Imagine an STC where the error on the time coordinate is sibling of the 
time element and the error on the x coordinate is a child and the error 
on the y coordinate is two layers down and the error on the z coordinate 
is in a header section at the top.  Then imagine there is a separate 
format to the get method for each of these error types.  There is 
nothing to exclude such behaviors in an object model made up entirely 
for the purpose of STC without consideration for other parts of the VO.  
Quantity is just a compact to not do that.

>Cheers,
>
>Martin
>
>
>  
>