[vodml] EnumLiterals and vodml-id
Observatoire
laurent.michel at astro.unistra.fr
Thu Jan 14 15:56:49 CET 2016
Hi
I'm travelling up to Monday
Laurent
Chuss/Salut/Bye from my IThing
Laurent
> Le 14 janv. 2016 à 14:50, Gerard Lemson <glemson1 at jhu.edu> a écrit :
>
> HI Laurent
>>
>> I'm always a bit puzzled with what is VODML done for or not.
>> So let's keep away from the VODML machinery and move back to the point of
>> view of a VO-DML naive user, I mean not a list subscriber.
> Could you explain what a naïve VO-DML user is supposed to be? We have used the phrase "naïve" as characterizing a particular type of software clients of the VOTable mapping specification, are you referring to those?
> Otherwise, Naïve persons, in the sense that they do not need to understand VO-DML for example, should not be allowed to perform data modelling efforts in the IVOA. No one naïve should think they can perform annotation of data sets with VO-DML. I would argue this is no different from any other IVOA effort. People need to follow the standards to create resources that implement them, be they protocols, or data formats or data models. And they should better understand the standards if they want to use these implementations, be it directly, or by writing a client that allows other people a simple(r) interface to them.
>
> In any case, VO-DML is a language for writing data models in the IVOA and in particular is tailored for use in annotations to support data integration between (generally) preexisting data sources. Primarily for annotating VOTables and through these also of FITS tables and TAP schemas for example. Especially the latter case is very promising. We anticipate that people may want to implement features of the model directly, e.g. by mapping faithfully, 1-1 to some OO language, e.g. Java. That is *not* its main use case, but we take the possibility into account. Similarly we try to accommodate possible representation in relational databases, use of identifiers (vodml-ref-s, formerly utypes) in hyperlinks, or more generally pointers, as well as use in query languages.
>
>
>
>
>> If a model states that an attribute must take its value among an enumeration,
>> then items of that enumeration must refer of the modelled domain as any other
>> attribute value. They must not refer to the meta model used by the tool.
>> How can my modeller understand that he is allowed to state
>>
>> object.Mission = "XMM-Newton"
>>
>> But that at the same time, he is not allowed to state that
>>
>> object.Band = "X-ray"
>>
>> just because the Band field is an enumeration.
> First, your example seem to me to be serialization examples, *not* modelling examples.
> But your main argument seems to be that it may be confusing that one can do one thing in one context, but must do something else in another context.
> I don't think this is strange at all and caused simply by the fact that VO-DML is a strongly types language.
> For example in Java you have a completely analogous situation.
> There one may define for example:
>
> public enum Band {
> xray, optical, radio;
> }
> (Note that the literals conform to certain syntax rules, for example x-ray is not allowed.)
>
> I can define a class
> public class UseBand {
> private Band band;
> private String otherBand;
> }
> In some declaration you might wish to define:
>
> UseBand object = new UseBand();
> object.band=Band.xray;
> object.otherBand = "Rolling Stones";
>
> but
> object.band = "xray"
> would be illegal as UseBand.band is of type Band, not of type String.
> That's all.
>
> Yes, I could use
> object.band=Band.valueOf("xray");
>
> And yes, I could complicate my code further with special string values used to refer to these (say as in the second reply in http://stackoverflow.com/questions/604424/convert-a-string-to-an-enum-in-java). But the literal represented by the value is still of type Band, not of type String.
>
> Now, if you could decide *not* to predefine (in the model) a set of (photometry) bands using an enumeration, but would define object.Band as a (ivoa:s)string, you can use "X-Ray". This of course is less restrictive, and so you might desire to assign a <<semanticconcept>> to the attribute that would restrict values to those defined in some vocabulary of bands.
>
> OR you might wish to reuse the Photometry data model where PhotometryBand is defined as an Object Type and would define a reference for band iso an attribute.
>
> Plenty of options, that in my opinion are actually more suitable in the IVOA, data integration context which VO-DML is supposed to support.
>
> Cheers
>
> Gerard
>
>
>
>> I understand well the motivation for this in VO-DML, but to me that is rather a
>> lack in the system than an intuitive feature.
>
>
>> Cheers
>> Laurent
>>
>>
>> Le 12/01/2016 17:32, gerard.lemson at gmail.com a écrit :
>>> 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.
>>
>> --
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20160114/cf9ad86c/attachment-0001.html>
More information about the dm
mailing list