2.1.3 Поиск с учетом ключевых слов, мультимедийной информации

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

Для обхода дерева используется прямой рекурсивный алгоритм обхода в глубину (рис. 1), потому что анализируются все узлы дерева, и такой обход не требует хранения узлов в новой структуре данных [9]. Процесс обхода дерева начинается с корня и идет «вглубь» до тех пор, пока это возможно, тем самым проходя все возможные вершины и находя все возможные совпадения с ключевыми словами в графе.

Рисунок 1. Обход дерева в глубину

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

Процесс поиска совпадений можно разделить на несколько этапов.

1) Ключевые слова приводятся в начальную форму

Перед поиском совпадений все ключевые слова, введенные пользователем, приводятся в начальную форму с помощью морфологического анализа [16].

2) Проверка опечаток в ключевых словах

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

3) Определение объектов на изображении

Сам анализ происходит либо в текстовой, либо в мультимедийной информации. Чтобы проанализировать мультимедийную информацию (изображения), необходимо:

- определить объекты на изображении;

- полученный список названий объектов перевести на русский язык.

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

4) Разделение на слова проверяемого текста

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

5) Слова из текста или списка объектов приводятся в начальную форму

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

6) Проверка опечаток в словах из текста

Если слово не нашлось в словаре, оно отправляется на проверку опечаток. Аналогично п. 2), если нашлись исправленные варианты, то они приводятся в начальную форму. Учитывается и сам неисправленный вариант.

7) Сравнение слов из текста и объектов с изображения с ключевыми словами

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

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

2.2 Аутентификация и авторизация пользователя

Аутентификация и авторизация пользователя необходимы для получения ключа доступа к таким защищенным ресурсам, как информация из различных профилей социальных сетей. Популярные социальные сети Twitter, Facebook, ВКонтакте, Одноклассники, LinkedIn используют протокол авторизации Oauth 2.0, который позволяет социальным сетям выдать права на доступ к защищенным ресурсам, доступным только конкретному пользователю [31]. С помощью протокола авторизации пользователь передает логин и пароль непосредственно социальной сети, а не используемому приложению, что избавляет пользователя от необходимости доверять свои личные данные самому приложению. После авторизации посредством Oauth 2.0 предоставляется access token, с помощью которого в дальнейшем можно будет обращаться к необходимым ресурсам [56]. Каждый access token имеет срок действия, по истечении которого доступ к запрашиваемой информации будет закрыт. Обычно есть информация, которую можно получить без выданного ключа доступа пользователя, однако в этом случае будут возвращаться только общедоступные данные.

Перед использованием протокола авторизации Oauth 2.0 необходимо зарегестрировать приложение с используемым сервисом. Это делается в разделе для Разработчиков социальной сети. В процессе регистрации приложения предоставляются следующие данные: название приложения, сайт приложения, список Redirect url, которые будут использоваться для перенаправления кода авторизации в случае двухэтапной авторизации пользователя либо ключа доступа в случае неявной авторизации.

Протокол предоставляет несколько вариантов авторизации [31]:

1) Авторизация для приложений с серверной частью

2) Неявная авторизация

3) Авторизация по логину и паролю

4) Восстановление ключа доступа

2.2.1 Авторизация для приложений с серверной частью

Двухэтапный вариант авторизации используется приложениями, которые имеют серверную часть, соответственно, в данной работе используется именно этот вариант авторизации. Полученный ключ доступа пользователя необходимо использовать во всех запросах с сервера приложения к API социальной сети для того, чтобы получить доступные авторизованному пользователю данные для их последующего анализа [46]. В данном варианте авторизации выполняются последовательные шаги (рис. 2):

1) Перенаправление на страницу авторизации

Открывается страница авторизации внутри социальной сети, где пользователю предлагается ввести логин и пароль от данной социальной сети.

2) Подтверждение у пользователя выдачи прав

На странице авторизации пользователю может подтвердить или не подтвердить выдачу прав приложению.

3) Перенаправление на Redirect URL с параметром code

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

4) Запрос на получение access token

С сервера выполняется POST-запрос на получение ключа доступа access token с использованием полученного параметра code.

5) Выдача access token

В результате выполнения запроса и успешной авторизации возвращается ключ доступа access token, который в последствии будет использоваться во всех методах обращений к API социальной сети, время его жизни и refresh token, который может использоваться в дальнейшем при варианте авторизации через Oauth 2.0 «Восстановление ключа доступа» (см. п. 2.4.4).

Рисунок 2. Протокол авторизации Oauth

2.2.2 Неявная авторизация

Еще один способ авторизации - это неявная авторизация. Она используется в случае, когда приложение полностью клиентское и не имеет серверной части. Выданный таким образом access token не может использоваться при запросах к API социальной сети с сервера приложения. Этот вариант авторизации имеет меньше шагов до выдачи ключа доступа, а именно не требует менять параметр code на access token. Также этот вариант авторизации не предоставляет refresh token в отличие от двухфакторной авторизации. В данном варианте выполняются последовательные шаги (рис. 3):

