Иван Бегтин

Появился исходный код Gridworks – http://code.google.com/p/freebase-gridworks/ , а также всяческие интересные примеры там же, в Wiki проекта. Этой такой инструмент по очистке и преобразованию данных сделанный внутри Metaweb’а, компании разработчика проекта Freebase.

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

Багу я им уже зарегистрировал, но сколько ждать придётся неизвестно.

Какое-то время назад я эту тему поднимал в посте «Распознавание национальности по имени» – http://ivbeg.livejournal.com/119528.html

Но там было нечто вроде результатов экспериментов, сейчас же затрону тему систематизации того как можно обрабатывать ФИО и какую информацию можно на основе ФИО извлечь.

Предыстория этого текста исключительно практическая, поскольку я очень много с данными работаю, то периодически возникают задачи по тому как обогатить, улучшить, извлечь и отклассифицировать данные.  Так, например, анализ  ФИО даёт возможность  добавить как минимум 2 новых среза – гендерный и этнический (более правильное название определения национальности).

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

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

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

В случае ФИО, начало систематизации начинается с шаблонов.

Continue reading «Систематизация распознавания пола и этноса по ФИО»

Шаг-за шагом объектные и безсхемные базы данных превращаются из экзотики в нечто общепринятое.

На nosql-database.org обнаружилась большая подборка ссылок и материалов по этой теме.

Лично я нашёл там для себя много нового и теперь знаю какие есть альтернативы уже используемого мной MongoDB.

На мой взгляд самые интересные это:

• Инфогрид – http://infogrid.org/
• HyperGraphDb – http://www.kobrix.com/hgdb.jsp
• LightCloud – http://opensource.plurk.com/LightCloud/

Но, в принципе, это интересная тенденция. Даже глаза разбегаются что лучше выбрать и использовать.

На TechCrunch почти год назад была пара интересных статей RSS is dying и Speeding up RSS.

В первой рассказывается про то как Twitter вытесняет RSS из повседневного использования, а вторая про протоколы PubSubHub и SUP.

PubSubHub – это инициатива Брэда Фицпатрика с открытой спецификаций и открытым исходным кодом http://code.google.com/p/pubsubhubbub/. Где главная идея в том создатели RSS лент регистрируют их на одном из PubSubHub сервисов и далее пингуют сервисы при обновлении своих лент, а хабы мультикастом распространяют контент по всем подписчикам. Конечно, в такой схеме нужно чтобы клиент мог принимать новые сообщения и такие клиенты появляются, их список можно посмотреть здесь – http://code.google.com/p/pubsubhubbub/wiki/SubscriberClients
Однако изменения нужны, и на сервере, и на клиенте, и необходим внешний сервис.

SUP (Simple Update Protocol) – это протокол разработанный для FriendFeed. Также с открытой спецификацией и исходным кодом доступными здесь http://code.google.com/p/simpleupdateprotocol/
Он очень просто устроен и отличается тем что никак не специфицирует работу клиентов, а описывает механизм публикации при котором в новостные ленты сайта добавляются указания на ленту SUP где с заданной периодичностью указываются те новостные ленты где произошли изменения. Тем самым, в случае если с одного ресурса извлекается более одной RSS ленты, то число обращений можно существенно ограничить. А также за счёт того что в заголовках HTTP ответов указывается текущий статус RSS ленты, то и существенно сократить число выгрузок лент.

Лично мне оба подхода в равной степени нравятся/не нравятся. На мой взгляд они вполне равновесны.
Однако они не решают другой большой и сложной задачи которая заключается в том что же делать когда вероятность что разработчики сайтов добавят поддержку одного из протоколов очень невлика. И это, в общем-то, обыденная ситуация если вспомнить что не все сайты до сих пор поддерживают технологию RSS. А если говорить про наиболее интересующую меня категорию веб-сайтов, то до 80% из них RSS не отдают.

