RegTAP 1.1 reference implementation feedback (from 'full' registry)

[Theresa Dower]

Just some small feedback for the RegTAP 1.1 reference implementation I have been working on at STScI, on-list for the sake of transparency.


We currently have an implementation of RegTAP 1.1 running on a publicly available test server, it should able to be operational before the May 2019 Interop. (I'd like to see it out the door before May.) I am also taking the opportunity to start with a clean slate and re-ingest all the RofR contents from scratch, and to make some fixes for the ongoing RofR validation project. We have had no issues with the schema changes: we've ingested CADC records with multiple security methods and updated some of our own records to include alternate identifiers where appropriate. The 'preferred' vocabulary changes in date/@role and relationshipType have been trivial to implement in code. Everything looks good!*


There is one caveat about the vocabulary changes as the maintainer of a full searchable registry:


A full searchable registry by definition provides access through standard search interfaces (in this case RegTAP) to resources harvested from other registries in the RofR. By general agreement, the harvesting registry does not change the content of these resources (except in validationLevels) on ingest, and will return them through at least the OAI interface as found through their home registry OAI interface. While the full registry can update its own ivo_managed set records to match the new preferred vocabulary, we will, as long as this is a minor version change, be serving records in a mixed state. This leaves three choices:


  1.  alter the incoming records to match new vocabulary, even for OAI etc. (No).
  2.  don't update to this part of the standard. (No.)
  3.  share all records via the RegTAP interface with the new vocabulary mapping, even though it may not necessarily match the content shared via the OAI interface.

I and Markus as the author are in agreement that the best thing for a full registry to do is the latter. While RegTAP as a standard doesn't reference any of the other interfaces specifically, it would be nice to have a sentence or so that RegTAP as a mapping and an interface may not match in content (just controlled vocabularies?) with representations of the data provided by other interfaces.

That's it!  Comments welcome. Generally everything looks on track, hopefully we can put this to RFC in May.


--Theresa




(*Note: we do not have ADQL 2.1 'ILIKE' support yet but it is trivial to add as a patch on our version of Gregory Mantele's taplib project ADQL parser, as, for once, it fits our underlying database SQL dialect more easily than some others. I am expecting to also have this feature complete by the interop, even if the main branch of the library's ADQL 2.1 support is not entirely finished. 'ILIKE' is the only feature of ADQL 2.1 needed for RegTAP 1.1)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20190404/0e8f349e/attachment.html>