Discussion on Registry Interfaces Version 2

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: proliferation risks (plus I don't like fixed schema names, but it's my opinion -- MarcoMolinaro)
• 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?

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->