Definition of Frames.

[Brian Thomas]

	David,

	I have to run to a meeting and may not be able to respond further until
	later, but a quickie response for this important issue.

On Thursday 13 May 2004 11:47 am, David Berry wrote:
> > > Given that a CoreQ consists of a Frame and a Mapping (taking a
> > > ValuesList to be a special form of Mapping), it is represented by:
> >
> > At the risk of delving into an issue with no bottom..
> >
> > Well, thats not how I see it. A CoreQ has coordSys information, but
> > if you want the full "Frame" you must use StandardQ, which has axes.
>
> Not clear what you see as the distinction between a CoordSys, and a Frame.
> I thought a Frame is supposed to be a container for all the meta-data
> needed to describe the system in which the phenomenon values are recorded.
> So how can CoreQ do without a Frame? Admitedly, the current doc has CoreQ
> *inheriting* from Frame (via BasicQ) and so CoreQ *is a* "full Frame". The
> more I think about this the less I like it - CoreQ should aggregate a
> Frame, not inherit from Frame.

	I consider a frame to be the meta-data needed in order to describe a
	"frame of Reference" or Coordinate system. In the present model, 
	this is something called a "CoordinateQuantity". The interface for
	frame, should be something like:

	interface Frame {
		public UCD getUCD();
		public CoordSystem getCoordSystem();
		public List getAxesList();
	}

	The frame may be extended in order to create "TimeFrame", "SkyFrame"
	(IF needed). I leave what axes are for the moment unconsidered. 

	It is clear that there is no way that CoreQ can meet this interface, but a
	StandardQ (one which can store quantities as values) or a CompositeQuantity
	could (or optionally make it a special stand-alone class). Consider that
	a Composite Quantity would look like:

	interface CompositeQuantity {
		public UCD getUCD();
		public CoordinateSystem getCoordSystem();
		public List getMemberList();
	}

	Its a trivial step to add in the "getAxesList()" method to the interface, and
	then you can have "compositeQuantity" inherit from "Frame", e.g. 

	interface ComposityQuantity extends Frame {
		public List getMemberList();
	}

	This allows one to downcast any compositeQ into a Frame, whenever they need to do
	so.

	Therefore, a mapping has the interface:

	Mapping {
		public Frame getInputFrame();
		public Frame getOutputFrame();
		public List transformValues():
	}

	Can take CompositeQ's (which inherit from Frame) and return Frame objects
	(which may or may not be CompositeQ's).

	I have strong reasons for wanting the axes (dimensions) of a quantity to
	be other quantities. I won't review them here (again), but what is the problem with
	having the axes be quantities themselves in your model? You can always
	ignore the values which they might hold, otherwise, all the meta-data are
	right (each axis has size, name, etc). 

	I think this is a matter of you only see the requirements that you think are important.
	I'm trying to create a model which will satisfy *both* our requirements.

	Regards,

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