Follow up for my question in Characterisation Data Model RFC

Arnold Rots arots at
Thu Jun 21 13:41:07 PDT 2007


I think what you are pointing at is the difference in approach between
Characterisation and STC.
The organization of the metadata that you are advocating is found in
native STC.


  - Arnold

Fabien Chereau wrote:
> Hello,
> This was my question on the twiki 
> (
> > "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
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at

More information about the dm mailing list