WD-AccessData-1.0-20140312

Wed Mar 19 06:43:47 PDT 2014

Hi

without digging into the syntax subtleties  I just will present my view of 
scientist who is supposed to work with stuff .
It concerns the query phase (and so SIAP) as well - the paragraphs about 
BAND in both docs seem to be identical

And IMHO it is quite misleading to show example of BAND = 500 meters !
more realistic (and optical centric ;-) whould be to give examples in 
something as  BAND=6300e-10/6700e-10

Especially you will show the numbers can contain e or E ? (should it be 
in capitals ?)
Everyone will undestand quickly it is about Halpha.
Or if you want to be more radio-centric select some nice line of CO or 
neutral Hydrogen (I am not expert on this) perhaps 0.21 m

The term "energy" in connection with the statement
"Energy values used in BAND ... are asumed to be barycentric wavelength"
is absolutely confusing and incorrect

I would suggest use term like "spectral  intervals"  spectral ranges ...
or even "spectral axis range, interval" With a explanation for other folks
  that the energy band in Xray must be converted to wavelengths

The same confusion in SIAP 2.0 doc.

As I understand the X-ray must use it as well so e.g the band instead of 
in keV would need to be in Angstroems (e.g 10e-10/12e-10 for XMM newton 
strong Ne line :
see 
http://xmm.vilspa.esa.es/external/xmm_links/trainee/2004/jenny.shtml
).
-------

Now to the BAND with symbolic names of bandpasses

I think the complicated translation by client from table of bandpasses to 
numeric range cannot simple work as you expect.
It is nice to have consistent protocol but the product must be useful for 
science !

As I understand the SIAP and Accessdata should serve not only to extract 
ALMA flatten datacubes but the normal collection of images as well .
The polarisation images are special case of datacube - they may be exposed 
(quasi) simultaneously  as well as multi-band photometry.

So it is natural to allow the symbolic names both for the image taken with 
special filter if it is half or quater wave plate, Wollaston prism or 
colour blocking filter. I do not see difference between U,B,R,V   filter names 
and U,Q "filter" names

THIS is the primary input information - the name of filter - (and will be 
written in FITS header from which you extract the metadata)

So for data discovery I may state interval of all visible light 
3000e-10/9000e-10  and I will get all images in different filters.

But when I want to get only and only the V band image (to compare it with 
the catalogue magnitude available) I need to select it by name!

In principle I may say in query  BAND=5500e-10 and it should return
all image containg that wavelength. So I can get both Johnson V and 
Stromgren "y". But I want to have only that stromgren !

If I say I have discovered several images in given wavelegth range I need 
to extract the particular one. So I need dataaccess to state that symbolic 
name which will extract that "datacube plane" from the multicolor 
(multiextension) image.

>> 
>> I believe Petr is thinking about multi-extension files and getting
>> just one extension out of this, referenced by band name.  I agree
>> this is an interesting use case, as the question what the "right
>> thing" to do when e.g., doing cutouts from multi-extension files is
>> tricky indeed and needs to be worked out before we REC anything on
>> data access services.  But the difficulty is, at least for me,
>> retrieval semantics and not parameter syntax.

I would say that so far the standards are written only by informaticians 
(which want the have the things consistent") for informaticians. But no 
real science case was taken in consideration. Many times it is stated that 
those docs should address 95% of science cases. (Chapter 1.2.1 in SIAP and 
very vaguely 1.2.1 in Accessdata) What is a rationale for such a 
statement? I would say that most typical (scientific) query is give me 
images in given place in GIVEN FILTER.

The  query for "energy range" is natural in case of spectra (and hence 
points to SSAP) - But we are talking rather on Images.
The number of SSA services is a order less than SIAP services !

> another name. The use cases we have to support clearly require that search 
> (in SIA query) and simple cutout (in AccessData) using numeric energy values.
>
> We chose BAND because that was used before, but we can chose something else. 
> If we want to reserve BAND for known energy band names or somesuch simlair 
> usage then we could do that. LAMBDA would not be my first choice for a 
> numeric energy parameter for a variety of reasons:
>
> - looks optical-centric and radio and high energy people scoff and go away
What about WAVE ?

But I would say both folks should know quite well what it means (see my 
example above - even the Xray people must use angstroem sometimes - the 
energy is not convenient always) - e.g. the energy and WAVE are inversely 
proportional which makes it convenient for particular longer range in some 
graphs (it is similar to logarithmic values of WAVE in radial velocity or 
redshift plots - the points are better sampled)

But take it in opposite way - the ENERGY looks to much X-ray centric and 
optical folks will run way ;-)
It will enforce the feeling of many "classical" astronomers that VO is 
something for HEP and sattelite bussiness and is not worth of try ....

> I recall someone proposing FRAVERGY in the past... I would prefer:
>
> BAND (numeric)
> BANDNAME (string) -- not in the current versions, maybe later

This is quite consistent and clearly understandable for everyone.

So I do not understand WHY you cannot simply allow both values for 
discovery and access - one is enumerated strings (the string could be even 
number like "25" if I know hwat it means - name of famous filter etc ...)

WHY to postpone it later ?

Both standards (SIAP 2 and access) are still at the begining and adding 
the several lines of text would calm most of the criticism what would sure 
appear immediately when the people start to use it in clients.

> it is just not what users ask for, if I can judge by what the astronomers 
> that use our apps ask for... they want fewer boxes/params with a bit more 
> power in them. That is what ranges (and geometry in POS) gives them and they 
> can use them effectively.

But here the second box with band name allows for much more advanced 
queries and the client NEED NOT to built extremely complicated translation 
mechanism involving mapping bandnames to numbers (which will never succeed 
fully ). It simplifies the matters a lot and gives all the reponsibility 
to hands of user.:

Of course still the characterization metadata should somehow translate 
bandnames into the spectral ranges to be conformant with metadata 
requirements. But it is the derived and hence not the primary information 
that may be quite rough not satisfying the science needs.

If I know exactly what I am searching for I can use BANDNAME (and I 
suppose the VO publisher has cleverly converted what is written in header 
by instrument maker). All I simply know the Sloan images are in 'z' band 
so I simply ask for 'z' to find other surveys using the same set of filter 
(many of them use the same)

If I am looking blindly for anything in optical region I can use the BAND 
with values  - I can use the obscore em_min em_max as well

--------------
So I would add the chapter to both docs stating the BANDNAME is a list of 
symbolic names (strings) of various filter names (including names of 
common X-ray channels) and give example of query with BAND=U,B,V or 
BAND=u,g,r,i,z

here in principle does not make sense define intervals - but you have it 
for polarisation as well so it does not matter.

The last more philosophical comment:

If you are seraching for  POL=I will you return (in discovery) only the 
polarimetric measurements (that have the polarimetric mode) or ALL 
observations as they are by definition in I state (=unpolarized) ?
...

*************************************************************************
*  Petr Skoda                         Tel   : (323) 649201, l. 361      *
*  Stelarni oddeleni                          (323) 620361              *
*  Astronomicky ustav AVCR, v.v.i     Fax   : (323) 620250              *
*  251 65 Ondrejov                    e-mail: skoda at sunstel.asu.cas.cz  *
*  Ceska republika                                                      *
*************************************************************************