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

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?

• 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.

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
 
 
-->

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

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?
• 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.

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
 
 
-->