SSAP clients for theoretical spectra

[Miguel Cerviño]

Hi,

The problem, from the theory point of view and the registry, is not  
only related with  theory-SSAP services: There are other theoretical  
results that can be access now with the
"format=metadata" approach like isochrones, evolutinary tracks or  
photoionization models
results that does not fit directly with an spectra (and neither with  
SSAP).

I agree that if the final result of a model a spectra, it should be  
follow the SSAP recomendations and de DataModel representation for  
spectra. But in the general case the theoretical result is not only a  
single spectra, but also its different components that can also be  
represented as a spectra  (e.j. the contrubition of different stellar  
populations in synthesis model case, or the incident, tranmited and  
absorbed continuum in photoionization model case). I agree in use
SSAP for the access of each one of this componets, but I also think  
that it would be better to
register theoretical services in general (i.e. something that say to  
applications that the query should be format=metadata or something  
like that) PLUS something that says with other protocols accept the  
service (SSAP + TAP + whatever). Otherwise we will have an access to  
theoretical spectral ok, but we will repeat the same discussion for  
every other type of theoretical result...

Summing up. From my point of view the issue of register theoretical  
models is:

1) Make sure that the FIRST query to the service will be a  
format=metadata (or getCapabilities like query)
2) Specify which other protocols the service provide (AFTER the  
format=metadata query has been done)

In this schema, applications that are able to work with tables other  
than spectra (e.g. TopCat) can retrieve theoretical data (e.j.  
isochrones) because only will need the format=metadata part of the  
protocol, which is in fact completely independent on the final  
product (spectra or other kind of table).

cheers

	Miguel


El 12/10/2007, a las 17:09, Doug Tody escribió:

> On Thu, 11 Oct 2007, Carlos Rodrigo Blanco wrote:
>
>> - At a registry level the only way to register these services is a  
>> SSAP
>> services. This mean that applications will query the services by
>> position/object name and the services will never ask annything  
>> useful. There's
>> no way to register them as TSAP, meaning that, even though the  
>> service
>> conformes with SSAP specification, it does not answers to position  
>> queries and
>> it needs a previous format=metadata query for finding the query  
>> parameters.
>>
>> I thing that this lack of a proper way to register theoretical  
>> spectra
>> services is very important. It makes these services almost  
>> invisible to the
>> applications (as they wouldn't know how to find which ones are  
>> available). And
>> maybe that is the reason why most application developers haven't  
>> felt the need
>> to implement a way to access theoretical spectra services.
>
> I agree that searching the registry for theory-SSAP serices is a
> problem currently, but we should be able to address this in SSA
> V1.1 once we have getCapabilities.  Then it should be possible to
> search the registry for SSA services for which DataSource="theory"
> (or something along those lines).
>
> The client apps do need to get smarter in terms of queries, so that
> queries can specify any parameter and not be limited to position.   
> I am
> sure that this will happen (I know some folks are already looking at
> this), however you need to give them time.  SSA only recently became
> a REC.
>
> I am not sure I understand the comments earlier about using TAP to
> access a service which returns synthetic spectra.  A theory-SSA  
> service
> returns spectra and requires passing in custom parameters to define  
> the
> model parameters, for which SSA would seem to be a much better choice.
>
> 	- Doug