SSAP clients for theoretical spectra
Miguel Cerviño
mcs at iaa.es
Fri Oct 12 12:36:23 PDT 2007
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
More information about the registry
mailing list