Inheritance of different Q's

[Brian Thomas]

On Thursday 13 May 2004 10:41 am, David Berry wrote:
> >  Finally we need to list the pieces that are controversial even within
> > the Q paradigm: should BasicQ have errors, should it be called AtomicQ,
> > etc.
> >
> >  With all respect to Martin, I am not so worried about the bigger
> > question of whether Q is the right model to be doing. We should do other
> > models too, along the lines Martin suggests, and perhaps they will turn
> > out more useful in the end. I don't think we can settle that argument in
> > advance.
>
> Maybe a compromise would be to keep StdQ, CoreQ (and probably BasicQ)
> but to do away with the inheritance relationships between them. So we
> would have:
>
> 1) CoreQ: a rule for getting values for a potentially vector-valued
> Quantity. Aggregates a Frame and a Mapping (or ValuesList). Does *not*
> inherit from Frame or BasicQ or anything else:
>
>   CoreQ {
>      Frame
>      Mapping or ValuesList
>   }

	If a Frame contains axis descriptions, then this won't work. The CoreQ
	is supposed to be just a list of values + metadata (which *don't* include
	a coordinates description). 

	If you plan to store the axes as the values (which I imagine you don't as
	I know you favor a separate non-quantity-based class for "axis"), then you 
	have created a CompositeQuantity. (or a CoreQ, where the dataType == "QuantityType").

	Having a non-Q based axis causes a good deal of problems as well.. the most
	important that comes to mind is that you have prevented the Q from having the power 
	to express quantities as functions of (or dependencies of) other quantities. This 
	expressive power is potentially very usefull for search and expression of a lot of 
	data in the VO (in particular theoretical data, n-dim data-cubes and tables). How
	can one express "Flux(t)" without having axis on the footing of being a Q?

	(One aside:  your proposal looks like one to implement/build classes, but I think 
	I see what you mean..)

	You could break Frame out of the inheritance tree, and that should help
	some things. {I proposed something similar in the last email}

>
>
> 2) StdQ: >*USES*<  CoreQ (but does not inherit from CoreQ) to describe
> a Quantity with optional axes and and alternate data representations:

	When you say "uses" it looks like a prescription for implementing a 
	class. The interface methods may overlap, and then you can say
	StandardQ interface inherits from CoreQ interface. I don't know how
	interfaces may "aggregate" other interfaces, I don't believe thats 
	correct UML...

>
>   StdQ {
>      CoreQ[] values;  (a list of CoreQ's holding the values in
>                        different representations. This list would often
>                        have a length of one - i.e. only one data
>                        representation).
>      CoreQ[] WCS;     (a list of CoreQs describing the coordinate systems
>                        which can be used to describe the position of
>                        elements within the "values"  CoreQ)
>   }
>
> Any problems with this?

	Yes. It won't work, and its framed as an implementation proposal, not one
	for interfaces.

	=b.t.

>
> David

-- 

  * 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]