Почему до сих пор нет такой разработки? Библиографическое описание, помещаемое на обороте титульного листа или в конце всех современных изданий, легко поддается разбиению на отдельные поля, которые сразу можно передавать в запись ИРБИС. Таким образом появляется новый простой и эффективный способ формирования записей электронного каталога: БО сканируется, автоматически проверяется на ошибки (с использованием словаря) и после незначительного редактирования (а иногда и без него) из текста БО формируется новая запись. Я уже реализовал это в своем самодельном АРМе с интерфейсом, похожим на Каталогизатор (его вторая функция - передача текста оглавления в соответствующие поля записи). Я сам работаю оператором в библиотеке Саратовской государственной консерватории, поэтому могу сказать, что метод вполне удобный и практичный. Из связки ИРБИС + технологии Abbyy FineReader вообще, на мой взгляд, получилось бы неплохое решение для библиотек. Я называю его САБО - Система Автоматизации Библиографической Обработки. Не хочет ли ГПНТБ взять его себе на вооружение (понятно, что мне продукт FineReader Engine недоступен)?

Если использовать лицензию FR, тогда стоимость АРМа Каталогизатор скакнет. А вообще, делайте доклад, приезжайте на конференцию. Там мы и оценим по достоинству вашу разработку.

Совсем не новая идея. Этим занимались прежде всего во ВГБИЛ, еще где-то... и здесь вроде бы обсуждали...

irbis_arbat@mail.ru



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

Да я и хочу сказать, что идея буквально лежит на поверхности. Взять хотя бы этот проект. Правда, они таким образом сканировали уже имеющийся карточный каталог, а не вводили новые поступления (вот интересно, если карточки у них хорошего качества, отпечатанные на компьютере, они, что, печатали их не из АБИС, что им потребовалось делать ретроконверсию? А если старые, машинописные, то каким модулем распознавания они пользовались, если смогли эффективно с ними справиться? Разве что работа хорошо финансировалась).

Насчет увеличения стоимости Каталогизатора - имхо, уж лучше так, чем использовать в библиотеках связку пиратских программ FineReader + Word (или стоимость гипотетической новой версии перекроет и лицензию этих программ?). Можно было бы не навязывать дорогой вариант Каталогизатора всем, а предлагать его тем библиотекам, вроде нашей, которые не располагают большим количеством сотрудников и в то же время нуждаются в подробном расписывании сборников, предполагающем ввод оглавления статей и необходимость печатать карточки на отдельные статьи. А "продвинутым" библиотекам предложить за небольшие деньги отдельный АРМ для создания записей ЭК с использованием C-Pen (правда, для внедрения в него C-Pen SDK придется сам этот модуль писать на .NET, что, кстати, я и делаю).

Думаю, лучше это реализовывать не как часть АРма Каталогизатор, а как DLL, пришивающуюся к Интерфейсу. У меня сейчас есть пара модулей, которые загнаны в ДЛЛ, и вызываются прямо из интерфейса Ирбиса. Вполне удобно, а главное - обработанные данные бросаются прямиком в АРМ Каталогизатор.

А по поводу самого модуля - давно это надо было делать. Я как-то начинал, но потом наши "гуру" меня отвадили от этого, описав сложность алгоритма распознования (я делал не под описания в книги, а под каталожные карточки, которые, к сожалению, имеют большое количество вариантов оформления). Я использовал виндовский компонент MIDI - бесплатная платформа для распознования. Для обычного печатного текста работает почти без ошибок.

Вообще проект интересный. У вас он уже полностью реализован?

А не подскажете, где можно найти информацию о том, как расширять интерфейс Ирбиса с помощью DLL? А то мне пришлось создавать некое подобие собственного АРМа для добавления оглавления к имеющимся записям ЭК, а также для создания записей из отсканированного текста библиографического описания. На самом деле этот самодельный АРМ мне пока нужен, т.к. я по нему защищаю диплом, но для конечных пользователей вызов DLL из Каталогизатора, безусловно, будет удобнее. Вот только если писать интерфейс для C-Pen, с ним придется работать в среде .NET. Возможно ли будет вызывать из Ирбиса DLL, работающую под .NET?

