(r2) RI2Discussion < IVOA

IVOA Web>IvoaResReg>RegistryInterface>RestfulRegistryInterfaceReq>RelationalRegistryDM>RI2Discussion (revision 2) (raw view)~~EditAttach~~

---+ 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?
      * 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?
<!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->

Topic revision: r2 - 2012-09-20 - MarkTaylor

IVOA

Log in or Register

IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics

Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki

TWiki intro
TWiki tutorial
User registration
Notify me

Working Groups

Interest Groups

Time Domain

Committees

Stds&Procs

www.ivoa.net
Documents
Events
Members
XML Schema