Shape as primitive with representations.

[Patrick Dowler]

Laurent, all,

In the context of CAOM, I was able to extract thes low-level building
blocks to see how re-use would work.

Shape et al are not primitive types, but rather dataType. These do map
to DALI xtypes: a serialization aimed at a single value in a cell of a
table (VOTable). In CAOM itself, (eg the xml serialization) the
structure is defined and used, so that is a different serialization
(no, I have not extracted and re-used the xsd, but I see no reason
that would be hard), but in a  CAOM database a shape would be stored
in a column and returned (TAP query) using DALI xtype serialization.

This is just in a branch of my fork of the CAOM model right now, here:
https://github.com/pdowler/CAOM/blob/datatypes-vodml/src/main/resources/DataTypes-current-vodml.xml

aside: There are several things in there in addition to "shape" that
we can/should discuss elsewhere.

--
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada

On Fri, 21 Mar 2025 at 10:21, CresitelloDittmar, Mark
<mdittmar at cfa.harvard.edu> wrote:
>
> All,
>
> For the benefit of those who might be reading this thread, but weren't at the running meeting.
> In a nutshell:
>    I see a problem with the current DM modeling practices as we move into more areas: CAOM integration, Mango, etc.
>    These projects require models which overlap in scope with other models, but at a different level of normalization due to the constraints of their usage.
>    An example of this is in the "Shape" concept, where CAOM requires a very simple shape, while other uses like REGION would need more flexibility.
>        see: https://wiki.ivoa.net/internal/IVOA/CaomIntegration/Shape_Model_Representations.pdf
>
>    Current practice would have us define new models for those concepts at the level needed for that project.
>       ** I believe that doing this will lead to confusion for users, and inconsistency between the models.  **
>       ** This is the same situation which resulted in the inconsistencies in overlapping content seen in the ObsCore, STC, Characterisation, Spectrum, and VOEvent models. **
>       ** Which will ultimately hinder interoperability. **
>
>    I'd like to have a discussion brainstorming ideas for how we might avoid this fate.
>
> This issue is in the bridge space between modeling and serializations, which we (the IVOA) haven't spent much time thinking about.
>
> NOTE: The following is moving away from Shape, but as I mentioned the issue applies to ObjectTypes as well.
> I do think there is value in being able to go from:
>
>     <INSTANCE dmid="CoordSystem_ICRS_id" dmrole="" dmtype="coords:SpaceSys">
>       <INSTANCE dmrole="coords:PhysicalCoordSys.frame" dmtype="coords:SpaceFrame">
>         <INSTANCE dmrole="coords:SpaceFrame.refPosition" dmtype="coords:StdRefLocation>
>            <ATTRIBUTE dmrole="coords:StdRefLocation.position" dmtype="ivoa:string" value="TOPOCENTER"/>
>         </INSTANCE>
>         <ATTRIBUTE dmrole="coords:SpaceFrame.spaceRefFrame" dmtype="ivoa:string" value="ICRS"/>
>       </INSTANCE>
>     </INSTANCE>
>     <INSTANCE dmtype="meas:Position">
>       <INSTANCE dmrole="meas:Position.coord" dmtype="coords:LonLatPoint">
>         <ATTRIBUTE dmrole="coords:LonLatPoint.lon" dmtype="ivoa:RealQuantity" ref="SC_RA" unit="deg"/>
>         <ATTRIBUTE dmrole="coords:LonLatPoint.lat" dmtype="ivoa:RealQuantity" ref="SC_DEC" unit="deg"/>
>         <REFERENCE dmrole="coords:Coordinate.coordSys" dmref="Coordsystem_ICRS_id"/>
>       </INSTANCE>
>       <INSTANCE dmrole="meas:Measure.error" dmtype="meas:Error">
>         <INSTANCE dmrole="meas:Error.statError" dmtype="meas:ASymmetrical2D">
>           <COLLECTION dmrole="meas:ASymmetrical2D.plus" >
>             <ATTRIBUTE dmtype="ivoa:RealQuantity" ref="SC_RA_ERR" unit="arcsec"/>
>             <ATTRIBUTE dmtype="ivoa:RealQuantity" ref="SC_DEC_ERR" unit="arcsec"/>
>           </COLLECTION>
>           <COLLECTION dmrole="meas:ASymmetrical2D.minus">
>             <ATTRIBUTE dmtype="ivoa:RealQuantity" ref="SC_RA_ERR" unit="arcsec"/>
>             <ATTRIBUTE dmtype="ivoa:RealQuantity" ref="SC_DEC_ERR" unit="arcsec"/>
>           </COLLECTION>
>         </INSTANCE>
>       </INSTANCE>
>     </INSTANCE>
>
> To
>     <INSTANCE dmtype="meas:Position" rep="meas:rep.SkyPosition">
>       <ATTRIBUTE dmrole="meas:rep.SkyPosition.refFrame" dmtype="ivoa:string" value="ICRS"/>
>       <ATTRIBUTE dmrole="meas:rep.SkyPosition.ra" dmtype="ivoa:RealQuantity" ref="SC_RA" unit="deg"/>
>       <ATTRIBUTE dmrole="meas:rep.SkyPosition.ra_err" dmtype="ivoa:RealQuantity" ref="SC_RA_ERR" unit="arcsec"/>
>       <ATTRIBUTE dmrole="meas:rep.SkyPosition.dec" dmtype="ivoa:RealQuantity" ref="SC_DEC" unit="deg"/>
>       <ATTRIBUTE dmrole="meas:rep.SkyPosition.dec_err" dmtype="ivoa:RealQuantity" ref="SC_DEC_ERR" unit="arcsec"/>
>     </INSTANCE>
>
> IFF your position happens to be
>   * Sky Position on the Unit Sphere with refPosition=TOPOCENTER, and errors expressed as  <value> +/- <error>
>
> Without having 'simplified' models of a base (full) model of the concept spread out over other models which have more constrained requirements.
>
> Perhaps this could be accomplished by a different class of model
>   * which could live within the base model standard
>   * and provide a simpler representation of the object IFF certain constraints apply.
>        * notice this example consolidated the coords model content into local attributes..
>   * This would allow us to ignore serialization (yay!)
>
> OR, it could be accomplished at the serialization level, by defining patterns or representations there.
>   * like "COOSYS" and "TIMESYS"  which are compact standard serializations of coords model elements in VOTable ).
>   * or something like the PRIMITIVE thing from my last mails in MIVOT serializations
>
> OR, ????
>
> Mark
>