1) Перенаправление на страницу авторизации

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

2) Подтверждение у пользователя выдачи прав

На странице авторизации пользователю может подтвердить или не подтвердить выдачу прав приложению.

3) Перенаправление на Redirect URL с параметром access token

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

Рисунок 3. Неявная авторизация

2.2.3 Авторизация по логину и паролю

Вариант авторизации по логину и паролю рекомендуется к использованию в том случае, если другие способы авторизации недоступны. Некоторые приложения не поддерживают такой способ авторизации, например, социальная сеть Вконакте не предоставляет возможности использовать вариант авторизации по логину и паролю. Такая авторизация представляет из себя POST-запрос, который напрямую возвращает ключ доступа access token в GET-параметре.

2.2.4 Восстановление ключа доступа

Ключ доступа имеет ограниченный срок действия, и по его истечению доступ к защищенным ресурсам будет закрыт. В таких случаях можно не перенаправлять пользователя на страницу авторизации для повторного введения логина и пароля, а использовать refresh token, который был предоставлен при первой авторизации пользователя (но только случае двухфакторной авторизации). Идентично авторизации по логину и паролю, необходимо отправить один POST-запрос с refresh token, который напрямую возвратит access token внутри GET-параметра.

2.3 Проектирование структуры данных

После предоставления ключа доступа к защищенным ресурсам социальной сети, появляется возможность получать информацию о профилях социальной сети путем отправки соответствующих запросов к используемому API. Для хранения полученной информации используются структура данных «Друг», в которой поля определены в соответствии с характеризующим профиль набором параметров. Также структура содержит информацию о списке разделов найденных совпадений после анализа, уровне внутри дерева друзей, списке дочерних узлов и ссылке на родителя (подробнее о структуре данных «Друг» см. табл. 1)

2.3.1 Набор параметров по каждому человеку

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

1) Раздел «о себе»

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

2) Раздел «интересы»

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

3) Раздел «Музыка»

Раздел представляет собой список названия композиции и ее автора.

4) В раздел «Карьера»

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

5) Раздел «Стена»

Раздел представляет собой более сложную структуру и также является обычно самым информативным разделом профиля из существующих. Каждая запись со стены содержит свой идентификатор, тип (запись пользователя или запись со стены другого пользователя - «репост»), информацию об изображениях внутри записи, прикрепленных аудиозаписях и самом тексте записи. Такой набор критериев требует хранить каждую запись в отдельной структуре данных «Пост» с соответствующими полями (табл. 2).

Таблица 1

Структура данных «Друг»

Поля
Имя	Назначение
info	Информация из разделов профиля «имя», «фамилия», «о себе», «интересы», «карьера», «музыка». Опционально.
friends	Список дочерних узлов текущего профиля
wall	Список записей со стены текущего пользователя
parent	Ссылка на родителя текущего пользователя, если он есть
depth	Уровень текущего пользователя в дереве (глубина, расстояние до корня дерева)
sections	Секции, в которых было найдено совпадение с ключевыми словами-интересами
ID	Идентификатор профиля текущего пользователя
Методы
Имя	Назначение
getParents	Возвращает цепочку друзей до профиля profile
getWall	Возвращает список записей со стены профиля
setProfileWall	Добавляет поле стены к профилю
getProfileInfo	Возвращает поле info профиля
initializeFriends	Метод инициализации друзей текущего профиля
getFriends	Метод для получения списка друзей человека
getProfileInfo	Метод для получения информации профиля
getDepth	Метод для получения глубины графа
setDepth	Метод для установки глубины графа
getParent	Метод для получения родителя
setParent	Метод для установки родителя
getSections	Метод для получения списка секций
addSection	Метод для добавления секции

Таблица 2

Структура данных «Пост»

Поля
Имя	Назначение
id	Идентификатор записи на стене пользователя
text	Текст записи на стене пользователя
photosurl	Список ссылок на изображения, прикрепленные к записи
audio	Список композиций, прикрепленных к записи
Методы
Имя	Метод для добавления в список ссылок на фотографии новой ссылки
addPhoto	Метод для добавления в список композиций новой композиции
addAudio	Возвращает список записей со стены профиля
getText	Возвращает текст записи
getId	Возвращает идентификатор записи
getAudio	Возвращает список композиций, прикрепленных к записи
getPhotosurl	Возвращает список ссылок на изображения, прикрепленные к записи

2.3.2 Граф друзей

Так как в структуре данных «Друг» есть ссылки на родительский узел и на дочерние узлы, инициализированные объекты «Друга» являются вершинами дерева друзей, где объект авторизованного пользователя - это корень дерева (рис. 4). Глубина графа, m - это количество уровней дерева, которое выбирается пользователем перед его построением. Ширина, n - это количество дочерних узлов в вершине, которая не является листом, то есть уровень которой меньше m.

