> Это же, в конце концов, не текстовый редактор. ((с) Куделя М.В.)
>> И напрасно! Обработка ошибок не помешает ни одному приложению.
>> Человеческий фактор – упрямая вещь: неприятности на работе, в семье – и появились глупые ошибки.
>> Если система не учитывает многих элементарных вещей, то грош ей цена. На дворе
>> не 80-е годы и в руках у Вас не ZX-Spectrum… Но, конечно, это тема отдельного разговора ((с) Горбунов Слава)

Итак, тема.

Основные "русла":
1. Насколько нужна проверка?
2. Достаточна ли она, и где еще конкретно требуется проверка?
3. А не стоит ли все это вынести в отдельные приложения, поскольку у каждой библиотеки "свои тараканы"?
4. Прочее.

Тут 30-го зашел в отдел обработки и меня там загрузили (ну а что, 50 г. налили и понеслось излияние души :). Как раз по проблеме корректировки каталога. Для корректоров Ирбис вообще никак не предназначен (по крайней мере не один из АРМов)... Корректору приходится в окне просмотра читать текст, ведя пальцем по монитору!!! Не знаю как вам, а мне даже стало ее жалко и очень обидно за Ирбис.
Да-да, знаю про АРМ Корректор, но и про цену его знаю (не в обиду Илье) :). Другое дело, если бы этот АРМ вошел в состав дистрибуции Ирбис. Но вот проблема: общая идеология (вернее даже схема работы) не соответствует схеме Ирбис.
Сейчас многие скажут: "Что еще за схема?". Это я просто так выссказался :). На самом деле было бы не плохо видеть язык скриптов более похожим на язык форматирования... или даже ввести эти команды в ГК (это мне даже больше нравиться).
По поводу отдельности АРМа: согласен, не стоит мешать молоко с селедкой (сами знаете что будет :). Но вот проверка орфографии необходима в каталогизаторе.
На этом мысль останавливается :)

В версии 2004.2 в АРМе Каталогизатор есть контроль орфографии...

Александр Иосифович, мы прекрасно об этом знаем :), но вот в областной библиотеке все еще 2003.1 :(... Да и сдесь мы не обсуждаем конкретные версии, а говорим о автокорректировке каталога + удобный инструмент для корректора (пробелы двойные и все такое).
Хотелось бы видеть что-то похожее на то, что Илья Михайленко написал, только в прайсе ГПНТБ.
Проверка орфографии в Каталогизаторе безусловно нужна. Это позволит отсечь львиную долю орфографических ошибок уже на этапе ввода записи. Но вот постредактуру следует выделить в отдельный АРМ.



Отправка отредактированного (19-01-05 16:41)

г. Ярославль

Стоп - стоп.
Про плач библиотечных "ярославен" и про скрипты работы - в соответствующих ветках. Пока писал текст уже много изменилось:)

Я за выходные был занят - спал, поэтому не успел приделать вводной лекции к данному форуму :)

Итак.

Согласно общим представлениям про системы и уровень доступа, пользователи, с одной стороны, хотели бы иметь систему, которая проверяла бы и исправляла все возможные ошибки сама.
НО, согласно требованиям человека, у которого "семь пятниц на неделе" в каждый конкретный период времени может потребоваться возможность исправления данных в системе. И при этом у исправляющего человека должны быть все права и возможности, в том числе пакетной корректировки.
Понимая, что это невозможно, человечество придумало знания, которые передаются в виде обучения (ликбез). И как показывает наука Марксизм-Ленинизм (извиняюсь, если кого обижу), то развитие происходит в виде спирали. Сейчас, при вере в то, что компьютер заменит человека во многом, люди пытаются свалить на технику алгоритмы и то, что она не успеет применить, поскольку сам человек изменит правила до этого момента.
Реальный пример: ГОСТ 7.1-2003. Зачем нужно было вкладывать в его разработку деньги в 1997-2000 гг, чтобы потом "пропустить на господство RUSMARC" в 2000-200х гг. и, ничего не вкладывая, принять на всю страну этот ГОСТ, основа которого MARC-21??? А мы и правила описания по RUSMARC не то что применить - изучить толком не успели!
В связи с этим вопрос: "А на что корректор настраивать? На какой из стандартов?"
К сожалению, многие в библиотеках забыли простые пословицы:
1. "Семь раз отмерь - один отрежь".
2. "Чисто - там, где не сорят".

Все больше я склоняюсь к мысли, что нужно вначале обучить, а потом давать технологии. К сожалению, исправление в электронном виде на порядок сложнее, чем создание заново. В этом заключается вселенская несправедливость - не что иное - как дешевизна новых технологий. Именно дешевизна. Я имею ввиду относительную ценность, скажем, по сравнению с 10-ю годами ранее. Ввести данные становится настолько просто и легко, и во столько же раз усложняется процесс исправления – законы диалектики :)
Философы предсказывают, что через 10 лет 80% населения планеты будет работать (зарабатывать и кушать) на том, что будут работать с информацией. Материальное будет возвращаться только во время еды :) Вот золотые времена близятся для «грамотных» библиотек!? Так что исправлять ошибки уж точно никто успевать не будет, но потребуются технологии этакого «лже он-лайн детектора».

