5 Dostęp do systemu

Motto:

Zapewnienie dostępu nie koniecznie zawsze może okazać się możliwe: dla pewnych zapytań mogą nie istnieć stosowne źródła; w przypadku niejasnych zapytań źródło może istnieć, ale zrozumienie go może leżeć poza granicami pojmowania pytającego jak w przypadku fragmentów zaginionych języków.

Michael K. Buckland, „Library Services in Theory and Context”, 1988, strona 188.

Wstęp

Aspekt dostępu do systemu cyfrowego był już uprzednio podejmowany przez polskich badaczy przedmiotu (Daniłowicz [1982], Choroś i Daniłowicz [1982], Daniłowicz [1993], Grabowska [1995], Próchnicka [1996]). Jest rzeczą interesującą, że wszystkie te badania były głęboko pragmatyczne, nastawione na analizę procesu dostępu użytkownika do informacji, od poziomu modelowania potrzeb informacyjnych użytkownika na podstawie badania przestrzeni jego zapytań i przestrzeni dokonywanych przez niego selekcji zbioru odpowiedzi systemu, po ontologiczną analizę cech interfejsu użytkownika. Zatem spektrum badań rozciągało się od obszaru serwera badającego zachowanie klienta do obszaru klienckiej stacji roboczej.

W swych wcześniejszych pracach autor dał wyraz swemu zainteresowaniu ścieraniem się różnych koncepcji protokołów komunikacyjnych w dostępie do systemu cyfrowego (Czermiński [1994-1], [1994-2], [1996]). O ile w połowie lat 90-tych główne starcie miało miejsce na poziomie trzeciej warstwy (sieciowej) modelu ISO/OSI, o tyle obecnie przenosi się ono na warstwę siódmą (aplikacji). Pierwszym elementem dostępu do systemu są urządzenia techniczne, nazywane w informatyce urządzeniami wejścia/wyjścia. Urządzenia te zostały omówione wcześniej, w rozdziale poświęconym systemowi. Drugim elementem dostępu jest komunikacja między urządzeniami wejścia/wyjścia a serwerem zasobów cyfrowych. Ten element został nakreślony w poprzednim rozdziale. Obie grupy mieszczą się w trzech dolnych warstwach modelu ISO/OSI. W zasobach cyfrowych zreferowane zostały wybrane zagadnienia dotyczące kodowania i reprezentacji używanych znaków. Te zagadnienia z kolei mieszczą się w warstwie prezentacji modelu ISO/OSI. W niniejszym rozdziale zajmiemy się niektórymi problemami dostępu, należącymi do warstwy najwyższej - aplikacji.

Boole wyszukiwania. Od żelaznej logiki do liberalnej probabilistyki

Mówienie o światowej powodzi informacyjnej stało się już komunałem. Biblioteki zwolna są wciskane do wielkiego kotła wielkich światowych systemów informacyjnych. Choć pod wieloma względami bardzo się różnią od swoich czysto cyfrowych sióstr, to w stosunku do obydwu czytelnik zaczyna mieć te same oczekiwania i te same kryteria oceny. Trudno się zresztą dziwić, skoro od sporego już czasu bibliotekarze wspólnie pracują z informatykami nad doskonaleniem zunifikowanego interfejsu do bibliotecznych katalogów, niestrukturalizowanych zasobów tekstowych i najróżniejszych baz danych. Zadajmy sobie pytanie: czy rzeczywiście dzisiejsze biblioteki są "takie same, jak dawniej"? Z pewnością nie! Biblioteki włączyły się w owczy pęd nie gorzej od innych dziedzin. Porównując zawartość starych kartek katalogowych ze współczesnym katalogiem online odnotowujemy znaczny wzrost wpisanej przez bibliotekarzy informacji. Niby opis staje się bogatszy - to raczej i dobrze. Ale szybkie narastanie nagromadzonej informacji równie szybko stwarza poważne problemy wyszukiwawcze. Pojawienie się Internetu od razu rozbudziło apetyty na tworzenie i przetwarzanie różnego rodzaju metadanych. Do takich ciekawych projektów, budzących nadzieje czytelników, należą rozszerzenia opisu przedmiotowego katalogowanych książek (Subject Access Project) o spisy rozdziałów (Peis, Molina [1998]). Już bez wahania się mówi (z zauważalną przesadą, oczywiście), że jest to równoważne dostępowi do treści artykułów publikowanych w czasopismach. Jeśli tego rodzaju tendencje rozwiną się na skalę masową, to do przetwarzania informacji kontrolowanych przez biblioteki trzeba będzie szybko zastosować metody obsługi masowej. Cechą charakterystyczną obsługi masowej jest automatyka kontrolowana algorytmem, a proces ingerencji ludzkiej jest zminimalizowany do poziomu uzależnionego od ilości przetwarzanej informacji. Dobrym przykładem takiej automatyki jest katalogowanie w systemie centralnego serwera, zorganizowane i prowadzone przez OCLC. Konsekwencją takiego modelu jest szybkie powstanie wielkich zasobów o znacznej niejednorodności. Przeto w takich przypadkach przestaje się stopniowo stosować znaną już powszechnie bibliotekarzom i znacznej liczbie użytkowników dwuwartościową logikę boolowską i operowanie opisem dokładnym z pełnym przestrzeganiem ortografii. Precyzję dawnego opisu możliwego do przygotowania na poziomie niewielkich zasobów zaczynają zastępować inne narzędzia, charakterystyczne dla epoki masowej obsługi: logiki wielowartościowe oraz opis statystyczny. Stwierdzenie tego faktu jest raczej przykre dla bibliotekarza. Z jednej strony automatyka daje szanse na sprostanie gwałtownie narastającym oczekiwaniom, z drugiej - dawna duma z powodu oferowanej jakości ulega szybkiej erozji. Niemiłe jest również to, że jeszcze niedawno trzeba było się uczyć logiki boolowskiej, a tu już mówi się o logikach wielowartościowych (znacznie bardziej skomplikowanych) oraz probabilistyce.

Przedmiotem zainteresowania współczesnych bibliotekarzy ze zrozumiałych względów są bazy danych. Ich wysublimowanym etapem rozwojowym są relacyjne bazy danych. Do zarządzania takimi bazami służą wydzielone, wyspecjalizowane systemy, takie jak Oracle, Informix, Sybase czy INGRES, mające na standardowym wyposażeniu strukturalny język zapytań SQL (ang. Structured Query Language). Popularność jego wyznacza liczba implementacji. Gruber [1996] podaje, że SQL został zaimplementowany w ponad 140 produktach. Obecnie z pewnością liczba ta jest znacznie wyższa. Gruber nazywa go, chyba dość trafnie, podjęzykiem danych.

