<div dir="ltr"><div>On the topic of Enumeration Literals in VO-DML which came up in the recent interop.<br><br></div><div>I wanted to summarize the concern which was expressed and the historical discussion on the topic. I want to be sure everyone's concerns are heard and addressed, but this topic was HEAVILY discussed in 2016, and a consensus reached. I would like to avoid further delay in getting this standard to REC by re-opening the thread if possible. <br><br></div><div>Pat and Mireille... not to call you out, but if you could review the state and provide feedback as to whether you are OK or not going forward, that would be appreciated. If you, or anyone else interested in the topic still have concerns, we can discuss them here.<br><br></div><div><div><div>Enumeration Literals<br></div> - twiki post by PD: 5/17/2017<br><br>"Following my presentation at the interop, discussion of enumeration
literals continued. I pointed out that one cannot generate or write code
or an XSD file from only the vo-dml spec of a model due to the lack of
enumeration literals with the actual value: some other input would be
necessary. Given the goal of having a normative machine readable model
specification, I find the current enumeration feature lacking compared
to real usage requirements and I think punting this to serialisation or
mapping step leaves a gap"<br><br></div><div>Previous discussion on DM mail list:<br> [vodml] EnumLiterals and vodml-id: 01/2016<br> <a href="http://mail.ivoa.net/pipermail/dm/2016-January/005297.html">http://mail.ivoa.net/pipermail/dm/2016-January/005297.html</a><br></div> + very lengthy discussion on the subject<br><div><div> + was topic covered in face-to-face focus meeting Feb 2016<br> + closing summary 02/19/16</div> <a href="http://mail.ivoa.net/pipermail/dm/2016-February/005335.html">http://mail.ivoa.net/pipermail/dm/2016-February/005335.html</a><br><br>Basic summary:<br></div><div> + vo-dml spec does not address serialization at all, it identifies concepts<br></div><div> + the 'actual value' string representation is implementation dependent, and therefore on the Mapping side<br></div><div> + the OptionMapping (I think that's right) annotation allows users to associate their implementation string to the model concept. This allows the users to retain their local format, and compatibility with local software.<br></div><div> + alternatively, users can 'convert' the local value to match the vo-dml model concept name, removing the need for OptionMapping<br></div><div> + allowing a 'label' in Enumeration literal could hinder interoperability.. IF DatasetMetadata defines a CalibrationLevel enumeration with labels "RAW", "CALIBRATED", etc. .and CAOM would like to use the Dataset model, but has different labels for this concept.. what do they do? They would be forced to convert their values, or define a different enumeration for the same concept and extension to the model which uses it.<br><br></div><div>Enumeration Literal vs Semantic Concept<br></div><div> + related to this thread, is when it is appropriate to use enumerations vs semantic concepts.. the basic rule has been<br></div><div> Enumeration if:<br></div><div> 1) if the set is small<br></div><div> 2) set is stable.. unlikely to change<br></div><div><br> + I would add a third rule to this list (if it isn't already)<br></div><div> 3) the vocabulary itself is not significant<br><br></div><div> For some cases (eg: UCDs), the actual string value is significant and may/may-not comply with vodml id generation rules. In these cases, the semantic concept should be chosen over enumeration. In others, the vocabulary itself may not be important ( eg: "QSO" vs "quasar" ), the significant thing is the concept.<br></div><div><br></div><div><br></div><div>CAOM case:<br></div><div> There is one detail about the CAOM case which I am not sure is significant or not.<br></div><div> Pat.. maybe you can clarify?<br></div><div> In the CAOM model, CalibrationLevel is represented by an integer.<br></div><div> Is there something specific about the integer nature which is an issue? or is it just that the string representation of a number is not a valid vo-dml id and therefore cannot be used as the enumeration literal name?<br><br></div><div>Mark<br><br></div></div></div>