table metadata and the registry

[Keith Noddle]

>> My apologies re Capability - I've been away too long - I thought the catalog
>> stuff was in the capability section.
> 
> I was also surprised to learn that you were returning dataset metadata in
> this fashion; it just came out in more detailed discussions this week.
> I knew that AstroGrid was caching table metadata in the registry, but
> not how it was getting into the registry.  Clearly we were right to put
> Registry-DAL integration on the agenda for this interop.
I would like to clarify a point here - and my apologies if I have misled 
you, Doug:

Currently, AstroGrid services push-register themselves with our 
Registry. We want to move to the pull model which is why we are keenly 
interested in a resolution to this debate! As soon as we have agreement, 
we will implement the appropriate solution. The comment above about 
capabilities is, I believe, a reference to the schema and not the 
service call.

> I have to say, it is not clear why the registry or registry-based apps
> should care much how the service delivers such data, except perhaps
> as how it affects registry content in the sense that Ray mentions
> (we assume service metadata is cached and searchable).  From the DAL
> perspective table metadata is science data - bulk science datasets and
> their associated metadata are in the same category - and our priority
> is to deliver both to client apps via a consistent, convenient to
> use interface.
Bottom line: I only care that we agree predictable and repeatable 
mechanisms for getting metadata. I would dearly like to avoid 
reinventing the same wheel in different Working Groups and I have 
preferences for how we do this stuff. Furthermore, I believe there is an 
obvious solution staring us in the face :-) However, I'm open to debate.

> Ultimately however, for a given GET-based service, regardless of the
> details of the service interface, this will just reduce to a fixed URL
> which we could probably manage to expose in the standard service metadata.
> The only thing that might be different than now if you want to cache
> this information, is that it might be necessary to fetch the data from
> these URLs when something unspecified triggers an update.
There's a VOSI defined mechanism that can be used to determine if 
service provided metadata has changed. It is an extremely light overhead 
for the service and makes caching metadata (wherever it is cached, not 
just in the Registry as we do) much easier to implement.


I totally agree about the need for all this to be discussed. It seems to 
me the VO is maturing. The once clear IVOA Working Group boundaries are 
starting to blur (one mail thread went to four mailing lists!) as we 
start to tackle more complex issues. There almost certainly isn't one 
optimal solution, but we do need to chose one. The worst decision we can 
make is NO decision.

Keith.

-- 
Keith Noddle                    Phone:  +44 (0)116 223 1894
AstroGrid Project manager       Fax:    +44 (0)116 252 3311
Dept of Physics & Astronomy     Mobile: +44 (0)7721 926 461
University of Leicester         Email:  ktn at star.le.ac.uk
Leicester, UK   LE1 7RH         Web:    http://www.astrogrid.org