Shape as primitive with representations.

[Laurent Michel]

Dear DM

> On 21 Mar 2025, at 18: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

Thank you Mark, for the clarification.
When I read your note, I realize that the mango:shape relates more  to the concept of coverage than a generic geometric shape. 
I propose to rename the mango shape property as space_coverage.

> 
>    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.

The important thing to me is that the same concepts have the same definition wherever they are used. This can be achieved without setting up any machine-readable inter-model import mechanism or model extensions, which is a burden.
This inter-model consistency can be achieved at document level by sharing  attribute descriptions as Mango does with the EpochPosition components which are taken out from Coords. That way there is no risk of confusion and the interoperability between models is ensured. 

> This issue is in the bridge space between modeling and serializations, which we (the IVOA) haven't spent much time thinking about.

I do not follow you here, the space between model and serialisation is well filled with Mivot and we 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>
> 

Your exemple misses something telling how to interpret the error (box or straight elliipse )

> Without having 'simplified' models of a base (full) model of the concept spread out over other models which have more constrained requirements.

This is exactly what Mango does with the EpochPosition. It exposes Coords concept in a flat class, hiding that way the trace of the many abstraction levels one can found in Coord:SkyPosition
If for some reason some clients have to reconstruct a Coords:skyPosition object from a Mango EpochPosition, it could find anything it needs in the VODML files.

> 
> 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!)

I do not share your enthusiasm for ignoring the serialisation, which is exactly at the interface in between models and data.

> 
> 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, ????

OR Turning back to the basics: the model defines classes with their attributes (semantic, roles and types) and :
1- The serialization explicitely reproduces this structure as Mivot does providing clients with the whole model information.
2-  The schema to which the data file obeys (XML, JSON) includes some pre-set patterns (e.g.COOSYS) which are well-known by the clients

LM

> 
> Mark
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20250326/113d9d8b/attachment.htm>