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 that is interested in harvesting VO resource records is the NASA ADS. It wants to 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

---

I tend to like the idea of dropping getRegistries() now. I think it might be easier just having our OAI listRecords (and Sets if we decide to support Sets) return vg:Registry types that it knows about. I think clients might like the idea as well that all they need to call is one OAI method such as ListRecords and will automatically get Registry types.

-- KevinBenson - 31 Mar 2005

Could you clarify this a bit? Currently, ListRecords returns just the records that originate with that registry; thus, this would not include other registrys' vg:Registry records. If we have sets and allow all records to be returned, then you would get all the vg:Registry records known. However, this would be a small minority of the records returned and the client would have to filter them out. Were you thinking of a different behavior?

I agree there are other ways besides getRegistries() to get all known Registry records; however, there is no way to find out specifically which ones are being harvested from. It could be all the ones it knows about, but it may not be. Perhaps this is splitting hairs.

-- RayPlante - 31 Mar 2005

---

Resolved: The decision to set up an IVOA-sponsored registry of registries makes a getRegistries() function (in the context discussed above) superfluous. Thus, it will be removed from the standard.

-- RayPlante - 05 May 2005