POL (Re: About the draft itself Re: WD-SIA-2.0)

[Patrick Dowler]

On 14/04/14 01:00 PM, Arnold Rots wrote:
> Since polarization is an enumerated axis, I think POL=I,Q,U,V should be
> perfectly acceptable, but POL=I/V is not.
> Note that by explicitly endorsing Stokes parameters, other polarization
> expressions (circular, linear, vector) are excluded.

Querying the polarization axis for (ObsCore) pol_states that are present 
in the data is not straightforward.

Using repeated parameters (as is done when you pick multiple things from 
a picklist), eg:

POL=I
POL=Q
POL=U

would generally mean that the data has to contain at least one of these. 
Changing that behaviour is wide-reaching and DAL has long ago (Nara, 
iirc) decided to use this in place of comma-separated lists for multiple 
input values. Using a range construct, eg:

POL=I/U

would mean the same thing and find the same data (in this particular 
example but not for all). In a TAP+ADQL query of the ObsCore table, one 
could look for exactly IQUV with

pol_states like '/I/Q/U/V/%'

as described in ObsCore-1.0 B.6.6 (no wildcard at front because I is 
first in the canonical ordering). That would do what people want, 
leading me to think that

POL=I Q U V

(suitably separated and/or encoded) is the right way to say "search for 
data with all of these states".

Now the mess: ObsCore-1.0 says that the separator between pol_state 
values is the slash (/) character and range querying in DAL also uses 
the / character. The first was essentially an adhoc decision; the second 
comes from previous use in DAL services and is based on some external 
param-based query spec (can't recall, was in geoscience, iirc) where / 
was used because it is straightforward to split  and doesn't interfere 
with scientific notation, ISO8601 timestamp values, etc.

Technically, the ADQL constraint would be: pol_states like '/I/Q/U/V%' 
and the POL parameter cannot use that string.

So, is searching for exactly I Q U V easily supported in the POL 
parameter? If in a single parameter, what separator? Is that a general 
pattern for other enumerated fields (personally: I doubt it: I have not 
run into another enumerated field with multiple values like pol_states)


PS - In my opinion, any special treatment means we are in for some 
complex language and a single very peculiar parameter if we try to 
support this. I think we should stick with multiple values and ranges 
and if someone needs more explicit query capability they can/should use 
TAP, where the hard and general problems are dealt with.

-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2E7

250-363-0044 (office) 250-363-0045 (fax)