Quantity - where does it fit?

[Martin Hill]

Ed Shaya wrote:

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

I get the impression though that the document *does* expect of quantity 
to be a root type.

> Ontologically there are 
> objects (Things) and quantities (properties).  Observation is a Thing 
> not a property, an SED is a property.

Hmmmm I have to disagree.  Properties are often Things. An SED is 
definitely a Thing, even if it's also a Property of something else.

> We are not building a programming language, we are building a huge 
> application.

With Quantity we are trying to build a modelling language that we can 
then express all our data models in.  That was really my point; we 
shouldn't be doing this.

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

What I meant was that these things don't have units and some do not have 
errors - so Quantity seems inappropriate.

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

It's an integer number, really a kind of string, that locates a 
triangular area on the sky (rather than a point). The longer the 
'number'/string, the smaller the area.


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

But some filters/passbands are based on formulae rather than a set of 
points.  So we need to make sure an SED can handle some Passbands that 
are defined by an equation - the whole SED might be a mix of point 
measures and formuale.  Trying to squeeze all this into a generalised 
Quantity is going to hurt.

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

I can't really get used to making things more complicated, bug prone and 
  expensive to write and maintain if there is no really significant 
advantage!  I don't know about Ontologies, but I fail to see how XML 
schemas do this; the whole point of polymorphism is that you get access 
to the supertype's properties.  Quantity breaks this - because you can 
no longer be sure if the subtype has the properties of the supertype or 
not.

But maybe we're thinking about this in different ways if you're not 
thinking of Quantity as a root type?

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

That is a silly example!  There is also nothing to stop us building our 
models in a standard way.  In the above example, the spatial coordinates 
are likely to be some kind of object, along with the associated error. 
Time might the same.  Where properties/things are common to different 
structures, we model them, and therefore access them in the same way. 
Where they are different, it does not matter if they have different 
method names (from a modelling, coding, messaging or using point of 
view) though obviously it is good practice if we consistently use, say, 
'Unit' for the property defining the unit, and 'UCD' for the property 
defining the UCD.

It's not difficult agreeing sensible data models - it *is* difficult to 
build a brand new framework that will express any data model, especially 
when we have existing ultimately flexible frameworks in the form of, 
say, UML and XML.

Cheers,

Martin

-- 
Martin Hill
www.mchill.net
07901 55 24 66