Baza LDAP jako repozytorium paramertów konfiguracyjnych serwerów protokołu Z39.50

Tomasz Wolniewicz
UMK

Wstęp

Zgodnie z założeniami zawartymi w raporcie [1] przygotowano schemat wspomagający obsługę protokołu Z39.50 oraz załadowano parametry serwerów Z39.50 najważniejszych polskich bibliotek. Otrzymane drzewo LDAP zawiera zarówno szablony odpowiadające typowym implementacjom, jak i wpisy dla pojedynczych katalogów.

Przygotowany schemat został podzielony na dwie części:
Całość składa się ze schematów (z3950.schema - załącznik 1, karo.schema - załącznik 2), drzewa szablonów (templates), drzewa komputerów (hosts) i drzewa katalogów (libraries). Dodatkowo, na użytek oprogramowania konfigurującego parametry, wprowadzono wpis zawierający wszystkie dopuszczalne wartości parametrów konfiguracyjnych.

Terminologia

W kontekście protokołu Z39.50 serwerem na ogół nazywa się oprogramowanie obsługujące ten protokół. W związku z tym, w ramach niniejszego opracowania słowo serwer będzie zawsze używane w tym kontekście. Słowa serwer często używa się również na określenie komputera, ale aby uniknąć nieporozumień, w tym znaczeniu stosujemy wyłącznie słowo komputer.
Poprzez katalog rozumiemy w istocie instancję serwera Z39.50 obsługująca konkretną bazę bibliograficzną. Katalog jest zatem identyfikowany przez adres internetowy komputera, port, na którym uruchomiono instancję serwera oraz nazwę bazy identyfikującą katalog. Z katalogiem wiąże się też nazwę, która pozwala go identyfikować, na ogół jest to nazwa instytucji związanej z danym katalogiem bibliotecznym.
Podstawowe pojęcia związane z opisem protokołu Z39.50 zostały zawarte w [1].

Operacje Z39.50

Standard przewiduje zestaw kilku operacji obsługiwanych przez serwer, z których najważniejszymi są: przeszukanie (search), przeglądanie indeksu (scan), prezentacja wyników (present). Te trzy operacje wystarczają do obsługi większości typowych zapytań. Zapytania (search i present) zawierają wzorzec, który ma być wyszukany w bazie. Dodatkowe atrybuty wskazują na sposób dopasowania wzorca do napisów występujących w bazie (na przykład, czy wyszukany napis ma być w całości zgodny ze wzorcem, czy wzorzec ma być jednym ze słów napisu, czy napis ma się rozpoczynać od wzorca itp.). Pomimo jednoznacznego określenia znaczenia dodatkowych atrybutów przez standard Z39.50, producenci oprogramowania implementują te znaczenia w różny sposób. Dodatkowym problemem jest to, że nie wszystkie indeksy są obsługiwane w taki sam sposób, to znaczy w zależności do rodzaju wyszukania dostępne są tylko niektóre zestawy atrybutów dodatkowych. Aplikacje klienckie protokołu Z39.50, które mają korzystać z dostępu do wielu baz, są zazwyczaj konfigurowane poprzez pośredni etap operacji opisanych etykietami tekstowymi. Na przykład operacja "isdnexact" może oznacza wyszukanie ze względu na numer ISDN z dokładnym dopasowaniem do wzorca, a "authortrunc" wyszukanie ze względu na nazwisko autora z dopasowaniem z lewej strony. W zaimplementowanym schemacie przewidziano zarówno wyliczenia operacji standardowych obsługiwanych przez serwer (search, scan, present), jak też operacji uszczegółowionych (typu isdnexact, authortrun itp.). Ponieważ nazwy operacji uszczegółowionych nie są w żaden sposób zestandaryzowane, to zestaw dopuszczalnych określeń jest również przechowywany w drzewie, a ich podstawowe znaczenia określa domyślny szablon.

Katalogi i ich opis