Хочется поставить, еще вопрос: «А насколько нужна вообще технология проверки данных, которые должны быть созданы в соответствии с нормативными документами?». Зачем писать в положении о сети, что в случае преднамеренного уничтожения данных администратора уволят, если есть статья, по которой ему могут 2 года дать? То же и про написание инструкций, в которых не стоит перепечатывать стандарты, чем сейчас очень многие занимаются, а просто дать ссылку на ГОСТ или нормативный документ. Были случаи, что библиотеки начинали спорить про разные трактовки нормативных документов, написанных для разных АБИС. Этого хочется избежать. И пусть инструкция или программа курсов будет «понаучнее», чем вместо повышения квалификации по биб.технологиям получать солнечные удары или осмотры дворцов.

В библиотечной среде, (как и в обществе в целом) характерен вопрос: «А как он(а) выглядит?» Точно так же наличие соблюдения формальных правил формата и проверок не гарантирует отсутствие нападок коллег, которые усмотрят ошибки каталогизации. Именно тут и кроется желание многих библиотек поставить программы коррекции, чтобы было на что свалить в случае появления ошибок. Особенно это характерно для сводных электронных каталогов, где никто ни за что отвечать не желает, если есть добровольные принципы передачи данных, и отдачи особой нет. Причем, тут имеется наличие региональных особенностей каталогизации (технологий). Вопрос:
А не стоит ли вынести технологии проверки не только во внешние файлы, а во внешние модули, причем формат работы модулей не был бы привязан к конкретной АБИС, а только к формату данных?
В данном случае сложно что-то предложить, поскольку выбор какого-либо одного поставщика технологий грозит монополизмом и стагнацией технологий, а вот единого формата передачи информации, кроме как xxxMARC, я не вижу.
Причем точно могу сказать, что стоит использовать технологии для передачи и обмена внутренними данными «не OLE». И не только для карточек (который тоже можно отдать внешним организациям (или сделать наконец-то на всю страну один этот орган, чтобы не было препирательств по виду карточек), а также для модулей проверки, ЭДД, бухгалтерии, конвертирования, книгообеспеченности и прочих.

Относительно вопросов АРМа корректора, как инструмента для ведущего библиографа, корректора, зав.отделом и его необходимости мною написано и сказано не раз. И учитывая все вышеописанное, разработчики ИРБИСа, видимо, не испытывают «особого счастья и вдохновения» для написания данной программы. Точно так же, как я не испытываю большого вдохновения писать модули проверок того, что прошли «мои подопечные» и не делают более ошибок, тем более, с привязкой к очень частным вопросам технологий, например заводов.

В свое время IsisUtil (да и сейчас тоже) позиционировался именно как АРМ для корректора CDS-ISIS с возможностью интерактивного доступа к данным, в отличие от пакетных корректоров. Далее большие сопутствующие задачи сделали его утилитами, а не только инструментом для корректора. Мы его давненько не обновляли, но в рабочих версиях, которые мы не выкладываем, потому, что никто не регистрирует у нас его, уже есть и статистика, для редких запросов, типа «А сколько экземпляров книг последних трех лет издания поступило в филиал А за последний год?» и будет еще много чего, вплоть до смены языка, он-лайн help’а и пакетной проверки орфографии заданных полей. Но повторюсь, что это АРМ для высококвалифицированного персонала, а не для новичков!
Прежде всего – обучение. Пусть через насилие. А помощь к этой программе так тяжело писать, что просто ужас.

Система показателей по эффективности безнесс-процессов накладывает иной подход к проверкам и коррекциям соответственно. Поскольку формализация достигла больших высот, то данные очень просто становится обратить из одной формы в другую. Т.е. информация становится просто «электрофицированной» (структурированной) везде, где это возможно и невозможно. Соответственно, стоит ли сейчас тратить время на исправление руками того, что после можно будет сделать автоматом? Ведь никто не думал 5 лет назад про проверку орфографии в АБИС, когда были «на коне» правила сокращений. А сейчас – все правится и карточки распознаются и блоками данных манипулируют, и смысл в словосочетаниях находят по смысловой близости. А?
Какова цена подобных проверок и коррекций (эффективность)? Не стоит ли ограничиться соблюдением формальных небольших правил и далее «не выпендриваться» у кого больше или меньше ошибок, и принять это как способ к действию?

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

Вопросы для обсуждения:
1. А на что корректор настраивать? На какой из стандартов?
2. А насколько нужна вообще технология проверки данных, которые должны быть созданы в соответствии с нормативными документами?
3. Не стоит ли вынести технологии проверки не только во внешние файлы, а во внешние модули, причем формат работы модулей не был бы привязан к конкретной АБИС, а только к формату данных?
4. Стоит ли делать он-лайн службу проверки (платную, естественно), куда бы можно было давать записи для экспертной проверки?
5. Стоит ли сейчас тратить время на исправление руками того, что после можно будет сделать автоматом?
6. Какова цена подобных проверок и коррекций (эффективность)? Не стоит ли ограничиться соблюдением формальных небольших правил и далее «не выпендриваться» у кого больше или меньше ошибок, и принять это как способ к действию?
7. И если пользователь делает ошибку в запросе, то ему нужен ли корректор запроса, или с другой стороны «антикорректор» электронного каталога, где бы встречались совпадения с частыми ошибочными запросами пользователя?

> Хотелось бы видеть что-то похожее на то, что Илья Михайленко написал, только в прайсе ГПНТБ.

Я бы написал несколько шире, а именно: "Какие формальные правила должны быть для ПО, которое пожелает быть в прайсе ГПНТБ?"
И с этого вопроса должен быть открыт форум с ограничением на участие только дилеров и соразработчиков!!! Пора уже, блин!
Туда же вопросы относительно качества поддержки дилеров и качества их работы в целом, вопросы законодательства и строчек договоров. С одной стороны марку портить нельзя, а с другой стороны так хочется прилюдно (или почти) высказаться, а встречи дилеров редко. Но будет, я верю, закрытая ветка в форуме. Да?

Точно!!! Но вот загвоздка: я не в одной системе не видел такого, чтобы пользователи добавляли в систему официально свои разработки. Да еще и деньги за это получали. Ооооочень сомнительно.

> Точно!!! Но вот загвоздка: я не в одной системе не видел
> такого, чтобы пользователи добавляли в систему официально свои
> разработки. Да еще и деньги за это получали. Ооооочень
> сомнительно.

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

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

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



Отправка отредактированного (11-01-05 16:50)

г. Ярославль

Ну дык создал - уровень доступа 7 = пока только трое - я , Александр и Макс = запостите что нить туда - работает или нет???

Проверил. Работает. Я кстати вначале туда и пошел. А сейчас восстановил контент :)

