CaomIntegrationMtgNotes20250220 < IVOA

IVOA Web>IvoaDataModel>CaomIntegration>CaomIntegrationMtgNotes20250220 (2025-03-13, MarkCresitelloDittmar) (raw view)

---+ 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 <b>[DONE]</b>
   * [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
The notes are rather light this week, there was a good bit of discussion around the topics; here I'm providing just a snapshot.

*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 ==&gt; 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 [[http://www.opencadc.org/caom2/interoperable-profile.html]['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).

<!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->

Topic revision: r2 - 2025-03-13 - MarkCresitelloDittmar

IVOA

Log in or Register

IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics

Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki

TWiki intro
TWiki tutorial
User registration
Notify me

Working Groups

Interest Groups

Time Domain

Committees

Stds&Procs

www.ivoa.net
Documents
Events
Members
XML Schema