getCapabilities() and graininess

[Ray Plante]

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