Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, a_b_orlov, Вы писали:


__>>Кроме того, дать возможность классифицировать весь текст по категориям, задаваемым пользователем. Это даст возможность, как полнотекстового поиска, так и быстрого поиска по ключевым словам.
S>Хм, ты не мог бы пояснить, что ты понимаешь под классификацией по категориям?

Посмотри как сделано в Outlook. Любой объект там можно описать категориями (так прямо и называется "категория"). Можешь выбрать из списка, добавить в список или написать все руками. Категории выносишь в отдельную таблицу, вяжешь ее с текстами N:N и индексируешь по тексту. По категориям нужен поиск на точное совпадение для скорости работы. При такой организации можно сделать что-то вроде окошка Dynamic Help в VS. К стати, можно посмотреть как MS решает задачу мгновенного поиска в MSDN из VS по контексту.

__>>Сценарий работы пользователя примерно такой: создается дело с четкой атрибутикой (дата, номер …). К нему цепляются эти самые тексты. Прямо в процессе ввода текста — поиск по ключевым словам, которые пользователь выделяет в тексте.
S>Я это прямо так себе это представляю: рраз правой кнопкой на выделенном — а там менюшечка "Пометить как >" и тут подменю со списком атрибутов. Вот только атрибутов-то у нас может быть очень много... Надо как-то показать наиболее вероятные.

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


__>>В качестве поисковой машины следует использовать что-то вроде Яндекса.
S>Т.е. Fulltext. Хм. Интересная идея, но имхо не очень реалистичная. Потому как доступный для использования полнотекстовик плохо работает с "ключевыми словами".
так любой SQL зато отлично справится с поиском по индексированному текстовому полю символов в 100.

__>>Кроме того, если Ваш клиент милиция (прокуратура, таможня…) или выходцы из нее, то Вы столкнетесь еще и с ужасающей безграмотностью. Поэтому в качестве основного инструмента предлагаю использовать уже знакомый им Word со встроенной проверкой грамотности.
S>Вот это ты в самую точку угадал! Spellchecker был отдельной строкой потребован в ТЗ с самого начала!

А главное, что все уже есть в MS Word!

Здравствуйте, Sinclair, Вы писали:

__>>Кроме того, дать возможность классифицировать весь текст по категориям, задаваемым пользователем. Это даст возможность, как полнотекстового поиска, так и быстрого поиска по ключевым словам.
S>Хм, ты не мог бы пояснить, что ты понимаешь под классификацией по категориям?

Как я понимаю: розовые штаны -> одежда, тел. 222222 -> номер телефона и т.п.

__>>Сценарий работы пользователя примерно такой: создается дело с четкой атрибутикой (дата, номер …). К нему цепляются эти самые тексты. Прямо в процессе ввода текста — поиск по ключевым словам, которые пользователь выделяет в тексте.
S>Я это прямо так себе это представляю: рраз правой кнопкой на выделенном — а там менюшечка "Пометить как >" и тут подменю со списком атрибутов. Вот только атрибутов-то у нас может быть очень много... Надо как-то показать наиболее вероятные.

По идее с существительными все просто, либо связь штаны -> одежда в системе есть, либо ее нет. Если есть, то в списке "пометить как" появляется только одно слово — "одежда". Если существительных в выделенном куске несколько, то показываем пользователю варианты для каждого существительного и он уже выбирает то, что ему нужно. Прилагательные классифицировать пожалуй сложно, но можно применять их к обобщающему понятию, т.е. если имеются "розовые штаны", то ищутся не только они, но и "розовая одежда". Если в словочетании присутствует произвольный набор цифр и букв, то, во-первых, это номер, во-вторых, возможно конкретный номер, т.е. номер банкноты, номер телефона, номер счета и т.д. С глаголами по-идее нужен список синонимов, т.е. чтобы система понимала, что "зарезал", "убил", "застрелил" и т.д. это все одно и тоже. Хотя тут проблема в том, что нужно по-крайней мере два списка синонимов: 1. по результату действия (убил, ограбил, украл и т.д.), второе по самому действию, т.е. система должна также понимать, что зарезал, ударил ножом и т.п. это одно и тоже действие.

