Hi All -
Sounds like this may be converging...
On Thu, 8 Mar 2007, Iņaki Ortiz de Landaluce wrote:
> Please find forwarded our internal view, within the ESAVO Team, on how
> the metadata access should be handled.
>
> Regarding the open issue about how to perform the queries to such
> metadata there are two clear and different views: using dedicated query
> languages (ADQL or SQL) or TAP specific methods/operations. Here we are
> favor of the second option as we find the query languages a bit too much
> for such a purpose. We would define a minimum number of simple
> operations to access the metadata (table, columns and, possibly, the
> full data model).
I tend to agree with all this: logically this is a table query and should use a similar method, but using SQL/ADQL for this is probably overkill.
Either VOTable or XML would work for the response; the argument for VOTable it merely for consistency with data queries, so that the same mechanism could be used for both.
From Aurelien.Stebe-at-sciops.esa.int Thu Mar 8 04:54:30 2007
> Here are my inputs on the subject of TAP metadata access and the
> relation to Registry schema. For a start, I believe VOTable is not
> the "ideal" format for this task, though it could work (just as it
> worked for SIAP v1.0). It is missing a few elements, and I don't
> think we should modify an already accepted recommendation for this
> specific use. Hence, the output format should be a structured XML,
> and in this area the Registry WG already did quite some work.... so
Could someone expand upon this point - what is VOTable lacking? Note, the suggestion is NOT to use VOTable the way SIAP V1 does, but rather to define a data model for the virtual table to be queried, and return the table metadata as actual data conforming to this data model. Hence in the output table, each row of the table could describe one such field (the table record describes a field, and each row of the table describes one such field). I think this is the way SQL92 does it as well.
> Furthermore, I believe like Doug and NVO that a clear separation
> exists between Service Metadata (that should reside in the Registry)
> and DataSet Metadata (that should be provided by the service).
Agreed.
> As Ray, I would not recommend registering the DataSet Metadata in the
> Registry, though it is possible, but I would certainly discourage
> providing the Service Metadata by the service itself.
But this is exactly the approach already adopted for the other DAL services, which I think Ray and I agreed to. A service should be self describing; the getCapabilities operation is the fundamental source of information regarding the capabilities of the service. The Registry itself, given a service endpoint, uses this to query the service metadata, which is merely cached in the registry. The cached information in the registry is used for service discovery, but a client can query either the registry or the service for service metadata. Hence a service can function with or without a connection to the registry (as in Kona'a example of an unregistered scratch service).