table metadata and the registry

[Tony Linde]

Hi Ray,
 
I'm not sure we do not have a better version of what you suggest already.
The GWS proposal for getCapabilities will return the full registry record
for a resource and this is, in effect, a URL for getting the extra metadata.
I expect most registry implementations will use this to harvest full
metadata anyway. If a service is separate from the data then it is simply a
matter of that service getting the table & column metadata from the data.
This also removes the need for implementing some standard way of retrieving
metadata at the data end - the service specific to that data source can use
whatever method is already provided by the data source to get the metadata.
 
If we were to implement your suggestion of a url for the fine-grained
metadata this would require:
-          that all resources implement these new URLs (effort matched by
the getCapabilities implementation anyway)
-          future resources which have fine-grained metadata not of a
table/column nature would have to implement other URL methods which
registries then have to implement rather than just using getCapabilities on
those resources (a method which will work on all existing and future
resource structures)
-          the registry interface will need changing to take account of
getting full resource information rather than the skeleton record 
 
Much as I'd like to close the fine/coarse-grained debate, I think the
getCapabilities approach will cause fewer problems in the future (and
present) than the URL approach.
 
Cheers,
Tony.
 
-- 
Tony Linde
Phone:  +44 (0)116 223 1292    Mobile: +44 (0)785 298 8840
Fax:    +44 (0)116 252 3311    Email:  Tony.Linde at leicester.ac.uk
Post:   Department of Physics & Astronomy,
        University of Leicester
        Leicester, UK   LE1 7RH
Web:    http://www.star.le.ac.uk/~ael
 
Project Manager, EuroVO VOTech   http://eurovotech.org 
Programme Manager, AstroGrid     http://www.astrogrid.org 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/registry/attachments/20070508/e83e67a2/attachment-0001.html>