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