Рисунок 4. Граф друзей

2.4 Алгоритм расчета весовых коэффициентов найденных друзей

2.4.1 Параметры, влияющие на итоговый вес найденного друга

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

1) Уровень узла найденного профиля в дереве друзей

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

2) Вес разделов, в которых найдено совпадение

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

3) Количество найденных ключевых слов в разделе

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

4) Количество уникальных найденных ключевых слов

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

5) Тип данных, в котором найдено совпадение

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

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

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

- Определение объектов на изображении и предоставление списка слов, соответствующих найденным объектам.

- Сравнение каждого слова из списка полученных слов с ключевыми словами, введенными пользователем (поиск совпадений в тексте).

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

2.4.2 Схема зависимостей параметров

С учетом всех параметров, от которых зависит итоговый приоритет найденного друга, может быть построена схема зависимостей, с помощью которой можно увидеть влияние параметров друг на друга (рис. 5). На схеме видно, что итоговый коэффициент напрямую зависит от трех параметров: уровень найденного друга в дереве друзей, проанализированные разделы профиля социальной сети и количество уникальных найденных слов из списка ключевых слов, введенного авторизированным пользователем. Каждый раздел зависит от найденных в этом разделе совпадений и приоритета, который выдается разделу авторизированным пользователем. Отдельное совпадение зависит от типа данных, в которых оно было найдено (текст или изображение). Таким образом, чем больше совпадений было найдено и чем они качественнее, тем больше вес конкретного раздела и, соответственно, общий вес разделов.

На схеме есть несколько переменных: количество разделов h, которое, как и сами разделы для анализа, зависят от используемой социальной сети, потому что API разных социальных сетей предоставляют доступы к разным разделам профиля. Например, раздел «о себе», содержание которого можно получить, используя VK API, возвратит пустое значение при обращении к этому разделу с помощью API Facebook. Это касается также раздела «карьера», а раздела «интересы» в Facebook, в отличие от ВКонтакте, не существует.

Переменные q₁..q_h отвечают за количество совпадений в каждом разделе, где индекс - это номер раздела.

Рисунок 5. Схема зависимостей при расчете итогового коэффициента друга

2.4.3 Расчет коэффициентов параметров

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

1) Совпадения

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

где ;

conf - вероятность корректного распознавания объекта на изображении;

j - номер раздела = [1..h];

q_j - количество совпадений в разделе j.

Далее, посчитав веса всех совпадений и их сумму, необходимо нормировать полученное число. Нормируются веса относительно максимального получившегося веса всех совпадений в данном разделе среди найденных друзей. Таким образом нормирующий множитель - это максимум среди весов совпадений данного раздела среди всех друзей (2).

где первый индекс - это номер друга;

второй индекс - раздел;

n - количество найденных друзей.

Нормированный вес совпадений в разделе j по формуле (3).

2) Разделы

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

Таблица 3

Шкала приоритетности разделов

Важность	Коэффициент
Очень важно	3
Важно	2
Почти неважно	1
Вообще неважно	0

В соответствии с выбранными весами нормирующий множитель считается как сумма коэффициентов разделов (4).

где - это коэффициент раздела;

j = [1..h] по шкале приоритетности разделов.

С учетом приоритетов и совпадений общий вес разделов вычисляется по формуле (5).

Используя нормирующий множитель, который будет учитываться при расчете веса конкретного раздела, нормированный вес разделов рассчитывается по формуле (6).

3) Уровень

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

,

где d - это уровень найденного друга.

4) Количество уникальных найденных слов

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

где u - количество найденных уникальных слов;

s - общее количество уникальных слов.

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

где: ,

conf - уверенность объекта на изображении,

j - номер раздела = [1..h],

q_j - количество совпадений в разделе j,

- это коэффициент раздела j = [1..h],

d - это уровень найденного друга,

u - количество найденных уникальных слов,

s - общее количество уникальных слов.

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

2.5 Выводы

1) Разработаны алгоритмы аутентификации и авторизации в приложении посредством использования аутентификации и авторизации через социальную сеть с использованием протокола авторизации OAuth 2.0.

2) Проанализированы варианты авторизации, использующие протокол OAuth 2.0, и в результате принято решение использовать способ авторизации для приложений с серверной частью, т.е. с дополнительной аутентификацией сервера.

3) Разработан алгоритм построения графа друзей пользователя на основе введенных пользователем параметров глубины и ширины желаемого графа.

4) Спроектированы структуры данных: структура данных «Друг», которая содержит в себе различную информацию о профиле человека в социальной сети, и структура данных «Пост», которая отвечает за данные о записи на стене профиля социальной сети.

