New version of VO Support Interfaces: v0.26
Aurelien.Stebe at sciops.esa.int
Tue May 8 07:51:14 PDT 2007
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
(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.
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.
More information about the dal