Sorry, you need to enable JavaScript to visit this website.

Vyjádření distributora systému ALEPH k obsahu článku Otakara Pinkase

Čas nutný k přečtení
6 minut
Již přečteno

Vyjádření distributora systému ALEPH k obsahu článku Otakara Pinkase

3 comments
Autoři: 

Rádi bychom na úvod poděkovali autorovi za pečlivou analýzu vyhledávání pomocí CCL jazyka. Potěšilo nás, že systém ALEPH může sloužit i jako pedagogické prostředí pro vysokoškolské studenty. Vítáme nabídku autora článku a připojujeme naše komentáře k některým jeho zjištěním.

Pravidla vyhledávání pro zacházení se samohláskami a souhláskami nastavuje systémový knihovník. Obvykle se rozhoduje na základě praktického používání systému uživateli a na základě uživatelských návyků, požadavků a preferencí. Mezi uživateli tvoří specifickou kategorii i knihovníci. 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.

Pro optimalizaci výkonu systému vyhledávání ve WWW katalogu může systémový knihovník nastavit dva limity – tzv. hit_limit a tzv. prox_limit:

  • hit_limit vyřazuje ze hry velké výsledkové množiny (např. je-li nastaven na hodnotu 50000, odmítne zobrazení takových výsledkových množin, kde výsledný počet záznamů je vyšší než 50000 záznamů);
  • prox_limit omezuje provádění dotazů, které obsahují znak pro pravostranné nebo levostranné rozšíření a kde výsledný počet slov, která by se měla použít pro vyhledávání, přesahuje uvedenou hodnotu v limitu (např. je-li nastaven na hodnotu 1000, odmítne provedení takových dotazů, kde počet jedinečných slov získaných na základě rozšíření řetězce přesáhne 1000).

Oba limity může systémový knihovník upravovat a sledovat, jak změněné hodnoty ovlivňují chování systému při vyhledávání. Vyhledávání pomocí grafického klienta knihovníka se tyto limity netýkají.

V případě, že jsou v dotazu s rozšířením použity speciální operátory !n nebo %n, tak jejich použití rovněž ovlivňuje celkový počet slov zpracovávaných v rámci daného vyhledávání. Proto je možný různý výsledek u dotazů D9 a D27.

V případě, že je dotaz zaměřen do určitého indexu (např. klíčových slov), může se v něm vyskytovat méně (nebo více) slov než v indexu jiném (např. slov z názvů). To má v důsledku opět vliv na chování systému při vyhledávání slov s rozšířením. Jinak řečeno v „chudším“ indexu se dotaz provede, v "bohatějším" indexu se dotaz neprovede, protože přesáhne hranici limitu prox_limit.

Při formulaci dotazu pro vyhledávání nemá systém ALEPH nastavena omezení na počet operátorů. Existuje však omezení délky dotazu - celý řetězec představující jeden dotaz (včetně operátorů, závorek a vlastního dotazu) nesmí překročit délku 500 znaků.

Na závěr bychom rádi připomenuli, že v článku uvedená zjištění se týkají instalace systému v Národní knihovně ČR, která používá ALEPH 500 ve verzi 14.2.6. Pro úplné ověření chování vyhledávání pomocí CCL jazyka bychom tak doporučili k analýze i novější verzi systému 16.2, která je k dispozici např. na ČVUT (http://aleph.cvut.cz/).

Hodnocení: 
Zatím žádné hodnocení
ŠIMKOVÁ, Dana. Vyjádření distributora systému ALEPH k obsahu článku Otakara Pinkase. Ikaros [online]. 2005, ročník 9, číslo 5 [cit. 2019-12-10]. urn:nbn:cz:ik-11812. ISSN 1212-5075. Dostupné z: http://ikaros.cz/node/11812

automaticky generované reklamy

Máme tu 3 komentářů

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.

Před dvěma lety (30.4.2003) jsem psal do NKP v dopise toto:

... A zrovna tak je to s nefunkčností
některých operátorů v některých typech vyhledávání, s mylnými odpověďmi, pokud třeba při pravostranném rozšíření ve složitějším dotazu se překročí určitá hranice vyhledaných záznamů a vůbec pak help k operátoru "blízkost slov". To je jak ukázka neznalosti autorů nadefinovat tuto funkci v terminologii tagů UNIMARCu. O neslučitelnosti vzdálenostních operátorů s pravostarným rozšířením a jeho konverzi na AND asi nemá cenu se zmiňovat, protože určitě to v NKP nikdo nepoužívá. Opravdu snad bylo lepší, když ve staré verzi help k operátorům %n či !n vůbec nebyl.
...
Přece není trvale možné, aby
za "instalatéry" či distrubutory systému
jej vždy ladili uživatelé. (Anebo se se všichni zmiňovaní bojí, že při možném odhalení nedostatku se na ně nejmenovaný vedoucí bude zlobit?)

registration login password