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.