ИРБИС64 и ИРБИС64 ПБД

В структуру файла \DATAI\<имя_БД>.PAR, определяющего реальное местоположение (путь) ресурсов БД, введена новая, 11 строка, которая определяет реальное местоположение (путь) внешних объектов, имеющих относительную адресацию: в случае ИРБИС64 это внешние объекты, адресуемые через поле 951 подполе А, а в случае ИРБИС64 ПБД это полные тексты, включаемые в БД по относительным путям (поле 952 подполе В). В случае отсутствия 11 строки в файле <имя_БД>.PAR предполагается, что соответствующие объекты находятся непосредственно в папке БД.
В случае ИРБИС64 ПБД и использования АРМа полнотекстового читателя путь в 11 строке файла <имя_БД>.PAR надо обязательно указывать начиная с имени компьютера (Например: 11=\\<имя_ПК>\<имя_общего_ресурса>\и т.д.)

Новая возможность позволяет:
- в случае ИРБИС64 - связывать с библиографической записью внешние объекты через относительную адресацию (951^A) и при этом размещать их за пределами папки, где находится соответствующая БД. При этом в случае перемещения внешних объектов не возникает необходимости корректировать 951 поле, достаточно лишь откорректировать 11 строку в файле <имя_БД>.PAR.
- в случае ИРБИС64 ПБД - включать в полнотекстовую БД объекты, используя опцию ОТНОСИТЕЛЬНый ПУТЬ и при этом размещать их за пределами папки с собственно БД. Если предполагается использование такой возможности, следует предварительно - ДО включения текстов в БД - внести в файл <имя_БД>.PAR 11 строку соответствующего содержания. Данная возможность позволяет рекомендовать пользователям при включении в БД полных текстов ПОЛНОСТЬЮ ОТКАЗАТЬСЯ от использования опции ПОЛНЫЙ ПУТЬ

Предлагается ввести иерархическую типологию внешних объектов (951^H)
На верхнем уровне:
01 - Текстовый ресурс
02 - Графический ресурс
03 - Аудио-ресурс
04 - Мультимедийный ресурс
05 - Интернет-ресурс

На следующем уровне можно уточнять типологию ресурса. Это оставить на усмотрение пользователя.

Пример уточнения:

02a - Обложка
02b - Миниатюра обложки
02c - Иллюстрация
02d - Отсканированное оглавление
и т.д.

Спасибо. Конечно пользователи могли реализовать такую доработку и сами, но такие единообразные подходы помогу в корпоративном наполнении полнотекстовых баз.

АРМ Каталогизатор ИРБИС64
В INI-файл в секции [MAIN] введен новый параметр
PREVCOPYABLE=
который определяет доступность режима ПРЕДЫДУЩИЕ КОПИИ и принимает значения:
1 - доступен (по умолчанию)
0 - недоступен



Редактировано 1 раз. Последний раз 29.08.2012 11:31 пользователем Alio.

Поскольку значения поля Категория предполагается использовать для разграничения доступа читателей, предлагаю удалить из справочника 50.mnu названия тех категорий, которые не могут для этого использоваться и конкретизировать названия некоторых категорий.

Понятно, что этот справочник может легко корректироваться организацией, но, мне кажется, в его версии по-умолчанию необходимо демонстрировать логику заполнения.

Категории «доцент» и «профессор» едва ли могут определять право на доступ к каким-то ресурсам. Сомневаюсь, что хоть в одной организации найдётся файл только для профессоров, или только для доцентов. Кроме того, для учёного звания должно использоваться поле 28.

Категория «сотрудник» слишком не определённа. Некоторые устанавливают её для всех сотрудников организации(уборщиц в ВУЗе), а некоторые только для сотрудников библиотеки (ВУЗа).

Предлагаю эти категории удалить и добавить значения:


СБ
сотрудник библиотеки
ВП
вспомогательный персонал


В J-ИРБИС 2.0, например, это позволит сотруднику библиотеки подключать и удалять подключённые электронные версии документов, а так же создавать новые материалы. У преподавателей будет возможность определять назначение литературы on-line (заполнять поле 691).

Таким образом, справочник должен будет принять вид:


школьник
школьник
студент
студент
аспирант
аспирант
стажер
стажер
преподаватель
преподаватель
СБ
сотрудник библиотеки
ВП
вспомогательный персонал




Редактировано 3 раз. Последний раз 30.08.2012 17:02 пользователем Кирилл Соколинский (СЗТУ).

Категории многие правят под себя. И связано это не с удобством, а с наличием определенных категорий в отчетной документации.

