Hi all,
> About the proposed approaches I have some comments from the experience
> of this previous years :)
>
> a) Theoretical data have the property of expands themselves exponentially. It
> means,
Yes, in fact every data expand quicky - you can eiher use faster computer
to allow 3D simulation or build a larger CCD mosaic ;-)
> results and it would saturate the mind of any user... of course it is a
> problem of the implementation of the service, but I still think that a proper
of course - I just tried to find an instant solution how to compare
spectra with simulations just now in current clients. It was not meant for
long-term support : I just considered situation like this use case:
"I have buch of files on my PC and will be happy to donate them to VO,
with some effort put together something like SAADA or DAL toolkit and will
consume it in SPLAT or SpecView (os VOSpec). I know how models are named
and will tell to anybody interested in some URL link provided in
provenance)". Of course, once TSAP is supported fully, will replace my
service (and in the meantime add more parametrs to my simulation...)
>
> b) It is not true that theoretical spectra will mainly use temperature,
> gravity and metallicity. It only applies to the stellar atmosphere case. But
> even a single temperature does not works for models of rotating stellar
> atmospheres.
Of course, as a theoretician I see the buch of problems in consisteny of
models, wind, convection .....
But what I have seen at many conferences (about hot stars, I am biased to
this), people just blindly take Kurucz models a manualy fit one after
another (or better compute chi square match) as a first estimate of
stellar parameters.
Even more, there are also synthesis models (with parameters like
> age, mass function, star formation history), spectra from photoionization
> models (with geometrical properties of the stars and gas) etc...
Sure - its a different use case, I used to compute envelopes of planetary
nebulae many years ago and again my models vere named as a mnemonic string
with parameters like Ne, Teff, W (dillution).
> In this case it is quite difficult to define a "typical theoretical"
> parameters,
Sure - it is not VO approach - I just were thinkink about names of different "theoretical stars" to compare with (knowing what they are)
> specific one for the analysis of stelar populations in galaxies or for the
> study of particular star). Again, a proper TSAP implementation looks to be a
> better option ;)
Of course - the question is when it is available.
> b) To be able to look for "format=metadata services" in the registry (and,
> for SSA clients look also for SSA).
Yes this is correct way - we can hardly decide now what other kind of models may be computed (eg. typical size of instabilities in stellar wind as a function of its composition ..)
>
> Of course, it will "depreciated" when getCapabilities in TAP will be ready,
> but at least it allow to access a more variety of data and, any case,
> applications that potencially will use TAP (even for an ADQL search of
> observec spectra)
Yes - fully agree
> and, in my case, also clients that use for a format=metadata access for other
> theoretical (and not theoretical) services ;)
I think it is better to push the developers of existing VO clients than to develop new ones - perhaps the VO-metalayer as in vo-iraf might be flexible enough (something like vo-splot or vo-spectool ;-)
To summarize: - I fully support metadata query to be implemented as you described - my TARGETNAME solution was a just quick hack how to start providing models and to CONSUME them immediately.
Best regards,
Petr