SSAP clients for theoretical spectra

[Petr Skoda]

Hi all,

I think that the problem is not only with the theoretical spectra but the
real spectra as well.

The problem I see is the POS - SSAP standard says that the POS is 
mandatory and should select something if asked (that means nothing for 
theoretical data) or the service returns everything if not POS given in 
query and other parameters should be used to constrain the query (SSAP 
chapter 4.1 last paragraph and 4.1.1)

The interesting parameter is the TARGETNAME (4.1.2.8) :
the original intention is for asteroids and similar objects:
it is said that for service providing spectra of moving objects the 
TARGETNAME is required.

As far as I have seen the results of synthetic spectra codes, people 
usually name the output spectrum as a joined string of used parameters
Temperature, logg, rotational broadening , or electron density, radiation 
dillution ... , radiation temperature ... for planetary nebulae ...
plus some chemical composition if not solar .

of course the metadata is required to tell everything about given model,
but I think the 90% of queries in any research  go to Kurucz models
named just 10xlogg+Teff   and some additional letter for different 
metalicity.

So I can imagine the situation where different models will be named by 
unique name expressing that parameters and the SSA query could use the 
TARGETNAME to query them directly without metadata. This will aloow 
already working SSA clients to overplot the theoretical spectra over 
observed immediately.

the question is what POS value should be returned for such a services 
that are "positionless".  In ancient times were the unusable values marked 
by series of 9   (e.g. 99999)  -
so we could have some unphysical position  like -1,-1 or 999,999 to 
return.

of course, it does not solve the problem of TSAP - I have to known how the 
service name his "hypothetical stars" - but it can given e.g. in 
provenance. But its a way how to start publishing of calculated spectra 
JUST NOW to allow some analysis already done with VO tools than to wait 
for new TSAP compatible clients ...

The problem I see for regular spectra - even for stars is that POS vs. 
TARGETNAME - We already have met several times the situation where the 
query by position is misleading and the identification of the star must be 
done by its name.

E.g. the cordinates returned by telescope to the data FITS header are not 
precise enough (flexures of tube, errors in encoders, axis flexures ... 
-all the stuff thta TPOINT tries to correct) to be able to distinquish 
components of close binary on slit (only the spectrum will tell which is 
which), or the Simbad resolver makes troubles as the data in simbad are 
wrong (we have met e.g mess in description of HR1847 in literature and 
SIMBAD, as the component A and B according to description of spectra seem 
to be swapped with respect to position, but its difficult to tell that for 
sure, as both spectra are changing.....)

I just wanted point out that the position is not justifying unique 
identificator even for distant objects. Another example is the Sirius
(there is a spectrum of Sirius B and A - how do you use position in 
searching the archives ?  (in Simbad is Sirius B: ICRS: 101.287 -16.718
while Sirius A ICRS is: 101.2871554 -16.7161158 - notice the precission 
difference !)

So to summarize: the TARGETNAME is a good way of querying not only 
theoretical spectra and asteroids but normal stars as well and should 
be supported if needed by the services .

(The only problem is last sentence of 4.1.2.8 : "if both TARGETNAME and 
POS are specified, both must satisfy the query for a candidate object to be 
matched" - what positions should be given in my spectra of Sirius to 
satisfy the resolver in Simbad ?
)



> The problem is I think that clients are in general not yet able to use this
> information.

>I talked with Mark Allen about this somewhat over a week ago
> and he suggested we post this question to the mailing lists to alert client
> builders about this problem.

Yes - the query by TARGETNAME and METADATA should be implemented 
definetely in new client versions.



> examples where a particular, identified star is being simulated and could be
> given positions !).

I agree - but is the computed spectrum of Vega the real star to bear the 
coordinates ? I would preffer to named this spectrum Vega_synth1 and query 
by its name .


> In the end every SSA service should respond to format=metadata with the
> parameters they support and clients should (eventually) make use of this
> information to at least not send positional queries to services that do not
> support them,
or if it gets strange POS from service (e.g. 999,999) stop using POS and 
use information returned in different way.


and once all metadata is there (getCapabilities will hopefully
> use the requirements form this discussion)

>GUIs can be generated that
> capture also more generic queries.

perfect - on the fly generation of menus with prelisted values of 
parameters is better than blindly hit the right parameters ranges
(instead of asking the Teff and try 3000, no hit, 5550 - no hit...
I will see in the (on-the-fly generated) menu that the Teff is only for 
25000, 30000 and 40000 .....) on this service for hot stars ;-)


Anyway the full metadata (getcapability) issue should be solved ASAP.



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