MCT - model document delivery.
laurent.michel at astro.unistra.fr
Thu Sep 17 11:33:42 CEST 2020
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
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
The annotation discussions, difficult point if any, shouldn't block this
Le 04/09/2020 à 16:52, CresitelloDittmar, Mark a écrit :
> 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
> + comparison writeup (pdf)
> + comparison diagram (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
---- English version:
---- 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
More information about the dm