Heaviness of Q (Was: Re: [QUANTITY] Data Model for Quantity v0.5 - inheritance vs aggregation

[Brian Thomas]

	Hi Martin,

On Monday 10 May 2004 11:27 am, Martin Hill wrote:
> 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.

	Almost none of the components are "required" by either the interface
	or serialization, for example "accuracy". It is nevertheless usefull to 
	know that if you have an object that implements "Quantity" you can ask
	it "whats your dataType?" or "whats your units?" or "whats your accuracy?"
	(the latter providing a list of objects which each in turn implement
	quantity themselves).

	If I understand your design correctly, you would deny VO programmers
	the ability to easily determine this sort of basic information that is needed
	to do scientific programming (!!). Without quantity as a interface/serialization
	that is used by other model elements, what is to rigorously keep 
	designers from deviating on how one might determine the coordinate
	System of X versus a model component Y which also has a coordinate
	system, but is specified in a different manner by another developer? And
	even if the components are the same object, there is not restriction on
	how each might create the methods for accessing that information, e.g.

	public interface A {
              public CoordSystem getMyCoordSystem();
	}

	public interface B {
		public CoordSystem getAReallyImportantPieceOfInformation();
	}

	By realizing the Q interface, DM model components avoid the above situation.
	How does your approach prevent it?

> [snip]
>
> 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.
>

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

	There is no fixed inheritance tree. The proper term is "realization". Each
	interface has an established realization relationship between themselves.
	*But this is NOT the same as inheritance*. You are not forced into creating
	a class hierarchy which mirrors the interface at all. I happen to think its easier
	if you do, but hey, thats an *option*. I regret that I lost the argument with the
	other editors to change the language surrounding figure 1 to reflect that we
	are proscribing "realization" and not "inheritance" relationships, but that is 
	what is intended.


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

	Mappings currently *don't* have a relationship to Q. This is because mappings
	work on *values* and not whole Quantities. In the future, should there be a need,
	we may wish to create a "QuantityMapping" interface, but this is NOT in the works.

	cheers, 

	=b.t.


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

-- 

  * Dr. Brian Thomas 

  * Dept of Astronomy/University of Maryland-College Park 
  * Code 630.1/Goddard Space Flight Center-NASA

  *   fax: (301) 286-1775
  * phone: (301) 286-6128 [GSFC]
           (301) 405-2312 [UMD]