5) Разработан алгоритм расчета весовых коэффициентов найденных друзей в зависимости от уровня узла найденного профиля в дереве друзей; вес разделов, в которых найдено совпадение; общего количества найденных ключевых слов и количества уникальных найденных ключевых слов; типа данных, в которых найдено совпадение. Итоговые коэффициенты используются для сортировки найденных друзей и их вывода по в порядке приоритетности.

Глава 3. Разработка приложения для поиска людей по интересам

3.1 Инструменты разработки

Веб-приложение FriendFinder разработано на языке программирования Java 8 на основе архитектуры клиент-сервер (рис. 6) и использованием внешних API социальных сетей ВКонтакте и Facebook, распознавания изображений от Microsoft Azure - Computer Vision, Яндекс Спеллера и Яндекс Переводчика.

Рисунок 6. Архитектура приложения

3.1.1 Серверная часть

В качестве локального сервера использовался Apache Tomcat 9. Серверная часть реализована на языке Java 8 с помощью среды разработки Intellij IDEA. Для разработки серверной части и взаимодействия с клиентской частью были использованы java-сервлеты, созданные с помощью стандартной библиотеки для сервлетов javax.servlet-api.

Также приложение доступно в сети и находится в общем доступе по адресу: http://friendsfinder.textanalysis.ru.

3.1.2 Клиентская часть

Для создания клиентской стороны были использованы JSP-страницы, в которых содержатся динамические jsp-элементы и статические элементы, оформленные в формате HTML. Отображаемые на странице элементы разработаны с помощью библиотеки Bootstrap 3.0 и JavaScript-библиотеки JQuery для взаимодействия JavaScript и HTML. Для некоторых компонентов страницы написан свой набор параметров форматирования CSS.

3.1.3 Инструменты ведения разработки

Для введения разработки использовались инструменты Git, Github и Sourcetree для контроля версий исходного кода приложения.

3.2 Работа с API

В данном приложении использовались несколько API для получения различной информации. Для получения информации о профиле социальной сети использовались API социальных сетей Facebook и ВКонтакте. Для распознавания изображений использовался Computer Vision API, который возвращает список объектов на загруженной фотографии. Из-за того, что список возвращается только на английском языке, используется Яндекс Переводчик API для перевода списка объектов и их дальнейшего использования в анализе. Яндекс Переводчик используется также для перевода ключевых слов, введенных пользователем, на русский язык. И из-за специфичности текстов в социальных сетях, который содержит большое количество опечаток, было необходимо обращение к еще одному API Яндекса - Яндекс Спеллеру для их устранения.

3.2.1 Принципы работы с VK API

3.2.1.1 Построение запроса VK API

API ВКонтакте содержит методы, с помощью которых можно получать информацию о конкретном профиле из базы данных социальной сети ВКонтакте [10]. Данные возвращаются в формате JSON в ответ на заданные HTTP-запросы к серверу ВКонтакте. Это позволяет построить дерево друзей авторизованного пользователя, где каждый узел заполняется информацией о профиле социальной сети, что повышает вероятность найти человека по ключевым интересам. Синтаксис запросов и формат данных, возвращаемых после отправки запроса строго определены в документации к API. Запрос строится по шаблону (рис. 7): после протокола соединения и стандартного адреса API сервиса ВКонтакте вводится необходимый метод (users.get или wall.get, или account.getInfo и.д. полный список методов представлен в документации к VK API). После названия метода перечисляются параметры (опционально), которые необходимы выбранному запросу. Например, для метода users.get можно использовать параметр user_id или user_ids, если нужно вернуть информацию не об одном пользователе, а о группе пользователей. После параметров обязательно указываются ключ доступа и версия используемого API.

Рисунок 7. Шаблон запроса к VK API

После отправки запроса с сервера возвращается объект в формате JSON, в котором содержатся данные, которые запрашивались, либо сообщение об ошибке. Например, если отправить запрос со своим ключом доступа <at>

на получение основных данных (Имя, Фамилия) о пользователе с id=210 и его даты рождения, вернется JSON-объект (рис.8(а)) с информацией о пользователе. Если в этом же запросе поменять с user_ids=210 на user_ids=21022222222222, то вернется ошибка с уведомлением о несуществующем пользователе с таким идентификатором (рис.8(б)).

Рисунок 8. JSON-ответ на запрос к VK API

Кроме правил построения запроса к API социальной сети ВКонтакте, существуют количественные и частотные правила-ограничения на отправку запросов.

3.2.1.2 Ограничения VK API

VK API может не возвращать запрошенные данные не только из-за некорректно введенного запроса, но и из-за превышения установленных ограничений на отправку запросов к API. Ограничения есть как частотные, так и количественные.

1) Частотные ограничения

К методам VK API с полученным ключом доступа пользователя access token (подробнее см. описание в п. 3.2.3.2 и получение ключа в API ВКонтакте п. 3.2.3.3) установлены частотные ограничения - обращение не более 3 раз в секунду. При превышении этого ограничения вернется JSON-ответ с ошибкой 6: Слишком много запросов в секунду (рис. 9) и описанием параметров, которые содержал запрос к API.



