MCT - model document delivery.

[Markus Demleitner]

Dear DM, again,

Another reply I had saved until other subthreads had died down; again,
let me just quickly round this off for the archive after
http://mail.ivoa.net/pipermail/dm/2020-September/006127.html

On Fri, Sep 18, 2020 at 05:23:22PM +0200, Laurent Michel wrote:
> You seem not be aware about the documentation role of the models I
> mentioned in my former message.  If you consider that an error is
> just a value, you do not need any model at all, just a UCD.  If you

No, a UCD is not enough to reliably group a value and its error.
Consider the schema of the arihip.main table on the TAP service
http://dc.g-vo.org/tap (http://dc.g-vo.org/tap/tables/arihip.main for
browser consumption).  There, you have multiple
pos.eq.ra/stat.error;pos.eq.ra pairs, and a client could not
confidently say which value belongs to which error.

This, incidentally, is another instance of why the original idea of
using FIELD/@utype and PARAM/@utype for DM annotation hasn't worked.

> want to go deeper in the modeling, you have to build a class
> hierarchy and the annotation must able to restitute that hierarchy.

That is true, too; a good example in the meas case would be that in
addition to my proposed NaiveError (value/error) we would, over time,
grow GaussianDistributedMeasurement, LognormalDistributedMeasurement,
MeasurementWithMomenta, and probably quite a few more.

But that doesn't mean that we cannot avoid cross-model dependencies
most of the time.

> The mapping you propose below is correct as long as it is related
> to the minimalist model you have in mind.  But you could never
> twist MCT to make it mapped that way.

Well, I volunteer for trying in the later TCG discussion; and looking
at slide 9 of your Groningen presentation
(https://wiki.ivoa.net/internal/IVOA/InterOpOct2019DM/A_Component_and_Association__URLFixed.pdf)
I think even if we're not quite on the same page yet, it seems to me
we're at least in the same chapter.

        -- Markus