2014. január 12., vasárnap

Re: [KATALIST] ETO és Google

2014/1/12 mandygabor@yahoo.com <mandygabor@yahoo.com>:
>
> De mindekelőtt egy ön-pontosítás. Egy gyarapodásjegyzék (vagy
> bármely más hosszú dokumentum) nem lenne alkalmas az
> ETO jelzetek szerinti Google-keresésre, mivel a Google - legjobb
> tudomásom szerint - az egész dokumentumot adja vissza,

És? A Google számára a katalógusrekord webes felületen megjelenítve
ugyanolyan dokumentum, mint az MNB egy-egy füzete vagy a www.oszk.hu
nyitóoldala vagy a MEK könyvszövegei. Ha a katalógusrekord (nem írom
le többet, hogy "webes felületen megjelenítve", remélem, érthető így
is) az a dokumentum, ahol megtalálja a keresőkifejezésünket, akkor azt
adja vissza, de mi ezzel a gond? Még sose hallottam olyan olvasóról,
aki azért panaszkodott volna, mert a katalógusban a keresett könyv
helyén csak egy cetlit talált...


ezért
> a keresőkérdést a találat szövegében meg kell ismételni; ráadásul
> ott már nem működik az idézőjelekkel való szűkítés, pláne nem,
> ha egyszerre két ilyen idézőjeles szövegrészletet akarunk
> megtalálni.

Elnézést kérek, de ezt úgy, ahogy van, nem értem. Mit kell itt a
"találat szövege" alatt érteni? Ha azt, amit a G elénk tesz az adott
kifejezésre keresve, akkor abban már benne van a keresőkifejezés
(azért tette elénk). Ha mást jelent, akkor mit? És miért okozhat
problémát a két idézőjeles kifejezés? A G számára a szöveg (első
megközelítésben) csak karakterek sorozata, amire kb. akárhány mintát
megpróbálhat illeszteni.


Ez a hiányosság csak úgy küszöbölhető ki, ha
> minden rekordot külön webdokumentumként töltünk fel. Ennél
> pedig egyszerűbb, ha megengedjük a Google-nek, hogy a katalógusainkban
> böngésszen. (Igazából nem értem, mi lehetne ebből hátrány a könyvtárak
> számára. Az egyértelmű előny, hogy a használó katalógusrekordokat is
> találhat, ami ösztönözheti az illető könyvtár felkeresésére.)
>

Az OPAC-okban minden katalógusrekord külön webdokumentumként jelenik
meg. A Google-nek annyi kell csupán, hogy az egyik rekordot olvasva
olyan kérdések merüljenek fel, amiket feltéve az OPAC-nak, az
legenerálja a többi katalógusrekordhoz tartozó webdokumentumokat.
Például: az OSZK portálján, a hírek közt van egy olyan, hogy 1956-ról
szóló könyvek kedvezményes vására
(http://www.oszk.hu/hirek/oktober-engedmenyes-konyvek). Itt az
engedményes könyvek címei be vannak linkelve a katalógusba, ezeket a
linkeket a G kigyűjti és végiglátogatja, ekkor van 2-3 tucat rekordja.
Amikor a második könyv (Budapest 1956 : a forradalom / Erich Lessing
fotográfiái) katalógusrekordjára ráfut, akkor abban talál néhány
linket besorolási tételekre, pl. "1956-os Int." mint kiadó,
tárgyszavak, ETO-jelzetek, szerző neve. Az elsőre ("Lessing, Erich",
mint név) ráfutva kap további 155 rekordot, a kiadóra még 70-et.
Következik a "magyar történelem" tárgyszó, erre kap 2000 rekordot.
Mindegyikben van néhány hasonló link, amin elindulhat további
irányokba. Ezek a linkek így egy gyorsan robbanó fát rajzolnak,
melynek élei a linkek, pontjai pedig az egyes rekordok (mindenféle
adatbázis-rekordok, dokumentumokra vonatkozó bejegyzések, besorolási
adatok, bármi, amit talál). Fa pedig attól lesz, hogy bár a 2000
találat mindegyike tartalmaz linket a "magyar történelem" tárgyszó
besorolási tételére, azonban ezek URL-je megegyezik, a G pedig számon
tartja, hogy milyen URL-en járt már és nem fut rá még egyszer, így a
gráf, amit bejár, körmentes lesz.

Itt látszik az is, hogy mi lehetne ebből hátrány a könyvtáraknak: a
Google-nek hirtelen nagyon sok kérdése lesz a katalógushoz, és ezek
egy részére a válasz is nagyon nagy. Ha szabályozatlanul ráengedik,
akkor két dolog lehetséges:
1) A buta robotok gondatlanul percek alatt kiütik az egész rendszert.
2) Mivel a Google okos, némi tanulás után pont olyan tempóban kérdez,
amit a katalógus még ki tud szolgálni. Ekkor "csak" a humanoid
felhasználók nem férnek hozzá a katalógushoz, vagy alig.

Ugyanakkor ezek a terheléses problémák jól kezelhetők több ponton
(alkalmazás szintű tűzfal, reverse proxy, webszerver) is, melyek közül
a webszerver egész biztosan minden OPAC esetében adott. Az is
megoldható, hogy a terhelés függvényében időről időre
újrakonfiguráljuk a hozzáférés-vezérlést (magyarul access control),
így a rekordok felolvasása is viszonylag lendületesen halad, meg az
olvasók is hozzáférnek a katalógushoz.

Ami még problémát jelenthet (nem tudom, hogy ténylegesen problémát
jelent-e), az a dinamikusnak látszó tartalom, vagyis hogy az OPAC-ok
ugyanazokat a katalógusrekordokat időről időre kissé eltérő URL-en
mutatják, jellemzően valamilyen véletlen adat (pl. session id) URL-be
szúrásával. Erre jó megoldás az OSZK-nál alkalmazott "Cool URI",
vagyis egy-egy statikus URL hozzárendelése a rekordokhoz. Ha megnézzük
a Google OSZK-s találatait, akkor látszik is, hogy ezeket indexelte
le.


> Nekem nem jutott eszembe az olyan eszközök alkalmazása, mint
> a site:.hu vagy a site:nektar.oszk.hu. Esetleg meg lehetne próbálni
> ezek választékát szélesíttetni.
>

Persze, miért ne. Pl. a kedvenc könyvtáraim katalógusainak doménnevét
összefűzöm egy OR operátorral.

> Izgalmas kísérletekről olvashatunk a gépi indexelés terén, de a
> jelen helyzetben nem gondolok arra, hogy a Google a dokumentumokat
> osztályozhatná. A nyelvi feltárásban viszont idővel egyre jobb eredményt
> ér majd el. Laikus használóként nem tudom, hogy lehetne proximity
> operátort alkalmazni, hogy más eredményt adjon a dokumentum-, a
> fejezet-, a bekezdés- vagy a mondat szintű keresés. (Ahogy fentebb
> utaltam rá, én eddig csak a dokumentum szinttel találkoztam.)
>

http://www.googleguide.com/wildcard_operator.html

Pl. a korábbi két idézőjeles részjelzettel, OSZK-n kívül a FSZEK-nél is keresve:
[82-322.4 * =945.11] site:nektar.oszk.hu OR site:saman.fszek.hu



Üdvözlettel:
Balogh Béla

_______________________________________________
Katalist mailing list
Katalist@listserv.niif.hu
https://listserv.niif.hu/mailman/listinfo/katalist