Рисунок 9. JSON-ответ при превышении частотного ограничения VK API

2) Количественные ограничения

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

3.2.2 Принципы работы с Facebook API

3.2.2.1 Построение запроса к Facebook API

Все запрашиваемые данные Facebook загружает и отправляет с помощью инструмента Graph API. Facebook предоставляет свои данные в определенном формате, разделяя их на несколько элементов:

1) Узлы, обособленные «объекты» (Фото, Страница, Пользователь и т.д.)

2) Границы контекста, т.е. связи группа объектов-объект (комментарии к Фото, фото на Странице)

3) Поля, данные объекта (родной город Пользователя, его имя или поле «любимые цитаты»)

Как и VK API, API Facebook'а основан на HTTP-запросах, и его синтаксис тоже строится по шаблону (рис. 10): после протокола соединения вводится стандартный адрес API сервиса, затем опционально версия (если версия пропущена, то по умолчанию ставится самая старая из существующих). Далее вводится идентификатор узла (либо «me», если запрос к профилю авторизованного пользователя), опционально границы контекста, поля (также опционально) и токен доступа, который необходим почти во всех запросах к Graph API.

Рисунок 10. Шаблон запроса к Graph API

Ответ возвращается в формате JSON аналогично API ВКонтакте (рис. 11 (а)), либо возвращается ошибка с описанием (рис. 11 (б)).

Рисунок 11. JSON-ответ на запрос к Graph API

3.2.2.2 Ограничения Facebook API

Facebook API аналогично VK API имеет ограничения на количество обращений (запросов) в единицу времени. Всего существует 2 типа ограничений для приложения.

1) Количественные ограничения на уровне пользователя.

Количество обращений одного пользователя с ключом доступа пользователя access token (подробнее см. п. 3.2.3.2) ограничиваются Facebook. Если пользователь выполнит слишком много обращений (даже из разных приложений) к API, то дальнейшие его обращения блокируются и возвращается ответ с ошибкой кода 17. Запросы блокируются до тех пор, пока количество обращений за последний час не снизится.

2) Количественные ограничения на уровне приложения Facebook.

Кроме ограничений на обращения от имени пользователя, Facebook имеет ограничения на количество запросов от самого приложения. Количество доступных обращений рассчитывается как 200 вызовов на 1 пользователя приложения в час. Т.е. если у приложения Facebook 100 пользователей, то приложение может делать 20000 запросов в час. В случае превышения данных ограничений, при запросах к API будет возвращаться ответ с ошибкой кода 4.

3.2.3 Аутентификация и авторизация пользователя

Почти во всех запросах к API социальных сетей необходимо добавлять ключ доступа, access token, чтобы получить доступ к защищенным объектам. Для его получения нужно пройти аутентификацию и авторизацию пользователя в социальной сети, для чего используется протокол авторизации OAuth 2.0 для приложений с серверной частью. Авторизация проходит в 2 этапа:

- получение параметра code;

- обмен code на ключ доступа (access token).

3.2.3.1 Описание параметра code

Код авторизации нужен для повторной аутентификации сервера, где сервер авторизации используется как посредник между клиентом и владельцем ресурса (пользователя, которому нужно авторизоваться). Клиент направляет пользователя, которому нужно авторизоваться, на сервер авторизации, затем сервер перенаправляет его обратно к клиенту с параметром кода авторизации.

3.2.3.2 Описание параметра access token

Ключ доступа - access token, можно получить, используя полученный параметр кода авторизации - code. Ключ нужен для работы с методами API социальных сетей от имени пользователя. Вызывая методы без access token, можно получить не все запрашиваемые данные (либо не получить вообще), т.к. нет информации о пользователе, от имени которого делается запрос, соответственно может не быть прав для просмотра какой-либо закрытой информации в профиле социальной сети.

Ключ доступа - это строка, которая используется в качестве параметра в HHTP-запросах к API социальной сети для подтверждения прав определенного пользователя на просмотр какой-либо информации, которая может быть не общедоступной. Вместе с access token после отправки запроса возвращается время его жизни в секундах. Т.к. время жизни ключа доступа ограничено, процедуру авторизации приложения или процедуру обновления ключа доступа с помощью refresh token необходимо повторять в случае истечения срока действия access token, смены пользователем своего логина или пароля.

3.2.3.3 Получение ключа доступа в VK API

Получение ключа доступа в VK API происходит в несколько этапов: открытие диалога авторизации, разрешение прав доступа, получение code, обмен параметра code на ключ доступа пользователя access token.

1) Открытие диалога авторизации

Для аутентификации и авторизации пользователя необходимо перенаправить по адресу https://oauth.vk.com/authorize и включить в запрос некоторые параметры (табл. 4)

