getCapabilities() and graininess

[Tony Linde]

> anything; however, once the URL is in place and used, it requires a
> lady-and-gentleman's agreement among our registries to prefer the URL
> over explicit inclusion of table metadata in the records we harvest.

This could be a problem for registries which do store the table/column
metadata: they're not going to want to hit all the services so registered if
the registry already contains the information. So we'd need a separate way
of harvesting full information - yes?

Also, how does a service/registry indicate that it has updated the
table/column metadata? Do we say that the current mechanism applies to all
metadata, whether the home registry holds detailed metadata or not?

>        want AstroGrid users to use NVO resources in the query builder, we
>        have to provide table metadata from our registries.

No, I thought we'd agreed that if the home registry does not keep the fine
metadata, it is up to the harvesting registry to get it from the service.

> Clearly from the opinions raised regarding the role of registries, it
> is not simply a DAL issue; registries have a role in this as well.
> It's the curation of the metadata in the registries that has folks
> bothered.  And even in the DAL and VOQL groups there is division about
> whether table metadata should be managed by the registry.

I'm still not sure registry curators can better define the fine/coarse split
than the service providers and users. I'd still prefer the registry folk to
define generic ways of handling fine/coarse metadata and the service folk to
settle what they are.

> As mentioned above, I am not calling for the removal of the table-related
> terms in the schema.  Leaving them in there will allow you to continue

That's good to know.

T.