On FORMAT=METADATA

[Pedro Osuna]

Dear all,


I am planning to send my inputs to the comments on the SSAP doc, both
from the community point of view as from my VOQL Chair hat (which I have
to following the RFC).

>From my working group side, I had an informal action from Doug to write
a "Use Case" in the form of appendix or similar for the FORMAT=METADATA
case for Theoretical spectra, and how it is currently used with -so
called- Theoretical Spectrum Access Protocol services.

I will write this "Use Case" and send it to Doug and the community by
tomorrow. This Use Case compiles inputs from both SVO and ESAVO, who
were the ones that first described the possible TSAP, now embedded in
SSAP.

I think the absorption of the so called TSAP in the SSAP was already
agreed some time ago, and it is maybe good enough for the time being at
least. Whether we will have to review it in the future depending on what
type of architecture is decided for the getCapabilities is something we
will have to discuss later, I believe.

Other issues related to what a "General Protocol" means, its relation to
TAP, its relation to the "getCapabilities", etc., are outside the scope
of the FORMAT=METADATA discussion for theoretical spectra here, as it
affects many other things in which we are working on different fields
and groups.

I will be sending the inputs by tomorrow.

Cheers,
P.




On Tue, 2007-07-03 at 12:31 +0200, Miguel Cerviño wrote:
> 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
> 
> 
-- 
Pedro Osuna Alcalaya

European Space Agency (ESA)
European Space Astronomy Centre (ESAC)
Research and Scientific Support Department (RSSD)
Astronomy Science Operations Division (SCI-SD)
e-mail: Pedro.Osuna at esa.int
Tel + 34 91 813 13 14    Fax: +34 91 813 11 72
-------------------------------------------------                                                                                
European Space Astronomy Centre (ESAC)
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN

================================================================================================
This message and any attachments are intended for the use of the addressee or addressees only. The
unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content
is prohibited. If you received this message in error, please delete it from your system and notify
the sender. E-mails can be altered and their integrity cannot be guaranteed. ESA shall not be liable
for any e-mail if modified.
=================================================================================================