<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p><br>
</p>
<p>As promised, bringing the resultant discussion from the RofR meeting to the rest of the list. <br>
</p>
<br>
<div style="color: rgb(0, 0, 0);">
<div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Markus Demleitner <msdemlei@ari.uni-heidelberg.de><br>
<b>Sent:</b> Monday, November 19, 2018 5:20 AM<br>
<b>To:</b> Zografou, Panagoula<br>
<b>Cc:</b> Janet Evans; Theresa Dower; Pierre Le Sidaner; Christophe Arviset; Kostandin Vrioni; Juan Gonzalez; Menelaos Perdikeas; Harbo, Peter<br>
<b>Subject:</b> Re: RofR meeting notes</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hi all,<br>
<br>
I suppose we could take some of these points to the registry mailing<br>
list for transparency (though I suppose the addresses of this mail<br>
cover about all the interested folks). Anyway, a few remarks from<br>
me:<br>
<br>
On Wed, Nov 14, 2018 at 01:09:46PM -0500, Zografou, Panagoula wrote:<br>
> - Should we re-harvest all registries, by-passing the validator?<br>
<br>
There's not much point running the whole enrollment procedure for<br>
every update. What needs to be done, though, is regularly<br>
re-harvesting the registry record itself. I *suppose* just going for<br>
what comes back from verb=Identify would be enough, but I'd really<br>
prefer trying verb=GetRecord&identifier=<registry-id>, as that<br>
would catch more subtle failures.<br>
<br>
If what's coming back there fails some basic validation, that's a<br>
reason for concern and should probably block updates to the RofR. <br>
<br>
So, I'm monitoring the publishing registries in the sense that<br>
each Wednesday, my harversters send me a mail what's currently<br>
broken, and after a couple of weeks of breakage I usually follow up<br>
manually. If the RofR could do a similar thing, that'd lighten my<br>
load.<br>
<br>
The most important thing to check, I think, would be if a registry<br>
claims someone else's managedAuthorities.<br>
<br>
> - Should we set a time by when all currently registered registries<br>
> must succeed validation and after that any new or updated<br>
> registries will be required to comply?<br>
<br>
While it would be useful to impress the importance of correct<br>
registry records on the operators, I suppose there's no real need to<br>
be heavy-handed. The searchable registries deal ok with the sorts of<br>
minor failures that are fairly common.<br>
<br>
I like Juan's proposal of sending, perhaps twice a year, a text<br>
version of the validation report to the contact addresses of the<br>
registries.<br>
<br>
> - For resource XSD validation, it was agreed to keep it and also<br>
> provide lower level errors like a stack trace. <br>
<br>
Is that really useful? We should, anyway, make sure the reports<br>
don't become even more hard to read than they already are.<br>
<br>
What I think would be helpful would be a reviving and reviewing the<br>
explanations for the various errors (the ones you get when you follow<br>
the links under the error codes; right now, examples look like<br>
<a href="http://rofr.ivoa.net/regvalidate/not_available.htm#OAIvalid" id="LPlnk508095" previewremoved="true">http://rofr.ivoa.net/regvalidate/not_available.htm#OAIvalid</a>). I'd<br>
volunteer for having a go at what *I* understand if you tell me where<br>
what's still there is.<br>
<br>
> - There is a discrepancy in some IVOA documents that causes some of<br>
> the XSD validation failures. Standards documents give examples of<br>
> ivo-id's that include a '#' but VOResource-v1.0.xsd or<br>
> VOResource-v1.1.xsd do not allow it, for example: <br>
> <br>
> <a href="http://ivoa.net/documents/SimpleDALRegExt/20170530/REC-SimpleDALRegExt-1.1.html" id="LPlnk410616" previewremoved="true">
http://ivoa.net/documents/SimpleDALRegExt/20170530/REC-SimpleDALRegExt-1.1.html</a><br>
> ivo://ivoa.net/std/SIA#query???2.0<br>
> <br>
> <a href="http://www.ivoa.net/documents/RegTAP/20180731/PR-RegTAP-1.1-20180731.html" id="LPlnk613342" previewremoved="true">
http://www.ivoa.net/documents/RegTAP/20180731/PR-RegTAP-1.1-20180731.html</a><br>
> <dataModel ivo-id="ivo://ivoa.net/std/RegTAP#1.1"<br>
> >Registry 1.1</dataModel><br>
<br>
These should be fixed in later versions or errata. If you find<br>
anything that's still wrong, let me know.<br>
<br>
> - A Harvesting Registry must return VOResource records when metadataPrefix=ivo_vor<br>
<br>
This should be "Publishing Registry", right?<br>
<br>
I actually have an issue with this requirement (and it's still being<br>
imposed) on searchable registries. For these, it may be perfectly<br>
sensible to have an oai-pmh endpoint without any records of its own;<br>
the ones associated with my RegTAP services are examples. I'd like<br>
it a lot if only publishing registries were requried to actually have<br>
at least one record. <br>
<br>
Incidentally, I don't register these OAI-PMH endpoints for exactly<br>
that reason.<br>
<br>
> - Registry resource should have one capability with either xsi:type='vg:Search' or xsi:type='vg:Harvest'<br>
<br>
That one should be dropped. RegTAP registries, for instance, can<br>
perfectly work with just a TAP or auxiliary TAP capabilitiy.<br>
<br>
> - ListRecords must include the record for the registry being tested.<br>
<br>
That one should also only be enforced for publishing registries, not<br>
of OAI endpoints of searchable ones.<br>
<br>
> - Recommend setting VOResource xsi:type='vs:CatalogService' on service with SimpleImageAccess capability<br>
<br>
This (and a few similar rules) might need to be dropped in the<br>
future, but for now it's fine.<br>
<br>
Thanks for looking into all this,<br>
<br>
Markus<br>
</div>
</span></font></div>
</div>
</body>
</html>