<div dir="ltr"><div dir="ltr">All,</div><div dir="ltr"><br><div> Thanks for another very productive meeting! Lots of attention on ObsCore Extensions this time.</div><div> Lots of good work going on! Mango has made a lot of changes, it'd be VERY helpful to give that</div><div> a read/review, even if you've done so before.</div><div><br></div><div>Mark</div><div><br></div><div><br></div><div><font face="monospace">Participants:<br> Mark Cresitello-Dittmar (MCD),<br> Mathieu Servillat (MS),<br> Paul Harrison (PH),<br> Mark Taylor (MT),<br> Bruno Khelifi (BK),<br> Gerard Lemson (GL),<br> Jesus Salgado (JS),<br> Mark Kettenis (MK),<br> Renaud Savalle (RS)<br><br> Contributions by email:<br> François Bonnarel (FB)<br> Laurent Michel (LM)<br></font></div><div><font face="monospace"><br></font></div><div><font face="monospace" size="4">Open Action Summary:</font><div><span style="font-family:monospace"> New actions</span><br style="font-family:monospace"><br></div><div><span style="font-family:monospace"> Carry-over actions</span><br style="font-family:monospace"><div><font face="monospace"> * </font><span style="font-family:monospace">[PH]</span><span style="font-family:monospace"> </span><span style="font-family:monospace">vo-dml 1.1 candidate list</span></div><div><font face="monospace"> - deliver summary of update candidates to DM mail list</font><span style="font-family:monospace">, (can reference git issues). </span></div><div><span style="font-family:monospace"> Please organize by the threads they support.</span></div><div><font face="monospace"> - set a timetable for steps moving forward, and send this to MCD/MS for the roadmap.</font></div><div><font face="monospace"> STATUS: In progress.. working twiki page (</font><a href="https://wiki.ivoa.net/twiki/bin/view/IVOA/VODML_1_1" target="_blank" style="font-family:"Helvetica Neue";font-size:13px">https://wiki.ivoa.net/twiki/bin/view/IVOA/VODML_1_1</a>)<font face="monospace"><br></font><font face="monospace"> * [MS] schedule ObsCore/Extension cross-group coordination meeting.<br> - This may wait for the next Radio Interest Group internal meeting to review </font></div><div><font face="monospace"> 'the plan' to move forward on the [Endorsed] Note, and then the relevant </font></div><div><font face="monospace"> working groups pick up content to integrate into the relevant standards.</font></div><div><font face="monospace"> At that point, it'd be good to have a meeting with RIG, TDIG, HEIG to </font></div><div><font face="monospace"> help define the paths each should take in producing content relevant to</font></div><div><font face="monospace"> those domains. i.e.: what should they be producing for the next interop.</font></div><div><font face="monospace"> * [MCD] bring the 'Shape' discussion to the DM mail list, with a goal to<br> gain consensus on where this model element should live in the DM ecosystem<br> * [MCD] bring vo-dml 'version' attribute to DM mail list for discussion.. </font></div><div><font face="monospace"> at least to form a plan IF the attribute is, in fact, needed for upcoming </font></div><div><font face="monospace"> vo-dml standard updates.</font><div><font face="monospace"><br></font></div><div><font face="monospace" size="4">Agenda Topics:</font></div><div><font face="monospace">ObsCore extensions from Interest Groups</font></div><div><font face="monospace"> [MS] provided review of the HEIG meeting discussion, highlighting that there </font></div><div><font face="monospace"> is a large percentage of the Radio Extension candidates that applies to</font></div><div><font face="monospace"> the HEIG domain as well. The HEIG will continue their work, focusing on </font></div><div><font face="monospace"> the domain specific extension items and any missing concepts in the </font></div><div><font face="monospace"> ObsCore + 'common extension items' set.</font></div><div><font face="monospace"> The DMWG job is to review the proposals, sort common elements, and work </font></div><div><font face="monospace"> the Standard updates.</font></div><div><font face="monospace"> The DAL WG should perform a complimentary review for the procedure for </font></div><div><font face="monospace"> accessing ObsCore Extensions.</font></div><div><font face="monospace"> Question: Who is editing this work?</font></div><div><font face="monospace"><br></font></div><div><font face="monospace"> [MCD] It is unclear, to me, that the radio group is OK with the goal of </font></div><div><font face="monospace"> delivering an Endorsed Note, rather than Standards updates..</font></div><div><font face="monospace"> o [MS] points out that the recent FB email suggested just this.</font></div><div><font face="monospace"> o [MK] agrees that is one path.. Q: what happens with the truly Domain </font></div><div><font face="monospace"> specific extension elements? </font></div><div><font face="monospace"> o [MCD] the DM group should review the Note and provide feedback</font></div><div><font face="monospace"> on the structure, to facilitate the migration from Note to Standards.</font></div><div><font face="monospace"> e.g. the "common" candidates should be separated from the "domain-</font></div><div><font face="monospace"> specific" candidates.</font></div><div><font face="monospace"> o [MK] we should probably discuss at the TCG level (especially the</font></div><div><font face="monospace"> question on how to discover extension content. These portions </font></div><div><font face="monospace"> of the Note will need to be picked-up by the appropriate group.</font></div><div><font face="monospace"> o [MK] RIG is holding a 'local' meeting to discuss the path and</font></div><div><font face="monospace"> see if this works from their 'client' perspective. They will</font></div><div><font face="monospace"> keep us informed on the outcome.</font></div><div><font face="monospace"> [JS] Reminder that extensions should be<span class="gmail-Apple-converted-space"> </span><b>extensions</b>... and not modify </font></div><div><font face="monospace"> existing content. We must be mindful NOT to break existing </font></div><div><font face="monospace"> imple</font><span style="font-family:monospace">mentations.</span></div><div><span style="font-family:monospace"> ** general agreement that we MUST consider the impact on implementations **</span></div><div><span style="font-family:monospace"> [MS] What is the status of the ObsCore Standard? Is there a plan/action </span></div><div><span style="font-family:monospace"> to port this to the ivoa-std repository?</span></div><div><span style="font-family:monospace"> o [PD] Porting the ObsCore standard it ivoatex is a TODO item</span></div><div><span style="font-family:monospace"> o<span class="gmail-Apple-converted-space"> </span><b>ACTION</b>: Create repository in ivoa-std for this project.</span></div><div><span style="font-family:monospace"> [MS] Extension implementation.</span></div><div><span style="font-family:monospace"> Markus has updated DaCHS to the radio extension content (incomplete,</span></div><div><span style="font-family:monospace"> but many).. this is the JIVE implementation FB references.</span></div><div><font face="monospace"> Question: What does Endorsed Note mean?</font></div><div><font face="monospace"> o [MCD] interprets as being a path for handling the use case, which </font></div><div><font face="monospace"> the IVOA supports, and perhaps encourages others to follow. But, </font></div><div><font face="monospace"> as a Note, is subject to change in any Standards updates to handle</font></div><div><font face="monospace"> the supported cases.</font></div><div><font face="monospace"> o [PD] as Endorsed, providers would/could start reviewing how to populate</font></div><div><font face="monospace"> the ObsCore elements in their databases. This could give them a </font></div><div><font face="monospace"> running start in providing implementations for the ObsCore standard</font></div><div><font face="monospace"> update. This would be helpful, it is always the hardest part.</font></div><div><font face="monospace"> o [MK] if we publish the Note and people develop to that, the same </font></div><div><font face="monospace"> problem of breaking implementations occurs if/when things move.</font></div><div><font face="monospace"> - if we only include the domain specific items, that would still</font></div><div><font face="monospace"> provide benefits over ObsCore 1.1.</font></div><div><font face="monospace"> ** Follow-up: HEIG could use help identifying exactly what they are to </font><span style="font-family:monospace">produce for the next interop.</span></div><div><br></div><div><font face="monospace">MANGO Update</font></div><div><font face="monospace"> There has been a lot of activity since the last meeting addressing Issues </font></div><div><font face="monospace"> submitted by MCD and MT. LM has sent an email summarizing the status of </font></div><div><font face="monospace"> update, along with Issues which remain open and why.</font></div><div><font face="monospace"> o [MT] It's looking better than it was. The prototype in TopCat shows proof-</font></div><div><font face="monospace"> of-concept of annotating data to support the epoch propagation use case.</font></div><div><font face="monospace"> Will update the implementation when new sample files are provided.</font></div><div><font face="monospace"> o [MCD] restatement of concern..</font></div><div><font face="monospace"> EpochPosition is a 2nd mode of representing content which can be done</font></div><div><font face="monospace"> with the Measurement types. This is generally considered bad practice.</font></div><div><font face="monospace"> I would be MUCH happier with the object if it were associated with </font></div><div><font face="monospace"> GAIA data, more than the "Epoch Propagation" use case. i.e. that it</font></div><div><font face="monospace"> is an object which supports the very complex GAIA (or GAIA-like) data</font></div><div><font face="monospace"> which the Measurements model is currently unable to support.</font></div><div><font face="monospace"> That would give providers/clients a more clear picture of WHEN to use</font></div><div><font face="monospace"> this Object over the PhysicalProperty representation.</font></div><div><font face="monospace"> o [MCD] my current focus is on making sure that there is proper documentation </font></div><div><font face="monospace"> of the model coverage in implementations so things can move forward.</font></div><div><span style="font-family:monospace"> ** I may be reading into things, but I felt there was a general agreement that </span></div><div><span style="font-family:monospace"> the object IS very GAIA-based and that may not be a bad idea.</span></div><div><br></div><div><font face="monospace">CAOM Integration</font></div><div><font face="monospace">[PD] We conducted a focus meeting last week which covered some of the lower level </font></div><div><font face="monospace">CAOM/VO-DML topics:</font></div><div><span style="font-family:monospace"> o extraction of datatypes from CAOM, and importing them in CAOM (e.g. Shapes)</span><br></div><div><span style="font-family:monospace"> o schematron warnings for open-ended multiplicities which is 'strongly discouraged'</span></div><div><span style="font-family:monospace"> but is really hard to do polygons without that. CAOM needs a Polygon model</span></div><div><span style="font-family:monospace"> so implementations have the same data structure for certain use cases.</span></div><div><span style="font-family:monospace"> o [GL] has been working a lot of polygons (geolocation) and there are standard</span></div><div><span style="font-family:monospace"> formats for polygons (strings) which are useful for databases</span></div><div><span style="font-family:monospace"> o [PD] format is reflecting the data model, and we want the same data structure</span></div><div><span style="font-family:monospace"> for interoperability.</span></div><div><span style="font-family:monospace"> o [GL] depends on the purpose of the object.. perhaps a standard string is</span></div><div><span style="font-family:monospace"> enough, similar to datetime.</span></div><div><span style="font-family:monospace"> o [PD] we do have a string format in DALI.. but that doesn't have a model </span></div><div><span style="font-family:monospace"> backing. There are some things which require the structure to be implemented</span></div><div><span style="font-family:monospace"> the same way.</span></div><div><span style="font-family:monospace"> o <discussion between PD, PH, GL> </span></div><div><span style="font-family:monospace"> - PH is opposed to removing the schematron check, it is valuable to </span></div><div><span style="font-family:monospace"> know that the practice is strongly discouraged</span></div><div><span style="font-family:monospace"> o [GL] real, integer vs long, int, double, float.. we don't specify that as</span></div><div><span style="font-family:monospace"> this is a serialization issue, outside the model concern.</span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">Next Meeting:</span></div><div><span style="font-family:monospace"> Mar. 18, 2025 @ 15:00 UTC</span></div></div></div><br class="gmail-Apple-interchange-newline"></div></div>
</div>