Discussion on Registry Interfaces Version 2
There is an internal working draft at
http://docs.g-vo.org/ridraft.
You can access and edit the draft sources in volute,
http://volute.googlecode.com/svn/trunk/projects/registry/RegistryInterface
Here's a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema:
createtables.sql (
RP - 2012-11-16).
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?