Много лет тому назад я работал в [...]]]> Я тут почитал обсуждения вокруг моего прошлого поста по работе с регулярными выражениями и упоминания про FPGA и не только и вспомнился мне мой личный опыт по работе с FPGA и вообще решением сложных задач. К тому же NDA у меня давно уже истёк так что можно рассказывать.

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

Как бы то ни было вероятно я и выглядел как наиболее незагруженный сотрудник поскольку когда возникла задача по приёмке и тестированию специально FPGS-девайса я и оказался тем кому это поручили.

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

а. Преобразовать картинку отпечатка пальцев в специальную модель.

б. Проводить нечёткое сравнение одной модели с другими.

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

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

Девайс этот был разработан и передан нам в отдел качества в формате «надо принять». А то есть было понятно что он как-то работает, но разработка извне никак не курировалась, документации было минимум, никаких тесткейсов и так далее.

Собственно что это было. Это был действительно мощный компьютер со встроенным Linux’ом с огромным числом спец-процессоров в которые заливалась специальная прошивка с алгоритмом, а далее заливались модели отпечатков пальцев, вплоть до миллиона отпечатков. Далее в девайс должны были отправлять отдельные отпечатки на сравнение и он возвращал ID’шники отпечатков ранее в него загруженных прогоняя задачу через все процессоры. Девайс был реально ОЧЕНЬ БЫСТРЫМ то есть возникни задача загрузить в него миллион настоящих отпечатков, то он мог бы в проводить аутентификацию по новым в течении нескольких секунд.  Те кто сталкивался с подобными задачами знают насколько это непросто.

Однако, были и свою нюансы и с избытком. Первый и ключевой нюанс в том что девайс работал через TCP/IP где у него был специальный демон через который загружались прошивки, модели отпечатков и модели на аутентификацию. Этот демон работал асинхронно, работать с ним было реально непросто и многих возможностей нехватало.

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

Кроме того девайс был один, а его необходимо было одновременно тестировать и одновременно разработчикам с ним работать для создания над ним программной обёртки.

И что делать? Особенно что делать мне как человеку весьма ленивому, а тут не не до лени — надо бы заставить эту штуку работать хоть как-то. Кроме того разработчиков тоже больше одного и у них тоже конфликты кто и как с устройством работает.

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

Однако мою идею в том что можно использовать кластер из моих «эмуляторов» вместо одного FPGA-устройства тогда не поддержали. Увы и ах, а было бы интересно если бы было по другому.

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

Лично я тогда приобрёл опыт в том что некоторые решения могут быть весьма некрасивыми, но объективно необходимыми и действенными. И каким-бы ни был тот самый FPGA-девайс с точки зрения его сопровождения, он был одним из немногих способных решать такие задачи.

А тем временем, на днях, представители Яндекса выложили в открытый доступ ряд open source проектов — http://clubs.ya.ru/company/replies.xml?item_no=30753

Самый интересный из которых, на мой взгляд — это PIRE, https://github.com/dprokoptsev/pire Perl Incompatible Regular Expressions Library.

Весьма интересная штука для тех кто когда либо прогонял через шаблоны [...]]]> Что-то давно я не писал про технологии и алгоритмы.

А тем временем, на днях, представители Яндекса выложили в открытый доступ ряд open source проектов — http://clubs.ya.ru/company/replies.xml?item_no=30753

Самый интересный из которых, на мой взгляд — это PIRE, https://github.com/dprokoptsev/pire Perl Incompatible Regular Expressions Library.

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

Как я понимаю авторы обещают производительность до 400MB в секунду на «common hardware», конечно, с кучей ограничений по тому что в регулярных выражениях может быть, но тем не менее — это быстро. Жаль там нет враппера для Питона, я бы попробовал на своих данных, благо их у меня накопилось много и есть с чем сравнивать. Пока поверю авторам на слово и исхожу из того что это так и есть, благо подход описанный у них в документации вполне понятен и должен работать.

Однако, жаль что подобных открытых разработок небыло хотя бы пары лет назад. Когда я разрабатывал Скиур — http://www.skyur.ru (это такой сервис по преобразованию веб-страниц в RSS), то решал задачи для которых как раз были необходимы такие инструменты  поскольку частью алгоритма является большое число тогда ещё регулярных выражений. В совокупности чуть менее 200, точно не скажу поскольку происходит их сборка из некого базового набора.

