[trans] - Model comments

[CresitelloDittmar, Mark]

Gerard,

This has been the focus of some of our (mine and David's) recent
conversations, as this has been a part of the Transform model for a while
but I suspected it might get some pushback in review.  This past week, I
made a version with the relation you show, but have not pushed it forward.
These questions are the source of the mail threads.

FWIW, the vo-dml validator does not report a problem with the child compose
parent relation, so long as there is only 1.

Mark


On Wed, Mar 11, 2020 at 8:37 AM Gerard Lemson <glemson1 at jhu.edu> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20200311/294e6299/attachment.html>