Konstantinus написал(а):
-------------------------------------------------------
> Категории многие правят под себя. И связано это не
> с удобством, а с наличием определенных категорий в
> отчетной документации.

Речь не идёт запрете на редактирование справочника, а о его адаптации для новой задачи -- разграничение доступа.

1) Касательно редактирования справочника 50.mnu - категорически возражаю. Не надо тянуть в сторону вузовских библиотек. У публичек категорий гораздо больше и они активно используются при статистическом учете и анализе читательского контингента. Лучше сделать отдельный справочник категорий доступа с сопоставлениями (действующий по типу mhrvn.mnu)
2) По поводу 951^H мне кажется, что "Интернет-ресурс" является логическим нарушением. Первые четыре пункта это тип контента, а пятый - режимдоступа или характеристика размещения. Он излишен, поскольку вполне однозначно идентифицируется наличием префиксной "протокольной" части сылки

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

И хорошо было-бы вернуть значек в трей при запуске сервера 64-го ИРБИСа в режиме сервиса на системах Windows Server 2008 и выше.

Куделя написал(а):
-------------------------------------------------------
> 1) Касательно редактирования справочника 50.mnu -
> категорически возражаю. Не надо тянуть в сторону
> вузовских библиотек.

Максим Викторович, если право на редактирование справочника даётся пользователю, то не стоит отбирать его у разработчиков. ;) Что мешает публичкам исключить неактуальные для них значения?

Я считаю важным ввод определённых значений по дефолту в связи с тем, большинство библиотечных администраторов не добираются до справочников типа mhrvn.mnu. И на форуме появляется много новых вопросов...

К этому справичнику добираются первым для получения статистики книговыдачи по категориям.
Хотя конечно Кирилл прав в том, что добираютя до него не сразу, а после того как такую статистику получить несмогли.

Кирилл Соколинский (СЗТУ) написал(а):
-------------------------------------------------------
> Максим Викторович, если право на редактирование
> справочника даётся пользователю, то не стоит
> отбирать его у разработчиков. ;) Что мешает
> публичкам исключить неактуальные для них значения?
>
>
> Я считаю важным ввод определённых значений по
> дефолту в связи с тем, большинство библиотечных
> администраторов не добираются до справочников типа
> mhrvn.mnu. И на форуме появляется много новых
> вопросов...

В таком случае предлагаю создать отдельный каталог, скажем deposit_user , аналогичный каталогу deposit с высшим приоритетом чтения файлов, куда пользователи смогут складывать измененные ими файлы, чтобы потом без проблем производить обновления системы (ну, или почти без проблем).

Александр Сергеевич, я это три года назад в Крыму просил об этом Александра Иосифовича. Но тогда он сказал, что не хотел бы трогать серверную часть без очень на то большой надобности. Может если желающих на такую доработку окажется несколько, то мы сможем Александра Иосифовича уломать.

Я просто не могу поверить, что Александр Иосифович забыл бы об этой замечательной просьбе :)

В 2011.1 А.И. реализовал мою просьбу виртуального сложения баз при выдаче по штрихкоду.
В 2012.1 анонсировали доработку 951 поля. Так что все "разумные" пожелания учитываются, конечно с задержкой на доработку.
Сегодня весь день дамаю про deposit_user, скажите теперь файл может быть в папке БД, в deposit и deposit_user? Смысл deposit'a не в высшем приоритете, а уход от необходимости править один и тот же файл во всех папках БД.
А если надо в одной БД править а в другой нет. файл в папке БД будет/должен иметь все же высший приоритет?

Идея такая:
Если файл в папке БД, то он исполняется на высшем приоритете, если в папке БД его нет, то исполняется он из папки deposit_user, если в deposit_user файла нет, то идет запуск из deposit.

Это дает возможность обновлять, не донастраивая систему путем копирования (а главное, и самое сложное, выискивания) файлов в каждом из каталогов, просто скопировать свои (лично правленные) файлы mnu, pft, fst, tre ... в каталог deposit_user. И в инструкции можно будет написать, что если вы правили какой-то файл системы под себя, и нужен он в каждой БД, то требуется просто его скопировать в deposit_user, а из каталогов БД - удалить.

И еще просьба, если возможно, сделать в параметрическом файле возможность изменять путь к каталогу deposit_user. Это так для будущего идеала ИРБИСа, когда можно будет все свои файлы (настройки пользователей, форматы, mnu, и пр.), что донастроил сам, хранить вдали от идеально поставленного ИРБИСа с дистрибутива.

