MCT - model document delivery.
Gerard Lemson
glemson1 at jhu.edu
Fri Sep 18 20:02:26 CEST 2020
HI
Sorry to jump in, I will try to find time to follow this thread.
> 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.
>
I don't know what mapping approaches you are referring to, but I do want to remind people that there has been a proposal for mapping out for some 7 years now.
In a number of incarnations that tried to accommodate feedback from the community, it provides a rigorous approach how to identify model instances in votables or tap schems.
And it is most definitely NOT ad hoc and I'd be keen to participate in any calls on mapping in general and maybe reviving this effort.
Hopefully Markus' comments might lead to developing some of the concrete use cases we have been dearly missing.
Cheers
Gerard
>
> 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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> >> hub.com%2Fivoa-
> std%2FMANGO&data=02%7C01%7Cglemson1%40jhu.edu%7Cc6
> >>
> 8e5244507c4b156bd008d85be6cd31%7C9fa4f438b1e6473b803f86f8aedf0dec
> %7C0
> >>
> %7C0%7C637360394139457144&sdata=gD8ehB0pDwkvjD5TPhRVWIgh8i
> mN1LHdN
> >> kYBo1GBE9I%3D&reserved=0
> >>
> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> >> hub.com%2Fivoa-
> std%2FModelInstanceInVot&data=02%7C01%7Cglemson1%4
> >>
> 0jhu.edu%7Cc68e5244507c4b156bd008d85be6cd31%7C9fa4f438b1e6473b803
> f86f
> >>
> 8aedf0dec%7C0%7C0%7C637360394139457144&sdata=L5FALHl30axBE%
> 2B4KpO
> >> u%2BoGnA6tg4jaNitm3BXZr3FKk%3D&reserved=0
> >
> > 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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.deepl.com%2Ftranslator&data=02%7C01%7Cglemson1%40jhu.edu%7
> Cc68e5244507c4b156bd008d85be6cd31%7C9fa4f438b1e6473b803f86f8aedf0d
> ec%7C0%7C0%7C637360394139457144&sdata=qX5E8kxO6Bm5bqKmxw
> PqXvrPyWiNp%2FfyipjH3YjWeJg%3D&reserved=0
> --
> 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
> <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fww
> w.unistra.fr%2F&data=02%7C01%7Cglemson1%40jhu.edu%7Cc68e5244
> 507c4b156bd008d85be6cd31%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7
> C0%7C637360394139457144&sdata=KzmYiivgBqS7vlC%2F4jrhzio4n1LzgQ
> kXfUnzKZxoT3w%3D&reserved=0>
> Observatoire Astronomique
> 11 Rue de l'Université
> F - 67200 Strasbourg
More information about the dm
mailing list