И вот вопрос как быть в этом случае?
Свои размышления по этому поводу я собрал в виде нескольких тезисов:
1. В зависимости от характера решаемых задач подход может быть различным. Главный критерий здесь – ожидаемый интервал оперативности в получении новостной информации и это может определять стратегии сбора информации. К примеру, если новости собранные за сутки используются лишь для дайджеста
2. У подавляющего числа RSS лент есть свои «временные паттерны». Которые можно охарактеризовать как периоды времени активности в данной RSS ленте. В большинстве случаев эти временные паттерны напрямую завязаны на суточный цикл дня и ночи привязанный к источнику этих данных и недельный/календарный цикл с учётом падения активности в выходные и праздничные дни. Разумеется в случаях когда речь идёт «естественных» новостных лентах формируемых людьми, а не ботами. При выявлении характеристик этих циклов могут быть определены интервалы опроса источников информации. Это может позволить соблюсти баланс между использованием ресурсов и частотой обновления.
3. Некоторые сервера честно возвращают даты фактического обновления в «Last Modified», некоторые отдают заголовок «ETag» и чаще отдают информацию о размере страницы/ленты. При наличии этой информации её можно использовать для сокращения числа GET запросов. Правда, при этом сразу возникают другие особенности – в том необходимо убедится в том что информация в заголовках от сервера корректна. Например, несколько раз я сталкивался с тем что возвращалось неверное значение ETag, в том что «Last Modified» возвращает корректные значения также необходимо убеждаться, равно как и есть определённые риски в использовании «Content-Length» для принятия решения об обновлении или необновлении RSS ленты.

Минусы этих подходов – необходимости предварительного сбора накопления информации перед тем как выбирать правильную стратегию опроса RSS лент. И, конечно, универсальным решением это не является, в отличии от SUP’а и PubSubHub. Правда, подозреваю что до тех пор пока разработчики CMS не начнут включать поддержку одного из них в свои продукты по умолчанию, на большинстве сайтов мы их так и не увидим.

Оказывается Microsoft сделали и предложили протокол OData – Open Data Protocol используемый для раскрытия данных в машиночитаемой форме.

Подробнее можно почитать здесь http://www.odata.org

А вот его полное описание –
There is a vast amount of data available today and data is now being collected and stored at a rate never seen before. Much, if not most, of this data however is locked into specific applications or formats and difficult to access or to integrate into new uses. Public data is often unfortunately held private or needlessly buried behind random, inefficient, and cumbersome interfaces.

The Open Data Protocol (OData) provides a way to unlock your data and free it from silos that exist in applications today, making it easy for data to be shared in a manner that follows the philosophy of Open Data. OData enables a new level of data integration and interoperability across a broad range of clients, servers, services, and tools.

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

А я тем временем всё больше понимаю что на OpenGovData.ru должны быть инструкции и разъяснения как именно надо публиковать информацию.

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

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

Пока я могу рассказать как сбором и анализом данных для алгоритмов занимаюсь я. Собственно ничего сложного в этом нет:

- у меня есть специально написанная система и пол-сервера на Amazon’е которая используется с единственной целью находить извлекать информацию с веб-сайтов. При этом извлечение происходит на нескольких уровнях: HTTP заголовки, meta информация HTML, скрипты, ссылки на изображения, любые ссылки, стилевые страницы и статистику по использованию тэгов их иерархии и структуре. В совокупности там хранится порядка 100 000 веб-страниц, в основном главных «морд» сайтов в виде нескольких выборок от 10 000 до 25 000 тысяч страниц.

Continue reading «Анализ веб-страниц, выявление новостей и не только»

Что радует, у Microsoft появляется всё больше более чем интересных проектов и, если абстрагироваться от провала Висты и нынешнего давления на покупателя чтобы переходили на W7, то есть о чём любопытном упомянуть:

• Codename Dallas  - http://pinpoint.microsoft.com/en-US/Dallas. Проект/сервис для поддержки разработчиков желающих распространять и использовать большие массивы данных. Включает как бесплатные так и платные данные в большом количестве.
• Microsoft Academic Search – http://academic.research.microsoft.com. Поисковик по научным работам в разных областях науки, в основном, околокомпьютерных. Мне понравилось наличие разных полезных срезов – по журналам и конференциям
• eGov 2.0 kit – http://egov.codeplex.com/. Движок на базе Sharepoint’а по построению сайтов для eGov. При том что мне не особо нравится реализация, сама идея довольно разумна – CMS или полуфабрикат для госсайтов.
• EntityCube – http://entitycube.research.microsoft.com/. Проект по выявлению «именованных сущностей», различных осмысленных фактов о персонах и организациях. На мой взгляд он тесно пересекается идеологически и информационно с Powerset’ом купленным Microsoft недавно и интересно как дальше будут развиваться события. Будут ли их объединять в гибрид, например.

