Опыт и разработки пользователей ИРБИС : ИРБИС
Мне уже было известно про разработку Геннадия, но в любом случае спасибо за ссылку, не знал, что это уже обсуждалось отдельно. Сам автор поделился ей по моей просьбе в другой теме. Что я могу сказать? Конечно, для бесплатной утилитки вещь весьма полезная. Однако она не избавляет от необходимости механического переноса отдельных элементов оглавления с целью их группировки по заранее заданному шаблону, поскольку:
Это может быть вполне приемлемо для набивщиков того типа, о которых я упоминал в конце первого сообщения, но точно не для меня
. Я изначально ставил перед собой задачу как можно более автоматизировать сам процесс восстановления структуры оглавления, примерно как это делает FineReader с документами. К сожалению, дело не обходится без настройки на конкретный вид оглавления. Но можно использовать и шаблоны для уже ранее встречавшихся структур.
В любом случае именно благодаря Геннадию Панарину и его программе у меня в дипломе появилась хотя бы одна реальная ссылка на аналогичные разработки... Не без критики, конечно, но таков закон жанра научной работы.
Предлагаю вам попробовать для сравнения мой плагин для Ирбиса, под который был создан отдельный АРМ "АльтерВвод" - [irbis.gpntb.ru]. Пример отсканированного оглавления можно взять отсюда. Наша задача - с как можно меньшими трудозатратами импортировать его в Ирбис. Запускаем программу, как описано в той теме, нажимаем кнопку пользовательского режима, которой соответствует плагин оглавления, вставляем текст оглавления из буфера обмена в рабочее окно плагина, загружаем этот файл (пункт меню "Файл" -> "Загрузить шаблон"). Выбираем в меню "Команды" -> "Запуск обработки", ждём какое-то время и можно посмотреть результаты. Правда, если вы копировали весь текст с самого начала, для первых нескольких пунктов оглавления распределение информации по подполям будет производиться с ошибками, но это и неудивительно, если вы изучите структуру элементов. В общем, автоматизация присутствует, но она не избавляет от необходимости думать. Впрочем, для опытного специалиста ввод практически любого оглавления по этой схеме не составит труда. Данная технология обработки оглавления основана на моей старой утилите почти пятилетней давности, которая в настоящий момент заброшена и представляет чисто исторический интерес. После того, как старый код парсера (на который я сейчас не могу смотреть без содрогания) был переведен мной на C#, модуль разбора оглавления оказался полностью интегрированным в приложение БАРСиК (где я уже мог работать с записями ЭК напрямую без необходимости осуществления экспорта-импорта). Но данный проект оказался плохо переносимым на клиентские машины. По этой причине я приостановил его развитие и начал создавать собственный АРМ в качестве аналога Каталогизатора с системой внешних подключаемых модулей для росписи БО и оглавления.
Редактировано 2 раз. Последний раз 07.02.2013 11:04 пользователем S-presso.
Вложения: Библиотека всемирной литературы. Part1.ptm (179 bytes)
Предлагаю просто посмотреть ролик. Правда, в нём показана работа уже неактуальной версии программы (с тех пор в дополнение к окну "Полное описание" появились новые вкладки "Картинка" и "КК", причём действие программы при выборе в тулбаре иконки сканера напрямую зависит от того, в какой именно вкладке мы находимся. Если в двух последних, то не будет автоматом запускаться распознавание и проверка орфографии. Вместо этого можно будет, например, установить расположение линий на карточке. Также теперь можно загружать сканы БО из файла).
[www.youtube.com]
Выбрали нужную область БО. Нажали на левую кнопку мышки, начали обводить прямоугольником область БО. В момент отпускания мышки - текстовые данные занесены в промежуточную ячейку и так далее. Согласен, что технология не использует возможность заимствования. Но ее вполне можно применить для ввода того же оглавления или аннотации. Подобным способом работает ABBYY Screen Reader.
Да, согласен: в том, что я сравнивал затраты на предлагаемые средства со стоимостью Office Professional, есть определённая натяжка. Дело в том, что у меня на рабочем месте стоит вообще Office Enterprise. И что характерно, не было больше ничего, и поставить самому нужное мне ПО было нельзя. По соображениям лицензионной чистоты мне отказали и в просьбе установить Virtual PC, чтобы я имел полный доступ хотя бы к виртуалке - а ведь у меня персональная академическая лицензия почти на все продукты Microsoft (ну, за исключением пресловутого Office'а). FineReader в сентябре, правда, поставили - и на том спасибо. Со своим собственным ПО работаю только с личного ноутбука, поскольку в данном учебном заведении я вообще на птичьих правах. По статусу нашей библиотеке в принципе не положена какая-либо должность, связанная с автоматизацией, поэтому я уже 5 лет нахожусь в положении простого оператора ЭВМ. Зато негласно мы одна из самых технически продвинутых библиотек
. Хорошо, что хоть начальство библиотеки осознаёт необходимость прогресса. Ещё с первых дней своей работы я увидел там сканеры и FineReader, иначе бы просто не стал связываться. Хотя нет: я бы сам принёс и то, и другое. Ну, а неизбежным этапом технической эволюции стала разработка БАРСиКа. Теперь я мечтаю внедрить подобные технологии повсеместно.
Возвращаясь к цене вопроса. Признаю, что мог ошибиться в своей оценке стоимости офисного пакета для библиотек. Но давайте посмотрим. 1500-1700 рублей - это стоимость лицензии на одно рабочее место? Для того же компьютера ABBYY FineReader 11 Professional Edition в версии для скачивания обойдётся в сумму чуть больше 4 т.р. - и это не считая академической скидки в 40 %, которую ABBYY предоставляет всем образовательным учреждениям. Если же обработка литературы осуществляется одновременно на нескольких компьютерах, целесообразно приобрести Corporate Edition - не думаю, что это окажется дороже, чем офисные пакеты на каждом рабочем месте. Правда, потребуются ещё сканеры. Но почему бы не потратиться на парочку? Ещё сейчас у многих есть собственные цифровые камеры, которые вполне могут заменить обычный сканер. Да что там - в FineReader'е уже с 10-й версии можно сносно распознавать текст, снятый хоть мобильным телефоном. Правда, у меня нет возможности проверить эту функцию по причине отсутствия актуальной модели телефона, оснащенного камерой. Зато имеется два сканера и ещё один дома плюс собственная камера, которая всегда под рукой.
К сожалению, ссылка не открывается - пишет, что сообщение не найдено.
Ну, я не столь категоричен. Вообще не понимаю, как OCR может быть ВМЕСТО чего бы то ни было (ну, разве что кроме тупого набора текста). В моём представлении OCR вполне мирно сосуществует как с текстовыми процессорами, так и с АБИС. У того же ABBYY был даже соответствующий продукт - ABBYY ScanTo Office. Так вот, мой БАРСиК - это своеобразная попытка сделать что-то типа ABBYY ScanTo Irbis. Причем не просто с экспортом результатов работы в виде отдельных записей ИРБИС (это умел делать и выложенный мной здесь несколькими сообщениями ранее "предок" нынешней САБО (Системы автоматизации библиографической обработки) под названием ПАРТИЗАН (Парсер-анализатор регулярной текстовой информации с заложенной автоматикой набора) - но он позволял вводить только оглавление, и не более чем из 200 пунктов (хотя, кажется, только сейчас мне попалась серия таких оглавлений - из сборников "Библиотеки всемирной литературы" - но с ними не то, что ПАРТИЗАН не справляется, БАРСиК и тот сохраняет записи лишь по частям в два захода, и лишь приложение под кодовым именем CIRBISC_NEW_UNICODE хоть и подвисает на время, но всё же героически выполняет экспорт-импорт и сохранение)), а с готовой оболочкой для просмотра всего ЭК и создания/модификации отдельных записей - но только средствами самой программы, без дубликации соответствующих функций Каталогизатора. Так что при желании можно, наверное, подключать и другие АБИС (Руслан, МАРК-SQL), если для них есть соответствующие программные интерфейсы к функциям для работы с БД и отдельными записями. Ау, есть тут представители ABBYY или их знакомые? Сделайте мне деловое предложение, и я готов поделиться всеми наработками!
В общем, я вижу два возможных вида конечного приложения, готового к распространению.
1. Можно сделать его IRBIS-specific, позволяющим выбирать из нескольких движков OCR в зависимости от предпочтений и финансовых возможностей конечного пользователя. Я так понимаю, лицензия на FineReader Engine стоит дорого, сама ГПНТБ использует её только для своего внутреннего приложения для ретроконверсии. Бесплатная пробная лицензия на движок ABBYY предоставляется различным организациям по запросу только ОДИН раз, и это лицензия на РАЗРАБОТКУ, которую можно установить лишь на ОДИН компьютер и срок использования истекает через ДВА МЕСЯЦА. Времени должно вполне хватить, чтобы набросать свой интерфейс со сканером и OCR, но явно не достаточно для полноценного использования конечного ПО хотя бы в рамках данной организации. Я успел реализовать многостраничное сканирование с распознаванием - в основном для чистого текста, но с некоторыми зачаточными функциями работы с областями (можно было сделать и больше - я лишь немного побаловался с FineReader Engine). Видимо, конечному пользователю САБО, желающему видеть эти функции в программе, придется самому раскошелиться на лицензию ABBYY - уже для ПОЛЬЗОВАТЕЛЕЙ (которая, насколько мне известно, тоже истекает через какой-то срок). Подозреваю, что проще будет просто купить FineReader Professional и использовать Copy / Paste. Ну, или надо как-то договариваться с ABBYY. Реальной альтернативы их движку, по крайней мере, в части распознавания русского языка, в настоящий момент нет. Правда, для распознавания библиографического описания я предпочитаю в своей программе использовать демо-версию компонента от Nicomsoft. Ее, в отличие от библиотеки компонентов ABBYY, можно продлевать неограниченно долго - но только, конечно, не при распространении в составе конечного продукта. Можно было бы купить неограниченную лицензию за $1400 (ее единственное ограничение установлено на количество разработчиков - 1, для команды до 4 разработчиков - уже $2400), и тогда у пользователя всегда будет хотя бы один предустановленный движок OCR. С распознаванием БО он справляется вполне достойно, чего, к сожалению, пока нельзя сказать об отсканированных оглавлениях. Кстати, для БО этот компонент оказался даже удобнее, чем FR Engine, требуя в целом меньше правок полученного текста "руками" (хотя, возможно, я просто не до конца разобрался в настройках FRE 9.0 для распознавания "чистого" текста без форматирования). Ну, а для обработки оглавлений можно лишь посоветовать пользователю переносить текст из FineReader. Либо, как я уже говорил, - см. выше. Потому как остальные известные мне компоненты (бесплатный Tesseract и основанный на нём коммерческий ABCocr) справляются с русским языком еще хуже. Правда, можно попробовать еще CuneiForm, но уж больно много возни с его подключением.
2. Можно было бы передать дальнейшую разработку САБО непосредственно ABBYY (а оно им надо ?!). Тогда они смогли бы реализовать все необходимые функции OCR на собственном движке, и свободно продавать продукт библиотекам. Этот вариант кажется мне (не знаю, что сказали бы сами представители ABBYY) даже более привлекательным. В конце концов, в силах этой компании сделать обработку оглавления еще более автоматизированной, не требующей вмешательства со стороны пользователя (ведь им, как я подозреваю, в большинстве случаев окажется человек, не обладающий такой же подготовкой, как я, создатель собственной разметки reg.exp. ПАРТИЗАН!). В общем, отсканированное оглавление будет так же непосредственно передаваться в ИРБИС или какую-то другую АБИС, как сейчас распознанный текст передается у них в Word и Acrobat. Про обработку БО и говорить нечего - если даже мне удалось более-менее решить эту проблему, пользуясь лишь своим опытом решения задач по информатике на строки. Думаю, специалисты ABBYY могли бы сделать всё так, чтобы мы вообще забыли про клавиатурный ввод в ЭК. На очереди - задача распознавания данных с каталожных карточек (не рукописных, но достаточно старых) с их последующим внесением в базу. Здесь надо научиться удалять лишние линии, как при работе с captcha (кстати, в одной из программ для автоматизации скачивания с рапиды и других файлообменников, использующих капчу, как раз применяется FR Engine - было бы интересно узнать, какая лицензия в данном случае была предоставлена разработчикам). Работа с линиями на исходной картинке могла бы пригодиться и для печати КК при использовании разлинованных карточек. Движок OCR автоматически определяет расположение линий и соответствующим образом подгоняет форматирование текста на карточке. Сейчас я провожу опыты с подобным экспериментальным модулем БАРСиКа. К сожалению, пока Nicomsoft OCR находит линии не там, где нужно (он пока не умеет объединять смежные линии в одну). Но, как я понял уже, данный функционал мало кому нужен (делаю для себя).
Что еще должна включать в себя САБО (Напомню: Система автоматизации библиографической обработки)? Может быть, оптимизированный модуль для библиотек, предназначенный для сканирования книг с целью изготовления цифровых копий? С минимумом настроек, понятных любому библиотекарю. Возможностью включения / выключения OCR, переноса отсканированного оглавления и/или БО в ИРБИС64, а самой цифровой копии - в ИРБИС128. Если у вас есть другие предложения, поделитесь, пожалуйста.
irbis_arbat@mail.ru
Редактировано 1 раз. Последний раз 29.11.2012 05:29 пользователем Lavrinovich.
Забавно:) Если стоит задача только печатать карточки, то покупать ИРБИС и не нужно - вполне достаточно демоверсии. Можно вообще наделать своих шаблонов для разных видов карточек в Word'е (его ведь тоже, наверное, покупали?) и дальше штамповать их прямо в редакторе. Но это если не требуется создавать отдельные записи. Я вот, наоборот, стараюсь вносить в каталог всё, даже старые издания, если требуется только новая карточка на них. Мало ли, вдруг пригодится в будущем? К тому же, не приходится самому додумывать внешний вид карточки.
Кстати, демоверсия Ирбиса позволяет не только печатать карточки, но и выполнять вообще практически всю работу, в том числе и удалённо. Если предварительно отсканировать библиографические описания на титульных листах изданий и/или их оглавления (или попросить кого-нибудь это сделать), можно выполнять всю дальнейшую обработку у себя дома. При этом, пользуясь БАРСиКом, я вообще свожу всю механическую работу по набивке текста к минимуму. В дальнейшем остается только импортировать созданные записи в базу данных на работе. Вот вам потенциальная возможность для фриланса.
В идеале хорошо бы вообще с любой АБИС. Не составит труда написать прослойки для других систем, так же как я это сделал для ИРБИС. Я уже писал об этом чуть выше. Тут должен помочь абстрактный класс - назовём его, как у меня, DBAccess. Именно к его методам будут обращаться клиентские модули для работы непосредственно с базой (в моём случае их два - один отображает всю базу в целом и каждую запись в отдельности, позволяя вызывать для неё функции обработки бибописания или оглавления, принимать из других модулей все изменения записи, отображать их и позволять сохранять; второй модуль позволяет просматривать отдельные строки оглавления и добавлять их к записи). А сами методы могут быть реализованы в классах-наследниках DBAccess, таких как IRBIS_DBAccess, Ruslan_DBAccess и др. Но это в идеале. А на практике мне приходится пока каждый раз перекомпилировать своё приложение, если я захочу запустить его на новой машине. Предполагаю, что это связано именно с irbis_client64.dll - нужно каждый раз выстраивать связи. К сожалению, не могу сказать точно, в каком именно месте возникает ошибка - ведь стоит мне воспользоваться отладчиком, как программа тут же начинает работать нормально, поскольку она уже перестроена. Не знаю, удастся ли мне сделать приложение не привязанным к конкретной машине, на которой оно работает (как все прочие мои приложения). Вариант с поставкой в виде исходных кодов, как в случае с программами под Linux, тут явно не годится (и не только потому, что не хочется показывать исходники, - нельзя же заставлять конечных пользователей держать на компьютере установленную визуальную студию от Microsoft?).
Это именно наш случай, и именно к подобным условиям работы относятся приведённые здесь ранее критические замечания в мой адрес:
Господи, да разве я что-то пытаюсь отметать! Я обеими руками за новые технологии. Просто в данном случае полностью уместна аналогия с необитаемым островом - оказавшись сам в положении этакого Робинзона, в отрыве, так сказать, от цивилизации, я вынужден был самостоятельно создавать для себя её блага, развивать технический прогресс с нуля. А окажутся ли созданные в результате этого средства полезными для других пользователей, это уже другой вопрос.
А наше участие в корпорации, по крайней мере, в данный момент невозможно по вполне банальной причине - начальство отказалось выделять на это мероприятие деньги. Как, впрочем, и на Web-сервер с OPAC-IRBIS'ом. Так что это они сокращают эффективность нашей работы, не я. Зато у нас есть "БАРСиК"
. Точнее, обитал у меня на ноутбуке до вчерашнего дня, когда я по неосторожности удалил весь раздел ноутбучного жёсткого диска... Что ж, пусть это простимулирует меня в доработке модулей с тем, чтобы можно было запускать их непосредственно на рабочем компьютере, подключённом к электронному каталогу библиотеки. В текущем виде я не могу выложить эти наработки в публичный доступ по ряду причин. Но за новогодние праздники постараюсь упростить средства их поставки потенциальному пользователю и интеграции с Ирбисом (приходится учитывать ситуацию, когда на клиентскую машину на рабочем месте без ведома администратора вообще нельзя установить никакое ПО). Понимаю, что придётся проводить тотальный рефакторинг, но если получится, тогда я выложу здесь демо-версии всего, что у меня имеется на сегодняшний момент. Правда, для этого, по-видимому, придётся внедрять свой АРМ с системой плагинов.
Ну, если вы настаиваете, то, видимо, придётся писать... Тем более, что концепция сейчас более-менее прояснилась у меня в голове. Если всё получится, то новый АРМ должен будет содержать не только таблицы рабочих листов, но и этот самый редактор, причём редактирование записей можно будет проводить синхронно в обоих режимах - подобно тому, как в визуальной среде проектирования изменяешь какие-либо значения в текстовых полях (например, имя формы) и они параллельно изменяются и в конструкторе.
Я как раз рассматриваю идею о том, что новый программный модуль для Ирбиса мог бы стать своеобразным средством разработки, визуальным конструктором собственных, проектируемых под конкретную задачу АРМов. Например, вам не нравится АРМ Читатель. Хорошо, напишите свой собственный в Дельфи-подобной среде на основе визуальных компонентов, набор которых включает в себя и специальные библиографические компоненты (таблицы и текстовые редакторы). Такова общая концепция на сегодняшний момент. Больше говорить об этом пока не хочется до представления рабочего прототипа.
Редактировано 1 раз. Последний раз 29.12.2012 19:16 пользователем S-presso.
) - правда, в моей текущей классификации возможных продуктов уже присутствует БАРСиК - это набор подпрограмм для упрощения каталогизации, из которых в качестве плагина IRBIS у меня уже работает анализатор БО. Или, может быть, переименовать последний в Б.А.Р.Т. (Библиографический Анализ Распознанного Текста?) Тогда БАРСИКом можно было бы назвать АРМ для ввода данных в ЭК (собственно, он уже и существует в таком виде, но я хотел переписать его оболочку на C++ Builder (чтобы затем перестроить её средствами Визуального БАРСа) и сделать существующие средства автоматизации ввода в виде плагинов к ней.
Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: S-presso (IP-адрес скрыт)
Дата: 01, November, 2012 16:52
Давно хотелось высказать некоторые свои соображения по поводу специализированного текстового редактора, который можно было бы применять в библиотеках, а также подытожить свой опыт автоматизации вообще. Сразу оговорюсь, что речь не идёт о неком мифическом ИРБИС-Офисе как замене Microsoft Office. Такой изначально мертворождённый (imho) продукт ещё можно было бы, наверное при большом желании и наличии энтузиастов разработать в режиме open source, но смысла в этом мало. Уже есть Open Office и другие свободные продукты, которыми всегда можно воспользоваться, если надо просто набрать текст или же сделать что-то более-менее сложное (например, применить сложное форматирование к этому тексту).
Почему я выступаю против MS Office в библиотеках? Если речь идёт о легальном приобретении программы, то это неоправданная трата средств. Если же у вас эта проблема не стоит, то прошу воздержаться от дальнейшего чтения этой темы. Впрочем, если вы уже купили офисный пакет, это не значит, что ничего из сказанного ниже не сможет вас заинтересовать.
Давайте порассуждаем на такую тему. Откуда берётся большая часть данных для внесения в электронные каталоги? Непосредственно со страниц книг и других печатных изданий, верно? Спрашивается, а зачем нам повторно вводить эти данные с клавиатуры, если они и так уже, как правило, содержатся в печатном виде? Разные рукописи, а также заимствование чужих записей мы сейчас не рассматриваем. Создавая новую запись, мы заполняем поля различными библиографическими данными. Так вот, если они все собраны воедино на одной странице книги (как это часто бывает в современных изданиях), достаточно отсканировать и распознать эту текстовую область, а затем проанализировать все данные и распределить их по полям. Всё участие человека в этом процессе сводится к первичной проверке текста на ошибки (с подчеркнутыми красным цветом словами и предложением вариантов) и вставке некоторых разделительных символов между полями, которые могут оказаться пропущенными (чаще всего оказывается пропущен дефис (или тире - тут без разницы) после точки, следующей за очередным полем и предваряющей новое). Иногда требуется удалить авторский знак. Затем нажатием одной кнопки мы отправляем данные в запись. Сохраняем ее, и дальше можно уже при необходимости вносить исправления обычными средствами Каталогизатора. Легче ведь, чем создавать запись вручную, правда? Кто скажет нет - тот просто недостоин работать каталогизатором. Замечу, что всё сказанное - это не какой-нибудь долгосрочный проект, а описание нашего реального опыта. Подробнее можно обсудить здесь или здесь.
Рассмотрим теперь ситуацию, когда различные данные об издании разбросаны по одной или нескольким страницам, когда нам уже приходится думать, в какое поле что внести. Должны ли мы использовать для этого клавиатуру? Нет, ведь напечатанный текст можно распознать. Конечно, зачастую набрать самим быстрее, чем сканировать и распознавать несколько страниц текста, а затем еще думать, что оттуда и куда скопировать. Но ведь можно сканировать и отдельные строчки. Если кто не знает, именно для этого предназначено устройство под названием C-Pen. Кстати, ядро распознавания текста (FineReader Engine) в нём уже встроено. Конечно, его не удобно применять для сколько-нибудь больших объемов текста, например для оглавления, но для заполнения отдельных полей - самое то.
Далее. Содержимое некоторых полей иногда требует предварительной обработки перед помещением в запись. Чаще всего требуется перевести текст из заглавного регистра в строчный или перенести инициалы автора в конец (это уже касается заполнения полей оглавления 922 или 330). Разве стандартный Word, который мы купили за такие большие деньги, предоставляет нам для этого какие-либо средства? Ну, если только самим писать макросы. Да и то, передавать данные из C-Pen в Word, затем применять макрос и передавать в Каталогизатор - неудобно. Что-то есть явно лишнее в этой цепи. Правильно, Word.
Теперь подходим к самому главному. Представим, что мы уже приобрели дорогостоящий офисный пакет и, естественно, вправе ожидать, что он будет тесно интегрирован в наши процессы бибобработки. Какие возможности предоставляет в этом плане Word? Да никаких. Всё, что мы можем сделать, это выделять в нем фрагменты текста и переносить их в отдельные поля записи ЭК с помощью буфера обмена. Не очень эффективная технология для XXI века, так ведь? При этом, если нам нужно внести длинное предварительно отсканированное оглавление, работа может растянуться на долгие часы. А ведь достаточно пометить особыми маркерами (не в самом тексте, а в настройках параметров элементов оглавления!) границы отдельных подполей оглавления, и оглавление можно будет перенести всё целиком. Как именно это реализовано у меня, я уже вкратце упоминал здесь, а для глубокого проникновения в тему можно скачать мою работу.
Ну и, наверное, излишним будет говорить, что для печати карточек нам Word тоже не нужен.
Задумаемся, а для чего он нам может всё-таки оказаться нужен? Набирать тексты? Open Office. Сканировать документы? Adobe Reader (в него можно экспортировать изображения после обработки). Сканировать с распознаванием и сложным форматированием? Так ведь можно сохранить результаты, полученные в FineReader, в формат DOCX, и открыть в том же Open Office. А создание сложных макетов текста - это уже прерогатива редакций, а не библиотек. Вот пусть они и покупают Microsoft Office. У нас же - обратная задача: извлечение текстовых данных со страниц напечатанных изданий. Что нам для этого потребуется?
1. Сканер и (опционально) C-Pen
2. ABBYY FineReader
3. Специализированные средства для интеграции с ИРБИС.
И 1) и 2) - вполне доступные вещи для большинства библиотек. Их суммарная стоимость вполне сопоставима с Office Professional. Что касается 3), то этим уже несколько лет из чистого энтузиазма занимаюсь, например, я. Исходники и бинарники дать не могу, но опытом поделюсь.
В моей программе сразу в нескольких местах применяются встроенные текстовые редакторы. Если пользоваться всеми возможностями этого компонента, можно даже создать что-то похожее на Word. Но поскольку сам компонент платный, ни о каком open source не может идти и речь. Какие специфические возможности текстовой обработки нам понадобятся ещё, кроме упомянутых мной ранее? Удаление лишних пробелов и переводов строк. Всё это должно использоваться и при распознавании библиографического описания, и при анализе оглавления. Что ещё могло бы оказаться полезным? Применение intellisense для автодополнения вводимых слов с возможностью выбора из списка. Почему это до сих пор не сделано в Word? Просто Microsoft это не надо. Почему-то в Visual Studio - надо, а в Word'е - нет. Тексты ведь вводят не только набивщики с рефлексами собаки Павлова.
Редактировано 1 раз. Последний раз 02.11.2012 08:01 пользователем S-presso.
Почему я выступаю против MS Office в библиотеках? Если речь идёт о легальном приобретении программы, то это неоправданная трата средств. Если же у вас эта проблема не стоит, то прошу воздержаться от дальнейшего чтения этой темы. Впрочем, если вы уже купили офисный пакет, это не значит, что ничего из сказанного ниже не сможет вас заинтересовать.
Давайте порассуждаем на такую тему. Откуда берётся большая часть данных для внесения в электронные каталоги? Непосредственно со страниц книг и других печатных изданий, верно? Спрашивается, а зачем нам повторно вводить эти данные с клавиатуры, если они и так уже, как правило, содержатся в печатном виде? Разные рукописи, а также заимствование чужих записей мы сейчас не рассматриваем. Создавая новую запись, мы заполняем поля различными библиографическими данными. Так вот, если они все собраны воедино на одной странице книги (как это часто бывает в современных изданиях), достаточно отсканировать и распознать эту текстовую область, а затем проанализировать все данные и распределить их по полям. Всё участие человека в этом процессе сводится к первичной проверке текста на ошибки (с подчеркнутыми красным цветом словами и предложением вариантов) и вставке некоторых разделительных символов между полями, которые могут оказаться пропущенными (чаще всего оказывается пропущен дефис (или тире - тут без разницы) после точки, следующей за очередным полем и предваряющей новое). Иногда требуется удалить авторский знак. Затем нажатием одной кнопки мы отправляем данные в запись. Сохраняем ее, и дальше можно уже при необходимости вносить исправления обычными средствами Каталогизатора. Легче ведь, чем создавать запись вручную, правда? Кто скажет нет - тот просто недостоин работать каталогизатором
. Замечу, что всё сказанное - это не какой-нибудь долгосрочный проект, а описание нашего реального опыта. Подробнее можно обсудить здесь или здесь.
Рассмотрим теперь ситуацию, когда различные данные об издании разбросаны по одной или нескольким страницам, когда нам уже приходится думать, в какое поле что внести. Должны ли мы использовать для этого клавиатуру? Нет, ведь напечатанный текст можно распознать. Конечно, зачастую набрать самим быстрее, чем сканировать и распознавать несколько страниц текста, а затем еще думать, что оттуда и куда скопировать. Но ведь можно сканировать и отдельные строчки. Если кто не знает, именно для этого предназначено устройство под названием C-Pen. Кстати, ядро распознавания текста (FineReader Engine) в нём уже встроено. Конечно, его не удобно применять для сколько-нибудь больших объемов текста, например для оглавления, но для заполнения отдельных полей - самое то.
Далее. Содержимое некоторых полей иногда требует предварительной обработки перед помещением в запись. Чаще всего требуется перевести текст из заглавного регистра в строчный или перенести инициалы автора в конец (это уже касается заполнения полей оглавления 922 или 330). Разве стандартный Word, который мы купили за такие большие деньги, предоставляет нам для этого какие-либо средства? Ну, если только самим писать макросы. Да и то, передавать данные из C-Pen в Word, затем применять макрос и передавать в Каталогизатор - неудобно. Что-то есть явно лишнее в этой цепи. Правильно, Word.
Теперь подходим к самому главному. Представим, что мы уже приобрели дорогостоящий офисный пакет и, естественно, вправе ожидать, что он будет тесно интегрирован в наши процессы бибобработки. Какие возможности предоставляет в этом плане Word? Да никаких. Всё, что мы можем сделать, это выделять в нем фрагменты текста и переносить их в отдельные поля записи ЭК с помощью буфера обмена. Не очень эффективная технология для XXI века, так ведь? При этом, если нам нужно внести длинное предварительно отсканированное оглавление, работа может растянуться на долгие часы. А ведь достаточно пометить особыми маркерами (не в самом тексте, а в настройках параметров элементов оглавления!) границы отдельных подполей оглавления, и оглавление можно будет перенести всё целиком. Как именно это реализовано у меня, я уже вкратце упоминал здесь, а для глубокого проникновения в тему можно скачать мою работу.
Ну и, наверное, излишним будет говорить, что для печати карточек нам Word тоже не нужен.
Задумаемся, а для чего он нам может всё-таки оказаться нужен? Набирать тексты? Open Office. Сканировать документы? Adobe Reader (в него можно экспортировать изображения после обработки). Сканировать с распознаванием и сложным форматированием? Так ведь можно сохранить результаты, полученные в FineReader, в формат DOCX, и открыть в том же Open Office. А создание сложных макетов текста - это уже прерогатива редакций, а не библиотек. Вот пусть они и покупают Microsoft Office
. У нас же - обратная задача: извлечение текстовых данных со страниц напечатанных изданий. Что нам для этого потребуется?
1. Сканер и (опционально) C-Pen
2. ABBYY FineReader
3. Специализированные средства для интеграции с ИРБИС.
И 1) и 2) - вполне доступные вещи для большинства библиотек. Их суммарная стоимость вполне сопоставима с Office Professional. Что касается 3), то этим уже несколько лет из чистого энтузиазма занимаюсь, например, я
. Исходники и бинарники дать не могу, но опытом поделюсь.
В моей программе сразу в нескольких местах применяются встроенные текстовые редакторы. Если пользоваться всеми возможностями этого компонента, можно даже создать что-то похожее на Word. Но поскольку сам компонент платный, ни о каком open source не может идти и речь. Какие специфические возможности текстовой обработки нам понадобятся ещё, кроме упомянутых мной ранее? Удаление лишних пробелов и переводов строк. Всё это должно использоваться и при распознавании библиографического описания, и при анализе оглавления. Что ещё могло бы оказаться полезным? Применение intellisense для автодополнения вводимых слов с возможностью выбора из списка. Почему это до сих пор не сделано в Word? Просто Microsoft это не надо. Почему-то в Visual Studio - надо, а в Word'е - нет. Тексты ведь вводят не только набивщики с рефлексами собаки Павлова
.Редактировано 1 раз. Последний раз 02.11.2012 08:01 пользователем S-presso.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: woodyfon (IP-адрес скрыт)
Дата: 01, November, 2012 19:58
Когда бибилотеки закупают Office, редко используются для интеграции с АБИС. Обычно для набора текста и отчетов.
Как по мне, была бы интересна идея вводить библиографические данные мышкой, а не с клавиатуры. Например, выбрали мышкой кнопку "Заглавие" на отсканированном титульном листе и обороте обвели область. Далее через средства OCR текст представлен согласно формату и тулиться в ячейку заглавия. После ввода всех необходимых данных каталогизатор проверяет/редактирует, если требуется, подготовленные данные и отправляет их в каталог. Но даже так это не будет быстрее работы опытных каталогизаторов, которые досконально знают БО и библиотечный формат АБИС. Такая технология повзолит всего лишь быстрее обучить новых сотрудников библиотечной технологии.
Как по мне, была бы интересна идея вводить библиографические данные мышкой, а не с клавиатуры. Например, выбрали мышкой кнопку "Заглавие" на отсканированном титульном листе и обороте обвели область. Далее через средства OCR текст представлен согласно формату и тулиться в ячейку заглавия. После ввода всех необходимых данных каталогизатор проверяет/редактирует, если требуется, подготовленные данные и отправляет их в каталог. Но даже так это не будет быстрее работы опытных каталогизаторов, которые досконально знают БО и библиотечный формат АБИС. Такая технология повзолит всего лишь быстрее обучить новых сотрудников библиотечной технологии.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: А. Роман (IP-адрес скрыт)
Дата: 02, November, 2012 04:38
Идея интересная, но на мой взгляд не учитывает некоторых существенных вещей и в целом не менее трудозатратная, нежели переключение по полям рабочего листа.
1. Отметая в самом началне технологии заимствования записей и в целом корпоративность работы ИРБИС-корпорация, LIBNET, МАРС, АРБИКОН, многочисленные Z39.50 сервера и т.д. (в том смысле, что один в поле - не воин) СУЩЕСТВЕННО сокращаете эффективность работы. ДОКАЗАННЫЙ ФАКТ.
Работа современных средств заимствования в ИРБИС (как в 64-м и особенно в 128-м (инлайн-заимствование)) проста и до предела удобна.
2. Перечисленные вами программные и аппаратные средства, тоже стоят определенных денег. Утверждение о дороговизне Microsoft Office вызывает БООЛЬШИЕ сомнения, т.к. для академических организаций (см. условия Academic Open License) библиотек, гос учреждений или образовательных учреждений действуют значительные скидки 1500-1700 рублей за 1 лицензию. Потом, зачем нужен пакет Professional??? Вы собираетесь во всех библиотеках использовать ACCESS??? Standard - за глаза.
3. Сообществу надо активнее работать с издательствами в плане получения от них информации об изданиях в RUSMARC или XML форматах, каждый из которых вполне можно использовать для импорта в ИРБИС. Сейчас для этого есть повод - активный рост числа ЭБС и вхождения в их состав материалов мелких издательств. Постепенно, они начинают организовывать сервисы эксорта записей в RUSMARC (например - Книгафонд, Лань). Следующий шаг - предоставление этой информации на Z39.50 серверах.
Поэтому, на мой взгляд заменять полностью эти технологии там, где проще использовать труд коллег по цеху, сажая на необитаемом острове человека со сканером и книгами - напрасное занятие.
4. В программном модуле при работе мышкой предполагается открывать контекстное меню и из него выбирать какой элемент БО копируется? Если так, то перечень позиций меню будет тоже не маленьким.
5. Какое количество кликов мышкой в среднем придется делать библиотекарю и какова будет средняя продолжительность ввода БО???
Конечно, облегчать задачу нужно, но там, где это действительно требуется и где это значительно облегчит задачу.
Как пример - разработка Панарина Геннадия
К слову, недавно проходил семинар по РИНЦ в СПбГУ на котором в числе прочего, в общих чертах, было сказано о технологии ввода данных в систему - копирование библиографического списка в поле, при обработке которого система сама разносит по полям элементы БО. Опыт интересный, НО ооочень спорный, т.к. требует значительной "доработки напильником".
Редактировано 2 раз. Последний раз 02.11.2012 04:41 пользователем А. Роман.
1. Отметая в самом началне технологии заимствования записей и в целом корпоративность работы ИРБИС-корпорация, LIBNET, МАРС, АРБИКОН, многочисленные Z39.50 сервера и т.д. (в том смысле, что один в поле - не воин) СУЩЕСТВЕННО сокращаете эффективность работы. ДОКАЗАННЫЙ ФАКТ.
Работа современных средств заимствования в ИРБИС (как в 64-м и особенно в 128-м (инлайн-заимствование)) проста и до предела удобна.
2. Перечисленные вами программные и аппаратные средства, тоже стоят определенных денег. Утверждение о дороговизне Microsoft Office вызывает БООЛЬШИЕ сомнения, т.к. для академических организаций (см. условия Academic Open License) библиотек, гос учреждений или образовательных учреждений действуют значительные скидки 1500-1700 рублей за 1 лицензию. Потом, зачем нужен пакет Professional??? Вы собираетесь во всех библиотеках использовать ACCESS??? Standard - за глаза.
3. Сообществу надо активнее работать с издательствами в плане получения от них информации об изданиях в RUSMARC или XML форматах, каждый из которых вполне можно использовать для импорта в ИРБИС. Сейчас для этого есть повод - активный рост числа ЭБС и вхождения в их состав материалов мелких издательств. Постепенно, они начинают организовывать сервисы эксорта записей в RUSMARC (например - Книгафонд, Лань). Следующий шаг - предоставление этой информации на Z39.50 серверах.
Поэтому, на мой взгляд заменять полностью эти технологии там, где проще использовать труд коллег по цеху, сажая на необитаемом острове человека со сканером и книгами - напрасное занятие.
4. В программном модуле при работе мышкой предполагается открывать контекстное меню и из него выбирать какой элемент БО копируется? Если так, то перечень позиций меню будет тоже не маленьким.
5. Какое количество кликов мышкой в среднем придется делать библиотекарю и какова будет средняя продолжительность ввода БО???
Конечно, облегчать задачу нужно, но там, где это действительно требуется и где это значительно облегчит задачу.
Как пример - разработка Панарина Геннадия
К слову, недавно проходил семинар по РИНЦ в СПбГУ на котором в числе прочего, в общих чертах, было сказано о технологии ввода данных в систему - копирование библиографического списка в поле, при обработке которого система сама разносит по полям элементы БО. Опыт интересный, НО ооочень спорный, т.к. требует значительной "доработки напильником".
Редактировано 2 раз. Последний раз 02.11.2012 04:41 пользователем А. Роман.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: S-presso (IP-адрес скрыт)
Дата: 02, November, 2012 09:39
Цитата:А. Роман
Конечно, облегчать задачу нужно, но там, где это действительно требуется и где это значительно облегчит задачу.
Как пример - разработка Панарина Геннадия
Мне уже было известно про разработку Геннадия, но в любом случае спасибо за ссылку, не знал, что это уже обсуждалось отдельно. Сам автор поделился ей по моей просьбе в другой теме. Что я могу сказать? Конечно, для бесплатной утилитки вещь весьма полезная. Однако она не избавляет от необходимости механического переноса отдельных элементов оглавления с целью их группировки по заранее заданному шаблону, поскольку:
Цитата:Gena
4. Для ввода оглавлений и перечня статей надо принять следующие условия:
- статьи/разделы отделяются друг от друга одной пустой строкой
- статья/раздел должна быть отредактированна до вида
[Заглавие]
[ФИО_1]
...
[ФИО_N]
[Страницы]
[пустая строка]
Это может быть вполне приемлемо для набивщиков того типа, о которых я упоминал в конце первого сообщения, но точно не для меня
. Я изначально ставил перед собой задачу как можно более автоматизировать сам процесс восстановления структуры оглавления, примерно как это делает FineReader с документами. К сожалению, дело не обходится без настройки на конкретный вид оглавления. Но можно использовать и шаблоны для уже ранее встречавшихся структур.
В любом случае именно благодаря Геннадию Панарину и его программе у меня в дипломе появилась хотя бы одна реальная ссылка на аналогичные разработки... Не без критики, конечно, но таков закон жанра научной работы
.
Предлагаю вам попробовать для сравнения мой плагин для Ирбиса, под который был создан отдельный АРМ "АльтерВвод" - [irbis.gpntb.ru]. Пример отсканированного оглавления можно взять отсюда. Наша задача - с как можно меньшими трудозатратами импортировать его в Ирбис. Запускаем программу, как описано в той теме, нажимаем кнопку пользовательского режима, которой соответствует плагин оглавления, вставляем текст оглавления из буфера обмена в рабочее окно плагина, загружаем этот файл (пункт меню "Файл" -> "Загрузить шаблон"). Выбираем в меню "Команды" -> "Запуск обработки", ждём какое-то время и можно посмотреть результаты. Правда, если вы копировали весь текст с самого начала, для первых нескольких пунктов оглавления распределение информации по подполям будет производиться с ошибками, но это и неудивительно, если вы изучите структуру элементов. В общем, автоматизация присутствует, но она не избавляет от необходимости думать
. Впрочем, для опытного специалиста ввод практически любого оглавления по этой схеме не составит труда. Данная технология обработки оглавления основана на моей старой утилите почти пятилетней давности, которая в настоящий момент заброшена и представляет чисто исторический интерес. После того, как старый код парсера (на который я сейчас не могу смотреть без содрогания) был переведен мной на C#, модуль разбора оглавления оказался полностью интегрированным в приложение БАРСиК (где я уже мог работать с записями ЭК напрямую без необходимости осуществления экспорта-импорта). Но данный проект оказался плохо переносимым на клиентские машины. По этой причине я приостановил его развитие и начал создавать собственный АРМ в качестве аналога Каталогизатора с системой внешних подключаемых модулей для росписи БО и оглавления.Редактировано 2 раз. Последний раз 07.02.2013 11:04 пользователем S-presso.
Вложения: Библиотека всемирной литературы. Part1.ptm (179 bytes)
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: А. Роман (IP-адрес скрыт)
Дата: 02, November, 2012 11:00
Коллеги, ваш опыт будет ооочень полезен в свете последних событий с оценкой эффективности деятельности организаций сферы науки и образования (высшего) и ажиотажа вокруг РИНЦ.
И вот в каком плане. Отличие библиографии публикаций в картотеках трудов сотрудников от записей в elibrary.ru заключается в отсутствии полных перечней использованных источников (по крайней мере по моему опыту общения с коллегами - большинство библиотек эти сведения не вводят). Добавлять сведения о публикациях, отсутствующих в РИНЦ (как бы не хотелось этим не заниматься) видимо придется все тем же библиотекарям.
Делать это в РИНЦ вручную - Боже упаси! Аналогичным образом вводить в свои записи - тоже та еще каторга.
На горизонте возникает необходимость (сканирования или заимствования сведений если они к примеру есть в МАРСианских записях) добавления этих сведений в ЭК с тем, чтобы в дальнейшем импортировать эти записи в РИНЦ (одно из основных требований к описаниям публикаций - для анализа цитирования). Правда, если не ошибаюсь, при этом нужно будет договориться о возможности импорта записей в РИНЦ в приемлемом формате (MARC или XML) и еще доработать структуру записей в ИРБИС, т.е. видимо 320 поле - ввести в его структуру соответствующие подполя. Это уже вопрос к разработчикам, который обязательно надо обсудить на ближайшем ЛИБКОМе.
И вот в каком плане. Отличие библиографии публикаций в картотеках трудов сотрудников от записей в elibrary.ru заключается в отсутствии полных перечней использованных источников (по крайней мере по моему опыту общения с коллегами - большинство библиотек эти сведения не вводят). Добавлять сведения о публикациях, отсутствующих в РИНЦ (как бы не хотелось этим не заниматься) видимо придется все тем же библиотекарям.
Делать это в РИНЦ вручную - Боже упаси! Аналогичным образом вводить в свои записи - тоже та еще каторга.
На горизонте возникает необходимость (сканирования или заимствования сведений если они к примеру есть в МАРСианских записях) добавления этих сведений в ЭК с тем, чтобы в дальнейшем импортировать эти записи в РИНЦ (одно из основных требований к описаниям публикаций - для анализа цитирования). Правда, если не ошибаюсь, при этом нужно будет договориться о возможности импорта записей в РИНЦ в приемлемом формате (MARC или XML) и еще доработать структуру записей в ИРБИС, т.е. видимо 320 поле - ввести в его структуру соответствующие подполя. Это уже вопрос к разработчикам, который обязательно надо обсудить на ближайшем ЛИБКОМе.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: S-presso (IP-адрес скрыт)
Дата: 02, November, 2012 11:21
Цитата:4. В программном модуле при работе мышкой предполагается открывать контекстное меню и из него выбирать какой элемент БО копируется? Если так, то перечень позиций меню будет тоже не маленьким.
5. Какое количество кликов мышкой в среднем придется делать библиотекарю и какова будет средняя продолжительность ввода БО???
Предлагаю просто посмотреть ролик. Правда, в нём показана работа уже неактуальной версии программы (с тех пор в дополнение к окну "Полное описание" появились новые вкладки "Картинка" и "КК", причём действие программы при выборе в тулбаре иконки сканера напрямую зависит от того, в какой именно вкладке мы находимся. Если в двух последних, то не будет автоматом запускаться распознавание и проверка орфографии. Вместо этого можно будет, например, установить расположение линий на карточке. Также теперь можно загружать сканы БО из файла).
[www.youtube.com]
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: woodyfon (IP-адрес скрыт)
Дата: 02, November, 2012 15:03
Цитата:Предполагается нажатие на кнопку из панели инструментов. Панель инструментов формируется в зависимости от того, какое БО необходимо: краткое - полное.4. В программном модуле при работе мышкой предполагается открывать контекстное меню и из него выбирать какой элемент БО копируется? Если так, то перечень позиций меню будет тоже не маленьким.
Цитата:В идеале 10-15 кликов. Продолжительность зависит от точности выделения области.5. Какое количество кликов мышкой в среднем придется делать библиотекарю и какова будет средняя продолжительность ввода БО???
Выбрали нужную область БО. Нажали на левую кнопку мышки, начали обводить прямоугольником область БО. В момент отпускания мышки - текстовые данные занесены в промежуточную ячейку и так далее. Согласен, что технология не использует возможность заимствования. Но ее вполне можно применить для ввода того же оглавления или аннотации. Подобным способом работает ABBYY Screen Reader.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: S-presso (IP-адрес скрыт)
Дата: 02, November, 2012 22:09
Цитата:А. Роман
Перечисленные вами программные и аппаратные средства, тоже стоят определенных денег. Утверждение о дороговизне Microsoft Office вызывает БООЛЬШИЕ сомнения, т.к. для академических организаций (см. условия Academic Open License) библиотек, гос учреждений или образовательных учреждений действуют значительные скидки 1500-1700 рублей за 1 лицензию. Потом, зачем нужен пакет Professional??? Вы собираетесь во всех библиотеках использовать ACCESS??? Standard - за глаза.
Да, согласен: в том, что я сравнивал затраты на предлагаемые средства со стоимостью Office Professional, есть определённая натяжка. Дело в том, что у меня на рабочем месте стоит вообще Office Enterprise. И что характерно, не было больше ничего, и поставить самому нужное мне ПО было нельзя. По соображениям лицензионной чистоты мне отказали и в просьбе установить Virtual PC, чтобы я имел полный доступ хотя бы к виртуалке - а ведь у меня персональная академическая лицензия почти на все продукты Microsoft (ну, за исключением пресловутого Office'а). FineReader в сентябре, правда, поставили - и на том спасибо. Со своим собственным ПО работаю только с личного ноутбука, поскольку в данном учебном заведении я вообще на птичьих правах. По статусу нашей библиотеке в принципе не положена какая-либо должность, связанная с автоматизацией, поэтому я уже 5 лет нахожусь в положении простого оператора ЭВМ. Зато негласно мы одна из самых технически продвинутых библиотек
. Хорошо, что хоть начальство библиотеки осознаёт необходимость прогресса. Ещё с первых дней своей работы я увидел там сканеры и FineReader, иначе бы просто не стал связываться. Хотя нет: я бы сам принёс и то, и другое. Ну, а неизбежным этапом технической эволюции стала разработка БАРСиКа. Теперь я мечтаю внедрить подобные технологии повсеместно.
Возвращаясь к цене вопроса. Признаю, что мог ошибиться в своей оценке стоимости офисного пакета для библиотек. Но давайте посмотрим. 1500-1700 рублей - это стоимость лицензии на одно рабочее место? Для того же компьютера ABBYY FineReader 11 Professional Edition в версии для скачивания обойдётся в сумму чуть больше 4 т.р. - и это не считая академической скидки в 40 %, которую ABBYY предоставляет всем образовательным учреждениям. Если же обработка литературы осуществляется одновременно на нескольких компьютерах, целесообразно приобрести Corporate Edition - не думаю, что это окажется дороже, чем офисные пакеты на каждом рабочем месте. Правда, потребуются ещё сканеры. Но почему бы не потратиться на парочку? Ещё сейчас у многих есть собственные цифровые камеры, которые вполне могут заменить обычный сканер. Да что там - в FineReader'е уже с 10-й версии можно сносно распознавать текст, снятый хоть мобильным телефоном. Правда, у меня нет возможности проверить эту функцию по причине отсутствия актуальной модели телефона, оснащенного камерой. Зато имеется два сканера и ещё один дома плюс собственная камера, которая всегда под рукой.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: S-presso (IP-адрес скрыт)
Дата: 03, November, 2012 09:28
woodyfon написал(а):
-------------------------------------------------------
> от точности выделения области.
> Выбрали нужную область БО. Нажали на левую кнопку
> мышки, начали обводить прямоугольником область БО.
> В момент отпускания мышки - текстовые данные
> занесены в промежуточную ячейку и так далее.
> Согласен, что технология не использует возможность
> заимствования. Но ее вполне можно применить для
> ввода того же оглавления или аннотации. Подобным
> способом работает ABBYY Screen Reader.
У меня модуль росписи оглавления изначально задумывался в расчёте на то, чтобы не возникало необходимости выделять отдельные элементы ни мышкой, ни клавиатурой. Для тех, кому трудно вручную настраивать программу на конкретную разметку оглавления, предусматривался режим, позволяющий самостоятельно отметить по каждому элементу в нескольких произвольно выбранных группах, а программа автоматически сгенерирует для них пограничные маркеры и сама определит все остальные элементы. Но то в теории. На практике все наработки, которые сейчас у меня имеются в этом направлении, - это небольшой набросок соответствующего экспериментального модуля, который я начинал писать года 3 назад, и некоторые сопутствующие примочки, попавшие в интерфейс, с возможностью выделения элементов пользователем вручную либо самой программой после указания всех границ. Но ту старую программу я уже давно забросил, а из нового модуля все эти рудименты были исключены. Всё равно программой кроме меня никто не пользуется. Если здесь кто-нибудь проявит интерес к данной разработке, можно будет попробовать вернуться и к этой идее. Может, кто-нибудь смог бы даже подвести теоретическую базу к процессу анализа оглавления. Сам-то я не математик.
Теперь насчет выделения отдельных элементов БО прямо в тексте с указанием нужных полей записи. Такая идея тоже была ещё на заре моей работы оператором. Соответствующий модуль, в общем, сделать несложно. Я бы даже мог, наверное, выложить здесь пробный проект с тем, чтобы он дорабатывался затем всем сообществом. С одним условием: изначальный код будет написан на языке C# и не использовать различных "фишек" БАРСиКа типа OCR, проверки орфографии, продвинутых таблиц. Соответствующие функции можно будет заимствовать только из open-source библиотек. Использовать C-Pen SDK можно вполне легально, но, насколько мне известно, он работает только под .NET, а тут может быть напряжёнка с другими свободными компонентами. Правда, бесплатная библиотека для взаимодействия со сканером имеется, а вот насчёт всего остального я не уверен. Для OCR я пытался использовать бесплатный Tesseract, но оказался неудовлетворён результатом.
Если же в самом издании уже содержится сводное библиографическое описание, то самостоятельно отмечать в нём отдельные элементы imho не имеет смысла. Вся структура описания уже сама по себе неплохо поддаётся анализу с целью выделения отдельных полей. Соответствующая подпрограмма заняла у меня буквально несколько дней не слишком напряжённой работы. Конечно, она не учитывает всех возможных случаев, но вполне справляется со своей задачей. Всё, что может потребоваться делать вручную, - это удаление авторского знака и вставка тире или точек между элементами в отдельных случаях. Аннотация определяется без проблем, все переносы строк заменяются на пробелы. А если что-то определилось и не так, как должно, то откорректировать запись впоследствии всё равно намного проще, чем создавать её вручную. Хотя, возможно, у вас существуют какие-то особые строгие требования к работе каталогизаторов с необходимостью досконального знания библиотечного формата. Но и в этом случае им, наверное, было бы легче начинать работать с записью не с чистого листа (в данном случае - рабочего), а уже имея какую-то заготовку. Всё, что мог предложить Каталогизатор в этом плане до настоящего времени - это копирование буферной записи. Сам активно этим пользуюсь, хотя данная технология есть источник потенциальных ошибок (иногда забываю удалить и заново сформировать сведения об ответственности). Замечание: это я про использование буферной записи, а не про распознавание БО. Хотя и с новой технологией тоже есть проблемы: можно занести в базу новую запись, не зная, что данное издание уже было внесено ранее. Сверка на дублетность в данном случае не работает - возможно, разработчикам стоит её усовершенствовать?
-------------------------------------------------------
Цитата:> В идеале 10-15 кликов. Продолжительность зависит> 5. Какое количество кликов мышкой в среднем
> придется делать библиотекарю и какова будет
> средняя продолжительность ввода БО???
> от точности выделения области.
> Выбрали нужную область БО. Нажали на левую кнопку
> мышки, начали обводить прямоугольником область БО.
> В момент отпускания мышки - текстовые данные
> занесены в промежуточную ячейку и так далее.
> Согласен, что технология не использует возможность
> заимствования. Но ее вполне можно применить для
> ввода того же оглавления или аннотации. Подобным
> способом работает ABBYY Screen Reader.
У меня модуль росписи оглавления изначально задумывался в расчёте на то, чтобы не возникало необходимости выделять отдельные элементы ни мышкой, ни клавиатурой. Для тех, кому трудно вручную настраивать программу на конкретную разметку оглавления, предусматривался режим, позволяющий самостоятельно отметить по каждому элементу в нескольких произвольно выбранных группах, а программа автоматически сгенерирует для них пограничные маркеры и сама определит все остальные элементы. Но то в теории
. На практике все наработки, которые сейчас у меня имеются в этом направлении, - это небольшой набросок соответствующего экспериментального модуля, который я начинал писать года 3 назад, и некоторые сопутствующие примочки, попавшие в интерфейс, с возможностью выделения элементов пользователем вручную либо самой программой после указания всех границ. Но ту старую программу я уже давно забросил, а из нового модуля все эти рудименты были исключены. Всё равно программой кроме меня никто не пользуется. Если здесь кто-нибудь проявит интерес к данной разработке, можно будет попробовать вернуться и к этой идее. Может, кто-нибудь смог бы даже подвести теоретическую базу к процессу анализа оглавления. Сам-то я не математик.
Теперь насчет выделения отдельных элементов БО прямо в тексте с указанием нужных полей записи. Такая идея тоже была ещё на заре моей работы оператором. Соответствующий модуль, в общем, сделать несложно. Я бы даже мог, наверное, выложить здесь пробный проект с тем, чтобы он дорабатывался затем всем сообществом. С одним условием: изначальный код будет написан на языке C# и не использовать различных "фишек" БАРСиКа типа OCR, проверки орфографии, продвинутых таблиц. Соответствующие функции можно будет заимствовать только из open-source библиотек. Использовать C-Pen SDK можно вполне легально, но, насколько мне известно, он работает только под .NET, а тут может быть напряжёнка с другими свободными компонентами. Правда, бесплатная библиотека для взаимодействия со сканером имеется, а вот насчёт всего остального я не уверен. Для OCR я пытался использовать бесплатный Tesseract, но оказался неудовлетворён результатом.
Если же в самом издании уже содержится сводное библиографическое описание, то самостоятельно отмечать в нём отдельные элементы imho не имеет смысла. Вся структура описания уже сама по себе неплохо поддаётся анализу с целью выделения отдельных полей. Соответствующая подпрограмма заняла у меня буквально несколько дней не слишком напряжённой работы. Конечно, она не учитывает всех возможных случаев, но вполне справляется со своей задачей. Всё, что может потребоваться делать вручную, - это удаление авторского знака и вставка тире или точек между элементами в отдельных случаях. Аннотация определяется без проблем, все переносы строк заменяются на пробелы. А если что-то определилось и не так, как должно, то откорректировать запись впоследствии всё равно намного проще, чем создавать её вручную. Хотя, возможно, у вас существуют какие-то особые строгие требования к работе каталогизаторов с необходимостью досконального знания библиотечного формата. Но и в этом случае им, наверное, было бы легче начинать работать с записью не с чистого листа (в данном случае - рабочего), а уже имея какую-то заготовку. Всё, что мог предложить Каталогизатор в этом плане до настоящего времени - это копирование буферной записи. Сам активно этим пользуюсь, хотя данная технология есть источник потенциальных ошибок (иногда забываю удалить и заново сформировать сведения об ответственности). Замечание: это я про использование буферной записи, а не про распознавание БО. Хотя и с новой технологией тоже есть проблемы: можно занести в базу новую запись, не зная, что данное издание уже было внесено ранее. Сверка на дублетность в данном случае не работает - возможно, разработчикам стоит её усовершенствовать?
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: Lavrinovich (IP-адрес скрыт)
Дата: 04, November, 2012 00:14
Сразу несколько серьезных интересных вопросов.
На форуме МАРК-SQL говорят, что в нем есть свой редактор. Никогда не задумывался, но фактически он есть в любой АБИС, иначе ввод и редактирование были бы невозможны, только такое слово не употребляется. Вероятно, в ИРБИСе он из Delphi...
Отдаленные прообразы библиопроцессора - системы версnки LaTex с ее вставкой библиографических списков в тексты и, кажется, Openffice.org.
irbis_arbat@mail.ru
Редактировано 5 раз. Последний раз 09.11.2012 07:56 пользователем Lavrinovich.
На форуме МАРК-SQL говорят, что в нем есть свой редактор. Никогда не задумывался, но фактически он есть в любой АБИС, иначе ввод и редактирование были бы невозможны, только такое слово не употребляется. Вероятно, в ИРБИСе он из Delphi...
Отдаленные прообразы библиопроцессора - системы версnки LaTex с ее вставкой библиографических списков в тексты и, кажется, Openffice.org.
irbis_arbat@mail.ru
Редактировано 5 раз. Последний раз 09.11.2012 07:56 пользователем Lavrinovich.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: Lavrinovich (IP-адрес скрыт)
Дата: 09, November, 2012 07:56
В идеале библиоредактор должен сам:
- проставлять УРЗ, но это делают все АБИС
- сокращать слова или проверять правильность сокращений по ГОСТ на нескольких языках
- проверять орфографию одновременно на нескольких языках
- контролировать соответствие MARC-форматам (?)
Идея может заинтересовать тех, для кого главное - подготовка указателей и т.п. типа ИРЛИ, ИНИОН или Теплоцентра ИВТ РАН.
См. [irbis.gpntb.ru]
Опять наука и наука...
Или имеется в виду OCR вместо АБИС!?
Но где ТЗ на разработку нового текстового процессора (если замысел именно в этом)?
irbis_arbat@mail.ru
Редактировано 4 раз. Последний раз 11.11.2012 04:17 пользователем Lavrinovich.
- проставлять УРЗ, но это делают все АБИС
- сокращать слова или проверять правильность сокращений по ГОСТ на нескольких языках
- проверять орфографию одновременно на нескольких языках
- контролировать соответствие MARC-форматам (?)
Идея может заинтересовать тех, для кого главное - подготовка указателей и т.п. типа ИРЛИ, ИНИОН или Теплоцентра ИВТ РАН.
См. [irbis.gpntb.ru]
Опять наука и наука...
Или имеется в виду OCR вместо АБИС!?
Но где ТЗ на разработку нового текстового процессора (если замысел именно в этом)?
irbis_arbat@mail.ru
Редактировано 4 раз. Последний раз 11.11.2012 04:17 пользователем Lavrinovich.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: S-presso (IP-адрес скрыт)
Дата: 10, November, 2012 17:36
Цитата:Lavrinovich
Идея может заинтересовать тех, для кого главное - подготовка указателей и т.п. типа ИРЛИ, ИНИОН или Теплоцентра ИВТ РАН.
См. [irbis.gpntb.ru]
К сожалению, ссылка не открывается - пишет, что сообщение не найдено.
Цитата:Lavrinovich
Или имеется в виду OCR вместо АБИС!?
Но где ТЗ на разработку нового текстового процессора (если замысел именно в этом)?
Ну, я не столь категоричен. Вообще не понимаю, как OCR может быть ВМЕСТО чего бы то ни было (ну, разве что кроме тупого набора текста). В моём представлении OCR вполне мирно сосуществует как с текстовыми процессорами, так и с АБИС. У того же ABBYY был даже соответствующий продукт - ABBYY ScanTo Office. Так вот, мой БАРСиК - это своеобразная попытка сделать что-то типа ABBYY ScanTo Irbis
. Причем не просто с экспортом результатов работы в виде отдельных записей ИРБИС (это умел делать и выложенный мной здесь несколькими сообщениями ранее "предок" нынешней САБО (Системы автоматизации библиографической обработки) под названием ПАРТИЗАН (Парсер-анализатор регулярной текстовой информации с заложенной автоматикой набора) - но он позволял вводить только оглавление, и не более чем из 200 пунктов (хотя, кажется, только сейчас мне попалась серия таких оглавлений - из сборников "Библиотеки всемирной литературы" - но с ними не то, что ПАРТИЗАН не справляется, БАРСиК и тот сохраняет записи лишь по частям в два захода, и лишь приложение под кодовым именем CIRBISC_NEW_UNICODE хоть и подвисает на время, но всё же героически выполняет экспорт-импорт и сохранение)), а с готовой оболочкой для просмотра всего ЭК и создания/модификации отдельных записей - но только средствами самой программы, без дубликации соответствующих функций Каталогизатора. Так что при желании можно, наверное, подключать и другие АБИС (Руслан, МАРК-SQL), если для них есть соответствующие программные интерфейсы к функциям для работы с БД и отдельными записями. Ау, есть тут представители ABBYY или их знакомые? Сделайте мне деловое предложение, и я готов поделиться всеми наработками!
В общем, я вижу два возможных вида конечного приложения, готового к распространению.
1. Можно сделать его IRBIS-specific, позволяющим выбирать из нескольких движков OCR в зависимости от предпочтений и финансовых возможностей конечного пользователя. Я так понимаю, лицензия на FineReader Engine стоит дорого, сама ГПНТБ использует её только для своего внутреннего приложения для ретроконверсии. Бесплатная пробная лицензия на движок ABBYY предоставляется различным организациям по запросу только ОДИН раз, и это лицензия на РАЗРАБОТКУ, которую можно установить лишь на ОДИН компьютер и срок использования истекает через ДВА МЕСЯЦА. Времени должно вполне хватить, чтобы набросать свой интерфейс со сканером и OCR, но явно не достаточно для полноценного использования конечного ПО хотя бы в рамках данной организации. Я успел реализовать многостраничное сканирование с распознаванием - в основном для чистого текста, но с некоторыми зачаточными функциями работы с областями (можно было сделать и больше - я лишь немного побаловался с FineReader Engine). Видимо, конечному пользователю САБО, желающему видеть эти функции в программе, придется самому раскошелиться на лицензию ABBYY - уже для ПОЛЬЗОВАТЕЛЕЙ (которая, насколько мне известно, тоже истекает через какой-то срок). Подозреваю, что проще будет просто купить FineReader Professional и использовать Copy / Paste. Ну, или надо как-то договариваться с ABBYY. Реальной альтернативы их движку, по крайней мере, в части распознавания русского языка, в настоящий момент нет. Правда, для распознавания библиографического описания я предпочитаю в своей программе использовать демо-версию компонента от Nicomsoft. Ее, в отличие от библиотеки компонентов ABBYY, можно продлевать неограниченно долго - но только, конечно, не при распространении в составе конечного продукта. Можно было бы купить неограниченную лицензию за $1400 (ее единственное ограничение установлено на количество разработчиков - 1, для команды до 4 разработчиков - уже $2400), и тогда у пользователя всегда будет хотя бы один предустановленный движок OCR. С распознаванием БО он справляется вполне достойно, чего, к сожалению, пока нельзя сказать об отсканированных оглавлениях. Кстати, для БО этот компонент оказался даже удобнее, чем FR Engine, требуя в целом меньше правок полученного текста "руками" (хотя, возможно, я просто не до конца разобрался в настройках FRE 9.0 для распознавания "чистого" текста без форматирования). Ну, а для обработки оглавлений можно лишь посоветовать пользователю переносить текст из FineReader. Либо, как я уже говорил, - см. выше. Потому как остальные известные мне компоненты (бесплатный Tesseract и основанный на нём коммерческий ABCocr) справляются с русским языком еще хуже. Правда, можно попробовать еще CuneiForm, но уж больно много возни с его подключением.
2. Можно было бы передать дальнейшую разработку САБО непосредственно ABBYY (а оно им надо ?!). Тогда они смогли бы реализовать все необходимые функции OCR на собственном движке, и свободно продавать продукт библиотекам. Этот вариант кажется мне (не знаю, что сказали бы сами представители ABBYY) даже более привлекательным. В конце концов, в силах этой компании сделать обработку оглавления еще более автоматизированной, не требующей вмешательства со стороны пользователя (ведь им, как я подозреваю, в большинстве случаев окажется человек, не обладающий такой же подготовкой, как я, создатель собственной разметки reg.exp. ПАРТИЗАН!). В общем, отсканированное оглавление будет так же непосредственно передаваться в ИРБИС или какую-то другую АБИС, как сейчас распознанный текст передается у них в Word и Acrobat. Про обработку БО и говорить нечего - если даже мне удалось более-менее решить эту проблему, пользуясь лишь своим опытом решения задач по информатике на строки. Думаю, специалисты ABBYY могли бы сделать всё так, чтобы мы вообще забыли про клавиатурный ввод в ЭК. На очереди - задача распознавания данных с каталожных карточек (не рукописных, но достаточно старых) с их последующим внесением в базу. Здесь надо научиться удалять лишние линии, как при работе с captcha (кстати, в одной из программ для автоматизации скачивания с рапиды и других файлообменников, использующих капчу, как раз применяется FR Engine - было бы интересно узнать, какая лицензия в данном случае была предоставлена разработчикам). Работа с линиями на исходной картинке могла бы пригодиться и для печати КК при использовании разлинованных карточек. Движок OCR автоматически определяет расположение линий и соответствующим образом подгоняет форматирование текста на карточке. Сейчас я провожу опыты с подобным экспериментальным модулем БАРСиКа. К сожалению, пока Nicomsoft OCR находит линии не там, где нужно
(он пока не умеет объединять смежные линии в одну). Но, как я понял уже, данный функционал мало кому нужен (делаю для себя).
Что еще должна включать в себя САБО (Напомню: Система автоматизации библиографической обработки)? Может быть, оптимизированный модуль для библиотек, предназначенный для сканирования книг с целью изготовления цифровых копий? С минимумом настроек, понятных любому библиотекарю. Возможностью включения / выключения OCR, переноса отсканированного оглавления и/или БО в ИРБИС64, а самой цифровой копии - в ИРБИС128. Если у вас есть другие предложения, поделитесь, пожалуйста.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: Lavrinovich (IP-адрес скрыт)
Дата: 11, November, 2012 04:16
S-presso написал(а):
-------------------------------------------------------
> К сожалению, ссылка не открывается - пишет, что
> сообщение не найдено
Новая метла по-новому метет... а все сказанное - это только желание помочь и прежде всего точнее сформулировать задачу.
Есть АБИС с "браузерными" клиентами (пример - ИРБИС 128), а вот гибрид АБИС с браузером? Первый вариант ИРБИС Навигатора... (по-прежнему ИМХО перспективная идея, надеюсь на ее реинкарнацию). Отдаленный аналог - прежний остроумный и удобный интерфейс MSIE, при открывании *.DOC и *.PDF превращавшийся в гибрид браузера с Word и Acrobat Reader.
irbis_arbat@mail.ru
Редактировано 4 раз. Последний раз 03.01.2013 14:07 пользователем Lavrinovich.
-------------------------------------------------------
> К сожалению, ссылка не открывается - пишет, что
> сообщение не найдено
Новая метла по-новому метет... а все сказанное - это только желание помочь и прежде всего точнее сформулировать задачу.
Есть АБИС с "браузерными" клиентами (пример - ИРБИС 128), а вот гибрид АБИС с браузером? Первый вариант ИРБИС Навигатора... (по-прежнему ИМХО перспективная идея, надеюсь на ее реинкарнацию). Отдаленный аналог - прежний остроумный и удобный интерфейс MSIE, при открывании *.DOC и *.PDF превращавшийся в гибрид браузера с Word и Acrobat Reader.
irbis_arbat@mail.ru
Редактировано 4 раз. Последний раз 03.01.2013 14:07 пользователем Lavrinovich.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: Lavrinovich (IP-адрес скрыт)
Дата: 17, November, 2012 05:49
Новый проект такой же грандиозный, как БАРСиК, и больше похож на альтернативу АБИС, а не текстовому редактору.
Даже "тянет на диссер" (не шучу)... а в начале такой работы необходим обзор и анализ достижений предшественников. Первый (известный мне) библиоредактор - это "Лексикон", доработанный во ВГБИЛ (или БЕН РАН - уважаемые коллеги, помогите найти ссылки, были ведь где-то публикации!) в направлении многоязычия.
Last but not least. Как планируете решить эту проблему, многоязычия, точнее "многоалфавитности", и особенно для ИРБИС 32, где нет юникода?
Вот для сравнения об ISIS:
To: "Michael Trachtengerts" <trachtengerts@yahoo.com>
Date: Saturday, 17 November, 2012, 6:34
Имеются библиографические описания на разных языках, в том числе одновременно на нескольких, подготовленные "в Ворде". При их вводе по рекомендуемому Вами методу, т. е. путем копирования и вставки отдельных элементов библиографического описания ("элементов данных" по ГОСТ) в соответствующие поля/подполя через Ваш конвертор IsoWin сохранится ли "расширенный набор символов", или юникод, т. е. диакритика? татьи.
ОТВЕТ:
Не испытывал, но думаю, что любые однобайтовые символы сохранятся.
Чтобы было понятнее, о чем речь отрывок из его статьи:
Трахтенгерц М.С.
Технология подготовки информации для баз данных в обменном формате ISO2709
Введение
Как известно, одной из самых трудоемких работ, проводимых при полноценном функционировании библиографических и других информационно-поисковых систем (ИПС), является регулярное пополнение их информационных ресурсов новыми документами. В этой статье рассматриваются вопросы техники и организации подготовки входящего потока информации на примере информационно-поисковой системы CDS/ISIS for Windows (далее ISIS), используемой в Теплофизическом центре Института высоких температур РАН [...].
В ISIS [...] это можно сделать двумя способами:
- последовательно вводить поля документа с помощью системного интерфейса и сохранить законченный документ;
- импортировать массив документов, имеющих формат стандарта ISO 2709 для обмена данных.
Второй способ значительно эффективней, но для этого нужно, чтобы массив документов был бы ранее кем-то подготовлен, например, использовался на другой ИПС и преобразован в нужный формат.
Следует учитывать еще одно немаловажное обстоятельство, связанное с глобальным расширением пользователей Интернет. С его помощью стали доступны, причем в электронном виде, многие документы (статьи, книги, материалы из периодических изданий и т.д.), которые должны отражаться в соответствующих базах данных. Это позволяет обойти ручной набор текстов в полях системного интерфейса и значительно уменьшить трудозатраты на ввод данных.
Интерфейс системы ISIS можно использовать и в этом случае, копируя строки из электронного документа сначала в буфер (clipboard) и затем из буфера в нужное поле интерфейса.
Если это действительно удобно и эффективно, то лишь в очень специфических условиях обработки большого объема, "потока", однотипных документов примерно одной структуры и тематики, чего в библиотеках почти не бывает.
Возможный вариант, программа-минимум: "хорошо настроенный" Word или Writer с Автозаменой, точнее со множеством автосокращений по библиоГОСТу. Но снова будет много проблем. Например, нельзя сокращать слова в заглавиях и т.д.
Из переписки:
From: Alexei Lavrinovich <irbis_arbat@mail.ru>
Subject: О Ворде и конверторе исоВин
To: "Michael Trachtengerts" <trachtengerts@yahoo.com>
Date: Saturday, 17 November, 2012, 6:34
Имеются библиографические описания на разных языках, в том числе одновременно на нескольких], подготовленные "в Ворде".
При их вводе путем по рекомендуемому Вами методу, т. е. путем копирования и вставки отдельных элементов биоблиографического описания (точнее говоря, "элементов данных", как предписано говорить ГОСТом) в соответствующие поля/подполя через Ваш конвеhтор IsoWin сохранится ли "расширенный набор символов", или юникод, т. е. диакритика?
Сбт 17 Ноя 2012 02:25:51 от Michael Trachtengerts <trachtengerts@yahoo.com>:
Не иcпытывал, но думаю, что любые однобайтовые символы сохранятся.
From: Alexei Lavrinovich <irbis_arbat@mail.ru>
Subject: Вот что вспомнил в связи с IsoWin
To: "Michael Trachtengerts" <trachtengerts@yahoo.com>
Date: Thursday, 22 November, 2012, 5:15
Даже если ограничиться только научными журналами на английском языке, то там русские фамилии траслитерируются по системе на основе чешского алфавита, с "гачеками" над C, S, Z и другой. Как же быть?
Чтв 22 Ноя 2012 02:49:47 от Michael Trachtengerts <trachtengerts@yahoo.com>:
Опускать их
МОЙ ОТВЕТ:
Это метод Библиотеки Конгресса США, не лучший, но часто неизбежный, романизация.
irbis_arbat@mail.ru
Редактировано 6 раз. Последний раз 23.11.2012 05:29 пользователем Lavrinovich.
Даже "тянет на диссер" (не шучу)... а в начале такой работы необходим обзор и анализ достижений предшественников. Первый (известный мне) библиоредактор - это "Лексикон", доработанный во ВГБИЛ (или БЕН РАН - уважаемые коллеги, помогите найти ссылки, были ведь где-то публикации!) в направлении многоязычия.
Last but not least. Как планируете решить эту проблему, многоязычия, точнее "многоалфавитности", и особенно для ИРБИС 32, где нет юникода?
Вот для сравнения об ISIS:
To: "Michael Trachtengerts" <trachtengerts@yahoo.com>
Date: Saturday, 17 November, 2012, 6:34
Имеются библиографические описания на разных языках, в том числе одновременно на нескольких, подготовленные "в Ворде". При их вводе по рекомендуемому Вами методу, т. е. путем копирования и вставки отдельных элементов библиографического описания ("элементов данных" по ГОСТ) в соответствующие поля/подполя через Ваш конвертор IsoWin сохранится ли "расширенный набор символов", или юникод, т. е. диакритика? татьи.
ОТВЕТ:
Не испытывал, но думаю, что любые однобайтовые символы сохранятся.
Чтобы было понятнее, о чем речь отрывок из его статьи:
Трахтенгерц М.С.
Технология подготовки информации для баз данных в обменном формате ISO2709
Введение
Как известно, одной из самых трудоемких работ, проводимых при полноценном функционировании библиографических и других информационно-поисковых систем (ИПС), является регулярное пополнение их информационных ресурсов новыми документами. В этой статье рассматриваются вопросы техники и организации подготовки входящего потока информации на примере информационно-поисковой системы CDS/ISIS for Windows (далее ISIS), используемой в Теплофизическом центре Института высоких температур РАН [...].
В ISIS [...] это можно сделать двумя способами:
- последовательно вводить поля документа с помощью системного интерфейса и сохранить законченный документ;
- импортировать массив документов, имеющих формат стандарта ISO 2709 для обмена данных.
Второй способ значительно эффективней, но для этого нужно, чтобы массив документов был бы ранее кем-то подготовлен, например, использовался на другой ИПС и преобразован в нужный формат.
Следует учитывать еще одно немаловажное обстоятельство, связанное с глобальным расширением пользователей Интернет. С его помощью стали доступны, причем в электронном виде, многие документы (статьи, книги, материалы из периодических изданий и т.д.), которые должны отражаться в соответствующих базах данных. Это позволяет обойти ручной набор текстов в полях системного интерфейса и значительно уменьшить трудозатраты на ввод данных.
Интерфейс системы ISIS можно использовать и в этом случае, копируя строки из электронного документа сначала в буфер (clipboard) и затем из буфера в нужное поле интерфейса.
Если это действительно удобно и эффективно, то лишь в очень специфических условиях обработки большого объема, "потока", однотипных документов примерно одной структуры и тематики, чего в библиотеках почти не бывает.
Возможный вариант, программа-минимум: "хорошо настроенный" Word или Writer с Автозаменой, точнее со множеством автосокращений по библиоГОСТу. Но снова будет много проблем. Например, нельзя сокращать слова в заглавиях и т.д.
Из переписки:
From: Alexei Lavrinovich <irbis_arbat@mail.ru>
Subject: О Ворде и конверторе исоВин
To: "Michael Trachtengerts" <trachtengerts@yahoo.com>
Date: Saturday, 17 November, 2012, 6:34
Имеются библиографические описания на разных языках, в том числе одновременно на нескольких], подготовленные "в Ворде".
При их вводе путем по рекомендуемому Вами методу, т. е. путем копирования и вставки отдельных элементов биоблиографического описания (точнее говоря, "элементов данных", как предписано говорить ГОСТом) в соответствующие поля/подполя через Ваш конвеhтор IsoWin сохранится ли "расширенный набор символов", или юникод, т. е. диакритика?
Сбт 17 Ноя 2012 02:25:51 от Michael Trachtengerts <trachtengerts@yahoo.com>:
Не иcпытывал, но думаю, что любые однобайтовые символы сохранятся.
From: Alexei Lavrinovich <irbis_arbat@mail.ru>
Subject: Вот что вспомнил в связи с IsoWin
To: "Michael Trachtengerts" <trachtengerts@yahoo.com>
Date: Thursday, 22 November, 2012, 5:15
Даже если ограничиться только научными журналами на английском языке, то там русские фамилии траслитерируются по системе на основе чешского алфавита, с "гачеками" над C, S, Z и другой. Как же быть?
Чтв 22 Ноя 2012 02:49:47 от Michael Trachtengerts <trachtengerts@yahoo.com>:
Опускать их
МОЙ ОТВЕТ:
Это метод Библиотеки Конгресса США, не лучший, но часто неизбежный, романизация.
irbis_arbat@mail.ru
Редактировано 6 раз. Последний раз 23.11.2012 05:29 пользователем Lavrinovich.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: Lavrinovich (IP-адрес скрыт)
Дата: 29, November, 2012 05:24
irbis_arbat@mail.ru
Редактировано 1 раз. Последний раз 29.11.2012 05:29 пользователем Lavrinovich.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: Lavrinovich (IP-адрес скрыт)
Дата: 29, November, 2012 05:28
S-presso написал(а):
-------------------------------------------------------
[...]
> задача: извлечение текстовых данных со страниц
> напечатанных изданий. Что нам для этого
> потребуется?
>
> 1. Сканер и (опционально) C-Pen
> 2. ABBYY FineReader
> 3. Специализированные средства для интеграции с
> ИРБИС.
> В моей программе сразу в нескольких местах
> применяются встроенные текстовые редакторы. Если
> пользоваться всеми возможностями этого компонента,
> можно даже создать что-то похожее на Word. Но
Нужны уточнения:
1. интеграция с ИРБИС или с любой АБИС?
2. не приведет ли реализация проекта к усугублению негативных традиций, когда, постоянно вводя данных в БД, библиографы не знают слов «база данных», думают, что только делают указатель или печатают карточки, или придерживаются жуткого обычая набирать текст указателя вручную в редакторе параллельно с ведением неизвестно для чего БД?
3. "встроенные текстовые редакторы" планируете распространять отдельно?
Короче говоря, какова конечная цель?
irbis_arbat@mail.ru
Редактировано 1 раз. Последний раз 29.11.2012 05:32 пользователем Lavrinovich.
-------------------------------------------------------
[...]
> задача: извлечение текстовых данных со страниц
> напечатанных изданий. Что нам для этого
> потребуется?
>
> 1. Сканер и (опционально) C-Pen
> 2. ABBYY FineReader
> 3. Специализированные средства для интеграции с
> ИРБИС.
> В моей программе сразу в нескольких местах
> применяются встроенные текстовые редакторы. Если
> пользоваться всеми возможностями этого компонента,
> можно даже создать что-то похожее на Word. Но
Нужны уточнения:
1. интеграция с ИРБИС или с любой АБИС?
2. не приведет ли реализация проекта к усугублению негативных традиций, когда, постоянно вводя данных в БД, библиографы не знают слов «база данных», думают, что только делают указатель или печатают карточки, или придерживаются жуткого обычая набирать текст указателя вручную в редакторе параллельно с ведением неизвестно для чего БД?
3. "встроенные текстовые редакторы" планируете распространять отдельно?
Короче говоря, какова конечная цель?
irbis_arbat@mail.ru
Редактировано 1 раз. Последний раз 29.11.2012 05:32 пользователем Lavrinovich.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: А. Роман (IP-адрес скрыт)
Дата: 29, November, 2012 07:44
Lavrinovich написал(а):
> 2. не приведет ли реализация проекта к усугублению
> негативных традиций, когда, постоянно вводя данных
> в БД, библиографы не знают слов «база данных»,
> думают, что только делают указатель или печатают
> карточки, или придерживаются жуткого обычая
> набирать текст указателя вручную в редакторе
> параллельно с ведением неизвестно для чего БД?
Пример из недавней практики: пользователь на вопрос, для каких задач покупали ИРБИС ответил - чтобы печатать каталожные карточки :)
> 2. не приведет ли реализация проекта к усугублению
> негативных традиций, когда, постоянно вводя данных
> в БД, библиографы не знают слов «база данных»,
> думают, что только делают указатель или печатают
> карточки, или придерживаются жуткого обычая
> набирать текст указателя вручную в редакторе
> параллельно с ведением неизвестно для чего БД?
Пример из недавней практики: пользователь на вопрос, для каких задач покупали ИРБИС ответил - чтобы печатать каталожные карточки :)
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: Lavrinovich (IP-адрес скрыт)
Дата: 29, November, 2012 14:49
Во время Великой Французской революции выкопали и повесили скелет Нострадамуса. Поступим так же с останками Дьюи, изобретателя не только ДКД, но и каталожных карточек.
К началу. А если мы хотим все бесплатно... Из доклада: Шрайберг Я.Л. Автоматизация библиотек сегодня...
...о CDS/ISIS спорят и пытаются оценивать те, кто этот пакет не знает и ничего в нем не понимает. О том, что CDS/ISIS умеет и чего не умеет, как правило, распространяются некомпетентные люди, желающие найти оправдание неразумно расходуемым средствам (или собирающиеся расходовать большие средства) на другие системы.
Утверждаю: сегодня CDS/ISIS является развитым инструментальным средством создания и поддержки библиотечно-информационных баз данных и технологий, которое при помощи разработки дополнительных модулей позволяет создавать современные интегрированные системы библиотечной автоматизации. Главная особенность CDS/ISIS — система (пакет) разрабатывалась ЮНЕСКО специально для библиотек, архивов, музеев и документально-информационных служб и таким образом, чтобы обеспечить легальную дистрибьюторскую поддержку во всем мире бесплатно
[...]
С использованием CDS/ISIS можно построить любые современные автоматизированные библиотечные и информационные системы, учитывая то, что, с одной стороны, внутренние механизмы системы специальным образом сконструированы для быстрого поиска и поддержки структур с переменными полями, а с другой — открытость и модульность программных средств позволяют принимать дополнительные модули на любых языках. Кроме того, ряд функций легко и эффективно реализуется с помощью встроенного ПАСКАЛЯ и языка форматирования.[...]
Возникает вопрос: а в чем же дело? Почему нельзя на базе CDS/ISIS и его приложений развивать сегодня библиотечную автоматизацию в стране?[...]
Может быть, стоит посмотреть на это под другим углом и предложить переходить на иные системы после того, как все библиотеки реализуют вышеприведенные функции. Но тогда, очевидно, уже ни на что не надо будет переходить, для многих библиотек все уже будет решено.
Что изменилось с тех пор - все разбогатели или?.. Желания творить самим не убавилось, начиная от ИРБИС-утилит до АРБУЗа и до совсем новых совсем отдельных АБИС...
irbis_arbat@mail.ru
Редактировано 2 раз. Последний раз 30.11.2012 10:27 пользователем Lavrinovich.
К началу. А если мы хотим все бесплатно... Из доклада: Шрайберг Я.Л. Автоматизация библиотек сегодня...
...о CDS/ISIS спорят и пытаются оценивать те, кто этот пакет не знает и ничего в нем не понимает. О том, что CDS/ISIS умеет и чего не умеет, как правило, распространяются некомпетентные люди, желающие найти оправдание неразумно расходуемым средствам (или собирающиеся расходовать большие средства) на другие системы.
Утверждаю: сегодня CDS/ISIS является развитым инструментальным средством создания и поддержки библиотечно-информационных баз данных и технологий, которое при помощи разработки дополнительных модулей позволяет создавать современные интегрированные системы библиотечной автоматизации. Главная особенность CDS/ISIS — система (пакет) разрабатывалась ЮНЕСКО специально для библиотек, архивов, музеев и документально-информационных служб и таким образом, чтобы обеспечить легальную дистрибьюторскую поддержку во всем мире бесплатно
[...]
С использованием CDS/ISIS можно построить любые современные автоматизированные библиотечные и информационные системы, учитывая то, что, с одной стороны, внутренние механизмы системы специальным образом сконструированы для быстрого поиска и поддержки структур с переменными полями, а с другой — открытость и модульность программных средств позволяют принимать дополнительные модули на любых языках. Кроме того, ряд функций легко и эффективно реализуется с помощью встроенного ПАСКАЛЯ и языка форматирования.[...]
Возникает вопрос: а в чем же дело? Почему нельзя на базе CDS/ISIS и его приложений развивать сегодня библиотечную автоматизацию в стране?[...]
Может быть, стоит посмотреть на это под другим углом и предложить переходить на иные системы после того, как все библиотеки реализуют вышеприведенные функции. Но тогда, очевидно, уже ни на что не надо будет переходить, для многих библиотек все уже будет решено.
Что изменилось с тех пор - все разбогатели или?.. Желания творить самим не убавилось, начиная от ИРБИС-утилит до АРБУЗа и до совсем новых совсем отдельных АБИС...
irbis_arbat@mail.ru
Редактировано 2 раз. Последний раз 30.11.2012 10:27 пользователем Lavrinovich.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: Lavrinovich (IP-адрес скрыт)
Дата: 30, November, 2012 10:21
Обзор успехов предшественников, как полагается в диссертации:).
1. Word по крайней мере с версии 6.0 - это на 70-90% не редактор, а полноценная издательская система (нельзя верстать только газеты из-за их сложных врезок), включающая редакторы формул, графический, табличный и не знаю что еще.
2. ИРБИС Навигатор (первый вариант [irbis.gpntb.ru]) = АБИС + браузер + средство разработки (верю в будущую реинкарнацию проекта).
3. ИРБИС64 ПБД Special Edition с фрагментом сайта ГПНТБ [irbis.gpntb.ru] = АБИС + браузер
4. Сhrome = браузер + медиаплейер + не знаю что еще (все основные браузеры давно не только "листалки", HTML-смотрелки, а целые "кухонные комбайны" с почтой и не знаю чем еще; поэтому снова появились легкие Arora, Midori).
5. Коммандеры ушли далеко вперед от предка Синего Квадрата, мне больше по вкусу freeCommander, многим Total, чего в них только нет, тоже не знаю всех функций.
Вывод: можно вообразить и редактор, интегрировавший в себя АБИС.
irbis_arbat@mail.ru
Редактировано 4 раз. Последний раз 03.12.2012 05:36 пользователем Lavrinovich.
1. Word по крайней мере с версии 6.0 - это на 70-90% не редактор, а полноценная издательская система (нельзя верстать только газеты из-за их сложных врезок), включающая редакторы формул, графический, табличный и не знаю что еще.
2. ИРБИС Навигатор (первый вариант [irbis.gpntb.ru]) = АБИС + браузер + средство разработки (верю в будущую реинкарнацию проекта).
3. ИРБИС64 ПБД Special Edition с фрагментом сайта ГПНТБ [irbis.gpntb.ru] = АБИС + браузер
4. Сhrome = браузер + медиаплейер + не знаю что еще (все основные браузеры давно не только "листалки", HTML-смотрелки, а целые "кухонные комбайны" с почтой и не знаю чем еще; поэтому снова появились легкие Arora, Midori).
5. Коммандеры ушли далеко вперед от предка Синего Квадрата, мне больше по вкусу freeCommander, многим Total, чего в них только нет, тоже не знаю всех функций.
Вывод: можно вообразить и редактор, интегрировавший в себя АБИС.
irbis_arbat@mail.ru
Редактировано 4 раз. Последний раз 03.12.2012 05:36 пользователем Lavrinovich.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: S-presso (IP-адрес скрыт)
Дата: 30, November, 2012 10:52
Цитата:А. Роман
Пример из недавней практики: пользователь на вопрос, для каких задач покупали ИРБИС ответил - чтобы печатать каталожные карточки :)
Забавно:) Если стоит задача только печатать карточки, то покупать ИРБИС и не нужно - вполне достаточно демоверсии. Можно вообще наделать своих шаблонов для разных видов карточек в Word'е (его ведь тоже, наверное, покупали?) и дальше штамповать их прямо в редакторе. Но это если не требуется создавать отдельные записи. Я вот, наоборот, стараюсь вносить в каталог всё, даже старые издания, если требуется только новая карточка на них. Мало ли, вдруг пригодится в будущем? К тому же, не приходится самому додумывать внешний вид карточки.
Кстати, демоверсия Ирбиса позволяет не только печатать карточки, но и выполнять вообще практически всю работу, в том числе и удалённо. Если предварительно отсканировать библиографические описания на титульных листах изданий и/или их оглавления (или попросить кого-нибудь это сделать), можно выполнять всю дальнейшую обработку у себя дома. При этом, пользуясь БАРСиКом, я вообще свожу всю механическую работу по набивке текста к минимуму. В дальнейшем остается только импортировать созданные записи в базу данных на работе. Вот вам потенциальная возможность для фриланса.
Цитата:Lavrinovich
Нужны уточнения:
1. интеграция с ИРБИС или с любой АБИС?
В идеале хорошо бы вообще с любой АБИС. Не составит труда написать прослойки для других систем, так же как я это сделал для ИРБИС. Я уже писал об этом чуть выше. Тут должен помочь абстрактный класс - назовём его, как у меня, DBAccess. Именно к его методам будут обращаться клиентские модули для работы непосредственно с базой (в моём случае их два - один отображает всю базу в целом и каждую запись в отдельности, позволяя вызывать для неё функции обработки бибописания или оглавления, принимать из других модулей все изменения записи, отображать их и позволять сохранять; второй модуль позволяет просматривать отдельные строки оглавления и добавлять их к записи). А сами методы могут быть реализованы в классах-наследниках DBAccess, таких как IRBIS_DBAccess, Ruslan_DBAccess и др. Но это в идеале. А на практике мне приходится пока каждый раз перекомпилировать своё приложение, если я захочу запустить его на новой машине. Предполагаю, что это связано именно с irbis_client64.dll - нужно каждый раз выстраивать связи. К сожалению, не могу сказать точно, в каком именно месте возникает ошибка - ведь стоит мне воспользоваться отладчиком, как программа тут же начинает работать нормально, поскольку она уже перестроена. Не знаю, удастся ли мне сделать приложение не привязанным к конкретной машине, на которой оно работает (как все прочие мои приложения). Вариант с поставкой в виде исходных кодов, как в случае с программами под Linux, тут явно не годится (и не только потому, что не хочется показывать исходники, - нельзя же заставлять конечных пользователей держать на компьютере установленную визуальную студию от Microsoft?).
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: Lavrinovich (IP-адрес скрыт)
Дата: 01, December, 2012 06:14
все темы S-presso генерируют длинные ответы.
Можно вообразить такое: бесплатная библиографически-ориентированная СУБД + мощный библиографически-ориентированный редактор (ISIS или PostgreSQL).
[www.sai.msu.su]
Но если верить Руководству по CDS/ISIS, "в системе имеются мощные средства для создания выходных форм, вы можете использовать эти средства для обработки данных и печати их в различных форматах." Интереснейшая, но не раскрытая тема...
Итак, редактор в дополнение к АБИС. Чего только не бывает. Например, ИРБИС сами его создатели сначала считали дополнением к ISIS. "Почему нельзя на базе CDS/ISIS и его приложений развивать сегодня библиотечную автоматизацию в стране? [...] Например, пакет ИРБИС и CDS/ISIS — основные технологии в ГПНТБ России..." (Шрайберг Я.Л. Автоматизация библиотек сегодня).
"Наделать своих шаблонов". Похожее делали в МВТУ им. Баумана [irbis.gpntb.ru]
Насчет "для любой АБИС"... есть Hyperhelp для МАРК-SQL (ср. идею [irbis.gpntb.ru]), который разработчик хотел адаптировать к другим системам...
Продолжим пиратскую тему. СПО может иметь экзотический интерфейс, например The GIMP. Некоторые дистрибутивы OOo включают графический редактор более традиционной "внешности" (пока нашел его только в составе версии для Linux).
Свободная издательская система, похоже, только одна и тоже непривычная - LaTeX, но ее Windows-версию не нашел, только о ней.
OCR, поставляемые со сканерами, как бы бесплатные, но если это не CuneiForm или FR, у них проблемы с кириллицей.
Похоже, только АБИС не имеют полноценной бесплатной альтернативы. Есть для DOS без поддержки новых ГОСТОв и MARC'ов, без конверторов, есть неинтегрированные и есть нерусифицированные. Интегрированная современная ABCD (как и другие ISIS-based) известны только в романоязычных странах. Ближе всего к идеалу, видимо, School Library System 2.0, подходит ли она не для школ?
[i]Из прессы 90-х. Наш человек в их вузе:
- Почему до сих пор используете старый WordPerfect и т.д.?
- Ректор последний раз выделил средства пять лет назад. Да и зачем менять?
Но у нас по-прежнему за это отвечает (причем по собственной инициативе) любознательный "студенд-преколизд", меняющийся каждые полгода... или "вечный студент" вроде меня...
Редактировано 11 раз. Последний раз 02.01.2013 18:26 пользователем Lavrinovich.
Можно вообразить такое: бесплатная библиографически-ориентированная СУБД + мощный библиографически-ориентированный редактор (ISIS или PostgreSQL).
[www.sai.msu.su]
Но если верить Руководству по CDS/ISIS, "в системе имеются мощные средства для создания выходных форм, вы можете использовать эти средства для обработки данных и печати их в различных форматах." Интереснейшая, но не раскрытая тема...
Итак, редактор в дополнение к АБИС. Чего только не бывает. Например, ИРБИС сами его создатели сначала считали дополнением к ISIS. "Почему нельзя на базе CDS/ISIS и его приложений развивать сегодня библиотечную автоматизацию в стране? [...] Например, пакет ИРБИС и CDS/ISIS — основные технологии в ГПНТБ России..." (Шрайберг Я.Л. Автоматизация библиотек сегодня).
"Наделать своих шаблонов". Похожее делали в МВТУ им. Баумана [irbis.gpntb.ru]
Насчет "для любой АБИС"... есть Hyperhelp для МАРК-SQL (ср. идею [irbis.gpntb.ru]), который разработчик хотел адаптировать к другим системам...
Продолжим пиратскую тему. СПО может иметь экзотический интерфейс, например The GIMP. Некоторые дистрибутивы OOo включают графический редактор более традиционной "внешности" (пока нашел его только в составе версии для Linux).
Свободная издательская система, похоже, только одна и тоже непривычная - LaTeX, но ее Windows-версию не нашел, только о ней.
OCR, поставляемые со сканерами, как бы бесплатные, но если это не CuneiForm или FR, у них проблемы с кириллицей.
Похоже, только АБИС не имеют полноценной бесплатной альтернативы. Есть для DOS без поддержки новых ГОСТОв и MARC'ов, без конверторов, есть неинтегрированные и есть нерусифицированные. Интегрированная современная ABCD (как и другие ISIS-based) известны только в романоязычных странах. Ближе всего к идеалу, видимо, School Library System 2.0, подходит ли она не для школ?
[i]Из прессы 90-х. Наш человек в их вузе:
- Почему до сих пор используете старый WordPerfect и т.д.?
- Ректор последний раз выделил средства пять лет назад. Да и зачем менять?
Но у нас по-прежнему за это отвечает (причем по собственной инициативе) любознательный "студенд-преколизд", меняющийся каждые полгода... или "вечный студент" вроде меня...
Редактировано 11 раз. Последний раз 02.01.2013 18:26 пользователем Lavrinovich.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: Lavrinovich (IP-адрес скрыт)
Дата: 03, December, 2012 05:27
Идеология или концепция Ворда абсолютно не "библиографическая", ее точнее всего называть "оформительской". структурная единица в нем - абзац с его стилями, отступами, интервалами, шрифтами. По идее больше подошел бы LaTeX, но он вообще не редактор.
Были надежды на XML, где структура как раз смысловая, но неизвестны основанные на этом языке редакторы (и АБИС), не слышно больше и про XML-ISIS (?)
Так нужен ли нам Word? Давно и хорошо известно: во всех "больших" редакторах 70-90% функций избыточны. Уже как минимум Word 6.0 был полноценной издательской системой (кроме верстки газет). Маленькими у нас никто не хочет пользоваться, хотя очень удобен Hieroglyph, совсем неплох WordPad, а когда-то Norton Just Write. Не тестировал лишь незалежноязычный Atlantis.
Непопулярны и малые "офисы", точнее "вёрксы" типа MS Works, хотя он имел свои достоинства. Скифам и казакам нужны широкий простор и большой вес:))) Можно теоретически довести Word до состояния АБИС, или, что более вероятно, включить некую несложную АБИС в MS Office, как были в нем Publisher, PhotoDraw, FrontPage (и напрасно пропали). Когда MS купила системы управления предприятием (ERP, ERM, HRM), видимо, придала им фирменный "мс-офисный" вид...
Когда же прекратится пресловутая "набивка вручную"? Возьмем крайний случай - нет интернета и нет участия в корпорациях. Но есть хотя бы парочка подаренных дисков, скажем, РСК НТЛ или "Книги в наличии и печати", почему на брать оттуда, почему, наконец, не копировать и редактировать собственные прежние похожие записи!?
irbis_arbat@mail.ru
Редактировано 7 раз. Последний раз 17.12.2012 12:27 пользователем Lavrinovich.
Были надежды на XML, где структура как раз смысловая, но неизвестны основанные на этом языке редакторы (и АБИС), не слышно больше и про XML-ISIS (?)
Так нужен ли нам Word? Давно и хорошо известно: во всех "больших" редакторах 70-90% функций избыточны. Уже как минимум Word 6.0 был полноценной издательской системой (кроме верстки газет). Маленькими у нас никто не хочет пользоваться, хотя очень удобен Hieroglyph, совсем неплох WordPad, а когда-то Norton Just Write. Не тестировал лишь незалежноязычный Atlantis.
Непопулярны и малые "офисы", точнее "вёрксы" типа MS Works, хотя он имел свои достоинства. Скифам и казакам нужны широкий простор и большой вес:))) Можно теоретически довести Word до состояния АБИС, или, что более вероятно, включить некую несложную АБИС в MS Office, как были в нем Publisher, PhotoDraw, FrontPage (и напрасно пропали). Когда MS купила системы управления предприятием (ERP, ERM, HRM), видимо, придала им фирменный "мс-офисный" вид...
Когда же прекратится пресловутая "набивка вручную"? Возьмем крайний случай - нет интернета и нет участия в корпорациях. Но есть хотя бы парочка подаренных дисков, скажем, РСК НТЛ или "Книги в наличии и печати", почему на брать оттуда, почему, наконец, не копировать и редактировать собственные прежние похожие записи!?
irbis_arbat@mail.ru
Редактировано 7 раз. Последний раз 17.12.2012 12:27 пользователем Lavrinovich.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: Lavrinovich (IP-адрес скрыт)
Дата: 17, December, 2012 12:29
Перечитал, так и не понял: вы пишете новый редактор или нет?
Гипотеза: он все-таки будет дальним родственником ИРБИСа, который ведь имеет дело не с таблицами, а фактически ("да простят меня разработчики", как говорит Гена) с текстовыми файлами, только обрабатывает их иначе, по-своему... не хочу сказать, что ИРБИС может быть средством разработки редактора... хотя...
И еще нужно тщательно изучить то, что уже есть в ИРБИСе, а именно Генератор выходных табличных форм (Общее описание, Приложение 9).
***
Редактор не должен проставлять УРЗ (если он не замена АБИС), но мог бы сам сокращать слова (кроме заглавий и других случаев) по ГОСТ? Или, лучше, проверять правильность таких сокращений, или исправлять неправильные, или подсказывать правильные.
***
Можно вообразить автоформирование каталожных карточек на основе распознанных бгр. списков и "прикнижных" (или отдельных) бгр. указателей. Но такой подход (в обход ЭК, в обход АБИС) неперспективен, неэффективен, нерационален, не отвечает важнейшему, основополагаеющему принципу однократного ввода и многократного многоаспектного вывода, использования данных. Надо обсудить с А.С.Караушем, М.С.Трахтенгерцем...
Вот более конкретная (хотя пока и абстрактная) идея: Редактор, Генератор или Мастер указателей [irbis.gpntb.ru]
irbis_arbat@mail.ru
Редактировано 8 раз. Последний раз 26.12.2012 06:26 пользователем Lavrinovich.
Гипотеза: он все-таки будет дальним родственником ИРБИСа, который ведь имеет дело не с таблицами, а фактически ("да простят меня разработчики", как говорит Гена) с текстовыми файлами, только обрабатывает их иначе, по-своему... не хочу сказать, что ИРБИС может быть средством разработки редактора... хотя...
И еще нужно тщательно изучить то, что уже есть в ИРБИСе, а именно Генератор выходных табличных форм (Общее описание, Приложение 9).
***
Редактор не должен проставлять УРЗ (если он не замена АБИС), но мог бы сам сокращать слова (кроме заглавий и других случаев) по ГОСТ? Или, лучше, проверять правильность таких сокращений, или исправлять неправильные, или подсказывать правильные.
***
Можно вообразить автоформирование каталожных карточек на основе распознанных бгр. списков и "прикнижных" (или отдельных) бгр. указателей. Но такой подход (в обход ЭК, в обход АБИС) неперспективен, неэффективен, нерационален, не отвечает важнейшему, основополагаеющему принципу однократного ввода и многократного многоаспектного вывода, использования данных. Надо обсудить с А.С.Караушем, М.С.Трахтенгерцем...
Вот более конкретная (хотя пока и абстрактная) идея: Редактор, Генератор или Мастер указателей [irbis.gpntb.ru]
irbis_arbat@mail.ru
Редактировано 8 раз. Последний раз 26.12.2012 06:26 пользователем Lavrinovich.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: S-presso (IP-адрес скрыт)
Дата: 29, December, 2012 11:34
Цитата:Lavrinovich
Когда же прекратится пресловутая "набивка вручную"? Возьмем крайний случай - нет интернета и нет участия в корпорациях.
Это именно наш случай, и именно к подобным условиям работы относятся приведённые здесь ранее критические замечания в мой адрес:
Цитата:А. Роман
Отметая в самом началне технологии заимствования записей и в целом корпоративность работы ИРБИС-корпорация, LIBNET, МАРС, АРБИКОН, многочисленные Z39.50 сервера и т.д. (в том смысле, что один в поле - не воин) СУЩЕСТВЕННО сокращаете эффективность работы. ДОКАЗАННЫЙ ФАКТ.
Работа современных средств заимствования в ИРБИС (как в 64-м и особенно в 128-м (инлайн-заимствование)) проста и до предела удобна.
...
Поэтому, на мой взгляд заменять полностью эти технологии там, где проще использовать труд коллег по цеху, сажая на необитаемом острове человека со сканером и книгами - напрасное занятие.
Господи, да разве я что-то пытаюсь отметать! Я обеими руками за новые технологии. Просто в данном случае полностью уместна аналогия с необитаемым островом - оказавшись сам в положении этакого Робинзона, в отрыве, так сказать, от цивилизации, я вынужден был самостоятельно создавать для себя её блага, развивать технический прогресс с нуля. А окажутся ли созданные в результате этого средства полезными для других пользователей, это уже другой вопрос.
А наше участие в корпорации, по крайней мере, в данный момент невозможно по вполне банальной причине - начальство отказалось выделять на это мероприятие деньги. Как, впрочем, и на Web-сервер с OPAC-IRBIS'ом. Так что это они сокращают эффективность нашей работы, не я. Зато у нас есть "БАРСиК"
. Точнее, обитал у меня на ноутбуке до вчерашнего дня, когда я по неосторожности удалил весь раздел ноутбучного жёсткого диска... Что ж, пусть это простимулирует меня в доработке модулей с тем, чтобы можно было запускать их непосредственно на рабочем компьютере, подключённом к электронному каталогу библиотеки. В текущем виде я не могу выложить эти наработки в публичный доступ по ряду причин. Но за новогодние праздники постараюсь упростить средства их поставки потенциальному пользователю и интеграции с Ирбисом (приходится учитывать ситуацию, когда на клиентскую машину на рабочем месте без ведома администратора вообще нельзя установить никакое ПО). Понимаю, что придётся проводить тотальный рефакторинг, но если получится, тогда я выложу здесь демо-версии всего, что у меня имеется на сегодняшний момент. Правда, для этого, по-видимому, придётся внедрять свой АРМ с системой плагинов.
Цитата:Lavrinovich
Перечитал, так и не понял: вы пишете новый редактор или нет?
Ну, если вы настаиваете, то, видимо, придётся писать... Тем более, что концепция сейчас более-менее прояснилась у меня в голове. Если всё получится, то новый АРМ должен будет содержать не только таблицы рабочих листов, но и этот самый редактор, причём редактирование записей можно будет проводить синхронно в обоих режимах - подобно тому, как в визуальной среде проектирования изменяешь какие-либо значения в текстовых полях (например, имя формы) и они параллельно изменяются и в конструкторе.
Цитата:не хочу сказать, что ИРБИС может быть средством разработки редактора... хотя...
Я как раз рассматриваю идею о том, что новый программный модуль для Ирбиса мог бы стать своеобразным средством разработки, визуальным конструктором собственных, проектируемых под конкретную задачу АРМов. Например, вам не нравится АРМ Читатель. Хорошо, напишите свой собственный в Дельфи-подобной среде на основе визуальных компонентов, набор которых включает в себя и специальные библиографические компоненты (таблицы и текстовые редакторы). Такова общая концепция на сегодняшний момент. Больше говорить об этом пока не хочется до представления рабочего прототипа.
Редактировано 1 раз. Последний раз 29.12.2012 19:16 пользователем S-presso.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: Lavrinovich (IP-адрес скрыт)
Дата: 30, December, 2012 11:35
1. Отметают корпорации по-прежнему многие, а почему непонятно.
2. Ни на чем не настаиваю, ваш план прояснился и очень интересен.
3. Предлагаю обсудить еще одну идею: библиографический иерархический HTML/XML-редактор или Генератор. Формирует многоуровневые указатели, например:
- список названий журналов по предметным рубрикам
- название конкретного журнала и другие сведения об издании в целом
- описание отдельного номера
- аналитика
Часть нужного в ИРБИСе уже есть. Другие возможные средства реализации - язык форматирования, HTML, HTML5, XML, PHP (есть в 128).
Или такой "запасной" вариант: какая-либо СУБД (например PostgreSQL), "ненастроенная", "как есть" + множество шаблонов, макросов и прочего для Word и/или надстроек Excel?
ЗЫ. Чтобы все было максимально объектно-визуальным - это моя старая навязчивая идея.
ЗЗЫ. Чтобы не путаться, нужно (хотя бы рабочее) название нового АРМа!
С Новым Годом!
irbis_arbat@mail.ru
Редактировано 5 раз. Последний раз 01.01.2013 04:11 пользователем Lavrinovich.
2. Ни на чем не настаиваю, ваш план прояснился и очень интересен.
3. Предлагаю обсудить еще одну идею: библиографический иерархический HTML/XML-редактор или Генератор. Формирует многоуровневые указатели, например:
- список названий журналов по предметным рубрикам
- название конкретного журнала и другие сведения об издании в целом
- описание отдельного номера
- аналитика
Часть нужного в ИРБИСе уже есть. Другие возможные средства реализации - язык форматирования, HTML, HTML5, XML, PHP (есть в 128).
Или такой "запасной" вариант: какая-либо СУБД (например PostgreSQL), "ненастроенная", "как есть" + множество шаблонов, макросов и прочего для Word и/или надстроек Excel?
ЗЫ. Чтобы все было максимально объектно-визуальным - это моя старая навязчивая идея.
ЗЗЫ. Чтобы не путаться, нужно (хотя бы рабочее) название нового АРМа!
С Новым Годом!
irbis_arbat@mail.ru
Редактировано 5 раз. Последний раз 01.01.2013 04:11 пользователем Lavrinovich.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: Lavrinovich (IP-адрес скрыт)
Дата: 01, January, 2013 09:22
1. «Google автоматически генерирует HTML-версии документов в то время, как мы исследуем интернет».
2. «Генерить — создавать что-либо (обычно программу или стандартные сообщения) с помощью полуавтоматических средств» (Воройский Ф.С. Словарь-справочник по информатике, раздел «Компьютерный сленг»).
Но способ, которым "генерились" HTML-списки новых поступлений в ГПНТБ в начале "нулевых", был скорее «чисто ручным», а как теперь?
Некий аналог возможный - ISIS2XML
(http://perso.wanadoo.fr/pierre.chabert)
Фантазия: «Web-ИРБИС 3000 ®© автоматически генерирует HTML-версии документов в то время, как Вы их ищете. ГПНТБ России®© и
Ассоциация ЭБНИТ®© не несут отвеnственности за содержание и оформление этого документа».
irbis_arbat@mail.ru
Редактировано 1 раз. Последний раз 05.01.2013 14:04 пользователем Lavrinovich.
2. «Генерить — создавать что-либо (обычно программу или стандартные сообщения) с помощью полуавтоматических средств» (Воройский Ф.С. Словарь-справочник по информатике, раздел «Компьютерный сленг»).
Но способ, которым "генерились" HTML-списки новых поступлений в ГПНТБ в начале "нулевых", был скорее «чисто ручным», а как теперь?
Некий аналог возможный - ISIS2XML
(http://perso.wanadoo.fr/pierre.chabert)
Фантазия: «Web-ИРБИС 3000 ®© автоматически генерирует HTML-версии документов в то время, как Вы их ищете. ГПНТБ России®© и
Ассоциация ЭБНИТ®© не несут отвеnственности за содержание и оформление этого документа».
irbis_arbat@mail.ru
Редактировано 1 раз. Последний раз 05.01.2013 14:04 пользователем Lavrinovich.
Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: S-presso (IP-адрес скрыт)
Дата: 01, January, 2013 12:27
Цитата:Кажется, название БАРС уже закреплено за каким-то библиотечным продуктом? А то бы подошло для конструктора: Библиографический Автоматизированный Редактор Сценариев. Ну, или, чтобы не путаться - "Визуальный БАРС" (за Visual Barsik Microsoft даст по шееЧтобы не путаться, нужно (хотя бы рабочее) название нового АРМа!
) - правда, в моей текущей классификации возможных продуктов уже присутствует БАРСиК - это набор подпрограмм для упрощения каталогизации, из которых в качестве плагина IRBIS у меня уже работает анализатор БО. Или, может быть, переименовать последний в Б.А.Р.Т. (Библиографический Анализ Распознанного Текста?) Тогда БАРСИКом можно было бы назвать АРМ для ввода данных в ЭК (собственно, он уже и существует в таком виде, но я хотел переписать его оболочку на C++ Builder (чтобы затем перестроить её средствами Визуального БАРСа) и сделать существующие средства автоматизации ввода в виде плагинов к ней.Re: Нужен ли нам Word? Текстовый процессор для библиотек. Интеграция с АБИС
Пользователь: Lavrinovich (IP-адрес скрыт)
Дата: 05, January, 2013 10:59
БАРТ это хорошо, что-то из научной фантастики?
БАРС - разработка МВТУ им. Баумана, чуть ли не первая в стране, давно забытая [irbis.gpntb.ru]
ориентированная исключительно на карточки. Похоже, это как раз и был редактор-генератор КК!. В результате им пришлось заниматься ретроконверсией и даже самим писать OCR...
А еще БАРСом хотели сначала назвать ИРБИС 64. В общем, сегодня имя свободно.
***
Можно вообразить и автоформирование каталожных карточек на основе распознанных библиографических списков и "прикнижных", пристатейных или отдельных указателей. Но такой подход (в обход ЭК, в обход АБИС) неперспективен, неэффективен, нерационален, не отвечает важнейшему принципу однократного ввода и многократного многоаспектного вывода, использования данных. Надо будет обсудить с А.С.Караушем, М.С.Трахтенгерцем...
Вот более конкретная (хотя пока и абстрактная:)) идея: Редактор, Генератор или Мастер указателей [irbis.gpntb.ru]
irbis_arbat@mail.ru
Редактировано 4 раз. Последний раз 07.01.2013 06:40 пользователем Lavrinovich.
БАРС - разработка МВТУ им. Баумана, чуть ли не первая в стране, давно забытая [irbis.gpntb.ru]
ориентированная исключительно на карточки. Похоже, это как раз и был редактор-генератор КК!. В результате им пришлось заниматься ретроконверсией и даже самим писать OCR...
А еще БАРСом хотели сначала назвать ИРБИС 64. В общем, сегодня имя свободно.
***
Можно вообразить и автоформирование каталожных карточек на основе распознанных библиографических списков и "прикнижных", пристатейных или отдельных указателей. Но такой подход (в обход ЭК, в обход АБИС) неперспективен, неэффективен, нерационален, не отвечает важнейшему принципу однократного ввода и многократного многоаспектного вывода, использования данных. Надо будет обсудить с А.С.Караушем, М.С.Трахтенгерцем...
Вот более конкретная (хотя пока и абстрактная:)) идея: Редактор, Генератор или Мастер указателей [irbis.gpntb.ru]
irbis_arbat@mail.ru
Редактировано 4 раз. Последний раз 07.01.2013 06:40 пользователем Lavrinovich.
Извините, только зарегистрированные пользователи могут писать в этом форуме.