RI 1.1: Stand-alone records for non-RI1.0 searchable registries

[Theresa Dower]

Hello all,

To piggy-back on Markus' message, there is a new version of the RI 1.1 working draft, available at http://www.ivoa.net/documents/RegistryInterface/20161107/. 

It addresses 
* keeping the SOAP-based RISearch schema in the document as an appendix for backward compatibility, while noting its implementation in new registries is discouraged
* The issue which came up in Trieste that (and why) the RofR does not actually automatically determine 'full search' or 'publishing' registries but requires registration as a publishing registry and then human contact to the RofR maintainer. Assuming this was done automatically was a misconception on my part regarding Ray Plante's RofR implementation. It does free us from having to find a very ugly way to determine this programmatically, at least.
* not guaranteeing all standards will be in the RofR (again, an issue which came up in Trieste)
* a handwavey overview of Markus' #aux / TAP solution here (I wrote it before this email, and it can be adjusted)
* various editorial fixes.

As always, I'd appreciate feedback on the whole thing, but if there are specifically any issues with the bullet points above, that would be the most help for the smallest effort!

--Theresa

-----Original Message-----
From: registry-bounces at ivoa.net [mailto:registry-bounces at ivoa.net] On Behalf Of Markus Demleitner
Sent: Monday, November 07, 2016 10:30 AM
To: registry at ivoa.net
Subject: RI 1.1: Stand-alone records for non-RI1.0 searchable registries

Dear colleagues,

In Trieste we've discussed how to make "stand-alone" resource records for RegTAP services (and other searchable registries when they are defined).  Near the foot for this mail you'll find a short intro to the problem in case you didn't make it to the session.

Anyway, I've now updated my RegTAP registration to what's the current plan (I think) -- see 

http://dc.g-vo.org/oai.xml?verb=GetRecord&metadataPrefix=ivo_vor&identifier=ivo://org.gavo.dc/rr/q/create

Main features:

(1) vg:Registry-typed record (so you can easily search "all things Registry"); this is what's also used for publishing registries and the old, SOAP-RI1.0 searchable registries).

(2) a TAP auxiliary capability (which currently is good for saying "it's RegTAP all right") and lets you get the access URL.

(3) extra registry metadata (that's currently the <full>True</full> at the very bottom).

Yulie (in particular): do you think this kind of thing will work for your list of searchable registries?

And... PROBLEM.  I would really love to include the tableset into the record, i.e., the tables in the rr schema as implemented by the concrete service.  The main reason is that I think that's what future discovery should be based on: "Find RegTAP services by locating vg:Registry-typed records having a TAP capability and a schema named rr" (or, if people prefer, "a schema with some utype").

This would be particularly nifty when there are RegTAP extensions, in particular for space-time constraints; UIs could then figure our the support for extensions by looking at the tableset ("is there a table rr.coverage?").

Unfortunately, the VORegistry schema doesn't allow tablesets in vg:Registry records.  Since we're touching things, and this would be an optional addition and thus we could keep the namespace:  How does everyone feel about allowing vs:tableset in vg:Registry?

The only downside *I* can see is that VORegistry grows a dependency on VODataService.  I must have lost my So-What-O-Meter (for measuring how much I care about something) right now, so I can't say I'm worried, but neither that I'm not.  As a data point: RI 1.0 used to say it's linked to VOResource 1.0, so dependencies of this kind didn't blow everything up.

Opinions welcome.


Finally, the background (old hands can stop reading here): This is about discovering searchable registries.  The old, SOAP-based ones had a special capability for that (defined in Registry Interfaces 1.0 and its accompanying schema VORegistry a.k.a. vg), plus a corresponding standardID.  RegTAP, a newer standard for searchable registries, on the other hand, said: "Just look for a TAP service with a dataModel of ivo://ivoa.net/std/RegTAP#1.0" (where dataModel is a piece of metadata in the capabilities of a TAP service).

That's not good for a number of reasons.  A simple one is that the RofR wants to have a directory of searchable registries, and with this recipe it'll have things like "The GAVO DC TAP service" in that list, which is (at the very least) ugly.  And anyway, a searchable registry, even one queriable through a TAP service, is an entity of its own and thus has metadata of its own and thus should have a resource record of its own.

And that's why in the last RI 1.1 draft we propose to use TAP auxiliary capabilities (cf. the parallel thread on the discovercollections note) for creating vg:Registry records.

Cheers,

           Markus