Технології ІРБІС-корпорації

Директорам бібліотек присвячується

Пару місяців тому отримала лист від співробітника бібліотеки з запитанням: чи можу я проконсультувати з питань "конвертации в Ирбисе". Я попросила уточнити в чому суть проблеми, для чого потрібно щось конвертувати? Відповідь шокувала: "Мне директор библиотеки сказала, чтоб я спросил вас о конвертации, конкретно что - не сказала!". Можливо, я не стала би писати про цей випадок, якби ситуація не повторилася, у ще більше шокуючій формі. Для себе зробила висновок: слід написати про технології ірбіс-корпорації для директорів бібліотек :) . Може й ще комусь буде в нагоді.

Головна проблема будь-якої корпорації – виконання правил та обов’язків усіма учасниками. При цьому ці правила НЕМОЖЛИВО раз і назавжди формалізувати (бо технології учасників змінюються), так й неможливо ретельно відстежували їх виконання (це питання витрати часу). Чому неможливо? Наведу декілька прикладів:

1)      бібліотека перейшла з Ірбіс-32 на Ірбіс-64. У цьому випадку, наприклад, рубрики MESH вносяться у поле 966, на не в 606. Чи є сенс попереджати партнерів? Як на мене – немає. Легше проаналізувати надіслані записи, ніж встановити демо-версію нового Ірбісу та розібратися в усіх нюансах.

Інша проблема – кодування. Ірбіс-64 працює з UTF, WIN-1251, DOS. Ірбіс-32 не працює з UTF! Якщо перехід від WIN-1251 до UTF – простий та однозначний, то конвертувати файл з UTF у WIN-1251 не завжди можливо! Всі символи, яких немає у WIN-1251, будуть замінені на знак питання (наприклад, грецькі букви, діакритичні знаки).

Якщо в корпорації одна бібліотека працює на Ірбіс-64, то має сенс обмінюватись записами з кодуванням WIN-1251 (як у Ірбіс-32). А якщо дві, то слід для цих двох бібліотек організувати обмін в UTF, а для інших у WIN-1251. Бо бібліотеки, які використовують сучасні версії Ірбіс будуть мати у записах ті ж знаки питання замість якісних записів.

2)      інший приклад – шифрування журналів, позначення місця зберігання, дати надходження, вартості. Ці поля можуть мати різний зміст у різних бібліотеках. Домовлятися про єдині шифри (на мій погляд) має сенс лише для нових учасників корпорації.

3)      ще один приклад – новий співробітник у бібліотеці або новий технологічний процес. Наприклад, нового співробітника не попередили як вводити букву ё або ґ

Новий процес – створення бібліографічного списку або покажчику. У цьому випадку не рідко вводять спеціальні позначки для записів, які включатимуться у покажчик, наприклад, як ключове слово – "списоктерапевту", або у поле "індекси іншої класифікації" – "петров1.2" - номер розділу покажчика. Наслідки всіх методичних рішень однієї бібліотеки не варто копіювати у свій каталог. Сюди ж слід віднести позначку до прізвища автора – "Працює/не працює в організації".

Чи можливо передбачити все-все відразу? Пам'ятаю як вперше побачила 3 томи MARC-формату бібліотеки Конгресу США. Кожен завтовшки 10 см.  Чи варто готувати такі томи декільком бібліотекам, що вирішили розписувати журнали разом? Скільки на це піде часу? Написати,… засвоїти,… проконтролювати виконання? А технології змінюються швидко! Ось і знову потрібні нові інструкції… Є чим зайнятися.

Я згодна – інструкції потрібні, але є речі, які без усяких інструкцій прийняті у суспільстві (наприклад, митися, розчісувати волосся). Так само у кожного бібліотекаря є свій кодекс етики незалежно від того, розробив та затвердив хтось такий кодекс в їх країні чи ні.

Мій шлях – працювати на результат, домовлятися спочатку усно. Ліпше ДІЯТИ, припускаючись помилок, ніж зволікати, прагнучи безпомилковості. Звісно, керівники бібліотек можуть обирати інший шлях. Адже не помиляється той, хто нічого не робить. Заявляти: "Ніякої корпорації у Вас не було! (бо не було документів!) Просто надсилали записи один одному…". Можливо й не було, але були усні домовленості, був певний технологічний процес у якому брали та хотіли брати участь бібліотеки.

