[vodml] EnumLiterals and vodml-id

Mon Jan 18 20:35:47 CET 2016

Hi Laurent
> 
> The current discussion about EnumLiterals is somehow similar with this about
> multiplicity.
> The question is not to find a pattern on which VO-DML fails. It is quite robust
> and I'm pretty sure that a work around can always be found (DataTypes
> encapsulated in ObjectTypes, using a semantic instead to label the
> EnumLiterals...) .
> 
> What I am asking myself is to know why (a few) patterns ([0...n]) or labels (X-ray)
> widely used in our domain have been discarded from VO-DML.
> I did find a clear response in these long threads which are more focused on the
> "how to" than on the "why".
> 
Though clearly the issues are different in detail, you could indeed argue that there is a kind of "meta-motivation" behind both.
This is that restrictions in the language should help guide modelers in the direction of common design patterns, and, if you wish, best practices, and if you really wish "better models".
Fewer restrictions give modelers more rope to hang themselves. It provides the option to design similar model patterns in intrinsically different ways. Restriction should make it easier for modelers to use common patterns design by not allowing an alternative. It can help imposing such best practices more easily. What qualifies as a "best practice" can sometimes be derived from somewhat philosophical ideas (e.g. "promote explicitness") on what constitutes a good model in the context that VO-DML targets (data integration, annotation). But best practices may also be derived for example from simplifying faithful/1-1 mapping of the model to implementation contexts (see the Java enum example I discussed in my reply to you).

And I think I have at least tried explaining the "why" about EnumLiterals. The fact is, these are *not* semantic labels. They are the distinct instances/values in the Type defined by an Enumeration. VO-DML has explicit support for labels using the 'semanticconcept' attribute you can associate to Attribute definitions. 
See a longer discussion about this on the DM mailing list spawned by Markus some while back in which for a while he argued against support for Enumerations, positing that these should all be pointers to an appropriate semantic vocabulary. In the end we agreed that Enumerated types are different and useful enough to warrant a special supporting concept in VO-DML. One moreover that has ample support in other computational contexts (including the constraints). 

The issue with the cardinalities is that it often leads modelers to *not* model their domain correctly. E.g. modeling the list of 'authors' on a publication, or collaborators on a project/resource as a string array clearly ignores the actual concept, namely that these are roles played by real people. Even though the modelers know better, they cut some corner because they think it is sufficient for their use case. It is my observation from looking at *many* data models that almost invariably when users try to have an [0..*] multiplicity on an attribute, they are avoiding a proper model requiring a collection of object types. I have myself multiple times had to rewrite models where originally I thought I could get away with cutting some corner, but eventually found out that the full concept was needed anyway. And particularly where we don't yet know who will want to (re)use the model, it is best to be explicit all the time. VO-DML tries to promote that. 

And I believe that basically all the examples that I have seen being proposed so far corroborate the set of choices currently in place. Not just because "there is a work around" in VO-DML, but because that work around actually provides a better model in the context of annotation/data-integration/modelling-the-world.

Cheers

Gerard

>
> Cheers
> Laurent
> 
> 
> Le 15/01/2016 18:11, CresitelloDittmar, Mark a écrit :
> >
> >
> > On Fri, Jan 15, 2016 at 9:19 AM, Gerard Lemson <glemson1 at jhu.edu
> <mailto:glemson1 at jhu.edu>> wrote:
> >
> >     Hi Mark
> >
> >      >...
> >     >
> >     >       These models we are working (DatasetMetadata, STC2, etc) are
> working
> >     > to be vo-dml compliant to facilitate this path, but must also serve the
> present
> >     > and near-term, where we have model aware, but not vodml aware
> software.
> >     >
> >     I would be very interested to see examples of this Model aware software,
> for I think this has been sorely missing so far.
> >     Examples of software that "code against a model". I'm meeting with Tom
> today to talk about precisely that.
> >
> >
> > I would consider existing WCS software 'model aware' of the STC2 transform
> components.
> >
> >     >
> >     >       So, if I define vo-dml compliant enumeration in the DatasetMetadata
> model
> >     >          SpectralBand
> >     >             + Radio
> >     >             + XRay
> >     >
> >     >       what value would a data provider need to give in order for model
> >     > aware, but not vo-dml aware software to be able to instantiate the proper
> >     > literal instance on
> >     >
> >     >         myObject.band:SpectralBand[1]
> >
> >     This depends on the implementation of the model in the software,
> something VO-DML is silent about.
> >
> >
> > For the EnumLiteral, I'm not sure it can be.  The job of an Enumeration is to
> define a specific set of
> > values which are allowed, other values should be illegal.  For EnumLiteral, the
> value and the type are
> > intimately connected.
> >
> > A data provider can tag their products with the proper vodml-id for the
> matching EnumLiteral, but
> > their local value is not legal unless it matches the EnumLiteral name.  vo-dml
> aware software would
> > have the option of ignoring the local value and instantiating based on the
> vodml-id alone.
> >
> >     It also depends on what you mean by being "model aware".
> >     Even if the software aims to represent the model 1-1 there are still going to
> be implementation and language dependent
> >     choices that must be made.
> >
> >     Now I have XSLT that transforms a VO-DML model to POJO Java classes,
> though I have not kept it up-to-date with latest
> >     changes. There an Enumeration is mapped to a Java 'enum' and the
> EnumLiterals directly to the literals in the enum. I.e.
> >     similar to the example I sent yesterday in reply to Laurent's comments
> >     and the values to be used to set appropriately typed attributes would be
> these literals.
> >     But everyone is free to use their own implementation in principle.
> >
> >
> > Provider A implements the model and codes the SpectralBand.XRay literal to
> use the string "X-ray" because that is what their
> > products use.
> > Provider B implements the model and codes the SpectralBand.XRay literal to
> use the string "XRay" because they are new and doing
> > a 1-1 match with the model.
> >
> > Serializations from A will have string values "X-ray" with vodml-ids
> "ds:SpectralBand.XRay"
> > Serializations from B will have string values "XRay" with vodml-ids
> "ds:SpectralBand.XRay"
> >
> > When these are passed to a validator to test model compliance, won't A
> products generate an error because the value does not
> > match any literal?
> >
> >     I think the issue is mainly important if the software is to be interoperable
> with other resources. If messages need to be
> >     sent between them.
> >     Now it depends on the serialization that is chosen to represent instances of
> the data model. Annotated VOTable is one way to
> >     do so, and the only one we're currently explicitly working on. Software that
> makes particular choices for representing the
> >     model will have to be able to interact with such representations and in
> general will have to map from the annotated VOTable
> >     to its internal representation. This in fact is what Tom and I are trying to
> work on.
> >
> >
> > Well, interoperability certainly is a consideration, especially with existing
> software.
> >
> >
> >
> >
> 
> --
> jesuischarlie
> 
> Laurent Michel
> SSC XMM-Newton
> Tél : +33 (0)3 68 85 24 37
> Fax : +33 (0)3 )3 68 85 24 32
> laurent.michel at astro.unistra.fr <mailto:laurent.michel at astro.unistra.fr>
> Université de Strasbourg <http://www.unistra.fr>
> Observatoire Astronomique
> 11 Rue de l'Université
> F - 67200 Strasbourg
> http://amwdb.u-strasbg.fr/HighEnergy/spip.php?rubrique34