TWiki
>
IVOA Web
>
IvoaResReg
>
RegistryInterface
>
RestfulRegistryInterfaceReq
>
RelationalRegistryDM
>
RI2Discussion
(revision 11) (raw view)
Edit
Attach
---+ 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 [[http://docs.g-vo.org/ridraft/RegTAP.pdf][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: [[%ATTACHURL%/createtables.sql][createtables.sql]] ([[IVOA.RayPlante][RP]] - 2012-11-16). [Warning: this reflects the draft as it was then; the current draft has some relatively minor) changes -- IVOA.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_?)? * 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? -- IVOA.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? -- IVOA.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? <!-- * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup -->
Attachments
Attachments
Topic attachments
I
Attachment
History
Action
Size
Date
Who
Comment
sql
createtables.sql
r1
manage
5.1 K
2012-11-16 - 20:22
RayPlante
non-vendor-specific CREATE TABLE statements that implement DM's proposed model
Edit
|
Attach
|
Watch
|
P
rint version
|
H
istory
:
r18
|
r13
<
r12
<
r11
<
r10
|
B
acklinks
|
V
iew topic
|
Raw edit
|
More topic actions...
Topic revision: r11 - 2013-03-13
-
MarkusDemleitner
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
Applications
Data Access Layer
Data Model
Grid & Web Services
Registry
Semantics
Interest Groups
Data Curation
Education
Knowledge Discovery
Operations
Radio Astronomy
Solar System
Theory
Time Domain
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki?
Send feedback