Philosophy of basic Q (Was: Re: [QUANTITY] Data Model for Quantity v0.5

[Brian Thomas]

On Tuesday 11 May 2004 02:22 am, Jonathan McDowell wrote:
> Brian,
>  You make some proposals for changes to Q.
>
>  (1)  You propose adding Accuracy to BasicQ.
>
>   I don't like this for the same reason I don't like mappings in BasicQ:
>   the idea behind BasicQ was to make something really simple that
>   would not be much more than a name and a value and a unit (which
>   we can currently stick in a single FITS keyword). We added the
>   full Frame for various technical reasons. But I would prefer
>   not to add anything else. Otherwise, the distinction between
>   a BasicQ and a CoreQ becomes less useful.

	Well, my concept of BasicQ (and I don't think I'm alone on this)
	is that it was for _holding a single value_, not to make something
	"really simple". Yes, I have said as much to the quantity-editors
	before, but I think this point bears public "airing" as it strongly
	influences the use and development of the basic Quantity. I see the 
	following uses/needs which would drive use to have accuracy within basicQ :

	1. To insure that its possible to have one-to-one decomposition of
	higher dimensional Q's into a set of basic Q's. This functionality is
	very desirable from 2 standpoints :

		A. It allows someone with a higher-d Q to decompose it and pass it 
		along to a receiver (VO service/application) who will only understand basic Q's
		(because they use a package that doesnt implement them, etc).

		B. From Ed's (and my) experiments with searching Q-based documents,
		it is better to have them represented as basic Q's.

	2. From a philosophical standpoint : it should be able to hold a _scientific_ datum.
	 Without the possibility for having the accuracy described (e.g. "errors") it just isn't
	scientific.


>  ".. you have to allow the user the option to record the errors".
>
>   We do, the option is "Use a CoreQ". 

	This option doesn't work with the above needs "1" and "2".

> But the reality is that
>   there is a LOT of data out there with no known errors and
>  actually, the more I think about it, a lot of metadata that should
>  not have errors (CCD chip number, pixel position of a hot pixel,
>  (arguably) proposed RA and Dec of pointing, etc.). Certainly
>   the majority of integer and string metadata. Possibly some
>   floating point metadata representing requested values (although
>  I guess they could come with tolerances, they usually don't.)
>  And indeed, 99 percent of all FITS header metadata out there right
>  now is error-free for better or worse.


	I agree there is a lot of data without errors, but thats not a reason for
	modeling *all* data without errors. If all data lacked errors, then you
	would have a point. 

>  (2) You want to change add/remove/getValueQuantity
>                      to add/remove/getAlternativeValue.
>
>   I don't have a big problem with this.
>   I'm not so keen on removing the getCurrent... but if others
>   want to I'll go along with it.

	Lets leave this as a detail for IVOA.

	=b.t.

>
> OK, bedtime.
>
>  - Jonathan

-- 

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