Discussion on Registry Interfaces Version 2

The current draft for a schema letting people query the registry via TAP ("RegTAP") is at https://volute.googlecode.com/svn/trunk/projects/registry/regtap/RegTAP-fmt.html; check out the directory this is in from volute to edit and fix things (which you're welcome to do).

Here's a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16).

There is a draft for a replacement of the Registry Interfaces specification at http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface; RegTAP used to be part of this, and while it's in development, work on Registry Interface itself is suspended.

See also RestfulRegistryInterfaceReq.

Topics the authors would particularly appreciate community feedback on:

Requests for discussion

(you're welcome to add your own...)

• Is this thing just too complex to be implemented by the current workforce-strapped registries?
  • Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor) .
• Is it really a good idea to have all role-like things in one table (res_role) rather than have creator, publisher, and contact information in separate tables?
  • Pro: You save between one and three tables, and it has a nice relational feel
  • Con: It's completely against VOResource; it may be a bit more inconvenient to query
• Should the tables live in the ivoa schema (like obscore)? Should they have a schema of their own (like right now)?
• Should footprint_ivoid and data_url go into res_details rather than being given a prominent place in the resource table?
• Should there be a required table containing VOResource XML?
  • Pro: many implementations that have an OAI-PMH endpoint will have such a table anyway, and certain classes of clients could use this kind of "all info in one" representation
  • Con: it "muddys the water", and it's a major implementation effort if you don't do OAI-PMH anyway; clients needing VOResource can always get the records using OAI-PMH.
• Should the node name going into the utypes be the type of the root element (i.e., vor:standard.endorsedVersion)? In general, that's certainly a bad idea (we don't want standard.curation, service.curation, authority.curation...), but maybe it makes sense for what's, e.g., in Standard but not in Resource?
• Do we want to require VO registries to have either day or seconds granularity (cf. http://www.openarchives.org/OAI/openarchivesprotocol.html#SelectiveHarvestingandDatestamps)?
  • Pro: It's kind of a pain to have to ask each time before harvesting.
• Do we want to talk about STC at all?
  • If this works, it can certainly cut down on the number of services to query -- for the current VO, that would be almost a precondition to make All-VO SCS queries feasible, and with SIAP and SSAP, we may be running into such a situation sooner or later, too.
  • It's an awful lot of work, and it's not clear at all many people would use such a facility anyway.
• Are there volunteers/is there an expectation that this will be implemented by more than one group? If not, the considerable effort of standardising it is of questionable value (-- MarkTaylor)

Requests for contributions

• Could someone mark up not NULL-constraints in the DB schema based on the XML schema?
• Who'd work with us in creating a validation suite?