New report feature for EuroVO Registry

[Kostandin Vrioni]

Dear Markus,



Thank you for your comments!


I will check them, especially the SG-1 and update the reports. 


Maybe some of them should be removed as they are not an "anomaly" 
(HRV-02, HRV-10) but an acceptable situation.  

I will let you know for the reports update.


Kind Regards,
Costas


-- 
___________________________________________________________________
Costas Vrioni
NEUROPUBLIC Information Systems & Technologies S.A. 
email: k_vrioni at neuropublic.gr 
web : http://www.neuropublic.gr 
phone: (+30) 216 200 9882
phone: (+30) 210 4 10 10 10 ext:3882 
addr.: 6 Methonis Str, 185 45, Piraeus, Greece


___________________________________________________________________



 From:   Markus Demleitner <msdemlei at ari.uni-heidelberg.de> 
 To:   <registry at ivoa.net> 
 Sent:   2/20/2017 4:48 PM 
 Subject:   Re: New report feature for EuroVO Registry 

Hi, 
 
On Mon, Feb 20, 2017 at 03:25:23PM +0200, Kostandin Vrioni wrote: 
> I would like to inform you about the new report feature of our 
> EuroVO Registry. The "Registry Ecosystem health report" which is a 
> public accessible report generated monthly and consist of three 
> types of reports: 
 
Great!  I like it. 
 
Now, on to fix what troubles are left: 
 
ROR-10, ROR-12, ROR-13, ROR-14, and ROR-15: This is a (single, known, 
minor) problem on the side of the RofR -- Yulie, can you perhaps 
already make promises on removing the binding of the empty namespaces 
in your oai containers? 
 
NRV-02: I'm not terribly worked up about common prefixes as 
Identifiers expliticly says that authorities are opaque.  Still, I 
admit these do not look like they were registered on purpose. 
Theresa, Costas: could you work these out between the two of you? 
 
HRV-10: Why are missing shortNames flagged as "anomalies"?  I admit 
that short names are generally useful in displays, but since there 
wasn't a consensus to make them mandatory in VOResource, we can't 
really point fingers if people leave them out, can we?.  Or am I 
missing something? 
 
HRV-11: At least for ivo://org.gavo.dc/rr/q/create I can say that the 
OAI interface is missing on purpose (it's our RegTAP endpoint, 
and while there is an OAI interface, it doesn't have any records of 
its own, which makes the RofR validator really unhappy).  These cases 
will become more frequent if Registry Interfaces 1.1 becomes REC as 
defined now.  So, I guess that's no longer an anomaly. 
 
ROR-HRV-1: There's several cases here.  ivo://org.gavo.dc/rr/q/create 
is discussed in HRV-11; the RofR probably can't really deal with 
these just yet.  I guess fixing this could be a criterion for the 
implementation of RI 1.1. 
The issue with ivo://org.gavo.dc/__system__/services/registry is my 
fault.  I'll look into it. 
 
ROR-HRV-2: I don't quite understand where these come from -- Yulie, 
could you comment? 
 
SG-1: I'm surprised to see most of the services in here (chivo-lirae 
is a known problem at this point, being worked on).  I wonder what 
went wrong there since I can't remember when last I found a 
whopping six registries down or severely broken.  What's the deeper 
meaning of _int.esa.esavo.common.PersistentHTTPConnectivityException? 
Perhaps there was a local issue? 
 
 
Summing up: Apart from SG-1, this is all fairly benign, and I must 
say for a distributed system like the Registry it looks pretty good. 
In particular, it's much better than a similar report would have 
looked a year ago.  And a fairly small fix at the RofR will make it 
still look better. 
 
Thanks to all who helped de-linting the Registry, and thanks to 
Costas for making this public. 
 
         -- Markus 


Αποποίηση ευθυνών / Disclaimer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20170223/59d93077/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8465d259-72b5-40cf-b929-5132537a6412.jpg
Type: image/jpeg
Size: 4320 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20170223/59d93077/attachment.jpg>