[QUANTITY] Data Model for Quantity v0.5 - more on Quantity vs assembly

[Martin @ ROE]

David Berry wrote:

> Martin,
>        So what you are saying is that, just as we see Quantity as a
> aggregated component of the Observation model, so also we should be
> thinking about what the *components* of a Quantity are? That is, we
> should build Quantity from a collection of component parts which are not
> themselves Quantities (and so do not inherit from Quantity), but which
> fulfill some specified role within the higher level Quantity model and
> which are designed independantly of each other. The "Quantity model" would
> then presumably define how these components are used within the context of
> a Quantity, which are mandatory which are optional etc.

Yup!

> 
> Is this the idea? I myself have always favoured that approach.
> 
> David
> 
> 
> 
> On Mon, 10 May 2004, Martin @ ROE wrote:
> 
> 
>>Er well that's a little misleading...   To be clear it means that
>>quantities are assembled from re-used components with a specific purpose
>>in mind.  ie, a quantity that describes a radio flux will be related to
>>one that describes an x-ray flux, but is not related (in a class
>>diagram) to a quantity that describes the size of my shoe.
>>
>>
>>>	In the end, this will be very complex model with no reusable parts. The supporting
>>>	library is likely to be quite large and complex and difficult to implement and
>>>	understand and maintain.
>>
>>No! We are now in the area of computer science rather than software
>>development, and the impact of decisions we make on object models do not
>>always have the 'common sense' results.
>>
>>The issue is about how things are 'reused' not whether we reuse them.
>>Using assembly/aggregation rather than inheritance means we 'free up'
>>the ways we can develop things from existing things.   We need this if
>>we can be sure we can cope with things we haven't thought of yet.  Our
>>supporting libraries can then be sets of packages, rather than being
>>large monolithic codesets that have to be created in a single step to be
>>of any use at all.
>>
>>
>>>	I don't see how this will be extensible either as it amounts to proscibing a universal model
>>>	(or set of models) for all, from which nobody can extend without breaking the functionality
>>>	of the VO as a whole.
>>
>>In fact it is the other way around.  Single inheritance models are
>>extremely restricting - if down the road we find we need to change
>>something in Frame for example, we risk breaking every single VO
>>quantity in the whole model...
>>
>>
>>>      I vote "no!" for this. Proponents: please outline how you can satisfy
>>>	VO needs with this kind of approach.
>>
>>In contrast to my comments above: any particular assembly is not an
>>attempt to solve the whole VO needs.  This is its strength and
>>Quantity's weakness; we can build quantities for particular purposes.
>>This makes agreement much easier and code libraries relatively
>>independent.  Where models overlap, we share models - such as the STC.
>>
>>The STC is a classic example of something already happening this way; we
>>have a common representation & model, and we *include* it in our model.
>>This is the reuse I would like to see, and without which it is going to
>>be harder, not easier, to build an interoperating VO.
>>
>>
>>--
>>Martin Hill
>>Software Engineer, AstroGrid (ROE)
>>07901 55 24 66
>>
> 
> 
> ----------------------------------------------------------------------
> Dr David S. Berry    (dsb at ast.man.ac.uk)
> 
> STARLINK project		 |	Centre for Astrophysics
> (http://www.starlink.ac.uk/)	 |	University of Central Lancashire
> Rutherford Appleton Laboratory	 |	PRESTON
> DIDCOT				 |	United Kingdom
> United Kingdom			 |	PR1 2HE
> OX11 0QX                                Tel. 01772 893733
>                                              01257 273192
> 


-- 
Martin Hill
Software Engineer, AstroGrid (ROE)
07901 55 24 66