RofR meeting notes
Markus Demleitner
msdemlei at ari.uni-heidelberg.de
Wed Dec 5 10:04:07 CET 2018
Hi Registry,
On Tue, Dec 04, 2018 at 07:32:04PM +0000, Theresa Dower wrote:
> From: Markus Demleitner <msdemlei at ari.uni-heidelberg.de>
> > On Wed, Nov 14, 2018 at 01:09:46PM -0500, Zografou, Panagoula wrote:
> > > - Should we re-harvest all registries, by-passing the validator?
>
> >The most important thing to check, I think, would be if a registry
> >claims someone else's managedAuthorities.
>
> something else) is a good thing, a good low and useful bar would be
> to periodically check the Identify record for validation and
> managedAuthority issues, with manual followup as Markus mentioned.
Well, of course the most important part of the re-harvesting is to
update the metadata in the RofR itself; as the other harvesting
registries in the VO, I suppose for the purposes of inferring that
> >> ["A Registry must return at least one resource record with
> >> ivo_ovr"]
> >>
> >I actually have an issue with this requirement (and it's still being
> >imposed) on searchable registries. For these, it may be perfectly
> >sensible to have an oai-pmh endpoint without any records of its own;
> >the ones associated with my RegTAP services are examples. I'd like
> >it a lot if only publishing registries were requried to actually have
> >at least one record.
>
> >Incidentally, I don't register these OAI-PMH endpoints for exactly
> >that reason.
>
> >> - Registry resource should have one capability with either xsi:type='vg:Search' or xsi:type='vg:Harvest'
>
> >That one should be dropped. RegTAP registries, for instance, can
> >perfectly work with just a TAP or auxiliary TAP capabilitiy.
>
>
> >> - ListRecords must include the record for the registry being tested.
>
> >That one should also only be enforced for publishing registries, not
> >of OAI endpoints of searchable ones.
>
>
> I'm either misunderstanding or disagreeing with a key point in this
> bit about RegTAP. IVOA registries are, on a fundamental level,
> built on the OAI-PMH design, and the concept of a searchable
> registry is built on top of a publishing one, whether it has any
Hm -- is it? As Registry Interfaces correctly says, OAI-PMH is not
suited for discovery-type searches, which is why we have come up with
RegTAP; and RegTAP works without having an OAI-PMH endpoint.
Of course, if you go into the trouble of harvesting all the records,
you might as well push them out again and so have an OAI-PMH endpoint
after all. But in that case what would be the point of having some
record of your own in there?
At least for me, the RegTAP service is registered in a (comparatively
small) publishing registry, and burdening the OAI-PMH endpoint
serving the records harvested from elsewhere with this record would
at least be inconvenient -- and I don't see a reason to.
> records beyond Identity (and associated authority and/or
> organisation, etc) of its own or not. Even a searchable registry
> with only RegTAP and basic OAI endpoints should have
> self-reflective resources (i.e. identify) for contact information,
Sure, they should be registered -- but why would they need to
self-register?
> vg:Harvest capability) in that case; a RegTAP query can't fully
> construct that XML resource. Are you arguing that those bookkeeping
> records don't count, or don't have to exist? Or does this come from
I'm arguing they don't have to exist *in the OAI-PMH endpoint* (i.e.,
the vg:Harvest capability) of the service itself. As long as it
exists in *some* publishing registry, it's fine -- and that means
that it's fine if a registry doesn't have any ivo_managed records.
To help diagnosing accidents, it might be a good idea to complain if
such a registry claims authorities.
-- Markus
More information about the registry
mailing list