Shape as primitive with representations.

[Laurent Michel]

Patrick,

I was not saying that shapes should be modelled as primitive types, I think it shouldn’t be.

I used this as an example of my understanding of primitive type:
A shape model  made of a string + a seralization mode could be described as a primitive type.

Anyway, I do not see which gain we can expect by creating new primitive types.

Laurent

> On 25 Mar 2025, at 23:07, Patrick Dowler <pdowler.cadc at gmail.com> wrote:
> 
> 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
>>