ownedAuthority element

[KevinBenson]

I will think about that scenario some more, Ray, but I think it is a little
overkill.

I would suggest that we try to keep this a little more simpler, just replied
to Matthew's e-mail that possibly we don't actually require a Registry to be
managed by a Full Registry.  But simply recommend it for now.  Once a
Registry performs a harvest and discovers it harvested a Registry with
particular "managing authority id" then it should simply just know that it
does not need to go to the smaller publishing registry to do the harvest.
But even that I think we don't have to restrict, if desired a Full Registry
may go more to a Flat model and just harvest every Registry type it has.

Cheers,
Kevin

-----Original Message-----
From: owner-registry at eso.org [mailto:owner-registry at eso.org]On Behalf Of
Ray Plante
Sent: 05 April 2005 19:51
To: Registry List
Subject: Re: ownedAuthority element


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