DM Workshop wrap-up
Gerard Lemson
glemson1 at jhu.edu
Wed Jul 21 19:40:07 CEST 2021
Hi Mark
We introduced a single VODML element containing the mapping prescription for a whole VOTable for various reasons.
One was to have all the mapping annotations close together under one element that could easily be inserted, or ignored.
We also assumed that a VOTable document would be quite coherent, with TABLEs related to each other through a common mapping.
Having also shared "GLOBAL" elements, say coordinate frames or so in a common area might benefit reusability.
And having all annotations at the start could facilitate setting up a data structure for storing instances obtained from the TABLE elements before needing to deal with those.
I guess one might argue that a RESOURCE could be such a coherent set of tables and that various RESOURCE elements could each have their own VODML annotation, which would only apply to the TABLEs in that RESOURCE.
The xs:any currently comes after all the TABLEs in the xs:sequence defining the RESOURCE's content though. Though it could come in a RESOURCE inside and at the start of the parent RESOURCE...
Note btw that in the very first iteration of the VO-DML mapping we had mapping annotations distributed throughout the VOTable.
Each table would define GROUPs representing VO-DML instances/objects, possibly we'd have some standalone GROUPs for the reference data.
That could have worked as well, I had code interpreting such annotations, but I feel having it separate has quite some benefits.
Gerard
> -----Original Message-----
> From: dm-bounces at ivoa.net <dm-bounces at ivoa.net> On Behalf Of Mark
> Taylor
> Sent: Wednesday, July 21, 2021 12:59
> To: Tom Donaldson <tdonaldson at stsci.edu>
> Cc: dm at ivoa.net
> Subject: Re: DM Workshop wrap-up
>
> Tom et al.,
>
> I haven't thought deeply about document structure in this context, but I'd be a
> bit cautious about mandating where such RESOURCE/VODML elements could
> appear; e.g. is it really only ever required to have a single VODML element in a
> VOTable document?
>
> One (admittedly non-standard) use case to consider: topcat can save a session
> in VOTable format. That takes the form of a single VOTable document
> containing all the (perhaps unconnected) tables (down)loaded or created by the
> user in the session, with in some cases associated metadata in RESOURCEs
> identified by obvious document scope rules (e.g. sibling elements to the TABLE).
> If different VODML chunks are loaded for different input tables, I'd find it hard
> to serialize to a VOTable document in this way if it only permitted a single
> VODML element.
>
> On the other hand if there is only a single VODML element present alongside a
> TABLE or set of linked TABLEs in a given VOTable document, it's usually pretty
> straightforward to find it during SAX or DOM processing, without really needing
> detailed rules for where to look.
>
> So: if there's a strong case for requiring such rules then go ahead, but I'd
> hesitate to impose them just because it looks tidy.
>
> One rule that might be important: require the VODML to appear earlier in the
> document than its associated table data, so that streaming processors can use
> it to pull out the relevant objects as they are streamed, rather than having to
> buffer the XML content.
> I don't know if that actually makes sense, but I can imagine it might do.
>
> Mark
>
> On Wed, 21 Jul 2021, Tom Donaldson wrote:
>
> > Hi All,
> >
> > Thanks, Mark, for looking into that. This does seem promising. I would like to
> do a few experiments with our existing parsers/validators to be sure, but it
> seems good.
> >
> > If we use this approach I would propose that we give strict guidance on the
> RESOURCE where VODML content lives. Since RESOURCEs can show up all
> over the place in a VOTABLE, I think it would be good to mandate things like:
> >
> >
> > * Only one such RESOURCE
> > * Only one possible location (e.g., the first RESOURCE)
> > * With well-defined scope (most likely it should be a top-level stand-alone
> RESOURCE, not nested in or containing other RESOURCEs)
> > * With type="meta"
> > * With a specific ID and/or name?
> >
> > Thanks,
> > Tom
> >
> >
> > From: <dm-bounces at ivoa.net> on behalf of Laurent Michel
> > <laurent.michel at astro.unistra.fr>
> > Date: Wednesday, July 21, 2021 at 11:39 AM
> > To: Mark Taylor <m.b.taylor at bristol.ac.uk>
> > Cc: "dm at ivoa.net" <dm at ivoa.net>
> > Subject: Re: DM Workshop wrap-up
> >
> > External Email - Use Caution
> > Hell all,
> >
> > This would be a very clean solution.
> >
> > - Gerard proposed to rephrase the XSD in order to isolate complexTypes from
> elements which should make easier the validation in the context of a VOTable.
> > - We have been using XSD1.1 (with Python) because the merged syntax put
> many constraints on element attributes. This is a key point of the proposal. I do
> not think that such rules could be set with XSD1.0
> > - The xerces web site does not look worry about this
> (https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxerces.a
> pache.org%2Fxerces2-j%2Ffaq-
> xs.html&data=04%7C01%7Cglemson1%40jhu.edu%7C74a602833c354b6d0
> a5008d94c68d1ed%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7C6376
> 24835924280042%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bu%2BI
> XB2xZqIEe%2BKbNjgN26UggDq7gy1seOo60hjE%2BtU%3D&reserved=0<htt
> ps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.
> com%2Fv3%2F__https%3A%2Fxerces.apache.org%2Fxerces2-j%2Ffaq-
> xs.html__%3B!!CrWY41Z8OgsX0i-WU-
> 0LuAcUu2o!nQi4ELtSSzKUpZjOVSCN0rLK20EZWxEHU8Fskrp9js4kx9qVU47SL56je
> 5h6c5iFdQ%24&data=04%7C01%7Cglemson1%40jhu.edu%7C74a602833c3
> 54b6d0a5008d94c68d1ed%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%
> 7C637624835924290035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=
> xIYz%2FHlebIJ3JCNHVIzGVDeQRUl%2F1rTnCdC3o2aVJRA%3D&reserved=0
> >) but I've no experience with this code
> > - I've no idea about how could this fit with volint either.
> >
> > Best
> > Laurent
> >
> >
> >
> > On 21 Jul 2021, at 17:02, Mark Taylor
> <m.b.taylor at bristol.ac.uk<mailto:m.b.taylor at bristol.ac.uk>> wrote:
> >
> > François,
> >
> > Yes, I think that use of the xs:any type is the right way to go here.
> >
> > However, that is already accommodated by the VOTable schema as it stands.
> > Quoting from
> > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > ivoa.net%2Fxml%2FVOTable%2FVOTable-
> 1.4.xsd&data=04%7C01%7Cglemson1
> >
> %40jhu.edu%7C74a602833c354b6d0a5008d94c68d1ed%7C9fa4f438b1e6473b8
> 03f86
> >
> f8aedf0dec%7C0%7C0%7C637624835924290035%7CUnknown%7CTWFpbGZsb3
> d8eyJWIj
> >
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C100
> 0&am
> >
> p;sdata=iVMLop%2BBpGxwZkjs%2BLuux695EpRDbmiP1cKzSPdDk2o%3D&r
> eserve
> > d=0:<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >
> Furldefense.com%2Fv3%2F__https%3A%2Fwww.ivoa.net%2Fxml%2FVOTable%2
> FVOT
> > able-1.4.xsd%3A__%3B!!CrWY41Z8OgsX0i-WU-
> 0LuAcUu2o!nQi4ELtSSzKUpZjOVSCN
> >
> 0rLK20EZWxEHU8Fskrp9js4kx9qVU47SL56je5i1_43vxg%24&data=04%7C01
> %7Cg
> >
> lemson1%40jhu.edu%7C74a602833c354b6d0a5008d94c68d1ed%7C9fa4f438b1
> e6473
> >
> b803f86f8aedf0dec%7C0%7C0%7C637624835924290035%7CUnknown%7CTWF
> pbGZsb3d
> >
> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C
> >
> 1000&sdata=PKu2oq4%2FXr98QCYtbs49f1W1mEGDXeB%2B1IcuTH82XEA
> %3D&
> > reserved=0>
> >
> > <xs:complexType name="Resource">
> > ...
> > <!-- Suggested Doug Tody, to include new RESOURCE types -->
> > <xs:any namespace="##other" processContents="lax" minOccurs="0"
> maxOccurs="unbounded"/>
> > ...
> > </xs:complexType>
> >
> > which means that the elements from the VODML schema can be included
> > within a RESOURCE element in a VOTable document, with no changes to
> > the VOTable standard required at all (thanks to Markus for pointing
> > this out).
> > So something like this should work out of the box:
> >
> > <VOTABLE version="1.4"
> >
> xmlns="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
> ww.ivoa.net%2Fxml%2FVOTable%2Fv1.3&data=04%7C01%7Cglemson1%4
> 0jhu.edu%7C74a602833c354b6d0a5008d94c68d1ed%7C9fa4f438b1e6473b803f
> 86f8aedf0dec%7C0%7C0%7C637624835924290035%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
> %3D%7C1000&sdata=q6wVHMPWWutgoCjmHrXUohzQON3Oi%2F4D%2Fo
> 1NOoesOOw%3D&reserved=0<https://nam02.safelinks.protection.outlook.
> com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2Fwww.ivoa.n
> et%2Fxml%2FVOTable%2Fv1.3__%3B!!CrWY41Z8OgsX0i-WU-
> 0LuAcUu2o!nQi4ELtSSzKUpZjOVSCN0rLK20EZWxEHU8Fskrp9js4kx9qVU47SL56je
> 5h2xvKE0w%24&data=04%7C01%7Cglemson1%40jhu.edu%7C74a602833c
> 354b6d0a5008d94c68d1ed%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0
> %7C637624835924290035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdat
> a=pTHmkmPvE1UkuKj7x%2FBivNFLdVZPWpgm%2BNffjpncCVw%3D&reser
> ved=0>"
> >
> xmlns:dm="https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%
> 2Fwww.ivoa.net%2Fxml%2Fvodml&data=04%7C01%7Cglemson1%40jhu.ed
> u%7C74a602833c354b6d0a5008d94c68d1ed%7C9fa4f438b1e6473b803f86f8ae
> df0dec%7C0%7C0%7C637624835924290035%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> 7C1000&sdata=RL8ooMHCr%2BlhccKENZIO0ShAO7Z92m9peq6wGaK3dJs
> %3D&reserved=0<https://nam02.safelinks.protection.outlook.com/?url=htt
> ps%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2Fwww.ivoa.net%2Fxml%2
> Fvodml__%3B!!CrWY41Z8OgsX0i-WU-
> 0LuAcUu2o!nQi4ELtSSzKUpZjOVSCN0rLK20EZWxEHU8Fskrp9js4kx9qVU47SL56je
> 5iiGyvehQ%24&data=04%7C01%7Cglemson1%40jhu.edu%7C74a602833c3
> 54b6d0a5008d94c68d1ed%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%
> 7C637624835924290035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=
> GCB%2FTqN%2BYGFtYTAvEZBLfUY5JginuxyqPpQ6tjELORU%3D&reserved=
> 0>">
> > <RESOURCE type="meta">
> > <dm:VODML ...>
> > <MODELS>
> > </MODELS>
> > ...
> > </dm:VODML>
> > </RESOURCE>
> > <RESOURCE type="results">
> > <TABLE>
> > ...
> > </TABLE>
> > </RESOURCE>
> > </VOTABLE>
> >
> > A VOTable document like that validates for me under the VOTable 1.4
> > schema (e.g. xmllint -noout -schema VOTable1.4.xsd). At present
> > votlint
> >
> (https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sta
> rlink.ac.uk%2Fstilts%2Fsun256%2Fvotlint.html&data=04%7C01%7Cglemso
> n1%40jhu.edu%7C74a602833c354b6d0a5008d94c68d1ed%7C9fa4f438b1e6473
> b803f86f8aedf0dec%7C0%7C0%7C637624835924290035%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C1000&sdata=KHEwoOWxKdf3Z7SEfZTxfMQykj%2BsqADxNJc
> otN%2F5wyM%3D&reserved=0<https://nam02.safelinks.protection.outlook
> .com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2Fwww.starli
> nk.ac.uk%2Fstilts%2Fsun256%2Fvotlint.html__%3B!!CrWY41Z8OgsX0i-WU-
> 0LuAcUu2o!nQi4ELtSSzKUpZjOVSCN0rLK20EZWxEHU8Fskrp9js4kx9qVU47SL56je
> 5iXtd5-
> Iw%24&data=04%7C01%7Cglemson1%40jhu.edu%7C74a602833c354b6d0
> a5008d94c68d1ed%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7C6376
> 24835924290035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kKW5y
> 5AdIV4Pwas2tz7ok8xyasy3jR91746ZAgBgl6w%3D&reserved=0>) does
> complain:
> >
> > WARNING: Element in wrong namespace
> > (https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> >
> ivoa.net%2Fxml%2Fvodml&data=04%7C01%7Cglemson1%40jhu.edu%7C74
> a6028
> >
> 33c354b6d0a5008d94c68d1ed%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%
> 7C0%7
> >
> C637624835924290035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIj
> >
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RL8ooMH
> Cr%2B
> >
> lhccKENZIO0ShAO7Z92m9peq6wGaK3dJs%3D&reserved=0<https://nam02.
> safe
> > links.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F
> > __http%3A%2Fwww.ivoa.net%2Fxml%2Fvodml__%3B!!CrWY41Z8OgsX0i-WU-
> 0LuAcUu
> >
> 2o!nQi4ELtSSzKUpZjOVSCN0rLK20EZWxEHU8Fskrp9js4kx9qVU47SL56je5iiGyveh
> Q%
> >
> 24&data=04%7C01%7Cglemson1%40jhu.edu%7C74a602833c354b6d0a500
> 8d94c6
> >
> 8d1ed%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7C6376248359242
> 90035%
> >
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> iI6Ik
> >
> 1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=GCB%2FTqN%2BYGFtYTAvEZB
> LfUY5Jgin
> > uxyqPpQ6tjELORU%3D&reserved=0> not
> > https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.i
> >
> voa.net%2Fxml%2FVOTable%2Fv1.3&data=04%7C01%7Cglemson1%40jhu.
> edu%7
> >
> C74a602833c354b6d0a5008d94c68d1ed%7C9fa4f438b1e6473b803f86f8aedf0d
> ec%7
> >
> C0%7C0%7C637624835924290035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC
> 4wLjAwMD
> >
> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=q
> 6wV
> >
> HMPWWutgoCjmHrXUohzQON3Oi%2F4D%2Fo1NOoesOOw%3D&reserved
> =0<https://
> > nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.c
> >
> om%2Fv3%2F__http%3A%2Fwww.ivoa.net%2Fxml%2FVOTable%2Fv1.3__%3B!!
> CrWY41
> > Z8OgsX0i-WU-
> 0LuAcUu2o!nQi4ELtSSzKUpZjOVSCN0rLK20EZWxEHU8Fskrp9js4kx9qV
> >
> U47SL56je5h2xvKE0w%24&data=04%7C01%7Cglemson1%40jhu.edu%7C74
> a60283
> >
> 3c354b6d0a5008d94c68d1ed%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7
> C0%7C
> >
> 637624835924300028%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD
> AiLCJQIjo
> >
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bdfcHh5NG
> wUGh
> > Z9TfrGZ4Qw23gP69e68DteSHCXsbEo%3D&reserved=0>)
> >
> > but that's really a votlint bug that I will fix.
> >
> > I would certainly favour this approach rather than adding new VOTable
> > elements, to avoid unnecessary coupling between the VODML and VOTable
> > standards.
> >
> > Concerning the xsi:type="mapping:VODML-type" attribute:
> > as I understand it, that wouldn't work with a schema in the form of
> > the one at
> >
> >
> > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Fivoa-
> std%2FModelInstanceInVot%2Fblob%2Fmaster%2Fschema%2Fxsd%
> > 2Fmerged-
> syntax.xsd&data=04%7C01%7Cglemson1%40jhu.edu%7C74a602833c
> >
> 354b6d0a5008d94c68d1ed%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0
> %7C63
> >
> 7624835924300028%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> CJQIjoiV
> >
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MG3xn8eqU
> EzPkSG
> >
> c9oI7APBvwqsIm7h0rHRG99VR9pU%3D&reserved=0<https://nam02.safeli
> nks
> >
> .protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__htt
> > ps%3A%2Fgithub.com%2Fivoa-
> std%2FModelInstanceInVot%2Fblob%2Fmaster%2Fs
> > chema%2Fxsd%2Fmerged-syntax.xsd__%3B!!CrWY41Z8OgsX0i-WU-
> 0LuAcUu2o!nQi4
> >
> ELtSSzKUpZjOVSCN0rLK20EZWxEHU8Fskrp9js4kx9qVU47SL56je5jFLJq0uQ%24&
> amp;
> >
> data=04%7C01%7Cglemson1%40jhu.edu%7C74a602833c354b6d0a5008d94c68
> d1ed%7
> >
> C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7C637624835924300028%7
> CUnkno
> >
> wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiL
> >
> CJXVCI6Mn0%3D%7C1000&sdata=n%2BC2oImfMx2ND5X%2F%2F6Ihp208
> NwRI5G1aG
> > BedDH0xtTE%3D&reserved=0>
> >
> > since that defines elements directly and not types (Gerard queried
> > this stylistic decision during the DM workshop session #4).
> >
> > So I'm not quite sure how validation of the embedded VODML would
> > proceed: either the schema could be rephrased to define types, or
> > perhaps XSD validators are able to determine the required contents
> > based on the <VODML> element name without requiring an xsi:type.
> >
> > One other point on the current merged-syntax.xsd: use of XMLSchema
> > 1.1, instead of 1.0, makes it harder to validate using some tools.
> > Java support at least is not so good for XSD 1.1, so I don't know
> > whether votlint would be able to provide XSD validation for VODML if
> > it was defined using this schema.
> >
> > Mark
> >
> >
> >
> > On Fri, 16 Jul 2021, BONNAREL FRANCOIS wrote:
> >
> >
> > Hi all,
> > Considering the VOTAble schema versioning issue, with the "import"
> > of a mapping syntax which may evoluate on its own I wonder i something
> > like the following could work.
> > 1 ) in next VOTABLE schema version, create a "VODML" tag inside
> > VOTable of type "anyType" (minoccurs = 0 of course)
> > 2 ) in VOTABLE documents type this VODML tag with an
> > xsi:type="mapping:VODML-type" , with "mapping" xmlns defined as the
> > last version of the mapping xml schema (can be done with attributes of
> > the VODML
> > tag)
> > 3 ) as far as I remember this would make the two schemata
> > independant and does not require that VOTABLE documents import the
> > mapping schema
> >
> > Do you think it could work ?
> >
> > Cheers
> > François
> >
> > Le 15/07/2021 à 11:36, Laurent Michel a écrit :
> >
> > Dear DM,
> >
> > Last Tuesday we had our last DM workshop meeting.
> > This concluded a fruitful 7-month process whose main conclusions and
> > prospects are listed below.
> >
> > An overview of the work done has been presented by LM
> > (https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwik
> > i.ivoa.net%2Finternal%2FIVOA%2FDm2021%2FMAY2021-
> ws41.pdf&data=04%7
> >
> C01%7Cglemson1%40jhu.edu%7C74a602833c354b6d0a5008d94c68d1ed%7C9f
> a4f438
> >
> b1e6473b803f86f8aedf0dec%7C0%7C0%7C637624835924300028%7CUnknown
> %7CTWFp
> >
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn
> >
> 0%3D%7C1000&sdata=1BxjiMvgiWa%2B24ynZG3RlA6yJV59CVlLKyGupx6B
> tNU%3D
> > &reserved=0<https://nam02.safelinks.protection.outlook.com/?url=ht
> >
> tps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwiki.ivoa.net%2Fintern
> a
> > l%2FIVOA%2FDm2021%2FMAY2021-ws41.pdf__%3B!!CrWY41Z8OgsX0i-WU-
> 0LuAcUu2o
> >
> !nQi4ELtSSzKUpZjOVSCN0rLK20EZWxEHU8Fskrp9js4kx9qVU47SL56je5jMh_tCrQ
> %24
> >
> &data=04%7C01%7Cglemson1%40jhu.edu%7C74a602833c354b6d0a5008d
> 94c68d
> >
> 1ed%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7C637624835924300
> 028%7C
> >
> Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1h
> >
> aWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FvJ7wwK5ROYILwInAb5zutsqV
> 3hDepiy
> > 2SkSI4tAU0s%3D&reserved=0>
> > <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwik
> > i.ivoa.net%2Finternal%2FIVOA%2FDm2021%2FMAY2021-
> ws41.pdf&data=04%7
> >
> C01%7Cglemson1%40jhu.edu%7C74a602833c354b6d0a5008d94c68d1ed%7C9f
> a4f438
> >
> b1e6473b803f86f8aedf0dec%7C0%7C0%7C637624835924300028%7CUnknown
> %7CTWFp
> >
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn
> >
> 0%3D%7C1000&sdata=1BxjiMvgiWa%2B24ynZG3RlA6yJV59CVlLKyGupx6B
> tNU%3D
> > &reserved=0<https://nam02.safelinks.protection.outlook.com/?url=ht
> >
> tps%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwiki.ivoa.net%2Fintern
> a
> > l%2FIVOA%2FDm2021%2FMAY2021-ws41.pdf__%3B!!CrWY41Z8OgsX0i-WU-
> 0LuAcUu2o
> >
> !nQi4ELtSSzKUpZjOVSCN0rLK20EZWxEHU8Fskrp9js4kx9qVU47SL56je5jMh_tCrQ
> %24
> >
> &data=04%7C01%7Cglemson1%40jhu.edu%7C74a602833c354b6d0a5008d
> 94c68d
> >
> 1ed%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%7C637624835924300
> 028%7C
> >
> Unknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1h
> >
> aWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2FvJ7wwK5ROYILwInAb5zutsqV
> 3hDepiy
> > 2SkSI4tAU0s%3D&reserved=0>>)
> >
> > Conclusions in short
> > ================
> >
> > . Models:
> > . Meas, Coord, PhotDM, Dataset, Cube and MANGO accepted . New
> > use-cases to be investigated . X-RAY Astronomy . Asteroids, multi-core
> > datasets . CTA and MM astronomy : meta-data characterization
> >
> > . Data Provider / client specific use-cases . Need for annotations to
> > help processing spectra . Need to associate parameters . Need for a
> > simple description of the photometric calibration . Need for a simple
> > view on Provenance . Annotation on the fly feasible . Model-based PyVO
> > API easy to design
> >
> > . Mapping syntax
> > . Divergence between the 2 proposals (VODML mapping and
> > ModelInstanceInVot) . Proof of concept for a YAML serialization of
> > model instances
> >
> > Annotation
> > =========
> > An important effort has been made over the last 6 weeks to merge the 2
> > syntax proposals:
> > . see on
> > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Fivoa-
> std%2FModelInstanceInVot&data=04%7C01%7Cglemson1%40j
> >
> hu.edu%7C74a602833c354b6d0a5008d94c68d1ed%7C9fa4f438b1e6473b803f8
> 6f8ae
> >
> df0dec%7C0%7C0%7C637624835924300028%7CUnknown%7CTWFpbGZsb3d8e
> yJWIjoiMC
> >
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a
> mp;sd
> >
> ata=erfP%2FUIHFkQGzokSNioJCp6Id5xeLxH0iNJGzC6wxLA%3D&reserved=
> 0<ht
> > tps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldef
> > ense.com%2Fv3%2F__https%3A%2Fgithub.com%2Fivoa-
> std%2FModelInstanceInVo
> > t__%3B!!CrWY41Z8OgsX0i-WU-
> 0LuAcUu2o!nQi4ELtSSzKUpZjOVSCN0rLK20EZWxEHU8
> >
> Fskrp9js4kx9qVU47SL56je5gbe7QepA%24&data=04%7C01%7Cglemson1%
> 40jhu.
> >
> edu%7C74a602833c354b6d0a5008d94c68d1ed%7C9fa4f438b1e6473b803f86f8
> aedf0
> >
> dec%7C0%7C0%7C637624835924300028%7CUnknown%7CTWFpbGZsb3d8eyJW
> IjoiMC4wL
> >
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&s
> data
> >
> =g9IPxIIRbF%2BOSFqTlEEQwwDZE41IyUTtYh%2BcZYJXeTw%3D&reserved=
> 0>
> > <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
> > hub.com%2Fivoa-
> std%2FModelInstanceInVot&data=04%7C01%7Cglemson1%40
> >
> jhu.edu%7C74a602833c354b6d0a5008d94c68d1ed%7C9fa4f438b1e6473b803f8
> 6f8a
> >
> edf0dec%7C0%7C0%7C637624835924300028%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiM
> >
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> amp;s
> >
> data=erfP%2FUIHFkQGzokSNioJCp6Id5xeLxH0iNJGzC6wxLA%3D&reserved
> =0<h
> > ttps://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furlde
> > fense.com%2Fv3%2F__https%3A%2Fgithub.com%2Fivoa-
> std%2FModelInstanceInV
> > ot__%3B!!CrWY41Z8OgsX0i-WU-
> 0LuAcUu2o!nQi4ELtSSzKUpZjOVSCN0rLK20EZWxEHU
> >
> 8Fskrp9js4kx9qVU47SL56je5gbe7QepA%24&data=04%7C01%7Cglemson1
> %40jhu
> >
> .edu%7C74a602833c354b6d0a5008d94c68d1ed%7C9fa4f438b1e6473b803f86f8
> aedf
> >
> 0dec%7C0%7C0%7C637624835924300028%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4w
> >
> LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> sdat
> >
> a=g9IPxIIRbF%2BOSFqTlEEQwwDZE41IyUTtYh%2BcZYJXeTw%3D&reserved
> =0>>
> >
> > . 3 items available so far:
> >
> >
> >
> > --
> > Mark Taylor Astronomical Programmer Physics, Bristol University, UK
> > m.b.taylor at bristol.ac.uk<mailto:m.b.taylor at bristol.ac.uk>
> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.star.
> bristol.ac.uk%2F~mbt%2F&data=04%7C01%7Cglemson1%40jhu.edu%7C74
> a602833c354b6d0a5008d94c68d1ed%7C9fa4f438b1e6473b803f86f8aedf0dec%
> 7C0%7C0%7C637624835924300028%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> amp;sdata=0evmzZ3hUC1v85acY6OyDbjSxzDUzhh6AECD1pKZ7BY%3D&res
> erved=0<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Furldefense.com%2Fv3%2F__http%3A%2Fwww.star.bristol.ac.uk%2F*mbt%2F__
> %3Bfg!!CrWY41Z8OgsX0i-WU-
> 0LuAcUu2o!nQi4ELtSSzKUpZjOVSCN0rLK20EZWxEHU8Fskrp9js4kx9qVU47SL56je
> 5gnFcabKg%24&data=04%7C01%7Cglemson1%40jhu.edu%7C74a602833c3
> 54b6d0a5008d94c68d1ed%7C9fa4f438b1e6473b803f86f8aedf0dec%7C0%7C0%
> 7C637624835924310024%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=
> rwEXRHLHC7lDVFmVlEXut5Pblrv1g0hYSH0Jn6NQtFI%3D&reserved=0>
> >
> >
>
> --
> Mark Taylor Astronomical Programmer Physics, Bristol University, UK
> m.b.taylor at bristol.ac.uk
> https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.star.
> bristol.ac.uk%2F~mbt%2F&data=04%7C01%7Cglemson1%40jhu.edu%7C74
> a602833c354b6d0a5008d94c68d1ed%7C9fa4f438b1e6473b803f86f8aedf0dec%
> 7C0%7C0%7C637624835924310024%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&
> amp;sdata=8sP2%2BzTzgSrOwMFtaOBWkowMXHpss26HmuiUh8Oo2KM%3D&a
> mp;reserved=0
More information about the dm
mailing list