another lookup problem
- Previous message (by thread): another lookup problem
- Next message (by thread): another lookup problem
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Wilfried Woeber, UniVie/ACOnet
woeber at cc.univie.ac.at
Thu Jul 18 14:54:09 CEST 1996
Hi David & DB folks ! >What happened: > >The software first searches for 'U. Schaefer' and cannot find anything. >Then it breaks up the 'U. Schaefer' in the following fields: > >U (trailing dots are discarded) >Schaefer > >the U key is discarded because it is too small (for a good reason) As much as I remember, this is in line with a recommendation from the DB-WG. >... >Short discussion: > >- U. Schaefer > > Names likes this will be rejected in the next release of the updating > code. Names should consist of at least two parts, not counting > abbreviated parts/titles. Good stuff. But I think we should try to weed out offending things before (or in parallel) with the introduction of this more stringent checks. I think we add just another level of complexity and user confusion if we don't... >- The inetnum object is incorrect: It references a non-existing person > object. This will not happen in normal circumstances. The new (not yet > deployed) updating code will disallow (most) non-existing references. Hmmm.... What about allowing an update but issuing a warning? And the other way 'round - issue a warning if an object which is still referenced gets removed. I'm not sure whether it makes sense to *sometimes* enforce link sanity and to allow for breaking them later (e.g. with a delete for the referenced object). Maybe that's just some aspects for a (hypothetical) package of sanity checks that might be activated regularly or upon request. >- the software should have found 'U. Schaefer' if the object existed (and > nothing more, see algoritm above) > >- I can change the indexing in such a way that that trailing dots are > indexed. However, this might be worse then the problem: accidental dots > after names cause the generation of different keys from the objects > where the dots are left out and thus objects that are obvious the same > are not seen as such anymore (by the software). I don;t think that we should make software chages to accomodate syntax errors. In a lot of different documents, the syntax for a person object is cleraly defined: name [initials] name - the initials to be registered without a trailing dot. At the same time titles and gender specific local language "syntactic sugar" is not allowed. Not sure whether there's a chance to guard against the proliferation of "Herr", "Frau", "Professor" etc... ~~~~~~ WRT "fuzzy" / wildcard matches - it would make the RIPE-DB software more user friendly (and maybe more attractive for deployment by other registries) to provide for (implicit/explicit) regexp or partial key matches. But I think that would be a major (conceptual) change and should be discussed, both technically and the human resources involved. Even if it might be easy to implement :-) Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------
- Previous message (by thread): another lookup problem
- Next message (by thread): another lookup problem
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]