VizieR repository

[Ray Plante]

Hey Sebastien,

This looks great!  I'm in the process of comparing existing OAI 
implementations out there to get a list of things we need to unify, so 
I'll have more feedback later.  

Just out of curiosity: did you implement the protocol yourself or did you 
build on something existing?

For now, here are some quick items.

On Mon, 24 Nov 2003, Sebastien Derriere wrote:
> * The AuthorityID has been set to "CDS". Is this the correct choice, or
> should it look more like a domain name? Or should there be different
>  AuthorityIDs for VizieR, Simbad, Aladin, ... etc in the case of CDS ???

"CDS" is a fine choice.  (I'm now discouraging domain name-like names.)

> * I have defined as 'Sets' the top-level categories in VizieR, and
> the items correspond to the different 'Tables'. Should the items be
> 'Catalogues' rather than 'Tables'? (there are approx. 4000 catalogues,
> and 10,000 tables - 1 cat. can contain several tables).
>   Is there a way to handle different levels of granularity (sets,
> subsets)?

The OAI spec allows for hierarchical set membership, where the levels are 
delimited by colons (:).  For example, a record in the set called 
"Table:AstrometricData" would be returned when someone asked for set=Table 
or set=Table:AstrometricData, but not when 
set=Table:Table:AstrometricData.

We don't need a standard on this within the IVOA, so I encourage your 
experimentation with this.

> * I still had problems with the allowed syntax for ResourceKey,
> therefore I currently use a modified version of VOResource-v0.9.xsd

I've corrected the schema and sent it to Marco for posting.  (Thanks 
again!)

> * How do we deal with obsolete items in a registry?
> 
>   Sometimes, an item becomes obsolete in a repository,
>   but it is very rare that it is acually deleted.
>   Therefore, the status can still be 'active' while the
>   item is obsolete.

This is an interesting idea.  Possible ways to deal with this (in the 
long term):

  1) add a status type, "obsolete"  (I like this the most.)

  2) change nothing; just for the purposes of the IVOA registries, mark 
     these as deleted.

  3) add some other mark up to tag this characteristic.  (I like this the 
     least.)

Unless it causes us problems in the short term, I would recommend that we
wait until after Jan. to make this change.  For now, it might better to 
not register the obsolete resources.

> * Not all the possible metadata are filled yet. At least the
> required ones are. How are we supposed to describe the coverage
> in this kind of OAI-PHM XML ? Should it be a second element in
> the <metadata> section, formatted accordingly to the coverage
> schema?

All of your resources are apparently described as generic resources, i.e. 
you use "Resource" as the root element.  Typically, one would describe 
them using one of the Resource sub-classes.  

Assuming these are all tables from the catalog service, you can register 
them as a TabularSkyService (defined in VODataService).  This subclass 
included additional elements that can describe coverage.  For example, 
catalog I/100A/w10 would be described like this:

<vs:TabularSkyService xmlns="http://www.ivoa.net/xml/VOResource/v0.9">
   <Identifier>
      <AuthorityID>CDS</AuthorityID>
      <ResourceKey>VizieR/I/100A/w10</ResourceKey>
   </Identifier>
   ...
   <vs:Coverage xmlns="http://www.ivoa.net/xml/VODataService/v0.4">
      <Spatial>
         <AllSky/>
         ...
      </Spatial>
   </vs:Coverage>
   ...
</vs:TabularSkyService>

You can also describe the service interface.  How you do that, depends on 
the type of service you are registering.  (You will see ConeSearch 
and SIA examples in my example file.)  One simple way for you might be to 
try registering it as a "GLUService."  This is done like this:

   <Interface>
      <Invocation>GLUService</Invocation>
      <!-- AccessURL gives the URL to the GLU record describing the 
           service -->
      <AccessURL>...</AccessURL>
   </Interface>

Let me know if any of this does not make sense, and I will advise
more.  

> * Last question for now, how do we deal with mirrors/clones?
> Should we copy this repository on all vizier clones, so that people 
> can harvest on any vizier site?

My short recommendation is that for the purposes of Jan demos would be
to register only the CDS Vizier site.  The issue of mirrors is a
largely under-developed area at the moment. 

Currently, the state is this:

  * An AccessURL may transparently choose an appropriate mirror; this 
      would typically be the case for mirrors that are all managed by a 
      single organization.  In this case, the resource and its mirrors are 
      registered once with a single record.  Otherwise, ...

  * Every mirror of a is registered separately, each with its own unique 
      identifier.  Descriptions of mirrors include the following:  

      <RelatedResource>
         <Relationship>mirror-of</Relationship>
         <RelatedResource>
            <!-- the resource being mirrored -->
            <Identifier>
               <AuthorityID>CDS</AuthorityID>
               <ResourceKey>...</ResourceKey>
            </Identifier>
         </RelatedResource>
      </RelatedResource>

      You can also (optionally) include a LogicalIdentifier that is
      shared by the original and all its mirrors.  It can be the same
      as the original's identifer, but it is not required.  It might
      look like this:

      <LogicalIdentifier role="mirror">
         <AuthorityID>CDS</AuthorityID>
         <ResourceKey>VizieR/I/100A/w10</ResourceKey>
      </LogicalIdentifier>

      Thus, if you request records where the <Identifier> equals the
      above, you only get the original resource.  However, if you ask
      for records where <LogicalIdentifier> equals the above, you get
      the original and all its mirrors.  

thanks for the update!
Ray