[trans] - Model comments

[Gerard Lemson]

Hi Dave
The model you use is illegal in terms of VO-DML. A composition relation is a parent-child relation where a parent MUST exist before a child can be added. In your model CompoundMapping is-a Mapping, but is also its parent in a parent-child relationship.
Instead a compound type like this is generally built according to the pattern in the attached diagram.
Note that the associative class also allows more metadata to be added such as the role the referenced object plays, or in this case the rank of the object in the collection.

I agree with your thoughts on forward-inverse.

Cheers
Gerard

> -----Original Message-----
> From: dm-bounces at ivoa.net <dm-bounces at ivoa.net> On Behalf Of David
> Berry
> Sent: Tuesday, March 10, 2020 19:26
> To: David Berry <d.berry at eaobservatory.org>
> Cc: Data Models mailing list <dm at ivoa.net>
> Subject: Re: [trans] - Model comments
> 
> Here's a diagram of the sort of model I described at the end of my reply to
> Gerard's comments on the other thread. Only one class
> (CompoundMap) composes the base Mapping class, so hopefully it passes the
> vo-dml restrictions. If the open-ended nature of the composition
> ("2...*") is a problem, I would be more than happy to revert to the way AST
> does it - which is to restrict all compound Mappings to contain exactly two
> component Mappings. Longer strings of mappings can then be created by
> nesting CompoundMaps inside other CompoundMaps.
> 
> There is no mention of inverse/forward transformations in this model.
> I feel we may be getting too  worried by the whole forward/inverse thing. I
> think most of the responsibility for handling the provision of inverse and
> forward transformations probably rests with the implementation library rather
> than the data model.  In general, the data model for a particular type of
> Mapping should (IMHO) store the parameters that define the forward
> transformation. I think it should then be the job of the implementation library
> to deduce (if possible) the nature of the inverse transformation. However, it is
> occasionally necessary to define the inverse transformation explicitly in the
> data model - either because the specific class of mapping does not allow the
> implementation library to determine an inverse transformation (e.g. Permute)
> or to obviate the need for the implementation library to use an expensive
> iterative inversion (e.g. Polynomial2D).  To cover such cases it is only necessary
> to add one more subclass of Mapping - a "BiDirection" (AKA "TransMap"?) .
> This is a CompoundMap containing two Mappings - one used to define the
> forward transformation of the BiDirection and the other the inverse
> transformation.
> 
> This sort of model seems to combine much greater simplicity with flexibility.
> Please let me know what flaws you see in it. It may well be that I've become
> blinded to its limitations due to the many years I've been working with it.
> 
> David
> 
> 
> On Tue, 10 Mar 2020 at 16:34, David Berry <d.berry at eaobservatory.org>
> wrote:
> >
> > Sorry - I've mistakenly sent my response to Gerard's comments to the
> > old thread. Apologies.
> >
> > David
> >
> > On Tue, 10 Mar 2020 at 15:06, CresitelloDittmar, Mark
> > <mdittmar at cfa.harvard.edu> wrote:
> > >
> > > Gerard/All,
> > >
> > > Just attempting to separate Transform model discussion separate from
> > > the vo-dml Composition rule Gerard's last mail with suggested model
> changes:
> > >    http://mail.ivoa.net/pipermail/dm/2020-March/005994.html
> > >
> > > 1) What AST implements as Frame is modeled in the coords model..
> > >     The version coming out next (post RFC comments), uses CoordSys
> > > to combine the "Frame" and "CoordSpace" information which ==
> > > ast:Frame
> > > 2) The Transform model has also been updated to include a "SystemMap"
> which references source and target coords:CoordSys with a trans:TMapping
> > >     This has not been released on Volute, because David is working through
> the implementation thereof with AST to look for issues in compatibility with
> ast:FrameSet.
> > >
> > > In the coords model, the visibility of individual axes is severely limited.  For
> the most part, our data reside in standard coordinate spaces, and the specific
> axes (other than Pixel), are rarely explicitly defined.  So the AxisMap design
> doesn't, I think, play well with the typical data product.
> > >
> > > I also don't see that supporting the compound mapping, though it may be
> modifiable to do so.
> > > The scenario for the compound mapping is something like
> > >      Frame A  (x,y) ==> [ shift ] => [scale]  => [Permute] => | Poly2D | =>
> (X',Y') Frame B
> > >                                                               |
> > > Poly2D |
> > >
> > > With a similar set of operations for the 'inverse' path.  There is no "Frame"
> spec between each individual operation.
> > >
> > > Mark
> > >
> > >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compoundmapping.png
Type: image/png
Size: 9226 bytes
Desc: compoundmapping.png
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200311/1f56d736/attachment-0001.png>