table metadata and the registry

[Tony Linde]

I don't agree, Ray. The table/column information is as much a part of the
description of the service as any of the aother metadata. Splitting it out
is arbitrary: why is the table/column information different from the rest of
the metadata?

Doug suggests that it is 'data-related metadata, and in general access to
such metadata is as important as access to the data iself' which makes no
sense: it is important so we shouldn't make it as accessible as the rest of
the metadata? 

And it is not data-related, it is service-specific. Any service can choose
which tables and columns from a database it returns or even to return data
not in the database, by presenting views as if they were tables. 

The idea that we might need to include more than the basic table/column/ucd
names doesn't hold water either. It would still be metadata about the
service: it is part of the service offering, as much as any other part of
the capability. The service is capable of providing this information: it is
specifically metadata, not data, and should be treated as such.

> but specifically because the table metadata are not even part of the
> capability metadata.

My apologies re Capability - I've been away too long - I thought the catalog
stuff was in the capability section.

But that doesn't change the simple fact that I can see no reason to treat
the table/column metadata any differently from the rest of the detailed
metadata. I was assuming you were treating the coarse-grained stuff as the
RM-level stuff and everything else as fine-grained. But you seem to be
wanting three levels of metadata: basic, capability and table/column: why?

Or are you saying that everything except the table/column info is
coarse-grained and only the table/column metadata is fine-grained?

And if so, why not just have VOSI define two methods: getCoarseMetadata and
getFineMetadata? Then each service standard can decide if they need both
and, if so, can determine what goes into each.

(Sigh - back to square one I guess!)

Cheers,
Tony.

> -----Original Message-----
> From: owner-registry at eso.org [mailto:owner-registry at eso.org] On Behalf
> Of Ray Plante
> Sent: 09 May 2007 18:52
> To: 'IVOA Registry WG'
> Subject: RE: table metadata and the registry
> 
> 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