vo-dml for cube
Arnold Rots
arots at cfa.harvard.edu
Fri Dec 11 21:46:48 CET 2015
Well, the solution is simple (though tedious):
I can change all my Datatypes to Classes and associated Attributes to
Collections.
The issue simply is whetehr that is the correct thing to do from a modeling
point of view and my sense is that it isn't.
- 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 11:43 AM, Gerard Lemson <glemson1 at jhu.edu> wrote:
> Hi Arnold
>
> Am traveling, will reply in more detail later, but a quick over your use
> cases confirms the point that all can and (in my opinion) SHOULD be
> modelled NOT as attributes but as collections.
>
> Arguments about code have no place here, VO-DML is supposed to be
> application neutral.
>
> Serializations can optimize the storage requirements of their
> representations quite easily.
>
> So I think you need to do better.
>
>
>
> Wrt STC progress, I think you need support with that effort indeed, have
> other people look at it.
>
> I am happy to try to create versions that are semantically at least as
> rich as what you have now, more reusable, and eminently serializable,
> whilst staying within the bounds of the current VO-DML doc. But others with
> more relevant domain knowledge than I MUST start looking at the contents of
> STC as is.
>
>
>
> Cheers
>
> Gerard
>
>
>
>
>
>
>
> *From:* Arnold Rots [mailto:arots at cfa.harvard.edu]
> *Sent:* Friday, December 11, 2015 10:32 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>;
> msdemlei at ari.uni-heidelberg.de; dm at ivoa.net
>
> *Subject:* Re: vo-dml for cube
>
>
>
> 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/20151211/6b6bf141/attachment-0001.html>
More information about the dm
mailing list