[vodml] EnumLiterals and vodml-id

gerard.lemson at gmail.com gerard.lemson at gmail.com
Tue Jan 12 17:32:30 CET 2016


Hi Mark
> 
> Gerard.. this was your own suggestion :)
> 
Yes, but I also mentioned my preferred alternative, which is leaving things as they are *including* the constraint on the EnumLiteral names.

> 
> I'm not sure Marcus was voting against having a label as much as not sure where
> it would be used.  The pattern of having an enumeration literal with a code and
> label seems pretty common and fits what we are talking about.  The description
> field is not appropriate as that is more than just an alternate representation of
> the enum literal name.
> 
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.
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. 
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.
So if you think that we need human readable values, do you propose the same for Type names? And why would that be useful?
And if you think we need human readable titles/labels, why for example is simple CamelCase not good enough?

> 
> For example, the SpectralBandType  (again)
> 
>     name    label          description
> 
>    OPTICAL  Optical      "0.3 microns <= wavelength <= 1 micron"
> 
>    UV       UltraViolet  "100 Angstrom <= wavelength <= 3000 Angstrom"
> 
>    XRAY     X-ray        "0.1 Angstrom <= wavelength <= 100 Angstrom"
> 
> 
> satisfies everyone's needs, so seems like a very reasonable approach.
> 
Are you saying that

    name    description
   Optical      "0.3 microns <= wavelength <= 1 micron"
   UltraViolet  "100 Angstrom <= wavelength <= 3000 Angstrom"
   XRay        "0.1 Angstrom <= wavelength <= 100 Angstrom"

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. 

> 
> Remember that this exercise is not just to write models conforming to VO-DML,
> but also to exercise VO-DML and its ability to serve the modeling.
> 
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.
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.
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.

Cheers

Gerard

> 
> Mark
> 
> 
> 
> On Mon, Jan 11, 2016 at 5:34 PM, <gerard.lemson at gmail.com
> <mailto:gerard.lemson at gmail.com> > wrote:
> 
> 
> 	HI Mark
> 
> 	> -----Original Message-----
> 
> 
> 	I agree with Markus' opinion, which was also my favorite, that we do
> not need a human readable label|title|fullName. The 'description' attribute can
> take care of the explanation. The name is the one to be used in the
> computational context where one may wish to use the data model. To me the
> fact that other standards did not use this is not so important as those were not
> written in VO-DML.
> 
> 




More information about the dm mailing list