VOSI, getCapabilities and table metadata

[Ray Plante]

Hi VOSI enthusiasts,

As you may know, we have this joint session between GWS, DAL, and Reg
in Trieste as a follow-on to a similar session in Cambridge last fall.
A major purpose of these joint conversations is to figure out how we
can get more metadata about a service--in particular, service
interface and capability metadata and, where applicable, table
metadata--from the service itself.  Registries can harvest from these
services in smart ways to cache the metadata in whatever ways they see
fit.  Since last fall, I feel like that there has been some important
maturation of VOSI ideas that we can really settle on a solution.

The VOSI v0.4 document includes the getCapabilities() operation for
retrieving the capability metadata in the VOResource format.
Guy later illustrated via email to the GWS list how we can encode into
a registry's VOResource record the handle to this operation; this
involves an extra capability element:

   <capability standardID="ivo://ivoa.net/std/VOSI#capabilities">
     <interface xsi:type="vs:ParamHTTP">
       <accessURL use="full">http://casx019-zone2.ast.cam.ac.uk/community/VOSI/capabilities</accessURL>
       <queryType>GET</queryType>
       <resultType>application/xml</resultType>
     </interface>
   </capability>

Although it is not currently in the latest VOSI document, we can use a
similar technique for indicating how to get table metadata:

   <capability standardID="ivo://ivoa.net/std/VOSI#tables">
     <interface xsi:type="vs:ParamHTTP">
       <accessURL use="full">http://casx019-zone2.ast.cam.ac.uk/community/VOSI/tables</accessURL>
       <queryType>GET</queryType>
       <resultType>application/xml</resultType>
     </interface>
   </capability>

This is a really nice technique, because it does not require any
changes to the registry standards nor does it impose (as I'll
discuss below) any mandatory requirements on our standard protocols or
the services that implement them.  Best of all, this is a technique
that AstroGrid *already uses* to harvest table metadata and have
demonstrated that it is practical.

I propose then that we add the provision for retrieving table metadata
to the VOSI spec.  This would involve adding another subsection to
section 2 that looks much like the "Capability Metadata" section
(2.1).  The important differences would include:

    a. the operation would be called "getTableData"

    b. it would return a sequence of one or more elements of type
       {VODataService}Table
         o  note an alternative would be one or more
            {VODataService}Catalog elements;  more on this later.

    c. the standardID for citing this operation in a resource record in
       the registry would be ivo://ivoa.net/std/VOSI#tables

    d. the operation would be OPTIONAL.  That is, if a service chooses
       to support this, this spec says how it should be done.

The last point (d) is key to minimizing the impact on both protocol
specifications and implementing services.  All of our standard catalog
services--ConeSearch, SIA, SSA, SkyNode, and the emerging TAP(s)--have
ways of accessing this information via the service, albeit they are
all different.  However, it would be quite straightforward to create a
simple proxy service (one for each service type) that use the
mechanism specific to a protocol to retrieve the data and convert it
into the VOSI standard format.  Such proxy services could be provided
by one or more registries; publishing registries could automatically
insert a getTableData() capability into the registry record anytime
someone publishes a new standard service.

As a result, NO IMPLEMENTATION OF A STANDARD SERVICE NEEDS TO SUPPORT
THIS FUNCTION.  The services that would consider doing so would be
the custom ones--i.e. the one's that don't comply with any standard
protocol.  Custom services that did support it would benefit from
the greater visibility of their service in a registry; however, if it
was not supported, it wouldn't break anything.

In summary, the advantages of this getTableData proposal are:
   *  no changes to registry standards are necessary
   *  it has ZERO impact on providers of standard services
   *  AstroGrid has already demonstrated its viability
   *  it solves the long-standing controversy over coarse and
        fine-grained registries!!  (Yeah!)

cheers,
Ray