SSA-1.1

[Francois Ochsenbein (ext.52429)]

>
>>
>> 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 ;-)
>
>OK
>
>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
>A-Z.
>
>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
=======================================================================