SSAP clients for theoretical spectra
mcs at iaa.es
Mon Oct 15 00:58:47 PDT 2007
> 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 think that the key point is that there are theoretical spectra
services, but most apps (all expecting VOSpec) that provide SSAP
access does not access it. So, there is a very high risk to lost
these brach of theoretical astronomy in the VO, and, hence, the
development of proper analysis tools (i.e. to be able to evaluate if
the scientific result is a model independent robust result).
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.
> 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
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...
More information about the registry