Здравствуйте, s.ts, Вы писали:

ST>Здравствуйте, bkat, Вы писали:

ST>А какие тогда ключевые слова для поиска ?

Поищи по словам "metamodel ontology"

ST>Поиск по "создание экспертных систем" дает только ссылки на существующие системы.

На самом деле сейчас это не является специфическим именно для экспертных систем.
Там это могут применяют, но эдин один из способов описания очень сложных
предметных областей и данных в них. Но понятно, что такие задачи стоят не только перед
создателями ЭС. Потому лучше искать именно по словам "метамодель и онтология".

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, a_b_orlov, Вы писали:

...
__>>В качестве поисковой машины следует использовать что-то вроде Яндекса.
S>Т.е. Fulltext. Хм. Интересная идея, но имхо не очень реалистичная. Потому как доступный для использования полнотекстовик плохо работает с "ключевыми словами".

Вот эта штука с ними будет работать прекрасно

...
__>>Кроме того, если Ваш клиент милиция (прокуратура, таможня…) или выходцы из нее, то Вы столкнетесь еще и с ужасающей безграмотностью. Поэтому в качестве основного инструмента предлагаю использовать уже знакомый им Word со встроенной проверкой грамотности.
S>Вот это ты в самую точку угадал! Spellchecker был отдельной строкой потребован в ТЗ с самого начала!

Я бы не стал связываться с Вордом из-за спеллчекера. Проще взять сторонний спеллчекер благо их полно, в том числе и бесплатных. Я напрмер в свое время брал вот это

Здравствуйте, EM, Вы писали:


EM>Я бы не стал связываться с Вордом из-за спеллчекера. Проще взять сторонний спеллчекер благо их полно, в том числе и бесплатных. Я напрмер в свое время брал вот это

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

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, a_b_orlov, Вы писали:

S>Т.е. Fulltext. Хм. Интересная идея, но имхо не очень реалистичная. Потому как доступный для использования полнотекстовик плохо работает с "ключевыми словами".
Вообще существует целый класс программ называемых автоматический классификатор. Когда-то давно попадала одна из них ко мне, по моему сделанная на основе нейросети со всеми вытекающими последствиями, то есть жутко тормозная, и долгая процедура обучения. Поэтому тогда (года 3-4 назад) от него отказались. Тема не заглохла, сделал поиск в www.yandex.ru "автоматический классификатор", несколько выдал сразу. Возможно, они спасут отца демократии.
С уважением, Gleb

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, Sinclair, Вы писали:

S>>Здравствуйте, a_b_orlov, Вы писали:

S>>Т.е. Fulltext. Хм. Интересная идея, но имхо не очень реалистичная. Потому как доступный для использования полнотекстовик плохо работает с "ключевыми словами".
GZ>Вообще существует целый класс программ называемых автоматический классификатор. Когда-то давно попадала одна из них ко мне, по моему сделанная на основе нейросети со всеми вытекающими последствиями, то есть жутко тормозная, и долгая процедура обучения. Поэтому тогда (года 3-4 назад) от него отказались. Тема не заглохла, сделал поиск в www.yandex.ru "автоматический классификатор", несколько выдал сразу. Возможно, они спасут отца демократии.
GZ>С уважением, Gleb


Я имел отношение к разработке такого классификатора и, помнится, основная проблема там не в тормозах и скорости обучения а том, что он плохо классифицирует короткие документы т.к. для них он не может составить достоверный семантический образ. Тоесть это хорошая штука для раскладывания резюме, но плохая для расладывания например почты.
Еще стоит добавить что "хороший" результат для автоматической классификации это ~ 60/70% попаданий, так что не думаю, что это хорошее решение для системы, о которой идет речь

Здравствуйте, Sinclair, Вы писали:

S>[...]

