<div dir="ltr"><div><div><div><div>Just for the record, I have no enumerations that violate the rules.<br></div>And I see no reason to need whitespace characters; CamelCase works just fine.<br><br></div>One clarification, though: are numerals allowed in the strings? (not that I have any)<br><br></div>Cheers,<br><br></div> - Arnold<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">-------------------------------------------------------------------------------------------------------------<br>Arnold H. Rots Chandra X-ray Science Center<br>Smithsonian Astrophysical Observatory tel: +1 617 496 7701<br>60 Garden Street, MS 67 fax: +1 617 495 7356<br>Cambridge, MA 02138 <a href="mailto:arots@cfa.harvard.edu" target="_blank">arots@cfa.harvard.edu</a><br>USA <a href="http://hea-www.harvard.edu/~arots/" target="_blank">http://hea-www.harvard.edu/~arots/</a><br>--------------------------------------------------------------------------------------------------------------<br><br></div></div></div>
<br><div class="gmail_quote">On Tue, Jan 12, 2016 at 11:32 AM, <span dir="ltr"><<a href="mailto:gerard.lemson@gmail.com" target="_blank">gerard.lemson@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mark<br>
<span class="">><br>
> Gerard.. this was your own suggestion :)<br>
><br>
</span>Yes, but I also mentioned my preferred alternative, which is leaving things as they are *including* the constraint on the EnumLiteral names.<br>
<span class=""><br>
><br>
> I'm not sure Marcus was voting against having a label as much as not sure where<br>
> it would be used. The pattern of having an enumeration literal with a code and<br>
> label seems pretty common and fits what we are talking about. The description<br>
> field is not appropriate as that is more than just an alternate representation of<br>
> the enum literal name.<br>
><br>
</span>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.<br>
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.<br>
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.<br>
So if you think that we need human readable values, do you propose the same for Type names? And why would that be useful?<br>
And if you think we need human readable titles/labels, why for example is simple CamelCase not good enough?<br>
<span class=""><br>
><br>
> For example, the SpectralBandType (again)<br>
><br>
> name label description<br>
><br>
> OPTICAL Optical "0.3 microns <= wavelength <= 1 micron"<br>
><br>
> UV UltraViolet "100 Angstrom <= wavelength <= 3000 Angstrom"<br>
><br>
> XRAY X-ray "0.1 Angstrom <= wavelength <= 100 Angstrom"<br>
><br>
><br>
> satisfies everyone's needs, so seems like a very reasonable approach.<br>
><br>
</span>Are you saying that<br>
<br>
name description<br>
<span class=""> Optical "0.3 microns <= wavelength <= 1 micron"<br>
</span><span class=""> UltraViolet "100 Angstrom <= wavelength <= 3000 Angstrom"<br>
</span> XRay "0.1 Angstrom <= wavelength <= 100 Angstrom"<br>
<br>
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.<br>
<span class=""><br>
><br>
> Remember that this exercise is not just to write models conforming to VO-DML,<br>
> but also to exercise VO-DML and its ability to serve the modeling.<br>
><br>
</span>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.<br>
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.<br>
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.<br>
<br>
Cheers<br>
<span class="HOEnZb"><font color="#888888"><br>
Gerard<br>
</font></span><span class="im HOEnZb"><br>
><br>
> Mark<br>
><br>
><br>
><br>
> On Mon, Jan 11, 2016 at 5:34 PM, <<a href="mailto:gerard.lemson@gmail.com">gerard.lemson@gmail.com</a><br>
</span><div class="HOEnZb"><div class="h5">> <mailto:<a href="mailto:gerard.lemson@gmail.com">gerard.lemson@gmail.com</a>> > wrote:<br>
><br>
><br>
> HI Mark<br>
><br>
> > -----Original Message-----<br>
><br>
><br>
> I agree with Markus' opinion, which was also my favorite, that we do<br>
> not need a human readable label|title|fullName. The 'description' attribute can<br>
> take care of the explanation. The name is the one to be used in the<br>
> computational context where one may wish to use the data model. To me the<br>
> fact that other standards did not use this is not so important as those were not<br>
> written in VO-DML.<br>
><br>
><br>
<br>
<br>
</div></div></blockquote></div><br></div>