International Virtual Observatory Alliance

Difference: RI2Discussion (8 vs. 9)

Revision 92013-03-04 - MarkusDemleitner

  META TOPICPARENT 
  name="RelationalRegistryDM"  

 Discussion on Registry Interfaces Version 2
- META TOPICPARENT
+  name="RelationalRegistryDM"
-<
<
+The current draft for a schema letting people query the registry via TAP ("RegTAP") is at http://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).
->
>
+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).
-<
<
+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 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.
->
>
+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 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 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?)?
 
 

 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?
 
<-- 
 
 
 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->




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

View topic | History: r18 < r17 < r16 < r15 | More topic actions...