Ну и как там - "натроих" ?:)) а то я б тоже заглянул, вернувшись из отпуска...

Скучно :))), так письмо Михаилу Владимировичу и все...

Большие и серьезные вопросы Вы, Максим, поставили.
Над этими вопросами я то же очень много думал, прежде чем начинал что-то делать. Надеюсь, эта ветка получит продолжение и появится много мнений по этим вопросам. Вопросы действительно "наболевшие". Ниже я попробую изложить ход своих мыслей по этим вопросам.

>1. А на что корректор настраивать? На какой из стандартов?

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

>2. А насколько нужна вообще технология проверки данных, которые должны быть созданы в соответствии с нормативными документами?

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

>3. Не стоит ли вынести технологии проверки не только во внешние файлы, а во внешние модули, причем формат работы модулей не был бы привязан к конкретной АБИС, а только к формату данных?

Выносить в отдельный модуль стоит. Скрипты проверок слишком большие, а, как следствие, их исполнение занимает слишком много времени. Особенно проверка связанных записей...
А вот про форматы АБИС... Нельзя "отвязывать" такую проверку от АБИС. Можно, конечно же, проверять ISO в каком-то там марке - это одно. Но если вести разговор про АРМ, то он должен отслеживать весь жизненный цикл записи и ее окружения.
Да и что даст "стандартному библиотекарю" сообщение об ошибке в индикаторе n-ного поля формата rusmarc? Даже если и даст какую-то иформацию, пользователю все равно придется открывать и править эту запись в своей АБИС.

>4. Стоит ли делать он-лайн службу проверки (платную, естественно), куда бы можно было давать записи для экспертной проверки?

Вот это, имеет мало смысла.
1. Что такое "запись" - в каком она формате? Если в коммуникативном, то понадобится еще эксперт, который точно знает как эта запись встанет в такой-то АБИС такой-то версии у пользователя.
2. Как проверить окружение этой записи?
3. Кто из _русских_ пользователей будет платить деньги за то что бы ему сказали "Вы плохо работаете"? Где это может сработать, так это при сертификации. Но тут - другие игроки - разработчики АБИС.

>5. Стоит ли сейчас тратить время на исправление руками того, что после можно будет сделать автоматом?

Нет инструмента, который бы показывал "хорошая запись" или "плохая запись". Вот, пытаюсь сделать что-то хоть отдалено напоминающее такой инструмент. :-)
Автоматом не всегда возможно.

>6. Какова цена подобных проверок и коррекций (эффективность)? Не стоит ли ограничиться соблюдением формальных небольших правил и далее «не выпендриваться» у кого больше или меньше ошибок, и принять это как способ к действию?

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

