table metadata and the registry

[Tony Linde]

Or, thinking about it, are you suggesting, Ray, that the table/column
metadata is removed from the resource definition entirely and is only
available from the URL you propose?

T.

> -----Original Message-----
> From: Tony Linde [mailto:Tony.Linde at leicester.ac.uk]
> Sent: 09 May 2007 20:46
> To: 'IVOA Registry WG'
> Subject: RE: table metadata and the registry
> 
> 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