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
Received on 2006-05-05Z12:48:36