Na temat korzystania z Z39.50 opublikowano RFC-2056 [] dotyczące sposobu adresowania zapytań. Propozycje nie są na razie implementowane, producenci oprogramowania stosują swoje własne konwencje formułowania zapytań.
Pomysł utrzymywania parametrów serwerów Z39.50 w usłudze LDAP jest motywowany trudnością konfiguracji oprogramowania klienckiego. Przykładem podobnego rozwiązania mogą być prace nad opisem ExplainLite [] tworzonym w języku XML. Zakładamy, że w bazie LDAP będzie można przechowywać również konfigurację w formacie XML (jako wartość wydzielonego atrybutu).
Bezpośrednią motywacją do zajęcia się protokołem Z39.50 w ramach projektu LDAP są równoległe prowadzone prace rozwojowe nad katalogiem rozproszonym KaRo[].
Podstawowym celem niniejszego dokumentu jest określenie sposobów przechowywania konfiguracji w ramach bazy LDAP oraz odpowiednie zdefiniowanie grupy parametrów konfiguracyjnych typowego serwera protokołu Z39.50. Obecna analiza ma na celu przygotowanie podstaw implementacji prototypowego rozwiązania. Proponowany standard schematu LDAP będzie w przyszłości wymagał rozbudowy, tak by objąć wszystkie aspekty protokołu Z39.50.
Na jednym komputerze może pracować wiele instancji serwera Z39.50
Jedna instancja serwera Z39.50 może obsługiwać wiele baz.
Z punktu widzenia użytkownika najistotniejszym obiektem jest baza.
Użytkownik systemu Z39.50 korzysta z bazy, którą zazwyczaj kojarzy z instytucją. Parametry techniczne (adres serwera, port, identyfikator bazy w serwerze) są dla niego całkowicie nieistotne i niee powinny być dla niego widoczne.
Dostęp do bazy za pośrednictwem protokołu Z39.50 wymaga określenia szeregu dodatkowych parametrów. Protokół definiuje szereg operacji, z których najważniejsze to:
Operacje search i scan wymajają określenia atrybutów przeszukania, te określa się zazwyczaj przy pomocy standardu Bib-1 []. Ten standard przyporządkowuje najbardzije typowym rodzajom zapytań (np. autor, tytuł, wydwanictwo itd.) wartości numeryczne. Poza atrubutami określającymi temat zapytania, Bib-1 definiuje również atrybuty relacji, pozycji i struktury. Relacje to równość i nierówności, pozycja określa ogreniczenia położenia napisu wyszukiwanego w wyrażenia odnalezionych, struktura pozwala na wprowadzenie dodatkowych ograniczeń, np., aby dopasowanie wyszukiwało wyłącznie pełne słowa.
Określenie właściwego zestawu parametrów może zależeć zarówno od ustawień samej bazy (np. zdefiniowanych i udostępnianych indeksów), jak i implementacji. Czasami zmiana parametrów struktury prowadzi do zaskakujących rezultatów, z tego powodu konieczne jest dostrojenie całego zestawu parametrów do konkretnego rodzaju zapytania.
Kolejną trudność sprawiają formaty wyników. Informacja bibliograficzna jest zapisywana z w różnych standardach. Obecnie najbrardziej rozpowszechniony jest zapis w jednej z wersji MARC, ale coraz popularniejsze staje się prezentowanie wyników w formacie XML. Niezależnie od samego formatu opisu, konieczne jest wzięcie pod uwagę sposobu kodowania znaków diakrytycznych. W tym zakresie spotykamy się również z wieloma możliwościami. Nowoczesne implementacje używają UTF-8, starsze stosują jedną z kilku konwencji rozpowszechnionych wcześniej. Niekiedy sam serwer Z39.50 dokonuje przekodowania w locie na jakąś stronę kodową (co wiąże się zazwyczaj z utratą informacji). W przypadku rozbudowanego opisu zawierającego obok opisu bibliograficznego również informację o egzemplarzach, zdarza się, że część bibliograficzna jest kodowana inaczej niż część dotycząca egzemplarzy. Kolejnym zagadnieniem jest kodowanie wyrażenia wyszukiwawczego, które może być również inne od dotychczas wymienionych. Serwery Z39.50 działające w Polsce prezentują pełną gamę możliwych rozwiązań.
Konfiguracja oprogramowania dostępowego do protokołu Z39.50 jest zazwyczaj zapisywana w plikach tekstowych.
Polski katalog rozproszony KaRo [] jest systemem eksploatowanym od lipca 2001 i w tym czasie uzyskał znaczną popularność. Obecne (luty 2002) dzienne liczby przeszukań przekraczają 5000, a maksimum godzinne 1000.
Wadą katalogu rozproszonego jest to, że bardzo wiele przeszukań obciąża niewielkie serwery lokalne. Może to być szczególnie uciążliwe w sytuacjach kiedy na jednym komputerze zainstalowano wiele baz. O ile przeszukania pojedynczych baz na ogół rozkładają się w czasie w taki sposób, że komputer nie jest przeciążany, to przeszukanie rozproszone jest realizowane jednocześnie na wszystkich bazach i może prowadzić do bardzo istotnego spadku wydajności bazy. Wielokrotne odwołania do tej samej bazy (przez różnych użytkowników) mogą używać zbyt dużej liczby licencji i w konsekwencji uniemożliwiać użytkowanie bazy nawet przez jej właścicieli. Dotychczasowe doświadczenia pokazują, że należy brać pod uwagę następujące ograniczenia systemu Z39.50:
Proponowane rozwiązanie powinno:
Większość znanych programów korzystających z protokołu Z39.50 używa z tekstowych tablic konfiguracyjnych. Proponowane rozwiązanie powinno umożliwiać tworzenie odpowiednich tablic poprzez kontakt z bazą LDAP. Ponieważ każdy program ma inny format tablicy, należy uwzględnić kilka najbardziej znanych.
Należy przyjąć, że użytkownik jest zainteresowany konkretną bazą danych skojarzoną z instytucją (np. biblioteką) co w naturalny sposób przekłada się na fragment drzewa DIT. Najwłaściwszą wydaje się struktura oddzielnej gałęzi z zawierającej instytucje, a pod nimi bazy danych. Innym dopuszczalnym rozwiązaniem jest korzystanie globalnej bazy LDAP i przechowywanie danych konfiguracyjnych w obiekcie zdefiniowanym poniżej poziomu konkretnej instytucji (biblioteki).
Katalog rozproszony powinien umożliwiać przeszukiwanie grupy baz wybranych z płaskiej listy. Katalog powinien uwzględniać opisane powyżej ograniczenia wydajnościowe.
Katalog rozproszony powinien zezwalać na wyświetlanie podlisty ograniczanej jakimś kryterium, np. lokalizacją bazy, typem implementacji, specjalizacją biblioteki itd. Najwłaściwsza konfiguracja drzewa, to płaska lista opisów baz. Podlista może być tworzona jako wynik opracji ldapsearch z odpowiednim filtrem.
Z powodów wygody zarządzania, najwłaściwszą strukturą DIT jest odwzorowanie obiektów opisanych w p. 2, a zatem komputer jako obiekt nadrzędny dla instancji serwera Z39.50, będących z kolei obiektami nadrzędnymi baz.
Z wyjątkiem limitów wydajnościowych, wszystkie parametry elementów systemu Z39.50 mogą być przenoszone w dół drzewa konfiguracji technicznej. Niepotrzebne przenoszenie parametrów w dół jest jednak wadą, kiedy trzeba dokonać zmiany konfiguracji (na przykład adresu internetowego komputera), w takiej sytuacji wystąpi konieczność poprawienia adresów w wielu obiektach, co może źródłem błędów.
Wydaje się, że najwłaściwszym rozwiązaniem jest dopuszczenie występowania atrybutów opisujących elementy systemu Z39.50 na wszystkich poziomach gałęzi technicznej, z założeniem automatycznego dziedziczenia atrybutów w dół. Wystąpienie niepustego atrybutu na poziomie niższym automatycznie wyłącza dziedziczenie tego atrybutu na ten poziom. Z uwagi na specyficzne właściwości implementacji serwerów Z39.50 właściwe jest wprowadzenie szablonów konfiguracyjnych, do których można się odwołać. Podobnie jak w przypadku dziedziczenia, odpowiednie atrybuty szablonu są wyłączane jeżeli w opisie wystąpi niepusty atrybut danego typu. Szablony są przechowywane w oddzielnym fragmencie drzewa LDAP, w podobny sposób jak elementy systemów Z39.50.
Z powodu powyższych założeń każdorazowy odczyt parametrów bazy jest związany z czteroma operacjami odczytu w bazie LDAP, a następnie odpowiednim zhierarchizowaniem wyników (z uwzględnieniem ograniczeń dziedziczenia). Wspomniane operacje są operacjami odczytu, a nie przeszukania, więc nawet przy korzystaniu z bazy LDAP w trybie on-line nie powinny powodować zauważalnego opóźnienia.
Konfiguracja techniczna ma sens wyłącznie dla odpowiedniej implementacji katalogu rozproszonego. Tylko katalog rozproszony może stosowa ograniczenia wydajnościowe. Również tylko dla katalogu rozproszonego sensowna jest stosowanie profili implementacji itp.
Na podstawie powyższego opisu można stwierdzić, że w bazie LDAP należy przechowywać opisy obiektów Z39.50 w postaci nieustrukturalizowanej (patrz 4.1 i 4.2) oraz ustrukturalizowaniej (4.3). Jeżeli opis jednej bazy występuje w obu formach, to należy zadbać o ich synchronizację.
Dotychczasowe doświadczenia wskazują, że właściciele baz nie zawsze zatrudniają informatyków, którzy są w stanie prawidłowo określić parametry swoich serwerów Z39.50. Z powodu niejednorodności implementacyjnych wiele parametrów należy ustawiać metodą prób i błędów. W zależności od przypadku, synchronizacja obiektu ustrukturalizowanego i nieusturukturalizowanego powinna przebiegać w jednym bądź drugim kierunku. Zaproponujemy rozwiązanie, które będzie uwzględniało oba warianty.
Każda baza (w postaci ustrukturalizowanej lub nie) może posiadać atrybut wskazujący na obiekt który powinien być z nią synchronizowany, jak i obiekt, z którym należy się synchronizować. Umieszczenie takich wskazań pozwoli na implementacji synchronizacji w standardzie push inicjowanie synchronizacji przez modyfikację obiektu nadrzędnego, jak i pull inicjowanie synchronizacji przez obiekt podrzędny, w stałych odstępach czasu. Mamy tu do czynienia z klasycznymi modelami replikacji (z tym, że opisana synchronizacja następuje między obiektami o różnej strukturze).
Obiekt ustrukturalizowany
| element opisu | poziom, na którym może wystąpić |
| adres IP | komputer |
| port TCP | serwer |
| nazwa instytucji | komputer, serwer, baza |
| URI instytucji | komputer, serwer, baza |
| DN instytucji | komputer, serwer, baza |
| wewnętrzna nazwa bazy | baza |
| opisowa nazwa bazy | baza |
| szablon | komputer, serwer, baza |
| nazwa implementacji | komputer, serwer |
| wersja implementacji | komputer, serwer |
| dodatkowy parametr określający | komputer, serwer |
| parametry autoryzacyjne | serwer, baza |
| obsługiwane operacje Z39.50 (init, scan, search, present, explain, delete itd.) | serwer, baza |
| określenie obsługiwanych formatów opisów (USMARC, OPAC, GRS-1, itd.) | komputer, serwer, baza |
| kodowanie w opisie bibliograficznym (UTF-8, ALA, ISO-LATIN-?, itd.) | komputer, serwer, baza |
| kodowanie w innych obszarach wyniku (elementy opisu egzemplarza, wyniki operacji scan, itd.) (j.w.) | komputer, serwer, baza |
| kodowanie danych wejściowych (wyrażeń wyszukiwawczych) (j.w.) | komputer, serwer, baza |
| obsługiwane indeksy wyszukiwawcze | komputer, serwer, baza |
| obsługiwane atrybuty dopasowania i relacji | komputer, serwer, baza |
| liczba dozwolonych operacji równoczesnych | komputer |
| liczba dozwolonych przeszukań równoczesnych | komputer |
| liczba dozwolonych dowiązań równoczesnych | komputer, serwer, baza |
| wskazanie obiektu podrzędnego | baza |
| wskazanie elementu nadrzędnego | baza |
| parametry autoryzacyjne procesu synchronizującego | baza |
Uwagi:
Przy opisie obsługiwanych indeksów wyszukiwawczych należy uwzględnić:
Przy opisie obsługiwanych atrybutów dopasowania i relacji należy uwzględnić:
Z uwagi na to, że większość obiektów standardu Z39.50 posiada przypisane im identyfikatory (OID), wszędzie gdzie to możliwe należy unikać wartości tekstowych zamieniając je na wartości OID zgodne z standardem. Oznacza to, że docelowo obsługa drzewa LDAP będzie wymagała specjalizowanego narzędzia operującego rozwijalnymi listami.
Opis obiektu nieustrukturalizowanego może zawierać każdy z elementów opisu obiektu ustrukturalizowanego z wyjątkiem:
1 http://www.one-2.org/ rfc-2056 Uniform Resource Locators for Z39.50. R. Denenberg, J. Kunze, D. Lynch. November 1996. http://karo.umk.pl http://www.loc.gov/z3950/agency/defns/bib1.html Bib-1 Attribute SetZZ