<div dir="ltr"><div dir="ltr">David,<div><br></div><div>I'll just put in my $0.02 on this since it can be hard for others to consider the details.</div><div><br></div><div>1) As shown, this would pass vo-dml validation, though Gerard points out that it should not due to the child->parent composition.</div><div> o the * multiplicity on Mapping would not be a problem since Mapping is an ObjectType.</div><div><br></div><div>2) As shown, the definition of Mapping becomes somewhat muddled.</div><div> I've tried to keep with the definition that </div><div> Mapping == the bi-directional relation (between 2 frames), has 'forward' and 'inverse' concepts</div><div> Transform (TOperation) == unit-directional mathematical operation</div><div><br></div><div> With this model, the Operation gets denormalized with the Mapping, so </div><div> o some are bi-directional (Unit, Scale), some uni-directional (Permute, Poly2D), and Matrix may be either.</div><div> o the profile for each Mapping is different (has the parameters of the operation)</div><div><br></div><div>3) The current model is factoring in a requirement that a Mapping must be able to explicitly define the forward and inverse operation.</div><div> This model reverts to the original assertion that forward and inverse are methods on Mapping (formerly Transform), which may or may not produce results. The only type guaranteed to have both is BiDirectional, where the 2 component Mappings are for forward and inverse specifically.</div><div><br></div><div>In short..</div><div> + I definitely prefer separating Operation from Mapping.. and I think, is needed to support #3 above.</div><div> + but if we remove the requirement in #3, a variation of what you show is workable.</div><div><br></div><div>Mark</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 10, 2020 at 2:25 PM David Berry <<a href="mailto:d.berry@eaobservatory.org" target="_blank">d.berry@eaobservatory.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Here's a diagram of the sort of model I described at the end of my<br>
reply to Gerard's comments on the other thread. Only one class<br>
(CompoundMap) composes the base Mapping class, so hopefully it passes<br>
the vo-dml restrictions. If the open-ended nature of the composition<br>
("2...*") is a problem, I would be more than happy to revert to the<br>
way AST does it - which is to restrict all compound Mappings to<br>
contain exactly two component Mappings. Longer strings of mappings can<br>
then be created by nesting CompoundMaps inside other CompoundMaps.<br>
<br>
There is no mention of inverse/forward transformations in this model.<br>
I feel we may be getting too worried by the whole forward/inverse<br>
thing. I think most of the responsibility for handling the provision<br>
of inverse and forward transformations probably rests with the<br>
implementation library rather than the data model. In general, the<br>
data model for a particular type of Mapping should (IMHO) store the<br>
parameters that define the forward transformation. I think it should<br>
then be the job of the implementation library to deduce (if possible)<br>
the nature of the inverse transformation. However, it is occasionally<br>
necessary to define the inverse transformation explicitly in the data<br>
model - either because the specific class of mapping does not allow<br>
the implementation library to determine an inverse transformation<br>
(e.g. Permute) or to obviate the need for the implementation library<br>
to use an expensive iterative inversion (e.g. Polynomial2D). To cover<br>
such cases it is only necessary to add one more subclass of Mapping -<br>
a "BiDirection" (AKA "TransMap"?) . This is a CompoundMap containing<br>
two Mappings - one used to define the forward transformation of the<br>
BiDirection and the other the inverse transformation.<br>
<br>
This sort of model seems to combine much greater simplicity with<br>
flexibility. Please let me know what flaws you see in it. It may well<br>
be that I've become blinded to its limitations due to the many years<br>
I've been working with it.<br>
<br>
David<br>
<br>
<br>
On Tue, 10 Mar 2020 at 16:34, David Berry <<a href="mailto:d.berry@eaobservatory.org" target="_blank">d.berry@eaobservatory.org</a>> wrote:<br>
><br>
> Sorry - I've mistakenly sent my response to Gerard's comments to the<br>
> old thread. Apologies.<br>
><br>
> David<br>
><br>
> On Tue, 10 Mar 2020 at 15:06, CresitelloDittmar, Mark<br>
> <<a href="mailto:mdittmar@cfa.harvard.edu" target="_blank">mdittmar@cfa.harvard.edu</a>> wrote:<br>
> ><br>
> > Gerard/All,<br>
> ><br>
> > Just attempting to separate Transform model discussion separate from the vo-dml Composition rule<br>
> > Gerard's last mail with suggested model changes:<br>
> > <a href="http://mail.ivoa.net/pipermail/dm/2020-March/005994.html" rel="noreferrer" target="_blank">http://mail.ivoa.net/pipermail/dm/2020-March/005994.html</a><br>
> ><br>
> > 1) What AST implements as Frame is modeled in the coords model..<br>
> > The version coming out next (post RFC comments), uses CoordSys to combine the "Frame" and "CoordSpace" information which == ast:Frame<br>
> > 2) The Transform model has also been updated to include a "SystemMap" which references source and target coords:CoordSys with a trans:TMapping<br>
> > 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.<br>
> ><br>
> > 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.<br>
> ><br>
> > I also don't see that supporting the compound mapping, though it may be modifiable to do so.<br>
> > The scenario for the compound mapping is something like<br>
> > Frame A (x,y) ==> [ shift ] => [scale] => [Permute] => | Poly2D | => (X',Y') Frame B<br>
> > | Poly2D |<br>
> ><br>
> > With a similar set of operations for the 'inverse' path. There is no "Frame" spec between each individual operation.<br>
> ><br>
> > Mark<br>
> ><br>
> ><br>
</blockquote></div></div>