On FORMAT=METADATA

[Miguel Cerviño]

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