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