Typowy wpis katalogu wygląda jak poniżej:
dn: cn=LOC, ou=libraries, dc=karo, dc=pl
objectClass: karoServer
cn: LOC
ipHostNumber: z3950.loc.gov
ipServicePort: 7090
z3950databaseName: voyager
z3950databaseUFN;lang-en: Library of Congress
z3950databaseUFN;lang-pl: Biblioteka Kongresu USA
labeledURI: http://www.loc.gov
z3950supportedFineOperation: authortrunc
z3950supportedFineOperation: authorbrowse
z3950supportedFineOperation: titletrunc
z3950supportedFineOperation: titlebrowse
z3950supportedFineOperation: isbnexact
z3950supportedFineOperation: issnexact
z3950supportedFineOperation: seriestrunc
z3950supportedFineOperation: seriesbrowse
z3950supportedFineOperation: subjecttrunc
z3950supportedFineOperation: subjectbrowse
z3950supportedFineOperation: publishertrunc
z3950supportedFineOperation: publisherbrowse
z3950supportedSyntax: 1.2.840.10003.5.10
z3950implementationName: Voyager
z3950marcOutputEncoding: ALA
z3950supportedOperation: search
z3950supportedOperation: present
Uzupełnieniem opisu serwera jest opis operacji uszczegółowionych (na które wskazują wartości atrybutów z3950supportedFineOperation). Przykładowo wpis określający operację "authortrunc" może być zdefiniowany jako:
dn: cn=authortrunc,cn=default,ou=templates, dc=karo, dc=pl
objectClass: z3950attribute
cn: authortrunc
z3950operation: search
z3950attributeUFN;lang-pl: Autor
z3950attributeUFN;lang-en: Author
z3950useAttribute: 1003
z3950structureAttribute: 1
z3950truncationAttribute: 1
Opis ten oznacza, że należy korzystać z operacji "search" ze względu na atrybut Bib-1 o numerze 1003 (autor) oraz dodatkowych atrybutach Bib-1 - structure i truncate o wartościach 1.
Innym przykładem operacji uszczegółowionej może być authorbrowse" oznaczająca przeglądanie indeksu autorskiego jest domyślnie zdefiniowana jako:
dn: cn=authorbrowse,cn=default,ou=templates, dc=karo, dc=pl
objectClass: z3950attribute
cn: authorbrowse
z3950operation: scan
z3950attributeUFN;lang-pl: Autor
z3950attributeUFN;lang-en: Author
z3950useAttribute: 1003
W tym przykładzie używana jest operacja "scan" ze względu na atrybut Bib-1 o numerze 1003 (autor), bez dodatkowych atrybutów sterujących.
Atrybuty z3950attributeUFN występują w dwóch wersjach językowych (polskiej i angielskiej) i służą do ustawienia parametrów wyświetlania w interfejsie użytkownika.
W opisie serwera występują jedynie nazwy operacji uszczegółowionych, które trzeba zamienić na prawdziwe operacje protokołu Z39.50 (z uwzględnieniem wszystkich parametrów). Konieczne jest zatem stworzenie mechanizmu przemapowania nazw operacji uszczegółowionych na ich opisy. W przedstawianej implementacji przyjęto, że opisy operacje uszczegółowione mogą być definiowane w dwóch miejscach: w ramach serwera lub w ramach szablonu (o ile jest stosowany). Jeżeli operacja nie jest definiowana w żadnym z tych miejsc, to przyjmowane są ustawienia domyślne.

Szablony

Ponieważ wiele ustawień występujących w opisie serwera jest wspólne dla dużej grupy katalogów, to aby uprościć obsługę, wprowadzone zostało pojecie szablonu. Definicja szablonu jest identyczna jak definicja serwera, różnica leży wyłącznie w lokalizacji wpisu - serwery są umieszczane w gałęzi "libraries", a szablony w gałęzi "templates". Jeżeli definiuje się serwer, to do jego opisu można dodać atrybut "z3950templateName". Wartość tego atrybutu będzie nazwą szablonu. Jeżeli dla danego serwera określono szablon, to atrybuty, które nie mają zdefiniowanych wartości w ramach serwera uzyskują wartości z szablonu. Jeżeli jednak dany atrybut występuje w serwerze chociaż jeden raz, to z szablonu nie są pobierane żadne inne wartości tego atrybutu. W ten sposób poprzez zdefiniowanie atrybutów w ramach serwera można zarówno rozszerzyć, jak i zawęzić zestaw wartości określonych w szablonie. Jeżeli atrybut nie jest zdefiniowany ani w ramach opisu serwera, ani w ramach jego szablonu, to konsultowany jest jeszcze szablon domyślny i z niego pobierane wartości domyślne. Należy pamiętać, że szablon to nie tylko zbiór atrybutów, ale również wpisy dotyczące operacji uszczegółowionych.