Інше дуже важливе питання – програмне забезпечення. Комп'ютер не працює без програмного забезпечення. Але РЕЗУЛЬТАТ є головним! А не програмне забезпечення. Наприклад, змінювати шифри можна у будь-якому текстовому редакторі. Так само, робити списки журналів, які надсилатимуться партнерам, можна у текстовому редакторі (Блокноті, Ворді), прямо у поштовому клієнті, Ірбісі або іншій АБІС. Всіх варіантів не перерахувати. В Ірбісі це можна зробити декількома способами й не має серед них лише одно вірного! РЕЗУЛЬТАТ є головним та трудовитрати (які у різних співробітників будуть різними незалежно від обраної технології).

Із повною відповідальністю заявляю, що Ірбіс (будь-яка версія, починаючи з 2004.1, можливо й старшими, але я з ними не працювала) має всі необхідні інструменти для корпоративної роботи. Написання сценаріїв для "глобальной корректировки" вирішує проблеми із заміною змісту та видалення "зайвих" полів.

Але не обов’язково використовувати лише Ірбіс! Мені, наприклад, було зручніше використовувати SED та Perl. Про SED мені розповів Антон Симонов з Дніпропетровська. На його сайті – докладні інструкції та програми у відкритому доступі для корпоративної роботи http://irbis.mezzazine.dp.ua/notes/import.html

Користуйтеся! Засвоюйте! Впроваджуйте!

Розробляйте своє!

Зазначу ще раз - технології змінюються!!! Якщо просто взяти чужі програми та бездумно їх використовувати, то дуже швидко вони перестануть Вас задовольняти. Передбачити яке методичне рішення буде прийнято в іншій бібліотеці та як воно вплине на записи, які Ви будете отримувати, НЕМОЖЛИВО!!! Потрібно весь час думати, аналізувати, підлаштовуватись, СПІВПРАЦЮВАТИ! Співпрацювати – не означає висувати претензії і тільки.

Тепер трохи інформації про SED

sed – потоковий текстовий редактор та мова програмування. "Потоковий" – означає, що текст для редагування задається як вхідний потік (вхідний файл).

Докладніше тут - http://uk.wikipedia.org/wiki/Sed

Sed можна скачати тут - http://gnuwin32.sourceforge.net/packages/sed.htm

"Complete package, except sources                Setup              2038876                     28 december 2010"

З цього пакету фактично потрібен тільки файл sed.exe

з Program Files\GnuWin32\bin\sed.exe

Наприклад, Ви регулярно отримуєте записи від учасника з Ірбіс-32. А у Вас – Ірбіс-64.

Перед завантаженням записів потрібно видалити поле 910 (місце зберігання в іншій бібліотеці). Замінити поле 606 на 996. 905 на 996, якщо Ваш партнер помилково використав поле 605 замість 606. Можливо зробити ще якісь операції, наприклад, заміну шифрів. Всі файли, отримані від бібліотеки-партнера, легко змінити натисканням на одну іконку на робочому столі. Під іконкою буде прихований командний файл, який потрібно створити. Його зміст може бути таким

for %%i in (1\*.txt) do sed -f to-i64.sed "%%i" > "%%i".tmp

del all.txt

for %%i in (1\*.tmp) do type "%%i" >all.txt

У папку з назвою "1" розміщують всі файли, які слід конвертувати.

Результат для завантаження в Ірбіс – файл all.txt.

Створіть файл to-i64.sed

Його зміст:

s/^#605:/#996:/

s/^#606:/#996:/

/^#910:/d

Пояснення команд файлу to-i64.sed:

s/^#605:/#996:/                    - замінить поле 605 (помилково вписане) на 996

s/^#606:/#996:/                    - замінить поле 606 (поле для предм.рубрик у старому Ірбісі) на 996

/^#910:/d                             - видалить поле 910 - місце зберігання документа. в кожній бібліотеці - своє