about galaxy "velocity cubes"

[François Bonnarel]

I think DM work has to be usefull for astronomers.
   -  So, Igor if data providers have data with radial velocities on the 
third axis and want to distribute like that, why should we oppose ?
    - from the Char DM point of view, a specific  axis (time, position, 
spectral etc ... )is always  a specialization of the generic time axis 
by fixing:
                -name attribute value
                -ucd attribute value
                -unit attribute
                - use of STC coordinates class instances with 
appropriate reference to STC coordsys instance
So, Arnold, it was always the intent (and it's done actually) to reuse 
STC where it is needed in Char
DM. I think STC model Recom don't make Redshift (or any) coordinate 
mandatory in the coordinate
structure. So we have to add it if  and when we need it.
                - an last but not least, specific utype (TimeAxis, 
SpectralAxis, etc ....) (- this actually from
the model point of view is a role and from the xml serialisation pov an 
element name).
       In addition each "specific" axis may actually recover different 
observables, units, and (usual) names
Spectral axis eg can be (at the moment) in frequency, wavelength or 
photon energy.

     I see two possible solutions if we want to describe a redshift 
dimension :
          solution 1 : add the velocity or redshift "flavor" to spectral 
axis.
             This will require that usual name is "redshift", ucd the 
appropriate one, as well as unit and that
we reuse the redshift coordinate structure from STC with appropriate  
Coord system.

         solution 2: we define a new Redshift axis by adding a new 
RedshiftAxis utype (or UML role, or xml
element by type restriction) in  addition to the other attribute changes 
described in solution 1.

My understanding is that most people here would prefer solution 2. the   
main reason I guess is that
frequency and redshift are equivalent representation only if we consider 
a single line.

It's time to discuss this because the new version of characteriation 
which will be presented tommorrow can include this change...

Why dont' we push this discussion to DM, Mireille ?

Cheers
François

Le 07/12/2010 16:54, Roy Williams a écrit :
> I agree with Adam. It should be clear to the radio astronomers a 
> simple thing is sufficient. The only necessary metadata is 
> labeling/describing the axes of the cube, and providing min and max 
> values. The VO-supplied libraries should work with this simple 
> information and the VO registry. An interoperable representation of 
> the radio cubes in HDF5 or FITS would complete the picture, ways to 
> subset the cubes, access protocols for cubes, etc.
>
> The next level -- after acceptance of the above by the community -- 
> could allow computers to "understand" the meaning of the axes by 
> allowing complex metadata (utypes, STC, Char, semantic linking, etc 
> etc). Moving too fast on these advanced concepts could make the VO 
> look out of touch with real scientists.
>
> I suggest that "full metadata characterization" is not interesting to 
> 99% of scientists.
>
> Roy
>
>
> On 12/07/2010 6:33 AM, Adam Brazier wrote:
>> Yes indeed. The radio astronomers with whom I am working are excited
>> about the prospect of their data cubes being easily and directly
>> embeddable in VO protocols and any suggestion that they are "horribly
>> wrong" or the like is going to be met with reactive hostility and a
>> complete lack of compliance with whatever else we suggest.