MCT - model document delivery.

[Markus Demleitner]

Dear Laurent,

On Thu, Sep 17, 2020 at 03:02:22PM +0200, Laurent MICHEL wrote:
> Le 17/09/2020 à 12:13, Markus Demleitner a écrit :
> > 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.

But then the VO-DML and the model *does* matter for how clients will
deal with the annotations, which is why I'm whining about nested,
entangled DMs and pleading for relatively flat, independent ones.
Let me give you an example in roughly the syntax of
ModelInstanceInVOT, where you have a catalogue with a position and
photometry:

  <FIELD name="ra"/>
  <FIELD name="ra_err"/>
  <FIELD name="dec"/>
  <FIELD name="dec_err"/>
  <FIELD name="mag"/>
  <FIELD name="mag_err"/>

What I would like to see in the end is something like:

  <INSTANCE type="meas:NaiveMeasure">
    <ATTRIBUTE role="expectation" ref="ra"/>
    <ATTRIBUTE role="error" ref="ra_error"/>
  </INSTANCE>

  <INSTANCE type="meas:NaiveMeasure">
    <ATTRIBUTE role="expectation" ref="mag"/>
    <ATTRIBUTE role="error" ref="mag_error"/>
  </INSTANCE>

  <INSTANCE type="coords:Position">
    <ATTRIBUTE role="ref_frame" value="ICRS"/>
    <ATTRIBUTE role="latitude" ref="dec"/>
    <ATTRIBUTE role="longitude" ref="ra"/>
  </INSTANCE>

  <INSTANCE type="phot:PhotPoint">
    <ATTRIBUTE role="band_name" value="G"/>
    <ATTRIBUTE role="value" ref="mag"/>
  </INSTANCE>

-- notice how all of position, photometry, and errors are annotated
without one annotation (or model) having to know anything about the
other.  A client interested in positions will easily find all
positions, a client interested in errors will easily find value/error
pairs (or later the distributions), and clients needing both still
have a rather easy time.

Which becomes really crucial when we will get a meas2 DM, in which
case you simply simply *add*:

  <INSTANCE type="meas2:NewNaiveMeasure">
    <ATTRIBUTE role="mean" ref="ra"/>
    <ATTRIBUTE role="uncertainty" ref="ra_err"/>
  </INSTANCE>

If you can pull off this latter trick with entangled DMs, I'll shut
up about Meas including Coords.  The central point being: We can't
have flag days in the VO, where everyone moves from one model version
to the next.  We will have to plan for something like a decade in
which an old and a new major version will be sitting next to each
other.  I don't like that myself, but if we can learn anything from
the last decade of the VO (where I've just succeeded this year in
purging the last ProtoSpectralAccess services), and of 40 years of
FITS evolution, it's that we ignore that requirement at our peril.

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

I'd be happy to help out on ModelInstanceInVot (full disclosure:
at this point I'd like to do away with TABLE_ROW_TEMPLATE, FILTER,
JOIN, GROUPBY, and the shortcuts, and I'd like to restrict inline
literals to strings and use PARAMs otherwise, but in all these points
I might be swayed).  

What if we had a Mapping telecon with the express goal of getting
implementors on board and seeing what we can still chip away?

         -- Markus