Use case 3.8 is for discovery of data including polarization information.

Actually this use case has been reinforced by scientific needs of two communities: radio astronomy and optical spectropolarimetry... So how can we take into account this use case in ObsTAP?

I see three possible solutions:

• existence of Polarization information of the data could be considered as a subproduct type. Something like Subproduct-type: polarization.Stokes could be added to productype "Cube" or spectrum... By the way the same could be true for "Multi band" imaging, which could be another SubProductType... But what to do if SubProductType is not retained ?

• Actually the o_ucd field tells us what is the measured quantity on the observable (or functionally dependant) axis. the existence of polarization could be described by a UCD second word "polarization.stokes" concatanated with a phot.* ucd.

• With both solutions it will be possible to tell that polarization information is there but it will not be possible to give the list of polarization states actually present in the data. Characterisation version 2 (see Char2 DM presentation in Nara for details) proposes a new dedicated axis: polarizationAxis with an enumeration attribute. This attribute can describe the list of polarization states actually present in the dataset. A new optional field with utype Char.polAxis.enumeration could be added to the Query response to encompass this.

I think a pol_states field with a Char.polAxis.enumeration UType would be the right addition. However, polarization is not always measured as direct Stokes parameters. Should we have an enumeration of the Stokes parameters present, of non-Stokes parameters, or of deducible Stokes parameters?

-- JuanDeDiosSantanderVela - 07 Mar 2011

I agree, for example LL and RR data are not a Stokes type. Would it be simple to adopt Juan's solution, with an enumeration based on the FITS polarization axes labels (by code, not by number, i.e. I Q U V RR LL RL LR XX Y Y XY Y X POLI POLA UNDEF (see http://www.ivoa.net/Documents/Notes/Polarization/ which incidentally needs updating in the light of recent comments)?

-- AnitaRichards - 08 Mar 2011

I fully agree with Juan De and Anita there. But if we don't want this pol_states parameter to be mandatory we will convey minimal information with the o_ucd field. This one doesn't allow to give the full list however, but only the polarization "style".

-- FrancoisBonnarel - 15 mar 2011

To be more precise: - if we want to use the mandatory fields only o_ucd can be used to specify that phot.flux.density is completed by phys.polarization or phys.polarization.* - this is interesting for data discovery, but only the pol_states optional field can give us the full list of available polarization states in the data set.

-- FrancoisBonnarel - 16 mar 2011

In our internal model (CAOM) we do have polarization metadata. In the lower part of the model (generally not seen by users) we have the FITS WCS description of various axes. In the part devoted to discovery, we compute useful and queryable summary fields. For spatial WCS these are polygons and for polarization this is a string with the letter codes in the canonical order (eg order of Table 7 in FITS WCS Paper 1). The order is important to be able to look for multiple states in a single predicate:

WHERE pol_states LIKE 'I Q%RR%'

The only difference is that we decided to use a slash (/) separator in the string representation (inc leading and trailing double /) to help make queries consistent, clear and unambiguous:

example value: //I/Q/U// example value: //X/Y//

WHERE pol_states LIKE '%/Y/%'

matches only Y while

WHERE pol_states LIKE ''

would match Y, XY, YX, and YY. The double / at the ends is to make sure the % wildcard always has something to consume because iirc some RDBMSs behaved differently/non-standard in this regard -- and the user doesn't know if the value they want is the first or not unless it is I.

A space separator is more readable and technically it is equally usable, but it looks a lot more subtle:

WHERE pol_states LIKE '% Y %'

versus

WHERE pol_states LIKE ''

If we can specify the string representation, I think we should add pol_states to support the use case.

-- PatrickDowler - 2011-03-23