Komputery

Opisy komputerów mieszczą się w gałęzi "hosts". Jedynym powodem dla zdefiniowania tej kategorii jest możliwość wprowadzenia ograniczeń związanych z obciążeniem. Jeżeli na jednym komputerze jest obsługiwane wiele katalogów, to zbyt wiele połączeń może powodować nadmierne obciążenie. Systemy przeszukujące równolegle wiele baz mogą korzystać z ograniczeń zdefiniowanych w opisach komputerów, aby limitować obciążenie. Przykładowy wpis definiujący komputer podano poniżej.
dn: ipHostNumber=150.254.35.111,ou=hosts, dc=karo, dc=pl
ipHostNumber: 150.254.35.111
objectClass: karoHost
karoLoadLimit: 20

Parametry konfiguracyjne katalogu KaRo

KaRo jest systemem równoległego przeszukiwania polskich katalogów bibliotecznych korzystającym z protokołu Z39.50. W czasie tworzenia systemu okazało się, że zapewnienie poprawnej pracy z wieloma katalogami wymaga dopasowywania konfiguracji w sposób wykraczający poza standard. Dotyczy to na przykład stron kodowych w jakich przechowywane są opisy bibliograficzne, czy specyficznego znakowania wyników przeglądania indeksu (w systemach Horizon i Virtua). Do tych celów określone zostały dodatkowe parametry konfiguracyjne, które znalazły swoje odzwierciedlenie z stworzonym schemacie LDAP. Ponieważ ta grupa parametrów nie dotyczy bezpośrednio protokołu Z39.50, więc klasy i atrybuty z nią związane zostały umieszczene w oddzielnym schemacie (karo.schema).

Implementacja

Zasadniczym celem prac badawczo-rozwojowych było określenie możliwości zastosowania bazy LDAP jako repozytorium opisów obiektów związanych z protokołem Z39.50, przygotowanie niezbędnych schematów oraz oprogramowania wspomagającego.
Projekt został zaimplementowany zgodnie z przedstawionym powyżej opisem. Bazę LDAP załadowano przykładowymi danymi pobranymi z plików konfiguracyjnych katalogu KaRo. Przygotowano interfejs do administrowania danymi, uwzględniający specyfikę rozkładu danych.

Wnioski

Na podstawie przeprowadzonych prac można jednoznacznie stwierdzić, że zaproponowany schemat bazy bardzo dobrze nadaje się do pełnego opisu systemu katalogów obsługiwanych przez protokół Z39.50. Należy jednak stwierdzić, że korzystanie z bazy LDAP w trybie on-line, w ramach zaproponowanego systemu, może wprowadzać pewne opóźnienia, ponieważ określenie wszystkich parametrów niezbędnych do kontaktu z serwerem Z39.50 wymaga wielu operacji odczytu. Dlatego najwłaściwszą formą korzystania z bazy jest pobieranie konfiguracji sporadycznie (np. w celu wygenerowania podręcznego pliku konfiguracyjnego).
Przygotowana baza zawiera informacje o praktycznie wszystkich dostępnych katalogach polskich i o najważniejszych katalogach zagranicznych. Nieograniczone udostępnienie zawartości bazy nie jest jednak możliwe z powodu specyficznej sytuacji w Polsce - z powodu szczupłych zasobów, jakimi dysponują biblioteki, zarówno co do liczby licencji jak i mocy komputerów dostęp do serwera Z39.50 na ogół jest chroniony.

Bibliografia

[1] Tomasz Wolniewicz, Analiza standardu Z39.50 pod kątem możliwości przechowywania parametrów konfiguracyjnych w bazie LDAP

Załącznik 1 (z3950.schema)

# class z3950server

# karoProjectOID 1.3.6.1.4.1.13685.1.1.1.3

objectIdentifier plz3950 1.3.6.1.4.1.13685.1.1.1.3.1
objectIdentifier plz3950ObjectClass plz3950:1
objectIdentifier plz3950AttributeType plz3950:2

attributetype ( plz3950AttributeType:1 
	NAME 'z3950databaseName'
	DESC 'database name used for access information'
	EQUALITY caseExactMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	SINGLE-VALUE 
	)