Таблица 4

Параметры для запроса на аутентификацию и авторизацию

Параметр	Описание
client_id (обязательный)	Идентификатор приложения ВК.
redirect_uri (обязательный)	Адрес, на который будет передан code (домен указанного адреса должен соответствовать основному домену в настройках приложения и перечисленным значениям в списке доверенных redirect uri -- адреса сравниваются вплоть до path-части).
display	Указывает тип отображения страницы авторизации: · page -- форма авторизации в отдельном окне; · popup -- всплывающее окно; · mobile -- авторизация для мобильных устройств (без использования Javascript) Если пользователь авторизуется с мобильного устройства, будет использован тип mobile.
scope	Битовая маска настроек доступа приложения (friends, photos, audio, status…), которые необходимо проверить при авторизации пользователя и запросить отсутствующие.
response_type	Тип ответа, который Вы хотите получить, в данной работе используется code.
v (обязательный для VK, необязательный для Facebook)	Используемая версия API. Актуальная версия ВКонтакте: 5.95. Актуальная версия Facebook: 3.3.
state	Произвольная строка, которая будет возвращена вместе с результатом авторизации.

Пример запроса:

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

2) Разрешение прав доступа

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

3) Получение code

После успешной авторизации приложения произойдет перенаправление по адресу redirect_uri, указанному при открытии диалога авторизации. При этом код для получения ключа доступа code будет передан в GET-параметре на указанный адрес:

Параметр code может быть использован в течение 1 часа для получения ключа доступа к VK API access token с используемого сервера. В случае возникновения ошибки браузер пользователя будет перенаправлен с кодом и описанием ошибки:

4) Получение access token

Для получения access token необходимо выполнить запрос c сервера на https://oauth.vk.com/access_token, передав необходимые параметры (табл. 5).

Таблица 5

Параметры для получения access token

Параметр	Описание
client_id (обязательный)	Идентификатор используемого приложения ВК.
client_secret (обязательный)	Защищенный используемого приложения ВК (указан в настройках приложения)
redirect_uri (обязательный)	URL, который использовался при получении code на первом этапе авторизации. Должен быть аналогичен переданному при авторизации.
code (обязательный)	Временный код, полученный после прохождения авторизации.

Пример запроса:

В результате выполнения данного запроса сервер получит вновь созданный access token. В случае успешного выполнения запроса вернется JSON-список с ключом доступа, временем его жизни, идентификатором доступа (рис. 10 (а)), а в случае ошибки будут переданы параметры error и error_description (рис. 10 (б)).

(а) Информация об access token (б) Информация об ошибке

Рисунок 10. Ответ на запрос для получения access token

3.2.3.4 Получение ключа доступа в Facebook API

Получение ключа доступа Facebook API совершается в несколько этапов. Составление запросов аналогично составлению запросов VK API.

1) Открытие диалога авторизации

Для аутентификации и авторизации пользователя необходимо перенаправить по адресу https://www.facebook.com/dialog/oauth передав параметры client_id, redirect_uri, scope, response_type=code (см. описание этих параметров в табл. 4). В параметр scope необходимо поместить необходимые разрешения user_posts, чтобы получать доступ к стене пользователя, public_profile, чтобы получать открытые данные из основной информации профиля социальной сети, user_friends для доступа к друзьям пользователей Facebook и user_likes, чтобы была возможность получить такую информацию как любимые книги, любимые цитаты и любимая музыка.

Пример запроса:

2) Разрешение прав доступа

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

3) Получение code

Получение параметра code от Facebook API происходит аналогично получению параметра code от VK API. Пример GET-параметра, возвращенного на указанныей адрес redirect_uri:

4) Получение access token

Для получения access token необходимо выполнить запрос c сервера на https://graph.facebook.com/oauth/access_token передав параметры client_id, redirect_uri, client_secret, code аналогично VK API (см. описание параметров в табл. 5). В результате выполнения данного запроса сервер получит созданный access token, переданный в GET-параметре:

3.2.4 Методы API социальных сетей для извлечения информации

3.2.4.1 Методы для профиля ВКонтакте

Для заполнения графа друзей по профилям ВКонтакте используется несколько методов (см. табл. 6).

Таблица 6

Методы для заполнения графа друзей профилями ВКонтакте

Реализованные java-методы	Методы VK API	Описание
getVKGraphFriends(String ID, int offset)	friends.get	Метод для получения идентификаторов друзей пользователя с id = ID и сдвигом относительно начала списка друзей на количество offset
getVKGraphUser(ArrayList<String> friends, String fields)	users.get	Метод для получения информации о пользователях с идентификаторами в списке friends и из полей fields =about, career, interests, photo_200, city
getVkGraphWall(String ID,int count)	wall.get	Метод для получения count постов со стены пользователя идентификатора ID

3.2.4.2 Методы для профиля Facebook