Имхо, реальный положительный эффект от этой системы появится, в лучшем случае, только через несколько месяцев (скорее лет), после начала её внедрения. Чтобы заработал продвинутый поиск по ключевым позициям, сначала нужно набить то, по чему искать, хоть какую-то базу данных.
Представляю себя на месте среднего следователя. Какой смысл ему напрягаться, выделять в документах самые ценные поля, тыкать пальцем по клавиатуре, пытаясь ввести их в систему, и всё это в надежде, что потом, при соответствующем усердии остальных следователей города/области/страны, может быть получить какие-то полезные возможности по розыску...
Гораздо проще накопить все эти несчастные бумажки. В конце месяца отсканировать их и все скопом, не разбираясь, загнать в базу.
Результат понятен.

Я бы вообще сейчас не стал заморачиваться с этими продвинутыми возможностями поиска.
Лучше сфокусироваться на более достижимых целях: просто автоматизация внутреннего документооборота органов внутренних дела (та ещё задачка), интеграция его с другими государственными системами (ты вроде про это что-то вскользь говорил) — это сейчас самое главное. Ещё файнридер сюда прикрутить не помешает.

А потом, через N лет, когда всё заработает, можно будет и об ЭС подумать...

Здравствуйте, Sinclair, Вы писали:

Первое, что я стараюсь делать сначала, это смотреть программы конкурентов.
Понравилась одна статья: здесь. Но дороговато получится.

S>Начинаем проектировать. Ага, сущностей-то — всего ничего: дело, персона, улика, да прочий материал.

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

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

S>А главное — не факт, что это надо!
S>С точки зрения п.2, фиксация любой структуры — это
S>а) наличие нуднейшей формы, в которой большинство полей не заполняются никогда
S>б) нехватка полей для ввода какой-то информации, которую мы не предусмотрели.
Генерация новых справочников на лету, ничего страшного. Будет несколько нелепый GUI (универсальные view никогда красивыми не бывают (или бывают только на тестовых данных)).
Например:
1. Пользователь ввел в поле "Улика" — нож
2. Пользователь открыл (ему стала виден) справочник аттрибутов улики типа нож
3. Пользователь ввел в поле Ручка — каменная
4. Пользователь добавил новое свойство лезвие
5. Пользователь нажал на кнопку открыть свойства от свойства лезвие
6. Сгенерировался новый тип "Лезвие"(создался справочник, произведены изменения в метамодели)
7. Пользователю открылся (ему стала виден) справочник свойства Лезвие
У тебя всегда остается нормальная древовидная метамодель.

S>Таким образом, возникает острое желание заменить это моделью, в которой с любым объектом можно проассоциировать любые именованные атрибуты. Атрибут соответственно может быть либо скаляром, либо вектором. При этом скаляр может быть значением, а может быть и ссылкой.
S>В общем, чистый джаваскрипт.

S>Однако смущает меня три вопроса:
S>1. Как нам приделать к этому персистенс? Не будет ли "однотабличная" модель, в которой свалены все кусочки данных (objectID, attributeName, attributeValue), слишком медленной?
Будет, лучше тип-таблица (или класс-набор таблиц, тогда снизишь границы поиска).
S>2. Как насчет пункта 3?
S>В идеале, система должна выводить "все преступления с таким же почерком". На практике, надо искать
S>а) похожих людей (сходство по любому атрибуту)
S>б) похожие места (в смысле адреса)
S>в) похожие улики (типа поддельный чек выписанный на тот же банк, или там еще что)
S>Вот мне и интересно, есть ли опыт практического решения подобных задач для слабоструктурированных данных (окромя как за.кинуть вообще все в full-text engine, а дальше нехай враги разбираются)
Самый дешевый вариант. Все зависит от ресурсов.
S>3. Как быть с пунктом 4? Статистика вроде хорошо ездит по структурированным данным, а как быть со слабоструктурированными — я что-то даже не соображу.
В каждый момент времени, существует вполне понятная метамодель, которая изменяется только в сторону увеличения. Используем генератор отчетов.

Вообще это самая дешевая модель.

