MCT - model document delivery.

[Laurent MICHEL]

Markus,

Le 17/09/2020 à 12:13, Markus Demleitner a écrit :
> Dear Laurent,
> 
> On Thu, Sep 17, 2020 at 11:33:42AM +0200, Laurent MICHEL wrote:
>> 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.
> 
> 
> I freely admit that I've made my comments on all the various DMs
> under the assumption that once the VO-DML and the annotation document
> are in place, I will know how to annotate a VOTable, and I will know
> how to fetch the annotations from a VOTable, without having to resort
> to guesswork and without having to consult additional specifications.
> 
You emphasized on this point as often as you could, for sure.

> Do I understand you right that this is not what you have in mind?
> 
> And if I understand you right: How will you specify the annotation?
> Do you forsee additional, per-DM specifications that will tell
> implementors how to serialise instances?

No, I don't. The annotation must be model independent an it must keep 
consistent even when a part of the model only is mapped and clients must 
be clever enough to work with model subsets.

Let me summarize what I've in mind (and in Latex and in Python as well):

One recurrent criticism often made to the models (not only by you) is 
that they are lacking of concrete way to be tested on real data.

This is a well known endless loop in the VO:
- CLIENT DEVELOPER: I’ll implement model annotations when data providers 
will provide annotated data
- DATA PROVIDER: I’ll annotate my data when clients will be able to make 
advantage of them.
- BOTH: We won’t do anything while there is no recommended annotation 
syntax.

To break this loop, we are developing a mapping syntax named 
ModelInstanceInVot (see GitHub link below) that can be used on any VODML 
model. Notice that the VOMDL standard lets open the door for many 
different annotation mechanisms
Although not part of the MANGO project, this syntax is used to exercise 
it on real data.
It will be the subject of a specific proposal.
This syntax is derived from the proposal of Omar and Gerard, but 
revamped with Vizier and Provenance people with the hope of having 
something better suited for archival data and reasonably human-readable.
The basics of this proposal have been presented several time last 2 
years at Interop.
There is a draft, not completed yet but advanced enough for tolerant 
readers to get its substance.
There is also an XSD and Python code handling this syntax.
There are many unit tests showing how specific features are implemented.

The principle of this proof-of-concept-client is to translate XML 
mapping blocks into JSON structures that can easily be consumed by any API.
These JSON structures must be faith to model subsets in any cases.

After a preliminary test phase with Time Domain data, this syntax has 
been exercised with Mango on Vizier/XMM data and with Provenance on 
Vizier catalogs.

As Mango makes abusive use of MC classes, this work could join the 
reference implementations of both models.

Best
LM

-- still not WDs yet --
https://github.com/ivoa-std/MANGO
https://github.com/ivoa-std/ModelInstanceInVot

> 
>              -- Markus
> 

-- 
---- 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
---