Standard SQL składa się z pary klient - serwer. Podobnie, jak i bazy danych, również i standard SQL nie będzie tutaj szerzej referowany - szczegółowy opis znajdzie Czytelnik w cytowanej literaturze. Wspominamy go tu na okoliczność faktu, że właśnie SQL ma zaimplementowaną logikę trójwartościową. Może Czytelnika zastanowi fakt, dlaczego omawiamy to zagadnienie tutaj, a nie przy Jednostce Arytmetyczno - Logicznej procesora. Przyczyna jest klarowna: obecna arytmetyka komputerowa jest oparta na zjawiskach fizycznych z dwoma rozróżnialnymi stanami fizycznymi - stąd w naturalny sposób arytmometr ma wbudowaną na stałe logikę dwuwartościową - boolowską. Niestety, szczegółowe prace nad bazami danych pokazały, że oprócz dwóch standardowych wartości logicznych: TRUE (prawda) oraz FALSE (fałsz) dobrze jest się jeszcze posłużyć wartością UNKNOWN (nieznane). Taki zabieg nie jest jednak realizowany sprzętowo, lecz programowo. Wprowadzenie trzeciej wartości logicznej, choć dobrze oddaje realia życia, stanowi jednak zauważalne utrudnienie. System wyszukiwawczy oparty o SQL oprócz spodziewanych odpowiedzi:

może jeszcze dać trzecią odpowiedź:

Trzeba bowiem zdawać sobie sprawę z faktu, że do bazy, zamiast brakującej danej można wprowadzić wartość NULL (zero, puste). Pojawienie się takiego obiektu jako argumentu np. relacji logicznej będzie prowadziło do nadania odpowiedniemu predykatowi wartości UNKNOWN. Wartości NULL nie muszą zresztą pochodzić bezpośrednio z bazy, ale mogą być również generowane przez zapytania, lub wyrażenia (patrz Gruber op.cit.:192). Warto wiedzieć, że pierwszą na świecie pracę na temat tej logiki opublikował J. Łukasiewicz [63] (Łukasiewicz [1920], por. też Kotarbiński [1957]). Okazuje się, że badania tekstów prowadziły do wielu ciekawych odkryć. Rogowski [1964] badając wypowiedzi Hegla na temat zagadnień antynomialnych opracował szczegółowo logikę czterowartościową, a Gödel [1931], analizując tekst pretendującego do bycia szczytem poprawności dzieła Russela i Whiteheada Principia Mathematica, udowodnił jedno z najciekawszych twierdzeń XX wieku - twierdzenie o niezupełności systemów dedukcyjnych, w których da się zbudować arytmetykę liczb naturalnych (por. też Nagel i Newman [1966]). Odnotowania godny jest też fakt zainicjowania przez Reichenbacha i Łukasiewicza badań dotyczących zastosowania logik wielowartościowych do teorii prawdopodobieństwa (Mała Encyklopedia Logiki [1970]). Nie ma zatem nic specjalnie zaskakującego w fakcie, że współczesne zabiegi o znalezienie nowych, efektywnych sposobów wyszukiwania informacji w wielkich zbiorach, sięgają do metod probabilistycznych (używany jest też termin wyszukiwanie bayesowskie). Tendencja ta już się zarysowała i należy oczekiwać jej intensyfikacji. Interesujące odnośniki literaturowe na ten temat można znaleźć np. w pracy Losee [1997].

Wybrane zagadnienia dotyczące protokołu ANSI/NISO Z 39.50

W niniejszym paragrafie poświęcimy nieco uwagi pewnym praktycznym, ale i teoretycznym aspektom tego ciągle mało popularnego w Polsce interfejsu opartego na protokole Z 39.50 Poruszane zagadnienia będą miały wyraźną orientację praktyczną, będą prezentowały wyniki własnych badań, testów i działań o charakterze organizacyjnym.

Na pierwszy rzut oka dziwne wydawać się może sformułowanie opinii, że usługa Z39.50 jest w Polsce niepopularna, gdy równocześnie liczne biblioteki systemu Horizon (Toruń, Poznań, Łódź) pracują właśnie w tej klasie protokołów. Z jednej strony rzecz polega na tym, która wersja protokołu jest na danym serwerze zaimplementowana. Z drugiej - chyba bardziej istotnej - w ilu oddziałach informacji naukowej polskich bibliotek i na ilu stanowiskach roboczych naszych naukowców zainstalowane jest oprogramowanie klienta Z39.50 z odpowiednią bogatą bazą adresową, dotyczącą zarówno serwerów baz bibliograficznych, jak i pełnotekstowych.

