SSA-1.1

[Petr Skoda]

>
> Unless there is something left to discuss, I want to move SSA-1.1 to RFC at
> the end of this week (2011-04-15).

I am extremely sorry for bothering again so late with the SSA changes, but 
this one (I hope) cannot break any working service but might improve the 
handling of VO archives by astronomers:

I have realized the problem two days ago when trying to make 
SSA-compatible archive of one set of 2m telescope spectra (with max 
magnitude available say 13m) and no I am pretty sure its 
important to hint the spectra providers and give them proper rules how to 
implement this.

The problems concerns the SSA TARGETNAME query vs POS.
When an astronomer looks for spectra of some target, he uses VOSPEC or 
SPLAT-VO and in fact the vast majority of SSA services supports only POS 
query. So the usual expectation is - you call name resolver to get 
coordinates and make the POS query.

But, even in our relatively bright stars spectra archive there are stars 
that are not recognized by any resolver (eg most GALEX stars, stars with 
KEPLER names etc ...) or people are using different nomenclature
(e.g. GALEX J193156.8+011745)

Those come from special catalogues and the astronomer has only solution to 
look up the coordinates in given catalog, convert to ICRS decimal degrees 
and enter in POS field in given tool.

In addition (as I was showing several times at interops) there are cases 
(e.g. in binary star research) when you cannot use the coordinates to 
distinguish the particular spectrum (e.g. component of close spectroscopic 
binary - e.g HR1847A and HR1847B. The components are very close and have 
the same pointing in FITS header, but during the spectrum extraction 
(position on the slit) you get either spectrum of A or B component.
Of course there not in SIMBAD distinguished.

So for this purpose we have the TARGETNAME query (not only solar system 
databse needs it).
So I can ask for TARGETNAME=HR1847B or TARGETNAME=GALEXxxxx+yyyyy or 
IRASxx+yy  etc ...

But it could help a lot to have a explicitely defined way how to define 
the names for TARGETNAME that all servers would support (and I would be 
very glad to see the status of TARGETNAME in 4.1.2 to be changed to REC 
(from OPT).

To get anything if blindly asking the unknown archive a some kind of 
wildcard or regular pattern is important.

Probably the esiest way would be to refer to SIMBAD resolver wildcards
http://simbad.u-strasbg.fr/simbad/sim-fid
following the unix filename patterns  but I am not sure about the problems 
in http URL encoding.

Some web based (not SSA) archives are using SQL wildcards % 
or _  for the LIKE operator and it is directly translated to database 
query.

So I suggest to extend the sec  4.1.2.8 TARGETNAME by adding the sentence:
----------------------------------------------
The TARGETNAME parameter may contain the wildcards according to the
XXXXXXXXXXXXX convention (for example .......) which the server should 
translate to the appropriate call to database.
-----------------------------------------------
There should be explicitly said XXXXX = SIMBAD resolver or XXXXX=SQL
and we should clarify if the parameter value is case sensitive or not and 
how the white spaces are understood.

e.g.  "Theta 2 TAU" or V475cYg"  and if the [abc]something is supported

I hope that this issue could be solved quickly refering to some already 
existing handling of patterns ....

probably some kind of limits like MAXREC will have to be applied according 
to server's internal setting

and what is your opinion about making TARGETNAME  a REComended parameter ?
I suppose that most spectra metadata are converted from FITS headers and 
it was a good practice in observation to give every object  a name.


*************************************************************************
*  Petr Skoda                         Phone : +420-323-649201, ext. 361 *
*  Stellar Department                         +420-323-620361           *
*  Astronomical Institute AS CR       Fax   : +420-323-620250           *
*  251 65 Ondrejov                    e-mail: skoda at sunstel.asu.cas.cz  *
*  Czech Republic                                                       *
*************************************************************************