<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.<br><br></div><div>Mark<br><br></div><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></div></div>