attributetype ( plz3950AttributeType:2
	NAME 'z3950templateName'
	SINGLE-VALUE 
	SUP name 
	)

attributetype ( plz3950AttributeType:3
	NAME 'z3950protocolVersion'
	DESC 'protocol version as number'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
	)

attributetype ( plz3950AttributeType:4
	NAME 'z3950implementationName'
	DESC 'Implementation name in free format'
	SINGLE-VALUE 
	SUP name 
	)

attributetype ( plz3950AttributeType:5
	NAME 'z3950implementationVersion'
	DESC 'Implemetation version in free string format'
	SINGLE-VALUE 
	SUP name 
	)

attributetype ( plz3950AttributeType:6
	NAME 'z3950supportedOperation'
	DESC 'supported operation type like search, scan, present, explain'
	SUP name
	)

attributetype ( plz3950AttributeType:7
	NAME 'z3950supportedSyntax'
	DESC 'supported record syntax as OID'
	EQUALITY objectIdentifierMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
	 )

attributetype ( plz3950AttributeType:8
        NAME 'z3950forceBriefSyntax'
        DESC 'forec brief syntax if different from supported as OID'
        EQUALITY objectIdentifierMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
         )

attributetype ( plz3950AttributeType:9
	NAME 'z3950supportedSearchAttibute'
	DESC 'supported attribute as Bib-1 number'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
	 )

attributetype ( plz3950AttributeType:10
	NAME 'z3950supportedScanAttibute'
	DESC 'supported attribute as Bib-1 number'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
	 )

attributetype ( plz3950AttributeType:11
	NAME 'z3950searchInputEncoding'
	DESC 'accepted encoding for search input out of a predefined set'
	EQUALITY caseIgnoreMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	 )

attributetype ( plz3950AttributeType:12
	NAME 'z3950marcOutputEncoding'
	DESC 'output encoding for MARC record out of a predefined set'
	EQUALITY caseIgnoreMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	 )

attributetype ( plz3950AttributeType:13
	NAME 'z3950scanOutputEncoding'
	DESC 'output encoding for scan record (if different then marc) out of a predefined set'
	EQUALITY caseIgnoreMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	 )

attributetype ( plz3950AttributeType:14
	NAME 'z3950holdingsOutputEncoding'
	DESC 'output encoding for holdings part of the record if different from marc out of a predefined set'
	EQUALITY caseIgnoreMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	 )

attributetype ( plz3950AttributeType:15
	NAME 'z3950scanToSearchUseAttribute'
	DESC 'attribute used to create a search query from scan result (VTLS)'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
	SINGLE-VALUE
	)

attributetype ( plz3950AttributeType:16
	NAME 'z3950connectionLimit'
	DESC 'limit of concurrent connections'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
	SINGLE-VALUE
	 )

attributetype ( plz3950AttributeType:17
	NAME 'z3950databaseUFN'
	DESC 'user-friendly name of the database - subtyped'
	SUP name
	)


objectclass ( plz3950ObjectClass:1
	NAME 'z3950template'
	SUP top 
	MUST ( cn )
	MAY ( ipServicePort $ 
	z3950templateName $
	z3950databaseName $
	z3950protocolVersion $
	z3950implementationName $ z3950implementationVersion $
	z3950supportedOperation $
	z3950supportedSyntax $
	z3950forceBriefSyntax $
	z3950supportedSearchAttibute  $
	z3950supportedScanAttibute  $
	z3950searchInputEncoding $
	z3950marcOutputEncoding $ z3950scanOutputEncoding $
	z3950holdingsOutputEncoding 
	)
	)

objectclass ( plz3950ObjectClass:2
	NAME 'z3950server'
	SUP z3950template
	MUST ( cn $ ipHostNumber )
	MAY ( z3950connectionLimit  $
	z3950databaseUFN $
	labeledURI $ l $ c
 	)
	)

# klasa z3950attributeObject
# RDN obiektu jest atrybutem cn
# wartość tego atrybutu to uniwersalne napisy okreslające typ zapytania
# przykładowo: authorWord, authorExact
# kolejne jednowartowartościowe atrybuty okeslają wartości
# wszystkich stosowanych typów atrubutów wyszukania
# atrybut description pozwala na wyswietlanie w interfejsie użytkownika
# z zastosowaniem podtypow językowych