Ключевая проблема — поиск. В зависимости от того как ты ее решишь, будет вытекать остальные пункты.

S>Да, очень близко. К сожалению, иначе как рекламой IBM Content Manager эту статью не назовешь.
Ну реклама — и Бог с ней
Может действительно стоит посмотреть вокруг — вдруг есть что-то уже подобное, сделанное... Потриалить да и купить, если подойдет. В этом случае, конечно, меняется задача — не разрабокта, но внедрение... Ну а кто говорил, что будет легко?

Подобная задача была решена коллегами на Lotus Domino. Сделано было для страховой компании — что-то типа рабочей среды для экспертов при расследовании страховых случаев (компания страховала объекты недвижимости и строительство). Lotus Domino — масштабируемый, готовый полнотекстовый поиск, поиск-индексация аттачментов, синхронизация серверов и рабочих станций (у экспертов были ноутбуки). По-моему было сделано одним человеком за 1-2 месяца.

Здравствуйте, <Аноним>, Вы писали:

А>Подобная задача была решена коллегами на Lotus Domino. Сделано было для страховой компании — что-то типа рабочей среды для экспертов при расследовании страховых случаев (компания страховала объекты недвижимости и строительство). Lotus Domino — масштабируемый, готовый полнотекстовый поиск, поиск-индексация аттачментов, синхронизация серверов и рабочих станций (у экспертов были ноутбуки). По-моему было сделано одним человеком за 1-2 месяца.
Ага. У наших заказчиков, как я понял, уже стоит солюшн на базе Lotus Domino. Теперь они заказывают нам новое решение
Мотивация:

· Lack unified data services and customized workflow.
· There is no integration with either internal or external data sources, such as thirdpart
databases or internal databases like customer
database.
· Inferior Search Technology and lack of real time look-ups prevent efficient cross
case correlation of crucial evidence.
· Pre-set reports lack meaningful details and reports contain errors.
· Inability to store pertinent information and documents such as Check Images,
Security Video and Interviews.
· Poorly designed User Data Entry Areas lead to cumbersome and unnecessary,
time consuming activities.
· Simple, yet highly beneficial tools do not function (such as Spell Check).
· Personal Management Tools (Calendaring and Tasking) are non-existent or do
not integrate with existing PIM systems.
· Lack Real Time Management Reporting.
· No workflow efficiency.

S>· Lack unified data services and customized workflow.
S>· There is no integration with either internal or external data sources, such as thirdpart
S>databases or internal databases like customer
S>database.
S>· Inferior Search Technology and lack of real time look-ups prevent efficient cross
S>case correlation of crucial evidence.
S>· Pre-set reports lack meaningful details and reports contain errors.
S>· Inability to store pertinent information and documents such as Check Images,
S>Security Video and Interviews.
S>· Poorly designed User Data Entry Areas lead to cumbersome and unnecessary,
S>time consuming activities.
S>· Simple, yet highly beneficial tools do not function (such as Spell Check).
S>· Personal Management Tools (Calendaring and Tasking) are non-existent or do
S>not integrate with existing PIM systems.
S>· Lack Real Time Management Reporting.
S>· No workflow efficiency.

похоже на аудит любой криво сделанной на коленке стажером системы.

"There is no integration with either internal or external data sources" — очень странно, что IBM-овский продукт не имеет никаких возможностей, кроме того Lotus умеет работать с webservices, а любой современный продукт имеет webservices интерфейс.

всё остальное — свойства типичной кривой системы, сделанной консалтинговой компанией, и на данном проекте не было ни одного человека, прилично разбирающемся в задаче

Здравствуйте, mihhon, Вы писали:

M>похоже на аудит любой криво сделанной на коленке стажером системы.
Похоже.
M>"There is no integration with either internal or external data sources" — очень странно, что IBM-овский продукт не имеет никаких возможностей, кроме того Lotus умеет работать с webservices, а любой современный продукт имеет webservices интерфейс.
Я не думаю, что IBM хоть что-то знает про тот продукт, который используется у заказчика.
M>всё остальное — свойства типичной кривой системы, сделанной консалтинговой компанией, и на данном проекте не было ни одного человека, прилично разбирающемся в задаче
Ну, мне отсюда плохо видно, был ли у них человек, разбирающийся в задаче Но теперь разобраться во всем надо мне.

