[obs-tap] topics 1 and 3

[Petr Skoda]

Hi all

I have been following the discussion about the draft but still
I am not sure I understand correctly the typical usage of the ObsTAP.
So before commenting on details I would ask questions from the point of 
view of the ordinary astronomer.

1) how will be ObsTAP consumed ? I.e. what will the clients look like ?
A web form or a client like TOPCAT (it is famous but limited in  to 
consuming spectra) -  If there is a lot of expected data products - how 
will be the interaction between discovery client (using database 
responses from all servers ) and consuming client(used to analyze the 
information received - in given mime types ) organised  ?
Through SAMP ?

How the astronomer will use the information received from example queries 
(from the survey )?

How will be the sending of query to ALL servers realized ? In a vodesktop 
like interface ?

The most crucial question I see is - should the ObsTAP be used to query 
the tables in published journals ? I.e most of the information of 
great interest for the astronomer are the Level2 or level3 products 
published in electronic appendices of journals (most of them go the 
vizier)

In fact all the practical examples of VO benefits (e.g. in ESO VO 
summers/winter schools) start with opening particular table/catalog from 
vizier (e.g. selected quasars, X-ray sources ....).

So I think the crucial moment for success of ObsTAP is the access to 
Vizier and other published catalogues and tables.
>From this it stems the requirement to describe the VARIOUS content of 
possible queries/answers in a fine-grain manner.

So I think we have to either think about the more detailed hierchical 
structure or the "other" type . We are hardly able to forecast what the 
astronomers will look for and what could be published (mainly in Level2-3 
products).

It is as well difficult to think about typical raw data format if asking 
for level0 products as every instrument requires special format of stored 
data and some may not be predicted now and we want the standard to be 
valid for several years. But still the raw data may be easier identified 
with some of the basic types (datacube, spectrum, time series ...) then 
higher level product (e.g. time series of equivalent widths, periodogram 
of different line profiles ....).


I think the important feature of the query process is the possibility to 
return the content of table (until some server-prescribed limit) without 
any limitations on any characterization axis - it is very frustrating if 
you do not know what is in the archive and the system will not give you 
any answer if you do not state particular position, targetname etc....

Considering the mime types of answer - we need to have client clearly 
understanding all possible answers - I am afraid its almost impossible - 
something like the SSA format NATIVE is required.
And I fully support Igor's objection stating the reply must be in binary 
table fits - realy 1D FITS or even other special formats may be expected 
for spectra (from IRAF, MIDAS ...) and are published in such format.

If we restrict the answers too much we may not have enough data to query 
;-) (its now the problem of SSA - the lack of useful spectra in VO is 
clearly seen everywhere in a research)


> This topic still need some examples to try to cover most of the 
> possibilities.

Best regards,

Petr

*************************************************************************
*  Petr Skoda                         Phone : +420-323-649201, ext. 361 *
*  Stellar Department                         +420-323-620361           *
*  Astronomical Institute AS CR       Fax   : +420-323-620250           *
*  251 65 Ondrejov                    e-mail: skoda at sunstel.asu.cas.cz  *
*  Czech Republic                                                       *
*************************************************************************