ranges

Clive Page cgp at star.le.ac.uk
Thu May 1 01:32:05 PDT 2003


On Wed, 30 Apr 2003, Robert Hanisch wrote:

> Having finally caught up on my e-mail, there is in my mind one major issue I
> would like some additional discussion on prior to the interop workshop.
> Elizabeth's AstroGrid prototype registry, Anita's document on frequency
> coverage, and Bob Jackson's previous work on telescope and instrument
> capabilities, all use range specifications for quantities such as bandpass
> coverage.  The RSM V.6 document generally does not do this.  In fact, I have
> a bit reluctant to put in specific metadata elements for upper and lower
> limits, as they are often poorly defined (what are the exact wavelength
> limits for various optical filters?), I am not sure they will be terribly
> helpful in locating data of interest, and they increase the burden on the
> data provider in registering their resources.  For example, I know that HST
> observations can be described as (near) IR, optical, and UV, but it would be
> non-trivial to say exactly what the lower and upper wavelength limits would
> be.  Moreover, if I were to select particular limits, say at lambda max of
> 9000 angstroms, and someone submits a query to the registry looking for data
> at 9005 angstroms, would we want to steer them away from HST?  I don't think
> so.

Bob et al.

Since I have argued in favour of the spectral ranges approach in the past,
maybe I can explain it, and defend it somewhat.

The main point of the Registry is to make every query a wanted query
(sorry about the political overtones of that phrase).  In your example the
important thing is to avoid the HST archive being pestered with queries
from folk who want, say, radio or x-ray data, which it cannot provide.
If we don't do this, every query will be sent to potentially hundreds of
sites.  The way to ensure that the HST archive _always_ gets queries it
_can_ help with, and avoids _most_ of the queries to which it cannot
respond, is for the HST archive's declared spectral range to be all
inclusive.  If there is any possibility that the HST archive could help
somone wanting data at 9005 angstroms, then the limits should be declared
to encompass this wavelength, and not just go out to 9000 angstroms.
There must be _some_ wavelength completely outside the HST's band which
can be used to ensure that radio/millimetre-wave/XUV/Xray/Gamma-raw
queries do not get passed on, but all others do.

The most obvious alternative would be to have a simple enumerated list of
wavebands, with each archive declaring which named band or bands it
covers.  This would be much simpler to set up, but somewhat less selective
in practice.  Maybe this doesn't matter much, and we should adopt it as an
interim solution?  The main problem I foresee is that we are likely to get
into interminable arguments over where the boundaries are between bands,
and how many named bands there should be.  If we distinguish between soft
and hard x-rays, what about medium-energy x-rays, don't they deserve their
own enumeration value?  And what about UV and IR etc.: do we just call
them soft/hard or near/far, or go for named bands (J, K, L etc)?  If I
thought that the community could agree on this in a finite time, I'd be in
favour of it, at least in the interim.

The other extreme is to have some method of registering the spectral
coverage of each archive or resource in detail.  Here I foresee that
debates on which units to use (MHz, Angstroms, eV?) and choice of
resolution might go on for years.  It's also hard to see how all this
information could be extracted in the first place, nor how it could be
stored in a Registry of modest size and complexity, unless the relative
resolution were rather low (in which case it doesn't provide much more
selectivity than the spectral ranges approach).

On balance, it seemed to me that the spectral range approach was a
reasonable compromise betwen these two extremes.


-- 
Clive Page,
Dept of Physics & Astronomy,
University of Leicester,    Tel +44 116 252 3551
Leicester, LE1 7RH,  U.K.   Fax +44 116 252 3311



More information about the registry mailing list