Вот ссылка на ролик, описывающий процесс работы с программой. Проект пока нельзя назвать полностью готовым, хотя бы потому что используемый в нем компонент распознавания Nicomsoft OCR на текущий момент не обеспечивает такого уровня распознавания русского текста, при котором не приходилось бы ничего поправлять руками. Сам текст распознается неплохо, но периодически в словах "вылезают" несколько заглавных букв подряд или попадается целиком слово из заглавных букв. К тому же сам компонент платный, а лицензия на одного разработчика с правом распространения стоит 1400$. Пробовал дешевый компонент ABCocr, основанный на свободно распространяемой системе Tesseract, которую в Hewlett Packard писали с 1985 по 1995 гг., но его результат распознавания меня не удовлетворил - на типичном оглавлении сборника научных статей выдал какую-то абракадабру (Nicomsoft справился удовлетворительно, FineReader - вне конкуренции). MIDI не пробовал.

По Ирбис и ДЛЛ смотрите в RELEASE_OVERALL.DOC (Обычно лежит или в папке сервера ирбиса, или в папке с клиентами) Там есть раздел про функционал, добавленный в версии 2006.1. Привожу выдержку:


4. Предлагается возможность подключения пользовательских режимов, т.е. режимов, созданных самим пользователем-разработчиком (ИРБИС64). Это означает, что пользователь может "повесить" собственные режимы обработки (как пакетные, так и интерактивные) в главном меню и на панели инструментов.
Предполагается, что режим пользователя представляет собой функцию DLL (как в &unifor('+8...) – см. ниже)
Режимы пользователя описываются через INI-файл (irbisc.ini секция [USERMODE]) по следующей схеме - каждый внешний режим пользователя описывается следующими параметрами:
- UMDLLn - имя DLL (в случае нестандартного вызова функций перед именем DLL следует поставить символ *);
- UMFUNCTIONn - имя функции DLL, реализующей данный режим;
- UMPFTn - имя формата, в соответствии с которым осуществляется передача входных данных в функцию (формат применяется к текущей записи);
- UMNAMEn - название режима на естественном языке (для главного меню и подсказки);
- UMGROUPn - порядковый номер группы режимов в главном меню;
- UMICONn – имя иконки для отображения данного режима на панели инструментов (иконка включается в DLL в качестве ресурса типа ICON размером 16х16 ).
n – порядковый номер режим в списке (начиная с 0).
Общее количество режимов пользователя указывается в параметре UMNUMB.
Регламентируется формат данных, возвращаемых функцией режима. В общем случае это список строк (т.е. данных, разделенных символами $0D0A):
Конкретное содержание возвращаемых данных определяется кодом возврата функции режима (целое число).
В настоящей версии предлагаются следующие коды возврата:
- отрицательное число – ненормальное завершение режима, возвращаемые данные не учитываются:
- 0 – нормальное завершение, никакие данные не возвращаются;
- 1 – выполнена корректировка текущей записи, возвращаемые данные представляют собой текущую запись (полностью) в соответствии с форматом &unifor(‘+0’), а именно:
0
<mfn>#<статус записи>
0#<версия записи>
<метка поля 1>#<значение поля 1>
<метка поля 2>#<значение поля 2>
……………………
<метка поля N>#<значение поля N>
При этом данные <mfn>, <статус записи> и <версия записи> при возврате не учитываются.


У меня на этой основе сделан модуль для отправки электронных писем читателям. Плюс в том, что таким образом настраивается двухсторонняя связь АРМа с пользовательским модулем.

S-presso
Из бесплатных систем для OCR есть CuneiForm. Качество распознавания наилучшее среди бесплатных программ.
Gena

Цитата:

У меня на этой основе сделан модуль для отправки электронных писем читателям. Плюс в том, что таким образом настраивается двухсторонняя связь АРМа с пользовательским модулем.

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

woodyfon написал(а):
-------------------------------------------------------
> Из бесплатных систем для OCR есть CuneiForm.
> Качество распознавания наилучшее среди бесплатных
> программ.

Вот если бы еще кто-нибудь написал удобный в использовании готовый компонент на основе CuneiForm... И, насколько мне известно, они уже не обеспечивают поддержку своего продукта. У Nicomsoft в плане поддержки все очень хорошо, и их демо-версия компонента вполне функциональная. Вдобавок он уже может распознавать линии на изображении. Это можно использовать для определения точного месторасположения верхней горизонтальной и двух вертикальных линий слева на каталожной карточке. Цель - разработка модуля для "красивой" печати библиографического описания на предварительно отсканированной карточке, зная соответствующую величину отступа сверху и слева.

De modus cacandi*

Мое предложение. а скорее предположение, об интеграции в ИРБИС OCR обсуждалось здесь
[irbis.gpntb.ru]
с непонятным результатом.

_______________________________________________________________________

*Ф. Рабле. Гаргантюа и Пантагрюэль. Кто переведет, тот получит водокачку.

irbis_arbat@mail.ru



Редактировано 2 раз. Последний раз 11.04.2012 06:02 пользователем Lavrinovich.

Я идею распознания карточек в системе Имидж-каталога обсуждал с АИ два года назад на конференции и ничем хорошим это не закончилось - было объявлено, что это гигинтский объем работы на уровне дисера и что никто особо этим нзаниматьс не хочет, ибо смысла не видит. Так что уважаемый S-presso советую связаться с АИ и обсудить ваши успехи. С тем что у вас уже сделано, вполне могли бы попасть в группу разработчиков. А у ГПНТБ есть и Фаинридоровский СДК.

S-presso написал(а):
-------------------------------------------------------
> Да я и хочу сказать, что идея буквально лежит на
> поверхности. Взять хотя бы этот проект. Правда,
> они таким образом сканировали уже имеющийся
> карточный каталог, а не вводили новые поступления
> (вот интересно, если карточки у них хорошего
> качества, отпечатанные на компьютере, они, что,
> печатали их не из АБИС, что им потребовалось
> делать ретроконверсию? А если старые,
> машинописные, то каким модулем распознавания они
> пользовались, если смогли эффективно с ними
> справиться? Разве что работа хорошо
> финансировалась).
>
> Насчет увеличения стоимости Каталогизатора - имхо,
> уж лучше так, чем использовать в библиотеках
> связку пиратских программ FineReader + Word (или
> стоимость гипотетической новой версии перекроет и
> лицензию этих программ?). Можно было бы не
> навязывать дорогой вариант Каталогизатора всем, а
> предлагать его тем библиотекам, вроде нашей,
> которые не располагают большим количеством
> сотрудников и в то же время нуждаются в подробном
> расписывании сборников, предполагающем ввод
> оглавления статей и необходимость печатать
> карточки на отдельные статьи. А "продвинутым"
> библиотекам предложить за небольшие деньги
> отдельный АРМ для создания записей ЭК с
> использованием C-Pen (правда, для внедрения в него
> C-Pen SDK придется сам этот модуль писать на .NET,
> что, кстати, я и делаю).
Ага, будут версии Каталогизатора Professional, Special Edition, Lite...:)

irbis_arbat@mail.ru

Версионирование АРМа - не нужное по мне занятие, нужно все интегрировать в один, но удобный и эргономичный АРМ.

А в продолжение обсуждения темы, хочу добавить вот что. Когда я с АИ общался на тему распознования карточек в Имидж-каталоге, у меня была вполне конкретная задумка - распознать КК, а потом по распознаным данным выполнить поиск полного описания по Z39.50 или в Ирбис-Корпорации. Распознаная карточка - это не вся, а только часть информации. Ее надо еще дополнять и редактировать, а вот для поиска там оптимальное количество информации. И вот в этом русле, как мне кажется, было бы очень интересно работать, тем более что протокол Z39.50 давно описан вдоль и поперек, а протокол Ирбис-Корпорации под такое доброе дело можно было бы вытянуть из разработчиков.

Ну ясно же, про версии пошутил.
А что требуется дополнять и редактировать, тоже давно известно. Кажется, самый большой опыт у ПроСофт-М [www.prosoft-m]
А будет ли такой DLL автоидентифицировать и автораспихивать распознанные данные по полям? Вот в чем вопрос. Иначе в затее нет смысла. И реализуема ли она в принципе, неважно какими средствами?

***
C Имидж-каталогом знаком мало, но кажется. что он дублирует предыдущие проекты. Был ведь еще ИРБИС Ретрокон.
В любом случае сначала необходимо изучить весь имеющийся опыт!

irbis_arbat@mail.ru



Редактировано 4 раз. Последний раз 11.04.2012 05:33 пользователем Lavrinovich.

В такой ДЛЛ может быть все что угодно и с любыми возможностями. Фактически, это будет программа, сохраненная как ДЛЛ, а не как ЭКЗЕ.

Все что угодно - значит, мdжет быть и автопереводчик, и автоаннотатор...:)))
Насчет версионирования. А вот бы инсталлятор спрашивал, какие компоненты АРМа (или ИРБИСа) требуется установить, наподобие интсталлятора MS Office и других.
Получится много модификаций, своих у каждого пользователя, причем совместимых.