>7. И если пользователь делает ошибку в запросе, то ему нужен ли корректор запроса, или с другой стороны «антикорректор» электронного каталога, где бы встречались совпадения с частыми ошибочными запросами пользователя?

Попадая на форумы в интернете (этот - редкое исключение) начинаешь думать об отсутствии проверки орфографии в iExplorer. :-) "Пишите правильно". Хоть так приучать молодежь к русскому языку. :-)
Глядишь, начнут учить русский язык только из желания получить необходимую информацию. Ну нет у нас книг ДостАевского...

Открываем плоскость "Ввод" АРМ "Каталогизатор" системы "Мини Ирбис" версии 2003.2. Что мы видим?

- В 1997 г. для многих пользовательских приложений уже был распространен как стандарт
вид формы с главным меню и панелью инструментов.

- Поля со списком (РЛ, БД, формат) открываются не на ширину текста строки списка,
а на ширину поля, это неудобно.

- На многих страницах элементы БО расположены не в том порядке, каком они описаны в стандарте ГОСТ-7.1
(хотя для программы это не важно).

- В окне полного описания нет пробелов между текстом и разделительными знаками областей БО по ГОСТ-7.1.

- При вводе в подполе объемного текста, н-р длинного заглавия,
удобно было бы применять вызываемую по "Shift"+"F2" отдельную форму,
типа как окно для ввода данных элемента "331: Аннотация".

- Аналогично форма "Термин полностью" почему-то слишком мала.

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

- Если значение подполя нужно выбирать из справочника или списка, то по "F2" открывается форма
соответствующего справочника и фокус переходит в ключ.
Но в простых (не иерархических) справочниках удобнее искать нужную строку, вводом начала слова
непосредственно в списке с выделением первых совпавших символов (как в "Консультант +").
При этом выборку надо допускать или по значению, или по пояснению справочника.
Ключ же лучше использовать как фильтр, ограничивающий список,
н-р: список авторов - фамилиями, начинающимися со слова в ключе,
а список заглавий - содержащими слово из ключа.
Подобные процедуры в Ms Access 97 легко решается с помощью DAO и Basic.

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

Н-р: в справочнике элемента «463^1: Местоположение - Единицы измерения" при вводе в ключе "cd-rom"
открывались бы строки, содержащие этот текст.
Примерно также это делает правовой навигатор "Консультант Плюс".

- Еще наглядный пример: для поиска в списках и в иерархических справочниках можно сделать так,
как это сделано в справочнике "Ирбис" «Авторитетный файл «Предметные заголовки».
На вкладке «Фрагмент» в поле «Ключевое слово» вводим "общ", и в списке открываются рубрики:
«Общественно-политическая жизнь» и «Экономика - Торговля – Общественное питание».
Это гораздо удобней, чем долгий перебор рубрик на вкладке «Словарь».

- Во многие справочники не внесены даже толковые пояснения к значениям,
а информация по применению этих значений вообще не предусмотрена.
Н-р: кто встречал печатный ББК с приведенными индексами и их наименованиями,
но без текстов, содержащих описания применения этих индексов?


"Ирбис" можно дополнить обработкой простых текстовых ошибок:

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

- можно удалять повторные или не нужные пробелы в начале, внутри и в конце текста элемента записи,

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

- определить и подставить к заглавию, начинающемуся с числа, текстовое значение этого числа,

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

Слава, я заметил, что Вы очень любите Консультант+. Но веть консультант - это консультант, а ирбис - это ирбис. Вы сейчас пытаетесь нам докозать, что Ирбис не похож на Консультант. Да, не похож. И что? Увидев один раз продукт Microsoft Вы хотите, чтобы все без исключения программы поддерживали его интерфейс? А Вы пользуетесь WinAMP-ом? Он что, сильно похож по функциональности на Консультант? У него есть меню и тулбары? Нет.
С некоторыми предложениями по улучшению функциональности, я согласен. Например окно справочника или рабочего листа подполей удобно было бы закрывать на Esc (я периодически по привычке нажымаю :). Таких примеров много. Но нельзя же все под одну грубенку...

>"Ирбис" можно дополнить обработкой простых текстовых ошибок:

В сам Ирбис не стоит. Время на обработку записи и так достаточно велико. Основные проверки (логические) там присутствуют.

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

Какой элемент?

- можно удалять повторные или не нужные пробелы в начале, внутри и в конце текста элемента записи,

Это делается в IsisCorrector.

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

Мысль интересная, но надо четко представлять в каких полях это возможно. Иначе, например, если в url после точки вставить пробел...

- определить и подставить к заглавию, начинающемуся с числа, текстовое значение этого числа,

Это уже вопрос к библиографам. На сколько вообще это корректно. Если заглавие книги начинается с числа.

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

