SSA-1.1

[Douglas Tody]

Hi Petr -

TARGETNAME is an important feature for some new things we want to do
(e.g. SEDs), however it is not needed for the usual spectrum searches
and is rarely implemented by services.  We also need more experience 
to learn how to use this effectively so I don't see this as an issue
which needs to hold up SSA 1.1.  I don't know of any existing services
which it would affect.

What we are finding for SEDs is that TARGETNAME wants to be mandatory
as name resolution has usually already been performed for SEDs since
they combine data from multiple observations, often of well known
sources, and searches for SEDs are normally performed by object name.
Hence this will give us an opportunity to gain more experience with use
of this parameter for non-planetary data.  (This is one example
BTW of how SEDs and SSA/spectrum can differ).

Rather than make SSA more complicated than it is I think we should gain
some more experience with SEDs and time series as compared to spectra,
to see what features/capabilities are most important for each class of
data, closely related as they may be.

 	- Doug


On Mon, 18 Apr 2011, Petr Skoda wrote:

>> 
>> 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                                                       *
> *************************************************************************
>