STC2 Model and VO-DML Issues
Arnold Rots
arots at cfa.harvard.edu
Tue Dec 29 23:37:32 CET 2015
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>
More information about the dm
mailing list