<div dir="ltr">Pat,<div><br></div><div>There are flavors which have open ended list of content</div><div> Lookup table has open ended list of Entries</div><div> Polynomials have open ended list of Coefficients, to avoid individually modeling the different order of polynomial functions.</div><div><br></div><div>DataTypes are supposed to have fixed size.</div><div><br></div><div>Mark</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 6, 2020 at 5:13 PM Patrick Dowler <<a href="mailto:pdowler.cadc@gmail.com">pdowler.cadc@gmail.com</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"><div dir="ltr"><div class="gmail_default" style="font-size:small">I don't understand "<span style="color:rgb(0,0,0)">NOTE: the nature of several operations require it to be an ObjectType rather than a DataType, so these can't be Attributes." <br></span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0)"><br></span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0)">I have created models with DataType(s) that are "structures" so I could use them as attributes in multiple places and I have declared DataType(s) that extend (subclass) other DataType(s). Both of those are vodml compliant... what is it that requires TOperation to be an ObjectType? Is it a philosophical issue?<br></span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0)"><br></span></div><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 4 Mar 2020 at 09:43, CresitelloDittmar, Mark <<a href="mailto:mdittmar@cfa.harvard.edu" target="_blank">mdittmar@cfa.harvard.edu</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"><div dir="ltr"><div dir="ltr">Hi,<div><br></div><div>In the Transform model, we have a case where we want to use the same Object with different roles in the parent Object.</div><div>Specifically, we want to define a "Mapping" with a forward and inverse "Operation".</div><div><br></div><div>What I'd like to do is:</div><div><div><img src="cid:ii_k7dl7z0l0" alt="A.png" style="margin-right: 0px;" width="201" height="326"><br></div></div><div><br></div><div>But the VO-DML rec states; Section 4.17, pg 48, "an ObjectType can only be the target of at most one Composition relation".</div><div>And this does indeed fail vo-dml validation. <span style="color:rgb(0,0,0)"> NOTE: the nature of several operations require it to be an ObjectType rather than a DataType, so these can't be Attributes.</span></div><div><br></div><div>I CAN do:</div><div><div><img src="cid:ii_k7dleq7e1" alt="B.png" width="294" height="326"><br></div></div><div><br></div><div>Which has only 1 composition, but is hacky and not very user-friendly.. I'd really prefer to have explicit 'forward' and 'inverse' tags.</div><div>To make a vo-dml compliant version of the first diagram, I need to add a layer to the model. This works fine, and is the current model, but is rather ugly and makes it a little more difficult to interpret. </div><div><br></div><div><div><img src="cid:ii_k7dlm8rj2" alt="C.png" width="384" height="406"><br></div></div><div><br></div><div>Mainly, I think I'm looking to confirm that the rule in Section 4.17 is <b>intended</b> to include this case.</div><div>I expect it is, and has to do with RDB implementations and distinguishing the instances, but I'm not a DB person and don't fully get all that.</div><div><br></div><div>Mark</div><div><br></div></div></div>
</blockquote></div>
</blockquote></div>