getCapabilities() and graininess

[Tony Linde]

>    o  At the heart of the fine-grained metadata issue is the method we
> use to share metadata: registry harvesting. 

So why are we talking about changing the schema? Why not just change the
harvesting spec: instead of a getMetadata method (or whatever it is), add a
getCoarseMetadata method so that those registries which do not want to
maintain the fine-grained metadata do not need to. 

>    o  We need a common understanding of what fine-grained means.

Why not leave this to the people who define the service standard: so whoever
defines SIAP, SSAP, TAP etc can define the fine and coarse level of metadata
(if necessary - they might be equivalent), depending on the needs of those
who use the services.

>    o  With issue #3 above, I proposed a common way to get at table
>       metadata without explicitly including it in the VOResource record
>       that enters the harvesting stream.  

See above for keeping it out of the harvesting stream. 

But the definition of it MUST remain part of the IVOA standard for a tabular
data service. To go back on that after the months of tiger team and
workgroup wrangling to derive the standard cannot be right. It would render
all the registries and applications that rely on it non-standard and thereby
ineffective in the eyes of other apps developers - no-one could countenance
that.

>       Tony suggested that the VOSI standard provides the same solution.

Ignore what Tony said previously: it seems I'm only now coming to realise
what your proposal was, Ray, and maybe I'm still off-track. Please correct
me if I'm wrong.

I know you want this discussion to stop on the list and continue in Beijing,
but I need it to continue as long as you're accessible. Neither Kevin nor I
can be in Beijing and we need to brief those who will be there on the affect
your proposal might have on AstroGrid, so I'll have to keep digging I'm
afraid (does your flight have wireless? :) ).

Cheers,
Tony.

> -----Original Message-----
> From: owner-dal at eso.org [mailto:owner-dal at eso.org] On Behalf Of Ray
> Plante
> Sent: 09 May 2007 21:02
> To: IVOA Registry WG; dal at ivoa.net; gws at ivoa.net
> Subject: getCapabilities() and graininess
> 
> Hi WGers,
> 
> (I apologize for one last cross-posting.  We've had a very important
> discussion here that has truely been cross-cutting, so I thank the
> non-participants for their patience.)
> 
> I feel this week's threads winding down, so it might be time for some
> summarizing words.  We have talked about three issues that are clearly
> interrelated.
> 
>    1.  The VO Standard Interfaces (VOSI) WD and how registries might
> use it
>        to receive resource descriptions.
> 
>    2.  The DAL-proposed getCapabilities() method and how it relates to
> VOSI
>        and possible use by registries.
> 
>    3.  A proposal for addressing the fine-grained vs. coarse-grained
>        registries related specifically to table metadata.
> 
> In hopes of providing some useful things to think about going into next
> week, here are some summarizing thoughts.
> 
>    o  I think we all agree that retrieving metadata from the service
>       is a good thing.  It gives the service provider greater ease and
>       control to keep the information up to date. It also makes it
> easier
>       to register the service because there will be less form-age to
> deal
>       with.  The questions needing answers are:
> 
>        a.  should the service export a complete VOResource description,
>              as in VOSI's getRegistration()?
>        b.  should the service export only the capability metadata, as
> in
>              DAL's getCapabilities()?
>        c.  is there a way to provide both in a consistant way that
> doesn't
>              confuse everyone involved?
> 
>    o  Note that I didn't say anything about grain-iness or table
>       metadata above.  This is, I believe, a separable issue; that is,
>       answering these questions do not address the grain-iness issue.
> 
>    o  At the heart of the fine-grained metadata issue is the method we
> use
>       to share metadata: registry harvesting.  If reputed fine-grained
>       information gets into the harvesting stream, it will tickle this
>       controversy.  More importantly, if we expect the information to
> be
>       there, it will irritate the controversy.
> 
>    o  We need a common understanding of what fine-grained means.  We
> may
>       not agree on what information falls into that category, but if we
>       know its characteristics, we might develop some general
> strategies to
>       deal with it.
> 
>       I have some thoughts on this, but I won't get into them here.  We
>       will discuss it in a Registry session, and I hope to capture our
>       thoughts in an IVOA Note.
> 
>    o  With issue #3 above, I proposed a common way to get at table
>       metadata without explicitly including it in the VOResource record
>       that enters the harvesting stream.  It involves putting a URL in
>       the record that points to the table metadata encoded in a
> standard
>       format.
> 
>       Tony suggested that the VOSI standard provides the same solution.
> So
>       the questions that remain are:
>         a.  Can the VOSI interface indeed allow a registry to
> sufficiently
>               limit the fine-grained metadata it has to contend with.
>         b.  Could VOSI be altered to enable this?
>         c.  Can either Ray's suggestion or VOSI point to a general
> solution
>               that can be applied to other information that might
> qualify
>               as "fine-grained"?
> 
>    o  Finally, the graininess issue points to a larger issue of how we
> work
>       together in the IVOA.  Personally, I feel that it should be an
>       important principle of the IVOA that VO projects should be free
> to
>       innovate new ways to meet the needs of their communities, but
> they
>       should do that in a way that doesn't prevent other projects from
>       doing the same at the cost of interoperability.
> 
>       Note that I want to emphasize the part about what projects CAN
> do,
>       not the CAN'T.
> 
>       Furthermore, we need to keep each other informed about the cool
> stuff
>       we are doing.  In this way we can identify early opportunities
> for
>       interoperability and avoid harmful fragmentation.
> 
> hope this helps,
> Ray
> 
> 
>