Discussion on Registry Interfaces Version 2

The current draft for a schema letting people query the registry via TAP ("RegTAP") is at http://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

Questions discussed at the last interop are on http://docs.g-vo.org/talks/2012-sampa-ri2.pdf

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

• 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 we suggest to reserve ivo_% like schema names for IVOA standardized schemas?
    • Pro: clean schema identifications, avoid ivoa schema blow-up if all follow Obscore suggestion
    • Con: profliferation risks (plus I don't like fixed schema names, but it's my opinion -- MarcoMolinaro)
• 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 fragments?
  • 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 we highlight the impacts of the RDB solution on VO Resource data model (i.e. required/optional fields may need changes switching from XML to RDB implementation of the DM)
  • #-tag lists: should be explicitly mentioned in the specification ( resource.content_level can be #-tagged, but what about creator_seq?)?

Old discussion items

• 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) .
  • At least EuroVO will hopefully have a completely independent implementation; there are activities to at least mirror the ingested tables from other projects; for further activities, see this page (-- Markus Demleitner)
    • IA2 (INAF-OATs) is working at a mirror (dumped) of the GAVO relational registry (work in progress -- MarcoMolinaro)

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?