On FORMAT=METADATA

From: Miguel Cerviño <mcs-at-iaa.es>
Date: Tue, 3 Jul 2007 12:31:43 +0200

Hello,
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:

http://svo.laeff.inta.es/modules.php?
op=modload&name=phpWikiP&file=index&pagename=TSAP

(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 here....
Maybe SSA covers these needs (I would including TSAP), but the real problem is
how many applications includes the format=metadata query... I only know VOSpec
and VOSed.... Services adn protocol are ready, the problem is in other place...

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 them).

Any case It is not an issue in this mailing list.

Finally, It also support the claim by Jesus about TSAP as a "transitory" protocol:

• 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 service offers)

     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 queries with

    query:     							answer
1. http..... format=metadata                  VOTable with possible  
query parameters without
                                                                    

tabledata

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...

cheers

        Miguel Received on 2007-07-03Z12:32:00