[QUANTITY] why we should have string values in quantity

[Brian Thomas]

On Friday 31 October 2003 11:39 am, Ray Plante wrote:
> > Should Q support string values?
> >  (Thomas, Oct 25 0845, yes)
> >  (Plante, Oct 29, no)
> >  (McDowell, strongly yes)
>
> I agree with Gerard that string values should be handled as a
> "Classification".   To be convinced otherwise, I need an example of string
> type that semantically supports the concept of an Error.  (It probably
> needs to pass some mathematical muster as well: can you multiply and
> divide with it?)

	Well I agree that anyone will have a hard time placing an "error" (number) 
	on a string. The best case I can come up with is the possibility that as
	user/data repository wants to put one or more quality flags on the string datum.
	For example, consider a column of galaxy names, or object id's which are strings. 
	The origin of those values might be flagged in terms of "original", "myOwnId", etc.

	But thats not a terribly strong case to make for strings. I prefer the following 
	instead: Yes, its true that you cant multiply and divide strings. But you can map 
	them to  numerical values that are operable in that fashion (use-case below). 
	The simplest way to achieve this is to insure that the "mapping" interface
	takes a "quantity" (class/interface) that includes strings. 

	Use-case: Consider that the string quantity "M31" might be mappable to a 
	numerical  quantity "Sky Coordinates" that has Ra, Dec that you may operate on.
	This allows a search for "M31" to auto-matically expand to a coordinate search
	(or, in cases vice-versa).

	Regards,

	-b.t.



-- 

  * Dr. Brian Thomas 

  * Code 630.1 
  * Goddard Space Flight Center NASA

  *   fax: (301) 286-1775
  * phone: (301) 286-6128