SSAP clients for theoretical spectra

[Gerard]

Hi

> > The key thing here is what is the data which is returned.
> 
>  From this point of view, considering what is returned *at the very
> end*, I completely agree with you, but the point raised by Carlos,
> Ulrike and myself is not only about the very final data returned, but
> about how to ask the data!
> Currently, it is not possible to access theoretical spectra excepting
> by VOSpec, but
> some applications are implementing "ad hoc" the theoretical spectra
> inside them because
> they need it for analysis (e.j. specview).

I believe that also VOSpec did not deal correctly with our SSA service,
until some extra custom work was performed (correct Ulrike?). After all, we
are not a TSAP service and actually as far as I'm aware TSAP is not a
standard. In all the recent interop meetings it was claimed that theory
spectra could be handled using SSAP, hence that is what we implemented. The
format=metadata part of SSAP is assumed to be sufficient to find out which
parameters are supported. Is there anything in TSAP that is essentially
different from this?
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. So this discussion started not as a criticism
on client builders, far from it!

> I still think that if this services can be registered not only as
> SSAP but WITH another "keyword" that allows apps to know that the
> query is a "format=metadata" can solve part of the problem.
> Or, in other words, thinking about what is returned:
> 
> - a "standard" SSAP query returns an spectra
> - a "format=metadata" SSAP query returns a set of metadata that the
> user must select and,
>      *after that*, the service returns an spectra
> 
> So even at this level, what is returned *first* by the service is
> different, although the very final result (an spectra obtained in 1
> or 2 steps) is the same.

The registry already allows one to enter metadata indicating that a service
contains simulation results. This might alert clients to the fact that a
positional query may not be appropriate (though Thomas Rauch has interesting
examples where a particular, identified star is being simulated and could be
given positions !).

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


> 
> > If you are returning more general theory data ....
> > ... this might also be getting into the realm of what has been called
> > SNAP, for real theory data.
> 
> About SNAP, it is not the case. SNAP is designed to access (and
> explore) theoretical
> databases that can be parametrised in N independent physical axes
> (e.j. N-body simulations)
> But it is not valid for other theoretical data like isochrones,
> tracks, star formation histories of galaxies etc...
> 
For the record, SNAP deals with simulation and post-processing results that
represent a volume of space time, not every possible set of N independent
physical axes.


Cheers

Gerard