[vo-dml] - Enumeration Literal redux

[CresitelloDittmar, Mark]

On the topic of Enumeration Literals in VO-DML which came up in the recent
interop.

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.

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.

Enumeration Literals
  - twiki post by PD: 5/17/2017

"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"

Previous discussion on DM mail list:
   [vodml] EnumLiterals and vodml-id: 01/2016
     http://mail.ivoa.net/pipermail/dm/2016-January/005297.html
     + very lengthy discussion on the subject
     + was topic covered in face-to-face focus meeting Feb 2016
     + closing summary 02/19/16
        http://mail.ivoa.net/pipermail/dm/2016-February/005335.html

Basic summary:
  + vo-dml spec does not address serialization at all, it identifies
concepts
  + the 'actual value' string representation is implementation dependent,
and therefore on the Mapping side
  + 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.
  + alternatively, users can 'convert' the local value to match the vo-dml
model concept name, removing the need for OptionMapping
  + 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.

Enumeration Literal vs Semantic Concept
  + related to this thread, is when it is appropriate to use enumerations
vs semantic concepts.. the basic rule has been
     Enumeration if:
       1) if the set is small
       2) set is stable.. unlikely to change

   + I would add a third rule to this list (if it isn't already)
      3) the vocabulary itself is not significant

      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.


CAOM case:
   There is one detail about the CAOM case which I am not sure is
significant or not.
   Pat.. maybe you can clarify?
   In the CAOM model, CalibrationLevel is represented by an integer.
   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?

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20170526/dcd945c0/attachment.html>