Кстати в Research  же занимаются ещё одной наработкой/небольшой библиотекой – Site Analyzer  http://research.microsoft.com/en-us/downloads/58e8953e-3626-4994-bf95-19039e978223/default.aspx

Проектом это назвать рановато, но возможность структурировать веб-страницы форумов, определять шаблоны URL’ов туда уже закладывается. А это уже ровно то же самое чем я занимаюсь, только подходы разные.

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

Кстати, для анализа HTML в Site Analyzer’е свой парсер который кроме обычной информации об элементе DOM-дерева фиксирует поля о его глубине, числе потомков и так далее. Я знал, я знал что не один я об этом ломал голову, что приятно.

Я тут постепенно отлаживаю свои алгоритмы построения «объектных карт сайтов». Постепенно – поскольку приходится учитывать сотни разных параметров и заниматься микроклассификацией.  Что весьма увлекательно и в равной степени рутинно. Часть алгоритма – это определение CMS сайта для анализа его ссылочной структуры. Собственно главным является определение ссылочной структуры, а знание CMS в этом предполагается что помогает.

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

В результате  по тестовой выборке в 25 000 сайтов на 10% сайтов определяется CMS одна из 40 возможных по которым работает алгоритм и на 30% различные сервисы парковки которые, с некоторой натяжкой, тоже можно рассматривать как подвид CMS.

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

А вот то о чём я ранее писал, алгоритм определения коммерческой направленности ресурса наконец-то готов. Его смысл не в тематической классификации, а в ответе да/нет на простой вопрос «Сайт коммерческий?».

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

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

Итого Рунет можно классифицировать:

• по структуре
• по тематике
• по коммерциализованности
• по геометкам

И каждый из этих срезов по своему интересен.

Недавно обнаружил в блоге у Mencius Moldbug довольно интересное мнение про Wolfram Alpha. Жаль не прочитал его ранее, там есть целый ряд интересных мыслей.

Но, пожалуй, одна из самых интересных в предсказуемости результатов в WA. Фактически он назsвает Wolfram Alpha – «control interface» и сравнивает с Google который таким не является поскольку результат выдачи Google не предопределён.

Это как со школьным и многим другим навязанным образованием – отсутствует в WA разнообразие мнений, несколько точек зрения и, фактически, Wolfram Alpha сейчас это такой особо умный словарь / энциклопедия где вся разница с классическими энциклопедиями в том что в WA гораздо больше источников информации.

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

Кстати, ещё одно интересное наблюдение на сайте Wolfram Alpha нет упоминаний про Semantic Web, онтологии и так далее, хотя, на самом деле, там данные из Semantic Web и Linked Data используются и внутри есть онтология.

Причина проста, RDF, SPARQL, OWL, Semantic Web и прочая – это всё довольно сложные технологии для даже для подготовленного пользователя. Так порог вхождения для изучения SQL и SPARQL довольно существенен и многие проекты используют свои, сильно упрощённые языки запросов чтобы минимизировать заведомую сложность.

Но причина не только в этом. Для построения подавляющего большинства частных коммерческих задач использование RDF или Triple Store – это оверкилл и более простые и дешёвые решения подходят лучше. Иначе говоря для проектов на базе Sematic Web до сих пор нет рынка и тем более его нет в России и большой вопрос будет ли.

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

P.S. Постоянно сталкиваюсь с тем что когда путают «семантические технологии» и «семантический веб». Первое – это, по сути, мат. лингвистика и анализ текстов, к RDF и онтологиям имеет слабое отношение.

Недавно наткнулся на чрезвычайно интересное исследование – TLDR: Interfaces for large-scale online discussion spaces.

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

Причём с помощью ряда алгоритмов определяется где идёт аргументированная дискуссия, где троллинг и какими являются оценки – позитивными или негативными.

В качестве примеров там приводятся дискуссии на Reddit и видео веб-интерфейса с визуализацией результатов анализа включая несколько паттернов – продолжительной дискуссии и успешного троллинга.

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

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