Discussion on Registry Interfaces Version 2

RegTAP material

RegTAP is now in RFC. Any further discussion on RegTAP goes there.

The source is maintained in volute, http://volute.googlecode.com/svn/trunk/projects/registry/regtap -- feel free to fix things.

Also: There is now a validation suite; see http://svn.ari.uni-heidelberg.de/svn/gavo/regtap-val

There is 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]

A script for generating the schema for MySQL servers (requires version 5.6-4 at least, due to indexing solutions) is available here. Based upon the 2013-03-05 draft it includes also example UDF functions in MySQL scripting language. (M.Molinaro - 2013-04-10)

All this is an attempt to fulfill RestfulRegistryInterfaceReq.

See also Notes from the RegTAP talk at the Heidelberg Interop.

Related Material

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.

Requests for discussion/TODO

This is a list of questions Markus would appreciate input on. Feel free to add discussion points yourself as you see fit.

Please do comment in particular if you disagree with Markus' preference.

  • Add strict non-null conditions (rather than and/or in addition to the milder conditions currently imposed by the shoulds on primary and foreign keys)?
    • Pro: In-DB validation might lead to less junk users have to cope with; also, non-null conditions might help implementors
    • Con (Markus' Favourite): don't require anything. What's valid is defined by VOResource anyway, but if people can ingest slightly invalid data without breaking, why punish them (by declaring them in violation of the spec)?
  • 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 (Markus' Favourite): 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. Also, there's the question of namespace management: Require namespace declarations in all records? Allow them? Forbid them?
  • Should we have a table mapping prefixes to namespace URI, i.e., a canonical 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?
    • Pro: clients can do schema discovery this way, FWIW; such data is necessary at least during OAI processing anyway. Also, it's a nice analog to the xmlns declaration in XML documents
    • Con: These mappings are largely static and are amended fairly slowly. Also note that it is intended that there are going to be multiple URI for a prefix (e.g., vs: already has two), so such a table is less straightforward than you may think

Topic attachments
I Attachment Action Size Date Who Comment
Unknown file formatsql RegTAP_MySQL_schema.sql manage 25.1 K 2013-04-10 - 09:43 MarcoMolinaro MySQL (5.6-4+) flavoured schema creation, based on 2013-03-05 draft
Unknown file formatsql createtables.sql manage 5.1 K 2012-11-16 - 20:22 RayPlante non-vendor-specific CREATE TABLE statements that implement DM's proposed model
Topic revision: r18 - 2014-03-14 - MarkusDemleitner
This site is powered by the TWiki collaboration platformCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback