Fwd: RE: [vodml] EnumLiterals and vodml-id
Laurent Michel
laurent.michel at astro.unistra.fr
Wed Jan 20 17:27:56 CET 2016
Gerard
> 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?
Right. My MagicDraw fails for some XMI version issue.
> 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.
I swear I did :=)
> 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.
The problem is neither to understand what is wrong nor to get a fix, both doc and tool are well done. The problem is to
understand why it is wrong or not supported .
> 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.
I agree with this. Writing a note is big job (for you!), but I'm still thinking that such a document would be useful
>
> 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."
However, this option shouldn't be discarded a priori .
> 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.
Nothing disallow a language to be connected with an application domain (however again)
Laurent
>
>
>> 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
--
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