Проблема работы с неструктурированными данными

Не так давно читая материалы по Apache UIMA (Unstructured Information Management applications) я удивлялся зачем нужно такое переусложнение? Да и форма подачи документации UIMA, простоты не подразумевает, для любых частных задач проще создать частный анализатор и использовать его, а UIMA — это большая и сложная система. Разработки из IBM в принципе, по моим ощущением, простыми бывают редко, но интересными очень часто, а то что они передали UIMA в Apache — повышает вероятность его востребованности.

И сейчас по результатам чтения большего числа материалов я начинаю понимать зачем такая сложность нужно и, хотя, подход в UIMA мне лично не нравится, но по крайней мере он понятен. Это попытка построения универсального решения для обработки и аннотирования текста.

Так, я всё более убеждаюсь что правило классификации и местоположение артефакта по которому классификация производится также являются метаданными обязательными к сохранению и последующему анализу. Здесь, конечно, мы приходим к тому что алгоритмы (цепочки правил) также должны подчинятся определённой онтологии и точка принятия решения при в дереве решения должна сохранятся.

Одна из проблем в том что есть ощутимая разница в анализе текста и полу-структурированных данных (PDF, документов MSWord, HTML и так далее), которая затрудняет классификацию поскольку, в некоторых случаях, структура является не контейнером данных, но и обладает рядом характеристик дополняющих модель распознавания. Выявление таблиц из PDF — один из наглядных примеров. Так, в большинстве случаев, анализ любых полуструктурированных текстов сопряжён с потерей метаданных поскольку API для работы с HTML, PDF и другими форматы абсолютно не адаптированы для глубокого анализа и, для повышения производительности, метки местоположения и связанных данных установить крайне непросто. В свою очередь промежуточное преобразование сопряжено со значительным расходом времени и ресурсов (процессорное время, память, постоянное хранилище).

Но дело не только в этом. У метаданных есть своя иерархия и различные области применения, а также есть контекст и области применения. И, что хуже всего, начисто отсутствуют более-менее пригодные инструменты для работы. За исключением CouchDb и аналогичных column-based баз данных — крайне непросто уложить метаданные в общую модель и ещё сложнее с ними работать.

Иерархия метаданных и сами классификационные правила приводят к тому что без построения базовой системы классификаторов — модели метаданных и НСИ, последующая классификация скатывается до узких / частных решений. В свою очередь построение этой онтологической модели — это задача нетривиальная и до сих пор никем полностью не решённая. Ранее я сетовал на подобную ситуацию в области компьютерной лингвистики, но, справедливости ради надо сказать что это не только там. Постепенное наполнение коллективной копилки знаний в виде ВикиПедии, крупных проектов по построении — медицинских справочников, ДНК и других на основе Semantic Web и OWL, медленно, но верно меняет эту ситуацию, но медленно.

В итоге, как не подходи к этой задаче, любое универсальное решение требует очень глубокого анализа форм и характера данных. Цена этого перфекционизма: усложнение и резкое снижение производительности. Но… Мы всё ещё живём в мире, где неизвестны потенциальные пределы процессорных мощностей, зато возможно оценить пределы информации. Пока же вопрос в выборе решения в существующей ситуации и серебрянной пули пока не видно.

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