STC2 Model and VO-DML Issues

[Gerard Lemson]

Hi Arnold and all

Good to do this on mailing list indeed, thank you Mark.



Improvements in text are no doubt necessary and I will be happy to react on
each comment. So please all start reading.

I will make updates and commit changes to the volute version of the
documents regularly (as uploading to IVOA documents is a slow process).

So please look at
https://volute.g-vo.org/svn/trunk/projects/dm/vo-dml/doc/VO-DML-WD-v1.0.docx
(or *.pdf).



Constraints are currently modelled in a rather implicit manner. In
particular for custom constraints there is **no** formal language, simple
English is deemed sufficient for now. There is a special type of
constraints that represents the subsetting pattern in UML and which is more
explicit and already frequently used. The latest update to the VO-DML doc
was partially made to create this constraint, where before it required a
redefinition of a Role, which would complicate the vodml-id referencing
mechanism.

I think this should suffice for version 1.0 of VO-DML. In particular
because the only formal constraint language I know of (OCL) is itself
highly complex and, without automated translators to other languages, will
not buy us anything beyond what an ordinary  English description gives us.



As to the particular issue about multiplicities of Attributes, this is a
more involved discussion that I will respond to in a separate email.

Note that part of it requires one to check whether the model that
supposedly needs such updates actually does so on good grounds, or whether
that model can be changed (and possibly improved!) by conforming to the
more restricted set of modelling features.

So please all start reading STC2 as well so we can have an informed
discussion!



Cheers

On Sat, Oct 31, 2015 at 10:28 PM, Arnold Rots <arots at cfa.harvard.edu> wrote:

> We have recently had some discussions on VO-DML in the context
> the the STC2 model, that Mark suggested should be summarized to
> the DM list to entice larger participation.
>
> The current version of the STC2 model is now posted on:
>
> https://volute.g-vo.org/svn/trunk/projects/dm/vo-dml/models/STC2/2015-10-30/
> As reported yesterday, the following action items have been resolved:
> - Transformations are done in atomic fashion, following the AST style
> - Gerard has a scrippt that will process the XMI file
> The following actions are in progress:
> - Complete the enumerations of standard frames and standard positions
>    This is trivial and quick
> - Complete the in-model documentation
>    Most description boxes in the documentation are still empty
> - Investigate (and experiment with) defining specialized coordinates
>    through subsetting. A first attempt is contained in the Specialized
>    package; but it is not clear this is worthwhile.
> The following items are still to be tackled
> - Writing a WD
>    It probably makes more sense to draft that on the basis of completed
>    documentation (see above)
> - Collaborating with whoever (if anyone) is working on the Units model
>    The issue is the mechanism to restrict units according to context;
>    STC2 includes such a mechanism, but this needs to be done in
>    consultation
> - Generate a library from the processed model
>    The intent is that this be linked to the AST library for transformations
> - Resolve remaining VO-DML issues
>
>
> This last point is the second subject of this message.
> There are two places where the STC2 VO-DML model runs into trouble.
>
> One is a relatively trivial one. I would like to request that the VO-DML
> WD include a section on the syntax of Constraints. It is hard to find
> documentation on this (at least, I find it hard), and adding his would be
> very helpful.
>
> 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.
>
>
> This is a summary of the arguments I have made over the past few days;
> I'll leave it to the other participants to voice their opinions.
>
> Cheers,
>
>   - Arnold
>
> PS: My access to internet connectivity will be spotty, at best, this
> coming week.
>
>
> -------------------------------------------------------------------------------------------------------------
> 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/
>
> --------------------------------------------------------------------------------------------------------------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20151101/0f2b0b2e/attachment.html>