Relationship between Q and STC - Frames & Mapping

[Brian Thomas]

On Monday 10 May 2004 07:20 pm, you wrote:
> Done a bit more thinking (in the pub, oh dear!).
> 

	There are worst places; you could have been at the bus station :)

>  From what I gather Mapping is not part of what is presented by the 
> Quantity interface.  As far as a Quantity user is concerned, we just do 
> getValue(), and we get the value back according to the described Frame.
> What is done to turn the internal value into the Frame-described value 
> is an implementation issue.

	Yes, this is my interpretation.

> 
> In which case please let's get rid of the Mapping from the Quantity 
> interface!  In fact it probably doesn't belong in the *model* at all, 
> especially as we will need to work out how to map between Quantities 
> where we will definitely need a modelled mapping, called, say, Mapping...
>

	Well, I almost agree. I think there is a strong need for some way to create Q's 
	that get their values from mappings (mappings are particularly nice for 
	compact description of large quantities like axes). But you don't want to
	just allow the user of the Q to change (or mix!) how the values are created
	in any given Q (it would be a nightmare to implement..). This is why I suggested the 
	constructor as a likely place (once made, how Q interoperates with its values
	is set).  I'd also favor having a boolean method to determine the nature of how 
	the values are generated in a Q also. This is nice because you can't (shouldn't) do 
	"q.setValue(Obj, Location);" method call on a Q that has a mapping
	behind it. The method thus allows the user to pre-determine whether its
	OK to make the setValue call rather than having to always catch an error.

	It's also important to reinforce that the current mapping prescription is
	for *values* (V-mappings if you will). There are *no* mappings for 
	generation of Q's (this is a point that took me some time to grok). There may 
	be a need for mapping Q's into other Q's (I think so, particularly for use in 
	tandem with UCD3/ontologies)  but currently that isn't the case, and there 
	are no plans at this time to make Q-mapping interface/serialization.
 
> Does that sound OK?

	More or less. :)

-- 

  * Dr. Brian Thomas

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

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