<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I'm travelling up to Monday</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Laurent<br><br>Chuss/Salut/Bye from my <span style="font-size: 13pt;"> IThing</span><div><div>Laurent</div><div><br></div></div></div><div><br>Le 14 janv. 2016 à 14:50, Gerard Lemson <<a href="mailto:glemson1@jhu.edu">glemson1@jhu.edu</a>> a écrit :<br><br></div><blockquote type="cite"><div><span>HI Laurent</span><br><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I'm always a bit puzzled with what is VODML done for or not.</span><br></blockquote><blockquote type="cite"><span>So let's keep away from the VODML machinery and move back to the point of</span><br></blockquote><blockquote type="cite"><span>view of a VO-DML naive user, I mean not a list subscriber.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span>Could you explain what a naïve VO-DML user is supposed to be? We have used the phrase "naïve" as characterizing a particular type of software clients of the VOTable mapping specification, are you referring to those?</span><br><span>Otherwise, Naïve persons, in the sense that they do not need to understand VO-DML for example, should not be allowed to perform data modelling efforts in the IVOA. No one naïve should think they can perform annotation of data sets with VO-DML. I would argue this is no different from any other IVOA effort. People need to follow the standards to create resources that implement them, be they protocols, or data formats or data models. And they should better understand the standards if they want to use these implementations, be it directly, or by writing a client that allows other people a simple(r) interface to them.</span><br><span></span><br><span>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.</span><br><span></span><br><span></span><br><span></span><br><span></span><br><blockquote type="cite"><span>If a model states that an attribute must take its value among an enumeration,</span><br></blockquote><blockquote type="cite"><span>then items of that enumeration must refer of the modelled domain as any other</span><br></blockquote><blockquote type="cite"><span>attribute value. They must not refer to the meta model used by the tool.</span><br></blockquote><blockquote type="cite"><span>How can my modeller understand that he is allowed to state</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> object.Mission = "XMM-Newton"</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>But that at the same time, he is not allowed to state that</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span> object.Band = "X-ray"</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>just because the Band field is an enumeration.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span>First, your example seem to me to be serialization examples, *not* modelling examples.</span><br><span>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.</span><br><span>I don't think this is strange at all and caused simply by the fact that VO-DML is a strongly types language. </span><br><span>For example in Java you have a completely analogous situation.</span><br><span>There one may define for example:</span><br><span></span><br><span>public enum Band {</span><br><span> xray, optical, radio;</span><br><span>}</span><br><span>(Note that the literals conform to certain syntax rules, for example x-ray is not allowed.)</span><br><span></span><br><span>I can define a class </span><br><span>public class UseBand {</span><br><span> private Band band;</span><br><span> private String otherBand;</span><br><span>}</span><br><span>In some declaration you might wish to define: </span><br><span></span><br><span>UseBand object = new UseBand();</span><br><span>object.band=Band.xray;</span><br><span>object.otherBand = "Rolling Stones";</span><br><span></span><br><span>but </span><br><span>object.band = "xray" </span><br><span>would be illegal as UseBand.band is of type Band, not of type String.</span><br><span>That's all.</span><br><span></span><br><span>Yes, I could use </span><br><span>object.band=Band.valueOf("xray");</span><br><span></span><br><span>And yes, I could complicate my code further with special string values used to refer to these (say as in the second reply in <a href="http://stackoverflow.com/questions/604424/convert-a-string-to-an-enum-in-java">http://stackoverflow.com/questions/604424/convert-a-string-to-an-enum-in-java</a>). But the literal represented by the value is still of type Band, not of type String.</span><br><span></span><br><span>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. </span><br><span></span><br><span>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.</span><br><span></span><br><span>Plenty of options, that in my opinion are actually more suitable in the IVOA, data integration context which VO-DML is supposed to support.</span><br><span></span><br><span>Cheers</span><br><span></span><br><span>Gerard</span><br><span></span><br><span></span><br><span></span><br><blockquote type="cite"><span>I understand well the motivation for this in VO-DML, but to me that is rather a</span><br></blockquote><blockquote type="cite"><span>lack in the system than an intuitive feature.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span></span><br><span></span><br><blockquote type="cite"><span>Cheers</span><br></blockquote><blockquote type="cite"><span>Laurent</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Le 12/01/2016 17:32, <a href="mailto:gerard.lemson@gmail.com">gerard.lemson@gmail.com</a> a écrit :</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Hi Mark</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Gerard.. this was your own suggestion :)</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Yes, but I also mentioned my preferred alternative, which is leaving things as</span><br></blockquote></blockquote><blockquote type="cite"><span>they are *including* the constraint on the EnumLiteral names.</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>I'm not sure Marcus was voting against having a label as much as not</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>sure where it would be used. The pattern of having an enumeration</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>literal with a code and label seems pretty common and fits what we</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>are talking about. The description field is not appropriate as that</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>is more than just an alternate representation of the enum literal name.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>My position comes from that fact that I see no useful use case for introducing</span><br></blockquote></blockquote><blockquote type="cite"><span>an alternative label/title/.... At least not in VO-DML.</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>My motivation was that Enumerations are generally used as values for</span><br></blockquote></blockquote><blockquote type="cite"><span>attributes that put the attribute's owning type instances in a certain category.</span><br></blockquote><blockquote type="cite"><span>And a simple list of values [1,2,3,..., N] might work perfectly, assuming a proper</span><br></blockquote><blockquote type="cite"><span>description is provided.</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Enumerations are often used as a poor man's solution where an alternative</span><br></blockquote></blockquote><blockquote type="cite"><span>choice would be to create a full type hierarchy representing those categories.</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>So if you think that we need human readable values, do you propose the same</span><br></blockquote></blockquote><blockquote type="cite"><span>for Type names? And why would that be useful?</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>And if you think we need human readable titles/labels, why for example is</span><br></blockquote></blockquote><blockquote type="cite"><span>simple CamelCase not good enough?</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>For example, the SpectralBandType (again)</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> name label description</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> OPTICAL Optical "0.3 microns <= wavelength <= 1 micron"</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> UV UltraViolet "100 Angstrom <= wavelength <= 3000 Angstrom"</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> XRAY X-ray "0.1 Angstrom <= wavelength <= 100 Angstrom"</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>satisfies everyone's needs, so seems like a very reasonable approach.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Are you saying that</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> name description</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> Optical "0.3 microns <= wavelength <= 1 micron"</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> UltraViolet "100 Angstrom <= wavelength <= 3000 Angstrom"</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span> XRay "0.1 Angstrom <= wavelength <= 100 Angstrom"</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>does not satisfy everybody's needs? Who are these people and coders that</span><br></blockquote></blockquote><blockquote type="cite"><span>would need the label to be able to understand how to map their data to the</span><br></blockquote><blockquote type="cite"><span>common model? Why all-caps for enumliteral names? Why use a grammar</span><br></blockquote><blockquote type="cite"><span>suitable for English phrases? Don't say that this is for human readable UIs, for</span><br></blockquote><blockquote type="cite"><span>than all non-English speakers might well be offended.</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Remember that this exercise is not just to write models conforming to</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>VO-DML, but also to exercise VO-DML and its ability to serve the modeling.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Indeed, but I would also hope that these examples and the discussions help to</span><br></blockquote></blockquote><blockquote type="cite"><span>make people realize the semantics of VO-DML concepts and its supposed usage.</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Which is primarily annotation of data sets for use by software. In general we</span><br></blockquote></blockquote><blockquote type="cite"><span>will encounter instance of VO-DML concepts (types etc) in circumstances that</span><br></blockquote><blockquote type="cite"><span>cannot be interpreted as a "faithful", 1-1 representation. It is up to "annotators"</span><br></blockquote><blockquote type="cite"><span>to identify their representations with those in a model. For this they will have to</span><br></blockquote><blockquote type="cite"><span>understand the local concept and the VO-DML version of it. I cannot believe that</span><br></blockquote><blockquote type="cite"><span>it would help them greatly to have a label in vernacular English.</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>I would also refer to Omar's presentation in Heidelberg about robots and</span><br></blockquote></blockquote><blockquote type="cite"><span>utypes, emphasizing that human readability is *not* the main requirement of</span><br></blockquote><blockquote type="cite"><span>our work (apart obviously from documentation/descriptions.</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Cheers</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Gerard</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Mark</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>On Mon, Jan 11, 2016 at 5:34 PM, <<a href="mailto:gerard.lemson@gmail.com">gerard.lemson@gmail.com</a></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span><<a href="mailto:gerard.lemson@gmail.com">mailto:gerard.lemson@gmail.com</a>> > wrote:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> HI Mark</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> > -----Original Message-----</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span> I agree with Markus' opinion, which was also my favorite, that we do</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>not need a human readable label|title|fullName. The 'description'</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>attribute can take care of the explanation. The name is the one to be</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>used in the computational context where one may wish to use the data</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>model. To me the fact that other standards did not use this is not so</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>important as those were not written in VO-DML.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>--</span><br></blockquote><blockquote type="cite"><span>jesuischarlie</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Laurent Michel</span><br></blockquote><blockquote type="cite"><span>SSC XMM-Newton</span><br></blockquote><blockquote type="cite"><span>Tél : +33 (0)3 68 85 24 37</span><br></blockquote><blockquote type="cite"><span>Fax : +33 (0)3 )3 68 85 24 32</span><br></blockquote><blockquote type="cite"><span><a href="mailto:laurent.michel@astro.unistra.fr">laurent.michel@astro.unistra.fr</a> <<a href="mailto:laurent.michel@astro.unistra.fr">mailto:laurent.michel@astro.unistra.fr</a>></span><br></blockquote><blockquote type="cite"><span>Université de Strasbourg <<a href="http://www.unistra.fr">http://www.unistra.fr</a>> Observatoire Astronomique</span><br></blockquote><blockquote type="cite"><span>11 Rue de l'Université</span><br></blockquote><blockquote type="cite"><span>F - 67200 Strasbourg</span><br></blockquote><blockquote type="cite"><span><a href="http://amwdb.u-strasbg.fr/HighEnergy/spip.php?rubrique34">http://amwdb.u-strasbg.fr/HighEnergy/spip.php?rubrique34</a></span><br></blockquote></div></blockquote></body></html>