Некоторые повторяются так что я отвечу на часть из них тут и объясню как работает проект.

1. Ключевая особенность ГосСети от любых каталогов веб-сайтов. Мы вначале создаём карточку госструктуры к которой сайт относится и лишь потом добавляем сайт. И ни один из сайтов не добавляется без такой [...]]]> Вчера пришло очень много вопросов, писем и комментариев.

Некоторые повторяются так что я отвечу на часть из них тут и объясню как работает проект.

1. Ключевая особенность ГосСети от любых каталогов веб-сайтов. Мы вначале создаём карточку госструктуры к которой сайт относится и лишь потом добавляем сайт. И ни один из сайтов не добавляется без такой привязки. В свою очередь органы власти имеют привязку к региону, ветви власти, виду структуры и так далее.

2. Данные в Госсеть вносятся двумя способами — автоматически и вручную. Например, автоматически вносились территориальные подразделения ФАС, Казначейства, управления ГИБДД и многие другие. В то же время, например, данные о сайтах проектов органов власти, ФЦП, сайтов закупок и большая часть региональных сайтов вносятся вручную.

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

4. Информация о CMS, Счетчиках, хостингах, геолокации, данных валидации по W3C собирается полностью автоматически.  Собственно какое-то время назад я писал у себя в блоге что результатом всех моих исследований Рунета является сервис аналогичный BuiltWith.com с той лишь разницей что он непубличен, а работает в режиме веб-сервиса. Собственно ГосСеть — это его первая публичная апробация.

5. ГосСеть — это долгосрочный проект и, как я уже писал ранее, это фундамент на основе которого могут быть построены и другие проекты и сервисы нацеленные на общественное благо. Те из Вас кто знают про проекты по открытым данным от New York Times и британской Guardian поймут о чём речь. Конечно, тема открытых данных в России пока ещё вызревает, но тема открытости государства уже горячая

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

7. Проект с самого начала нацелен на партнёрство со всеми заинтересованными сторонами. И если у Вас есть конкретные предложения, например, публикации своих рейтингов, исследований, лучших практик, получения данных, предоставления данных и так далее — пишите на ibegtin (собака) gmail.com .

И немного статистики.

На 08.06.2010 в Госсети есть:

• 2453 госучреждения
• 30 видов госучреждений
• 1808 веб-сайтов
• 11 видов веб-сайтов
• 94 региона
• 19 нормативно-правовых документов
• 195 - видов признаков выявляемых с госсайтов: CMS, хостинг и т.д.
• 19973 — выявленных признаков на госсайтах

SPDY — это протокол расширяющий и дополняющий HTTP таким образом чтобы убрать из него все неоднозначности, вроде того что статус в ответе описан иначе чем остальные поля и сжатие запросов и ответов и так далее.  Подробнее можно прочитать [...]]]> В Arstechnica появилась хорошая статья про SPDY^eng — протокол ускорения загрузки веб-страниц который предлагают иccледователи из Google.

SPDY — это протокол расширяющий и дополняющий HTTP таким образом чтобы убрать из него все неоднозначности, вроде того что статус в ответе описан иначе чем остальные поля и сжатие запросов и ответов и так далее.  Подробнее можно прочитать здесь — http://dev.chromium.org/spdy

При том что действительно, тема интересная важная и так далее, а Google при его массе и скорости может эту идею даже протолкнуть, на самом деле всё несколько сложнее. Собственно в статье в Arstecnica это изложено:

1. Сейчас SPDY работает только поверх сессий SSL что во-первых ограничивает кеширование данных, а во вторых не повлияет на то что большая часть контента в публичной части сети доступно не по SSL, и в третьих использование SSL априори создаёт дополнительную нагрузку на ресурсы клиента и сервера что также ограничивает применимость.

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

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

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

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

Вместо этого можно поступить так:

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

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

3. Предложить механизмы, программы, продукты и так далее кеширования отдельных участков веб страниц и интегрировать эту информацию на уровне HTTP протокола. То есть создать возможность при запросе веб-страницы или любого иного документа с комплексным содержимым возвращать не один ETag код, а несколько хэшей/идентификаторов блоков, но не более 20 блоков. Далее с помощью расширения к HTTP запрашивать о том не изменились ли отдельные или все блоки и в результате получать не всю страницу или подтверждения что она не менялась, а статус частично изменено и данные только изменившихся блоков склейка которых происходит уже на клиенте.

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

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

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

В первый день в Нижнем Новгороде меня более всего впечатлили 3 доклада:

Недавно у меня перед глазами такой пример образовался — обновился официальный сайт закупок Воронежской области, http://zakaz.gfu.vrn.ru

Точнее вместо старого сайта появился новый.

Причём к новому сайту в плане дизайна у меня серьёзных претензий нет — доводилось видеть как хуже так и [...]]]> Чтобы понять разницу между дизайном и информационной архитектурой — мало объяснений нужны и примеры.

Недавно у меня перед глазами такой пример образовался — обновился официальный сайт закупок Воронежской области, http://zakaz.gfu.vrn.ru

Точнее вместо старого сайта появился новый.

Причём к новому сайту в плане дизайна у меня серьёзных претензий нет — доводилось видеть как хуже так и лучше. А по сравнению с федеральным — так просто конфетка. 

Но не дизайн определяет то как же информация становится доступной пользователям.  

Например:

1. На сайте начисто отсутствует RSS как для отслеживания закупок так и просто для новостей — хотя сложного тут ничего нет. 

2. В реестрах организаций нет поиска по инн, названию и так далее