Проблемы, которые возникают при этом:
1. Бывает, что меняются наборы файлов (формы например) и они взаимосвязаны, в этом случае копируются все файлы одной формы.
2. Я не до конца знаю, но может быть будут проблемы с вложенными файлами форматов (не пробовал использовать вложенные pft конструкции с файлами из разных каталогов).

Итоговый вариант дополнительной структуры 951 поля:
^H - типология внешнего объекта (951H.mnu)
^D - уровень доступа по категориям пользователей (при доступе через Web) (50.mnu)
^L - доступен только в ЛВС (ДА/НЕТ)

Для подполя D используется справочник категорий читателей (в связи с чем он перенесен из БД RDR в DEPOSIT). Данное подполе вряд ли будет применяться в публичных библиотеках, но наверняка найдет применение в вузовских библиотеках.

Очень нужна возможность on-line продления книги на руках в личном кабинете в модулях WEB-Ирбис и J-ирбис.

Думаю реализовать надо лишь запрос пользователя на продление конкретной книги из его формуляра.
Примерное решение.

В поле v40 БД RDR добавится подполе «Запрос на продление», в котором будет указываться статус запроса на продление.

Примерные значения для статусов:
1- получен запрос на продление данной книги,
2- отказ в продлении по причине №1,
3- отказ в продлении по причине №2 и т.д.
По умолчанию, подполе пустое.
Раскодировку статусов можно хранить в обычном .mnu

В Арм "Книговыдача" организовать:
1 Поиск по необработанным Запросам на продление (Например, "Кафедра выдачи - читатель").
2 В области выданной литературы добавить соответствующую колонку куда будет выводиться расшифровка причины отказа на продление или сам факт того, что поступил такой запрос.
3 Рядом с кнопкой "Продлить" добавить кнопку «Отказать в продлении» с возможностью выбора причины отказа (смотрим справочник статусов продления). Для того чтоб читатель в личном кабинете мог видеть почему ему отказали в продлении книги.

В итоге это должно выглядеть как-то так:

В личном кабинете ЭК на вкладке формуляр для книги которую необходимо продлить, читатель нажимает ссылку "Запрос на продление" или кнопку .
При этом ссылка выводится при следующих условиях:
1 эта книга не продлевалась
2 не был получен отказ на продление этой книги
3 ну и, к примеру, книга задолжена не более 2-3х дней (понятно что эти данные библиотека должна где-то сама настраивать).

При переходе по ссылке "запрос на продление", в подполе соответствующей книги на руках статус в подполе «Запрос на продление» изменится на «1 - получен запрос на продление книги».

Далее на соответствующей кафедре выдачи библиотекарь, увидев в поиске необработанный запрос, переходит на нужного читателя. И
1 - либо продлевает издание, нажав на кнопку "продлить". При этом в соответствующем повторения поля 40 подполе "запрос на продление" зачищается, заполняется подполе «Дата продления», изменяется подполе «Дата предполагаемого возврата» на N - дней.
2 - либо отказывает в продлении, нажав на кнопку «Отказать в продлении» и выбрав причину отказа. При этом в соответствующем повторения поля 40 подполе "запрос на продление" статус 1(получен запрос на продление) меняется на статус, например 2(отказ в продлении по причине №1).

Далее читатель в личном кабинете ЭК на против нужной книги может увидеть :
1 дату до какого книга продлена и дату когда она была продлена
2 или, в обратном случае, причину по которой книга не может быть продлена.
Как то так:)


Ссылка на обсуждение этой темы на форуме

Государственная универсальная научная библиотека Красноярского края, Ассоциация ЭБНИТ

GLUKa написал(а):
-------------------------------------------------------
> Очень нужна возможность on-line продления книги на
> руках в личном кабинете в модулях WEB-Ирбис и
> J-ирбис.

Полностью присоединяюсь

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Ух ты! Все же рано Кирилл собирался Веб-Ирбис откладывать на дальнюю полку - слишком много на данный момент его инсталяций, в том числе и среди тех, кому новый функционал ДжейИрбиса не очень важен. А на счет продления книг в личном кабинете - не будут ли этим злоупотреблять? Вообще очень интересная идея! Ее еще надо скомбинировать с автор россылкой о задолженностях и предупреждениями о том, что скоро книга станет просроченной

GLUKa написал(а):
-------------------------------------------------------
> Очень нужна возможность on-line продления книги на
> руках в личном кабинете в модулях WEB-Ирбис и
> J-ирбис.

