Dear All,
The forthcoming meeting in Cambridge could be a good opportunity to discuss how "column groups" can be introduced in VOTable. Such a functionality was already expressed (maybe not explicitely); I feel that this it has also implication on UCDs, and I'm therefore posting this message to both VOTable and UCD groups. I apologize to those who will receive this message twice.
The "column groups" proposition tries to answer questions frequently
themail: Undefined variable
asked about column associations, typically:
--> error (or standard deviation) associated to a column, e.g. a flux
consists of two numbers: the measured value + the mean error
--> qualities or weights associated to values
--> source or origin (e.g. telescope, or bibliographical reference) of a value
--> individual components e.g. x,y position of a CCD
--> etc...
This "column grouping" has obviously the same role as defining structures made of columns; defining structures made of structures can also be viewed as grouping groups of columns.
I see essentially two ways of defining such "column groups" in VOTable:
<GROUP name="Flux" ucd="PHOT_FLUX_RADIO_8.4G">
<FIELD ID="Flux1" name="fluxValue" datatype="float" unit="mJy">
<DESCRIPTION>Value of the flux at 8.4GHz</DESCRIPTION>
</FIELD>
<FIELD ID="e_Flux1" name="errFlux1" ucd="ERROR" datatype="float" unit="mJy">
<DESCRIPTION>Error on flux value</DESCRIPTION>
</FIELD>
<PARAMETER ID="Freq1" name="Frequency" value="8.6" datatype="float"
unit="GHz" ucd="OBS_FREQUENCY" />
</GROUP>
There could be a third way which would introduce new tags within each table element like e.g. <VAL> and <ERR> to give <TD><VAL>11.35</VAL><ERR>1.12</ERR></TD> but it would be against the current philosophy of VOTable which defines all metadata first, and is followed by the data alone, in order to keep the efficiency and the FITS compatibility; this third method would also require frequent modifications of the schema (XMLSchema) -- generally disturbing for working applications.
The <GROUP> defined in b) above seems to me to be a good framework for this definition. I see several advantages: => the basic tabular scheme remains -- VOTable can still be viewed as a
relational database, and keeps a full compatibility with existing
FITS binary tables;
=> groups of groups (i.e. recursive <GROUP> tags) enables a definition
of arbitrary complex structures;
=> the UCDs become more accurate when defined in a group:
<GROUP name="Flux" ucd="PHOT_FLUX_RADIO_8.4G">
<FIELD ID="Flux1" name="fluxValue" datatype="float" unit="mJy">
<DESCRIPTION>Value of the flux at 8.4GHz</DESCRIPTION>
</FIELD>
<FIELD ID="e_Flux1" name="errFlux1" ucd="ERROR" datatype="float" unit="mJy">
<DESCRIPTION>Error on flux values, both at 8.4 and 7.5GHz</DESCRIPTION>
</FIELD>
<PARAMETER ID="Freq1" name="Frequency" value="8.6" datatype="float"
unit="GHz" />
</GROUP>
<GROUP name="Flux" ucd="PHOT_FLUX_RADIO_7.5G">
<FIELD ID="Flux2" name="fluxValue" datatype="float" unit="mJy">
<DESCRIPTION>Value of the flux at 7.5GHz</DESCRIPTION>
</FIELD>