Куда же девать вычислительные мощности?
Как известно, параметры сегодняшних ПК, даже начального уровня, намного превосходят потребности библиотек, даже максимальные. Зачем, например, винчестер на 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.. Возможно, эти или похожие идеи уже высказывались здесь (или где-то еще) мной (или кем-то еще) или даже уже реализованы. Однако показалось интересным обобщих их в одном месте.

X) Автоматическое определение релевантности
…как известно, в «поисковиках» релевантность определяется, мягко говоря, очень своеобразно — как часто в документе встречается данное слово или фраза, что вызывает множество нелепиц и допускает множество махинаций.
Очевидно, что она должна определяться по совокупности признаков: заглавиям, по всему лингвистическому обеспечению (если оно имеется), далее — по предисловиям, аннотациям, рефератам, заключениям, выводам, оглавлениям… и только в последнюю очередь и при отсутствии всего вышеперечисленного – по часто повторяющимся словам. А если речь идет о «бумажных» документах, не обойтись без сканирования и распознавания – если статьи, то всего текста, если книги – «выборочных участков».
Y) Мультимедийный интерфейс пользователя, прежде всего для детских библиотек: выбор цветов, стилей, «тем», вариантов оформления (“skins”), трехмерные анимационные «помощники», текстовые, графические, видео- и аудиофрагменты произведений, отраженных в каталоге.

Вообще насколько сегодня важна скорость (быстродействие), в частности, при поиске, чем во время оно особо гордился Вислый? и отчего она зависит больше? От типа СУБД?
Скорость работы, вообще говоря, не является основной причиной использования реляционных СУБД. Более того, первые реляционные базы работали медленнее своих предшественников. Выбор этой технологии был вызван скорее
- возможностью возложить поддержку целостности данных на СУБД;
- независимостью логической структуры данных от физической.
[...]
Таким образом, прежде, чем искать ответ на вопрос «как заставить РСУБД работать быстрее в моей задаче?» следует ответить на вопрос «нет ли более подходящего средства для решения моей задачи, чем РСУБД?» Работа с PostgreSQL: настройка и масштабирование. А.Ю.Васильев
А какие быстрее (если это еще важно)? Не встречал таких упоминаний, например, об иерархических.

irbis_arbat@mail.ru



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