New version of VO Support Interfaces: v0.26

[Aurelien Stebe]

Hi all,

This issue obviously affects many WGs and it is a good thing to discuss 
it openly in the different lists. I will present ESAVO point of view, 
which we already detailed a few times, more recently on the VOQL-TEG 
list regarding TAP, but I'll try to summarize it here as clearly as I can.

We consider 3 different types of Metadata :
 - Resource Metadata : the "curation" and "content" elements of 
VOResource (creator, contact, description, subjects, ...)
 - Service Metadata : the "capability" element of VOResource (URL 
endpoint, service type, max records, ...)
 - Table / IO Metadata : the "catalog" and "param" elements of 
VOResource (table/column name, UCD, uType, input parameters, output 
fields, ...)
(we will not talk here about Dataset Metadata, which only concerns the 
Service and is accessed through the "queryData" method in DAL)

The Registry is not just a cache for any of this information. It was not 
designed with the idea of just being a cache and changing the ideology 
now that the design is done might not be a good idea. The Registry 
should be the source for the Resource and Service Metadata, and it 
should be inserted directly there.
The Table / IO Metadata must obviously be accessible from the Service 
itself, and some Registries do not want to handle this information as 
the coarse/fine-grained debate showed. Hence, this metadata should 
originate from the Service. Fine-grained Registries can then harvest 
this information if desired. This is where those Registries work would 
be much simpler if all the Services would provide this information in a 
standard fashion (same access point method or Ray's pointed URLs idea, 
same output format - specific VOResource elements).
If people feel that it might be useful to access the Resource and 
Service Metadata from the Service itself, an optional standard method 
call could easily "proxy" this from the Registry. Meaning that the call 
would only redirect to the Registry entry without the client being any 
the wiser about any Registry system.

In the end that makes one method on the Registry to get the VOResource 
record, one on the Service to get the Table / IO Metadata and eventually 
one on the Service to get the VOResource record. All coarse, 
fine-grained, service or registry source-for-the-metadata people should 
be happy and be able to do the calls the way the want to. Those that 
want to handle the full VOResource record at the Service should even be 
able to do so, having an agreement with a particular Registry that it 
will harvest them every x days to update itself. This mechanism 
shouldn't be considered standard though and be handled outside the VO.

Comments are welcome, but I guess discussions will be much easier next 
week in Beijing.

Cheers,
Aurelien

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