Избыток мощностей!?
Пользователь:
Алексей Лавринович (IP-адрес скрыт)
Дата: 24, July, 2004 13:03
Куда же девать вычислительные мощности?
Как известно, параметры сегодняшних ПК, даже начального уровня, намного превосходят потребности библиотек, даже максимальные. Зачем, например, винчестер на 40 Гб — ведь если данные хранятся на сервере, не нужно и 3 Гб. То же касается процессора 2,4-3 ГГц, памяти 256-512 Мб, видеопамяти 64-128 Мб и т. д. (добавим к этому привычку отечественных библиотекарей использовать на четвертом Пентиуме с Windows 2000 DOS-приложения начала 90-х, бессознательно имитируя 286-й, а при наличии «витой пары» 100 Мбит/с работать исключительно в однопользовательском режиме).
Логично предположить, что возросшие на порядки )за последние 5 лет – в 10 раз) характеристики нужны для решения принципиально новых задач, например:
1.Индексирование полнотекстовых документов (тем более что Windows 2000 и XP сами индексируют все файлы для ускорения поиска и для замедления своей работы:)). Теперь должно хватить и места для индексных файлов в 10 раз больших, чем файлы данных, и времени на их построение. Хотелось бы узнать мнение Александра Иосифовича, с которым я обсуждал эту проблему (по телефону) году эдак в 98-м.
2.Автоматизированный перевод (как минимум с русского на английский и обратно) полнотекстовых документов
3.Автоматизированное реферирование — такие системы вообще известны (например, Либретто), но несовершенны и, конечно, не интегрированы с АБИС. Сейчас Microsoft разрабатывает систему, «способную сгенерировать “мини-реферат” из нескольких новостных сообщений, посвященных одной и той же теме». Очевидно, здесь речь идет о подписке на конкретный интернет-сервис, но ясно, что новости упомянуты просто как пример и что эта система может перерабатывать и любую другую текстовую информацию.
4.Автоматизированное индексирование ключевыми словами (КС). Как известно, ИРБИС по умолчанию формирует КС из заглавий, отбрасывая незначащие слова. Однако, как известно вообще в этом процессе (далее цитата) «анализу подлежат: Заглавие (название), продолжение заглавия, аннотация или реферат (к книге или статье), оглавление (содержание), а в наиболее ответственных случаях — также выборочные участки текста (например, введение, выводы и т.п.)» (Воройский Ф. С. Индексирование документов в АБИС // Библиотека. – 1996. – № 9. – С. 42-44). Предположим, эти фрагменты отсканированы и распознаны. Теперь нужно:
• исключить из них незначащие слова;
• определить удельный вес каждого элемента (например, заглавие и оглавление важнее, чем введение) – значит, анализируемый файл должен иметь структуру, поля (видимо, не обойтись без XML).
• далее нужна еще какая-то экспертная или информационно-логическая система…
• а потом все исправить ручками (или написать КС заново)
5. В пунктах 2-4 речь шла об обработке и переработке (в т. ч. сканировании и распознавании) в основном небиблиографических и неструктурированных (слабоструктурированных) элементов данных большого объема.
Однако давно известны попытки ввода библиографических описаний (БО) и создания ЭК путем сканирования и распознавания каталожных карточек (задача по сути обратная формированию выходных документов). Если не ошибаюсь, этим занимался Н. Е. Каленов в БЕН РАН, а позже, но совсем по-другому, фирмы «ПроСофт-М» и «Гипер» — «полуручным», очень трудоемким и дорогим способом (хотя каждая по-своему).
ИРБИС теоретически допускает импорт текстовых файлов, но если я правильно понял, каждый элемент в них должен быть вручную размечен метками UNIMARC, что практически неосуществимо и бесполезно.
(А ведь когда-то правила БО очень усложнились именно для того, чтобы оно стало машиночитаемым — для чего и придумали условные разделительные знаки типа «точка тире», «две косые черты»!..)
Что изменилось с тех пор (кроме вышеупомянутого многократного роста вычислительных мощностей и объемов памяти):
• значительно усовершенствовались системы OCR (FineReader);
• широко распространился XML.
Предлагаемый (предполагаемый) новый способ реализации: файл, полученный путем сканирования и распознавания БО, размечаем XML-тэгами (опять вручную?), представляющими собой метки MARC-формата, и соответствующие ЭД отправляем в соответствующие поля (непонятно как). Ясно, что здесь понадобятся усиленный (усовершенствованный) нормоконтроль и последующая глобальная корректировка. И, наконец, опять-таки исправляем «ручками»?
Конечно, все это имело бы смысл только при автоматизированном (а лучше даже автоматическом) и ПОТОКОВОМ выполнении всех операций — распознавания, контент-анализа, разметки (индексирования) полей и формирования документов в БД. Чтобы, например, сразу обработать целый список или указатель. Может быть, это умеет XISIS? Но в любом случае понадобятся скоростные сканеры и еще более совершенные системы OCR. Может быть, такая система уже есть и называется AIDIS — ABBYY Integrated Document Input System (см.: Васильев В. Документооборот: «чертики прячутся в деталях» // Сетевой журнал. — 2003. — № 11. — С. 58 - 62)
6. Если предполагается создание БД, включающих в качестве «внешних объектов» графику, аудио- и видеофайлы, интернет-ресурсы и т. д., неизбежно встает вопрос об автоматизации классифицирования, индексирования и аннотирования всех этих богатств. Опять-таки Microsoft разрабатывает технологию снабжения цифровых изображений метаданными...
P.S.. Возможно, эти или похожие идеи уже высказывались здесь (или где-то еще) мной (или кем-то еще) или даже уже реализованы. Однако показалось интересным обобщих их в одном месте.