MCT - model document delivery.

[Laurent Michel]

Hello
Le 02/10/2020 à 09:29, Markus Demleitner a écrit :
> 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.

Totally agree on the diagnosis (a bit less on the drug you are proposing)

> 
>> 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.
I've nothing against having a NaiveError.
What I Really dislike is to accept people to say "you have here a Measure instance but as the error shape is not supported by 
Measurements take my NaiveError in replacement of this proposed by the model".

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

My Mango metaphor is more valid than ever.
I think we agree on the idea that, at least for sources, a model must be able to support different sets of parameters depending 
on the case.
This flexibility does not mean that we can put anything we want in the data annotations.
The Mango proposal provides an uniform way to get the exact role of each measure (UCD, class, vocab ...)
In addition , all supported measures are built upon the same template issued from M/C: the Meas-Coord-System triptych.
This homogeneity and consistency brought by the model has many advantages:
- It makes easier the annotation task since it can be done with a well defined component box and the way items are put together 
is perfectly documented.
- It ensures that all clients could "understand" any mapped quantity e.g. from any measure you can immediately get the frame 
just because the model says where it is and what does it look like.
- You are sure to be able to match measure by measure different data-sets mapped on that model.

Bye
LM

--
English version: https://www.deepl.com/translator
-- 
jesuischarlie/Tunis/Paris/Bruxelles/Berlin

Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg