<div dir="ltr"><div class="gmail_default" style="font-size:small">Hello DMers,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">At the recent Sydney Interop we discussed the path for CAOM to become an IVOA standard. It became clear from Mark's talk about the DM landscape that there is overlap between various DM efforts and CAOM would contribute to that... with the resulting complexity/confusion for users/consumers of the WG outputs.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">At the same time, there are efforts to extend ObsCore (radio: advanced, time series: in progress, high energy: starting) and I heard at least a few people question whether the "ObsCore" and "extension" concepts made sense or were in fact conflicting concepts. There's clearly some ambiguity there that needs to be cleared up.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Also, there is an immediate effort in the SKA Regional Center Network (SRCNet) collaboration to build the initial v0.1 prototype network and that includes observation metadata.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I have consulted with new and current CAOM stakeholders and we have collectively agreed on the following path forward:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1. modify the current CAOM (2.4) model to align better with other IVOA models</div><div class="gmail_default" style="font-size:small">2. modify CAOM to better support radio metadata (CADC and SRCNet use cases)</div><div class="gmail_default" style="font-size:small">3. clear alignment so that ObsCore is a "data model view" of CAOM</div><div class="gmail_default" style="font-size:small">4. deliver prototype implementations asap4. deliver WD-CAOM-2.5 by approx Sept (2024)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The current operational data centers (CADC, ESAC, MAST, IPAC) accept that #1 above will create a level of incompatibility and therefore require a larger amount of work to adapt from the current version (2.4), which has been stable and operational for 5 years. We are willing to make that additional effort in order for CAOM to be a better fit in the IVOA. If successful, I can say with a high level of certainty that a "CAOM Relational Mapping" for TAP could follow shortly after as a separate standard.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">With respect to items 1 and 3 above, there is considerable overlap with current active work in the DM WG and we are willing and able to engage with those other efforts as soon as possible.</div><div class="gmail_default" style="font-size:small"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div></div>