Об особенностях направленного сбора информации

Я ранее не раз поднимал вопрос о направленном индексировании здесь: http://ivan.begtin.name/2008/10/14/направленное-индексирование-и-верти/ и здесь http://ivan.begtin.name/2009/04/08/информационная-архитектура-наоборот/

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

Предположим есть группа сайтов с которых необхдимо собрать некую информацию. К примеру, пройтись по сайтам всех периодических печатных и собрать с них: код ISIN, ФИО главного редактора, адрес редакции и реквизитов ИНН/КПП/ОГРН если они доступны. Например, это может быть нужно для задачи обогащения информации — составления полного списка сайтов и сопоставления его с базой номеров ISIN.

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

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

Технологическое же решение состоит из решения следующих подзадач:

1. Определить носитель информации — искомый сайт

2. Найти на сайте контейнер

3. Определить форму контейнера

4. Разобрать контейнер и извлечь из него необходимые данные

Подробнее по каждой подзадаче:

1. Определить носитель информации

Прежде чем информацию извлечь необходимо найти сайт где она присутствует. И здесь изначальная постановка задачи может варьироваться в рамках одного из 3-х случаев:

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

В первом случае всё очень просто. Искать сайт ненужно, он заранее известен.

Во втором случае задача сводится в сопоставлению известного текста с искомым сайтом. Здесь помогают каталоги сайтов и API поисковых систем.

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

2. Найти на сайте контейнер

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

3. Определить форму контейнера

В условиях когда на 100 процентов неизвестно как именно представлена информация, но есть понимание (и реализация понимания) в том как обычно она представляется, то определение формы контейнера заключается в том чтобы понять как эта информация представлена — таблицей, списком, разбросана по странице и так далее и тому подобное.

4. Разобрать контейнер и извлечь из него данные

Финальная часть когда контейнер найден извлечь из него информацию. Осуществляется это HTML парсером или разбором найденного файла — в зависимости от ситуации.

—

А теперь собственно нюансы реализации. Главное то что практически все эти задачи дробятся ещё более простым:

• для того чтобы найти контейнер информации есть два основных подходов: определение контейнера по его типу и по ключевым меткам. Оба этих случая требуют понимания навигационной структуры сайта — где главная страница, где страница описания, страница контактов и так далее. Определение навигационной структуры сводится к двум алгоритмам:
  • определения навигационных меню сайта — главного и вспомогательных
  • классификация внутренних ссылок сайта
• в свою очередь вопрос классификации внутренних ссылок требует понимания их структурной модели. Ответов на вопросы: используются ли человекочитаемые ссылки, каков уровень вложенности, как навигацию где страницы подгружаются через GET запросы и так далее. В результате алгоритм классификации внутренних ссылок работает гораздо эффективнее при определении этой структурной модели. Определить её возможно как динамически, накоплением базы внутренних ссылок сайта, так и определением CMS сайта.
• определение формы контейнера упирается также в две подзадачи:
  • локализация значимого участка страницы — блока в HTML где содержатся искомые данные
  • определение формы представления данных в этом блоке.
• локализация значимого участка может быть осуществлена несколькими способами: по ключевым навигационным и стилевым меткам в разметке страницы, по выявлению значащего блока страницы путём последовательного сравнения и анализа нескольких других страниц сайта и определение блоков с изменяющимся содержимым и по ключевым меткам в тексте, например, поиском по ключевым словам и регулярным выражениям в тех случаях когда известна ключевая информация о метках.
• определение формы представления данных это то что уже необходимо превратить из неструктурированного блока информации в структурированное описание. Я именно про это писал ранее неоднократно про то есть конечное число способов представления информации и вполне можно их определять как в контексте, так и вне его. Неполный перечень форм это: таблица, несколько таблиц, различные одностраничные списки,  многостраничные списки, неформатированный текст.

Зачем всё это нужно?

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

Ну и могу сказать что решением как раз этой задачи я и занимаюсь.