Registry Interface Working Draft Discussion Topic

Should we drop getRegistries() or redefine it?

As it is currently define, getRegistries() returns all registries that the registry knows about. Because you can get this information via a simple ADQL-based search, there is a suggestion to drop it from the standard. However, there is a related piece of information that is not strictly available, and that is the list of the registries that the searchable registry harvests from. Since this is not necessarily the same as "all the registries it knows about", there is no other way to get this information.

So as an alternative to dropping getRegistries(), we would make it a part of the harvester interface (or searchable interface; see HarvesterInterface discussion) and have it return a listing of the registries that it harvests from. This would allow other registries to discover where it they should harvest from if they want the same contents.

One group client interested in harvesting VO resource records is the NASA ADS. It want's incorporate this information into its abstract database. They have expressed an interest in discovering harvestable registries using OAI only. This would presumably be done with Sets. So as a follow-up question, should we define a special set that returns the same thing as our revised getRegistries()?


If you have an opinion, question, or comment about this topic, feel free to append your discussion below. Be sure to indicate your name as the author.

I support redefining getRegistries(). In addition, I think we should look at ways to incorporate this functionality into the OAI interface as well using sets, but I think that it needs some prototyping before we attempt to include it; let's not target the OAI part for RI 1.0.

-- RayPlante - 30 Mar 2005




Edit | Attach | Print version | History: r5 | r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r1 - 2005-03-30 - RayPlante
 
This site is powered by the TWiki collaboration platformCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback