|
META TOPICPARENT |
name="RelationalRegistryDM" |
Discussion on Registry Interfaces Version 2 |
|
< < | There is an internal working draft at http://docs.g-vo.org/ridraft. |
> > | The current draft for a schema letting people query the registry via TAP |
|
> > | ("RegTAP") is at
https://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). |
| |
|
< < | 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). |
| |
|
< < | 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
(you're welcome to add your own...) |
|
< < |
- Is this thing just too complex to be implemented by the current workforce-strapped registries?
|
> > |
- 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?
<--
-->
META FILEATTACHMENT |
attachment="createtables.sql" attr="" comment="non-vendor-specific CREATE TABLE statements that implement DM's proposed model" date="1353097332" name="createtables.sql" path="createtables.sql" size="5262" user="RayPlante" version="1" |
|