SSAP clients for theoretical spectra

[Doug Tody]

Hi Miguel -

The key thing here is what is the data which is returned.  If it is
some well-defined type such as a spectrum or image, it would be best
to use an interface like SSA or SIA.  If you have multiple components
which can be represented as spectra, then you can use SSA, adding an
Association to associate the component spectra which are available.
If you are returning more general theory data as a simple table then
possibly that could be done with TAP if the parameter interface were
general enough to permit extension (it is an interesting suggestion),
but this might also be getting into the realm of what has been called
SNAP, for real theory data.

	- Doug


On Fri, 12 Oct 2007, Miguel Cerviño wrote:

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