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

[Markus Demleitner]

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