Difference: Polarization (8 vs. 9)

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

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->