Historia rozwoju międzynarodowych standardów definiujących usługi oraz protokoły wyszukiwania i pobierania informacji (ang. Search and Retrieve, SR) liczy już sobie kilkanaście lat. W pierwszym zamyśle (1984) były one przeznaczone do obsługi informacji bibliograficznej (por. Buckland, [1987]). Solidne podstawy do przygotowania odpowiednich specyfikacji dała norma ISO 7498  oraz dokumenty ISO wydane na przełomie lat 1987/1988. W roku 1988 National Information Standards Organization, NISO ( http://www.niso.org/), zatwierdziła normę przygotowaną przez Komitet Standardów "D" (Z39) i moment ten uważa się za początek skali rozwoju tej relatywnie nowej dziedziny usług sieciowych.

Prowadzonym pracom od początku towarzyszyło nadspodziewanie wielkie zainteresowanie wszystkich, którym bliska była potrzeba dostępu do najróżniejszego typu informacji: bibliograficznej, finansowej, użyteczności publicznych, chemicznej (CAS: Chemical Abstracts Service, http://www.cas.org/)czy prasowej. Odpowiedzią na to zainteresowanie było utworzenie w 1990 roku interdyscyplinarnej grupy wdrożeniowej ZIG (Z39.50 Implementors’ Group), moderowanej przez ustanowioną rok wcześniej przy Bibliotece Kongresu USA, Agencję Obsługi Z39.50 (Z39.50 Maintenance Agency). Po dzień dzisiejszy obydwie te instytucje stanowią siłę motoryczną rozwoju nieustannie rozszerzającego się standardu. Osoby interesujące się bliżej tym rozwojem mogą się wpisać na listę dyskusyjną Z3950IW wysyłając list rejestracyjny pod adresem: Z3950IW@LISTS.UFL.EDU). Wszystkie teksty przesyłane do listserwera są automatycznie archiwizowane. Zawartość archiwum aktualnie dostępna jest na serwerze Florida University pod adresem: http://www.lists.ufl.edu/archives/z3950iw.html

Dokumenty o charakterze wynikowym, ogólnym i pomocniczym dotyczące prac ZIG dostępne są w formatach *.ps, *.pdf, *.wp w katalogu pub/z3950 anonimowego konta serwera rs7.loc.gov (140.147.248.7),

Wersje standardu i dokumentacja

W zasadzie niniejszy przegląd referuje rozwój prac nad narodowym standardem USA, jakim jest Z39.50. Nadmienić jednak należy, że od samego początku zespół tworzący amerykańskie specyfikacje tego protokołu w znacznej mierze pokrywał się z zespołem rekomendującym do zatwierdzenia normy w International Organization for Standards, ISO ( http://www.iso.ch/) . Fakt ten znakomicie wspomagał wzajemny przepływ idei i przyspieszał zatwierdzanie dokumentów. Praktyka jednak pokazuje, że ze względu na nieustannie prowadzone prace rozwojowe i szybkie tempo uzupełniania norm, specyfikacje amerykańskie stanowią nadzbiory odpowiednich standardów ISO. Rozróżnia się następujące poziomy rozwoju specyfikacji:

• Z39.50-1988 (wersja przestarzała i wcześnie zarzucona, nazywana czasem Wersją zerową)
• Z39.50-1992 (zwana Wersją 2, z wyraźną niechęcią twórców standardu do podania, co należałoby uznać za Wersję 1. Zgodnie z zatwierdzoną dokumentacją Wersja 1 winna być utożsamiana z Wersją 2),
• Z39.50-1995 (Wersja 3).
• ISO 23950 (w przygotowaniu jest polska norma)

Nomenklatura

Wszelkie akty normatywne rozpoczynają się listą określeń stosowanych przy opisie normy. W szczególności dotyczy to norm z obszaru informatyki i dziedzin pokrewnych. Z listy roku 1995, liczącej 102 pozycje, warto przetłumaczyć (w nawiasie podane są terminy angielskie) minimalną liczbę pojęć niezbędnych do zrozumienia prezentacji.

• A-Asocjacja, Skrótowe określenie angielskiego terminu Application Association - sesji komunikacyjnej pomiędzy użytkownikiem bazy danych (data base user) a oferentem bazy danych (data base provider)
• źródło (origin), jednostka (ang. entity), która inicjuje Z-Asocjację oraz operacje podczas trwania Z-Asocjacji
• cel (target), jednostka, która przyzwala na Z-Asocjację
• klient (client), aplikacja (oprogramowanie użytkowe), którą wyposażono w źródło, także użytkownik bazy danych
• serwer (server), aplikacja, którą wyposażono w cel, także oferent bazy danych. Warto zwrócić uwagę, że w potocznym języku terminem serwer określany jest komputer (tu jest nim oprogramowanie).
• udogodnienie (facility), logiczna grupa usług Z39.50
• Z-Asocjacja, skrótowe określenie terminu Z39.50-Association, - sesji jawnie otwartej przez źródło i bądź jawnie zakończonej przez źródło lub cel, bądź niejawnie zakończonej przez zakończenie A-Asocjacji.

Rotacja terminów użytych w powyższych definicjach przez twórców normy może przypominać bibliotekarzowi znany z logiki błąd idem per idem (błędne koło). Jednakże Czytelnikowi mającemu wykształcenie informatyczne przytoczone definicje natychmiast będą się kojarzyć z werbalną wersją notacji BNF(Turski [1979:167]). Szczegółowa lista warunków sine qua non dla źródła i celu podana jest w dokumencie:
http://www.loc.gov/z3950/agency/v3base.html .

Pragniemy zwrócić uwagę, że w zakresie stosowanej nomenklatury od roku 1988 nastąpiły zasadnicze zmiany. Już przy definicji opcji protokołu używany dawniej termin origin zastąpiony został terminem client, zaś termin target terminem server. Jednakże na poziomie opisu procesu inicjowania Z-Asocjacji terminy używane w 1988 roku i 1995 roku są identyczne. Świadczy to o przewartościowaniu obszarów znaczeniowych niektórych terminów. Używana poniżej terminologia bazuje na wersji z 1995 roku i w niektórych punktach nie jest zbyt szczęśliwa. Wprowadzanie całkowicie nowych określeń na oznaczenie terminów podrzędnych w stosunku do dobrze ukorzenionego pojęcia nie sprzyja popularyzacji tego dość trudnego standardu. Wydaje się, że świeżo zaproponowane przez Evansa terminy Z-klient na miejsce terminu źródło oraz Z-serwer na miejsce terminu cel, choć nieco dłuższe w zapisie, wydają się nieporównanie szczęśliwsze i należy mieć nadzieję, że się przyjmą.

Podstawowe informacje o protokole

Protokoł Z39.50 określa formaty i procedury rządzące wymianą komunikatów pomiędzy dwoma systemami komputerowymi, mające na celu pobranie informacji z serwera i przeniesienie jej do klienta inicjującego nawiązanie kontaktu. Protokół nie przewiduje inicjowania Z-asocjacji przez serwer. Elementami tego dialogu są: zgłoszenie zapotrzebowania na usługę przez Z-klienta lub Z-serwer (service request) oraz odpowiedź na zgłoszone zapotrzebowanie (response). Usługi mogą być potwierdzone, niepotwierdzone oraz potwierdzone warunkowo.

Bliższa charakterystyka procedur tego protokołu nie będzie tu przytoczona, choćby z braku miejsca. Dość będzie wspomnieć tylko, że detale techniczne tych procedur wymienione są w cytowanych wcześniej normach. Z punktu widzenia końcowego użytkownika znacznie ważniejsze są oferowane przez standard usługi czy też udogodnienia. Protokół Z39.50 definiuje 11 podstawowych udogodnień (zlepków usług o zbliżonym charakterze):

1. Inicjowanie (Initialization facility) połączenia w ramach której Z-klient (źródło) proponuje Z-serwerowi (celowi) negocjację warunków zestawienia Z-asocjacji. Jeśli zarówno stan łącza fizycznego jak i warunki podlegające negocjacji umożliwią Z=Asocjację, to komunikujące się ze sobą systemy mogą przejść do następnego etapu. Negocjowana jest tu wersja standardu, repertuar znaków, segmentacja odpowiedzi, współbieżne przeszukiwanie kilku różnych baz danych (tylko wersja 3) oraz inne opcje

2. Wyszukiwanie informacji (Search Facility). Z-klient ma możliwość indagowania bazy danych w oparciu o uzgodniony wcześniej format wyszukiwania, wytworzenia na serwerze zbioru wyników oraz otrzymanie informacji o tym zbiorze (m.in. jego liczebności). Ta faza rozpoczyna się negocjacją typu składni zapytań (języka zapytań). Wersja 3 standardu Z39.50 przewiduje sześć typów składni zapytań, proponowanych przez klienta serwerowi. Aktualnie rozważa się również wprowadzenie siódmego typu zapytań dopuszczającego użycie SQL:

• Typ-0: Niestandardowy język zapytań, uzgodniony bilateralnie,

• Typ-1: Odwrotna Notacja Polska (Reverse Polish Notation, RPN) (Turski [1979])

• Typ-2: Standardowy język zapytań do interaktywnego wyszukiwania tekstu wg normy ISO 8777

• Typ-100: Standardowy język zapytań do interaktywnego pobierania informacji wg normy ANSI Z 39.58

• Typ-101: Rozszerzona Odwrotna Polska Notacja (ERPN) - dotyczy uzupełnienia Type-1 o operator bliskości,

• Typ-102: Zapytanie wg Ważonej Listy (Ranked List Query) - rezerwowane rozszerzenie dla późniejszych wersji Z39.50.
  
  Typ-102 znajduje się obecnie (koniec 1999 r.) w fazie opracowania. Liczne szczegóły można znaleźć w dokumencie:
  http://www.itl.nist.gov/iaui/894.02/projects/rlq/RLQ_spec_Feb96_ZIG.html

• Typ SQL  (w trakcie dyskusji)

• Typ XML (w trakcie dyskusji)

Drugim ważnym parametrem, ułatwiającym wyszukiwanie, jest profil dostosowujący charakterystykę pracy robota wyszukiwawczego do domeny zawodowej użytkownika. Wśród nich wymienimy następujące domeny:

• Bib-1 – domena bibliograficzna ( ftp://ftp.loc.gov/pub/z3950/defs/bib1.txt)
  

• GILS – domena usługi globalnej lokalizacji informacji (Global Information Locator Service ) 

  http://www.gils.net/locator.html

• STAS – domena nauki i techniki (Scientific and Technical ) http://www.cnidr.org/stas.html

• DL – domena zasobów bibliotek cyfrowych (Digital Library Collection )
    http://www.loc.gov/z3950/agency/profiles/collections.html

• CIMI – domena informacji o zbiorach muzealnych (Consortium for the Interchange of Museum Information ) http://www.cimi.org/index.html

• GEO – domena meta danych geoprzestrzennych [72] (Geospatial )
  http://www.fgdc.gov/publications/documents/clearinghouse/dlipaper395.html
  

• Union Catalogue – domena katalogu centralnego http://www.nla.gov.au/ucp/

Protokół definiuje dwa typy rekordów odpowiedzi, które mogą zostać nadesłane z Z-serwera: rekordy bazy danych oraz rekordy diagnostyczne. Rekordy bazy danych mogą zostać przesłane w jednej z kilku różnych składni (formatów), na przykład:




• MARC (USMARC, UNIMARC, UKMARC i CANMARC)

• SUTRS (Simple Unstructured Text Record Syntax) – do pobierania informacji pełnotekstowej

GRS1 (Generic Record Syntax) – do pobierania rekordów strukturalizowanych

• OPAC – (Online Public Access Catalog) – katalog publiczny on-line

• Summary – {składnia notatek bibliograficznych)

• Explain – (Bibliographic Summary Syntax) składnia Serwera Informacyjnego Z39.50

• Extended Services - składnia rekordów rozszerzonych usług
  

W trakcie opracowywania jest SQL-RS – składnia rekordów wspierająca typy danych SQL3 oraz XML. Ta ostatnia składnia wywołuje aktualnie gorące dyskusje na forum listy dyskusyjnej Z39.50 z uwagi na znaczną konsumpcję pamięci i pasma transmisyjnego w przypadku przesyłania rekordów, zawierających małe porcje danych. Tak np. zakodowanie pojedynczego bitu ‘1’ w XML pociąga za sobą 96-cio krotną ekspansję rozmiaru!

Typy rekordów diagnostycznych nie będą tu omawiane.

Po uzgodnieniu języka zapytań, Z-klient wysyła do Z-serwera przygotowane przez końcowego użytkownika zapytanie wyszukiwawcze, stosownie do składni, która została wcześniej wynegocjowana. Końcowym rezultatem tego procesu jest odesłanie komunikatu z podaniem liczby odnalezionych rekordów (ale nie ich zawartości). Jeśli zbiór rekordów nie jest pusty, cel może przejść do trzeciej fazy: pobierania informacji.

3. Pobieranie informacji (Retrieval Facility) na które składają się dwie usługi:

   • Prezentacja wyników wyszukiwania. Usługa prezentacji rozpoczyna się negocjacją 16 parametrów, wśród których na początku źródło zamawia określoną liczbę rekordów z określeniem miejsca pierwszego zamawianego rekordu. Wśród opcjonalnych informacji Z-klient może określić format przysyłanych danych (np. MS Word lub HTML), zakres przesyłanych rekordów czy wskazać konkretne elementy do przesłania (np. autora, tytuł oraz ISBN)

   • Segmentacja zbioru wyników. Jeżeli zamówione przez źródło rekordy nie mieszczą się w granicach wyznaczonych tym parametrem, wówczas cel uruchamia automatycznie segmentację zgromadzonej informacji.

4. Usuwanie zbioru będącego wynikiem wyszukiwania (Result-set-delete Facility)

5. Kontrola dostępu do danych (Access Control Facility). Usługa ta pozwala na poziomie Z-serwera nadzorować dostęp do bazy danych poprzez wprowadzenie mechanizmów uwierzytelnienia, czy też szyfrowania informacji kluczem publicznym.

6. Rozliczenie/kontrola zasobów (Accounting/resource Control Facility). Składają się nań trzy usługi:

• Kontrola zasobów (Resource–Control) – pozwala Z-serwerowi poinformować swego klienta o aktualnym, czy też przewidywanym poziomie konsumpcji zasobów bazy danych w stosunku do ustalonych limitów (ważne w przypadku odpłatnych usług dostępu do bazy danych). Klientowi pozostawiona zostaje możliwość przerwania lub kontynuacji Z-Asocjacji

• Wymuszenie kontroli zasobów (Trigger-resource-control). Pozwala klientowi na szybkie zorientowanie się w przebiegu niepokojąco przedłużającej się sesji wyszukiwania

• Raport (Resource-report). Pozwala klientowi na zażądanie raportu z zakończonej operacji lub Z-Asocjacji. Również serwer może bez wcześniejszych uzgodnień sporządzić i dostarczyć klientowi raport z nadzoru procesu przeszukiwania zasobów

7. Sortowanie (Sort Facility). Pozwala klientowi na posortowanie wyników (w przypadku wcześniejszej segmentacji poszczególne segmenty mogą zostać przed sortowaniem połączone w jedną całość)

8. Przeglądanie (Browse Facility). Możliwość przejrzenia (np. wg nazw, tytułów etc.) uporządkowanego zbioru

9. Wyjaśnienie (Explain Facility). Możliwość uzyskania szczegółowych informacji technicznych o Z-serwerze

10. Rozszerzone usługi (Extended Services Facility). Ułatwienia te dotyczą możliwości udostępnienia klientowi dostępu do usług nie zdefiniowanych w ramach Z-39.50, w szczególności tego, co klient oczekiwałby po zamknięciu Z-Asocjacji. Tu można wymienić automatyczne wykonanie tych samych poszukiwań po niezależnym od klienta uaktualnieniu bazy danych, lub wykonanie pewnych wsadowych wyszukiwań według określonego kalendarza, a także automatyczne dowiązanie usług oferowanych w ramach wypożyczalni międzybibliotecznej (Inter-Library Loan).

11. Zakończenie (Termination Facility). Z-Asocjacja może zostać zakończona zarówno po stronie Z-klienta, jak i Z-serwera.

Cechy sieciowe

Protokoł Z39.50 wersja 2 należy do klasy połączeniowych (ang. connection-oriented ) usług sieciowych (por. Bilski, Dubielewicz [1993]:153). Fakt ten w naturalny sposób sprzyjał dwom czynnikom: łatwej implementacji w sieciach X.25 opartych na rekomendacjach CCITT, oraz szybkiej adaptacji modelu przez ISO. Ze zrozumiałych jednak względów, amerykańscy twórcy specyfikacji Z39.50 wyraźnie ciążyli w stronę powszechnie zaakceptowanego w USA i burzliwie rozwijającego się Internetu. Jednakże protokoły TCP/IP służą do realizacji usług w sieciach lokalnych (LAN) w trybie bezpołączeniowym. Konflikt ten jest więc podobny do tego, który pojawia się w związku z problemem emulacji LAN w sieciach ATM. Rozwiązanie tego problemu byłoby stosunkowo proste do osiągnięcia w jednorodnym środowisku z zaimplementowaną Wersją 3 protokołu Z39.50. Natomiast w środowisku heterogenicznym nie jest to łatwe i wymaga dodatkowych zabiegów o ograniczonej skuteczności. Identycznie sprawa się ma z integracją Z39.50 z WWW - z uwagi na bezpołączeniowy charakter tego ostatniego.

Mimo formalnie podobnych specyfikacji warstwy aplikacji modelu ISO/ OSI, oprogramowanie zgodne z ANSI NISO Z39.50 wersja 2 nie komunikuje się bezpośrednio z oprogramowaniem zgodnym z ISO 10162/10163 z uwagi na odmiennie zdefiniowany stos protokołów warstw sieciowych i transportowych (por. Cechy sieciowe). Obejściu narosłych rozbieżności miał służyć realizowany przez trzy biblioteki europejskie (Irlandia, Dania i Hiszpania) projekt EUROPAGATE budowy adaptera międzysieciowego (bramki) - patrz Ciardhuain [1995]. Alternatywny projekt niemiecki "DBV-OSI II" ( patrz Herget [1995]), w którym oprócz kilku bibliotek niemieckich znajduje się również holenderska PICA przewiduje trójkanałowy dostęp do serwera SR-/Z39.50 (tak autorzy oznaczają tworzoną hybrydę ISO-ANSI). Ten ostatni projekt oprócz "czystych" wariantów dostępu (zestaw protokołów CCITT/ISO z jednej strony, zaś TCP/IP na warstwie fizycznej CSMA/CD z drugiej strony) przewiduje również wariant mieszany: standardowe usługi OSI warstw prezentacji i sesji posadawia się na warstwie transportowej TCP z uwzględnieniem zaleceń RFC 1006.

Pod względem sieciowym trzecia wersja protokołu Z39.50 w zasadzie usunęła wszystkie wady swego protoplasty. Zachowanie się aplikacji (7 warstwa modelu OSI/ISO) przestało zależeć od cech protokołu sieciowego (4 warstwa modelu OSI/ISO). Ponadto, dzięki protokołowi HTTP, Internet praktycznie zdominował komunikację w sektorach publicznych. Jednakże nie tylko atrakcyjność nowego protokołu warstwy aplikacji przyczyniła się do tego sukcesu. Sam protokół IP jest typu „lekkiego” i był zaprojektowany dla systemów o wysokiej niezawodności (Internet Protocol wywodzi się z projektu Departamentu Obrony USA). W odróżnieniu od niego protokół X.25 zaprojektowany został do pracy w środowisku o wysokim poziomie szumów i braki jakościowe w obszarze medium transmisyjnego wyrównywał algorytmicznie – kosztem szybkości transmisji. Po masowym wprowadzeniu technologii światłowodowej do warstwy fizycznej modelu współdziałania systemów otwartych błyskawicznie ujawniła się przewaga protokołu IP nad X.25: już w roku 1992 na rynku dostępne były interfejsy oferujące usługi IP poprzez szeregowy port synchroniczny 4 Mbps, podczas gdy w tym samym czasie najszybsza karta X.25 pozwalała na komunikację z szybkością 384 Kbps – ponad dziesięć razy wolniej! Mimo rychłego wprowadzenia przez operatorów telekomunikacyjnych protokołu Frame Relay (FR) - mutacji X.25 odciążonej od korekty błędów – dystans pomiędzy modelem ARPA i modelem ISO/OSI narastał nadal, prawdopodobnie umiejętnie moderowany przez gospodarczą strategię rządu USA.

W 2002 roku można zaryzykować opinię, że znaczna liczba problemów została już rozstrzygnięta. Aktualnie mamy na rynku kilka niezłych produktów – zarówno komercyjnych, jak i darmowych, w których nieźle rozwiązano problem heterogeniczności protokołów.

Implementacja

Pierwsza w Polsce szersza, publiczna prezentacja on-line wyszukiwań według standardu Z39.50 ver. 2 miała miejsce w 1994 r. w Gdańsku, podczas zorganizowanej pod auspicjami KBN konferencji polskich bibliotek naukowych. Szczegóły można znaleźć w opublikowanych materiałach konferencyjnych (Czermiński [1996]). Dla potrzeb ówczesnej prezentacji przetestowane zostały wówczas dwa pakiety klienta instalowanego w środowisku DOS/Windows: jeden komercyjny (VTLS) wersja 1.0 i wersja Alpha Test 2.0 oraz jeden klasy Public Domain (PD), opracowany na zlecenie Biblioteki Narodowej Kanady. Testowanych było kilkanaście niekomercyjnych amerykańskich serwerów i jeden holenderski (PICA - niekomercyjna baza testowa). Można było zaobserwować niepełną implementację zarówno w klasach produktu komercyjnego, jak i PD. Dotyczyło to zarówno klienta, jak i serwera, ale zwłaszcza serwera. Znaczna liczba serwerów udostępniała tylko testowe bazy, znacznie mniej - bazy eksploatacyjne (produkcyjne). Niektóre serwery udostępniały tylko rekordy uproszczone i to w wersji nie-MARCowskiej. Odnotowano znaczne rozbieżności co do implementacji poszczególnych atrybutów USE. Tak na przykład próba wyszukiwania w Bibliotece Kongresu książek jakiegokolwiek autora poprzez wybranie atrybutu "Author name" skończyła się fiaskiem. Serwer zwracał komunikat "Diagnostic Error 114. Unsupported USE attribute". Analogiczne wyszukiwanie w innych bibliotekach kończyło się sukcesem [75]. Do wyszukiwania tego typu w Bibliotece Kongresu należało posłużyć się atrybutem "Personal name". Testowane pakiety klienta miały poważne usterki, wśród których należy wymienić brak funkcjonowania szeregu zadeklarowanych w okienkach funkcji, takich jak SAVE, PRINT, NEW. Pakiet Z-klienta VTLSa był wyraźnie lepszy od testowanej wcześniej starej wersji 1.0, ale ciągle pozostawiał wiele do życzenia. Najmocniejszą stroną kanadyjskiego, darmowego produktu jest dostępność jego wersji źródłowej.

Testowany był wyłącznie dostęp przez Internet. Liczba rozłączonych lub przerwanych sesji była zdecydowanie wyższa, niż przy innych usługach internetowych (telnet, ftp, WWW). Ze względu na ubogą diagnostykę trudno było ocenić, czy przyczyn tego faktu należało doszukiwać się we wspomnianej wyżej niejednorodności trybu transmisji (połączeniowa - bezpołączeniowa), czy też w niepełnej implementacji standardu po stronie serwera (cel powinien być całkowicie odporny na każde pytanie zadane przez źródło). Użyte oprogramowanie kanadyjskie implementowało Wersję 2 standardu (1992) i było dostępne z anonimowego konta serwera FTP ftp.nlc-bnc.ca ( 142.78.40.4) lub serwera owl.nstn.ns.ca. Pliki celu umieszczone są w katalogu pub/irtool/target, zaś pliki źródła w katalogu pub/irtool/origin. Komplet plików źródła dla MS-Windows nazywa się CanSearch. System został zrobiony przez Software Kinetics Limited (Stittsville, Ontario, Canada) i sfinansowany przez Bibliotekę Narodową Kanady (NLC). System wymagał przynajmniej procesora 386 plus 4 MB RAM a jego dostęp do sieci realizował pakiet WINSOCK.

Obecnie znacznie bardziej popularne jest oprogramowanie implementujące ostatnią wersję protokołu Z39.50. Wymienimy tu przykładowe pakiety darmowe: ZedKit, Z-klienta ICONE dla Linuxa na procesorach Intela oraz dla MS Windows (Crossnet), ZNavigator Ver. 1, oraz Z39.50/PRISE (minimalna para klient-serwer Z39.50-1995 v.3 na UNIX Solaris, klient dla GUI wykonany w języku skryptów Tcl/Tk) - patrz U.S. Department of Commerce Technology Administration, National Institute of Standards and Technology (NIST). http://www-nlpir.nist.gov/works/papers/zp2/zp2.html . Propozycje komercyjne w większości przypadków zmierzają do rozwiązań typu „kombajn”, na które oprócz pary klient – serwer składają się narzędzia programistyczne, demony proxy, bramki do środowiska WWW, roboty wyszukiwawcze plików internetowych, applety Javy do wprowadzania meta-danych, narzędzia do tworzenia lokalnych baz danych.

Spośród dostępnych wersji przetestowany został Z-klient ICONE w wersji 32-bitowej na MS Windows NT oraz ZNavigator. Jest rzeczą ciekawą, że podobnie jak to miało miejsce z Z-klientami wersji 2, testowanymi pięć lat wcześniej, testy wykazały mizerę opisu bibliograficznego testowanych serwerów. Nadal typowe Z-serwery udostępniają bazy testowe, a nie produkcyjne. Z obydwu przetestowanych klientów bezdyskusyjnie lepszy był ZNavigator. On też został wybrany w charakterze pakietu pokazującego pewne fragmenty otwierania Z-asocjacji i realizacji pewnych usług. Testowym Z-serwerem był HLC.ACTX.EDU administrowany przez Harrington Library Consortium z danymi zarządzanymi przez system bardzo popularnej i oferującej wielki wybór usług (łącznie ze współbieżnym przeszukiwaniem wielu baz i serwerów) bazy MARION. Przytoczone zrzuty ekranu ilustrują kolejne fazy zawężania odpowiedzi Z-serwera, zmierzające do lokalizacji Nędzników V. Hugo w bibliograficznej bazie danych. Okienko klienta związane z tworzeniem kolejnych zapytań pozwala śledzić rozrastanie się struktury drzewiastej odpowiadającej liniowej składni Odwrotnej Notacji Polskiej. Ten spektakularny chwyt projektanta interfejsu graficznego testowanego Z-klienta znakomicie ułatwia zrozumienie funkcjonowania genialnego pomysłu naszego wielkiego rodaka.

ZNavigator pozwala grupować Z-serwery w grupy zasobów. Pakiet dostarczany jest z utworzonymi trzema grupami o nazwach: Geo, Samples oraz Ztargets oraz możliwościami utworzenia nowej grupy, lub jej usunięcia. W każdej z grup oprogramowanie to pozwala dodać nowy Z-serwer, edytować istniejący, usunąć niepożądany lub ustalić wybrany jako domyślny. Na Rysunku 39 podano przykładowy wybór celu (inaczej mówiąc Z-serwera) w grupie zasobów oznaczonej ZTargets.

Rysunek 39. Wybór celu (Z-serwera) w danej grupie zasobów.

Funkcja edycji parametrów Z-serwera pozwala zmieniać siedem opcji: opis zasobu, nazwę hostu, numer portu TCP/IP, nazwę bazy danych, składnię rekordu, nazwę konta oraz hasło. Na Rysunku 40 podana jest przykładowa edycja parametrów dla serwera Harrington Library Consortium.

Rysunek 40. Edycja parametrów serwera Z39.50.

Rysunek 41. Kreator Zapytań.

Rysunek 42. Wynik wyszukiwania prostego (hasło osobowe).

Rysunek 43. Obraz złożonego wyszukiwania tworzony przez Kreator Zapytań w kategoriach Odwrotnej Notacji Polskiej.

Rysunek 44. Wynik wyszukiwania złożonego.

Proponowane przez trzecią wersję standardu mechanizmy dają do rąk użytkownika wspaniałe narzędzia. Do nich należy między innymi filtracja rekordów według rdzenia (ang. stem) kategorii wyszukiwawczej. Celem poniższego przykładu jest wyszukanie wszystkich rekordów, które na dowolnym miejscu strefy tytułu skatalogowanej pozycji wydawniczej zawierają słowo XML. Na rysunku 45 przedstawiony jest wypełniony formularz kreatora zapytań z otwartym fragmentem listy możliwych opcji operatora relacji, wśród których wymieniony jest rdzeń.

Rysunek 45. Budowanie zapytania pozwalającego wyszukać rekordy zawierające słowo XML zlokalizowane na dowolnym miejscu strefy tytułu.

Rysunek 46. Lista rekordów zawierających słowo XML w strefie tytułu.

Przyczynę, dla której wyselekcjonowany został rekord numer 4 (brak w wyświetlonym tytule na­pisu XML), można wykryć dopiero po wyświetleniu pełnego opisu w formacie USMARC (Rysunek 47). Napis ten znajduje się w polu 246.

Rysunek 47. Rekord zawierający słowo XML w strefie tytułu (USMARC).

Bogate omówienie różnych implementacji standardu Z39.50 można znaleźć na sieci pod następującymi adresami:
http://lcweb.loc.gov/z3950/agency/resources/software.html
http://archive.dstc.edu.au/RDU/reports/zreviews/z3950-client-survey.html

Wyszukiwanie współbieżne (równoległe)

Projekt trzeciej wersji Z39.50 wśród oferowanych usług przewidywał możliwość realizacji współbieżnego wyszukiwania w kilku bazach danych jednego serwera, lub na kilku serwerach równocześnie. Mimo oficjalnej implementacji tej usługi na szeregu serwerach dopiero po 7 latach od oficjalnego opublikowania trzeciej wersji standardu duńska firma Index Data opublikowała wyniki pierwszych testów w wyszukiwaniu równoległym, udostępniając zarazem dla testów darmowy pakiet klienta do wyszukiwania równoległego ParaZ. Oprogramowanie zostało napisane w języku C i uruchamiane jest pod Linuxem. Szczegóły testu oraz hiperłącze do niezbędnego oprogramowania (w tym dodatkowego pakietu YAZ) znajdują się pod URL: http://www.indexdata.dk/paraz.

Z obszernego, zamieszczonego tam uprzednio dokumentu: Issues in Z39.50 Parallel Searching autorstwa Hammera i Andresena wynikało, że intencją autorów tej inicjatywy było przebadanie możliwości utworzenia wirtualnego centralnego katalogu w oparciu o system Z-serwerów. Dość zaskakujące są niektóre wnioski wyprowadzone z eksperymentu: autorzy spostrzegli, że przyczyna leniwego przebiegu eksperymentu nie leżała ani po stronie sieci, ani po stronie klienta – ale po stronie serwerów. Doprawdy wcale nie było potrzeba wykonywać takiej pracy, żeby wyprowadzić podobny wniosek! Dobrze się jednak stało, że ktoś zaczął spostrzegać pewne fakty: Czy współbieżne wyszukiwania w setkach, czy nawet tysiącach serwerów są realistyczne jako część mocno używanych systemów produkcyjnych? Biorąc pod uwagę bieżący poziom technologii, to może być wyzwaniem i może wymagać znacznych nakładów na systemy poszczególnych serwerów – piszą autorzy raportu.

Autor niniejszej książki testował duńskiego klienta ParaZ i niezależnie od prymitywnej technologii, która została użyta, ma bardzo krytyczny stosunek do samej idei współbieżnego wyszukiwania. Tego rodzaju narzędzie inicjujące współbieżność wyszukiwania w rękach masowego użytkownika baz danych może dosłownie „zarżnąć” wszystkie światowe serwery, które zaimplementują tą usługę (implementują ją praktycznie wszystkie serwery duńskie – ok. 13% wszystkich Z-serwerów, przy stosunkowo daleko idącej wstrzemięźliwości serwerów amerykańskich wobec implementacji tej usługi). Czego katastroficznego można oczekiwać w inkryminowanej usłudze, to błyskawicznego wyczerpania się limitów licencyjnych i całkowitej niewydolności systemów dyskowych. W rachubę też wchodzi blokada portów dostępowych serwerów wielkim strumieniem pakietów (nieświadome spowodowanie odmowy usługi masowo zlecanej przez rozproszonych po świecie klientów, Distributed Denial of Service - patrz Rozdział 3.). Pokusa współbieżnego wyszukiwania jest ogromna, lecz w przypadku masowej implementacji jej skutki będą zabójcze. Ostatnio zagadnienie to dyskutował u nas Padziński [2000], ale raczej od strony teoretycznej, niż praktycznej. Mimo serdecznej sympatii i szacunku wobec tego świetnego bibliotekarza i uroczego kolegi, autor pragnie tu wyrazić swoją głęboką dezaprobatę dla promocji tej nieodpowiedzialnej usługi.

Czy można zrealizować zadanie współbieżnego przeszukiwania serwerów poza platformą Z39.50 ? Odpowiedź na to pytanie jest twierdząca. Jako przykład systemu oferującego współbieżne wyszukiwanie zrealizowane w klasie skryptów CGI (Common Gateway Interface) można podać bardzo ceniony wirtualny katalog biblioteki uniwersyteckiej w Karlsruhe dostępny poprzez URL: http://www.ubka.uni-karlsruhe.de/hylib/en/kvk.html. Sporo szczegółów technicznych dotyczących tego projektu zostało opublikowanych przez jego autorów (Dierolf, Mönnich [1996]). Tekst tej publikacji jest dostępny również w formacie HTML pod URL: http://www.rz.uni-karlsruhe.de/Uni/RZ/Schriften/RZ-News/96/Sep/. Jednak i tu, podobnie jak i w przypadku Z39.50, należy zniechęcać do korzystania z usługi współbieżnego wyszukiwania.

Podsumowanie

Standard Z39.50 znajduje się niewątpliwiew fazie zaawansowanego rozwoju. Nowe wersje standardu (zwłaszcza najnowsza z 1995 roku) są już znacznie lepsze od protoplasty z 1988 roku, i cechują się poprawieniem i uproszczeniem procesu obsługi końcowego użytkownika.

Zaimplementowanie standardowych ułatwień i usług jest w trzeciej wersji Z39.50 ogromnie zróżnicowane. Wbrew przypuszczeniom przodującej roli nie odgrywa tu ani Biblioteka Kongresu USA ani MIT. Ciekawą statystykę przytaczają Duńczycy ( http://bagel.indexdata.dk/targettest/targetstat.shtml) po przetestowaniu 224 Z-serwerów z 374 zainstalowanymi bazami danych. Spośród 14 usług - wyszukiwanie i prezentacja zaimplementowane są na wszystkich testowanych serwerach, natomiast scan wspiera już tylko ¾ Z-serwerów. Usługi sortowania, przypisywania nazwy zbiorom wyników oraz usuwania zbioru wyników oferuje praktycznie tylko ich połowa. Rozszerzone usługi, operacje współbieżne oraz kontrola zasobów występują w przybliżeniu na co czwartym serwerze – cała reszta w zasadzie jest wspierana prawie dokładnie przez 15% wszystkich serwerów.

Z pewną nostalgią należy odnotować, że dawny, dobry obyczaj przypisywania protokołowi Z39.50 portu 210 należy do przeszłości. Choć nadal jest to najczęściej używany numer portu, tym niemniej w użyciu są również porty 2020 , 2100 , 2210 , 2200 , 3951, 6007,  6674 , 6671, 7090 i inne. Polityka przypisywania numeru portu do różnych baz danych jest bardzo zróżnicowana. Tak np. Colorado Alliance of Research Libraries przypisuje wspólny numer portu 210 do wszystkich posiadanych baz (AIM, ARA , BEM, CDE, CSP, DPL, EST, FTM, LAM, LUT, MCC, MIN, NEL, NEU, NJC, OTE, PPC, PUE, RGU, RRC, STR, TKO, TRI, WYO) ulokowanych na tym samym serwerze. Natomiast CIESIN przypisuje bazie gils port 6007, bazie atsdr port 6024, bazie usda port 6020 – a wszystko na tym samym serwerze infoserver3.ciesin.org. Oczywiście dane te są konieczne przy dopisywaniu nowego Z-serwera do pliku konfiguracyjnego Z-klienta i w zasadzie tzw. zwykłego użytkownika mało obchodzą (Z-serwer jest wybierany z preinstalowanej listy rozwijalnego menu). Klient ICONE w testowanej wersji nie dostarcza użytkownikowi narzędzia pozwalającego na samodzielne konfigurowanie dostępu do nowego Z-serwera i wpisywanie lub modyfikację adresu portu serwera. Narzędzie takie jest natomiast dostarczane przez ZNavigator. Trzeba jednak tu od razu nadmienić, że konfigurowanie Z-klienta wersji 3 uchodzi za raczej trudne i wymaga znacznej ostrożności i doświadczenia.

Bardzo ciekawe wyniki dotyczą wsparcia dla składni rekordu (record syntax) [77]. Tu bezdyskusyjny prym wiedzie USMARC, który wspiera ¾ instytucji eksploatujących Z-serwery. Następna pozycja na liście – SUTRS (28%) – jeszcze jest zrozumiała z uwagi na zainteresowanie, jakim cieszą się pełnotekstowe bazy danych. Natomiast zdumiewająco niska wydaje się być lokalizacja na liście składni Unimarc i składni jej pokrewnych (UKmarc , Ibermarc, Normarc, Picamarc, Danmarc, Intermarc, Librismarc, Jpmarc) wszystkich zajmujących koniec listy z zainteresowaniem nie przekraczającym 3%.

Warto w podsumowaniu podkreślić, że posługiwanie się dobrym Z-klientem jest dla użytkownika prawdziwą przyjemnością - pod warunkiem, że kontaktuje się z Z-serwerami hojnie wyposażonymi przez ich twórców w odpowiednie usługi. W szczególności piszący te słowa odnosi je do testowanej wersji ZNavigatora. Należy mieć nadzieję, że technologia Z stanie się wkrótce bardziej popularna w Polsce, a zasoby informacji na świecie, dostępnej dzięki tej technologii będą się stawały coraz lepsze.

Perspektywy rozwojowe tego standardu nie są oczywiste. Trzecia jego wersja jest już produktem dojrzałym, ale z pełną jej implementacją na poziomie serwerów ciągle są problemy. Jeszcze na dobre ten standard nie zadomowił się w bibliotekach, a już w 2001 roku pod nazwą ZNG (Z39.50 Next Generation) pojawiła się inicjatywa, wzywająca do zaprojektowania od nowa całego protokołu ( http://www.loc.gov/z3950/agency/zng.html). Nowa propozycja zakłada, że protokoł będzie bezpołączeniowy, a wszystkie rekordy będą pobierane zgodnie ze składnią XML. Z planowanych do odrzucenia cech Z39.50 można wymienić zapytania w notacji RPN, opis składni zgodny z ASN.1, sesje i połączenia. ZNG wprowadza język zapytań o nazwie CQL (ang. Common Query Language), bazujący na znanym CCL, ale o nieco innym charakterze. Nowy protokoł ma w zasadniczy sposób oprzeć się na Web-ie, definiując pojedynczą, zintegrowaną webową usługę wyszukiwania i prezentacji.

Założenia ZNG wydają się być rozsądne i przekonywujące. Jeszcze trudno ocenić, na ile chętnie nowy protokół będzie wdrażany przez biblioteki i systemy informacyjne. Jedno nie ulega wątpliwości – idea wyszukiwania i pobierania informacji za pomocą tak dobrze zaprojektowanego narzędzia, jakim jest Z39.50, nie umiera. Projekt ten jest dobrze zarządzany i realizacji jego nieustannie towarzyszy innowacyjność.

[63]ten sam, który wprowadził beznawiasowy zapis wyrażeń formalnych, zaadaptowany przez firmę Hewlett-Packard (obecnie HP Invent) do sterowania pracą rejestru przesuwnego i nazwany na cześć twórcy zapisu Reverse Polish Notation, RPN (Odwrotna Polska Notacja).

[72] do chwili oddawania do druku brak terminu polskiego. Proponowany termin wypracowano w drodze konsultacji ze środowiskiem geografów.

[75] Obecna wersja (tzn. 3) Z-serwera Biblioteki Kongresu już poprawnie obsługuje w domenie Bib-1 wartości atrybutów 1003 (Author), 1004 (Author-name personal), 1005 (Author-name corporate).

[77] Określenie ‘syntax’ stosowane jest w całej technologii Z zamiast skądinąd powszechnie używanego określenia ‘format’.