[vo-dml] - Enumeration Literal redux

[Patrick Dowler]

Since the interop, I have done some work and run into some other
things that helped me think about the boundaries some more.

First, in the latest version of CAOM we converted a few things from
Enumeration to Vocabulary so they would be extensible. CAOM does
provide a core vocabulary but now new terms can be used as well.
Although we provide a set of constant declarations for the core
vocabulary in code that is both source- and serialisation-compatible,
the values do not appear in the model at all and here I would not
expect it. I still have to write the vocabulary doc but it is clearly
an external entity.

The second thing was a discussion about where to document the units
for various numeric values in the model. Here I found myself reluctant
to specify units in the description field of the VO-DML document
(although there may be some in there from porting the docs from a
previous form) and I've come to the conclusion that I need to define
some sort of  "profile" for the model that specifies all the units.
That would allow (but more importantly clarify that it was ok) to
re-use with a different profile.

So, I guess now I see enumerations, vocabularies, and unit-profiles
along a spectrum of "tightly coupled to the model". Units and
vocabularies are more clearly outside the model and I no longer see a
compelling reason to draw a line between them and enumerations.

TL;DR - I am fine with not adding enumeration literals to VO-DML and
leaving it to the serialisation spec.

Pat

PS - CalibrationLevel is serialised as an integer for compatibility
with ObsCore calib_level; to do it the right way would be moving the
integer values to the serialisation. The ObsCore standard defines both
(a view on) a data model and a serialisation (database persistence).

On 26 May 2017 at 08:59, CresitelloDittmar, Mark
<mdittmar at cfa.harvard.edu> wrote:
> 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
>



-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada