Например, вот такой документ МинЭкономРазвития (ссылка на документ со сканами страниц) можно найти через поиск — например, вот так и щелкнув на ссылку «просмотреть» переходим в Google Docs где ещё одним [...]]]> Сегодня обнаружил интересное явление. Оказывается Гугл научился автоматически индексировать PDF файлы содержащие отсканированные страницы документов. Соответственно эти документы теперь находятся через поиск.

Например, вот такой документ МинЭкономРазвития (ссылка на документ со сканами страниц) можно найти через поиск — например, вот так и щелкнув на ссылку «просмотреть» переходим в Google Docs где ещё одним щелчком на «Обычный формат HTML» документ возвращается в виде текста.

В общем, Google нашли себе ещё один большой срез данных. Осталось лишь дождаться когда поисковик начнет заглядывать в архивы, распознавать текст и объекты на картинках и так далее.

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

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

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

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

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

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

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

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

При преобразовании HTML в RSS, как, например, это происходит в Скиуре, очень часта ситуация когда структура данных меняется. Это может быть из-за того что немного подкрутили верстку или, к примеру, у новости появилась метка которая при обучении на данных сайта не [...]]]> Прежде чем продолжить рассуждения, а что же такое данные с нечеткой структурой? Начну с примера.

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

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

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

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

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

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

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

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

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

Например, лично я считаю что рассматривая регулярные выражения с целью их индексирования необходимо забыть про DFA и NFA и не вспоминать столь долго сколь это только возможно.

Для [...]]]> Задача которую я затрагивал в предыдущем посте, конечно, решаема и даже понятно как её решать, вопрос лишь во времени и в оценке достаточности решения для решаемых задач.

Например, лично я считаю что рассматривая регулярные выражения с целью их индексирования необходимо забыть про DFA и NFA и не вспоминать столь долго сколь это только возможно.

Для анализа должно быть достаточно развёртывания регулярных выражений как дерева в соответствии с их написанием и последовательное построение «шаблонов шаблонов», которые, как окажется, будут состоять из вполне измеримых «микроблоков правил». Причём каждый из этих микроблоков будет обладать собственным набором метрик. Итоговое дерево выражения будет состоять из ветвей непосредственно правил подвергнутых группировке и кластеризации и рассчитанных ветвей метрик для каждого. При этом несмотря на то что хранение этих метрик может оказаться накладным процессом, тем не менее эти объёмы будут несравнимо меньше чем объёмы «распакованных» NFA.

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

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

На самом деле жаль что её так никто и не решил. В моём понимании моделирование алгоритмов анализа дерева HTML и прочих полуструктурированных данных куда увлекательнее чем моделирование алгоритмов анализа деревьев RE. Но пока получается что эта нерешённая задача, тормозит решение остальных.

Нового там мало, основной акцент на правильной подачи собственного контента.

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

Кстати, [...]]]> Гугл опубликовали у себя в блоге 22 страничный PDF документ с рекомендациями по оптимизации сайтов под поисковые системы.

Нового там мало, основной акцент на правильной подачи собственного контента.

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

Кстати, многие из этих правил поддаются формализации и значительной автоматизации в рамках CMS систем.

Например, организация поиска по собственному сайту с помощью внешнего поисковика требует хоть и не слишком многих, но всё же усилий и хотя бы небольшого понимания HTML. Да и многие просто ленятся [...]]]> Что меня удивляло и продолжает удивлять так это так это нерасторопность поисковых машин, за исключением Google,  в продвижении своих сервисов везде где только возможно.

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

Вот я и не могу понять что мешает поисковым машинам:

1. Спонсировать разработчиков open-source CMS для поддержки поиска по внешней системы «из коробки».

2. Договариваться с разработчиками коммерческих CMS а ля 1С-Битрикс для поддержки внешнего поиска из коробки или же опционально.

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

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

Вначале озвучу проблему: подавляющее число информационных систем никак не учитывают формы представления информации которую они предоставляют пользователям и не только им.

Рассмотрим несколько [...]]]> Относительно недавно, размышляя над антипаттернами юзабилити, там же я упоминал про такое явление как сдвиге идентификаторов элементов веб списках. Это довольно большая тема сама по себе и я раскрою её подробнее.

Вначале озвучу проблему: подавляющее число информационных систем никак не учитывают формы представления информации которую они предоставляют пользователям и не только им.

Рассмотрим несколько примеров.

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

Для того чтобы далее было проще описать ситуацию я введу термин LISA (Last In. Shift All) -построение списка элементов при котором любой новый элемент становится первым сдвигает номера остальных.

Предположим, у нас уже есть 100 опубликованных новостей, 10 страниц по 10 новостей на одной странице. Что произойдёт после того как мы добавим ещё одну новость? Появится 11 страница и полностью изменится содержимое всех остальных 10 поскольку добавленная новость сдвинет все предыдущие на одну позицию в отсортированном списке.

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

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

Примеров таких списков более чем множество. Даже Вордпресс на котором работает мой блог нумерует страницы считая последнюю первой.

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

Возьмём другой пример — каталог организаций рассортированных в алфавитном порядке по имени. Организаций обычно бывает много, пусть у нас их будет порядка 2000 по 25 на странице, всего 80 страниц. Что происходит когда добавляется новая организация — технически, в базу попадает просто новая запись, но форма представления меняется таким образом что новая запись сдвигает все последующие за ней ровно на единицу и число сдвинутых записей зависит от имени новой. Такие формы списков можно назвать LISP (Last in. Shift part). Тем самым получая новый элемент списка мы можем предсказать каким будет сдвиг списка в целом, но мы не можем предсказать какой же элемент мы получим и как придётся сдвигать, не зная содержимого элемента. Понятно также что это распространяется не только для списков с алфавитной сортировкой по именам, а ко всем постраничным спискам с сортировкой отличающейся от сортировки по последнему идентификатору или по последней дате. В этом случае поисковые машины при повторном индексировании будут обходить уже не все страницы, а только затронутые сдвигом. На уникальность ссылки для пользователей влияние также будет зависеть от того как именно элемент сдвигает все остальные.

Надо отдать должное что в случае LISP списков, некоторые ресурсы предпринимают дополнительные усилия по по организации работы с ними. Например, список печатных СМИ на сайте Федерального агенства по печати и массовым коммуникациям отличается двойной сортировкой. На первом уровне записи рассортированы по первым буквам названий и лишь на втором они разбиты постранично в рамках выбранной буквы. Если, к примеру,  добавлять новое СМИ, то изменится не более чем страниц под определённую букву, это от 1 до 10 страниц, но не никак не несколько сотен.

Почему это вообще важно? Причины в проблемах для поисковиков и пользователях что я озвучил выше.

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

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