Registry Interfaces 1.1 - drafts post-Stellenbosch

[Markus Demleitner]

Hi all,

On Tue, May 24, 2016 at 03:46:15PM +0000, Theresa Dower wrote:
> > What changes do you have in mind?  As far as I can see, we'd only
> > need to change some text annotation.   Essentially, the second
> > annotation on vg:Registry right now says:
> 
> It's mostly text annotation, but when we get to search, there's
> xquery-specific definitions including an enumerated type which
> should either be expanded or removed (especially since the xquery
> search is no longer described in the most current version of the RI
> document), plus the whole concept of the TAP capability as you've
> illustrated below.

I'm against removal, as that would be an incompatible change that
would, by the book, require changing the namespace.  My take is that
it doesn't hurt.  Changing the annotation to "this is no longer used
for modern discovery, and xquery was explored in 1.0 but dropped for
2.0" should IMHO suffice.


> * We need to allow for RegTAP capabilities to count as searchable -
> but not exclude existing XQuery.

I'd say if there's an (possibly auxiliary) TAP capability, it counts
as searchable.

There is a dark spot, though: How would the RofR know if it's RegTAP
rather than, say, some custom schema containing registry data?

Current wisdom says "check the content of
capability/dataModel/@ivo-id".  As I've said in other places, I'm no
longer a big fan of that; I'm now convinced that having dataModel in
the capability is a misdesign inspired by the first use case,
ivoa.obscore, that, with its fixed name, could indeed  be considered
a property of the service (or the capability).

But really, conformance to a data model is a property of a table or a
schema.  EPN-TAP (that can contain several "instances" of data model,
i.e., schemas containing EPN-TAP) painfully shows that: the dataModel
element just isn't good enough to let clients discover where these
EPNTAP tables sit.

And for the discovery of RegTAP services, it's again painful, because
the auxiliary capability won't have the dataModel element, so you'd
have to go through relationship to the main capability to figure out
the dataModel.

Now, if we can agree that data model conformance is a property of the
schema, the problem miraculously solves itself: You'll use the
tableset of discovery.  Since VODataService's tableset//* don't give
dataModel, we can use what was originally intended for data model
annotation: utypes.  Unfortunately, RegTAP was written in the midst
of The Big Utype Schism and so the utypes defined there aren't really
useful for discovery.  This should be fixed at some point (my
personal opinion: treat the schema and table utypes like standardID
on capabilities, i.e., put in full URIs, as Norman has said all
along).  Until then we can exploit the fact that RegTAP fixes  the
table names and say:

  A RegTAP service should be discovered by looking for
  vg:Registry-typed resources having a (possibly auxiliary) TAP
  capability and a tableset containing a table rr:resource.  The
  capability/dataModel-based discovery suggested in an example in the
  RegTAP document should not be used any more, as it is difficult to
  write a query against capability/dataModel that correctly takes
  into account auxiliary TAP capabilities.

While my doubts whether capability/dataModel was a good idea in the
first place could be added to motivate the discontinuation of its
use, but for now I feel that RI is not the right place for this.

> * We need to allow for RegTAP capabilities to NOT count as "full"
> -- ROE wants to add RegTAP to their general TAP services since
> they've also got a registry anyway and this is reasonable enough to
> allow.
> * Therefore we need a way to mark "full" searchable without relying
> on xQuery OR the existence of a RegTAP service.

The vg:Registry/full element should do the trick here, no?

> SO:
> * (This goes in a new optional vg:Registry element)  OR
> * (change to searchable to allow RegTAP capability/tableset AND
> some optional 'full'ness element is added) OR
> * (Something with #aux that I don't understand) ?

Ouch!  You're of course right.  vg:Registry doesn't admit a tableset
element right now.

So, yes, we should definitely allow vs:Tableset in there, which means
that the schema indeed needs to be changed, so we'd have VORegistry
1.1.  That would still work with the old namespace (because tableset
must be optionsl -- we don't want publishing registries to invent
something here).

Going all the way to a new namespace (which would also allow cleaning
out the cruft) I'd still consider expensive, although perhaps the
number of clients actually looking for elements in the
http://www.ivoa.net/xml/VORegistry/v1.0 might be small.  Google shows
an unnerving number of matches for a phrase search for it, though, so
I'd rather not wantonly change it.

Cheers,

         Markus