Follow up for my question in Characterisation Data Model RFC

[Fabien Chereau]

Hello Francois,

> A sensitivity on (x,y,lambda) can be such that it cannot be 
> expressed as a
> product of s(x,y)*s(lambda)... and then the bounds and central position
> cannot be so easilly inferred from the separated supports ....
>   X ray astronomers have some exmaples of that ,an we will assess that 
> for the
> next version ....

I agree, and this is unfortunately a problem which may require a large 
re-design of the model. In the general case, all the axes are 
inter-dependent and it becomes a bit strange to speak of spatial or 
spectral axes, when both cannot be separated.
Maybe the name "CharacterisationAxis" should be replaced by "Frame". 
Then it would be possible to define for each Frame all the properties 
for each axis. This is close to the way the AST library is designed 
(http://www.starlink.ac.uk/~dsb/ast/sun211.htx/sun211.html).

For example, in the AST vocabulary, the sensistivity (x,y,lambda) will 
then naturally be defined as a "Mapping" between the sky frame and the 
detector frame. Then, the central position can be very precisely defined 
in these 2 frames for example by defining it as the barycenter of all 
the projected positions of all the pixels of the dataset for all 
frequencies. We will thus end-up with one central position per frame: 
one in the sky frame which would be for example RA DE in degree, and 
another one in the detector frame which would be for example in mm.

I am aware that this goes far beyond what is described in the existing 
characterisation document so this is maybe more appropriate for a future 
release of it, but this kind of design would allow for a very large 
flexibility.

Cheers,
Fabien

> 
>  Cheers
> François
> 
> Fabien Chereau wrote:
> 
>> Hello,
>>
>> This was my question on the twiki 
>> (http://www.ivoa.net/twiki/bin/view/IVOA/CharacterisationDataModelRFC):
>>
>>> "Hello, instead of having many collections of Properties for each
>>> instance of Characterisation (like Resolution, SamplingPrecision
>>> etc..) one for each axis as shown in Figure 4, why don't you have
>>> only one collection of a CharacterisationAxis class which itself
>>> would contains the properties for this axis? I think it would make
>>> the design clearer. It is also convenient because to each
>>> CharacterisationAxis instance can be associated a single coordinate
>>> frame which also apply to each property."
>>>
>>> * Response (by IVOA.Mireille.Louys): The XML representation of the
>>> model has this feature , that is each CharacterisationAxis is a node
>>> underwhich we have the properties: coverage, resolution, Sampling for
>>> this axis. 
>>
>>
>>
>>> For the model we want to keep the symetry , the
>>> matrix-like design that is shown in the different examples. One could
>>> search / group the metadata in a Property first order and have , for
>>> example Resolution , for all axes, then Coverage, for all axes,
>>> etc... 
>>
>>
>>
>> I don't understand why we would want to order the metadata in a 
>> Property-first order since knowing what the value of the meta data is 
>> without knowing for which CharacterisationAxis it is associated is not 
>> very useful. For example in figure 4, if I go through the list of 
>> Resolution and find that the first element has a resolution of 5.78, 
>> it is meaningless if I don't know in which CharacterisationAxis (and 
>> thus coordinate system and unit) it is. So at the end we always need 
>> to link both, and it looks simpler to me if we decide that the 
>> properties for a CharacterisationAxis are just its attributes.
>>
>>> When the axes are not independant, that is Space depends on
>>> time, for instance, Resolution may be represented by a multi-variable
>>> function of all axes, and will be hooked in the Resolution Class.
>>
>>
>>
>> In the general (and real) case where the axes are not independent, 
>> having only one network of inter-connected generic 
>> CharacterisationAxis classes (with methods or attribute such as 
>> getCentralPosition, getBounds etc.) will be easier to manage than 
>> having many Property classes connected to each other. Especially 
>> because the properties of one axis are all derived from the same 
>> quantity (for example the bounds are just the min/max of the support, 
>> the Central Position is just the barycenter of the support etc..).
>>
>> Sorry if what I say is not very clear, I will try to explain what I 
>> mean with more details in a future email.
>>
>> Fabien
> 
> 
>