|
META TOPICPARENT |
name="RelationalRegistryDM" |
Discussion on Registry Interfaces Version 2
The current draft for a schema letting people query the registry via TAP ("RegTAP") is at http://docs.g-vo.org/ridraft (also as PDF). The source is maintained in volute, http://volute.googlecode.com/svn/trunk/projects/registry/regtap -- feel free to fix things.
Here's a draft set of (non-vendor-specific) CREATE TABLE statements that define the schema: createtables.sql (RP - 2012-11-16). [Warning: this reflects the draft as it was then; the current draft has some relatively minor) changes -- MarkusDemleitner - 2013-03-05]
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.
There is also a rough draft on representing STC coverage information alongside the more general metadata in http://volute.googlecode.com/svn/trunk/projects/registry/RegTAP-STC. This is suspended since there is a sentiment is that spatial coverage should use MOCs rather than bounding boxes, but we don't quite know yet how to do that.
All this is an attempt to fullfil RestfulRegistryInterfaceReq.
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?)?
|
> > |
- #-tag lists: should be explicitly mentioned in the specification ( resource.content_level can be #-tagged, but what about creator_seq?)?
|
|
> > |
-
- creator_seq is a different beast (it's ordered and mainly for presentation purposes; are there other places in which it's unclear if there can be hashes? -- MarkusDemleitner - 2013-03-13
- Should we have a table mapping prefixes to namespace URI, i.e., a canoical place in which clients can figure out that vr on a particular site means http://foo.bar/v1 rather then http://bar.foo/v2, and so on for vs:, vg:, etc? -- MarkusDemleitner - 2013-03-13
|
|
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?
<--
-->
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" |
|