Alternative proposal

[Doug Tody]

On Thu, 10 May 2007, Tony Linde wrote:

>> do this in general.  For service and data-related metadata yes, this
>> could come only from the service, but not high level resource metadata.
>
> Not a major issue, I don't think - if we have an interface then people can
> do it or not. Eg, the AstroGrid DAL service self-registers when installed -
> this is pretty necessary if you offer a service like DAL that can be
> installed in front of any type of dataset.

I can see where one might want to do this in the kind of situation
you describe.  Perhaps the right way to think of this is as a registry
feature, with the service framework taking the place of a human using
the registry Web interface.  If so, it might want to continue to be a
"push" (call to a registry doRegistration method of some sort), using
pull as is now planned to have the registry update cached metadata,
once it already has the service registered.

>> For finding resources, metadata describing service capabilities or
>> data characteristics such as table/column information may be useful
>
> Actually, I'll backtrack on what I've been saying (meant to say this in
> original message) and claim that table/column names should not be part of
> the selection metadata. What should be however is UCDs and utypes. No-one is
> likely to search on a column name but will on the UCD which expresses the
> column datatype.

Yes.  Probably this is what would be actually be used for selection,
plus perhaps table metadata such as the class or type of table,
relationship to any data collections, and so forth.

> That said, we must have a standard way of getting the table/column name from
> the service (which I believe DAL has proposed): and must be able to get all
> table/column names, units etc in one call to whatever method provides it.

This would be no problem and would have to be part of any metadata query
interface.

 	- Doug