V reakci na článek dr. Pinkase spatřuji problém, že v podobných případech není zřejmé, za které chyby může tvůrce systému a za které může nastavení v konkrétní knihovně. Uživateli je to ovšem jedno (nemůžete po něm chtít, aby to rozlišoval - "XXX je přece vynikající systém, jenom v této knihovně ho mají nešikovně nastavený"). Tedy očekával bych i odpověď z Národní knihovny.
"Současné nastavení v Národní knihovně se řídí výkladem normy ČSN pro řazení: znaky s primárním řadicím významem si při vyhledávání ponechávají původní hodnotu, znaky se sekundárním a terciárním řadicím významem jsou převáděny na základní podobu bez diakritiky."
Nevidím logiku v tom, proč se pravidla pro řazení použijí při vyhledávání. Jesliže uživatel hledá slovo "vír", nechce přece záznamy se slovem "vir"! Zajímalo by mne, kdo (jmenovitě) a proč o takovém nastavení rozhodl.

Jako systémová knihovnice NK ČR bych ke článku a zároveň odpovědi ing. Šimkové měla následující poznámky:

1/ Nápověda

Opravdu by mohla být lepší - děkujeme za náměty a vynasnažíme se je brzy zapracovat.

2/ Písmena s českou diakritikou

Nastavení vyhledávání tak, že písmena, která jsou podle ČSN považována za samostatná a mají řadící platnost (č,ř,š,ž), jsou samostatně vyhledatelná a s „holými“ písmeny nezaměnitelná, zatímco ostatní písmena s diakritikou se vyhledávají pod formou bez diakritiky, bylo před lety dohodnuto v diskusích mezi knihovnami Aleph. Je to kompromis mezi variantou „česká písmena hledej, tak jak jsou zapsána“, která je optimální pro české uživatele, a variantou „vše bez diakritiky v podobě ASCII“, která by vycházela vstříc uživatelům ze zahraničí, kteří většinou na svém počítači, pokud nejsou dost zkušení, naše písmena nevyloudí. (M.j. i z těchto důvodů s ohledem na české uživatele necháváme vyhledat znaky s „nečeskou“ diakritikou jako ASCII). Považuji to za správné řešení – ale je pravda, že uživatel má být v nápovědě upozorněn.
(Poznámka: tato část odpovědi na článek byla připravena dříve, než vznikl příspěvek ing. Brožka - necítím potřebu zde nic měnit. Zpoždění v odeslání bylo způsobeno snahou co nejlépe prověřit věci související s bodem 3, který považuji za klíčový.)

3/ Přetékání – neprovedení dotazu z důvodu přesáhnutí limitu

Limit pro krácení v souboru slov má NK ČR nastaven tak, aby příliš dlouhé vyhledávání neomezilo další uživatele, na doporučovanou hodnotu 1000 slov (tj. jednotlivých slov v indexu slov zahrnutých rozšířením, nikoli na ně navázaných záznamů). Kromě toho je zde limit pro proximitu (tj. počet záznamů, které se testují na vzdálenost slov), který je nastaven na 5000, stejně jako limit pro celkový výsledek. Limit pochopitelně bývá překročen, jestliže je zadáno poměrně velké krácení (např. geo*) – báze NKC obsahuje cca 1,5 miliónu záznamů. Pokud dá systém odpověď „Váš požadavek na vyhledávání nalezl příliš mnoho záznamů. Zpřesněte dotaz, prosím.“, což se děje v případě jednoduchého dotazu, je to v pořádku. Špatnou odpověď dává systém u dotazu, který kombinuje krácení a logické či proximitní operátory, když vyhledání neproběhne z důvodů přetečení některého z limitů. Toto JE CHYBA SYSTÉMU a jsme rádi, že byla takto odhalena – funkčnost operátorů obyčejně testujeme na jednodušších dotazech, producent a distributor navíc v menších testovacích bázích, kde k přesáhnutí limitu vůbec dojít nemůže. Doufáme, že v nové verzi, která by měla být v NK instalována do konce roku, bude tato závada odstraněna. V každém případě již nemá být limit na celkovou velikost vyhledaného souboru, pouze na zobrazení výsledků.

Jsem rovněž toho názoru, že není vadou systému, jestliže nezvládne příliš velké krácení u mnohdy nesmyslných dotazů jako c*, ale měl by vždy odpovídat správnou chybovou hláškou.