Работа с данными с нечеткой структурой

Прежде чем продолжить рассуждения, а что же такое данные с нечеткой структурой? Начну с примера.

При преобразовании HTML в RSS, как, например, это происходит в Скиуре, очень часта ситуация когда структура данных меняется. Это может быть из-за того что немного подкрутили верстку или, к примеру, у новости появилась метка которая при обучении на данных сайта не встречалась, но была с самого начала предусмотрена, например, «новое» или ещё что-либо не являющееся сменой CMS или реорганизацией структуры сайта, но затрагивающее HTML структуру ленты новостей.

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

  • более долгий процесс извлечения структурных блоков;
  • невозможность ручной корректировки шаблона распознавания в виду его отсутствия.

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

В случае новостной информации — это довольно просто и даже очень просто, поскольку структура транслируемых новостей давно уже определена в спецификациях RSS/ATOM, и то при распознавании достаточно 10% от специфицированных полей.  Кроме того отслеживание структурных аномалий для частного случая — это однократная и решаемая задача. Поиск решения для новостной информации закодированной в HTML у меня занял пару месяцев — в основном на анализ и систематизацию структуры данных в источниках. 

А вот в случае условно неограниченного числа данных различных по структуре, форме размещения/публикации, способу хранения и так далее, ситуация отличается в корне. Без автоматизации процесса распознавания, без формализации поиска отклонений в структуре данных, без совмещения динамического формирования шаблонов с шаблонами уже накопленными — решить эту задачу невозможно. Фактически полноценное решение требует системы близкой по логике к ETL, но отличной в том что в отличии от ETL источники данных там не фиксированы, структуры данных могут меняться, новые источники могут добавляться даже при неполном описании приходящих из них данных, а все ошибки в обработке яляются не предметом приостановки процесса импорта или игнорирования, а обучения.  При этом, разумеется, необходимы специальные методы распознавания структур данных, решение проблемы производительности использования больших баз регулярных выражений и так далее.  

К вопросу о том зачем всё это нужно? Это нужно, поскольку сейчас процесс организации данных в Linked Data и иных связанных машиночитаемых формах — весьма долгосрочен. В каждом случае — это связано с долгим ожиданием когда владелец/контролёр источника данных решит представлять его в более удобной форме. При том что есть множество энтузиастов которые могут оцифровать тот или иной срез данных — как, например, статистические данные США или России, в машиночитаемую форму — тем не менее систематизация источников данных позволит обеспечить доступность данных на потоковой основе. 

Или, говоря иначе, ненужно ждать пока государство начнёт отдавать данные в RDF или же общедоступные данные станут доступными в виде микроформатов или тех или иных срезов — необходимо создавать механизмы и программные продукты автоматизирующие процесс преобразования данных из Legacy форм в формы пригодные к последующей интеграции. 

Всё это к вопрос о том как лично я вижу data.gov.ru  примерно через пару лет, разумеется, в случае его появления.

About This Author

  • http://shcherbak.net SHCHERBAK

    Не буду обращать внимание на то, что пост опубликован первого апреля. И считаю, что содержимое поста не шутка.

    то что необходимо распознавать структуру это однозначно полезно, но на сегодняшний день если посмотреть на OCR-системы(например) тот же Finereader весьма и весьма неплохо распознает структуру любой таблицы(даже с разрушенной структурой). и поверьте возможная реализация их алгоритма в online -сервисе позволит распознавать таблицы в PDF и других бинарных форматах с очень высокой точностью. А для структурного анализа текстовых форматов с целью выявления табличных данных существует десятка 2 алгоритмов. о некоторых из которых можно почитать в онлайн. Только была бы в них необходимость…

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

    Что касается «Поиска решения для новостной информации закодированной в HTML» здесь есть много неоднозначностей, что приводит к невозможности создания унифицированного решения, то есть автомат нельзя создать для всех случаев +особенно если вы вручную не указываете какая конкретно таблица из веб-страницы содержит новости (и где собственно границы семантически значимой таблицы).
    а для каких случаев у вас работает автомат я не увидел. Еще проблема (а где то ж помню находил статистику на 2004 год) 52% сайтов интернета использует табличную верстку. то есть таблицы в таблицах. проанализировать это можно а вот проинтепретировать практически нельзя. Конечно на онтологиях есть решение, но тоже с ограничениями. еще хотел сказать когда табличные данные проанализированы, их нужно проинтепретировать, даже в терминах RSS, т.е нужно установить семантическое соответствие между элементами таблицы и терминами предметной области или RSS. Это сложно и практически невозможно так как в структуре семантики нет.
    В таблицах, и даже в таблицах HTML построенных с использованием Simple Table Model или Complex Table Model, средств выражения семантики практически нет, а учитывая то, что в большинстве случаев даже те средства что есть не используются. Сами понимаете, что будет получатся в результате анализа.
    Чесно говоря, если бы семантический интерпретатор таблиц был бы создан, то наверное как раз и не важно было бы в RDF данные представлены или в таблицах, потому что мапинг всегда можно было бы сделать при необходимости))

    С целями разработки заявленныз в посте средств согласен. Тем более вероятно в Linked Data семантика менее важна чем в Semantic Web, но без возможности интерпретации цена этим структурированным данным не велика.

  • http://ivan.begtin.name ivbeg

    Под нечеткой структурой я имел, в первую очередь, не изменчивость в статическом массиве данных, а изменчивость с течением времени. Например, для веб сайтов характерно то что время от времени структура их веб страниц меняется и нельзя на 100% положится на сформированные шаблоны при длительной обработке информации. Термин «нечёткая структура», пожалуй, действительно не лучший, но пока не могу подобрать более верного.

    В том что касается табличной верстки и вообще таблиц, на самом деле ситуация не столь безыходна что нельзя делать, в том числе и в автоматическом режиме, гипотезы по структуре сайта и далее их проверять.
    К примеру, мой алгоритм превращения новостных блоков в RSS вообще не учитывает специфики таблиц. Фактически, он выполняет лишь довольно простые логически и сложные алгоритмически действия по поиску повторяющихся блоков, отделения от этих блоков дат и заголовка, далее, огрублённая группировка всех нераспознанных участков в поле description в RSS.

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

    Анализ табличных данных — это, имхо, несколько другая история. Для классификации потребуются довольно длительные усилия по классификации типов полей, правил кластеризации и так далее. Я интересовался немного этой темой в целях анализа и классификации структуры таблиц для последующего ручного связывания её полей с RDF или иными спецификациями, но простого решения найти не удалось. Впрочем не могу сказать что посвятил много времени именно этой теме.

  • http://shcherbak.net SHCHERBAK

    Тогда думаю название по лучше будет — данные с динамически изменяемой структурой.
    А то нечеткие данные это уж совсем не то. Даже динамически изменяемые данные это по вашему контексту будет не то…
    Насчет безысходности — некоторые классы табличных структур не поддаются автоматической интерпретации и распознаванию… поэтому я и говорю несколько в таком печальном тоне. Уж что-то а с этими классами я достаточно долго работал.

Яндекс.Метрика