[vo-dml] Clarification on composition rule..

[Gerard Lemson]

Hi Dave and others
I think the AST model is logical and clearly battle tested.
Precisely what I miss in the current state of the transformation model are the representations of the Frame and possibly the Frameset and how Mappings work on these.

I tried sketching a domain model for this in the attached diagram. In the sketch a FrameSet is a collection of Frame-s with Mappings between them.
A Mapping is a relation *from* one frame *to* another. I think a compound mapping could be expressed as a frameset with appropriate number of frames and mappings
and is easily able to capture a situation say as in your figure 2 in https://arxiv.org/pdf/1602.06681.pdf.

To represent the datils of the Mapping I represent the Frame as a collection of axes (bit of a denormalization of the coordframe in cords model). 
Here I assume a mapping is a collection of axismappings that transform one or more (x) axes from the "from" Frame to a single (y) axis in the "to" frame.
I.e. for simplicity I assume an *explicit* functional operation, rather than an implicit function relating the "from" and "to" axes. I think this is assumed in the transformation model as well. If necessary such implicit mappings could be handled as well.

The AxisMapping also defines an operation, which is the most atomic expression of the mapping.
In many cases this could be a mathematical equation, expressed as y=f(x1,..,xn), where y refers to the toAxis and the fromAxis collection defines how to interpret x1,..,xn and f is some function. Maybe a standardized syntax for this might be an option as I wondered in my previous email. Maybe the parameter description standard may have suggestions here as well.
I understand that people might wish to represent the operation using some type hierarchy, but I think it is a different one than the hierarchy you referred to as being required for the compound mappings. Polynomials can be expressed easily in such a math expression, or can be expressed as datatypes with attributes with Open ended multiplicities.

Note that because now we have Frames explicitly expressed, and the Mapping explicitly states which is the "from" and which the "to" Frame, and the AxisMapping explicitly specifies the toAxis and fromAxes, there is not really a need to indicate a forward or inverse mapping. This is obvious from the assignment. If you want you can have  axismapping-s corresponding to both forward and inverse operations in a single Mapping, as you do in AST I believe. Or you could choose to only have forward axismappings and have two Mappings for a given pair of Frame-s, each once being a 'from' and once being a 'to'.

This to me would solve the original issue Mark had. It makes the input/output of a mapping explicit and it isolates the actual operations that express one axis in terms of another.

It may need some more work for the lookup operation. Since datatype-s allow references, a lookup table might still be represented as an objecttype that such a function references.
I think most, hopefully all of the choices in the current transformation model can be transferred to this structure as Pat was in a sense suggesting.


Cheers

Gerard


> -----Original Message-----
> From: David Berry <d.berry at eaobservatory.org>
> Sent: Tuesday, March 10, 2020 12:21
> To: Gerard Lemson <glemson1 at jhu.edu>
> Cc: Laurent MICHEL <laurent.michel at astro.unistra.fr>; dm at ivoa.net
> Subject: Re: [vo-dml] Clarification on composition rule..
> 
> On Tue, 10 Mar 2020 at 10:54, Gerard Lemson <glemson1 at jhu.edu> wrote:
> 
> > As to the case that started this discussion, I am still wondering whether the
> issue could be resolved more elegantly once an explicit representation of the
> things that are being mapped/transferred is added to the model.
> 
> From the point of view of working with a similar system (AST) for many years, it
> has been very useful to separate the representation of the variables being
> transformed  ("Frames") from the representation of the transformation itself
> ("Mappings") . Doing so means that you can combine Mapping objects together
> into compound Mappings in various ways without needing to worry about  the
> associated Frames. Most real world Mappings are formed by combining lots of
> simpler atomic mappings together into a compound Mapping. If each atomic
> Mapping included a description of the associated input and output variables,
> you would end up with a large amount of redundant information in the
> compound Mapping.
> 
> Of course, at the end of the day you need the variable descriptions to be stored
> some where. We have found it useful to define a higher level "FrameSet" class
> for this purpose, which contains a tree structure of related Frames connected
> together by (potentially compound) Mappings.
> So for instance a FITS WCS header could be described by a FrameSet that
> contained separate Frames describing pixel coordinates, WCS coordinates,
> focal plane coordinates, CCD coordinates, etc, together with Mappings that
> transform positions between each of these coordinate systems.
> 
> David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ast.png
Type: image/png
Size: 30180 bytes
Desc: ast.png
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200310/538d4e0b/attachment-0001.png>