Philosophy of basic Q (Was: Re: [QUANTITY] Data Model for Quantity v0.5
brian.thomas at gsfc.nasa.gov
Tue May 11 08:23:56 PDT 2004
On Tuesday 11 May 2004 02:22 am, Jonathan McDowell wrote:
> 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
> ".. 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.
> 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]
More information about the dm