S3: Introduction

The aim of this document is to suggest a new protocol designed to provide access to theoretical data/services in the framework of the Virtual Observatory.

We call it “Simple Self-described Service” protocol as it is based in the ability of the data server to describe itself in a simple standardized way. We refer to the protocol, in what follows, as S3.

Motivation

Theoretical models are widely used in Astronomy. Physical properties of an object can be, for instance, inferred by comparing the observed spectra with a collection of theoretical spectra. There is also a large set of theoretical models that, having no direct observational counterpart, can be used too to infer physical properties of observed systems. The inclusion of such kind of models in the VO framework is fundamental for the development of analysis tools.

A large number of libraries of theoretical models are presently available in the Internet. They can be downloaded as a collection of data files with, in some cases, the help of a web form allowing a previous selection of the files of interest. The results are usually presented in different formats as ASCII or FITS files.

This scenario forces the user to perform a previous work in order to be able to infer physical properties of the observational data from theoretical models. The situation is even worse if several sets of theoretical models, with different formats and outputs, are used. This lack of homogeneity makes it difficult to design automatic tools to simultaneously work with different models and almost impossible to develop applications able to use the models on the fly.

One of the aims of the Virtual Observatory is to guarantee full interoperativity not only among observational data but also between them and theoretical data. However, there are a number of issues that make it difficult to achieve this goal. One of them is the fact that so far VO has clearly focused on observational data. This can be seen, for instance, in the main protocols and standards already developed: SSAP, SIAP, ConeSearch,..., all of them require the object position or name as mandatory, parameters that are meaningless when dealing with theoretical models. Another difficulty is that, depending on the physical problem to be tackled, the particular approach taken by the author of the model or even his/her own personal preferences, the set of parameters used to characterize the model usually differs from one to another. This makes it difficult to define a general data model for theoretical data, a major topic for the IVOA and Euro-VO Theory Groups.

So far, two different approaches have been proposed to tackle this problem:

• SimDB/SimDAP is a solution that is being developed with the main objective of handling complex simulations as, for instance, cosmological ones.

• The SSAP standard includes an use case for theoretical spectra (what was formerly know as TSAP) so that this kind of simulations can be handled in a similar way as the one for observed spectra.

The approach that we propose in this document is very similar to the one already present in SSAP. Actually we try to follow the same philosophy and generalize it to include other kind of theoretical data (isochrones, evolutionary tracks, etc.).

Requirements

Simplicity

A microphysics model is often developed by a small team, focused on science, not computing. They want to make their model available in the VO because they understand that it can be useful for other people, for instance, to infer physical properties of objects from observed data, and also to give more visibility to their model.

In fact, they would usually prefer to develop their own server by themselves, so that they can make available new versions as they are ready, correct errors as they are found, refine details...

But... there is a good chance that they don't have time, money or will to study long and complex protocol definitions or to invest much time (or people) in developing a complex service.

That's why we think that we should give the authors a protocol as simple as possible to make available their own models in the Virtual Observatory. The simpler the development of the service is, the more people will be willing to implement it and, thus, more theoretical models will be available in the VO.

This does not mean that more complex solutions can be developed to address complex models or advanced functionalities, but having a simple protocol can reduce the gap between scientific work and VO implementation that prevent most model developers to make their models available in the VO.

Self-description

A theoretical model is not related with a real object or with spatial coordinates. Instead, it is characterized by a set of parameters and the allowed values for each of them. Actually, those parameters and values are not the same for different models. Even models describing similar physics are often characterized using different types of parameters. This is not surprising. Each scientist develops his/her model focusing on the specific physical problem that he/she wants to address and there are reasons why each developer has chosen to characterize his model using a particular set of parameters.

It does not seem to be a good idea to predefine in a protocol how a scientist must characterize his model. It seems much better to give useful guidelines on how to describe that characterization.

Thus, we think that a useful protocol for microsimulations should be based on the service self-description approach.

The server offering the model must describe itself as clearly as possible. In particular, it must provide information on:

• What kind of model is being offered.
• What parameters characterize the model (what kind of queries can be done).
• What is the physical meaning of those parameters.
• What kind of results can be retrieved.

Moreover, the protocol must explain how an application/user can:

• Obtain that self-description in a standardized way.
• Build a viable query to the server.