Но не имея таких инструментов я пошёл другим путём с решением «в лоб», также оказавшего эффективным.

1. Все регулярные выражения были заменены на конечные автоматы

2. Собственно автоматы проанализированы и разбиты на повторяющиеся блоки.

3. Окончательная сборка шаблонов производится из группы базовых автоматов с добавлением к ним дополнительных блоков по набору правил.

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

То есть, фактически, это путь эффективен только в случае:

a.  Управляемости входного потока выражений.

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

Лично я нашёл что PyParsing - http://pyparsing.wikispaces.com при соблюдении описанных выше действий обеспечивает ускорение сравнения по сравнению с регулярными выражениями в разы. Собственно он и является весьма удобным конструктором.

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

Теперь Gridworks называется Google Refine и доступно по другому адресу https://code.google.com/p/google-refine/

Gridworks, а теперь Google Refine — это один из мощнейших и инструментов по очистке данных. Ему можно на вход подать данные в CSV формате и далее различными [...]]]> Для тех кто может быть ещё не знает Google купили компанию Metaweb — создателей FreeBase и Gridworks.

Теперь Gridworks называется Google Refine и доступно по другому адресу https://code.google.com/p/google-refine/

Gridworks, а теперь Google Refine — это один из мощнейших и инструментов по очистке данных. Ему можно на вход подать данные в CSV формате и далее различными способами перетасовывать колонки, фильтровать, обогащать, формировать производные колонки с помощью встроенных интерпретаторов Jython и GEL.

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

Помимо того что он автор книги Web Data Mining http://www.cs.uic.edu/~liub/WebMiningBook.html где охватывает почти все темы, но [...]]]> Хотя на сайте MS Research много интересных материалов, но, на самом деле отправной точкой во всём что касается извлечения информации из веб-сайтов, классификации, аннотирования и так далее — это страничка профессора Bing Liu http://www.cs.uic.edu/~liub/ из Института Иллинойса Чикаго.

Помимо того что он автор книги Web Data Mining http://www.cs.uic.edu/~liub/WebMiningBook.html где охватывает почти все темы, но у него же на сайте есть обучающий курс по Data Mining and Text Mining http://www.cs.uic.edu/~liub/teach/cs583-fall-10/cs583.html где как раз очень много материалов или ссылок на материалы других исследователей по структуре веб-сайтов.

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

Практических примеров, правда, не так много как хотелось бы. Мне понравилась идея с автоматическим анализом форм поиска билетов через сервисы бронирования для создания одной общей формы через которую идёт поиск по всем (более 5) сервисам.

Некоторые интересные и очевидные мысли которые я в его презентациях разглядел:

• данные в Веб сильно зашумлены и алгоритмы по автоматическому анализу должны уметь от этого шума избавляться
• большая часть данных в Веб представлена фиксированным набором способов её представления — шаблонами в виде HTML тэгов
• для выявления повторяющихся объектов на странице нужна их топологизация, формирование шаблонов в виде последовательностей полей и меток
• для определения структуры сайта можно использовать tree edit distance используя DOM как дерево
• главные проблемы работы с врапперами в их сопровождении и повторном обучении. В ответах на вопросы: как определить что враппер не работает? как его автоматически починить? должно ли переобучение менять текущий враппер или создавать новый?

Плюс, там же интересные материалы по тому как именно производится тематическая классификация веб-сайтов/веб-страниц.

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

Правда явно делают акцент на анализе форумов и других дискуссионных площадок, что в [...]]]> Оказывается в Microsoft Research есть проект Website Structure Understanding and It’s applications с весьма впечатляющей коллекцией материалов по этой теме.

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

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

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

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

Я же пытался зайти со стороны предварительной классификации сайта целиком, идентификации CMS, выявлению микро-признаков с «переупаковкой» структуры веб-страницы из DOM в специального рода таблицы.

Если бы я в последние годы не увлёкся проектами в области общественного блага (РосГосЗатраты, Открытые данные), то пожалуй самое интересное это было бы закончить исследования в этой области. Так что читаю такие материалы не без лёгкой белой зависти потому как очень увлекательно.

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

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

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

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

Предыстория этого текста исключительно практическая, поскольку я очень много с данными работаю, то [...]]]> Какое-то время назад я эту тему поднимал в посте «Распознавание национальности по имени» — http://ivbeg.livejournal.com/119528.html

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

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

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

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

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

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

