Re: SSAP clients for theoretical spectra

Hi Ulrike, Petr and the others :)

> That was exactly what I had in mind, when I posted my suggestions
> about
> theoretical SSA to the mailing lists: encourage all client
> developers to
> support more generic queries. I agree with Gerard in that it is not a
> problem of the protocol specification.

Yes, I completely agree :)
Indeed there are theoretical spectral services since 2005, but the TSAP appendix in SSAP
is just from this year, so ... Regarding VOSpec, it has been the only available tool during this time able to prove the concept of "access theoretical models". Some of its peculiarities (like the private TSAP list) was the only operative way (until now) to use a register-like repository of theoretical data. VOSpec has been the only way to reach this interesting discussion ;)

About the proposed approaches I have some comments from the experience of this previous years :)

1. Theoretical data have the property of expands themselves exponentially. It means, the only limit of a theoretical database is the disk/memory space, since you can change the sampling of any of the parameters of a model (e.g. a more detailed grid in metallicity or log g or Teff for atmosphere models or the age sampling for evolutionary models etc...)

In an operative point of view, the use of the TARGETNAME would easily produce too many
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 TSAP implementation makes a more better job ;)

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. 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... In this case it is quite difficult to define a "typical theoretical" parameters,
and, as far as I know, there are services that provides atmosphere models and synthesis models ready, so any solution must cover, at least, this two kinds of models (or this two kinds of parameter spaces).

So, I do not think that clients should provide any "ad hoc" query since it will lost other theoretical spectra (unless the application will be a very 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 ;)

---

Regarding any possible implementation, I think that at the end  
services will needed to
have the two GUIs, as Ulrike points out, since the metadata that  
recognize the theoretical
service will vary from service to service...



> 2) create two different GUIs: one for observational, one for  

> theoretical

> SSA (like VOSpec does), the observational one uses standard  

> parameters,

> the theoretical one starts the format=metadata dialogue with following

> generic queries. For this approach the client must be able to  

> recognize

> the difference between observational and theoretical SSA servers when

> harvesting the registry.


In this way there is also two ways to do that in applications:

a) to harvesting the resgistry looking for SSA services + simulation  
in the registry, that solve the solution for theoretical spectra, but  
only for spectra

b) To be able to look for "format=metadata services" in the registry  
(and, for SSA clients look also for SSA).

In my point of view this last approach have additional advantages,  
since other kind of theoretical services (but also non theoretical  
services that not fit in SSA or SIA) can be accessed. As another  
theoretical example, even SNAP services need at the very top a  
format=metadata query before began the SNAP protocol...

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) will need something similar to that
(so it is a work that can be easily recycled work, I hope ;), In  
addition I think it would help to
involve more theoretical researches in the VO development ;)


------

Just for the record and for future discussions: The "no result" in  
theoretical data pointed out in previous mails would have two  
different meanings:
a) the service has no result of the query
b) there is no physical result of this query (because, for example,  
you have asked
for a non-physical region of the parameter space)
There is any way to distinguish this two situations at any level?

------



> I would be happy to hear of any efforts to create clients for

> theoretical spectra access.

and, in my case, also clients that use for a format=metadata access  
for other theoretical (and not theoretical) services ;)


cheers

	miguel