ownedAuthority element

[Ray Plante]

Hi Kevin et al.

One misgiving I had with ownedAuthority/managedAuthority when we agreed to
it was that not only were we setting up a hierarchy in which some
registries were more important than others, but that with this tag, we
were building that hierarchy into our architecture when it seemed
unnecessary.  The other problem I see with these tags is that it is 
unclear to me how they would be used to determine which regional registry 
to harvest from.  

Ultimately what we're looking for is to be able to go to one registry per 
VO project (e.g. NVO) and be able to harvest all those and only those 
records that are associated with that project.  This is instead of going 
to the individual publishing registries where the records originated.  
(Note the multiple hops again ;-)  It is not necessary that there be only 
one such registry per project.  (If there were, could this be considered a 
single point of failure?)  Have I got the motivation correct here?  

I recommend the following alternative.  We define an optional standard set 
called (something like) "ivo_voproject" which returns all records that 
are associated with the registry's regional VO project (e.g. NVO, JVO, 
AstroGrid, etc.).  A full registry may choose to support this set if it 
wishes to represent its project in this way.  To make this work we need to 
put into place some additional infrastructure:

  1.  Each VO project should create an Organisation record that describes 
      the VO project.  This establishes an identifier for the NVO project, 
      AstroGrid, etc.  

  2.  We add the following information to the Registry resource metadata:
      a.  voProject:  the identifier of the VO project the registry wishes 
             to associate itself with.  
      b.  a piece of metadata that indicates whether it supports the
             "ivo_voproject" harvesting set.  

Here's a scenario of how this information would be used to do 
cross-project harvesting.  Imagine that a new regional VO project starts 
up called the Tobago Virtual Observatory (TVO).  

  1.  The TVO creates a full registry.  It creates an Organisation record 
      describing the TVO project.  In its Registry record, it sets 
      voProject to the identifier for the TVO project, and it indicates 
      that it supports the "ivo_voproject" harvesting set.  

  2.  The TVO full registry populates itself by grabbing all records from 
      any full IVOA-compliant registry in the world.  It discovers all 
      the other full registries that support "ivo_voproject" and 
      configures itself to harvest from them, one per VO project.  If more 
      than one registry can be used for a project, it sets up one as 
      preferred and others as fail-overs.  

  3.  Several publishing registries spring up in Tobago.  In their 
      registry records, they set voProject to the identifier for the TVO 
      project as well.  They call the TVO full registry's harvest() 
      function to tell it to start harvesting.  

  4.  Another full registry springs up in Tobago.  It also set voProject 
      to TVO and claims to support "ivo_voproject".  

  5.  The first full registry calls the NVO registry at STScI's harvest() 
      to tell them to get the TVO records. 

  6.  The STScI registry pulls the TVO registry's Registry record (via 
      the OAI Identify function).  STScI sees that it can represent 
      provide records for the entire TVO project; thus, STScI begins 
      harvesting using the "ivo_voproject" set.  It subsequently discovers 
      the 2nd full registry from TVO, so it sets it up as a fail-over 
      source.  

Of course, not everything above need be automated, and in a lot of cases 
it won't be.  Nevertheless, it provides a clear, scalable mechanism for 
harvesting by regional project.  

cheers,
Ray