ПРОТОКОЛ Z 39. 50
В останні два-три роки в бібліотечних колах, та й не тільки все частіше можна почути розмови про застосування протоколу Z 39. 50 в області автоматизації бібліотек, обробки інформації, надання доступу до даних.
Z 39. 50 — клієнт-серверний протокол для пошуку та отримання інформації з віддалених комп'ютерних баз даних. Він описується ANSI/NISO стандартом Z 39. 50, а також ISO-стандартом 23950. Основна агенція, що обслуговує стандарт — бібліотека Конгресу. Z 39. 50 широко застосовний у бібліотечних колах і часто є включений у автоматизовані бібліотечні інформаційні системи та персональні системи управління бібліографічною інформацією. Міжбібліотечні пошукові каталоги для міжбібліотечного абонементу часто реалізовані через запити Z 39. 50.
ЩО ПРЕДСТАВЛЯЄ З СЕБЕ ЦЕЙ ПРОТОКОЛ, І ЧИМ ВІН КРАЩЕ ЗВИЧНОГО ВСІМ HTTP? Протокол Z 39. 50 визначений відповідним стандартом (ANSI Z 39. 50 -1995, ISO / FDIS 23950). Z 39. 50 - протокол прикладного рівня в рамках семирівневої еталонної моделі взаємодії відкритих систем, розробленої Міжнародною Організацією Стандартів (ISO) і тому може бути реалізований в різних типах мереж (наприклад, в мережах TCP / IP, IPX / SPX, OSI), незалежно від реалізації транспортного рівня. Його призначення - надати комп'ютеру, що працює в режимі "клієнт", можливості пошуку і добування інформації з іншого комп'ютера, що працює як інформаційний сервер.
ЩО ПРЕДСТАВЛЯЄ З СЕБЕ ЦЕЙ ПРОТОКОЛ, І ЧИМ ВІН КРАЩЕ ЗВИЧНОГО ВСІМ HTTP? Стандарт визначає для комп'ютерів-клієнтів єдину процедуру запиту інформаційних ресурсів - серверів, що підтримують бібліотечні каталоги. Не вдаючись поки в деталі роботи протоколу, можна сказати, що стандарт Z 39. 50 визначає такі правила взаємодії комп'ютерів, які дозволяють уніфікувати доступ до різних баз даних. Іншими словами, користувач, який використовує всього лише один додаток на комп'ютері-клієнті, може проводити пошук інформації у віддалених розподілених базах даних, що мають саму різну структуру і формати подання інформації.
ІСТОРІЯ Z 39. 50 розроблявся в Бібліотеці Конгресу США з початку 80 -х років. У 1989 році в рамках бібліотеки конгресу було створено спеціальний підрозділ - Агентство підтримки Z 39. 50 (Z 39. 50 Maintenance Agency) (http: //lcweb. loc. gov/z 3950/agency/), яке в даний час координує роботу різних груп, розвиваючих окремі напрями використання протоколу, і пропонують нові версії стандарту, а також веде реєстр розробників програмного забезпечення для протоколу Z 39. 50. програмного забезпечення для протоколу
ПРИЗНАЧЕННЯ Спочатку протокол Z 39. 50 призначався для обробки бібліографічної інформації. Однак зараз протокол достатньо розвинений, щоб підтримувати різні дані - фінансову, хімічну, технічну інформацію, повні тексти та зображення. Можна назвати цілий ряд причин, які послужили стимулом до розробки протоколу Z 39. 50. Головною причиною, найбільш складною і загальною, є той факт, що в бібліотечному співтоваристві, та й не тільки в ньому, існує величезна кількість інформаційно-пошукових систем, електронних каталогів, систем автоматизації, які підтримують абсолютно різні форми подання інформації, форми зберігання даних, способи доступу до інформації. У цій великій проблемі можна виділити декілька складових частин.
ПРИЗНАЧЕННЯ По-перше, очевидно, що різні бази даних мають різну структуру зберігання інформації. Це означає, що записи БД (документи) можуть мати різні набори полів, в кожному конкретному випадку поля абсолютно по-різному називаються, одні й ті ж поля можуть трактуватися по-різному, а, отже, і наповнюватися даними по-різному в різних системах. Візьмемо, наприклад, поле АВТОР, що зустрічається в любій бібліографічній БД. В різних БД інформація зберігається відповідно з різними стандартами (а іноді і зовсім без всяких стандартів, просто так, як вважали за зручним розробники). Отже, в цьому полі можуть міститися зовсім різні значення. Наприклад, якщо структура документа відповідає запису формату MARC, то в поле Автор, швидше за все, буде міститися прізвище першого автора джерела (тобто поле 100 формату USMARC). Однак, поля БД можуть формуватися виходячи з інших міркувань, і тоді в поле АВТОР можуть міститися повторювані значення, тобто прізвище не тільки першого автора, а всі автори джерела разом. Подібна ситуація відбувається і з іншими полями, наприклад, коли виділяється основний заголовок документа, а всі інші (підзаголовок, альтернативні заголовки тощо. ) заносяться в одне поле. Очевидно, що така невизначеність вносить певні незручності, як при пошуку інформації, так і на етапі її видачі користувачу.
ПРИЗНАЧЕННЯ Далі, в різних системах використовуються різні пошукові мови, тобто правила складання запитів на пошук інформації в БД. Тут можна привести такі приклади, як використання різних символів для позначення скорочення, або різні правила позначення словосполучення в пошуковому виразі. Також розрізняється і спосіб представлення видаваної інформації. Різні системи по-різному визначають вихідний формат видаваної за запитом запису. Десь записи можуть видаватися просто у вигляді списку, десь форма запису видається у вигляді каталожної картки, а в деяких, більш серйозних системах існує можливість вибору вихідного формату, і, витративши деякі зусилля, користувач зможе вибрати потрібний формат. Останнім часом серйозні пошукові системи пропонують можливість видачі інформації в комунікативних форматах - в форматах сімейства MARC.
ПРИЗНАЧЕННЯ Однак вже навіть ці кілька перерахованих відмінностей ведуть до того, що кожна система має свій власний користувальницький інтерфейс, строго орієнтований на використовувані формати зберігання даних, пошукові мови і форму видачі даних. В свою чергу такі обмеження на доступ до інформації призводять до того, що користувач для спілкування з кожною окремою системою повинен вивчити її інтерфейс, розібратися в правилах складання запитів, і, можливо, змиритися з тим, що документи будуть видані не в необхідному форматі, а в тому, який підтримується системою.
ПРИЗНАЧЕННЯ До появи Z 39. 50 основним протоколом доступу до розподілених сховищ інформації був протокол HTTP. Однак HTTP - протокол загального призначення і не має практично ніяких спеціалізованих можливостей, що дозволяють, наприклад, уніфікувати доступ до різнорідної інформації, або створювати пошукові запити до БД. Зрозуміло, ці проблеми можна вирішити і на базі протоколу HTTP, однак для цього доводиться застосовувати різні додаткові кошти, мови програмування, бібліотеки функцій і так далі. Все це призводить до того, з чого ми й почали - кожен розробник знаходить власне рішення таких проблем, створюючи систему доступними йому засобами, використовуючи власні механізми, технології та моделі. В результаті і виходить, що окремо взята пошукова система має свою власну структуру, власні формати зберігання даних, часто не узгоджуються з існуючими стандартами. Тобто, ми отримуємо інформацію найчастіше тільки в тому вигляді, в якому вона представлена в цій системі, і немає ніяких гарантій, що ми зможемо без втрат або додаткових перетворень і зіставлень використовувати цю інформацію в інших системах і базах даних.
ПРИЗНАЧЕННЯ Висновок з усього вищесказаного невтішний - системи, побудовані без використання протоколу Z 39. 50 різнорідні і відособлені, що багато в чому ускладнює як роботу з ними, так і подальше використання наданої ними інформації.
ЩО Ж КАРДИНАЛЬНО НОВОГО ПРОПОНУЄ ПРОТОКОЛ Z 39. 50? Не вдаючись поки в подробиці, позначимо дві основні особливості, що відрізняють протокол Z 39. 50 від інших: • Модель представлення інформації, закладена в протоколі ніяк не залежить від джерел інформації, що використовують цей протокол. Іншими словами, протокол надає якусь абстрактну модель подання інформації на кожному етапі взаємодії клієнта і сервера. • Протокол Z 39. 50 повністю забезпечує сесійню взаємодію клієнта з сервером. Ця особливість закладена в самому протоколі та реалізується у всіх його додатках, будь то серверна система або програма-клієнт.
ОСНОВНІ ПОЛОЖЕННЯ ПРОТОКОЛУ Z 39. 50 Ідея представлення інформації при роботі з протоколом Z 39. 50 лежить в абстрагуванні від конкретної структури якої б то не було бази даних. Для цього в стандарті описано якась абстрактна модель БД. Ця модель включає в себе повний набір елементів, необхідних для доступу та обробки інформації, що зберігається в БД. Абстрактна модель описує у вигляді окремих елементів не тільки, наприклад, можливі пошукові поля або формати видачі інформації, а й всі виконувані сервером операції. Кожен елемент цієї абстрактної моделі детально описується до однозначного тлумачення і стандартизуется з присвоєнням унікального ідентифікатора - OID.
ВИСНОВОК Підводячи підсумок презинтації, хочеться ще раз визначити ті особливості протоколу, які дозволяють вважати його найбільш підходящим для організації доступу до бібліографічної інформації: • Підтримка сесійної взаємодії і чітко визначений порядок цієї взаємодії. Іншими словами - уніфікація способу передачі інформації. • Ідеологія абстрактної моделі даних - уніфікація представлення інформації. • Принцип стандартизованной видачі даних - уніфікація обміну даними. Все це призвело до того, що протокол Z 39. 50 визнаний у багатьох організаціях та бібліотеках по всьому світу і досить широко використовується.
ДЯКУЮ ЗА УВАГУ !!