STC2 Model and VO-DML Issues

[CresitelloDittmar, Mark]

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/17baaa52/attachment.html>