<html><head></head><body>Hi Markus,<div><br></div><div>I agree with you about the two basic categories. The definition </div><div>you give is reflecting the situation.<div><br></div><div>But note that we have a two dimensional categorization, the first dimension is:</div><div><br></div><div>[a] RoR registry resource anomalies</div><div><i>Anomalies discovered when examining solely the representation </i></div><div><i>of registry resource records as made available by the RoR.</i></div><div><br></div><div>[b] Harvested registry resource anomalies</div><div><i>Anomalies discovered when examining the registry resource records </i></div><div><i>as harvested from their respective publishing registries (and not as made available by the RoR)</i></div><div><br></div><div>[c] RoR - harvested registry records discrepancies</div><div><i>Discrepancies between the registry resource records as made available </i></div><div><i>by the RoR and as harvested by their respective registries</i></div><div><br></div><div>[d] Sui generis anomalies</div><div><i>Anomalies not falling into one of the other categories</i></div><div><br></div><div>and the second dimension:</div><div>[i] anomaly </div><div>[ii] warning</div><div><br></div><div><br></div><div>I think that as the word "anomaly" is stronger than what we want to title, </div><div>we could consider the word "inconsistency" but in any case it should be </div><div>abstract enough to fit with all reports.</div><div><br></div><div>What do you think? </div><div><br></div><div>Thanks again,</div><div>Costas</div><div><br></div><br><div>-- </div><div>___________________________________________________________________</div><div>Costas Vrioni</div><div>NEUROPUBLIC Information Systems & Technologies S.A. </div><div>email: k_vrioni@neuropublic.gr </div><div>web : http://www.neuropublic.gr </div><div>phone: (+30) 216 200 9882</div><div>phone: (+30) 210 4 10 10 10 ext:3882 </div><div>addr.: 6 Methonis Str, 185 45, Piraeus, Greece</div><div><div style="margin: 5px;"><img src="cid:8465d259-72b5-40cf-b929-5132537a6412.jpg"></div></div><div>___________________________________________________________________</div><br><br><br><div><strong>
From:
</strong>
Markus Demleitner <msdemlei@ari.uni-heidelberg.de>
<br>
<strong>
To:
</strong>
<registry@ivoa.net>
<br>
<strong>
Sent:
</strong>
3/15/2017 6:37 PM
<br>
<strong>
Subject:
</strong>
Re: New report feature for EuroVO Registry
<br><br><blockquote class="mori" style="margin:0 0 0 .8ex;border-left:1px solid #CCC;padding-left:1ex;">Hi Costas,
<br>
<br>On Tue, Mar 14, 2017 at 06:33:50PM +0200, Kostandin Vrioni wrote:
<br>> I understand that some of these "anomalies" are not actually anomalies.. and we are thinking to not remove but to consider them as "warnings".
<br>>
<br>>
<br>> I have grouped them as follow:
<br>>
<br>>
<br>>
<br>> Registry Anomalies Report
<br>>
<br>>
<br>> RoR registry resource anomalies
<br>> ROR-01 :: Common managed authority
<br>> ROR-02 :: Common managed authority prefix
<br>
<br>That should be a warning only -- there may be legitimate reasons for
<br>doing this.
<br>
<br>> ROR-03 :: Identical critical registry info
<br>> ROR-04 :: Same (case-insensitive) registry IVOA identifier
<br>> ROR-05 :: Same (case-insensitive) registry title
<br>> ROR-06 :: Same (case-insensitive) registry short name
<br>> ROR-07 :: Malformed OAI-PMH access URL
<br>> ROR-08 :: Same (case-insensitive) registry access URL
<br>> ROR-09 :: Same (URI-based check) registry access URL
<br>> ROR-11 :: A registry is not declared as a harvestable registry
<br>
<br>Again, there are legitimate reasons for that, so that should be a
<br>warning at worst.
<br>
<br>> ROR-16 :: Duplicate managed authority in RoR
<br>>
<br>>
<br>> RoR registry resource warnings
<br>> -> ROR-10 :: A registry doesn't contain a 'shortName' field
<br>> -> ROR-12 :: XSD-invalid RoR registry resource
<br>
<br>That I'd promote to a "full anomaly", as that can have potentially
<br>very bad consequences.
<br>
<br>> -> ROR-13 :: Identifier in OAI-PMH namespace
<br>> -> ROR-14 :: Title in OAI-PMH namespace
<br>> -> ROR-15 :: Short name in OAI-PMH namespace
<br>
<br>I suppose all of these are the consequence of the same thing (binding
<br>the oai namespace URI to the emtpy namespace). I'd predict these
<br>always turn up together, so I'd say it's ok to just test ROR-13 and
<br>just remove the other two tests.
<br>
<br>> Harvested registry resource anomalies
<br>> HRV-01 :: Common managed authority
<br>> HRV-03 :: Identical critical registry info
<br>> HRV-04 :: Same (case-insensitive) registry IVOA identifier
<br>> HRV-05 :: Same (case-insensitive) registry title
<br>> HRV-06 :: Same (case-insensitive) registry short name
<br>> HRV-07 :: Malformed OAI-PMH access URL
<br>> HRV-08 :: Same (case-insensitive) registry access URL
<br>> HRV-09 :: Same (URI-based check) registry access URL
<br>>
<br>>
<br>> Harvested registry resource warnings
<br>> -> HRV-02 :: Common managed authority prefix
<br>> -> HRV-10 :: A registry doesn't contain a 'shortName' field
<br>> -> HRV-11 :: A registry is not declared as a harvestable registry
<br>
<br>Agreed.
<br>
<br>> Do you agree on this approach? Any suggestion will be welcomed!
<br>
<br>Well, I'd like to work out an operational definition for "anomaly
<br>[sc. message]" and "warning". How about:
<br>
<br>:anomaly:
<br> indicates that some element of the Registry will probably
<br> fail for some subset of records
<br>
<br>:warning:
<br> indicates that a Registry operator may have inadvertantly expressed
<br> something that, while by itself perfectly legal, may not match what
<br> they have intended.
<br>
<br>Written like this, I'm not sure I like the term "anomaly" a lot and
<br>would perhaps like to upgrade it to something that is obviously
<br>stronger than "warning". Hm.
<br>
<br>But would you agree with the two basic categories, regardless of
<br>terminology?
<br>
<br> -- Markus
<br></blockquote></div></div><BR />
<BR />
<a href="http://www.neuropublic.gr/el/disclaimer"><font size="2"><b>Αποποίηση ευθυνών / Disclaimer</b></font></a><BR />
</body></html>