New report feature for EuroVO Registry

[Kostandin Vrioni]

Dear Markus, all,



Thank you Markus for these very interest suggestions!


I understand that some of these "anomalies" are not actually anomalies.. and we are thinking to not remove but to consider them as "warnings".


I have grouped them as follow:



Registry Anomalies Report


RoR registry resource anomalies
ROR-01 :: Common managed authority
ROR-02 :: Common managed authority prefix
ROR-03 :: Identical critical registry info
ROR-04 :: Same (case-insensitive) registry IVOA identifier
ROR-05 :: Same (case-insensitive) registry title
ROR-06 :: Same (case-insensitive) registry short name
ROR-07 :: Malformed OAI-PMH access URL
ROR-08 :: Same (case-insensitive) registry access URL
ROR-09 :: Same (URI-based check) registry access URL
ROR-11 :: A registry is not declared as a harvestable registry
ROR-16 :: Duplicate managed authority in RoR


RoR registry resource warnings
-> ROR-10 :: A registry doesn't contain a 'shortName' field
-> ROR-12 :: XSD-invalid RoR registry resource
-> ROR-13 :: Identifier in OAI-PMH namespace
-> ROR-14 :: Title in OAI-PMH namespace
-> ROR-15 :: Short name in OAI-PMH namespace


Harvested registry resource anomalies
HRV-01 :: Common managed authority
HRV-03 :: Identical critical registry info
HRV-04 :: Same (case-insensitive) registry IVOA identifier
HRV-05 :: Same (case-insensitive) registry title
HRV-06 :: Same (case-insensitive) registry short name
HRV-07 :: Malformed OAI-PMH access URL
HRV-08 :: Same (case-insensitive) registry access URL
HRV-09 :: Same (URI-based check) registry access URL


Harvested registry resource warnings
-> HRV-02 :: Common managed authority prefix
-> HRV-10 :: A registry doesn't contain a 'shortName' field
-> HRV-11 :: A registry is not declared as a harvestable registry


RoR - harvested registry records discrepencies
ROR-HRV-1 :: Registry in DB but not in RoR
ROR-HRV-2 :: OAI-PMH / RoR registry info discrepancy


Sui generis anomalies
SG-1 :: OAIPMH protocol failure
SG-2 :: OAIPMH duplicate set
SG-3 :: OAIPMH no ivo_managed set
SG-4 :: OAIPMH no data in ivo_managed / ivo_vor combo


(More info on site: http://registry.euro-vo.org/eurovo/eurovo/download_reports_service?key=s_ra_201703.html )


Once we agree on grouping I will update the identifiers in correct sequence (e.g. ROR-11,ROR-16..).


Do you agree on this approach? Any suggestion will be welcomed!


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/20170314/65e56aaf/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/20170314/65e56aaf/attachment.jpg>