[QUANTITY] Data Model for Quantity v0.5 - inheritance vs aggregation

[Martin Hill]

By 'heavy' I really mean that we are strongly defining a lot of things 
about what Quantity is, and therefore all the things that 'are' 
Quantities have to carry around this extra baggage that might or might 
not be relevent.

You've helped solve this problem partly by making a BasicQuantity, a 
CoreQuantity and a StdQuantity, but these are attempts to fix the wrong 
problem. A dead give away is the names - 'basic' and 'core' are similar 
ways of saying the same thing, and I think that's what you meant by Std 
too...

We must be careful that our interfaces don't end up being classes.  An 
interface should (mostly) specify *behaviour*, not contents.  Specifying 
a bunch of properties (as has been done for Quantity) is effectively 
specifying a container class, even if you can technically say that the 
properties are methods and the methods are defined in an interface.

Given that Frame -> BasicQuantity -> StdQuantity all define the contents 
of a Quantity, and very little about behaviour, we actually have classes 
with all the inheritance problems (and benefits) associated with these.

Instead let's have a Frame as you have.  Let's have things like Errors, 
Mappings, Accuracy, etc.  Then we assemble quantities as we like and as 
appropriate out of these things - just as at the moment someone would 
have to decide which of Basic, Std and CoreQuantities they should 
subclass from.

As an example, I think someone mentioned MagnitudeFrame in the last few 
days (can't find it now).  It makes sense to me that people can build 
different Frames, and include these with their values.  We can't do that 
if the inheritance tree is fixed.

Thinking about it more, Mappings should definitely not be part of the 
Quantity; Mappings (if I have them right) define how to convert values 
between one Frame and another, and this depends upon what the Quantity's 
user wants, not upon what the Quantity has.  The Frame should define 
enough about the source & target values to know which Mapping to use...

Cheers,

Martin



Brian Thomas wrote:

> On Monday 10 May 2004 08:46 am, David Berry wrote:
> 
>>That may be just a perception issue. Admittedly the document makes it
>>look fairly heavy, and I suspect the models presented by the interface and
>>the "first cut"  serialisation examples may appear to lean in different
>>directions (although Brian may not agree!), but non-the-less, all the
>>quantity model currently covers is how to record meta-data describing the
>>phenomenon measured by the Quantity, and the coordinate axes used to
>>locate each sampled value.
> 
> 
> 	I agree with this more or less. The serialization document lays out the
> 	structure, which is fairly simple. Here's a copy :
> 
> --- begin snippet ----
> 
>    The components of these types of quantity are given elsewhere, but
>    summarized here, are:
> 
>         Basic Quantity
>                 UCD
>                 CoordSystem
>                 Units
>                 DataType
>                 Value
>                 Accuracy
> 
>         Core Quantity
>                 UCD
>                 CoordSystem
>                 Units
>                 DataType
>                 Values
>                 AltValues
>                 Accuracy
> 
>         Std Quantity
>                 UCD
>                 CoordSystem
>                 Units
>                 DataType
>                 AxesList (gives coordinate frames for accessing values in Q)
>                 Values
>                 AltValues
>                 Accuracy
> 
> --- end snippet ----
> 
> 
>         Each of the components is either fairly simple in structure, or re-uses
> 	the quantity structure itself (e.g. "accuracy", "altValues", "axesList" and 
> 	"coordSystem" are conceived as types of quantities, or lists of quantities).
> 
> 	Now, that wasn't so bad, was it? How these quantities are used, how
> 	things like "units", "dataType" and "accuracy" are defined are still
> 	up in the air.
> 
>         How the quantities are used within other data models is also up for
> 	debate. My feeling is that they should be inherited by all node/structures 
> 	which are going to hold any scientific number/string information. This 
> 	seems (to me) the only way to truly satisfy the requirement that the data 
> 	models be universally searchable, transportable and "machine understandable". 
> 	Others feel that they should be limited to use only for the primary data container
> 	and then, only in aggregation. 
> 
> 	=b.t.
> 


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