Shape as primitive with representations.

[CresitelloDittmar, Mark]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20250321/ecb7c27f/attachment-0001.htm>