3. У организаций нет пермалинков и нет возможности просматривать закупки по определённому заказчику. Зачем это нужно? Да хотя бы для того чтобы департаменты области, ГУПы и МУПы могли указывать на своих сайтах не просто ссылку на сайт закупок области, а ссылку на свою карточку на сайте где можно просмотреть их заказы

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

5. Интерфейс проведения электронных аукционов сделан на Flash Flex. При том что Flex — это, конечно, модно тем не менее 600 килобайтный рантайм это не так мало. Если скрипты для AJAX’а можно прооптимизироать использовав сжатие — то тут сжатия не получится и вообще

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

—

Все эти частные замечания можно разбить на следующие критерии анализа:

1. Целостность данных — отсутствие пермалинков. 

2. Качество представления данных — полнота форм поиска и удобсто навигации.

3. Отсутствие описаний технических требований к клиентскому ПО.

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

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

Например, в публичном репозитарии Поискуна теперь доступен Django sitemap generator скрипт по генерации файлов]]> Я обычно пишу мало про практическое программирование потому как не так часто им давно уже занимаюсь,  но некоторые трюки и подходы могут быть полезны особенно тем кто программирует на Python и Django.

Например, в публичном репозитарии Поискуна теперь доступен Django sitemap generator скрипт по генерации файлов sitemap включая индексы sitemap’ов для большого числа элементов до 500 000 и более. В скрипте задаётся информация о моделях, правилах формирования ссылок и размере «нарезки» числа ссылок в одном сайтмапе — остальное он генерит автоматически. 

Собственно хотя и в Django есть собстенный генератор Sitemap’ов, для моделей для которых постоянно добавляются новые объекты и общее число их превосходит 10 000, встроенных механизм sitemap’ов неудобен, а в крупных проектах число экспортируемых ссылок может доходить до миллионов.

Я чуть подробнее остановлюсь на том что же являлось основной моих рассуждений и общем подходе к классификации который далёк от [...]]]> В том что касается онтологии веб и задач классификации — я несколько раз касался этой темы ранее в публикации «Эффективное геокодирование данных» и метапосте с полным перечнем моих заметок и рассуждений.

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

Для начала зададимся вопросом о том что же такое веб сайт. Это домен, домен + содержимое, домен + содержимое + хостинг? Трактовок может быть множество. В моём представлении веб сайт это домен — как точка входа и совокупность программно-технических средств по предоставлению информации посетителям. Но более всего веб сайт является формой представления объектов материального мира в мире цифровом. А ещё более точнее, он является одной из форм представления и самозначащей сложной (составной) сущностью одновременно. 

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

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

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

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

• Местонахождение (вопрос “Где?”). Определяет физическое местонахождение веб ресурса.
• Владение (вопрос “Где владелец?”). Определяет физическое местонахождение организации или физ.лица владельца ресурса.
• Аудитория (вопрос “Для кого?”). Определяет местонахождение потребителей информации с данного веб сайта, его целевую аудиторию.
• Тематика (вопрос “О чём?”). Определяет геопривязки тематики ресурса.

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

Мои рассуждения и подход и к классификации основываются на том что каждая из этих привязок анализируется для снятия всех или ключевых случаев снятия неоднозначностей. 

Теперь подробнее о привязках. 

1. Местонахождение

Мы рассматриваем веб сайт как составной объект из домена и содержания. По домену сайта можно определить перечень IP адресов данный сайт обслуживающий, а по IP адресу можно определить местонахождение сайта по IP Geobase. Но, при этом необходимо учитывать следующие факторы-исключения:

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

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

Первый фактор частично снимается за счёт выявления и ведения реестра CDN провайдеров, второй фактор менее критичен для веб и в данном случае рассматривается как допустимая ошибка. 

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

2. Владение

Владение веб сайтом подразумевает географическое месторасположение организации или физического лица владеющего им. Владением может быть определено по данным о домене в Whois — в частности, по телефону, факсу, e-mail и ключевым словам.

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

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

3. Аудитория

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

Аудитория веб сайта может быть определена несколькими способами:

- по анализу IP адресов через IPGeobase его посетителей, в том числе и за счёт использования внешних счётчиков;

- по регистрации сайта в каталогах в сети предусматривающих геопривязку, например, каталоги Яндекс и Mail.Ru

- по языку веб сайта, например, в случае национальных языков в РФ.

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

4. Тематика

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

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

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

—

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

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

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

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

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

При том что сама по себе идея очень интересная, она так и просится в различные [...]]]> В Yahoo! опубликовали спецификацию на YQL — Yahoo! Query Language — язык запросов для получения данных из информационных массивов Yahoo! Причём доступ к данным производится через специальный вебсервис, а результаты можно получить в XML или JSON. Нехватает толькок Thrift./

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

Внесу и мои 5 копеек. Проблема контроля и регулирования Рунета той же природы что и проблема модерирования крупных социальных сетей вроде Одноклассники, Вконтракте, Facebook и так далее. Эта проблема в необходимости в огромном и постоянно [...]]]> В последнее время всё активнее обсуждают тему можно ли регулировать / модерировать Рунет или нет и что для этого нужно.

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

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

На первом — люди собирают и отмечают ресурсы и материалы как экстремисткие или недопустимые.

На втором — группа экспертов подтверждает или отвергает народную оценку, фиксируя и беря на себя принятие решение голосованием по модели прямого большинства.

На третьем — модератор/администратор принимает решение о включение ресурса или материала в как кандидата на принятие мер в соответствии с законодательством.

Особенность всего вышеописанного в том что если Интернет-цензура будет неизбежной, то она должна быть:

a. Публичной.

б. Прозрачной.

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