irbis_arbat@mail.ru



Редактировано 2 раз. Последний раз 11.04.2012 09:45 пользователем Lavrinovich.

Тут проще сделать компонент, который будет потом динамически включать или выключать новые модули, прописывая их в нужные ини-файлы. Достаточно простенький компнонет, как мне кажется

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

Gena написал(а):
-------------------------------------------------------
> Тут проще сделать компонент, который будет потом
> динамически включать или выключать новые модули,
> прописывая их в нужные ини-файлы. Достаточно
> простенький компнонет, как мне кажется

Это будет прекрасное, просто упоительное занятие для админа. Не шучу.

irbis_arbat@mail.ru

Gena написал(а):
-------------------------------------------------------
> Я идею распознания карточек в системе
> Имидж-каталога обсуждал с АИ два года назад на
> конференции и ничем хорошим это не закончилось -
> было объявлено, что это гигинтский объем работы на
> уровне дисера и что никто особо этим нзаниматьс не
> хочет, ибо смысла не видит. Так что уважаемый
> S-presso советую связаться с АИ и обсудить ваши
> успехи. С тем что у вас уже сделано, вполне могли
> бы попасть в группу разработчиков. А у ГПНТБ есть
> и Фаинридоровский СДК.


Ну, я-то свою систему распознавания БО набросал за несколько дней. Протестировал на паре-тройке книг - с автором/ами и их инициалами, с полным именем автора, на многотомном издании без автора. Вроде работает - правда, пока ввел только несколько книг в ЭК таким образом. В общем случае могут быть ошибки - например, при переносе части слова на другую строку (программа для каждого найденного поля БО автоматически заменяет перевод строки на пробел - видимо, надо сделать проверку по словарю всех слов, в составе которых встречаются подряд символы дефис и пробел и в случае их нахождения убирать эти символы), некоторые поля могут попасть не туда, но объем ручного ввода при каталогизации все равно существенно снижается. А насчет гигантского объема работы - это, наверное, если учитывать вообще все возможные случаи, проверять фамилии и названия городов по словарю, интеллектуально обрабатывать сведения об ответственности? Я такой целью не задавался - мне даже сказали, что одна только эта задумка с БО на целый диплом не потянет.

