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

[David Berry]

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.

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