Анализ социальных сетей средствами Semantic Web
Хочу рассказать об одном исследовании, интересном пользователям социальных сетей:
Analysis of a Real Online Social Network Using Semantic Web Frameworks
(авторы - Guillaume Erétéo, Michel Buffa, Fabien Gandon, Olivier Corby, все – сотрудники INRIA, Франция).
Речь в нём идёт об инструменте общения в стиле Web 2.0 – социальных сетях. Задача, которая стояла перед авторами статьи – оценить параметры сети – диаметр, среднюю длину маршрута в сети друзей, лидеров сети, и т.д. – кажется простой для обычной БД: есть формулы расчета параметров сети (теория графов), пишем запросы и получаем ответы.
Однако, как отмечено авторами, далеко не все параметры социальной сети являются зависящими только от структуры графа. Смысл связей – дуг графа – для социальной сети далеко не один и тот же. «Я знаю его» и «это - мой враг» – разные по смыслу дуги – в стандартных алгоритмах расчета параметров социальной сети не различаются.
Группа воспользовалась данными, предоставленными молодой компанией Ipernity.com. Сеть была не очень большая – на момент анализа - 61937 участников, 494510 дуг-связей.
Подход
Анализ социальных сетей большой частью есть анализ графа связей. Для обычных (не семантических) графов применяется набор метрик под общим названием Social Network Analysis (SNA). Появилась идея проанализировать такой граф средствами Semantic Web.
Собственно социальные данные компании хранятся в РСУБД, в виде обычных реляционных таблиц. Было решено перевести эти данные в набор триплов.
На первом этапе произвели анализ видов элементов в соцсети (люди, объекты (музыка, фото, видео, сообщение), взаимодействия (знает, сообщает, комментирует, ...).
Затем прошлись по существующим ресурсам онтологий. Кое-что использовали без переделки, но большей частью – добавили своё.
Добавили варианты всевозможных связей, включая «папа», «мама», «друг», «враг» (взяли готовую онтологию relationship и развили её в части объявления подмножества семейных связей), использовали FOAF для определения участников социальной сети и контента, который они добавляют в сеть. Для описания тэгов использовали новую версию SCOT.
Когда оказалось, что нет онтологий для представления контента (сообщений, тем, домашних страниц), и собственно взаимодействия (посещений страниц, комментариев, приватных сообщений), создали свою онтологию взаимодействий в социальной сети - SemSNI (Semantic Social Network Interactions, на сайте INRIA сейчас отсутствует, но графическое изображение, возможно неполное, можно посмотреть здесь и свою онтологию для анализа социальных сетей SemSNA
Далее, сгенерировали из всей базы данных социальной сети Ipernity.com массив триплетов.
Сама триплификация записей РБД была сделана встроенными средствами хранилища триплетов Corese (разработка INRIA, автор Olivier Corby).
Примерный запрос к Corese на создание триплетов вида <user rel:friendOf user> (взято отсюда):
construct { ?url_user1 rel:friendOf ?url_user2 }
select sql('jdbc:mysql://localhost:3306/mysql','com.mysql.jdbc.Driver', 'user', 'pwd',
'SELECT user1_id, user2_id from relations where rel = 2 limit 100000' ) as (?id1, ?id2) fun:genIdUrl(?id1, 'http://semsni.fr/people/') as ?url_user1 fun:genIdUrl(?id2, 'http://semsni.fr/ people/') as ?url_user2 where { }
После триплификации общие размеры оказались такими:
Размер памяти для триплетов: описания участников сети + их связей = 4,9 Гб описания сообщений между участниками сети = 14,7 Гб описания документов + комментариев по ним = 27,2 Гб
Массив триплетов полностью размещался в оперативной памяти (параметры машины – двухпроцессорный четырёхядерный Intel(R) Xeon(R) CPU X5482 3.19 ГГц, 32.0 Гб ОЗУ и управлялся хранилищем Corese.
К этому массиву триплетов применили SPARQL запросы, реализующие вычисления параметров социальной сети.
Оказалось (впрочем, ожидаемая ситуация), что необходимых для вычислений агрегированных функций типа sum(), count(), avg() в SPARQL всё ещё нет, поэтому в запросах использовали смесь SPARQL + SQL путём вызова функции sql(запрос SQL) внутри SPARQL запроса.
Например, поиск геодезической линии (кратчайшего расстояния из from в to), безотносительно разметки дуг
select ?from ?to $path pathLength($path) as ?length where{ ?from sa (param[rel])*::$path ?to} group by ?from ?to
(параметр sa предписывает вычислять все кратчайшие пути)
Результаты
Для разминки рассчитали количественные показатели всей социальной сети – диаметр, количество узлов, дуг; их можно было получить и анализом РБД.
В рамках семантического анализа социальной сети вычислили параметры подграфов социальной сети по разным типам семантических связей («семья»/ «family», «мне нравится»/ «favorite», «дружба»/ «isFriendOf», более конкретные) и типам взаимодействий («комментирует», «создает сообщение», и др.).
Разрешив пользователям социальной сети использовать любые доступные онтологии для детализации своих профилей и сообщений, можно уточнять базовые аналитические запросы до любого уровня детализации. Например, спросить можно о связи типа isFriendOf, а можно - о более общем типе связи foaf:knows, подсвойством которого является isFriendOf.
Сухой остаток
Лично у меня есть только один вопрос (понятное дело, риторический).
Почему бы социальную сеть не делать сразу на RDF? Онтологии для разметки элементов графа социальной сети уже есть. RDF хранилища – тоже.
Посмотреть презентацию - http://isicil.inria.fr/res/slides/ereteoetal_ISWC2009_v9.pdf
| Natalya Keberle | |
| Наталья Геннадьевна Кеберле | |
| Род деятельности: |
исследователь, преподаватель |
|---|---|
| Роль участника: | |
| Основной раздел: | |
| Круг интересов: |
Semantic Web, онтологии, логики, OWL, время |
| Место рождения: | |
| Гражданство: | |
| Сайт: | |
| Nickname | |
