table metadata and the registry

[Ray Plante]

On Wed, 9 May 2007, Tony Linde wrote:
> Just one point I wanted to clarify: I sensed you were proposing the
> table/column retrieval method as 'extra' to the getCapability method. If
> not, no problem, discussion over. If so, can you explain why we'd need both?

The test question is this: suppose registry A retrieves metadata from a 
service using get*() and that metadata includes table metadata.  When 
registry B harvests that record from registry B, will the record include 
the table metadata?  If the answer is yes, we have a problem.

We need to have a common understanding of how replication will work with 
the introduction of a service method like get*().  Here's my take 
(assuming a VOSI getRegistration()):
    1.  Publisher goes to a Publishing Registry A to register the service.
    2.  Instead of filling out a big form, she identifies it as a
          VOSI-compliant service and provide the VOSI endpoint.
    3.  Registry A retrieves the record from the service using
          getRegistration().  The registry now counts this resource among
          those that it "manages".
    4.  Registry B harvests from Registry A, asking for the resources that
          Registry A manages (via the OAI set "ivo_managed").
    5.  Registry A periodically returns to the service's VOSI endpoint to
          see if the record has been updated.  If so, it updates its record
          accordingly.
    6.  Registry B again harvests from Registry A to get updates from the
          last harvest time.  RegB gets the updated record for the service.

As you can see, getRegistration() by itself does not address the question 
of fine-grained metadata.  The fine-grained information is intermixed with 
the coarse-grained.  Neither does getCapability() as Doug as recommends it 
(returning only the capability element) in general for the same reasons, 
but specifically because the table metadata are not even part of the 
capability metadata.

Now VOSI has getRegistration() and getMetadata() in which the latter 
return more (and let's say, fine-grained) metadata in VOResource format. 
If Registry A wants that extra info, does it call getMetadata() instead? 
If so, then we are back to the same problem: the table metadata will make 
its way to Registry B.  Furthermore, there is nothing that says that table 
metadata should go in one or the other method--it's completely the choice 
of the publisher!

Now rewind.  Suppose the service provides a record that does not 
explicitly include table metadata, but rather a pointer to it.  Registry A 
pulls the record over, and that is the record it manages, and that is the 
record it sends to Registry B during harvesting.  But Registry A also 
wants the table metadata, so it resolves the pointer and ingests the 
metadata.  Furthermore, it inserts the table metadata into the records it 
returns to users through the search interface.  A is happy, B is happy. 
IVOA harmony ;-)

Is there a way to make B happy with get*().  I'm open to suggestions.

cheers,
Ray