<div dir="ltr">All,<div><br><div>Please note, that my examples are not proposals.. but merely trying to illustrate my understanding of the earlier discussion and seed discussion about IF this idea works, and IF SO, how?</div><div>Some points:</div><div> 1) I think the mango.Shape has 'modeled' the 'representation' idea.</div><div> You allow different serializations of a given shape, and have a pointer identifying what that serialization is... ie: how to interpret it.</div><div> As I understand the idea from the discussion.. if Shape is a 'primitive' DataType, then any number of representations could be interpreted to define an instance ( like ivoa:datetime, but more complex ).</div><div><br></div><div> 2) "if it is primitive, it must be able to be serialized with a single ATTRIBUTE"</div><div> Why?</div><div><br></div><div> 3) I made up the new node PRIMITIVE mainly to separate it from the existing definition of INSTANCE ( which serves DataTypes and ObjectTypes ).</div><div> This is to show possibilities for what we might do to express: "This next chunk of serialization can be interpreted as an Ellipse, if you understand the DALI representation format".. or "XYZ representation format", </div><div> where DALI format is very simple and massively constrained, and the XYZ representation is more full and satisfies other use cases that maybe DALI doesn't.</div><div><br></div><div>The current approach would be to model the concept at different levels of complexity.. and serialize them.</div><div>Another approach would be to have 1 model for the concept, and define different representations (serializations) which would allow providers to write the instances at a level suitable for their data.</div><div><br></div><div>Mark</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Mar 20, 2025 at 12:54 PM Laurent Michel <<a href="mailto:laurent.michel@astro.unistra.fr">laurent.michel@astro.unistra.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="line-break:after-white-space">Dear DM,<div><br></div><div><div><div>I have to admit that I'm not far from agreeing with Markus.</div><div>Having a new primitive type might have been a great thing (<u>or not)</u>, but this is not the case yet and we can do with what we have: (ivoa primitive types, Meas, Coords, Mango soon, MIVOT, DALI... and circulating VOTables).</div><div>The way to represent a shape with Mivot/MANGO, let's say a POLYGON, is this:</div></div><div><br></div><div>The shape si serialized in a PARAM:</div><div><br></div><div><INSTANCE dmtype=“mango:shape” dmrole=“….”></div><div> <ATTRIBUTE dmtype=“ivoa:string” dmrole=“mango:Shape.shape” ref=“ID_OF_THE_PARAM” \></div><div><div> <ATTRIBUTE dmtype=“mango:ShapeSerialization” dmrole=“mango:Shape.serialization” value=“ POLYGON” \></div></div><div> <REFERENCE dmrole=”dmrole=“mango:Shape.spaceSys” dmref=“_id_of_the_desired_spacesys”\><span style="white-space:pre-wrap"> </span></div><div></INSTANCE><span style="white-space:pre-wrap"> </span></div><div><br></div><div><div>if it is not:</div><div><br></div><div><INSTANCE dmtype=“mango:shape” dmrole=“….”></div><div> <ATTRIBUTE dmtype=“ivoa:string” dmrole=“mango:Shape.shape” value=“1 2 3 4 5 6” \></div><div> <ATTRIBUTE dmtype=“mango:ShapeSerialization” dmrole=“mango:Shape.serialization” value=“ POLYGON” \></div><div> <REFERENCE dmrole=”dmrole=“mango:Shape.spaceSys” dmref=“_id_of_the_desired_spacesys”\><span style="white-space:pre-wrap"> </span></div><div></INSTANCE><span style="white-space:pre-wrap"> </span></div></div><div><br></div><div>I advocate that there is nothing complicated here.</div><div>I believe this serialization is self-consistent enough to not require a new primitive type.</div><div><br></div><div>The main question for me is to think about replacing the Mango enumeration mango:Shape.serialization with a vocabulary including the DALI xtypes.</div><div><br></div><div>My 2 cents about the serialization of a possible new primitive type</div><div>---------------------------------------------------------------------------------------</div><div>if it is primitive, it must be able to be serialized with a single ATTRIBUTE</div><div><br></div><div> <ATTRIBUTE dmtype=“ivoa:Circle” value=“1 2 3” \></div><div><br></div><div>If it requires a complex structure to be exploded, it is not longer primitive bu tne dataType as in MANGO</div><div><br></div><div>A last word about the FoV DM</div><div>-----------------------------------------</div><div>This model is definitely more complex than a simple shape.</div><div>A FoV is a set on individual shapes defined without specific sky position but with relative positions.</div><div>The list of shapes supported by the model matches what we can found in the telescope footprints.</div><div>We are far beyond describing an ellipse.</div><div><br></div><div><br></div><div>Laurent</div><div><br></div><div><div><blockquote type="cite"><div>On 19 Mar 2025, at 18:21, CresitelloDittmar, Mark via dm <<a href="mailto:dm@ivoa.net" target="_blank">dm@ivoa.net</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr">This puts a twist in my brain that I'm having trouble straightening out.</div><div dir="ltr"><br><div>I interpret Markus' statement: <span style="color:rgb(80,0,80)">"shapes are serialised </span><span style="color:rgb(80,0,80)">in whatever way the container formats wants them; in VOTable, use</span><span style="color:rgb(80,0,80)"> PARAM-s to store literals". </span>to mean that VOTable would define the serialization for each shape.. for example:</div></div><div class="gmail_quote"><div class="gmail_attr"> "A GROUP element containing FIELDref/PARAM/PARAMref elements for each attribute ( center_x, center_y, semi_major, semi_minor, angle )"</div><div class="gmail_attr"> This would <b>require</b> UCDs to identify each of the attributes since FIELDref does not contain names, and the column names probably won't match the attributes. (eg "RA" vs 'center_x' )</div><div class="gmail_attr"><br></div><div class="gmail_attr">Then there is the DALI serialization spec.. defines value list and order along with constraints that let the values be a simple list of numbers. This is more restrictive than the GROUP representation. I'm not too familiar with that form, but it seems like it would be something like </div><div class="gmail_attr"> <FIELD<span> name="<colname>" xtype="ellipse</span>" datatype="double" arraysize=5 /><br></div><div class="gmail_attr"> where the column value resolves to fill the 5 attributes.</div><div class="gmail_attr"><br></div><div class="gmail_attr"><b>The goal here is for a Model to allow different representations of the Ellipse</b> (or whatever datatype) at different levels of normalization. DALI may restrict to the DALI representation, but something more generic (like FOV/REGION) might want to allow a simple DALI string, STC-S string, MOC, or more full VOTable GROUP. The provider could supply whichever satisfies the needs of their data.</div><div class="gmail_attr">THAT would require being able to identify which representation is being supplied, so the user knows how to interpet it.</div><div class="gmail_attr"><br></div><div class="gmail_attr">With the above paragraph, I'm thinking also of the Coordinates model to some degree. This mechanism would allow a simple representation for the case of "Sky Coordinate in standard Reference position and reference Frame", while allowing for a fuller representation for others (e.g. "ccd coordinates").</div><div class="gmail_attr"><br></div><div class="gmail_attr">Mark</div><div class="gmail_attr"><br></div><div class="gmail_attr"><br></div><div dir="ltr" class="gmail_attr">On Wed, Mar 19, 2025 at 11:42 AM Patrick Dowler via dm <<a href="mailto:dm@ivoa.net" target="_blank">dm@ivoa.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Wed, 19 Mar 2025 at 06:01, Markus Demleitner via dm <<a href="mailto:dm@ivoa.net" target="_blank">dm@ivoa.net</a>> wrote:<br>
> So, I'd say DM should say not much more than "shapes are serialised<br>
> in whatever way the container formats wants them; in VOTable, use<br>
> PARAM-s to store literals".<br>
<br>
I agree with this. Serialization may differ depending on the format<br>
and DALI already<br>
says how to serialize in VOTable (sometimes referring to other<br>
standards like ISO8601<br>
or MOC when appropriate). That advice may or may not be applicable in<br>
other formats.<br>
<br>
--<br>
Patrick Dowler<br>
Canadian Astronomy Data Centre<br>
Victoria, BC, Canada<br>
</blockquote></div></div>
</div></blockquote></div><br></div></div></div></blockquote></div>