vo-dml for cube
Arnold Rots
arots at cfa.harvard.edu
Sat Dec 12 15:37:18 CET 2015
Just to make things clear for those in DM who have not paid much attention
to VO-DML, let me as a simple question.
Below, I offer two very simple models of a Polynomial.
They just provide the coefficients, so for argument's sake,
let's assume they are derived from an abstract Transformation class
that provides the independent variable x and the dependent variable y.
Model 1 is disallowed by the current VO-DML WD, Model 2 is legal.
My question: what is so wrong with Model 1 that it is disallowed
and why is Model 2 a so much better solution?
To me they look pretty equivalent and Model 1 is simpler.
Cheers,
- Arnold
Model 1
-------
Class Polynomial
attribute order
type = nonnegativeInteger
multiplicity = 1
attribute coeff
type = real
multiplicity = order+1
isOrdered = true
This evaluates y as:
y = sum (coeff[i] * x^i) where i=0..order
Model 2
-------
Class Coefficient
attribute value
type = real
multiplicity = 1
Class Polynomial
attribute order
type = nonnegativeInteger
multiplicity = 1
collection coeff
type = Coefficient
multiplicity = order+1
isOrdered = true
This evaluates y as:
y = sum (coeff[i].value * x^i) where i=0..order
-------------------------------------------------------------------------------------------------------------
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 Fri, Dec 11, 2015 at 10:32 AM, Arnold Rots <arots at cfa.harvard.edu> wrote:
> Yes, what I am proposing is an extension of what was agreed regarding the
> [0..]<literal> specification.
>
> I think requiring that the length of an array of values that is an
> attribute of an Objecttype (class) or Datatype (structure) has to be fixed
> by the data model is too restrictive.
> There are plenty of use cases where that length can only sensibly be set
> when instantiating the Object or Data item.
> Examples are:
> - The array of coefficients in a polynomial class; its length should be
> set by the order of the polynomial expression, which is a legitimate
> parameter for such an Objecttype
> - The pixel data values in a spectrum
> - The coordinate values along an enumerated coordinate axis
> - The number of samples in a time series
> Just think how often the length of an array is left variable in your code
> and set at runtime.
>
> VO-DML in its current specification requires that in such situations the
> array not be modeled as an array of data values (either primitive or
> compound - like structures), but as lists of objects - the instantiations
> of classes.
> My sense is that that is overkill and results in unnecessary overhead.
> There is no good reason to have to model a simple coefficient as a class in
> order to be able to use it in a polynomial class that has its order as a
> attribute.
>
> I think allowing multiplicity of attributes to be variable, but requiring
> it to be explicitly specified by a nonnegative integer attribute is an
> acceptable compromise for this issue.
>
> For me, the matter is that I need to have this issue resolved before I can
> proceed with the remainder of the STC2 development; it has become a major
> stumbling block requiring changes that I would prefer not to have to make.
> And, at the same time, I believe that this is an issue that will trip up
> future VO-DML developers as well, so I would rather see it changed right
> now.
>
> 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 Fri, Dec 11, 2015 at 7:58 AM, Gerard Lemson <glemson1 at jhu.edu> wrote:
>
>> HI (adding dm at ivoa in the Cc)
>>
>>
>>
>> Allowing 0..n, implying EITHER 0 OR exactly n with n a literal is same as
>> discussed before (and below in email trail).
>>
>> The current doc does not include this yet, I have had no other opinions
>> about this but yours, but I think it is reasonable.
>>
>> I thought I had already updated the doc, but apparently not yet.
>>
>>
>>
>> Allowing n to be an integer attribute with multiplicity 1 I am still
>> strongly against.
>>
>> For example, what if, after initializing the 0..n attribute, you change
>> the value of n?
>>
>> This possibility implies to me still that the concept represented by the
>> 0..n attribute should not be a datatype, but should be represented by a
>> collection of object types.
>>
>>
>>
>> I am also still doubtful of the use cases that would seem to require this.
>>
>> The cases where I have seen you use this feature in STC can and imho
>> SHOULD be designed differently.
>>
>> I think the dm group MUST start looking seriously at STC before its
>> presumed requirements are used to influence the language.
>>
>>
>>
>> Any comments from the others.
>>
>>
>>
>> Cheers
>>
>> Gerard
>>
>>
>>
>>
>>
>> *From:* Arnold Rots [mailto:arots at cfa.harvard.edu]
>> *Sent:* Thursday, December 10, 2015 5:23 PM
>> *To:* Gerard Lemson <glemson1 at jhu.edu>
>> *Cc:* CresitelloDittmar, Mark <mdittmar at cfa.harvard.edu>; Omar Laurino (
>> olaurino at head.cfa.harvard.edu) <olaurino at head.cfa.harvard.edu>;
>> msdemlei at ari.uni-heidelberg.de
>>
>> *Subject:* Re: vo-dml for cube
>>
>>
>>
>> Would it be acceptable extend this slightly:
>>
>> Multiplicity must be "[0..]n", meaning that the multiplicity is either 0
>> (but only if "0.." is present) or n,
>>
>> and where n is either a numeric literal or an existing nonnegative
>> integer attribute with multiplicity 1.
>>
>> 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 Sat, Oct 31, 2015 at 9:16 AM, Gerard Lemson <glemson1 at jhu.edu> wrote:
>>
>> Hi Arnold
>>
>> Thanks, will pass through pipeline.
>>
>>
>>
>> To all:
>>
>> I think we should allow 0..n for attributes, but with a different
>> interpretation from its counterpart in composition relations and references.
>>
>> It would imply that the value of the attribute is either *, or an array
>> of length exactly n.
>>
>> In relations the interpretation remains that one can have between 0 and n
>> (inclusive) instances in the collection.
>>
>> Makes sense?
>>
>> Shall I update docs?
>>
>> Cheers
>>
>> Gerard
>>
>>
>>
>> *From:* Arnold Rots [mailto:arots at cfa.harvard.edu]
>> *Sent:* Saturday, October 31, 2015 8:50 AM
>> *To:* Gerard Lemson <glemson1 at jhu.edu>
>> *Cc:* Omar Laurino (olaurino at head.cfa.harvard.edu) <
>> olaurino at head.cfa.harvard.edu>; Mark Cresitello-Dittmar <
>> mdittmar at cfa.harvard.edu>; msdemlei at ari.uni-heidelberg.de
>>
>>
>> *Subject:* Re: vo-dml for cube
>>
>>
>>
>> I have checked in my latest version, 2015-10-30.
>>
>> - 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 Thu, Oct 29, 2015 at 8:46 AM, Gerard Lemson <glemson1 at jhu.edu> wrote:
>>
>> Hi Arnold
>>
>> (Cc-ing Markus)
>>
>> It was an unforeseen advantage that VO-DML makes it so much easier
>> identifying errors.
>>
>> Could you check in your latest version of the Umodel file(s) as well?
>>
>> In particular because I realize you are still using <<skosconcept>>,
>> whereas my XSLT is now looking for <<semanticconcept>>.
>>
>> Easy to fix by renaming stereotype. Also rename broadestSKOSConcept to
>> topConcept. I realize I can do the transformation in XSLT, but better if
>> the Umodel profile is as close to VO-DML as possible.
>>
>>
>>
>> The aspect ratio of the PNG is bit hard to control in GraphViz.
>>
>> It should be seen on a screen where you can zoom in/out and move the
>> diagram. Hard to print especially for unwieldy models ;)
>>
>> I find it nice to zoom out a lot to see where what colors reside and
>> which areas have lots of associations.
>>
>>
>>
>> Is there a document already describing the model? Are you going to add
>> description elements in the UML so they can be picked up by the XSLT?
>>
>> In particular, I’d be curious for a description of the contents of the
>> frametransform package. And about how/where is it supposed to be used.
>>
>>
>>
>> Cheers
>>
>> Gerard
>>
>>
>>
>> *From:* Arnold Rots [mailto:arots at cfa.harvard.edu]
>> *Sent:* Wednesday, October 28, 2015 6:37 PM
>> *To:* Gerard Lemson <glemson1 at jhu.edu>
>>
>>
>> *Cc:* Omar Laurino (olaurino at head.cfa.harvard.edu) <
>> olaurino at head.cfa.harvard.edu>; Mark Cresitello-Dittmar <
>> mdittmar at cfa.harvard.edu>
>> *Subject:* Re: vo-dml for cube
>>
>>
>>
>> Thank you.
>>
>> I had missed the error in coords - it's pretty hard to find in UModel.
>>
>> Yes, four double-l typos
>>
>> I replaced the subset on PixelFrame by a constraint.
>>
>> I had made an attempt to see whether providing defaults for attributes
>> like npix
>>
>> would solve the illegal multiplicities, but that doesn't do the trick. I
>> guess that
>>
>> one is for you to figure out.
>>
>> The question about the Qualifier was prompted by my wondering whether
>>
>> that could/should be the mechanism to split on the basis of dimensionality
>>
>> (instead of the naxes=naxes constraints).
>>
>> In specialized I wasn't clear on where to use "=" and where "->".
>>
>> I know you like those PNGs - I don't, because their ridiculous aspect
>>
>> ratio makes them very hard to navigate and impossible to print.
>>
>> 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 Wed, Oct 28, 2015 at 8:42 AM, Gerard Lemson <glemson1 at jhu.edu> wrote:
>>
>> Hi Arold
>>
>> Pretty similar, you have now and then some typos (pixellType with double
>> l). Attached the error report.
>>
>> I had made the coords.SpatialCoord.error an attribute, you still have it
>> as reference for some reason.
>>
>> You used to have a subsetted role on PixelFrame but no longer.
>>
>> Thanks for your pointer to qualifier documentation. From description
>> there this seems to be mainly aimed at implementations. If one would like
>> to partition collections of associated objects for conceptual (rather than
>> speed) reasons, you can (and I think “should”) always do that explicitly.
>>
>> Cheers
>>
>> Gerard
>>
>>
>>
>>
>>
>> *From:* Arnold Rots [mailto:arots at cfa.harvard.edu]
>> *Sent:* Wednesday, October 28, 2015 7:45 AM
>> *To:* Gerard Lemson <glemson1 at jhu.edu>
>> *Cc:* Omar Laurino (olaurino at head.cfa.harvard.edu) <
>> olaurino at head.cfa.harvard.edu>; Mark Cresitello-Dittmar <
>> mdittmar at cfa.harvard.edu>
>>
>>
>> *Subject:* Re: vo-dml for cube
>>
>>
>>
>> Gerard,
>>
>> Yes I got it and, for the sake of understanding it, produced my own
>> version.
>>
>> Can you check the attached XMI?
>>
>> I am not sure I have the constraint syntax right in the Specialized
>> package.
>>
>> The qualifier question isn't really relevant anymore, but no, I didn't
>> mean
>>
>> ordered. I meant the use of a qualifier on an association, as in
>> http://www.uml-diagrams.org/property.html
>>
>> 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 Wed, Oct 28, 2015 at 6:54 AM, Gerard Lemson <glemson1 at jhu.edu> wrote:
>>
>> Hi Arnold
>>
>> Yes, when looking at the model I understood your question better.
>>
>> Have you seen my version with the possible fixes in place?
>>
>> Btw, when you asked about qualifiers relations, did you think about
>> things like “ordered”?
>>
>> That particular one already exists (isOrdered), were there other ones you
>> were thinking about?
>>
>> Btw, In that case the ordering is supposed to be “implicitly” imposed by
>> the order in which elements were added to the collection.
>>
>>
>>
>> Cheers
>>
>> Gerard
>>
>>
>>
>> *From:* Arnold Rots [mailto:arots at cfa.harvard.edu]
>> *Sent:* Tuesday, October 27, 2015 4:27 PM
>>
>>
>> *To:* Gerard Lemson <glemson1 at jhu.edu>
>> *Cc:* Omar Laurino <olaurino at head.cfa.harvard.edu>; Mark
>> Cresitello-Dittmar <mdittmar at cfa.harvard.edu>
>> *Subject:* Re: vo-dml for cube
>>
>>
>>
>> Ah, yes. That is what my earlier question was about.
>>
>> Will try to fix.
>>
>> - 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, Oct 27, 2015 at 9:43 AM, Gerard Lemson <glemson1 at jhu.edu> wrote:
>>
>> Hi Arnold
>>
>> Getting errors below after transforming to VO-DML and validating.
>>
>> Most have to do with your use of an attribute inside a multiplicity
>> constraint. Please create a real constraint about that in some way.
>>
>> And there is the case where you define a constraint by susetting, in
>> Xform3D for example. Use an ordinary constraint there.
>>
>> I can make a suggested version and check it in once I’m at workCHeers
>>
>> Gerard
>>
>>
>>
>>
>>
>> XSD:
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:445:54:
>> cvc-pattern-valid: Value '{multiplicity=naxes}' is not facet-valid with
>> respect to pattern '[\w_-]+:[\w_\-/\./*]+' for type 'VODMLREF'.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:445:54:
>> cvc-type.3.1.3: The value '{multiplicity=naxes}' of element 'vodml-ref' is
>> not valid.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:772:53:
>> cvc-pattern-valid: Value '{multiplicity=npix}' is not facet-valid with
>> respect to pattern '[\w_-]+:[\w_\-/\./*]+' for type 'VODMLREF'.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:772:53:
>> cvc-type.3.1.3: The value '{multiplicity=npix}' of element 'vodml-ref' is
>> not valid.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:827:53:
>> cvc-pattern-valid: Value '{multiplicity=npix}' is not facet-valid with
>> respect to pattern '[\w_-]+:[\w_\-/\./*]+' for type 'VODMLREF'.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:827:53:
>> cvc-type.3.1.3: The value '{multiplicity=npix}' of element 'vodml-ref' is
>> not valid.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:882:53:
>> cvc-pattern-valid: Value '{multiplicity=npix}' is not facet-valid with
>> respect to pattern '[\w_-]+:[\w_\-/\./*]+' for type 'VODMLREF'.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:882:53:
>> cvc-type.3.1.3: The value '{multiplicity=npix}' of element 'vodml-ref' is
>> not valid.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:937:53:
>> cvc-pattern-valid: Value '{multiplicity=npix}' is not facet-valid with
>> respect to pattern '[\w_-]+:[\w_\-/\./*]+' for type 'VODMLREF'.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:937:53:
>> cvc-type.3.1.3: The value '{multiplicity=npix}' of element 'vodml-ref' is
>> not valid.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:992:53:
>> cvc-pattern-valid: Value '{multiplicity=npix}' is not facet-valid with
>> respect to pattern '[\w_-]+:[\w_\-/\./*]+' for type 'VODMLREF'.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:992:53:
>> cvc-type.3.1.3: The value '{multiplicity=npix}' of element 'vodml-ref' is
>> not valid.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:1047:52:
>> cvc-pattern-valid: Value '{muliplicity=npix}' is not facet-valid with
>> respect to pattern '[\w_-]+:[\w_\-/\./*]+' for type 'VODMLREF'.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:1047:52:
>> cvc-type.3.1.3: The value '{muliplicity=npix}' of element 'vodml-ref' is
>> not valid.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:1102:52:
>> cvc-pattern-valid: Value '(multiplicity=npix' is not facet-valid with
>> respect to pattern '[\w_-]+:[\w_\-/\./*]+' for type 'VODMLREF'.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:1102:52:
>> cvc-type.3.1.3: The value '(multiplicity=npix' of element 'vodml-ref' is
>> not valid.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:1207:54:
>> cvc-pattern-valid: Value '(multiplicity=order}' is not facet-valid with
>> respect to pattern '[\w_-]+:[\w_\-/\./*]+' for type 'VODMLREF'.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:1207:54:
>> cvc-type.3.1.3: The value '(multiplicity=order}' of element 'vodml-ref' is
>> not valid.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:1320:55:
>> cvc-pattern-valid: Value '{mulitiplicity=naxes}' is not facet-valid with
>> respect to pattern '[\w_-]+:[\w_\-/\./*]+' for type 'VODMLREF'.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:1320:55:
>> cvc-type.3.1.3: The value '{mulitiplicity=naxes}' of element 'vodml-ref' is
>> not valid.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:1509:49:
>> cvc-pattern-valid: Value '{Xform.naxes=1}' is not facet-valid with respect
>> to pattern '[\w_-]+:[\w_\-/\./*]+' for type 'VODMLREF'.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:1509:49:
>> cvc-type.3.1.3: The value '{Xform.naxes=1}' of element 'vodml-ref' is not
>> valid.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:1550:49:
>> cvc-pattern-valid: Value '{Xform.naxes=2}' is not facet-valid with respect
>> to pattern '[\w_-]+:[\w_\-/\./*]+' for type 'VODMLREF'.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:1550:49:
>> cvc-type.3.1.3: The value '{Xform.naxes=2}' of element 'vodml-ref' is not
>> valid.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:1616:49:
>> cvc-pattern-valid: Value '{Xform.naxes=3}' is not facet-valid with respect
>> to pattern '[\w_-]+:[\w_\-/\./*]+' for type 'VODMLREF'.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml:1616:49:
>> cvc-type.3.1.3: The value '{Xform.naxes=3}' of element 'vodml-ref' is not
>> valid.
>>
>> [*schemavalidate*]
>> C:\workspaces\eclipse-luna-4.4.1\vo-urp-etc\vo-dml-g-vo\models\STC2\2015-10-25\STC2.vo-dml.xml
>> is not a valid XML document
>>
>>
>>
>> Schematron:
>>
>> -------
>>
>> error:
>>
>> -------
>>
>> *datatype* stc2:stctypes.MultiStruct of reference
>> coords.SpatialCoord.error is not an object type but a 'dataType'
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* Arnold Rots [mailto:arots at cfa.harvard.edu]
>> *Sent:* Tuesday, October 27, 2015 8:24 AM
>> *To:* Gerard Lemson <glemson1 at jhu.edu>
>> *Cc:* Omar Laurino <olaurino at head.cfa.harvard.edu>; Mark
>> Cresitello-Dittmar <mdittmar at cfa.harvard.edu>
>>
>> *Subject:* Re: vo-dml for cube
>>
>>
>>
>> Gerard,
>>
>> I tried to fix everything up the way it should be
>>
>> and posted it under 2015-10-25.
>>
>> Could you see whether that will rattle through your script?
>>
>> I'm not sure I did get it all right.
>>
>> I did split the transformations into atomic ones.
>>
>> - 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 Mon, Oct 26, 2015 at 11:52 PM, Arnold Rots <arots at cfa.harvard.edu>
>> wrote:
>>
>> Gerard,
>>
>> Do I understand correctly that your subsetting constraint is owned by the
>> property to which it applies; while a vanilla constraint is owned by the
>> object that contains the property to which it applies?
>>
>> Btw, does VO_DML allow qualifiers on relations? I don't think so, but
>> should it?
>>
>> - Arnold
>>
>> On Oct 26, 2015 10:35 PM, "Gerard Lemson" <glemson1 at jhu.edu> wrote:
>>
>> Hi Arnold
>>
>> In UML (MD) I do subsetting still the same way, defining it on the Role
>> (Attribute, Reference or Collection).
>>
>> (Mark, can you actually do this in Modelio?).
>>
>> I just now translate it to a SubsettingConstraint on the Type owning the
>> Role rather than defining a separate Role for it. That is a special
>> Constraint, that has a pointer to the subsetted Role.
>>
>> Has some nice features compared to the old model. Most important is that
>> it solves the problem that Omar identified, that the redefinition would
>> require a separate vo-dml id for the new Role. Also, the concept is really
>> a constraint on allowable values of the structural element defined above.
>>
>> Cheers
>>
>> Gerard
>>
>>
>>
>>
>>
>> *From:* Arnold Rots [mailto:arots at cfa.harvard.edu]
>> *Sent:* Monday, October 26, 2015 7:21 AM
>> *To:* Gerard Lemson <glemson1 at jhu.edu>
>> *Cc:* CresitelloDittmar, Mark <mdittmar at cfa.harvard.edu>; Omar Laurino (
>> olaurino at head.cfa.harvard.edu) <olaurino at head.cfa.harvard.edu>
>> *Subject:* Re: vo-dml for cube
>>
>>
>>
>> Gerard,
>>
>> How do you want constraints expressed:
>>
>> just like any ordinary UML constraint, on the class,
>>
>> or using your subsetting mechanism, in which case it can be associated
>> directly with an attribute?
>>
>> - 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 Sat, Oct 24, 2015 at 9:04 AM, Gerard Lemson <glemson1 at jhu.edu> wrote:
>>
>> Hi Mark
>>
>>
>>
>> Ok, I did not import ds as I did not know where the model was.
>>
>> This can be updated if you point me to it. Do yu have a separate Modelio
>> project for that?
>>
>> Based on what I did for stc2 you can see how to proceed (I hope ;)
>>
>>
>>
>> Stereotypes can be created on the root, with “Create stereotype”.
>>
>> I had problems seeing where they end up.
>>
>> In case you don’t know this already, on the project view window, in the
>> top right there is a triangle.
>>
>> Open up the menu and click Show Options > Show MDA model
>>
>> This will show a new item, “LocalModule” that shows all the stereotypes
>> under LocalProfile.
>>
>> Right click a stereotype and use Create element > Tag type.
>>
>> When now assigning the stereotype to an element, you can give values for
>> that tag type.
>>
>> Select the element, go to the “Elements” Tab. You should see the
>> stereotype show up below UML and Modeler Module.
>>
>> Clicking it will show the tags and you can add a value.
>>
>> I am using this for example for modelimport to define the url and
>> documentationURL.
>>
>> Similarly for <<Model>> you can add author, version etc.
>>
>>
>>
>> Let me know if yu can see all of this on the Cube-GL.zip version I
>> checked in.
>>
>>
>>
>> Are you in Australia already? Enjoy the meeting in any case and let me
>> know if/when I may participate in a session.
>>
>>
>>
>> Cheers
>>
>>
>>
>> Gerard
>>
>>
>>
>>
>>
>> *From:* CresitelloDittmar, Mark [mailto:mdittmar at cfa.harvard.edu]
>> *Sent:* Saturday, October 24, 2015 2:38 AM
>> *To:* Gerard Lemson <glemson1 at jhu.edu>
>> *Cc:* Arnold Rots <arots at cfa.harvard.edu>; Omar Laurino (
>> olaurino at head.cfa.harvard.edu) <olaurino at head.cfa.harvard.edu>
>> *Subject:* Re: vo-dml for cube
>>
>>
>>
>> that's great news.
>>
>> I sent comments from the other thread, but yes.. stc and ds are imported
>> to cube. dataset has it's own model/xmi file.
>>
>> I'll want to see what you did with the stereotypes.. you were able to
>> generate new ones?
>>
>> The stc2 model in my cube doc is a little different than arnolds, but
>> most closely related to the 2015-10-14 stuff.
>>
>> In the end, all the stc2 content will be removed from dataset, and
>> imported as you show.
>>
>> Mark
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20151212/a46d661c/attachment-0001.html>
More information about the dm
mailing list