Ну чё, капчу написал, на серваке всё новое развернул.
Понадобилось накатить на Djano 1.0 патчи из тикетов #7005, #8600, #8968.
Ещё понадобилось прописать FORCE_SCRIPT_NAME='', потому что
resolve() будет возвращать урлы такими, какими бы они были до
реврайта на сервере, это важно при использовании lighttpd:
url.rewrite-once = (
"^(/media.*)$" => "$1",
"^(/hg/static.*)$" => "$1",
"^/hg(/?.*)$" => "/hg.fcgi$1",
"^(/.*)$" => "/django.fcgi$1")
Если FORCE_SCRIPT_NAME не выставить, шаблонный тег {% url %} и
декоратор @models.permalink будут возвращать урл вида
/django.fcgi/blog/entry/42/, а не /blog/entry/42/.
На самом деле, сдувать пыль с давно не менявшегося движка я начал ещё в августе, благо Gentoo был даже доступен ебилд для SVN-версии Django. По сути дела, в основном потратил время на подчистку кода, освоение новой системы комментирования и django-tagging.
Читать далееДмитрий Зиновьев пишет о своих исследованиях «Моего Круга». Основные положение папира:
Степени вершин графа социальной сети распределены по Парето
Средняя длина пути в сети (учитывается только «ядро» — наибольший связный подграф) равна шести
У ядра сети есть «щупальца», образованные цепочками вершинами степени 2, идущих друг за другом и как будто выходящими из основного плотного ядра. Щупальце заканчивается вершиной, у которой в «друзьях» всего один человек (предыдущий в щупальце). Длины щупалец распределены экспоненциально, средняя длина — 1.
Интересно рассматривать плотное ядро Δ — часть ядра без щупалец. Мерой плотности вершин Δ удобно считать их степень
В Δ также вводится дополнительная (вдобавок к степени) мера вершины, глубина — среднее расстояние от вершины до всех остальных вершин в плотном ядре. Средняя глубина — 5.5 — в плотном ядре оказывается равной средней длине пути во всём ядре. Если рассмотреть сферически симметричный n-мерный объект, предполагается, что глубина точек объекта будет наименьшей в его центре. С учётом этого наблюдения получается, что центр и внешняя оболочка Δ имеют наименьшую плотность, а основная часть Δ сосредоточена в средних его слоях.
Изучая зависимость степени вершин от такой глубины, можно прийти к ожидаемому выводу, что из вершин с высокой степенью легче попасть в глубокие точки.
Автор рассматривает соотношение плотности вершины к средней плотности смежных с ней (то есть, отношение плотности члена сети к средней плотности его ближайших соседей) и выводит таким образом меру социальной активности, разделяя таким образом всех участников сети на «популярных» и «маргиналов». Статистика показывает, что среди контактов у популярных участников преобладают «маргиналы» — то есть серенький пипл вовсю кучкуется вокруг активных социодрочеров.
Напоследок рассмотрено вложение метрического топопространства соц. сети в векторное с огромной размерностью, что бесполезно.
В общем, результаты полностью согласуются с тем, что наблюдается в большинстве социальных сетей.
Ну и большинство людей — средненькие :-)
Некоторое время не следил за микроформатно-рдф-семантиквебовским миром, а ведь уже несколько месяцев как есть Google Social Graph.
Суть вот в чём — быстрый Гугл индексирует XFN и FOAF, предоставляя информацию о связях, обозначенных этими технологиями, через удобный API; профит очевиден. Таким образом, Google экономит время и усилия при разработке средств по обработке распределённых социальных сетей.
Это вам не вручную странички парсить (в принципе, Google тоже странички парсит, только ГОРАААЗДО быстрее).
Появился bestpersons.ru — на нём можно указать список всех-всех «своих» сайтов (в списке предопределённых есть ЛОР, лол), движок проставляет всем этим ссылкам rel="me"; профит очевиден. Кстати, мечта деанонимизатора :-) При помощи сабжа bestpersons может искать людей, указанных в качестве «друзей» на других сайтах, при условии, что эти связи обозначены при помощи XFN. В качестве дополнительных плюшек — это OpenID-провайдер и агрегатор контента со всех перечисленных сайтов. Плюс ниибаца значок:
А «В Контакте» по прежнему нет XFN. Уверен, многие писали афтарам сервиса просьбы это сделать — но, видимо не судьба. Поэтому получить красивую паутинку связей (как это можно сделать, к примеру, с Twitter или Facebook) нельзя.
Несмотря на десять миллионов вложенных долларов, выглядит как беспросветное пафосное говно, гомосексуальное чуть менее, чем полностью :-( Столько Flash не позволяют себе даже в Ю-Эс-Эй!
11 сентября инфраструктура GRDDL приобрела статус «W3C Recommendation».
Пройдут годы, прежде чем поставщики содержимого начнут уважать GRDDL, однако смысл технологии ясен уже сейчас.
Это мост между существующими диалектами XML и RDF. Использование GRDDL смещает точку приложения усилий с формирования RDF к созданию алгоритмов преобразования существующих данных в RDF (это очень разные вещи). GRDDL как раз обсуждает способы указания возможностей перевода существующих данных в RDF.
Документы могут быть включены в инфраструктуру GRDDL разными путями. В
общем случае для XML для этого нужно объявить пространство имён
grddl и указать в аттрибуте корневого элемента идентификатор ресурса
соответствующего преобразования из XML в RDF (например, файла XSLT).
Механизм также позволяет указывать преобразования для целых классов
XML-документов (имеются в виду классы по профилю или
пространству имён), например, можно указывать преобразования
микроформатов — хаков на HTML — в RDF —
формализованный каркас высокого уровня.
Для определённых типов XML-приложений есть частные особенности
применения, например, «GRDDL-enabling» для HTML-документов включает
указание корректного значения profile в секции метаданных
документа, для XHTML — profile и списка преобразований.
Пример для XHTML (образец из описания GRDDL):
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head profile="http://www.w3.org/2003/g/data-view">
<title>Joe Lambda's Home page [an example of RDF in XHTML]</title>
<link rel="transformation" href="http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokFOAF.xsl" />
<link rel="transformation" href="http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokCC.xsl" />
<link rel="transformation" href="http://www.w3.org/2003/12/rdf-in-xhtml-xslts/grokGeoURL.xsl" />
и т. д.
Здесь XHTML-документ и связывается с несколькими преобразованиями (здесь — XSLT), в которых указано, как извлечь данные из XHTML и преобразовать их в набор фактов RDF. Преобразования выполняются по шагам, на каждом шаге результат текущего сливается с уже сформированным RDF; инвариант GRDDL — на выходе получается корректный RDF.
(XHTML-документ обязательно должен быть валидным; создатели невалидных (и уж тем более не well-formed) страниц должны сменить свои убеждения на правильные или быть утилизированы в биореакторе.)
Предполагается, что преобразование в RDF при помощи соглашений GRDDL будут выполнять специальные агенты (например, встроенные в браузеры).
Чем отличается подход GRDDL от текущих решений по извлечению, например, микроформатов при помощи XSLT или как это делает Operator? GRDDL — более обобщённая инфраструктура, не завязанная на определённый формат (в терминах XML — фактически DTD) представления со стороны входных данных. Обобщение и высокий уровень описания, однако, может явиться причиной сложности в реализации GRDDL-агентов и фактическими различиями в деталях их функционирования.
В документе не указывается конкретная технология для извлечения данных:
grddl:transformation attribute whose value is an IRI reference, or list of IRI references, that refer to executable scripts or programs which are expected to transform the source document into RDF.
XSLT представляется одним из удобных (и, что подчёркивается, распространённых) средств извлечения данных из XML, существующие связанные с GRDDL преобразования построены именно на XSLT.