Присоединяюсь. Это ОЧЕНЬ нужно.
Нам самим пришлось сделать простую формочку на продление, читатели пользуются очень активно и благодарят за эту возможность. Если долгов нет - гиперссылка не появляется. Как только издания просрочены - появляется "продлить".

Еще нужно добавить простую, но важную возможность для читателя - в формуляре видеть список уже прочитанных им книг. С возможностью перехода по гиперссылке к любой книге в том числе для того, чтобы снова ее заказать при необходимости. Мы уже сделали, но эта возможность нужна в стандартной поставке.

Формуляр должен быть многофункциональным, а не только для того, чтобы смотреть, какие книги на руках. К примеру,у нас есть дополнительные услуги, на которые читатель подписан и эта информация содержится в RDR. В электронном формуляре читатель видит, на какие услуги он в данное время подписан. А если не подписан, появляется гиперссылка: "подписаться на тематические рассылки". И т.п.

Очень нужна обратная связь от читателя: рейтинг книги (хотя бы показывать, какие издания - "хиты"), возможность отзыв написать, или рекомендовать (важно для корпоративных библиотек). Можно не всем давать возможность рекомендовать, а, только, определенным категориям (у нас, например, руководителям). Естественно, чтобы потом можно было "собрать" книги, рекомендованные тем-то...

Еще важные маркетинговые "фишки"
ОЧЕНЬ нужна возможность анкетирования с сайта и сохранения результатов в БД. Как анонимного, так и из формуляра с автоматическим заполнением данных о пользователе. "Историю" ответов тоже нужно сохранять для анализа и выстраивания долгосрочных отношений.

Еще нужна возможность написания отзыва о работе библиотеки. По принципу "похвалить", "предложения", "пожаловаться", и чтобы ответы попадали в БД (для дальнейшего анализа). Т.е. если авторизованный читатель ответил, результаты ответа должны быть доступны из его формуляра. Нужно для удержания читателей, мотивации сотрудников и улучшения работы.

Я так понимаю, что большинство из этого Кирилл Соколинский заложил в J-Ирбис... И еще, новый J-Ирбис будет работать на других принципах, нежели старый J-Ирбис и Веб-Ирбис. Это позволит действительно писать сложные и нужные вещи. Так что я уверен, что все ваши пожелания в скором будущем будут реализованы. Правда очень сомневаюсь, что это будет в Веб-Ирбисе

Навеяно - [panbibliotekar.blogspot.com] (на украинском но есть картинки)

Некоторые системы (Алеф, УФД) умеют при поиске приравнивать «Ґ»=«Г» и «Ё»=«Е». Хотелось иметь такой параметр и в ИРБИСе.

Gena написал(а):
-------------------------------------------------------
> Ух ты! Все же рано Кирилл собирался Веб-Ирбис
> откладывать на дальнюю полку - слишком много на
> данный момент его инсталяций, в том числе и среди
> тех, кому новый функционал ДжейИрбиса не очень
> важен.

Пожелания пользователей как раз свидетельствуют в пользу того, что WEB ИРБИС уже полностью исчерпал свои возможности. Адекватная реализация технологии личного кабинета в WEB ИРБИС не возможна.

Целиком поддерживаю все идеи, высказанные ниже. Далее прокомментирую предложения в том порядке, в каком я вижу возможность их реализации.

Iskra написал(а):
-------------------------------------------------------
> GLUKa написал(а):
> --------------------------------------------------
> -----
> > Очень нужна возможность on-line продления книги
> на
> > руках в личном кабинете в модулях WEB-Ирбис и
> > J-ирбис.

Если это реализовано в WEB ИРБИС и если уже имеется готовый код ссылки, я могу попробовать включить его в WEB ИРБИС 2012.1. В J-ИРБИС 2.0 заказм буду заниматься ещё более серьёзно. Пока пока требует проработки сам принцип функционирования режима.


> Еще важные маркетинговые "фишки"
> ОЧЕНЬ нужна возможность анкетирования с сайта

> Еще нужна возможность написания отзыва о работе
> библиотеки. По принципу "похвалить",
> "предложения", "пожаловаться", и чтобы ответы
> попадали в БД (для дальнейшего анализа).

Компоненты формув, голосований для Joomla(J-ИРБИС) в большом количестве доступны в интернет. Это типичная задача, которая уже давно и успешно решается на коммерческих сайтах. Пожелания по включению конкретных компонентов для Joomla 2.5 в базовую поставку J-ИРБИС 2.0 буду рад выполнить.


