Повнотекстові бази даних

      Доповідь  на тему:

“Протокол Z39.50”

 
    В останні два-три роки в бібліотечних колах, та й не тільки все частіше можна почути розмови про застосування протоколу Z39.50 в області автоматизації бібліотек, обробки інформації, надання доступу до даних. 
Що вдає із себе цей протокол, і чим він краще звичного всім HTTP? 
Протокол Z39.50 визначений відповідним стандартом (ANSI Z39.50-1995, ISO / FDIS 23950). Z39.50 - протокол прикладного рівня в рамках семиуровневой еталонної моделі взаємодії відкритих систем, розробленої Міжнародною Організацією Стандартів (ISO) і тому може бути реалізований в різних типах мереж (наприклад, в мережах TCP / IP, IPX / SPX, OSI), незалежно від реалізації транспортного рівня. Його призначення - надати комп'ютера, що працює в режимі "клієнт", можливості пошуку і добування інформації з іншого комп'ютера, що працює як інформаційний сервер. 
Стандарт визначає для комп'ютерів-клієнтів єдину процедуру запиту інформаційних ресурсів - серверів, що підтримують бібліотечні каталоги. 
Не вдаючись поки в деталі роботи протоколу, можна сказати, що стандарт Z39.50 визначає такі правила взаємодії комп'ютерів, які дозволяють уніфікувати доступ до різних баз даних. Іншими словами, користувач, який використовує всього лише один додаток на комп'ютері-клієнті, може здійснювати пошук інформації у віддалених розподілених базах даних, що мають різну структуру і формати представлення інформації.

Історія. 
   Z39.50 розроблявся в Бібліотеці Конгресу США з початку 80-х років. 