Для получения информации о профиле Facebook используется java-метод getFBGraph(String ID), который посылает запрос к Graph API с узлом = ID необходимого пользователя и полями name, first_name, last_name, feed{message,attachments}, quotes, books, music, friends. В этом случае возвращаются данные со страницы пользователя: имя и фамилия пользователя, стена пользователя, любимые цитаты, любимые книги, любимая музыка и список идентификаторов друзей, которые также установили используемое приложение Facebook.

3.2.5 Принципы работы с Яндекс.Спеллер API

После построения графа друзей с использованием API социальных сетей необходимо обработать полученную информацию для поиска совпадений с введенными авторизованным пользователем ключевыми словами. Текстовая информация в социальных сетях может содержать различные опечатки из-за своей специфики Интернет-текста, поэтому это необходимо учитывать. Работа API строится на отправке HTTP-запросов с использованием XML, JSON и JSONP интерфейсов и возврате ответов с найденными ошибками и вариантами исправления неверного слова. В работе используется JSON-интерфейс и запрос к API имеет определенную структуру (рис.12).

Рисунок 12. Шаблон запроса к Яндекс.Спеллер API

Яндекс.Спеллер API имеет два метода:

1) checkText

2) checkTexts

3.2.5.1 Метод checkText

Метод checkText проверяет орфографию в указанном отрывке текста и требует один обязательный параметр text (полный список параметров приведен в табл. 7).

Таблица 7

Список входных параметров для метода checkText

Параметр	Тип	Описание
Обязательные
text	string	Текст для проверки на наличие опечаток. Ограничения: · Для POST-запросов максимальный размер текста = 10000 символов. Для GET-запросов ограничивается размер всей строки запроса (не только текст, но и другие параметры). Максимальный размер строки = 10Кб (в Internet Explorer 6,7 = 2Кб).
Необязательные
lang	string	Языки проверки (перечисляются с разделителем-запятой). Возможные значения: · en -- английский; · ru -- русский; · uk -- украинский. По умолчанию ставится "ru,en".
options	int	Опции Яндекс.Спеллера. Значение параметра = сумма значений необходимых опций (см. Настройки Яндекс.Спеллера в табл 8). В данной работе используется options=518.
format	string	Формат текста. Возможные значения: · plain -- текст без разметки; html -- HTML-текст. По умолчанию ставится «plain»

Таблица 8

Настройки Яндекс.Спеллера

Опция	Значение (десятичное)	Описание (пример)
IGNORE_DIGITS	2	Пропустить слова, содержащие цифры.
IGNORE_URLS	4	Пропустить почтовые адреса, интернет-адреса и имена файлов.
FIND_REPEAT_WORDS	8	Подсвечивать повторы слов, идущие подряд.
IGNORE_CAPITALIZATION	512	Игнорировать неправильное употребление ПРОПИСНЫХ/строчных букв (например, в именах собственных).

3.2.5.2 Метод checkTexts

Метод checkTexts проверяет орфографию в указанных отрывках текста и требует один обязательный параметр text, который, в отличие от метода checkText, имеет тип массива строк. Ограничения на запросы и необязательные параметры аналогичны методу checkText.

3.2.5.3 Ответ на запрос к Яндекс.Спеллер API

Т.к. используется JSON-интерфейс, API возвращает ответ в формате JSON (рис. 11) с элементами:

- error: информация об ошибке (может быть как несколько так и могут отсутствовать)

- word: исходное слово

- s: подсказка (может быть несколько, могут отсутствовать)

Например, при отправке запроса:

возвращается ответ с ошибкой 1 (слова нет в словаре) и с ошибкой 3 (неправильное употребление прописных и строчных букв). Предполагаемые правильные варианты возвращаются в поле s (рис. 13: синхрофазотрон и Дубна).



Рисунок 13. Пример ответа на запрос к Яндекс.Спеллер API