> Очень нужна обратная связь от читателя: рейтинг
> книги (хотя бы показывать, какие издания -
> "хиты"), возможность отзыв написать, или
> рекомендовать (важно для корпоративных библиотек).
> Можно не всем давать возможность рекомендовать, а,
> только, определенным категориям (у нас, например,
> руководителям). Естественно, чтобы потом можно
> было "собрать" книги, рекомендованные тем-то...


Эта функция требует очень серьёзной работы по формализации. Получается, что нужно фиксировать:
1. Кто рекомендовал
2. Как оценил
3. Что рекомендовал

Полагаю, что для массовых библиотек придётся ограничиться рейтингом. Для ВУЗовских требуется обеспечить возможность добавления данных книгообеспеченноти. У преподавателя будет возможность выбрать целевые группы из базы VUZ.


> Еще нужно добавить простую, но важную возможность
> для читателя - в формуляре видеть список уже
> прочитанных им книг. С возможностью перехода по
> гиперссылке к любой книге в том числе для того,
> чтобы снова ее заказать при необходимости. Мы уже
> сделали, но эта возможность нужна в стандартной
> поставке.

Это действительно важно, реализуемо лишь с некоторыми оговорками. В ВУЗовских библиотеках неактуальные данные 40 поля очищаются, в противном случае происходит серьёзное замедление работы системы (студент в год может взять и сдать до очень много книг).

> Формуляр должен быть многофункциональным, а не
> только для того, чтобы смотреть, какие книги на
> руках.

Вопрос о личном кабинете читателя очень актуален. Буду заниматься.


PS
Здесь когда я говорил о планах реализации, то конечно имел в виду J-ИРБИС 2.0. Реализовать большинство указанных здесь возможностей в WEB ИРБИС практически не возможно.

Konstantinus написал(а):
-------------------------------------------------------
> Навеяно -
> [panbibliotekar.blogspot.com]
> st_17.html#more (на украинском но есть картинки)
>
> Некоторые системы (Алеф, УФД) умеют при поиске
> приравнивать «Ґ»=«Г» и «Ё»=«Е». Хотелось иметь
> такой параметр и в ИРБИСе.
Серьезная, нужная задача. Тем более учитывая недавние реформы орфографии
и даже смену алфавита сразу в нескольких государствах.
Хотя темя почти необъятная, в ней появляются все новые и новые сложности...

irbis_arbat@mail.ru



Редактировано 1 раз. Последний раз 09.10.2012 08:47 пользователем Lavrinovich.

Тем временем в Koha ребята научились комментировать БО.
[koha.tntu.edu.ua]

То есть авторизованный пользователь может оставить комментарий "хороший учебник", и т.д.

Vox populi - vox dei. Читательский рейтинг, подобие Имхонета. I like it. Рекомендательная библиография от сохи, из гущи читательских масс.
Думал, моя идея и как всегда опоздал. Лучше бы тогда сделать действительно пятибалльный рейтинг.
Однако идея сомнительная в принципе, независимо от механизма, от конкретной реализации. Обожаю (ненавижу) Достоевского, предпочитаю (не читаю) детективы. И что с того?
Для научной литературы есть индекс цитирования, ИМХО тоже очень сомнительный - например. в КНР чаще всего цитируют Мао Цзэдуна)...
Вердикт: не надо ничего такого в ИРБИСе!

irbis_arbat@mail.ru

Alio написал(а):
-------------------------------------------------------
> Предлагается ввести иерархическую типологию
> внешних объектов (951^H)
> На верхнем уровне:
> 01 - Текстовый ресурс
> 02 - Графический ресурс
> 03 - Аудио-ресурс
> 04 - Мультимедийный ресурс
> 05 - Интернет-ресурс
>
> На следующем уровне можно уточнять типологию
> ресурса. Это оставить на усмотрение пользователя.

Не можно, а нужно! И может быть, не только для внешних...
Например, в ГОСТе или правилах БО (точно не помню где) когда-то было примерно такое деление в виде перечисления: однотомники, многотомники, периодические издания, звукозаписи, кинофильмы... как будто не бывает многотомных и периодических АВД и ЭД. Например, был CD-ROM-журнал "Аурамедиа", не говоря уже о MSDN [msdn.microsoft.com] Теперь все в интернете, но хорошо ли это? Не помню кто, но помню, что в 1997 г. говорил: CD-ROM - второй контур интернета. Т.е. вдруг прервалась связь или она слишком медленная, и мало ли еще что...

irbis_arbat@mail.ru



Редактировано 1 раз. Последний раз 05.10.2012 13:21 пользователем Lavrinovich.

Отзывается (исключается из релиза 2012.1) доработка, связанная с использованием механизма морфологии при полнотекстовом поиске.