mcs at iaa.es
Tue Jul 3 03:31:43 PDT 2007
I was not in the "dal" mail list, so I hope do not repeat issues that
may be there before.
I want to comment 3 issues related with TSAP (in general the use of
format=metadata) that have appeared in the list
1) About an use case of the FORMAT=METADATA usage can be found at:
(or http://svo.laeff.inta.es --> TSAP in left menu under SVO Projects)
I think that it is a clear example there :)
The important point in the usage of format=metadata in that pages is
that it is NOT
restricted to spectrum, it can be use to query any dataset (image,
spectrum, time series, catalog, numerical simulation...!)
Format=metadata is just a first contact with a VO service ("Hello,
what do you provide?")
after that, you can continue with a SSA, an image, a numerical
simulation via SNAP or, why not, another format=metadata query....
2) About the claims that SSA covers the needs of those
wishing to publish theory spectra... I think that it is a confusion
Maybe SSA covers these needs (I would including TSAP), but the real
how many applications includes the format=metadata query... I only
and VOSed.... Services adn protocol are ready, the problem is in
In other words, SSA theoretical enable the access to theoretical
models by the use of
format=metadata, but it do not allow the access to theoretical models
in the VO because
it is not user-friendly implemented in applications (except a few of
Any case It is not an issue in this mailing list.
Finally, It also support the claim by Jesus about TSAP as a
- TSAP is necessary NOW because it is the only way to access
theoretical data proved
to work, at least in the applications it has been implemented.
- It is hope to have another protocol (maybe more general) in the
future... In fact
it the "S" of spectra in TSAP is not required since the
protocol can be used for data
diferent than spectra.
The "T" in TSAP is also not required, since the idea of
the use of format=metadata
is to query a service where there is no "a priori" knowledge
about its offers, and there
is no a predefined way to make a query (ej: there is no RA
and DEC in the data the
So, it is hope to have a "general access protocol" that allow
access to all possible VOTables that are no spectra or image....
3) Finally, about possible extensions... As I point out in the first
item, I think that the
most natural extension is to allow a format=metadata query recursively.
In the current TSAP version, the TSAP service must be able to answer
1. http..... format=metadata VOTable with possible
query parameters without
2. http... value1=a&valuen=b VOTable with a list of
references to others VOTables
that can be loaded by the specific application
3. http.... id=12312 access to a
particular VOTable with data
The order is 1 --> 2 --> 3, but it is imposed by current applications
using TSAP. But
actually, the workflow can be 1 ---> 2 --> 1+2 ---> 1+2 ---> 1+2 ---
> .... ---> 3
where 1+2 means "for fixed values on some fields in the query, is
there more values to choose?". It allows to explore services like,
as example, VizieR, or in general, any
complex databese with no regular structure...
More information about the dal