Шаблоны

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

Этих элементов немного и их можно перечислить:

s — Фамилия (surname)

f — Личное имя (first name)

m — Отчество (midname)

S — Однобуквенная запись фамилии

F — Однобуквенная запись имени

M — Обнобуквенная запись отчества.

Далее при анализе ФИО я буду исходить из того что ФИО — это не только фамилия, имя и отчество, но в реальной жизни это гораздо большее число форм написания того же.

При этом у использования этих элементов есть свои особенности в частности есть устоявшиеся сочетания в которых они присутствуют. Далее я приведу перечень шаблонов для определения этих сочетаний:

sfm — Фамилия, имя и отчество. Например, Пилипенко Мария Геннадьевна

fms — Имя, Отчество, Фамилия. Например, Александр Аронович Хромов

sFM — Фамилия и по первой букве от имени и отчества. Например, Васильев И. И. или Минниханов Р Е

FMs — первые буквы от имени и отчества и фамилия полностью. Пример: А. Ю. Макаренко, Н.Г. Буранов

sfM — фамилия и имя полностью и первая буква от отчества. Примеры: Ефимов Борис А., Карманова Мария В.

Fs — Первая буква имени и фамилия. Например, А. Румянцев или В Ручкин .

sF — фамилия полностью и первая буква от имени. Примеры: Борисов Г., Рахмонова Е.

s — только фамилия. Например: Хазанов, Минниханов, Дудкина, Малых

fs  - имя, фамилия. Например: Арут Карапетян, Борис Рыбин

sf — фамилия, имя. Например: Климов Максим, Мирных Алексей, Дудяк Елена

fm — имя, отчество. Например: Иван Петрович, Василий Аркадьевич, Рахиль Альбертовна

f — личное имя. Примеры: Иван, Петр, Алексей, Равиль, Аслан и т.д.

SFM — по первой букве от фамилии, имени, отчества. Примеры: В.Р.Е, Е.Н.М.

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

Правила разбора ФИО

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

Прежде чем определять пол персоны или этнос важно разложить ФИО на элементы и для этой цели необходимо определить каким шаблоном ФИО написано. Как это сделать?

1. Вначале разбить ФИО на элементы исходя из того что разделителями могут выступать пробелы и точки.

2. Определяется количество частей после чего идёт ветвление на проверку по шаблонам. Если 1 часть (1 слово) — то шаблон s или f. Если две части, то sf, fm, fs, sF или Fs

3. Для ФИО из 3-х частей проводится простая проверка не состоят ли какие-либо части из одной буквы. Если да и более двух, то быстро определяются такие шаблоны как SFM, sFM и FMs

4. Далее как определить какая из частей каким типом элементов является. Есть два способа и их комбинация.

Способ 1. Базы имён, фамилий и отчеств

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

Способ 2. Регулярные выражения

Для отчеств — окончания на -вич и -вна. Для фамилий выражений больше. Например, таки как: ^(.*)(о|е|ё)в$, ^(.*)швили$ и так далее, несколько десятков.  А также есть набор выражений для имён, но там всё несколько сложнее и это отдельная тема.

Для каждого из выражений может быть сопоставление его с полом или этнической группой.

Способ 3. Использование баз и выражений совместно

Если запись находится в базе — исходить их признаков в базе, если нет — применять разметку регулярным выражением.

-

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

6. В конечном итоге результатом являются:

- выявленный формат шаблона

- размеченные элементы (фамилия, имя, отчество)

А также, или все имеющиеся или один производный признак пола и, при возможности определения, этноса.

Или же возврат,  и производного, и всех признаков. Об особенностях определения признаков в следующем пункте.

Особенности

Все было бы очень просто если бы не некоторые особенности которые важно помнить и учитывать.

1. Есть множество случаев когда пол определить невозможно даже определив шаблон и отдельные элементы. Связано это не с несовершенством методов проверки, а с тем что далеко не всегда информация о поле содержится в ФИО. Вот несколько примеров: Малых А.А. — имя и отчество присутствуют только в виде первых букв, а фамилия Малых является универсальной и может принадлежать, как женщине, так и мужчине. Точно также с фамилиями на -ко, -их и множестве других. Фактически во всех случаях шаблонов sFM, FMs, Fs, sF и s у нас недостаточно элементов несущих информацию и определение ограничено имеющейся информацией. В виду этого результатом метода по определению пола по ФИО могут быть 4 варианта ответа: женский, мужской, универсальный и неизвестно.