А может ли ГПНТБ прислать мне демо-версию FineReader SDK по эл. почте? Не для распространения вместе с моей программой, конечно, а только для служебного пользования в моей организации и демонстрации на защите диплома?

S-presso написал(а):
-------------------------------------------------------

> Ну, я-то свою систему распознавания БО набросал за
> несколько дней. Протестировал на паре-тройке книг
> - с автором/ами и их инициалами, с полным именем
> автора, на многотомном издании без автора. Вроде
> работает - правда, пока ввел только несколько книг
> в ЭК таким образом. В общем случае могут быть
> ошибки - например, при переносе части слова на
> другую строку (программа для каждого найденного
> поля БО автоматически заменяет перевод строки на
> пробел - видимо, надо сделать проверку по словарю
> всех слов, в составе которых встречаются подряд
> символы дефис и пробел и в случае их нахождения
> убирать эти символы), некоторые поля могут попасть
> не туда, но объем ручного ввода при каталогизации
> все равно существенно снижается.

Вообще для облегчения этой работы скорее всего надо применять регулярные выражения.


А насчет
> гигантского объема работы - это, наверное, если
> учитывать вообще все возможные случаи, проверять
> фамилии и названия городов по словарю,
> интеллектуально обрабатывать сведения об
> ответственности? Я такой целью не задавался - мне
> даже сказали, что одна только эта задумка с БО на
> целый диплом не потянет.

А к этому стремится не планируется?


>
> А может ли ГПНТБ прислать мне демо-версию
> FineReader SDK по эл. почте? Не для
> распространения вместе с моей программой, конечно,
> а только для служебного пользования в моей
> организации и демонстрации на защите диплома?

Это вы уж у Александра Иосифовича спрашивайте.

