STC2 Model and VO-DML Issues

[Arnold Rots]

This is a partial response. First just an update of the affected
occurrences, for the record.
The total is 19.

There is one instance in coords, your #1

There are 10 instances in frametransforms:
Your #2
Your #3 (2 instances)
Your #4 expands to include Enum2D and Enum3D (i.e., total 3 instances)
Your #5 expands to include PolCircular, PolLinear, PolVector (i.e., total 4
instances)

There is one instance in coordarea: PolCover

There are 7 instances in region:
Polygon, Convex, ConvexHull2D, ConvexHull3D, Union, Intersection, Difference
(though the last three can easily be dropped)


I'll respond to the use of the construction:
nitems: nonnegativeinteger, multiplicity 1
array: real, multiplicity 0,nitems

I introduced the requirement that there be an attribute holding the length
of the array
as a kind of compromise between requiring the length of the array to be
specified
explicitly through a literal in the model (as VO-DML currently requires)
and leaving that
length completely open. I was hoping that that would make it more palatable
for Gerard ;-)
The question: what happens when the length is changed by dropping or adding
elements to the array? actually raises a more philosophical issue:
If we have an instantiation of a Datatype or a Class, containing an array
of attributes,
and we change the length if that array, is it still the same instantiation
or have we
created a new instantiation by making that change?
If it is the latter, the issue of nitems changing value is moot: we have
not changed
its value, but we have created a new instance with a different value of
nitems.

Cheers,

  - Arnold


-------------------------------------------------------------------------------------------------------------
Arnold H. Rots                                          Chandra X-ray
Science Center
Smithsonian Astrophysical Observatory                   tel:  +1 617 496
7701
60 Garden Street, MS 67                                      fax:  +1 617
495 7356
Cambridge, MA 02138
arots at cfa.harvard.edu
USA
http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------------------------------------------


On Tue, Dec 29, 2015 at 4:34 PM, CresitelloDittmar, Mark <
mdittmar at cfa.harvard.edu> wrote:

> All,
>
> 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
>
> From what I can see, the list of conflicts are:
> 1) Coords.generic:GenericCoord[*]
>
> 2) PixelCoordinate.naxes:nonnegativeInteger[1]
>     PixelCoordinate.pixelCoord:RealQuantity[1..3]  {constraint
> pixelCoord.size == naxes}
>
> 3) Polynomial1D.order:nonnegativeInteger[1]
>     Polynomial1D.coeff:real[1..*]  {constraint coeff.size = order+1}
>     Polynomial2D.order:nonnegativeInteger[1]
>     Polynomial2D.coeff.real[1..*]  {constraint coeff.size = order*order+1}
>
> 4) EnumScalar.npix:nonnegativeInteger[1]
>     EnumScalar.ec:RealQuantity[1..*]  {constraint  ec.size = npix}
>     same for Enum2D, Enum3D
>
> 5) PolStokes.npix:nonnegativeInteger[1]
>     PolStokes.pixelType:PolStokes[1..*]  {pixelType.size = npix}
>
> NOTE: there are a couple others in the region and area packages, which I
> have not looked at.
> These are in my area of interest in supporting the Cube work.
>
> #4 and #5: Lookups
>   + npix is solely providing the length of the corresponding value array.
> As such, it could be considered a
>      non-modeled derived property of the element.  ie: npix = length of
> the array.
>      Note: This leaves the [1..*] multiplicity on value attribute.
>   alternatively
>   + one could model the Enum (lookup) as a sequence of EnumElements.
>      Each element would connect the native value to the target value.  The
> Enum/Polarization lookups in STC2
>      use an implicit native value (the pixel, or index #).  I prefer the
> explicit version I have in the STC2-prototype
>      within the Dataset model, which allows the nativeValue to be random.
> NOTE: These are not mutually exclusive,
>      In this case, the relation from Enum class to EnumElement would be
> 1..*, and npix would still be a non-modeled
>      derived property defined by the number of EnumElements.
>      Here, I think this approach makes sense, as the number of elements
> could change through filtering but
>      not effect the individual mapping.
>
> #3: Polynomial coefficients
>   + here 'order' is hard-linked to the length of the 'coeff' array, but in
> a slightly more complicated way.
>      For the 1D case,  coeff.size = order+1; while for 2D, coeff.size =
> order*order+1.
>      So again, this could be considered a non-modeled derived property of
> the Polynomial transform.
>      Leaving coeff:real[1..*] with constraint { * = order+1 }
>   alternatively
>   + not sure I like this, but rather than requiring an ordered array for
> 'coeff', one could define a Coeff object with:
>      - term:nonnegativeInteger[1]  specifies the polynomial term to which
> the coefficient applies
>      - value:real[1]  the coefficient value
>     This would be compliant with the vodml spec, producing a 1..* relation
> between Polynomial and Coefficient
>      with only a little more complexity.
>
>
> #1 and #2: Coord arrays
>   In #1, we have a simple open-ended array of GenericCoordinate (which is
> a datatype).
>   I'm not sure there is an alternative here.  Unless it is to say that
> this case should not exist.. that all
>   coordinates must be represented by the domain-specific flavors, and
> anything else is invalid.  That
>   doesn't seem correct.
>
>   In #2, we have a single class for any dimensionality of pixel
> coordinate. So, the pixelCoord attribute is
>   an array of 1..3 values depending on the dimensionality of the pixel
> coordinate frame. This is equivalent
>   to pixelCoord:RealQuantity[naxes], with naxes constrained to {1..3}.
> Here, one could make separate
>   classes of PixelCoordinate for the 1D, 2D, 3D cases, but that adds a
> good bit of bloat for little gain.
>
>   Both of these are similar to the string[0..*] type cases in the vo-dml
> multipliticy thread. (DataID.contributors:string[0..*] )
>   and boil down to the question.. do we allow varying length attribute
> arrays or force the generation of
>   a container object these cases.
>
> Mark
>
>
>
>
>
>
>
>
> The other concerns the multiplicity of datatype attributes.
>> Attributes can only have a specific length, specified in the model;
>> i.e., an object cannot contain a variable array of values.
>> STC2 runs into this in some places where that rule is uncomfortably
>> restrictive; for example:
>> —- A polynomial object cannot contain an order and an array of
>> coefficients,
>>    its length determined by the order
>> —- One cannot leave the dimensionality of a value (1, 2, or 3) open
>> —- The coordinate values of an enumerated axis cannot be specified in a
>> vector
>> The way to get around this is to turn these items into objects/classes.
>> But that, in my view, unnecessarily complicates the model further, since
>> a simple array of data values suffices in these situations.
>> Dynamic sizing of arrays/vectors of data values at the time of
>> instantiation
>> is, I think, a must.
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20151229/93aaa29d/attachment-0001.html>