Alternative proposal

[Tony Linde]

Thanks, Doug.

> I would go one step further and suggest that the registry has primary
> responsibility for defining, curating, and using high level resource
> metadata.  So for example if we want to relate two or more resources,
> or augment the resource metadata for a service with information such as
> the service validation level (which should not come from the service
> itself), or a status up/down marker, relations to related resources,
> etc., this is best done at the registry level.  

Completely agree.

> 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.

> 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.

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.

> or how it is obtained from the service.  At the service level we need
> to take all these different use-cases into account in specifying the
> metadata, and best to make it accessible.

Completely agree again.

> This would be a good place to start.  Lets also not forget the need
> to agree upon the scope of getCapabilities, as this is required now

I'd like to not prejudge. I know DAL has gone a long way towards defining
what metadata need to be provided but let's bring that to the table in the
discussions and see what else falls out.

Cheers,
Tony.