Se zkratkou SFX ( má připomínat slova Special eFfects) se v poslední době setkáváme často. Diskuse o systému, který se za ní skrývá, či spíše o problematice, kterou systém SFX řeší, probíhají na každém knihovnickém setkání, i když spíše v kuloárech, než na otevřeném fóru. Toto pojednání souvisí s článkem PhDr Stoklasové (Bohdana Stoklasová : Budování a zpřístupnění fondů) a jeho cílem je prezentovat základní rysy systému SFX a zařadit tento systém do širšího do kontextu.

Co se tedy skrývá za SFX? Odpověď je poměrně jednoduchá – SFX je nástroj, systém, umožňující integrovat heterogenní databáze do jednoho komplexu, a to metodou propojování databází. Propojované databáze (tedy databáze, nad kterými SFX operuje) přitom stále zůstávají samostatnými entitami, uživatel k nim může přistupovat i mimo rámec SFX.

Systém WebSPIRS

Krok 1: Nejprve vstoupíme do databáze MEDLINE. Dostanete se do ní přes položky

Informační služby, Databáze, Brána k informacím,

které najdete na

www stránce UK. ( http://www.cuni.cz/) V Bráně si zvolte položku

NOVINKY INFORMAČNÍ ZDROJE lékařské

(mimochodem, je to položka nikoli úplně "novinková") a vyberte si

Medline Express.

Po zalogování se dostanete se do prostředí WebSPIRS. Zvolte si databázi, například

MEDLINE EXPRESS 66-82,

(osmý řádek). Otevřete ji, zvolte si jako jazyk angličtinu a zkuste vyhledat term BRAIN .

Dostanete, jak se dalo čekat, desetitisíce nalezených odkazů.

Krok 2: V každém z nich objevíte na konci záznamu výzvu-volbu

Check for holdings

Zvolte (klikněte na ni ) si ji u libovolného záznamu, ve kterém je uvedeno ISSN 0036-5580.

Krok 3 (ten za vás udělá za pomoci WebSPIRS už webovské rozhraní TinWeb systému T Series, pod kterým jsou tyto katalogy UK a UP provozovány): Objeví se vám webovské rozhraní systému T Series obsahující informaci o seriálu, ve kterém se nachází příslušný plný text odpovídající nalezenému záznamu. Provedete-li totéž ( tj. krok 2) se záznamem, který má ISSN 0044-0086, systém T Series ( vlastně jeho www rozhraní TinWeb)vám odpoví, že příslušný seriál nenalezl.

Rozebereme si podrobněji, co všechno se vlastně událo. 

 V kroku 1 se nestalo zdánlivě nic zvláštního, v databázi MEDLINE jste vyhledali záznamy obsahující term "brain" v prostředí anglického jazyka. Při dalším prozkoumání nalezených záznamů jste však viděli u každého záznamu položku "Check for holdings". Podrobnější prozkoumání ukáže, že se za ní skrývá řetězec obsahující URL souborné databáze UK , databáze 1. lékařské fakulty UK, LFHK UK, souborného katalogu UP Olomouc a ISSN příslušného seriálu. To ale není všechno - součástí tohoto řetězce je i další informace, informace o akci, která se má nad uvedenými databázemi provést. Pomocí tohoto řetězce je tedy reálně, technologicky propojen a svázán MEDLINE (zdroj vazby) se systémy T Series (cílem vazby). Tato vazba, toto propojení spolupracuje na straně T Series s www rozhraním TinWeb. Připomeňme znovu, že součástí propojovací vazby jsou údaje o objektu (ISSN), o místu příští akce (URL katalogů v Praze, Hradci a Olomouci) a o akci, která se má provést (vyhledat seriál). Je zřejmé, že analogickým postupem by mohla být technologicky realizována též inherentní logická vazba mezi záznamem o plném textu (sekundární informací v Medline) a příslušným plným textem (primární informací).

V kroku 2 se využijí informace obsažené v propojovací vazbě a na základě nich se bojiště přesune z Medline přes TinWeb do katalogů v Praze, Hradci a Olomouci a zde se v Kroku 3 vykoná vazbou předepsaná akce (vyhledání) s objektem (seriálem).

Představte si nyní (jen v duchu, prosím, jak říká klasik), že z nějakých důvodů máme propojeny záznamy z Medline jen s katalogem na První lékařské a v Hradci a záznamy z Embase jen se souborným katalogem UP Olomouc. Tedy vazba záznamu v Medline má jakožto cíl vazby uvedeny katalogy UK a pro vazbu záznamu v Embase je cílem SK UPOL.

Představme si dále, že z tabulky vazeb vyřadíme ty vazby, které vedou jen k prázdnému vyhledání (v cílové databázi se seriál nenajde, vzpomeňme si na ISSN 0044 - 0086). V tomto ideálním tvaru tedy naše tabulka obsahuje jen vazby vedoucí k nějakému seriálu. Důsledkem je že systém nenutíme ke zbytečným vyhledáváním a navíc koncový uživatel nikdy nedostane odpověď typu "žádné záznamy". Ovšem ten, kdo ideální tabulku tvoří, tj. vyřazuje neefektivní vazby, ten musí mít cílové databáze k dispozici a musí nad nimi provádět rozsáhlé operace - pro každý záznam z Medline a Embase se musí přesvědčit, že v cílových databázích existuje odpovídající záznam.

Je zřejmé, že způsob propojování pomocí "ideální " tabulky (říká se mu statické propojování) je velmi rychlý (poté, co už je tabulka určena) a odolný vůči existenci chybných a irelevantních vazeb. Vyžaduje však předem provést rozsáhlé operace nad cílovými databázemi - a ty dodavatel databází ne vždy má k dispozici.

Situace by se velmi zjednodušila, pokud bychom netrvali na ideálním tvaru tabulky vazeb, tedy pokud bychom nevyřazovali vazby, nedávající žádný výsledek (to je případ vazeb ve WebSpirs). V tomto případě by tabulka vazeb byla ideově velmi jednoduchá a nemusela by se určovat předem. V našem případě WebSpirs by například mohla obsahovat vlastně jen "příkaz" vezmi ISSN (z dané zdrojové databáze Medline či Embase ) a jdi do cílové databáze (UK nebo SK UP) a proveď v ní vyhledání (najdi seriál). Tomuto způsobu propojování se říká dynamické propojování a při jeho implementaci ovšem zaplatíme tím, že konečné vyhledání bude někdy prázdné.

V jistém smyslu (ve smyslu pouhého přesměrování) by tedy tabulka obsahovala jen tři typy řádků, tři typy dvojic (zdroj, cíl) a sice (Medline, 1.LF UK), (Medline, LFHK) a (Embase, UP).

V našem případě SilverPlater databází je propojování prováděno (na straně SilverPlatter) na základě ISSN a ISSN je také to jediné, čím jsme ze strany producenta databází při propojování vázáni. Tomuto typu propojování se říká propojování otevřené. Má-li naproti tomu systém jen pevné propojovací vazby, tedy obsahuje-li jen nemodifikovatelné vazební informace (odkud, kam, typ akce), mluvíme o propojování uzavřeném. V systémech s uzavřeným propojováním tedy nemůže knihovna propojovací vazby měnit, je zcela závislá na producentovi databází.

Na základě toho, co nyní o propojování víme, můžeme SFX charakterizovat podrobněji: Je to systém pracující na principech dynamického a otevřeného propojování. (Takový je ovšem i WebSpirs).

Z předchozího je zřejmé, že obecný popis systému z vnějšku příliš efektivní zatím nebyl - jak SFX tak WebSpirs jsou charakterizovány stejně. Proto si v další části ukážeme trochu podrobněji, jak SFX funguje uvnitř. Nejprve musíme zavést několik pojmů (nebude to tak hrozné, jen dva pojmy nás čekají): Souborem konceptuálních vazeb (COLLI) budeme nazývat seznam vyžadovaných služeb (akcí) v cílových databázích. COLLI neobsahuje údaje o zdrojových databázích. V případě našeho hypotetického WebSpirs bude tedy COLLI mít tři položky a sice

1) najdi seriál na 1. LF UK

