CAOM Integration Meeting: Feb. 20, 2025

Attendees: Mark C-D, Pat D., Paul H.

Highlights

• discussed muiplicity usage in COAM and how that relates to vo-dml and rules for auto-generating databases.
• review of CAOM overlap with the various standards.

Action Summary:

• No new actions this meeeting
• [PD?] add issue to vo-dml repository to add these 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)

Proposed Agenda

• Details of the overlapping areas and plans to accommodate them
• VO-DML multiplicity specification in practice

Notes

Mapping Model to Databases

• MCD/PD: started off with a conversation about multiplicity and the Polarization node in CAOM
• PH: would be good to have a set of standard rules.. for generating DB tables from the UML
  • Composed ObjectTypes with multiplicity 0..1 or 1..1 can be collapsed into a single table with many rows
  • Composed ObjectTypes with multiplicity 0..* or 1..* can not.. they MUST be a separate table
• These rules could define the resulting database and schema associated with it within the toolkit
  • From rules + model, one could generate the schema (tap schema).
  • modulo some details ( primitives selected, etc ) that are DB brand specific
• [PH]: currently not a good way to map the complex DataType to a single column (the storage needs to be fixed)

Overlapping Models

• Proposal DM - CAOM proposal info is a very high level summary of proposal info - Dataset.Proposal.identifier ==> attribute with type = URI?
• Provenance DM - CAOM provenance is probably more like 1-step provenance (describes the previous step only)
• ObsCore * obvious * Not sure if ‘view’ as a model concept is worth pursuing…?
• Characterisation * Don’t need both CAOM characterisation elements AND Characterisation. * some discussion about whether or not it should be extracted from CAOM for reuse.. * once you import something, then changing is hard. If models share content, and one branches in a different direction, then that shared thing becomes very complicated. * Characterization doesn’t have a well defined purpose outside of its use within ObsCore. Perhaps when the DataProduct usage becomes a topic, the extraction can be revisited. If the usage is different enough, the objects may just be similar, but different.
• Coords * CAOM specifically tries not to state what the representation is for time, space, energy,.. * coordinate system metadata is outside.. would be good to allow different implementations to make different choices. (by domain) * A 'profile' provides the constraints applied to the data so that this information is not necessary in the fields (shapes, etc) * This is not available to the TAP schema, so intimate knowledge of the fixed values is required.
• Spectrum * not much overlap there.. any ties to ObsCore via UTypes?
• Dataset: * much of the metadata is considered: metadata extracted from a resource (like CAOM) describing the Observation details, and carried along with the DataProduct for reference and to aid the analysis threads * can this simply carry an instance of CAOM? * ACTION: MCD review details of ds:ObservationDataset content vs the caom content to see if that is an option.

Next Meeting:

• Next meeting in 2 weeks due to vacation schedule. (3/05).