Fwd: RE: [vodml] EnumLiterals and vodml-id
Laurent Michel
laurent.michel at astro.unistra.fr
Tue Jan 19 15:26:09 CET 2016
[Due to an mis-typing on my part the message below has not been sent to the list on Yesterday]
-------- Message transféré --------
Sujet : RE: [vodml] EnumLiterals and vodml-id
Date : Mon, 18 Jan 2016 21:13:42 +0000
De : Gerard Lemson <glemson1 at jhu.edu>
Pour : Laurent Michel <laurent.michel at astro.unistra.fr>
Hi Laurent
(Do you want this to go to DM as well?)
> A naive user is someone who starts with reading the VO-DML spec and then
> runs its favourite XML editor (editX in my case) to begin the job. When the XSD
> validator complains, he/she jump into the doc to get a fix. I can even look at the
> XSD.
> He/she is naive in that he/she feels quite away from the arguments stated in this
> discussion.
>
I suppose that you try to use editX to create a VO-DML/XML model?
I still think that even a naïve modeler SHOULD read the full VO-DML spec, not just the XML schema, or otherwise MUST NOT be
surprised if parts of the model turn out to be invalid. But I also think they should be willing to accept the help of non-naïve
modelers, and particularly in a standard process like the IVOA we should not let the work be done by naïve modelers.
In the perfect scenario, if a modeler finds a validation error this should be taken as an indication it is making an error
(Wouldn't it be great if we could "prove" that?) and the document would provide the proper alternative.
But this requires the document explain all concepts as well as possible. This is the struggle. It is hard to anticipate however
why someone might have a problem with which modeling construct. I do remember you asking for a Note on how to create VO-DML
models, and this might be the place to mention lots of concrete examples. Maybe patterns can be extracted form that that help
the user. I think the discussions we're having will help defining what contents should be included there. Now I would be very
very happy if I had the time to spend on the Note, but currently mailing list and some concrete work with Tom is all I have time
for.
In fact it would be nice if the mailing list could be used in the way stackoverflow is used. Say someone might ask: "Hey, I am
encountering the following error in my VO-DML model validation. Could someone help me fix that?"
I'd be very happy to do so (and have gone through a lot of effort trying to help for example Arnold and Mark by creating XSLT
scripts translating XMI to VO-DML/XML for their UML modeling tools so they would not have to write VO-DML by hand).
That I think is far preferable to: "Hey, I am finding an error in my model. Change VO-DML for it should allow me to do what I
want here."
For then it seems to be that we have to accept that the model is correct, it must be the language that is to blame. My
experience tells me otherwise.
> Cheers and happy birthday (according to your Skype profile)
't was last week that I gained another year. Please don't remind me :)
Cheers
Gerard
>
> Laurent
>
> > In any case, VO-DML is a language for writing data models in the IVOA and in
> particular is tailored for use in annotations to support data integration between
> (generally) preexisting data sources. Primarily for annotating VOTables and
> through these also of FITS tables and TAP schemas for example. Especially the
> latter case is very promising. We anticipate that people may want to implement
> features of the model directly, e.g. by mapping faithfully, 1-1 to some OO
> language, e.g. Java. That is *not* its main use case, but we take the possibility
> into account. Similarly we try to accommodate possible representation in
> relational databases, use of identifiers (vodml-ref-s, formerly utypes) in
> hyperlinks, or more generally pointers, as well as use in query languages.
> >
> >
> >
> >
> >> If a model states that an attribute must take its value among an
> >> enumeration, then items of that enumeration must refer of the
> >> modelled domain as any other attribute value. They must not refer to the
> meta model used by the tool.
> >> How can my modeller understand that he is allowed to state
> >>
> >> object.Mission = "XMM-Newton"
> >>
> >> But that at the same time, he is not allowed to state that
> >>
> >> object.Band = "X-ray"
> >>
> >> just because the Band field is an enumeration.
> >>
> > First, your example seem to me to be serialization examples, *not* modelling
> examples.
> > But your main argument seems to be that it may be confusing that one can do
> one thing in one context, but must do something else in another context.
> > I don't think this is strange at all and caused simply by the fact that VO-DML is
> a strongly types language.
> > For example in Java you have a completely analogous situation.
> > There one may define for example:
> >
> > public enum Band {
> > xray, optical, radio;
> > }
> > (Note that the literals conform to certain syntax rules, for example
> > x-ray is not allowed.)
> >
> > I can define a class
> > public class UseBand {
> > private Band band;
> > private String otherBand;
> > }
> > In some declaration you might wish to define:
> >
> > UseBand object = new UseBand();
> > object.band=Band.xray;
> > object.otherBand = "Rolling Stones";
> >
> > but
> > object.band = "xray"
> > would be illegal as UseBand.band is of type Band, not of type String.
> > That's all.
> >
> > Yes, I could use
> > object.band=Band.valueOf("xray");
> >
> > And yes, I could complicate my code further with special string values used to
> refer to these (say as in the second reply in
> http://stackoverflow.com/questions/604424/convert-a-string-to-an-enum-in-
> java). But the literal represented by the value is still of type Band, not of type
> String.
> >
> > Now, if you could decide *not* to predefine (in the model) a set of
> (photometry) bands using an enumeration, but would define object.Band as a
> (ivoa:s)string, you can use "X-Ray". This of course is less restrictive, and so you
> might desire to assign a <<semanticconcept>> to the attribute that would
> restrict values to those defined in some vocabulary of bands.
> >
> > OR you might wish to reuse the Photometry data model where
> PhotometryBand is defined as an Object Type and would define a reference for
> band iso an attribute.
> >
> > Plenty of options, that in my opinion are actually more suitable in the IVOA,
> data integration context which VO-DML is supposed to support.
> >
> > Cheers
> >
> > Gerard
> >
> >
> >
> >> I understand well the motivation for this in VO-DML, but to me that
> >> is rather a lack in the system than an intuitive feature.
> >>
> >
> >
> >> Cheers
> >> Laurent
> >>
> >>
> >> Le 12/01/2016 17:32, gerard.lemson at gmail.com a écrit :
> >>> Hi Mark
> >>>>
> >>>> Gerard.. this was your own suggestion :)
> >>>>
> >>> Yes, but I also mentioned my preferred alternative, which is leaving
> >>> things as
> >> they are *including* the constraint on the EnumLiteral names.
> >>>
> >>>>
> >>>> I'm not sure Marcus was voting against having a label as much as
> >>>> not sure where it would be used. The pattern of having an
> >>>> enumeration literal with a code and label seems pretty common and
> >>>> fits what we are talking about. The description field is not
> >>>> appropriate as that is more than just an alternate representation of the
> enum literal name.
> >>>>
> >>> My position comes from that fact that I see no useful use case for
> >>> introducing
> >> an alternative label/title/.... At least not in VO-DML.
> >>> My motivation was that Enumerations are generally used as values for
> >> attributes that put the attribute's owning type instances in a certain category.
> >> And a simple list of values [1,2,3,..., N] might work perfectly,
> >> assuming a proper description is provided.
> >>> Enumerations are often used as a poor man's solution where an
> >>> alternative
> >> choice would be to create a full type hierarchy representing those categories.
> >>> So if you think that we need human readable values, do you propose
> >>> the same
> >> for Type names? And why would that be useful?
> >>> And if you think we need human readable titles/labels, why for
> >>> example is
> >> simple CamelCase not good enough?
> >>>
> >>>>
> >>>> For example, the SpectralBandType (again)
> >>>>
> >>>> name label description
> >>>>
> >>>> OPTICAL Optical "0.3 microns <= wavelength <= 1 micron"
> >>>>
> >>>> UV UltraViolet "100 Angstrom <= wavelength <= 3000 Angstrom"
> >>>>
> >>>> XRAY X-ray "0.1 Angstrom <= wavelength <= 100 Angstrom"
> >>>>
> >>>>
> >>>> satisfies everyone's needs, so seems like a very reasonable approach.
> >>>>
> >>> Are you saying that
> >>>
> >>> name description
> >>> Optical "0.3 microns <= wavelength <= 1 micron"
> >>> UltraViolet "100 Angstrom <= wavelength <= 3000 Angstrom"
> >>> XRay "0.1 Angstrom <= wavelength <= 100 Angstrom"
> >>>
> >>> does not satisfy everybody's needs? Who are these people and coders
> >>> that
> >> would need the label to be able to understand how to map their data
> >> to the common model? Why all-caps for enumliteral names? Why use a
> >> grammar suitable for English phrases? Don't say that this is for
> >> human readable UIs, for than all non-English speakers might well be
> offended.
> >>>
> >>>>
> >>>> Remember that this exercise is not just to write models conforming
> >>>> to VO-DML, but also to exercise VO-DML and its ability to serve the
> modeling.
> >>>>
> >>> Indeed, but I would also hope that these examples and the
> >>> discussions help to
> >> make people realize the semantics of VO-DML concepts and its supposed
> usage.
> >>> Which is primarily annotation of data sets for use by software. In
> >>> general we
> >> will encounter instance of VO-DML concepts (types etc) in
> >> circumstances that cannot be interpreted as a "faithful", 1-1 representation.
> It is up to "annotators"
> >> to identify their representations with those in a model. For this
> >> they will have to understand the local concept and the VO-DML version
> >> of it. I cannot believe that it would help them greatly to have a label in
> vernacular English.
> >>> I would also refer to Omar's presentation in Heidelberg about robots
> >>> and
> >> utypes, emphasizing that human readability is *not* the main
> >> requirement of our work (apart obviously from documentation/descriptions.
> >>>
> >>> Cheers
> >>>
> >>> Gerard
> >>>
> >>>>
> >>>> Mark
> >>>>
> >>>>
> >>>>
> >>>> On Mon, Jan 11, 2016 at 5:34 PM, <gerard.lemson at gmail.com
> >>>> <mailto:gerard.lemson at gmail.com> > wrote:
> >>>>
> >>>>
> >>>> HI Mark
> >>>>
> >>>> > -----Original Message-----
> >>>>
> >>>>
> >>>> I agree with Markus' opinion, which was also my favorite, that we
> >>>> do not need a human readable label|title|fullName. The 'description'
> >>>> attribute can take care of the explanation. The name is the one to
> >>>> be used in the computational context where one may wish to use the
> >>>> data model. To me the fact that other standards did not use this is
> >>>> not so important as those were not written in VO-DML.
> >>>>
> >>>>
> >>
> >> --
> >> jesuischarlie
> >>
> >> Laurent Michel
> >> SSC XMM-Newton
> >> Tél : +33 (0)3 68 85 24 37
> >> Fax : +33 (0)3 )3 68 85 24 32
> >> laurent.michel at astro.unistra.fr
> >> <mailto:laurent.michel at astro.unistra.fr>
> >> Université de Strasbourg <http://www.unistra.fr> Observatoire
> >> Astronomique
> >> 11 Rue de l'Université
> >> F - 67200 Strasbourg
> >> http://amwdb.u-strasbg.fr/HighEnergy/spip.php?rubrique34
>
> --
> jesuischarlie
>
> Laurent Michel
> SSC XMM-Newton
> Tél : +33 (0)3 68 85 24 37
> Fax : +33 (0)3 )3 68 85 24 32
> laurent.michel at astro.unistra.fr <mailto:laurent.michel at astro.unistra.fr>
> Université de Strasbourg <http://www.unistra.fr> Observatoire Astronomique
> 11 Rue de l'Université
> F - 67200 Strasbourg
> http://amwdb.u-strasbg.fr/HighEnergy/spip.php?rubrique34
More information about the dm
mailing list