2) najdi seriál na LFHK

3) najdi seriál v SK UP

Druhý pojem, který budeme potřebovat je identifikátor - ten se skládá ze dvou položek, z popisu iniciátora vazby a z popisu akce. Popis iniciátora vazby je údaj, popisující , identifikující zdroj vazby ( ID serveru zdrojové databáze, jméno zdrojové databáze, položka ve zdrojové databázi). Druhou položkou v identifikátoru je popis akce, kterou má SFX vykonat. Identifikátor neobsahuje informace o cílových databázích. (Pokud si Identifikátora personifikujeme, tak je to ten, kdo zodpovídá za vykonání požadované služby - např. za vyhledání seriálu. Protože ale některé služby mohou být nesplnitelné, musíme identifikátorovi opatřit několik nepřátel - jejich úkolem bude zlikvidovat ho dřív, než při plnění nesplnitelných služeb spotřebuje příliš mnoho času.)

Pomocí COLLI a Identifikátoru můžeme zjednodušeně popsat principy práce SFX takto:

Krok 1): Je samozřejmě stejný jako u WebSpirs, vyhledáme ve zdrojové databázi záznamy.

Krok 2): Každý záznam ve zdrojové databázi obsahuje Identifikátor, ten je skryt pod položkou SFX a kliknutím na tuto položku se aktivuje, podobně tomu bylo u položky "Check for holdings" u WebSpirs ( identifikátor obsahuje s určitou nadsázkou stejné informace, jaké obsahuje WebSpirsová vazba - s výjimkou cílové databáze, samozřejmě). Po aktivaci (ta proběhla na serveru, kde je umístěna zdrojová databáze) se Identifikátor přenese na SFX server. Tam na něho číhá, jak čekáme, COLLI databáze. Ale nejen ona, má významné spolubojovníky, SFX filtry. Ve vzájemné spolupráci tyto jednotky určí, které cílové databáze má vůbec identifikátor povolené ( pokud tedy např. Identifikátor přišel z Medline, povolí mu jen databáze z UK, pokud identifikátor zároveň požaduje vyhledání seriálu s ISSN 0046 - 0086 tak ho filtr vyřadí). V naladění SFX filtrů samozřejmě spočívá efektivita celého SFX systému. Úlohou SFX filtrů je vyřadit maximální počet vazeb vedoucích k prázdnému výsledku a provést tuto vyřazovací akci maximálně efektivně, tedy s minimálními nároky na čas. Výsledkem cenzurní činnosti COLLI a filtrů je seznam vazeb, tedy akcí, které se mají provést na vybraných databázích. Zdá se tedy, že prošel-li identifikátor s alespoň jednou vazbou-akcí, má vyhráno - akce se provede. Takhle benevolentní ale SFX není, žádnou akci ještě nepovolí. Namísto toho vrátí seznam nadějných databází zpět uživateli a ponechá na něm, aby si mezi kandidáty sám vybral ty databáze, kde se má konečné vyhledání provádět.

Jednoduché, že?

Použité prameny:

Reference Linking in a Hybrid Library

Part 1: Frameworks for Linking

Part 2: SFX, a Generic Linking Solution

Part 3: Generalizing the SFX solution in the "SFX@Ghent & SFX@LANL" experiment

Herbert Van de Sompel
Los Alamos National Laboratory - Research Library
herbert.vandesompel@rug.ac.be

Patrick Hochstenbach
Automation Department of the Central Library
University of Ghent, Belgium
patrick.hochstenbach@rug.ac.be