attributetype ( plz3950AttributeType:31
	NAME 'z3950useAttribute'
	DESC 'supported attributes as Bib-1 numbers'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
	 )

attributetype ( plz3950AttributeType:32
	NAME 'z3950relationAttribute'
	DESC 'supported attributes as Bib-1 numbers'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
	 )

attributetype ( plz3950AttributeType:33
        NAME 'z3950positionAttribute'
        DESC 'supported attributes as Bib-1 numbers'
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
         )
attributetype ( plz3950AttributeType:34
        NAME 'z3950structureAttribute'
        DESC 'supported attributes as Bib-1 numbers'
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
         )

attributetype ( plz3950AttributeType:35
        NAME 'z3950truncationAttribute'
        DESC 'supported attributes as Bib-1 numbers'
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
         )
attributetype ( plz3950AttributeType:36
        NAME 'z3950completenessAttribute'
        DESC 'supported attributes as Bib-1 numbers'
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
         )

attributetype ( plz3950AttributeType:37
        NAME 'z3950attributeUFN'
        DESC 'attribute display text, in lang versions'
        SINGLE-VALUE 
        SUP name 
	)

attributetype ( plz3950AttributeType:38
        NAME 'z3950operation'
        DESC 'operation type like search, scan, present, explain'
        SUP name
        )

objectclass ( plz3950ObjectClass:3
        NAME 'z3950attribute'
	SUP top
	MUST ( cn $ z3950useAttribute )
	MAY ( z3950relationAttribute $ z3950positionAttribute $
	z3950structureAttribute $ z3950truncationAttribute $
	z3950completenessAttribute $
	z3950operation $
	z3950attributeUFN )
	)

attributetype ( plz3950AttributeType:51 
	NAME 'z3950supportedFineOperation'
	DESC 'attribute used to point to z3950attribute objects'
	SUP name
	)

Załącznik 2 (karo.schema)

# karoProjectOID 1.3.6.1.4.1.13685.1.1.1.3


objectIdentifier karoz3950 1.3.6.1.4.1.13685.1.1.1.3.3
objectIdentifier karoz3950ObjectClass karoz3950:1
objectIdentifier karoz3950AttributeType karoz3950:2



attributetype ( karoz3950AttributeType:1
	NAME 'karoBibPrefix'
	DESC 'special prefix for building Horizon search queries from scan'
	EQUALITY caseExactMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	)

attributetype ( karoz3950AttributeType:2
	NAME 'karoAuthPrefix'
	DESC 'special prefix for building Horizon search queries from scan'
	EQUALITY caseExactMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	)

attributetype ( karoz3950AttributeType:3
	NAME 'karoLibType'
	DESC 'library type meaning, general, university etc.'
	EQUALITY caseExactMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
	)

attributetype ( karoz3950AttributeType:4
        NAME 'karoImplementationType'
        DESC 'Implementation type in free format'
        SINGLE-VALUE 
        SUP name )

attributetype ( karoz3950AttributeType:5
        NAME 'karoSkipMarcFields'
        DESC 'local MARC fields to be skipped form display'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
	)

objectclass ( karoz3950ObjectClass:1
	NAME 'karoObject'
	SUP top
	MAY ( karoBibPrefix $
	karoAuthPrefix $
	karoLibType $
	z3950supportedFineOperation $
	karoSkipMarcFields $
	karoImplementationType )
	)


objectclass ( karoz3950ObjectClass:2
	NAME 'karoTemplate'
	SUP ( z3950template $ karoObject )
	)


objectclass ( karoz3950ObjectClass:3
	NAME 'karoServer'
	SUP ( Z3950server $ karoObject )
	)

# load limits (for use with KaRo)
attributetype ( karoz3950AttributeType:11
	NAME 'karoLoadLimit'
	DESC 'limit of concurrent operations'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
	SINGLE-VALUE
	 )

attributetype ( karoz3950AttributeType:12
	NAME 'karoSearchLimit'
	DESC 'limit of concurrent searches'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
	SINGLE-VALUE
	 )

objectclass ( karoz3950ObjectClass:4
	NAME 'karoHost'
	SUP top
	MUST ( ipHostNumber $ description )
	MAY ( karoLoadLimit $ karoSearchLimit $ z3950connectionLimit )
	)