CAOM Integration Meeting: Feb. 12, 2025

Attendees

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

Highlights

• discussed the addition of size-specific types to the base model to support CAOM use cases
• discussed the handling of shapes and intervals
• discussed vo-dml semantic concept vs IVOA vocabularies
• discussed handling of Custom data in CAOM (e.g. Faraday depth)

Action Summary:

• [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
• [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
  • CAOM - ObsCore/Ext - <Cube,Dataset,M,C,T>
• Extracting DALI datatypes to IVOA base model
  • adding a model backing for the serializations provided in DALI
• IVOA model refinement: cases where current options are problematic.
  • e.g. compatible implementations of CAOM have to choose the same primitive data types (e.g. double vs float) in order for a feature to function correctly, but the VO-DML model just says "ivoa:real". Same with int or long and "ivoa:integer"

Notes

We addressed the vo-dml and base types topics first:

Adding size specific integer and real types in the ivoa base model

CAOM has at least one use case (checksum calculation algorithm) which requires implementations to use the same size primitives for columns. This would be best conveyed if the base types model included these.

• PH: in the toolkit, xml serialization chooses one. Is this more-or-less an implementation level decision?
• MCD: If these are not base types and the model use case requires consistency in implementation, then something else in the CAOM model will have to require it. The reasoning for the generic 'integer' vs 'real' is because the size is generally irrelevant from the model point-of-view, and to avoid mappings which lean too much toward a particular implementation (different names for same sized integer (short vs int16) type of thing)
• PH: could use constraints..
  • general agreement that constraints would work, but they are open form, and not enforced by validation or implementable by machine generiated code.
  • this is not the preferred solution
• PD: can we have both available?
  • state (in the base model) that, in practice models should use the most flexible type that satisfies the requirements.
  • side note: this would apply to the use of Quantity in models as well
  • concern that this might open a floodgate of requests to add variations on these types.
    • these would need to be backed up by a firm requirement for including them
• our concensus is that the inclusion of the size-based (e.g. int32, int64, double) types to the base model is the preferred solution.
  • TODO: need to discuss the type names
• MCD: This change in the base model should happen sooner rather than later (i.e. would need to be part of the vo-dml 1.1 update).
• ACTION: [PD?] add issue to vo-dml repository to add these types to the base model, complete with the use-case description for justification.

xtypes in DALI migration to base model

DALI includes several xtypes which map to the base model primitives (e.g. timestamp -> ivoa:datetime ). It also includes shapes and intervals ( Point, Circle, Polygon, Interval ). These types are also in the CAOM model. Can we add these to the base types model for general usage? NOTE: this is the type itself, not the serialization thereof, which would remain in DALI.

• PH: probably better NOT in the base model, its not clear if these are primitive types. They seem in-between, from a code generation perspective. Suggests trying out in some experiments to see how they work in that context
• MCD: I'm still struggling to see how these would fold into the larger usage of Shape-s in a physical context. These shapes have no units, or physical context.. just hold values (real). There are several data models ( Region/Intervals from STC, FOV, MANGO ) which would want to add context "a Circle on the sky".
• PD: in CAOM (and TAP?) the context is a separate thing, provide by a profile that gives that information for the entire column.
  • This representation of Shape is geared towards data discovery; what is needed for data products and analysis may be a different model.
    • shape base type ( Circle, Polygon, Interval ).. just describing the shape, values for attributes are simple primitives (real)
    • can define a ShapeQuantity: associates the Shape with a unit.. can provide physical context for simple usecases
    • can use ShapeQuantity as the value for Region, and associate a coordinate space for full "Region on the SKY in ICRS" description.
  • MCD: this sounds like a promising path.. these could be defined in a Region model, filling out the replacement for those segments of STC
    • addendum to discussion: ShapeQuantity would naturally extend ivoa:Quantity, but I'm not sure it would be an ivoa:ShapeQuantity since it serves more specific usecases. As an extension of ivoa:Quantity, it would technically make it usable under Coordinates for individual coordinate values (e.g. LonLatPoint.lon ). This could be handy for specifying an Interval in a coordinate, but not so good for the Shapes. This may fall into the area of 'yes.. someone COULD do that, but they won't because it doesn't make sense.
• we have general agreement that the types should be extracted from DALI/CAOM to be reused as needed. Where that model lives is an open topic.
• ACTION: [PD] will extract it from CAOM, and import it.

VO-DML Semantic concept vs IVOA Vocabularies

CAOM modeling vocabularies as tagging. It has several 'enums' which may better be served by vocabularies, and many of them do overlap with existing vocabularies, but not all.

• ACTION: [PD] review all CAOM vocabulary candidates for CAOM progression. These will need to get seeded by Semantics group.
• MCD: same here.. in my models, I'm describing them as 'string' types whose value is pulled from the vocabulary at (url).
• PH: the vo-dml semantic concept is not well defined in th standard. It could be, and probably should be, modernized to sync up with the current usage of Vocabularies.
• ACTION: [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

CAOM collaboration on new data being folded into CAOM.

( MCD Note: my note here are sketchy as this is out of my wheelhouse! )

Axis for 'Faraday depth' or Rotation measure rather than Energy. These are modeled in CAOM using CustomAxis, but this seems unsatisfactory. These map closely to the CTYPE in FITS (WCS)... and we don't want to include the specific names in CAOM, and so would possibly want a vocabulary.

• PH: these are polarization related, different names for similar things..
• PD: not sure how to construct them for discovery POV
• PH: plenty of people 'here' with better knowledge of that could provide opinions, these are frequently used concepts
• PD: people are asking how to do this, and the answer is currently unsatisfactory... having a coordinate type label on the axis.
• MCD: Could UCDs help?
• PD: maybe.. but they still want to see the actual CTYPE value (specifically).
• I'm not sure we came to any conclusions here.

Source/Catalog model.

Final question from PH.. regarding what happened with the Source model effort.

• MCD: described that the MANGO model was the current incarnation of that work.. and allows catalogues to describe their content in a very general way. The effort to describe a "Source" object that applies to a broad set of cases is deemed untenable.
• PD: it (MANGO) is probably the closest you can get to a Source model for IVOA.

Next Meeting:

• We decided to continue weekly at the same day/time.