<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi Mark<o:p></o:p></p>
<p class="MsoNormal">I will try to fix the validator, though that will be pretty tricky.<o:p></o:p></p>
<p class="MsoNormal">For a type should not have a composition relation with any type in the same inheritance hierarchy it is in..<o:p></o:p></p>
<p class="MsoNormal">Thanks<o:p></o:p></p>
<p class="MsoNormal">Gerard<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> CresitelloDittmar, Mark <mdittmar@cfa.harvard.edu>
<br>
<b>Sent:</b> Wednesday, March 11, 2020 14:18<br>
<b>To:</b> Gerard Lemson <glemson1@jhu.edu><br>
<b>Cc:</b> David Berry <d.berry@eaobservatory.org>; Data Models mailing list <dm@ivoa.net><br>
<b>Subject:</b> Re: [trans] - Model comments<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Gerard,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">FWIW, the vo-dml validator does not report a problem with the child compose parent relation, so long as there is only 1.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Mark<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, Mar 11, 2020 at 8:37 AM Gerard Lemson <<a href="mailto:glemson1@jhu.edu">glemson1@jhu.edu</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">Hi Dave<br>
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.<br>
Instead a compound type like this is generally built according to the pattern in the attached diagram.<br>
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.<br>
<br>
I agree with your thoughts on forward-inverse.<br>
<br>
Cheers<br>
Gerard<br>
<br>
> -----Original Message-----<br>
> From: <a href="mailto:dm-bounces@ivoa.net" target="_blank">dm-bounces@ivoa.net</a> <<a href="mailto:dm-bounces@ivoa.net" target="_blank">dm-bounces@ivoa.net</a>> On Behalf Of David<br>
> Berry<br>
> Sent: Tuesday, March 10, 2020 19:26<br>
> To: David Berry <<a href="mailto:d.berry@eaobservatory.org" target="_blank">d.berry@eaobservatory.org</a>><br>
> Cc: Data Models mailing list <<a href="mailto:dm@ivoa.net" target="_blank">dm@ivoa.net</a>><br>
> Subject: Re: [trans] - Model comments<br>
> <br>
> Here's a diagram of the sort of model I described at the end of my reply to<br>
> Gerard's comments on the other thread. Only one class<br>
> (CompoundMap) composes the base Mapping class, so hopefully it passes the<br>
> 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 way AST<br>
> does it - which is to restrict all compound Mappings to contain exactly two<br>
> component Mappings. Longer strings of mappings can then be created by<br>
> 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 thing. I<br>
> think most of the responsibility for handling the provision of inverse and<br>
> forward transformations probably rests with the implementation library rather<br>
> than the data model. In general, the data model for a particular type of<br>
> Mapping should (IMHO) store the parameters that define the forward<br>
> transformation. I think it should then be the job of the implementation library<br>
> to deduce (if possible) the nature of the inverse transformation. However, it is<br>
> occasionally necessary to define the inverse transformation explicitly in the<br>
> data model - either because the specific class of mapping does not allow the<br>
> implementation library to determine an inverse transformation (e.g. Permute)<br>
> or to obviate the need for the implementation library to use an expensive<br>
> iterative inversion (e.g. Polynomial2D). To cover such cases it is only necessary<br>
> to add one more subclass of Mapping - a "BiDirection" (AKA "TransMap"?) .<br>
> This is a CompoundMap containing two Mappings - one used to define the<br>
> forward transformation of the BiDirection and the other the inverse<br>
> transformation.<br>
> <br>
> This sort of model seems to combine much greater simplicity with flexibility.<br>
> Please let me know what flaws you see in it. It may well be that I've become<br>
> blinded to its limitations due to the many years 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>><br>
> 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<br>
> > > the vo-dml Composition rule Gerard's last mail with suggested model<br>
> changes:<br>
> > > <a href="http://mail.ivoa.net/pipermail/dm/2020-March/005994.html" 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<br>
> > > to combine the "Frame" and "CoordSpace" information which ==<br>
> > > ast:Frame<br>
> > > 2) The Transform model has also been updated to include a "SystemMap"<br>
> which references source and target coords:CoordSys with a trans:TMapping<br>
> > > This has not been released on Volute, because David is working through<br>
> the implementation thereof with AST to look for issues in compatibility with<br>
> ast:FrameSet.<br>
> > ><br>
> > > In the coords model, the visibility of individual axes is severely limited. For<br>
> the most part, our data reside in standard coordinate spaces, and the specific<br>
> axes (other than Pixel), are rarely explicitly defined. So the AxisMap design<br>
> 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<br>
> modifiable to do so.<br>
> > > The scenario for the compound mapping is something like<br>
> > > Frame A (x,y) ==> [ shift ] => [scale] => [Permute] => | Poly2D | =><br>
> (X',Y') Frame B<br>
> > > |<br>
> > > Poly2D |<br>
> > ><br>
> > > With a similar set of operations for the 'inverse' path. There is no "Frame"<br>
> spec between each individual operation.<br>
> > ><br>
> > > Mark<br>
> > ><br>
> > ><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>