MCT - model document delivery.

[Laurent Michel]

Markus,

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 want to go deeper in the modeling, you have to build a class hierarchy and the annotation must able to restitute that 
hierarchy.

My approach for the annotation is to build a tree of XML elements that denotes the model structure (or a subpart of) and to tune 
the element attributes to connect the actual data.
So that I'm sure we can write generic code enable to reconstruct instances of any model and I'm confident we can facilitate the 
mapping process even for complex things.
I'm affraid that any other approach will lead to had-hoc annotations.

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.

Laurent

Le 17/09/2020 à 16:26, Markus Demleitner a écrit :
> 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
> 

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