У 1989 році в рамках бібліотеки конгресу було створено спеціальний підрозділ - Агентство підтримки Z39.50 (Z39.50 Maintenance Agency) (http://lcweb.loc.gov/z3950/agency/), яке в даний час координує роботу різних груп, розвиваючих окремі напрями використання протоколу, і пропонують нові версії стандарту, а також веде реєстр розробників програмного забезпечення для протоколу Z39.50.

 
Призначення. 
   Споконвічно протокол Z39.50 призначався для обробки бібліографічної інформації. Проте зараз протокол достатньо розвинений, щоб підтримувати різні дані - фінансову, хімічну, технічну інформацію, повні тексти та зображення. 
Можна назвати цілий ряд причин, які послужили стимулом до розробки протоколу Z39.50. Головною причиною, найбільш складною і загальної, є той факт, що в бібліотечному співтоваристві, та й не тільки в ньому, існує величезна кількість інформаційно-пошукових систем, електронних каталогів, систем автоматизації, які підтримують абсолютно різні форми подання інформації, форми зберігання даних, способи доступу до інформації. У цій великій проблемі можна виділити декілька складових частин. 
По-перше, очевидно, що різні бази даних мають різну структуру зберігання інформації. Це означає, що записи БД (документи) можуть мати різні набори полів, в кожному конкретному випадку поля абсолютно по-різному називаються, одні й ті ж поля можуть трактуватися по-різному, а, отже, і наповнюватися даними по-різному в різних системах . Візьмемо, приміром, поле АВТОР, що зустрічається в будь бібліографічної БД. У різних БД інформація зберігається відповідно з різними стандартами (а іноді і зовсім без всяких стандартів, просто так, як вважали зручним розробники). Отже, в цьому полі можуть міститися зовсім різні значення. Наприклад, якщо структура документа відповідає запису формату MARC, то в полі Автор, швидше за все, буде міститися прізвище першого автора джерела (тобто полі 100 формату USMARC). Однак, поля БД можуть формуватися виходячи з інших міркувань, і тоді в поле АВТОР можуть міститися повторювані значення, тобто прізвище не тільки першого автора, а всі автори джерела разом. Подібна ситуація відбувається і з іншими полями, наприклад, коли виділяється основний заголовок документа, а всі інші (підзаголовок, альтернативні назви і т.д.) заносяться в одне поле. Очевидна, що така невизначеність вносить певні незручності, як при пошуку інформації, так і на етапі її видачі користувачеві. Далі, в різних системах використовуються різні пошукові мови, тобто правила складання запитів на пошук інформації в БД. Тут можна привести такі приклади, як використання різних символів для позначення усікання, або різні правила позначення словосполучення в пошуковому виразі. 
Також розрізняється і спосіб представлення видаваної інформації. Різні системи по-різному визначають вихідний формат видається за запитом записи. Десь записи можуть видаватися просто у вигляді списку, десь форма запису видається у вигляді каталожної картки, а в деяких, більш серйозних системах існує можливість вибору вихідного формату, і, витративши деякі зусилля, користувач зможе вибрати потрібний формат. Останнім часом серйозні пошукові системи пропонують можливість видачі інформації в комунікативних форматах - у форматах сімейства MARC. 
     Проте вже навіть ці кілька перерахованих відмінностей ведуть до того, що кожна система має свій власний користувальницький інтерфейс, строго орієнтований на використовувані формати зберігання даних, пошукові мови і форму видачі даних. У свою чергу такі обмеження на доступ до інформації призводять до того, що користувач для спілкування з кожною окремою системою повинен вивчити її інтерфейс, розібратися в правилах складання запитів, і, можливо, змиритися з тим, що документи будуть видані не в потрібному форматі, а в тому, що підтримується системою. 
     До появи Z39.50 основним протоколом доступу до розподілених сховищ інформації був протокол HTTP. Однак HTTP - протокол загального призначення і не має практично ніяких спеціалізованих можливостей, що дозволяють, наприклад, уніфікувати доступ до різнорідної інформації, або створювати пошукові запити до БД. Ні, зрозуміло, ці проблеми вирішувані і на базі протоколу HTTP, проте для цього доводиться застосовувати різні додаткові кошти, мови програмування, бібліотеки функцій і так далі. Все це призводить до того, з чого ми і почали - кожен розробник знаходить власне рішення таких проблем, створюючи систему доступними йому засобами, використовуючи власні механізми, технології та моделі. У результаті й виходить, що окремо взята пошукова система має свою власну структуру, власні формати зберігання даних, часто не узгоджуються з існуючими стандартами. Тобто, ми отримуємо інформацію найчастіше тільки в тому вигляді, в якому вона представлена ​​в цій системі, і немає ніяких гарантій, що ми зможемо без втрат або додаткових перетворень і зіставлень використовувати цю інформацію в інших системах і базах даних.

Висновок із усього вищесказаного невтішний - системи, побудовані без використання протоколу Z39.50 різнорідні і відокремлені, що багато в чому ускладнює як роботу з ними, так і подальше використання наданої ними інформації. 
Що ж кардинально нового пропонує протокол Z39.50? 
Не вдаючись поки в подробиці, позначимо дві основні особливості, які відрізняють протокол Z39.50 від інших. 
1. Модель представлення інформації, закладена в протоколі ніяк не залежить від джерел інформації, що використовують цей протокол. Іншими словами, протокол надає якусь абстрактну модель представлення інформації на кожному етапі взаємодії клієнта і сервера. 
2. Протокол Z39.50 повністю забезпечує сесійне взаємодія клієнта з сервером. Ця особливість закладена в самому протоколі і реалізується у всіх його додатках, будь то серверна система або програма-клієнт. 
Основні положення протоколу Z39.50 
Заснована ідея представлення інформації при роботі з протоколом Z39.50 лежить в абстрагуванні від конкретної структури якої б то не було бази даних. Для цього в стандарті описані якась абстрактна модель БД. Ця модель включає в себе повний набір елементів, необхідних для доступу та обробки інформації, що зберігається в БД. Абстрактна модель описує у вигляді окремих елементів не тільки, наприклад, можливі пошукові поля або формати видачі інформації, але і всі виконувані сервером операції. 
Кожен елемент цієї абстрактної моделі докладно описується до однозначного тлумачення і стандартизуется з присвоєнням унікального ідентифікатора - OID. Робота з кожної конкретної СУБД повинна бути організована тільки через цю абстрактну модель шляхом обміну пакетами даних (APDU), що містять послідовності ідентифікованих по мітках об'єктів. У стандарті описані такі класи об'єктів: 
• Контекст програми (context), 
• APDU, 
• Атрибути (attributeSet), 
• Діагностика (diagnostic), 
• Структура записів (recordSyntax), 
• Синтаксис перетворень (transferSyntax), 
• Звіту з ресурсів (resourceReport), 
• Контроль доступу (accessControl), 
• Розширений сервіс (extendedService), 
• Користувацька інформація (userInfoFormat), 
• Елементи (elementSpec), 
• Варіанти (variantSet), 
• Схема даних (schema), 
• Схема міток (tagSet).

Усередині класу  об'єкти ідентифікуються номерами, дабавляемимі до класового номером. Наприклад, у класі recordSyntax {1.2.840.10003.5} об'єкти мають OID: Unimarc {1.2.840.10003.5.1}, USmarc {1.2.840.10003.5.10}, SUTRS {1.2.840.10003.5.101} і т.п. 
Протягом пошукової сесії відбувається обмін APDU між клієнтом і сервером, ініціатором яких найчастіше виступає клієнт. Основні APDU наступні: 
• Init 
• Search, 
• Present, 
• DeleteResultSet, 
• Scan, 
• Sort, 
• Segment, 
• ExtendedServices, 
• Close. 
Таким чином, абстрактна модель БД, представлена ​​протоколом відображається на конкретну модель існуючої бази даних. Завдання розробника системи полягає в тому, щоб правильно відобразити абстрактну модель даних протоколу на існуючу структуру БД і зіставити відповідні елементи. 
Спілкування клієнта і сервера 
А тепер, коли ми маємо деяке уявлення про абстрактну моделі даних, описаної в стандарті, ми можемо звернутися до особливостей спілкування клієнта і сервера за протоколом Z39.50, і перш за все, до можливостей сесійного взаємодії. 
По-перше, розберемося з тим, що ж таке сесія. Формально визначення сесії звучить приблизно так: 
Сесією є послідовність функціонально пов'язаних пошукових сеансів (операцій), спрямована на отримання логічно цілісного результату, кожен з яких виконується в рамках окремої мережевої транзакції. 
Іншими словами, сесія - це послідовність взаємопов'язаних операцій, причому, кожна наступна операція виконується тільки після завершення попередньої і заснована на її результатах.

Перш за все, відбувається процес ініціалізації  з'єднання. Клієнтський додаток посилає  серверу запит на з'єднання, передаючи  при цьому такі відомості про  себе, як використовувана версія протоколу, максимальні розміри записів, допустимі операції і так далі. Такий запит передається у відповідному APDU - InitializeRequest. У відповідь сервер відправляє клієнту APDU InitializeResponse, в якому пересилає клієнту той же набір параметрів, але вже зі своїми значеннями. Таким чином сторони "домовляються" про те, які можливості протоколу можуть бути використані в ході сесії. Після відповіді сервера клієнту відкривається нова сесія. В ході цієї сесії користувач може формулювати і посилати серверу пошукові запити, переглядати результат пошуку, сортувати видачу, проглядати пошукові індекси, видаляти результати пошуку і так далі. Закривається сесія або з ініціативи клієнтської програми, що посилає серверу APDU Close, або самим сервером після довготривалого відсутність яких би то не було запитів від клієнта. 
Запит на пошук відправляється клієнтським додатком у APDU SearchRequest. Цей APDU включає в себе таку інформацію, як база даних, в якій проводиться пошук, тип задається запиту, сам запит і деякі інші параметри, що стосуються результуючого безлічі. Стандарт протоколу Z39.50 підтримує кілька типів запитів, але обов'язковим є тип 1 - запит в зворотної польської записи, іменований в специфікації як RPNquery. Пошуковий вираз може містити інший запит, покажчик на результуюче безліч або комбінацію атрибутів та пошукових термінів. Під атрибутами в даному випадку розуміється якийсь набір параметрів, що характеризує правила пошуку кожного терміна. Найбільш поширений набір атрибутів Bib-1 {OID Z39.50 1 березня}, що включає групу Use з 99 пошукових атрибутів (таких як author, title, DatePublication і т.п.) і п'ять груп уточнюючих атрибутів (Relation, Position, Structure, Truncation , Completeness). Повну інформацію про набір атрибутів Bib-1 ви зможете отримати тут: ftp://ftp.loc.gov/pub/z3950/defs/bib1.txt. 
Прикладом розгорнутого в рядок RPN-запиту може бути запит на пошук записів, в яких автор починається на "Jhon" і зустрічається в будь-якій позиції поля: 

@attr 1=1003 @attr 2=3 @attr 3=3 @attr 5=1 {John}

        где

                Bib-1 @attr 1=1003  - соответсвует author,

                @attr 2=3 - равно,

                @attr 3=3 - любая позиция в поле,

                @attr 5=1 - усечение справа,

                John - поисковый термин 

Природно те, що серверу передається не рядок  запиту, а деревовидна RPN-структура, де кожна пара "атрибут = значення" представлена ​​окремим елементом. Така організація системи запитів дозволяє з одного боку однозначно відобразити логіку запиту, абстрагуючись від синтаксису запиту конкретної СУБД, а з іншого - абстрагуватися від пошукових полів конкретної бази даних, так як запит формулюється завжди в термінах абстрактного набору атрибутів, наприклад, Bib-1. Крім Bib-1, орієнтованого на роботу з бібліографічними базами даних, сьогодні стандартизовані і інші набори атрибутів, наприклад, STAS - 2000 атрибутів для науково-технічної інформації, GEO - 2000 атрибутів для геоінформаційних систем і ін 
Запити RPN (Type-1) - не єдино припустимий тип запитів в Z39.50. Стандарт 1995 року (версія 3) допускає запити Type-0 - запити в синтаксисі конкретної СУБД, запити Type-2 - запити в синтаксисі Common Command Language (CCL - ISO 8777) та ін В даний час ведеться обговорення включення до Z39.50 запитів в синтаксисі SQL. 
Відповіддю на пошуковий запит служить APDU SearchResponse, який містить таку інформацію, як кількість знайдених записів і номер наступного извлекаемой запису.      Оскільки протокол розрахований на сесійне взаємодія, і кожне наступне дія виконується лише за результатами попереднього. Ми не можемо відразу ж переглянути знайдені записи. У APDU відповіді на пошук знайдені записи не передаються. Для цього потрібно надіслати серверу запит на видачу потрібних записів - PresentRequest.

     При запиті на видачу серверу передається ім'я результуючого безлічі, з якого ми переглядаємо записи, номер запису, з якої починається перегляд, кількість видаваних записів, формат видачі та набір елементів (всі поля або тільки частина). Отримавши такий запит, сервер звертається до результуючому безлічі, вибирає потрібні записи, перетворює їх в потрібний формат і повертає клієнту в APDU PresentResponse. 
В процесі вилучення записів з баз даних самі дані послідовно існують в декількох різних уявленнях: 
  1. Внутрішнє подання даних в конкретній СУБД - в такому вигляді дані зберігаються. 
  2. Внутрішнє абстрактне уявлення сервера - в такому вигляді дані обробляються сервером. 
  3. Зовнішнє подання - в такому вигляді дані віддаються клієнту. 
У відповідь на запит користувача видати знайдені записи сервер Z39.50 повертає витребувані кількість записів клієнтові в необхідному форматі зовнішнього уявлення. Формати подання стандартизовані в класі RecordSyntax {Z39.50 5} і включають MARC-формати ISO-2709 (Unimarc, Usmarc, CCF, SBN і т.д.), неструктурований текстовий формат SUTRS, структуровані тегів формати (GRS-1, Summary) , спеціальні формати (HTML, XML, PDF, TIFF, GIF) та інші. Структуровані формати дозволяють після передачі по мережі повністю зберегти первісну структуру запису, на відміну від інших протоколів (http, ftp тощо), що є важливим в розподілених системах. Відповідно до стандарту, кожен Z-сервер зобов'язаний представляти інформацію як мінімум у форматі SUTRS - у вигляді неструктурованого тексту. Однак, більшість досить розвинених серверів не обмежується цим. Дуже багато сервера реалізують видачу записів в MARC-форматах - як правило Usmarc або Unimarc або ж Rusmarc, якщо ми маємо справу з вітчизняним сервером. 
Оскільки видобувні записи можуть мати значну довжину, а їх поля (елементи) - різні типи даних, стандарт дозволяє витягувати обмежений список полів із запису. Такі списки називаються "наборами елементів" (elementSet). Мінімально допустимі два набори елементів - Full (F) і Brief (B).

     Крім розглянутих операцій пошуку і видачі існують ще й інші можливості: сортування знайдених бібліографічних описів, перегляд пошукових індексів сервера, замовлення джерела, додавання або зміна записів. 

 
Висновок 

 
Підводячи підсумок цього досить приблизним огляду, хочеться ще раз  визначити ті особливості протоколу, які дозволяють вважати його найбільш підходящим для організації доступу до бібліографічної інформації: 
1. Підтримка сесійного взаємодії і чітко визначений порядок цієї взаємодії. Іншими словами - уніфікація способу передачі інформації. 
2. Ідеологія абстрактної моделі даних - уніфікація представлення інформації. 
3. Принцип стандартизованої видачі даних - уніфікація обміну даними. 
Все це призвело до того, що протокол Z39.50 визнаний у багатьох організаціях та бібліотеках по всьому світу і досить широко використовується. У продовженні це статті ми поговоримо про реалізації цього протоколу (про серверні і клієнтських додатках), а також розглянемо кілька найбільших бібліотек, що надають доступ до своїх БД по протоколу Z39.50.

 
ЛІТЕРАТУРА

1. Жижимов О.Л. Введение в Z39.50. - Новосибирск: Изд-во НГОНБ, 2000.
2. Материалы Z39.50 Maintenance Agency http://lcweb.loc.gov/z3950/agency/
3. Племнек А.И., Усманов Р.Т. Практика построения Z39.50-интерфейсов к библиографической реляционной базе данных для региональной библиотечной системы RUSLANet // Материалы международной библиотечной конференции "Информационные технологии в библиотеках на рубеже веков: проблемы, поиск, решения".-Минск: Красико-принт, 1999.-с.41-48.
4. Сысойкина М. А. Протокол Z39.50 для гуманитариев // Теория и практика научной информации, Т.18, 2002 г (в печати)