[vodml] EnumLiterals and vodml-id

CresitelloDittmar, Mark mdittmar at cfa.harvard.edu
Wed Jan 13 23:49:06 CET 2016


All,

chair hat on:
  I've certainly been the most vocal on this topic.. but don't want to gum
up the works.  I'm going to summarize my position here, then step back a
bit.  I suggest we give the topic a week or so for other
opinions/discussion to take place, then select a course of action (say ~
1/22 or 1/29) so Gerard can make whichever adjustments need to be made.

chair hat off:
> Mark, Arnold, any problems simply making the 'name' of the enumliterals
conform to these rules?

Basically yes, I don't think this is what we want.

This option means that all vo-dml compliant models must only use
EnumerationLiterals which conform to the vodml-id pattern '[a-zA-Z_][\w_]*'.
Since the value is directly tied to the definition of the
EnumerationLiteral, these are the values which data providers MUST give
when representing these literals.

Generally this is not an issue since enumerations are typically a simple
value set, but in the DatsetMetadata model, we already have 4 examples
which violate this pattern.
   SpectralBand:
     "X-ray"
     "Gamma-ray"

   CreationType:
     "catalog extraction"
     "spectral extraction"

I really can't speculate what things might be enumerated in future models,
but some examples of things which would not pass this pattern test:
  + anything with multiple words
        o CreationType above
        o Country:  "Papua New Guinea"
        o Institute: "Centre de Données astronomiques de Strasbourg"
        o StellarClass: "Brown Dwarf", "Red Giant", "Neutron Star", "X-ray
Binary Star"

  + anything containing '.' or '-' or non-word character, or starting with
a number
       o see SpectralBand above
       o Quasar: "SDSS J1004+4112", "QSO B1359+154", "3C 273",  "PKS
0637-752"

Again, I'm not suggesting any of these would be enumerated, only giving the
flavor.
All of these would be valid EnumerationLiterals in standard UML, but not be
compliant vodml EnumLiteral-s.
They would need to be converted to a vodml compliant form:
  + using CamelCase
        "XRay", "CatalogExtraction", "PapuaNewGuinea",
"CentreDeDonneesAstronomiquesDeStrasboug", etc

  + others more tricky
        "SDSS_J1004p4112", "PKS_0637d752"

  + not sure what we'd do with a numeric.. perhaps just a sequence ["A",
"B".. ]

Whatever the mechanism, most of these would still understandable as far as
the tag goes.
My concern is that since EnumerationLiterals are unique in that the value
is directly tied to the
literal, these are the values data providers would have to give in query
responses, and data products
when referencing these literals.  I don't think that is good.

The second option proposed would
  + allow the definition of a vodml pattern compliant name
  + and associate it with the real-world literal value
(lable|title|fullName)

Which I think is better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20160113/2086303b/attachment.html>


More information about the dm mailing list