New report feature for EuroVO Registry

Kostandin Vrioni k_vrioni at neuropublic.gr
Tue Mar 28 15:46:37 CEST 2017


Hi Markus,


I agree with you about the two basic categories. The definition 
you give is reflecting the situation.


But note that we have a two dimensional categorization, the first dimension is:


[a] RoR registry resource anomalies
Anomalies discovered when examining solely the representation 
of registry resource records as made available by the RoR.


[b] Harvested registry resource anomalies
Anomalies discovered when examining the registry resource records 
as harvested from their respective publishing registries (and not as made available by the RoR)


[c] RoR - harvested registry records discrepancies
Discrepancies between the registry resource records as made available 
by the RoR and as harvested by their respective registries


[d] Sui generis anomalies
Anomalies not falling into one of the other categories


and the second dimension:
[i]  anomaly 
[ii] warning




I think that as the word "anomaly" is stronger than what we want to title, 
we could consider the word "inconsistency" but in any case it should be 
abstract enough to fit with all reports.


What do you think? 


Thanks again,
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:   3/15/2017 6:37 PM 
 Subject:   Re: New report feature for EuroVO Registry 

Hi Costas, 
 
On Tue, Mar 14, 2017 at 06:33:50PM +0200, Kostandin Vrioni wrote: 
> 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 
 
That should be a warning only -- there may be legitimate reasons for 
doing this. 
 
> 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 
 
Again, there are legitimate reasons for that, so that should be a 
warning at worst. 
 
> 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 
 
That I'd promote to a "full anomaly", as that can have potentially 
very bad consequences. 
 
> -> ROR-13 :: Identifier in OAI-PMH namespace 
> -> ROR-14 :: Title in OAI-PMH namespace 
> -> ROR-15 :: Short name in OAI-PMH namespace 
 
I suppose all of these are the consequence of the same thing (binding 
the oai namespace URI to the emtpy namespace).  I'd predict these 
always turn up together, so I'd say it's ok to just test ROR-13 and 
just remove the other two tests. 
 
> 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 
 
Agreed. 
 
> Do you agree on this approach? Any suggestion will be welcomed! 
 
Well, I'd like to work out an operational definition for "anomaly 
[sc. message]" and "warning".  How about: 
 
:anomaly: 
  indicates that some element of the Registry will probably 
  fail for some subset of records 
 
:warning: 
  indicates that a Registry operator may have inadvertantly expressed 
  something that, while by itself perfectly legal, may not match what 
  they have intended. 
 
Written like this, I'm not sure I like the term "anomaly" a lot and 
would perhaps like to upgrade it to something that is obviously 
stronger than "warning".  Hm. 
 
But would you agree with the two basic categories, regardless of 
terminology? 
 
           -- Markus 


Αποποίηση ευθυνών / Disclaimer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20170328/be92a806/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/20170328/be92a806/attachment.jpg>


More information about the registry mailing list