В работе было принято решение отправлять на проверку опечаток только те слова, которые не нашлись в морфологическом словаре при приведении слов в начальную форму. Таким образом, в проверяемом разделе собирается список потенциально неправильных слов и отправляется одной строкой Яндекс.Спеллеру, используя метод checkText и параметр options = 518 (игнорируются проверки соблюдения прописных/строчных букв, слов, содержащих цифры и почтовые адреса/интернет-адреса и имена фалов. Все полученные исправленные варианты, если такие нашлись, и сами проверяемые слова используются при дальнейшей обработке текста на поиск совпадений с ключевыми словами, введенными авторизованным пользователем.

3.2.6 Принципы работы с Computer Vision API

Кроме текстовой информации в социальных сетях обрабатываются также и изображения для поиска объектов, которые могут совпадать с ключевыми темами запроса. Для распознавания объектов на фотографиях используется Computer Vision API, который имеет свой шаблон построения HTTP-запросов (рис. 14).

Рисунок 14. Шаблон запроса к Computer Vision API

После протокола соединения указывается локация (в данном случае North Europe), затем адрес API сервиса, версия (на данный момент есть только одна версия API), метод и параметры (опционально): особенности, детали и язык (подробное описание см. табл. 9)

Таблица 9

Описание параметров запроса к Computer Vision API

Параметр	Тип	Описание
visualFeatures	string	Особенности поиска, а именно тип возвращаемой информации (если используется несколько типов, они разделяются запятой): Categories: классифицирует содержание изображения; Тags: подробный список слов, связанных с содержанием изображения; Description: описывает содержание изображения полным английским предложением; Faces: определяет наличие лиц и если нашел, то пол, возраст человека; ImageType: определяет, является изображение рисунком или линией; Color: определяет цвет акцента, доминирующий цвет и является ли изображение черно-белым Adult: определяет, относится ли изображение к контенту 18+.
details	string	Строка, определяющая, какие специфичные детали возвращать. Возможные значения: Celebrities: идентифицирует знаменитостей, если они обнаружены на изображении. Landmarks: определяет достопримечательности, если они обнаружены на изображении.
language	string	Язык возвращаемого содержания изображения. Возможные значения: en: английский (по умолчанию); zh: упрощенный китайский.

Кроме параметров запрос должен иметь еще 2 свойства:

- ContentType: тип тела запроса, который содержит в себе url анализируемого изображения;

- Ocp-Apim-Subscription-Key: ключ из учетной записи, который дает доступ к использованию этого API.

Кроме свойств запрос должен иметь тело в формате JSON с полем «url», которое содержит ссылку на изображение: {"url":"http://example.com/images/test.jpg"}.

В данной работе используется visualFeatures=Tags, что означает, что в ответе на запрос будет содержаться список тегов, т.е. слов, которые связаны с контентом изображения. Кроме самих слов возвращается еще вероятность того, что объект на изображении определен верно (рис. 15).

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рисунок 15. Выделение содержания изображения с помощью Copmuter Vision API

Т.к. ответ возвращается на английском языке, необходимо переводить слова на русский язык для их дальнейшей обработки. С этой целью в данной работе используется Яндекс.Переводчик API.

3.2.7 Принципы работы с Яндекс Переводчик API

Для того, чтобы переводить слова с английского языка на русский, в данной работе использован Яндекс.Переводчик API. Он используется в случае перевода возвращенных тегов после обработки изображений, потому что в настоящее время рабочими в Computer Vision API остаются только английский и китайский языки.

API использует XML, JSON и JSONP интерфейсы. В данной работе используется JSON-интерфейс запроса, у которого есть определенный шаблон (рис. 16).

Рисунок 16. Шаблон запроса к Яндекс.Переводчик API

После протокола соединения и адреса API сервиса указывается версия (на данный момент актуальная 1.5), затем обозначение используемого интерфейса, метод translate, API ключ из учетной записи Яндекс.Переводчика для разработчиков и параметры, которые могут быть как обязательными, так и опциональными (подробнее см. табл. 10).

Таблица 10

Описание параметров запроса к Яндекс.Переводчик API

Параметр	Описание
key	API-ключ из учетной записи.
text	Текст для перевода. Можно использовать несколько раз в одном запросе. Ограничения: Для POST-запросов максимальный размер текста = 10000 символов. Для GET-запросов ограничивается размер всей строки запроса (не только текст, но и другие параметры). Максимальный размер строки = 10Кб (в Internet Explorer 6,7 = 2Кб)
lang	Языки перевода, направление перевода. Задается двумя возможными способами: · В виде пары кодов языков («с какого»-«на какой»). В виде кода конечного языка (например en), при этом сервис пытается определить исходный язык автоматически.
format	Формат текста. Возможные значения: · plain -- текст без разметки; html -- HTML-текст. По умолчанию ставится «plain»
options	options=1: включение в возвращаемый ответ автоматически определенного языка текста для перевода. При определении первоначального языка вручную параметр позволяет понять, правильно ли был указан исходный язык.
callback	Используется для получения JSONP-ответа, имя функции обратного вызова.

В разрабатываемом решении используются параметры lang=en-ru, т.к. объекты с фотографий приходят на английском языке. Возвращенные теги записываются в список строк, каждая из которых при запросе к Яндекс.Переводчик API записывается в отдельный параметр text (одной публикации соответствует одна строка тегов).

Ответ возвращается в формате JSON и содержит в себе переведенные слова-теги (рис. 17(а)) и код 200, который означает, что перевод был выполнен успешно либо ошибку (например, что ключ API неверный) (рис 17(б)).

Рисунок 17. JSON-ответ на запрос к Яндекс.Переводчик API

3.3 Построение графа друзей

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

3.3.1 Описание построения графа и инициализации профилей

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

Алгоритм создания дочерних узлов происходит в несколько этапов.