MCT - model document delivery.

[Laurent MICHEL]

Hello,

I'm a bit worry by the depth of disagreement. So I'll try clarify, in my 
perspective, the role of the different items that are questioned in this 
thread.

To me, the first purpose of a model is to document a knowledge domain. 
The model has to give a "Formal  description of the quantities used by 
the experts in a domain" (see my talk at last virtual interop) .
This is what Meas/Coord does. It makes distinctions between different 
sorts of measures (e.g. a sky position is not a polarization state) by 
setting different data classes and by providing accurate descriptions of 
the space frames these classes are related to.

Off record: I was a bit doubtful at the beginning of MC about the number 
of abstractions levels in Coords, but, while working on MANGO, I 
understood the power of that scheme that easily supports extensions. I'm 
sorry to cite myself again, but I showed up this point in my Source-DM 
talk  at the last Interop.

The tricky point is to figure out how a model can be used to annotate data.
Contrary to what many people believe, there is no need reproduce the 
whole model in each data file, but just to put the parts that are 
relevant in that peculiar case.

Let's take an example:
- Although Coords model describes what a Sky frame is, data providers 
must keep free not to repeat this in each VOTable. They just need to say 
that RA/DEC are in ICRS, considering that everyone, both human and 
machine, know what ICRS is. There no need to spend time to repeat again 
and again that e.g.  RA is something ranging from 0 to 360, even if it 
is stated by the model.
- From another hand, if my data set have fluxes in a given energy band 
(mission dependent data frame), I must be able to specify in my data 
sets what this energy band is, and the model allows this.

Thus, the key point is to keep a relatively loose coupling between the 
model and the annotation. The annotation must operate as a bridge 
between model elements and client needs.

Sorry again to cite myself again.. I'm working on a concrete 
implementation of these ideas along with MANGO (see ModelInstanceInVot 
on GitHub - work in progress)

In conclusion, I believe that the comments on the models must be 
restricted to the way use-cases are modeled and validated by reference 
implementations.

The annotation discussions, difficult point if any, shouldn't block this 
process.

LM


Le 04/09/2020 à 16:52, CresitelloDittmar, Mark a écrit :
> All,
> 
> My apologies for the delay in announcing these.  A few weeks ago, I 
> delivered updates to the STC-2.0 component models to the IVOA 
> repository.  I neglected to provide the updated schema and vo-dml 
> products, so will need to follow-up on that.
> 
> Below is the current status of the models:
>    * all models have corresponding example file suite serialized in 
> (VOTable, AnnotatedVOTable, XML) in volute
>    * for Meas and Coords, I'd say these are about as far as I can take 
> them.. the TCG is looking for more hands-on application before approving 
> the models, that depends on external (ie 'not me') implementations being 
> developed and providing feedback.
> 
> Coords-1.0 <http://www.ivoa.net/documents/Coords/20200310/index.html> ( 
> 10/Mar/2020 )
>    * updated to RFC comments
>    * made formal comparison of the model against AstroPy
>      o posted to STC2 twiki page 
> <https://wiki.ivoa.net/twiki/bin/view/IVOA/STC2>
>         + comparison writeup (pdf) 
> <https://wiki.ivoa.net/internal/IVOA/STC2/CoordsComparisonwithAstroPy-200702.pdf>
>         + comparison diagram (png) 
> <https://volute.g-vo.org/svn/trunk/projects/dm/STC/Coords/doc/diagrams/Coords_AstroPy.png>
>    * Topics
>       o Epoch: astropy includes epoch as a representation of Time, while 
> the Coords model does not include it under TimeStamp
>          ** we don't necessarily need to, but thought I'd point it out.
>       o Space-centric Point
>          ** these were specifically requested to be removed during RFC, 
> but Astropy does include them (and Frame-centric interfaces), and MANGO 
> model development has expressed that these maybe should exist.
> 
> Meas-1.0 <http://www.ivoa.net/documents/Meas/20200413/index.html> ( 
> 13/Apr/2020 )
>    * Updated to RFC comments
>    * Topics:
>       o I don't believe there are open topics here..
> 
> Trans-1.0 <http://www.ivoa.net/documents/WCSTrans/20200803/index.html> ( 
> 03/Aug/2020 )
>    * Updated with internal review comments, and to make use of Meas 
> model enhancement.
>    * Topics:  there are a few open suggestions from the author review 
> which I thought could wait to implement after broader review
>      o "Unit" transform: rename "Identity" to avoid name clash with 'units'
>      o M,N in Matrix transform -> row, column
>      o specifically mention that this model does NOT cover the 
> frame/property/representation level of transforms
>         + equatorial -> galactic
>         + energy -> wavelength
>         + date -> mjd
>         + FITS paper IV: time transformations
> 
> 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
---