New version of VO Support Interfaces: v0.26

[Doug Tody]

Hi All -

Aurelien makes a pretty good summary of the overall picture where
metadata is concerned:

On Tue, 8 May 2007, Aurelien Stebe wrote:
> 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)

Resource metadata also includes the Coverage element, which can be
quite complex, includes a nontrivial STC reference, and may require
a tool of some sort (e.g. a footprint service) to generate, if we
want to summarize coverage with a region description of some sort,
even a summary one.

Service metadata as defined by VOResource includes the interface
to a service as part of the capability element.  For a HTTP service
this includes the input parameters; for a SOAP service, a pointer to
the WSDL.  Aurelien suggests instead including the input parameters
with the table metadata instead, which would be another way of looking
at this since the information is tabular in nature.

Despite the tabular nature of the list of input parameters, I think
including this in the service metadata (as the registry currently
requires) is a reasonable simplification, since service metadata
describes the service instance, and logically includes both the
service capabilities and any public interfaces.  We cannot really
describe the service interface without saying something about what
input parameters are supported.  The "interface" linkage is stronger
than the "table" one.  Service introspection requires that the service
interface and any optional capabilities be described.

Table metadata is more complex than is suggested here, and more complex
than in the current view provided for a VODataService in the registry.
How much more complex, is an active topic of dicussion in connection
with TAP.  Effective query building may require more information
than mere field names and UCDs (the VOTable PARAM metadata), e.g.,
information about table indexes, views, keys, and so forth (as for
example in the SQL information_schema).  Note this extra information
is *not* required for registry-based discovery, only for data access.

I strongly agree that service and table metadata should originate
at the service (also dataset metadata); resource metadata is another
matter however.  More on this in a separate message.

	- Doug