M>>"There is no integration with either internal or external data sources" — очень странно, что IBM-овский продукт не имеет никаких возможностей, кроме того Lotus умеет работать с webservices, а любой современный продукт имеет webservices интерфейс.
S>Я не думаю, что IBM хоть что-то знает про тот продукт, который используется у заказчика.

говоря об IBM я имел в виду Lotus www.ibm.com/lotus

Л>Относительно неструктурированности: в CM есть понятие ItemType это фактически класс, прежде чем создавать экземпляры ты декларируешь структуру этого класса. После того как создан хотябы один экземпляр класса (ItemType'а) ты можешь только добавить новый атрибут и больше ничего ...
Л>Вся метаинформация храниться в DB2 ...

А насколько хорошо сделан поиск по данным? Есть ли возможность поиска по картинкам?

Здравствуйте, cvoronin, Вы писали:

C>А насколько хорошо сделан поиск по данным? Есть ли возможность поиска по картинкам?
Смотря какой поиск ты имеешь ввиду?
Мне известны два рабочих варианта:
1. Сканируешь образы документов (Aidis, Fine Reader, Kofax и др.), ну а затем заливаешь это всё в CM — это тот самый полнотекстовый
2. В Эрмитаже на CM смогли навесить поиск изображений по палитре красок ...

Здравствуйте, Sinclair, Вы писали:

А>>Подобная задача была решена коллегами на Lotus Domino. Сделано было для страховой компании — что-то типа рабочей среды для экспертов при расследовании страховых случаев (компания страховала объекты недвижимости и строительство). Lotus Domino — масштабируемый, готовый полнотекстовый поиск, поиск-индексация аттачментов, синхронизация серверов и рабочих станций (у экспертов были ноутбуки). По-моему было сделано одним человеком за 1-2 месяца.
S>Ага. У наших заказчиков, как я понял, уже стоит солюшн на базе Lotus Domino. Теперь они заказывают нам новое решение

S>· Lack unified data services and customized workflow.
В Lotus Notes есть соответсвующий продукт Lotus WorkFlow? Это если твой workflow достаточно "продвинутый"!
S>· There is no integration with either internal or external data sources, such as thirdpart
S>databases or internal databases like customer
В Lotus Notes есть две родные технологии (тулсы): Data Connections и DECS. Причём обе работают с ODBC и нативными библиотеками в случае не Win'дов!
S>database.
S>· Pre-set reports lack meaningful details and reports contain errors.
Ну это косяк програмеров, в Lotus'е само хранилище не реляционное? а скорее — документоориентированное. Тоесть некаких констраинов, primary/foreign ключей и т.п. Соответсвенно проектировать структуру данных нужно изходя из этого.
А отчёты это уже дело техники!
Lotus это Наследие mainframe'ов и тяжёлых машин
S>· Inability to store pertinent information and documents such as Check Images,
S>Security Video and Interviews.
Понятия составных документов, как таковых, нет! ... это факт!
S>· Simple, yet highly beneficial tools do not function (such as Spell Check).
Вот этого нет! Хотя я ещё не видел "изврашенцев" которые работали во встроеных редакторах Lotus, обычно тексты набираются в Word'е а уже затем прикрепляются к Lotus документам.
S>· Personal Management Tools (Calendaring and Tasking) are non-existent or do
S>not integrate with existing PIM systems.
В Lotus своя система PIM. Впринципе аналог MS Outlook.
S>· Lack Real Time Management Reporting.

S>· No workflow efficiency.
Это см. выше.

P.S. Я вообще не сторонник Lotus Notes, хотя и приходилось писать на нём приклад ... Я бы оценил платформу как — "специфическую".
P.S.S. Lotus, на МОЙ взгляд, не очень предназначен для задачи которую описывает Sinclair ...

Здравствуйте, Sinclair, Вы писали:

Отвечу только по пункту 3...

S>3. Могучая поисковая енжина. С таким интеллектом, чтобы пользоваться ей мог даже сержант ГИБДД. Ну типа повводили мы данных, а система нам и говорит "ага, мои любезные, хочу вам подсказать, что аналогичный случай имел место в городе Одесса. В связи с чем рекомендую обратить внимание на...". Причем не только не требуя от пользователя нудного указания условий поиска, а лучше и вообще безо всякой инициативы.

S>2. Как насчет пункта 3?
S>В идеале, система должна выводить "все преступления с таким же почерком". На практике, надо искать
S>а) похожих людей (сходство по любому атрибуту)
S>б) похожие места (в смысле адреса)
S>в) похожие улики (типа поддельный чек выписанный на тот же банк, или там еще что)
S>Вот мне и интересно, есть ли опыт практического решения подобных задач для слабоструктурированных данных (окромя как за.кинуть вообще все в full-text engine, а дальше нехай враги разбираются)

