MCT - model document delivery.
laurent.michel at astro.unistra.fr
Thu Sep 17 15:02:22 CEST 2020
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
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
As Mango makes abusive use of MC classes, this work could join the
reference implementations of both models.
-- still not WDs yet --
> -- Markus
---- 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