<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div>This is a partial response. First just an update of the affected occurrences, for the record.<br></div><div>The total is 19.<br></div><div><br></div>There is one instance in coords, your #1<br><br></div>There are 10 instances in frametransforms:<br></div>Your #2<br></div>Your #3 (2 instances)<br></div>Your #4 expands to include Enum2D and Enum3D (i.e., total 3 instances)<br></div>Your #5 expands to include PolCircular, PolLinear, PolVector (i.e., total 4 instances)<br><br></div>There is one instance in coordarea: PolCover<br><br></div>There are 7 instances in region:<br></div>Polygon, Convex, ConvexHull2D, ConvexHull3D, Union, Intersection, Difference<br></div>(though the last three can easily be dropped)<br><br><br></div><div>I'll respond to the use of the construction:<br></div><div>nitems: nonnegativeinteger, multiplicity 1<br></div><div>array: real, multiplicity 0,nitems<br><br></div><div>I introduced the requirement that there be an attribute holding the length of the array<br></div><div>as a kind of compromise between requiring the length of the array to be specified<br></div><div>explicitly through a literal in the model (as VO-DML currently requires) and leaving that<br>length completely open. I was hoping that that would make it more palatable for Gerard ;-)<br></div><div>The question: what happens when the length is changed by dropping or adding<br></div><div>elements to the array? actually raises a more philosophical issue:<br></div><div>If we have an instantiation of a Datatype or a Class, containing an array of attributes,<br></div><div>and we change the length if that array, is it still the same instantiation or have we<br></div><div>created a new instantiation by making that change?<br></div><div>If it is the latter, the issue of nitems changing value is moot: we have not changed<br></div><div>its value, but we have created a new instance with a different value of nitems.<br></div><div><br></div>Cheers,<br><br></div> - Arnold<br><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">-------------------------------------------------------------------------------------------------------------<br>Arnold H. Rots Chandra X-ray Science Center<br>Smithsonian Astrophysical Observatory tel: +1 617 496 7701<br>60 Garden Street, MS 67 fax: +1 617 495 7356<br>Cambridge, MA 02138 <a href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a><br>USA <a href="http://hea-www.harvard.edu/~arots/" target="_blank">http://hea-www.harvard.edu/~arots/</a><br>--------------------------------------------------------------------------------------------------------------<br><br></div></div></div>
<br><div class="gmail_quote">On Tue, Dec 29, 2015 at 4:34 PM, CresitelloDittmar, Mark <span dir="ltr"><<a href="mailto:mdittmar@cfa.harvard.edu" target="_blank">mdittmar@cfa.harvard.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>All,<br><br></div>I thought it would be worth looking at some alternative representations for some of the multiplicity issues we are coming up against. I'm not necessarily advocating a change to these, just presenting other possibilities for discussion<br><br></div>From what I can see, the list of conflicts are:<br></div>1) Coords.generic:GenericCoord[*]<br><br></div><div>2) PixelCoordinate.naxes:nonnegativeInteger[1]<br></div> PixelCoordinate.pixelCoord:RealQuantity[1..3] {constraint pixelCoord.size == naxes}<br><div><div><br></div><div>3) Polynomial1D.order:nonnegativeInteger[1]<br></div><div> Polynomial1D.coeff:real[1..*] {constraint coeff.size = order+1}<br></div><div> Polynomial2D.order:nonnegativeInteger[1]<br></div><div> Polynomial2D.coeff.real[1..*] {constraint coeff.size = order*order+1}<br></div><div><br></div><div>4) EnumScalar.npix:nonnegativeInteger[1]<br></div><div> EnumScalar.ec:RealQuantity[1..*] {constraint ec.size = npix}<br></div><div> same for Enum2D, Enum3D<br><br></div><div>5) PolStokes.npix:nonnegativeInteger[1]<br></div><div> PolStokes.pixelType:PolStokes[1..*] {pixelType.size = npix}<br></div><div><br></div><div>NOTE: there are a couple others in the region and area packages, which I have not looked at.<br></div><div>These are in my area of interest in supporting the Cube work.<br></div><div><br></div><div>#4 and #5: Lookups<br></div><div> + npix is solely providing the length of the corresponding value array. As such, it could be considered a <br></div><div> non-modeled derived property of the element. ie: npix = length of the array.<br></div><div> Note: This leaves the [1..*] multiplicity on value attribute.<br></div><div> alternatively<br></div><div> + one could model the Enum (lookup) as a sequence of EnumElements.<br></div><div> Each element would connect the native value to the target value. The Enum/Polarization lookups in STC2<br></div><div> use an implicit native value (the pixel, or index #). I prefer the explicit version I have in the STC2-prototype<br></div><div> within the Dataset model, which allows the nativeValue to be random. NOTE: These are not mutually exclusive,<br></div><div> In this case, the relation from Enum class to EnumElement would be 1..*, and npix would still be a non-modeled<br></div><div> derived property defined by the number of EnumElements.<br></div><div> Here, I think this approach makes sense, as the number of elements could change through filtering but<br></div><div> not effect the individual mapping.<br><br></div><div>#3: Polynomial coefficients<br></div><div> + here 'order' is hard-linked to the length of the 'coeff' array, but in a slightly more complicated way.<br></div><div> For the 1D case, coeff.size = order+1; while for 2D, coeff.size = order*order+1.<br></div><div> So again, this could be considered a non-modeled derived property of the Polynomial transform.<br></div><div> Leaving coeff:real[1..*] with constraint { * = order+1 }<br></div><div> alternatively<br></div><div> + not sure I like this, but rather than requiring an ordered array for 'coeff', one could define a Coeff object with:<br></div><div> - term:nonnegativeInteger[1] specifies the polynomial term to which the coefficient applies<br></div><div> - value:real[1] the coefficient value<br></div><div> This would be compliant with the vodml spec, producing a 1..* relation between Polynomial and Coefficient<br></div><div> with only a little more complexity.<br></div><div><br></div><div><br></div><div>#1 and #2: Coord arrays<br></div><div> In #1, we have a simple open-ended array of GenericCoordinate (which is a datatype).<br></div><div> I'm not sure there is an alternative here. Unless it is to say that this case should not exist.. that all <br></div><div> coordinates must be represented by the domain-specific flavors, and anything else is invalid. That<br></div><div> doesn't seem correct.<br></div><div><br></div><div> In #2, we have a single class for any dimensionality of pixel coordinate. So, the pixelCoord attribute is <br></div><div> an array of 1..3 values depending on the dimensionality of the pixel coordinate frame. This is equivalent<br></div><div> to pixelCoord:RealQuantity[naxes], with naxes constrained to {1..3}. Here, one could make separate <br></div><div> classes of PixelCoordinate for the 1D, 2D, 3D cases, but that adds a good bit of bloat for little gain.<br></div><div><br></div><div> Both of these are similar to the string[0..*] type cases in the vo-dml multipliticy thread. (DataID.contributors:string[0..*] )<br></div><div> and boil down to the question.. do we allow varying length attribute arrays or force the generation of <br></div><div> a container object these cases.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Mark<br><br></div></font></span><span class=""><div><br></div><div><br><br><br><br><br><div><div><div><div><br><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The other concerns the multiplicity of datatype attributes.<span style="font-size:24pt"><span style="color:rgb(15,111,198);font-family:"Wingdings 2";font-size:85%"><br></span></span><font size="2"><span style="font-family:arial,helvetica,sans-serif"><span style="color:black">Attributes
can only have a specific length, specified in the model;<br>i.e., an object cannot
contain a variable array of values.<br>STC2 runs into this in some places where that rule is uncomfortably<br>restrictive; for example:</span></span></font><font size="2"><span style="font-family:arial,helvetica,sans-serif"></span></font><font size="2"><span style="font-family:arial,helvetica,sans-serif"><span><span style="color:rgb(0,157,217)"><br>—</span></span><span style="color:black">- A
polynomial object cannot contain an order and an array of coefficients,<br> its
length determined by the order</span></span></font><font size="2"><span style="font-family:arial,helvetica,sans-serif"></span></font><font size="2"><span style="font-family:arial,helvetica,sans-serif"><span><span style="color:rgb(0,157,217)"><br>—</span></span><span style="color:black">- One
cannot leave the dimensionality of a value (1, 2, or 3) open</span></span></font><font size="2"><span style="font-family:arial,helvetica,sans-serif"></span></font><font size="2"><span style="font-family:arial,helvetica,sans-serif"><span><span style="color:rgb(0,157,217)"><br>—</span></span><span style="color:black">- The
coordinate values of an enumerated axis cannot be specified in a vector</span></span></font>
<br><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>The way to get around this is to turn these items into objects/classes.<br></div><div>But that, in my view, unnecessarily complicates the model further, since<br></div><div>a simple array of data values suffices in these situations.<br></div><div>Dynamic sizing of arrays/vectors of data values at the time of instantiation<br></div><div>is, I think, a must.<br><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br><br> </div></div></div></div></div></div></div></div></div></div></span></div></div>
</blockquote></div><br></div>