Во-первых, ИМХО, стоит разделить ввод данных (поступление данных в систему) и использование данных (поиск и т.п.). Мало того, я бы предусмотрел между этими группами use-cases ещё слой подготовки и преобразования данных (т.е. перевод их из сырого состояние в агрегатное и подготовленное к поиску). Этот слой, возможно, решит часть проблем, поскольку отвяжет вас от необходимости на одних структурах данных решать несколько перпендикулярных задач.

Что касается поиска, то помимо поиска по параметрам, который обязательно должен быть (по номеру дела и т.п), можно добавить ещё несколько механизмов поиска:
— поиск по контексту, а-ля Яндекс (с учётом морфологии). Это достаточно стандартный механизм, но к нему надо будет предусмотреть подготовку данных;
— поиск по смыслу. Это отдельная тема, которую я и хочу упомянуть.

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

— вводишь фразу "Президент России посетил Украину"
— получаешь документ с текстом "В.В.Путин — деловая поездка по странам СНГ"

У таких систем, как правило, есть серверная часть (довольно простая в использовании) и API, позволяющее подключиться к серверу откуда угодно, что позволяет встраивать эту поисковую машину в любые GUI. Данные же в сервер (а точнее индексы со ссылками на источник, например, на базу данных и конкретную запись) могут попадать в автоматическом режиме через большое количество так называемых коннекторов, которые присасываются как к БД, так и к другим хранилищам документов, включая даже Интернет.

Сам я возился в своё время с продуктом компании Autonomy.

Штука не сложная, хотя достаточно дорогостоящая. Писал на основе Authonomy тесты (минипоисковую систему). В качестве источников брал как данные из разных баз данных, так и N-ое количество сайтов из Интернет. Причём по сути не важно, с каким языком эта система работает (мы, для теста, взяли тогда набор документов в транслите и искали по транслиту — работало). С русским, разумеется, тоже работало.

В общем работало.

Думаю, что аналогичные по принципу системы сейчас есть (IBM чего-то в этом направлении делало да и MS тоже)...

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

Если интересно, могу ответить на вопросы подробнее (если будут )

Л>Смотря какой поиск ты имеешь ввиду?
Л>Мне известны два рабочих варианта:
Л>1. Сканируешь образы документов (Aidis, Fine Reader, Kofax и др.), ну а затем заливаешь это всё в CM — это тот самый полнотекстовый
Л>2. В Эрмитаже на CM смогли навесить поиск изображений по палитре красок ...

А как-раз полнотекстовой. Но, насколько я понял, работает он с отсканированными и с распознанными документами?
Сможет ли он, например, среди отсканированных авиабилетов найти"все билеты, выданные на имя Саддам Хуссейн". И неужели он (СМ, не Хуссейн) и по-русски искать сможет? Да со словоформами с разными...

Кстати, знаете новую неполиткорректную сказку? "Старик Хоттабыч". Как-там у него полное имя? Хассан Абурахман ибн Хаттаб