2. Есть множество региональной специфики в том что касается написания имён и отчеств. В частности в  азербайжанских казахских ФИО часто присутствует «Оглы» или «Кызы». Например, Асланов Ази Ахад оглы

3. Много специфики в именах используемых в национальных республиках России и бывшем СССР. Точность распознавания будет зависеть от наличия датасетов по регионам.

4. Описанный подход не охватывает случаи намерянных и случайных искажений. Например, когда вместо точки используют запятую или указывают ФИО вроде «Гадя Петрович Хренова». А также случаи с опечатками — это несколько более сложная, но не сверхсложная задача.

5. Определения этноса задача сложная, в первую очередь, в виду значительных объёмов классифицируемой информации. Фактически её можно разделить на принципы определения различных этнических особенностей в ФИО разных народов. Например, окончания фамилий на «-ян» у армян или «-дзе» и «-швили» у грузин. А также на основе баз имён разных народов.  Однако есть много случаев когда определить этнос сложно поскольку имя может указывать лишь на то из какого языка оно происходит. А в некоторых случаях имена могут иметь множественное значение. Например имя Артур — весьма популярно среди армян и это армянское имя переводящееся как «свет истины» и одновременно это нередкое современное имя в России среди русских.

Примеры

Собственно всё вышеперечисленное какое-то время я реализовал довольно давно в виде довольно простого закрытого веб-сервиса который на входе кушает текст, а на выходе выдаёт JSON с результатами. Работает это всё настолько просто назвать это алгоритмом у меня язык не поворачивается — просто «полезная штука», ничего более.

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

Текст: Бегтин И.В.

Разбор в формате JSON:

{‘format’: ‘sFM’, ‘gender’: ‘m’, ‘sn’: u’Бегтин’, ‘fn_s’: u’И’, ‘text’: u’Бегтин И.В.’, ‘mn_s’: u’В’, ‘parsed’: True}

Текст: Иван Викторович Бегтин

Разбор в формате JSON:

{‘format’: ‘fms’, ‘gender’: u’m', ‘mn’: u’Викторович’, ‘sn’: u’Бегтин’, ‘text’: u’Бегтин Иван Викторович’, ‘parsed’: True, ‘fn’: u’Иван’}

Где: fn — имя, sn — фамилия, mn — отчество, fn_s — первая буква имени, format — выявленный формат описания ФИО, parsed — флаг что формат был определён, gender — пол в виде одного из признаков m, f, u и «-» если определение пола не прошло.

Нет только признаков этноса, поскольку сейчас они присутствуют только для имён

Статистика

В качестве небольшого дополнения приведу некоторые статистические наблюдения.

Для проверки точности я взял небольшой массив примерно в  5 600 000 неуникальных записей из публичных официальных документов. А то есть с частыми повторениями одного и того же ФИО, но в разных формах. Например: где-то упоминается: Кудрявцев Е.В., где-то Кудрявцев Евгений, где-то Кудрявцев Евгений Викторович и так далее.

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

Фактически можно увидеть что при 4 основных написания — sfm, sFM, FMs и fms лидируют по частоте встречаемости. Но, как я упоминал ранее, здесь есть специфика в официальности. Если же анализировать другие массивы, то распределение шаблонов по популярности будет иным.

В качестве резюме

В общем-то разбор ФИО — это довольно простой пример на уровне «систематизации очевидного». Куда сложнее задачи по разбору адресов или, например, товарных позиций. Но ничего неразрешимого нет при условии последовательного упрощения и шаблонизации форматов представления, иногда многоуровневой.

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

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

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

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

PubSubHub — это инициатива Брэда Фицпатрика с открытой спецификаций и открытым исходным кодом http://code.google.com/p/pubsubhubbub/. Где главная идея [...]]]> На 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 не начнут включать поддержку одного из них в свои продукты по умолчанию, на большинстве сайтов мы их так и не увидим.

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

А вот его полное описание —
There is a vast amount of data available today and data is now being collected and stored at a rate [...]]]>
Оказывается 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 должны быть инструкции и разъяснения как именно надо публиковать информацию.