CAOM Integration Meeting: Mar. 12, 2025

Attendees:

• Mark C-D, Pat D., Paul H.

Highlights

• discussed diagram illustrating the multiple levels of representation for the Shape concept necessary to directly satisfy the requirements of CAOM and other models needing fuller descriptions.

Action Summary:

• [MCD] Upload diagrams for mapping elements from CAOM:Observation to Dataset:Observation
• [PH] brainstorm idea of identifying object(s) from one model being equivalent to object(s) from another model. (stemming from Shape representation discussion)
• [PD] add issue to vo-dml repository to add size-specific 'real' types to the base model, complete with the use-case description for justification.
• [PD] will extract Shape/Interval model from CAOM, and import it [DONE];
• [PD] review all CAOM vocabulary candidates for CAOM progression. These will need to get seeded by Semantics group.
• [PH] open Issue for VO-DML to modify the semantic concept description/fixture on Attribute. Similar to the ivoa updates, this may be wanted for VO-DML v1.1 to support this project
• [MCD] review Shape/Interval thread in context of other usage (Region, FOV, MANGO) [DONE]

Proposed Agenda

• Discuss feasibility of ObservationDataset metadata migrating to a CAOM Observation instance
• Multi-level representation of Shape concept.. overall impressions

Notes

The meeting was a bit short due to scheduling conflicts stemming from daylight savings change.

Shape representation

Discussion regarding the 3-level Shape Representations diagram

• [PD]: in databases, you want 1 copy of the things that don’t change.. so the Quantity is not applicable there.
• [MCD]: similar to Data Table.. where in serialization you can simplify the representation for efficiency... such as:
  • if the units apply to the column as a whole, serialize as an attribute on the column, otherwise need a separate column.
  • the FITS Green Bank convention to shrink a column of constant values to a single keyword
• [MCD]: perhaps the difference here is that in the general Table case, the action is an efficiency decision, but the full description is allowed, so the underlying model needs to remain the same; where in the database CAOM case, it is a REQUIREMENT of the application that they be constant.. thereby allowing a simpler model.
• [PH]: thinking about reusability of objects, it would be good to be able to import parts of other models (classes, packages). It would help clarify what the dependencies are, one wouldn’t have to import all of ‘coords’ if they only want coords:SpaceFrame.
• [PH]: also looking at the ‘Quantity’ vs ‘Basic’ representations; having a means to say these are equivalent would be handy from an auto-generation perspective.
  • [MCD]: noted this is along the lines of the questions discussed in recent interops..
• [PD]: for upcoming CAOM -> TAP mappings; it would be good to have variability in the “Profile”s between providers
  • this would help with the Energy/Wavelength type issues raised in the Radio Extension work
  • it would need sufficient information (from Meas/Coords) to support conversion of values to unify them during multi-provider queries.
    • typically on Energy axis so far, but maybe others.

Dataset:Observation - CAOM:Observation

• [MCD] shared images tagging Dataset Metadata attributes to the CAOM document (a quick pass matching, probably error prone)
  • Q: on matching layers from CAOM; which still confuses me a bit.
    • Plane = group of Data Products related to the Observation.
      • calibrationLevel is one thing which typically changes from Plane to Plane
    • Artifact = often a single file; or set of files which are a unit (eg Measurement Set)
    • Part = FITS block basically
    • Chunk = Image/(Column?) axis description + WCS
    • NOTE: Part and Chunk may not make the CAOM migration cut.
    • NOTE: I’m still not sure if my DataProduct is an Artifact or a Part. Probably for many they are pretty much 1-1
      • Maybe take a closer look at Artifact metadata vs Part metadata to help resolve that question.
• Went through the various mappings; in general seems good from PD perspective
  • ACTION: MCD post images on twiki page for review

Next Meeting:

• Mar. 19 at 16:00 UTC.