Надо всегда уточнять какой элемент имеется ввиду. Иначе разговор без предмета обсуждения получается. К каждому полю свой подход.

Не придется ли заводить отдельные словари для каждой предметной области, как в программах-переводчиках? Например, Word не знает слов «интернет», «сайт», «маршрутизатор» и мн. др.
А вообще здесь речь идет не столько о проверке орфографии, сколько о контроле соответствия требованиям MARC, ГОСТ и т. д. Хорошо бы еще была автопроверка имен и названий по авторитетным/нормативным файлам. Но здесь есть много опасностей — могут «автоисправляться» похожие фамилии, юмористические, каламбурные и пародийные названия, умышлено неграмотные написания (warez, rulezzz), жаргонизмы и диалектизмы, например, в рок-, панк-, рэп- и т. п. субкультурах. То же самое со строчными и заглавными буквами. А как автоисправить ошибочную дату издания — такие ошибки есть, например, в БД РКП, для человека они очевидны, а для программы нет.

По теории вероятности, текст определенного объема не может не содержать определенного % ошибок. В СвЭК их должно быть больше.

«АРМ Постредактор» — 1. IsisUtil действительно очень похож на такой АРМ. 2. Может быть, нужен не совсем отдельный новый АРМ, а разновидность «Каталогизатора», аналогично АРМ МБА, или задача (подсистема) в нем, аналогично «Книгообеспеченности»?

«Корректор запроса» — подобное уже есть в виде «мебель — стулья» и т. д. и может, видимо, развиваться и дальше (видимо, особенно в ИРБИС64). Главное, штоп не было политкорректора, вроде советского руководства чтением, когда детям навязывались книги про пионеров-героев.
А вот хорошо бы был еще «Подсказчик», т. е. автопоиск по связи по ключевым словам, предметным рубрикам, классификациям. То есть. если, например, в ЭК нет книги с определенным заглавием, система сама выдает рекомендательный список «похожих»!
«Антикорректоры, где бы встречались совпадения с частыми ошибочными запросами» есть в поисковиках, которые, как минимум, пытаются учитывать орфографические ошибки и неверную раскладку рус./англ.

А еслди рассуждать вообще о модулях (АРМах) конвертирования, книгообеспеченности, книгохранения, МБА и ЭДД, а также ведущего библиографа, зав.отделом, а также бухгалтерии, зав.кадрами, зав.складом, директора и т. д., то можно сказать одно: это будут модули не САБ, а системы управления предприятием (АСУП)
Или же САБ будет модулем АСУП с соответствующими «подмодулями». Например, в вузе — наряду с АРМами «Ректорат», «Учебно-методическое управление», «Приемная комиссия», «Издательство»... В НИИ, на заводе — еще что-то… Это мы уже здесь несколько раз обсуждали.
Будущие покупатели разработчиков ясны — «1С» и MS Business Solutions (пишут, что проф. Бабаян неплохо чувствует себя в Intel, хотя судьба процессора «Эльбрус» так и не ясна). А как делать «привязку к очень частным вопросам технологий, например заводов», говорят, знают в той же «1С».

OFF TOPIC
Глубокоуважаемый Александр Сергеевич!
Ну нету такой штуки «марксизм-ленинизм», само это словечко — выдумка Иосифа Виссарионыча. Вот марксизм — есть, но это ложная теория, как и материализм вообще, опровергнутый, как Вам, думаю, известно, в т. ч. -физиками.

О «вселенской несправедливости дешевизны новых технологий». И правда, сейчас любой может почти бесплатно обнародовать на весь мир свои стишки, песенки, рисунки, статьи:) И кроме «настольной типографии» (термин 15-летней давности), у всех желающих есть настольная аудио-, фото-, кино- студия. Но по законам диалектики (не Марксом открытым) в этом есть и плохое, и хорошее. Но эта тема бесконечная и, действительно, OFF…



Отправка отредактированного (05-08-05 12:48)

«Вынести в отдельные приложения, поскольку у каждой библиотеки "свои тараканы"?» — то есть писать собственные уникальные приложения? Но в большинстве библиотек нет разработчиков, а если есть, нет гарантии соблюдения стандартов, то есть выйдет еще хуже, чем есть.
«Вынести технологии проверки не только во внешние файлы, а во внешние модули, причем формат работы модулей не был бы привязан к конкретной АБИС, а только к формату данных?» — то есть, наоборот, общие модули для всех библиотек и для всех АБИС?
Это развитие и уточнение моей идеи (см. «Интероперабельность») — чтобы все ЛО, а также MARC’и ГОСТы были сменяемыми и подключаемыми (загружаемыми)! Но такие автономные «абисонезависимые» проверочные и другие приложения — видимо, идея неосуществимая.
Разве что если бы вся АБИС состояла из готовых модулей:
· клиент-серверная СУБД, например, MS SQL Server
· все ЛО — в формате XLS
· MARC, ГОСТ и правила БО — тоже «системонезависимые», конкретно пока не представляю (XML?)
· РЛ и все другие экранные формы — шаблоны (надстройки) для Word или Excel (?)
· проверка орфографии, список сокращений и выходные формы — Word (макросы, шаблоны)
Но как заставить все это взаимодействовать? Значит, не обойтись без «екзешника», и тогда вся затея теряет смысл? И не будет ли это шагом назад? И не лучше ли тогда открытые и бесплатные СУБД (напр., MySQL) и офисные пакеты (напр., OpenOffice.org), о чем здесь уже много говорилось?
Вот если бы средством разработки был MS Office или если бы АБИС были встроены в ОС (а так, или вроде того, и будет…). Вроде бы шаг в эту сторону — использование «стандартных» СУБД (открою страшный секрет — почти все покупатели «МАРК-SQL» используют Access; слышал, что разработчики «Библиотеки 3» даже рекомендуют для начала Access).

«ПО, которое пожелает быть в прайсе ГПНТБ?» — на то ведь оно и называется не ГПНТБ, а Международная Ассоциация ЭБНИТ.
Доработки и дополнения к ИРБИСу — это одно, а автономные «абисонезависимые» приложения (модули, утилиты) — другое, даже противоположное.
«Чтобы пользователи добавляли в систему официально свои разработки. Да еще и деньги за это получали».
Вопрос гораздо шире, серьезнее, стоит давно и не решается. Если, например, директор должен поощрять сотрудников, хотящих и могущих «автоматизироваться» (о чем здесь тоже уже говорили, в основном А.С.К.), то кто-то должен централизовано и систематически поощрять библиотеки за помощь программистам. Может быть, АРБИКОН — на его сайте что-то сказано о финансировании проектов — или фонды типа РФГН? Но здесь не должно быть конкурсности и разовости, нужно именно систематическое финансирование.
Причем оплачиваться должны не только готовые дополнительные разработки (утилиты, модули и т.д.), но и идеи, предложения, даже выраженные в словесной форме. Так как почти все АБИС больше похожи на многолетние альфы (когда-то где-то об этом говорил Э.Н.Замуруев из РХТУ им. Менделеева).

В этом отношении от областных, районных, городских властей больше вреда. Два-три года по всей стране идет ИЗБЫТОЧНОЕ, принудительное и БЕСЦЕЛЬНОЕ оснащение школ, вузов и библиотек компьютерами и «интернетом». Не будем говорить о коррупционом характере этого явления. Мы еще почему-то должны их хвалить, благодарить (как говорила Е.В.Линдеман, все время кланяться, петь и плясать) — см. московские районные газеты: «Ах, администрация подарила нам компьютер!!!». И никому даже не приходит в голову, ЗАЧЕМ.
О результатах я уже писал — см. «Еще мемуары» и «Секретные виды услуг». Добавлю только, что и в федеральных библиотеках слово «компьютер» по-прежнему часто произносится со страхом и ненавистью — что же говорить о филиалах ЦБС.

to О.Копылов:
ГИВЦ в 1990-2000 гг. постоянно вымогал у меня такие предложения и получал многостраничные тексты, фактически — ТЗ по каждому АРМу. И каждый раз их «теряли», и снова и снова просили, умоляли, настаивали, одновременно с требованиями им платить каждый год и т. д. и т. п. ДА, хочется верить, что теперь там ДРУГИЕ люди. Но и Ваша идея о скидках для активных тестеров «АС-Библиотеки 3», конечно, тоже неудачна. И вообще, что за удовольствие копаться в чужих ошибках и недоделках.
Скажу ЕЩЕ И ЕЩЕ РАЗ: advanced users — как минимум соавторы, а то и авторы (и даже М.В.Гончаров в 2002-м со мной в этом согласился).

Кстати.
Михаил Владимирович!
«Оргмомент и кто отвечает за качество товара» — независимая вневедомственная экспертиза, тот самый «МКЦАБР», который Феликс Семенович предлагал создать 10 лет назад!!!
Он должен быть общественным, но уполномоченным, как минимум, несколькими министерствами, а лучше правительством, или даже международными организациями? Впрочем, кажется, ЮНЕСКО рекомендовала ЛИБЭР (а ГПНТБ числилась его дистрибутором), хотя она (ЛИБЭР) была совсем не того (по крайней мере, в 3-й версии).
ЭБНИТ, АРБИКОН, КСМБ? — все они занимаются немножко (множко) другим. Скорее всего, нужна экспертная комиссия при РБА.



Отправка отредактированного (05-08-05 12:52)

«хто приблуды разные делает […] качество товара […]. двойственное впечатление».
Действительно, софт обычно не пишется в одиночку, а все, что free и share — кривое и недоделанное. Некоторые поверхностные и общеизвестные наблюдения (примеры):
1. Total Commander. Русификация самопальная, русского хелпа нету, и фамилия Гислер подозрительная - часто встречается у Нострадамуса:)
2. FAR, говорят, хорош только сторонними плагинами, да и делает его теперь не Е. Рошаль, а FAR Group; RAR соответственно — RAR Soft (или А.Рошаль?).
3. Linux. Миф о непадучести опровергается ежеминутно — по крайней мере, в отношении некоторых самых простых приложений (графических). ASPLinux хоть и улучшается с каждой версией, но и в 10-й русификация частичная, и в целом все выглядит как результат дуракаваляния студентов.
4. Ближе к делу.
4.1. WinISIS. He меньше трех вариантов русификации, более или менее самодельных, руского хелпа нет.
4.2. ISISMARC 1.1. Хелп только испанский.
4.3. GenISIS и ISIS Outil. Интерфейс только французский, хелпа нет вообще, документация неполная, в основном французская.

Вывод №1.
Цитата из А.С.К. от 2002 г. (тема «Open source library systems»): «сумма на изучение, освоение без программной поддержки и Upgrade, а потом на реорганизацию и конвертирование данных, существенно превосходят затраты на покупку мини-ИРБИС».

Вывод №2.
Граждане и гражданочки, покупайте ИРБИС по полной цене, дважды в год обновляйте и забудьте про любые собственные и сторонние доработки, дополнения и предложения по улучшению. Правильно? Нет, неправильно — ведь тогда и этот форум был бы не нужен. С другой стороны, результаты работы больших и высокооплачиваемых коллективов тоже часто не того. Еще цитата из А.С.К., оттуда же: «Windows собирается из подпрограм, которые пишут студенты. И вот вам "продукт вечно сырой"»
— а русифицируют его российские студенты в Ирландии. И ведь это продукт не одного человека, не одной фирмы и даже не одной страны — над Лонгхорном (теперь Vista) трудятся в т. ч. МГУ, СпбГУ и несколько НИИ РАН.

Вывод №3.
А нету вывода. Действительно, «двойственное впечатление», и даже множественное.



Отправка отредактированного (05-08-05 12:56)

«Стоит ли делать он-лайн службу проверки […], куда бы можно было давать записи для экспертной проверки» (М.Панев)

Говорят, что скоро вообще все ПО и ИТ-услуги будут онлайновыми. Например, MS Office будет сдаваться в аренду на сайте Микрософта, а сверхмощные программы синхронного перевода будут работать на сверхмощных серверах провайдеров или поисковиков, и любой французский или китайский сайт будет мгновенно и незаметно для пользователя переведен на русский, чукотский...

Поэтому представим, что ИРБИС256 2010 установлен в единственном экземпляре на сервере ЭБНИТ и вся каталогизация в СНГ онлайновая, с централизованной проверкой и автоисправлением орфографии, пунктуации, проверкой на соответствие ГОСТ 7.1-2009, RUSMARC-2009, с автоклассифицированием по ДКД, УДК, ББК, ГРНТИ, классификациям Библиотеки Конгресса и НБ МГУ, по нескольким тезаурусам, с автоиндексированием ключевыми словами и предметными рубриками, автореферированием и автоаннотированием.
И все бесплатно — а провайдеры, поисковики и ЭБНИТ (и ГПНТБ) будут получать миллиарды только от рекламы, как это уже делает Google (кстати, он [Google] собирается делать свой браузер и даже, якобы, свою ОС).

Насчет «Корректора» и «Постредактора».
В одной статье прочитал:
«Для проведения ретроконверсии каталога библиотеки сотрудники ВГБИЛ и специалисты «Гипер» совместно разработали комплекс «Маэстро». […] В автоматическом режиме система удаляет переносы в словах; доставляет точки в сокращениях; заносит соавторов из добавочных библиографических записей в поля авторов, расшифровывает сокращения [!!! — А. Л.] и т. д. Затем идет проверка и корректировка содержимого полей карточки библиотеки — параллельно в двух режимах. В автоматическом режиме содержимое полей редактируется с помощью программы «Коррект», на одну карточку при этом уходит 2 секунды. В ручном режиме оператор редактирует неформализуемые поля, например, инвентарный номер. […] Контроль качества библиографических записей выполняется в программе «Универсальный редактор» комплекса «Маэстро», которая сокращает время редактирования каталожной карточки до 2 минут. И, наконец, на последнем этапе обработки массива КК производится конвертирование их в требуемый формат. Причем непосредственно перед процессом конвертирования «Маэстро» проверяет электронные библиографические записи на дублетность названий и инвентарных номеров, производит поиск и удаление списанных изданий по актам списания [? — А. Л.] и генерирует предметные рубрики по классификационному индексу […] этот процесс предварительной обработки 1000 записей на ПК занимает несколько минут»
Глинников М. Мы и информация // Директор ИС. — 2001. — №1

to О.Копылов:
Если это правда, хотя бы частично, то «Гипер» (который ИАНС) далеко впереди планеты всей. Но почему же тогда хотя бы части всех этих сокровищ нет в "АС-Библиотека 3?"



Отправка отредактированного (05-08-05 12:58)

Потрясно!!!
Моя утопически-футуристическая фантазия, сочиненная больше джля смеху, что через 5 лет вся каталогизация и вообще вся автоматизация будет онлайновой, по сообщению А.С.К., уже сбылась в Израиле (вплоть до учета посещений и выдач!!!)…
Однако в стране шириной 6 км это не очень трудно…
А в США такое существует скорее как исключение. Никто пока вроде бы не заинтересовался интернет-арендой MS Office - а ведь этой идее уже несколько лет.

А вот в докладе Обухова А.В. «Разработка приложений для баз данных CDS/ISIS на основе компонента IsisOle» (http://www.gpntb.ru/win/inter-events/crimea2000/doc/tom2/section2/Doc117.HTML) говорилось, в частности, следующее:
«IsisDict — инструментальное средство для автоматизации процесса корректировки словарей БД CDS/Isis. Основное предназначение программы — стандартизация терминов, в первую очередь ключевых слов […] создается словарь исправлений, который может быть использован в дальнейшем для других баз данных. […] программа позволяет исправить записи БД в пакетном режиме и актуализировать словарь»
Это, видимо, было еще под DOS? Но в любом случае идея хорошая.

Иногда пишут о типичных ошибках, допускаемых библиотекарями в тексте, при вводе элементов библиографического описания. На это хочется заметить:

1. Проблема двойного пробела, вводимого неопытным пользователем.

Например, на VBA обработчик подобной ошибки может выглядить так:

Public Function PravText(strText As String) As String
Dim intI As Integer
Dim strTemp As String
' удаление пробелов в начале элемента описания,
strText = LTrim$(strText)
' а также лишних пробелов внутри текста
For intI = 1 To Len(strText)
strTemp = Mid$(strText, intI, 1)
' поочередный просмотр символов текста
If Not (strTemp = " " And Right$(PravText, 1) = " ") Then
PravText = PravText & strTemp
End If
Next intI
' конец, лишние пробелы из текста элемента описания удалены
End Function

Такая процедура удаляет лишние пробелы в элементе данных, перед его обновлением (сохранением) в АБИС на основе Ms Access, применяемой в нашей районной библиотеке. То есть для этого не нужно никаких других дополнительных подпрограмм или АРМ-ов!
Кстати, после ввода элемента описания по F7 тут же можно проверить текст на допущенные по невнимательности грубые ошибки.

2. Несколько лет школьников учат ставить точку после окончания предложения или сокращения слова. Но разработчики "Ирбис" предлагают нарушить традицию, не позволяя ставить точку в конце элемента, потому что тогда в описании получается повторение этой точки предписанным знаком.
Допустим, что текстовая переменая strText содержит составляемое подпрограммой библиографическое описание, тогда простая проверка (на VBA) последнего символа переменной позволяет избежать "двойных" точек в БО:

If Right(strText, 1) <> "." Then
' Проверка последнего символа текста описания
strText = strText & ".- "
' Если описание не заканчивается на точку, то вставить предписанный знак точки
End If
' Далее добавляется следующий элемент описания

3. Подобных примеров можно привести много, но остановимся пока на этом. Хотя я согласен, что необходимо перевести нашу библиотеку на приобретенную систему "Мини-Ирбис" версии 2003.2, да пока не хватает времени на этот ответственный шаг.

Слава, VBA - это конечно хорошо, но вот он не имеет никакого отношения к Ирбис. Двойные пробелы и точку в конце можно убрать и в autoin.gbl (только вот придется писать команды для каждого нужного поля, что достаточно грамоздко). Только в этом случае сохранение записи будет еще дольше продолжаться.

Двойные точки убираются специальным UNIFOR('!')

Пусть так, но ведь это устранение последсвия, а не следствия. Все равно точка в БО останется.
Рассуждая здраво, БО - это информация. Какая информация в точке? НИКАКОЙ. А лишние 4 байта она занимает :). Так может ее прсто чистить, так же ка и другие лишние символы. Для определения лишних символов можно придумать какой-нибудь механизм на основе ЯФ или даже ЯП (языка поиска). Пусть этот механизм работает так же как и ФЛК, только для каждого поля. Для всей записи он в общем-то не нужен. При нахождении неверных символов можно спросить пользователя, а можно и не спросить (параметр в ини). Если иметь возможность еще и отключать этот механизм, то получается все вроде бы радужно.
Мы удаляем все двойные пробелы, точки в конце, заглавные меняем на прописные может еще что-то. В принципе это не сильно замедлит процесс.
Как на счет такого улучшения в 2005.2?