VOSI, getCapabilities and table metadata

From: Ray Plante <rplante-at-poplar.ncsa.uiuc.edu>
Date: Fri, 9 May 2008 12:06:52 -0500 (CDT)


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:

  1. the operation would be called "getTableData"
  2. 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.
  3. the standardID for citing this operation in a resource record in the registry would be ivo://ivoa.net/std/VOSI#tables
  4. 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:

cheers,
Ray Received on 2008-05-09Z19:07:11