Gena написал(а):
>
> А к этому стремится не планируется?
>
Пока в ближайших планах - попытаться написать такую систему распознавания оглавления, которая не потребует ввода регулярных выражений для выделения границ элементов оглавления. Цель - быстрый ввод отсканированного оглавления в запись ЭК. Имеющаяся сейчас у меня система требует явно указывать левые и правые маркеры для элементов оглавления. Например, для имени автора статьи правым маркером может служить выражение "<буква>.<буква>." (т.е. инициал) или "<буква>.{<буква>.}" (инициал, после которого может быть любое количество инициалов), для названия статьи левым маркером может быть "{ }", правым - ".{.}|\t" (множество точек, разделяющих в оглавлении название пункта оглавления и номер страницы, которое обычно заменяется OCR-системами на табуляцию), для номера страницы левый маркер обычно "<цифра>", правый - "<Ввод>" (перевод строки). Понятно, что простому оператору ПК в библиотеке трудно самому составлять такие описания. Хорошо бы, если бы программа позволяла последовательно выделять несколько повторений для каждого из элементов оглавления, а сама составляла выражения для их границ. Идеальный вариант - полная автоматизация росписи оглавления по образу восстановления исходного вида документа в FineReader (вот это, пожалуй, действительно тема для диссертации).

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

Видимо, желание все оптимизировать может прийти только в том случае, если оператор - ты сам. Но, очевидно, случай оператора-разработчика редкий, иначе было бы много пользовательских разработок для Ирбиса. Оборотная сторона медали - в том, что оператор-разработчик пишет программу прежде всего для себя, с позиции программиста, и его программами сложно пользоваться другим операторам (либо по причине сложности, либо по причине консерватизма самих операторов). Это проблема практически всех моих программ, для которых я являюсь и разработчиком, и единственным пользователем.

Ну... Тут уж как вы себя поставите в общении со своими пользователями. У меня модуль работы с оглавлением установлен в 4 библиотеках и работают с ним именно библиотекари. Более того, так как я его ужа давно не менял, то многое забыл, а операторы (пользователи-библиотекари от 50 и выше) помнят и пользуются.

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



Редактировано 2 раз. Последний раз 13.07.2012 14:42 пользователем Gena.

Gena, а вы не могли бы прислать мне исходники своего модуля работы с оглавлением? Меня интересует не столько сам код, сколько то, каким образом dll встраивается в Каталогизатор и может передавать в него данные. А то из описания в RELEASE_OVERALL.DOC это как-то не очень понятно.

Вот как раз модуль работы с оглавлением у меня работает не как ДЛЛ, а как внешняя утилита, запускаемая при выборе нужного поля. Обмен данными идет через буфер обмена. Программа написана на VisualBasic. А вот модуль отправки электронных писем читателям уже сделан как Delphi DLL.

Спасибо, буду разбираться. А для модуля отправки писем не подскажете, как он встраивается в Ирбис?

в INI Каталогизатора добавляем:

[USERMODE]
UMNUMB=1
UMDLL0=test_dll.dll
UMFUNCTION0=UserMode
UMPFT0=Email
UMNAME0=Отправка E-mail читателю
UMGROUP0=2
UMICON0=

в директорию базы RDR копируем приложенный ФЛК и редактируем его под себя

''v11''/
'[F]'v10'[/F]'/
'[O]'v12'[/O]'/
'[E]'v32'[/E]'/
'[H]наш хост[/H]Логин[C]Пароль[/C][D]порт[/D][E]наш почтовый ящик[/E]'/
'формат должен выдать строки, обрамленные этими тегами. Это будет список задолженной литературы'/
'[N]формат должен выдать строки, обрамленные этими тегами. Это будет список новых поступлений[/N]'/
'[A]Путь к файлам, которые надо отправить читателю[/A]'/

Сейчас не могу найти рабочий формат, чуть позже его выложу для примера.

После этого при запуске АРМа должна на панели появится новая кнопка



Редактировано 1 раз. Последний раз 12.04.2012 17:58 пользователем Gena.

Gena
Пробовал поработать с вашим модулем оглавления, но при нажатии кнопки "Передать данные в Ирбис" возникает сообщение об ошибке "Runtime error '9': Subscript out of range". А подскажите: на выходе программы должна получаться запись ЭК в формате UTF-8? О самой программе: я бы добавил еще перевод в строчный регистр названий статей и фамилий авторов (чтобы первая буква осталась заглавной). И чтобы можно было печатать карточки на каждую статью из оглавления.