Late RegTAP rr.interface update [was: rr.interface+auth=ouch]

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Tue Apr 16 09:31:57 CEST 2019


Hi Pat,

On Mon, Apr 15, 2019 at 08:31:47AM -0700, Patrick Dowler wrote:
> A side issue: we have had what I think are under-informed discussions about
> what services actually implement and which securityMethod(s) are actually
> in use in the past. That started from "don't need to register all the

I'm pretty sure there simply haven't been any securityMethods defined
for many years (except for, IIRC, some astrogrid VOSpace that's now
disappeared) in records that made it to the VO Registry.  

I know that because RegTAP 1.0 (optionally) mapped securityMethod to
the

/capability/interface/securityMethod/@standardID

rr.res_details key.  RegTAP 1.1 still lets you do that, and
http://dc.g-vo.org/tap (for instance) does.  So, you can run

  select * 
  from rr.res_detail 
  where detail_xpath like '%securityMethod%'

and see what's there.

> interface/securityMethod combinations" and would continue if we didn't
> capture the set of securityMethod(s) that services used in RegTAP. Then
> later on we either can or cannot use RegTAP to see what's actually in use,
> depending on what gets captured in the relational mapping. I think we will
> want that information in the future.

So do I; but for this kind of research, we can always just locate the
records that have nonempty securityMethods and pull their full
records from an OAI-PMH endpoint.  At least until we've figured out
what to do with this information on the client side (and, more
critically, what information that is), I don't expect there's going
to be prohibitively many such records.

I guess my point is that I feel "research-level statistics" isn't
quite a sufficient use case for mapping something into RegTAP
("operational statistics" might be a different matter, though).

         -- Markus


More information about the registry mailing list