Shape as primitive with representations.

[Laurent Michel]

Dear DM,

I have to admit that I'm not far from agreeing with Markus.
Having a new primitive type might have been a great thing (or not), 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).
The way to represent a shape with Mivot/MANGO, let's say a POLYGON, is this:

The shape si serialized in a PARAM:

<INSTANCE dmtype=“mango:shape” dmrole=“….”>
    <ATTRIBUTE dmtype=“ivoa:string” dmrole=“mango:Shape.shape” ref=“ID_OF_THE_PARAM” \>
    <ATTRIBUTE dmtype=“mango:ShapeSerialization” dmrole=“mango:Shape.serialization” value=“ POLYGON” \>
    <REFERENCE dmrole=”dmrole=“mango:Shape.spaceSys” dmref=“_id_of_the_desired_spacesys”\>	
</INSTANCE>		

if it is not:

<INSTANCE dmtype=“mango:shape” dmrole=“….”>
    <ATTRIBUTE dmtype=“ivoa:string” dmrole=“mango:Shape.shape” value=“1 2 3 4 5 6” \>
    <ATTRIBUTE dmtype=“mango:ShapeSerialization” dmrole=“mango:Shape.serialization” value=“ POLYGON” \>
    <REFERENCE dmrole=”dmrole=“mango:Shape.spaceSys” dmref=“_id_of_the_desired_spacesys”\>	
</INSTANCE>		

I advocate that there is nothing complicated here.
I believe this serialization is self-consistent enough to not require a new primitive type.

The main question for me is to think about replacing the Mango enumeration mango:Shape.serialization with a vocabulary including the DALI xtypes.

My 2 cents about the serialization of a possible new primitive type
---------------------------------------------------------------------------------------
if it is primitive, it must be able to be serialized with a single ATTRIBUTE

    <ATTRIBUTE dmtype=“ivoa:Circle” value=“1 2 3” \>

If it requires a complex structure to be exploded, it is not longer primitive bu tne dataType as in MANGO

A last word about the FoV DM
-----------------------------------------
This model is definitely more complex than a simple shape.
A FoV is a set on individual shapes defined without specific sky position but with relative positions.
The list of shapes supported by  the model matches what we can found in the telescope footprints.
We are far beyond describing an ellipse.


Laurent

> On 19 Mar 2025, at 18:21, CresitelloDittmar, Mark via dm <dm at ivoa.net> wrote:
> 
> This puts a twist in my brain that I'm having trouble straightening out.
> 
> I interpret Markus' statement: "shapes are serialised in whatever way the container formats wants them; in VOTable, use PARAM-s to store literals".  to mean that VOTable would define the serialization for each shape.. for example:
>    "A GROUP element containing FIELDref/PARAM/PARAMref elements for each attribute ( center_x, center_y, semi_major, semi_minor, angle )"
>    This would require 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' )
> 
> 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 
>        <FIELD name="<colname>" xtype="ellipse" datatype="double" arraysize=5 />
>  where the column value resolves to fill the 5 attributes.
> 
> The goal here is for a Model to allow different representations of the Ellipse (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.
> THAT would require being able to identify which representation is being supplied, so the user knows how to interpet it.
> 
> 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").
> 
> Mark
> 
> 
> On Wed, Mar 19, 2025 at 11:42 AM Patrick Dowler via dm <dm at ivoa.net <mailto:dm at ivoa.net>> wrote:
>> On Wed, 19 Mar 2025 at 06:01, Markus Demleitner via dm <dm at ivoa.net <mailto:dm at ivoa.net>> wrote:
>> > So, I'd say DM should say not much more than "shapes are serialised
>> > in whatever way the container formats wants them; in VOTable, use
>> > PARAM-s to store literals".
>> 
>> I agree with this. Serialization may differ depending on the format
>> and DALI already
>> says how to serialize in VOTable (sometimes referring to other
>> standards like ISO8601
>> or MOC when appropriate). That advice may or may not be applicable in
>> other formats.
>> 
>> --
>> Patrick Dowler
>> Canadian Astronomy Data Centre
>> Victoria, BC, Canada

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20250320/201a5578/attachment.htm>