Francois Ochsenbein (ext.52429)
francois at cdsarc.u-strasbg.fr
Fri Apr 29 02:36:13 PDT 2011
>> like Myron, I think that is a usually a bad idea.
>OK I am giving up - - to solve the problem on which are several
>groups of people in IAU working for years is impossible by simple rules;-)
>I wanted to make easier the practical usage of TARGETNAME to motivate
>people by finding in cca 80% what they wanted (but as I remember in IVOA
>there was mentioned many times the 80-20 rule to explain why one should
>not deal with details - usual answer was we should have something to start
>with) - but evidently this is not accepted here as too many people want
>to be exact and recommend either complicate rules (full RE and escaping)
>or to be strict and forbid every possible amiguity ;-)
>Now we even have learned that SIMBAD is doing this in a wrong way ;-)
>I am glad that there are some people supporting my original idea that the
>TARGETNAME is sometimes important and there is definitely the need (and
>will appear for sure in future again) to prepare some formalism for such
>type of queries. However, it is not yet the right time to recommend
>anything until we get more experience .....
>Unfortunately as Markus wants...
>>IMHO that should be: "There are no metacharacters in
>>TARGETNAME. Clients should not assume any case folding or
>>whitespace normalization on the server side. Servers are free to
>>perform case folding and/or whitespace normalization."
>But maybe I have understood this in a wrong way -
>perhaps it does not mean "There is not allowed any metacharacter in
>TARGETNAME parameter (in queries)" - otherwise adding this to SSA would
>break already (well) running SSA of MAST and others who support some
>wildcards in TARGETNAME queries silently...
>The practical way of using the query by identifier in web archives and
>SIMBAD (I have observed both my colleagues and many students) is very
>similar to the layman's usage of google - to write part of the name
>and if it returns to much adding more constrains. In best case someone
>tries the asterisk as is in unix filenames.
>So what to do ?
>As I understand all objections to case-insensitive search of star names
>follows from the problem introduced by Johann Bayer in 1603 - i.e. after
>exhhausting greek letters he decided to use low case a-z and then upcase
>So this is a critical ambiguity as is shown below: by B.deBatz
>In this case it would be the solution such a rule:
>"Ignore the case UNTIL there is a single letter "
>Other problems like ambiguity in writing constellation name
>or greek letter (even shortened to 3 letters as in Simbad - Alp, alp..aLp)
>or variable stars like RS, rs, v355, V355 ... could be solved (I hope)
>by simple ignoring of case.
>Or does anybody has another example of ambiguity except of Bayer names ?
>Concerning argument "the * is part of many names"
>I think that probably no one uses * as part of name - it is just a
>formalism introduced by SIMBAD (after GCVS) as a class marker on output
>Does anyone have TARGETNAME with * ?
==> Oh yes, Sgr A* being the most cited one...
>Of course the TARGETNAME entered in SQL databases during the process of
>making them VO-compliant should be first converted to some canonical name
>(and we should give rules for this), but even then some wildcards will be
>needed just to asume the type of contents (do they have any GALEX object
>observed ? .. TARGETNAME=GALEX*.)
>> If you ask with identifier "z Pub" (a Be star B3Vne) Simbad answers with
>> V* Z Pup (a Mira type star M4e)
>Thanks for numerous suggestions and commnents
Francois Ochsenbein ------ Observatoire Astronomique de Strasbourg
11, rue de l'Universite 67000 STRASBOURG Phone: +33-(0)368 85 24 29
Email: francois at astro.u-strasbg.fr (France) Fax: +33-(0)368 85 24 17
More information about the dal