Shape as primitive with representations.

Thu Mar 20 23:20:50 CET 2025

All,

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?
Some points:
  1) I think the mango.Shape has 'modeled' the 'representation' idea.
      You allow different serializations of a given shape, and have a
pointer identifying what that serialization is... ie: how to interpret it.
      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 ).

  2) "if it is primitive, it must be able to be serialized with a single
ATTRIBUTE"
      Why?

  3) I made up the new node PRIMITIVE mainly to separate it from the
existing definition of INSTANCE ( which serves DataTypes and ObjectTypes ).
      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",
       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.

The current approach would be to model the concept at different levels of
complexity.. and serialize them.
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.

Mark

On Thu, Mar 20, 2025 at 12:54 PM Laurent Michel <
laurent.michel at astro.unistra.fr> wrote:

> 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>
> wrote:
>
>> On Wed, 19 Mar 2025 at 06:01, Markus Demleitner via dm <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/79679b6c/attachment-0001.htm>