I had a bit of a puzzle trying to figure out what was wrong with "mu Ori" in VSX. I was looking for the greek letter mu Ori aka AUID 000-BBK-574. I kept finding the one with AUID 000-BDZ-142. I wonder if this is an isolated case? If not, perhaps the VSX query needs to be enhanced to warn the user of the ambiguity?
I'm pretty sure VSX has adopted the CDS-SIMBAD scheme for the Greek letters in ascii Roman alphabets, whereby a period (or decimal point if you like) is added. Thus Greek mu Cep ---> mu.Cep, which I just confirmed works in the AAVSO VSX page (as well as the CDS VizieR version, item b/vsx, and certainly in SIMBAD itself). So also: pi ---> pi., nu ---> nu., etc. A partial alternative is to adopt 'miu', niu', etc, but that doesn't cover all the cases. Basically, the CDS scheme makes all the Greek letters three characters, which may be the easiest may to remember it. Of course, this scheme allows MU Cep and other variable-star designations to be handled gracefully given the organic nature of how things developed.
The problem arose because of the original computer-card version of the AID. All variable star names were in upper case, so MU and mu Cep look identical. Even today, you can look at any of these greek/GCVS pairs and see incorrectly assigned data.
I asked Samus/GCVS how they wanted to identify these stars, and he said they were using miu/khi/niu/etc. for the Greek letters, so that is what we selected. Then, sometime later, the CDS/Simbad decided to use mu./nu./etc. So in my mind, there is no standard. I don't like periods in variable star names personally - they are hard to see and get in the way of file naming.
I discussed with staff whether we could use some other standard (eg. UTF-8/Unicode) so that we could store Greek letters in the AID, but we didn't make any changes, mostly because there was no agreement on what WebObs would accept - many keyboards and computers were not capable of producing Greek letters.
I think a better solution could be found today, but it would be nice for it to be a standardized solution.
Although it is not an ideal solution, I would adopt the CDS scheme simply cuz they are the ones that dominate the biblio etc set-up in the literature in terms of assigning acronyms and so on. I'm sure there was a discussion long ago amongst ADS, NED, and CDS folks about how to deal with this circumstance, so it wasn't just an arbitrary decision.
In any case, not all the aliases are in VSX: Greek lettered nu (or nu.) Ori doesn't show up since that variable star is given only the name HIP 29038 in VSX; NU Ori of course is fine. To me this argues for not using VSX from the AAVSO site, but instead from the CDS VizieR, where all the aliases are linked under a single heading (or nearly always now). The VizieR output has a direct link to the VSX page at aavso.org, plus there's access to a lot more information through the myriad other catalogues in VizieR.
Hi Brian et al.,
I have updated nu. Ori in VSX, both in terms of variability (amazing TESS data to the rescue!) and aliases.
You are right regarding VSX and completeness when it comes to cross-identifications. However, the lack of aliases for such bright stars is not a common thing, it happens in cases like this when the star was taken from a specific paper that did not provide the most common names. This one was one of the Hipparcos variables published in 2002MNRAS.331...45K.
But yes, there will be more cases like this.