tehoretical SEDs in VO applications

[Jesus Salgado]

Dear Miguel,

Just some comments about your applications benchmark.

Units:
------

> 1. problem with units nomenclature: There is no recommendation about
the use of units in the VOTable fields. In particular, 
> VOSpec and specview use different ways to define the units for the
flux e.j. cm**2 vs. cm2 to define the $cm^2$ (in latex). 
> Would it be possible to define any recommendation about that?
Otherwise the same VOTable would not be used for both 
>  applications! 

As you probably know, VOSpec is not using the units string definition
for the units handling but the scaleq and dimeq fields. 
We made the proposal to include this dimensional analysis data to
prevent the problems of multiple unit string convections (among other
things)
You have read it in the SED document, (point 3.2 Units) 
http://hea-www.harvard.edu/~jcm/vo/docs/spec0.93.html
The definition of the scaleq and dimeq syntax is (hopefully) uniform for
all the services, following our recommendation.  In any case, same
VOTables are currently used for both applications, so it looks that the
problem has been solved at application level (for us, using the
dimensional analysis information instead of the unit strings, for others
using aliases and string conversions)

Metadata in VOTable
-------------------

About the VOTable metadata issue, in our view, the information inside
the VOTable response is to be used automatically by the client
application (except for the VOTable editors). 

In case there is no implementation to use specific information in the
VOTable response, there is a risk to lose it. VOSpec is taking the
information for the row where the spectrum is described and it is shown
to the user if the user double-click on one spectrum in the result tree.
This should not be enough in the future, as any essential information
included in the VOTable response should be protocolized in some way to
be properly treated in the client (not only shown). If there is some
information only to be shown to the user linked to one result, probably
the best way to do it for the time being could be to include a link to a
dynamically generated page  (in a format readable by humans).

About the columns for errors, this will be included in VOSpec quite soon
for all the services that can provide them. The only constraint would be
the order of the columns in the “columns” field.

TSAP:
-----

> d) A final comment, it looks that only VOSpec is able to manage a
Theoretical spectral acces protocol: 
> It means, perform the query to a server that gives back a table with
the parameter space covered by the 
> models that the server provides, and perform a "second" query over a
subsample of the parameter space covered.

This is not quite surprising as we were the ones to propose the
theoretical spectral access protocol in the IVOA. 
As you probably know, we proposed the creation of this kind of server to
the SVO coordinator (Enrique Solano) for the Kurucz models and we
implemented the client part in VOSpec. Some other services were created
later related to SVO and Mexican VO, and we have contacted some others
to create similar services (as the ones from the French VO), so all the
services have been created more or less under our coordination. We think
it is a good first step to include theoretical SEDs in the VO, and easy
to be implemented for SED VO applications.

Best Regards,
Jesus Salgado

ESA-VO team
e-mail: Jesus.Salgado at sciops.esa.int
Tel + 34 91 8131271

European Space Agency/European Space Astronomy Centre
VILLAFRANCA Satellites Tracking Station
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN