Re: Проверка. Необходимая и достаточная реакция АБИС на ошибки
Пользователь:
Карауш (IP-адрес скрыт)
Дата: 10, January, 2005 17:42
Стоп - стоп.
Про плач библиотечных "ярославен" и про скрипты работы - в соответствующих ветках. Пока писал текст уже много изменилось:)
Я за выходные был занят - спал, поэтому не успел приделать вводной лекции к данному форуму :)
Итак.
Согласно общим представлениям про системы и уровень доступа, пользователи, с одной стороны, хотели бы иметь систему, которая проверяла бы и исправляла все возможные ошибки сама.
НО, согласно требованиям человека, у которого "семь пятниц на неделе" в каждый конкретный период времени может потребоваться возможность исправления данных в системе. И при этом у исправляющего человека должны быть все права и возможности, в том числе пакетной корректировки.
Понимая, что это невозможно, человечество придумало знания, которые передаются в виде обучения (ликбез). И как показывает наука Марксизм-Ленинизм (извиняюсь, если кого обижу), то развитие происходит в виде спирали. Сейчас, при вере в то, что компьютер заменит человека во многом, люди пытаются свалить на технику алгоритмы и то, что она не успеет применить, поскольку сам человек изменит правила до этого момента.
Реальный пример: ГОСТ 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. И если пользователь делает ошибку в запросе, то ему нужен ли корректор запроса, или с другой стороны «антикорректор» электронного каталога, где бы встречались совпадения с частыми ошибочными запросами пользователя?