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

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

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

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

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

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

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

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

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

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

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