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:
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.
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
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
Working Groups
Interest Groups
Committees