Axis identifier in the coords model

[Laurent MICHEL]

DM,



Le 20/05/2020 à 16:57, CresitelloDittmar, Mark a écrit :
> Laurent/All,
> 
> I'm really glad to see you working through these questions!
> 
> ============================================================
> The reasoning for the current representation..
> 
> The previous version of the Coords model had explicit references from 
> the Coordinate to the associated Axis as well as the CoordFrame.
> This revision combined the CoordSpace(containing Axis-s) + CoordFrame 
> into CoordSys, and Coordinate now references CoordSys.
> 
> So, there is a path from Coordinate to the associated Axes via CoordSys, 
> as you noted.
> 
> Rather than having 2 paths from Coordinate to Axis, which may be out of 
> sync, the direct relation between them was removed, and the Point.axis# 
> values MUST map to the CoordSpace axes, in order.
A bit dangerous taking into account that e.g. JSON dict are not ordered.

Why not having a sibling Space class.
Point{axis1:real, axis2:real, axis3:real}
	==> PointAxes{axis1:Axis, axis2:Axis, axis3:Axis}
Binding things by attribute names is not worst the using indices and it 
is safer.

> 
> ============================================================
>  From here, I think the discussion may branches a bit into 'how are the 
> models to be used?'.
> Where do things need to be 'modeled'?, and what are serialization issues?
> For example:
>    would it be sufficient for the model to be as-is, but allow the 
> serialization to help bridge the gap to assist applications?
>       A VOTable serialization could use the UCD to tag each Point.axis* 
> value with "pos.eq.ra", "pos.eq.dec"  which applications could queue on 
> to *shortcut* tracing the model elements through the 
> CoordSys.SpaceFrame.refFrame and CoordSys.SphericalCoordsSpace.Axis[] .  
> If absent, they'd have to trace the path manually.
>    OR, if we concede that this is a very common action for applications, 
> is the model REQUIRED to provide the information at that point?
> 
> The model has iterated between these two points of view.
> 
> I don't know the answer to this, but it seems to me that this is the 
> sort of question that we are currently trying to resolve, with the 
> Mapping Syntax discussion, the Transform implementation project, and 
> your CAB-MSD work.
Coords model is a very exhaustive description of the coordinates that is 
built on abstract classes.
To know the purpose of a coordinate, you have to explore its description 
(Frame + Space). There no place where it is stated that "axis2" is a 
"longitude", because "longitude" is a word and, as I understand, Coords 
dos not identify things with words (ucd or whatever) referring to some 
common knowledge.
However, it is obvious that annotated data won't carry such a fine grain 
description.

Let's take the example of sky positions (class Point) which are the main 
concern here.
All clients, either machine or human, know what latitudes and longitudes 
are. This is a common knowledge that does not need to be repeated 
everywhere.
The problem comes when the data annotation process has to interpret data 
classes, e.g. to understand that "axis1" is actually a "Longitude". This 
requires some sort of inferences (or model interpretation at least) that 
shouldn't be part of that process.

To overcome this difficulty, CAB-MSD uses 2 tricks:
- UCDs on all parameters
- Use of classes extending MCT
    - Measure not natively supported by MCT
    - LonLat sky coordinate because this is most used coordinate and it 
must be identifiable very easily.

With this approach, I manage to get a straightforward model translation 
into VODML annotations.

Laurent
> 
> Mark

-- 
---- English version:
      https://www.deepl.com/

---- Laurent MICHEL              Tel  (33 0) 3 68 85 24 37
      Observatoire de Strasbourg  Fax  (33 0) 3 68 85 24 32
      11 Rue de l'Universite      Mail laurent.michel at astro.unistra.fr
      67000 Strasbourg (France)   Web  http://astro.u-strasbg.fr/~michel
---