«Программирование социальных взаимодействий»

Раздел: Социальные сети

В предыдущей публикации я ставил вопрос о стандартизации команд, с помощью которых можно управлять социальными взаимодействиями в интернете. Насколько я понимаю, предмет в такой постановке исследован мало, поэтому этот текст является скорей затравкой к размышлениям и обсуждению. Если брать наиболее «материальный» (непосредственно наблюдаемый) аспект, человек в сети это а) совокупность контента, созданного им на разных ресурсах. В несколько менее материальном виде человек есть б) «центр влияния» — нечто, разными способами влияющее на появление и исчезновение чужого контента. Вероятно, кульминацией обоих тезисов является утверждение, что человек в сети (и в социуме вообще) – это его имя. То же можно сказать о сообществах и организациях. Поэтому управление социальными взаимодействиями людей в интернете сводится в основном к операциям с контентом.

Производство контента всегда происходит в определенном контексте, который предоставляется различными сервисами – их функционалом и позиционированием. Они явно или неявно задают типы создаваемых контент-объектов, начиная от базового деления на текстовые, фото, видео и аудио, заканчивая более детальной типизацией по жанрам. Обычно базовые типы явно определены в функционале, а позиционирование сервиса по умолчанию задает жанровую типизацию. Например, текст может быть комментарием, романом, тезисом, стёбом, стихом и т. д. Даже если вопрос ставится об абстрактных операциях, реализованы они могут быть только в рамках конкретного сервиса. Поэтому скорей позиционирование такого сервиса должно быть достаточно универсальным (об этом ниже). Но в пределах этого универсализма обычная роль контекста не будет выполняться и все типы придется декларировать явно. Какие все? Жанровое разнообразие достаточно велико и вряд ли может быть полностью определено заранее. Поэтому создание типа в такой системе превращается в отдельную операцию. Это тем более актуально, если речь не только о контент-объектах. Например, человек не является контент-объектом, а скорее их совокупностью, как сказано выше. Вообще совокупность – одна из наиболее часто встречающихся вещей в природе и социуме. Те же сообщества, социальные сети, любого рода человеческие организации. Так что её стоит выделить в отдельный тип «множество». Тип и сам по себе является множеством, это объединение объектов в одно множество по некоторому общему признаку. Обратное верно не всегда; если некая совокупность уникальна, она по-определению не является типичной. Т.е. множество – понятие более общее и его создание можно было б использовать в качестве базовой операции вместо создания типа, а затем относить (связывать) конкретные объекты с конкретными множествами, что фактически и означало бы типизацию этих объектов. Но наверное слово «тип» (класс, сорт, род и т. п.) более привычно для восприятия, мы привыкли мыслить известными стандартными типами, т.к. это облегчает и ускоряет общение и осмысление.

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

Заметное усложнение, связанное с явным декларированием типов объектов и связей, имеет с другой стороны еще более заметное преимущество, связанное с тем, что типизация объектов перестает быть жестко фиксированной, одни и те же объекты могут принадлежать разным множествам. Текст может быть одновременно комментарием, стёбом и стихом, а также принадлежать множеству всех объектов (не только текстов), созданных одним автором. Если этот автор относится к некому сообществу, этот текст будет связан и с этим сообществом. А также с направлением в искусстве, если брать шире. Еще он будет принадлежать множеству всех объектов (тоже не только текстов), созданных в конкретный день (месяц, год, ..). В такой системе можно быстро выделять специфические множества объектов по разным общим признакам. Или обнаруживать все связи одного объекта. Зачем это нужно? Наверное, для разных целей. Для исследований, осмысления, анализа, статистики, маркетинга. Для контекстной рекламы и пиара. Для формирования социальных связей в сообществах по подробно классифицированным интересам. Возможно также, это удобный инструмент описания очень сложных вещей типа Большого Адронного Коллайдера со всей его физической начинкой и инфраструктурой, сопутствующей вычислительной инфраструктурой и программным обеспечением, сопутствующими коллективами разработчиков, не говоря уже о сопутствующих идеях. Стратегической целью является среда для создания авторских или коллективных проектов. Вы создаете множество и устанавливаете правила формирования контента в нем. Если среди элементов этого множества допустимы другие множества, можно строить очень сложные вещи. Которые и есть проекты. Хотя, конечно, что такое проект – тема отдельной статьи. Скажем, многие проекты сводятся к этому, но не все. Например игровые вещи, связанные с визуализацией образов, сюда не входят.

Это выводит нас на пункт б), указанный в начале. Человек влияет на создание контента другими. Непосредственными и формальными средствами, если он например модератор или создатель проекта. А также неявными и неформальными, если обладает известностью и/или авторитетом – он может ставить темы, которые начинают обсуждать многие, влиять на течение дискуссий. Варианты демократии тоже имеют место, когда решение о наказании принимается коллективно. Но с активностью масс сейчас больше связаны методы косвенного поощрения или неодобрения, что имеем в системах пользовательских голосований. В контексте обсуждаемого речь идет о формализации этих вещей. Из предыдущего рассмотрения можно выделить четыре операции – создание объектов и типов объектов, связей и типов связей. Создание подразумевает возможность удаления, а также изменения/редактирования, т.е. операций получится больше четырех. Соответственно, модераторские/администраторские полномочия относятся к этим операциям. Вопрос только, в каком пространстве действуют эти полномочия. Ответ – внутри объекта. Для этого объект должен иметь подходящий тип. Конечно это тип «множество», но с дополнительной уточняющей типизацией, например «сообщество». В сложных системах возникает необходимость делегирования полномочий, когда некий человек или сообщество внутри своего (авторского) пространства наделяет определенными полномочиями других людей (в том числе снова наделять полномочиями) и определяет подпространства, в которых эти полномочия действуют. Такая схема точно соответствует тому, что имеем в традиционном социуме в иерархиях отношений начальник – подчиненный. Наделение правами на выполнение операций – независимое от самих операций действие, его нужно рассматривать как отдельную операцию. В которой указаны объект делегирования (наделяемый правами человек или множество людей), область действия прав (объекты), сами права.

В «реале» возможна и часто реализуема ситуация, когда сообщества людей (народ) делегируют другим людям (правителям) или сообществам (например депутатам) намного больше полномочий, чем имеют сами. Но там и полномочия гораздо разнообразней указанных здесь операций с контентом и доступом к таким операциям. Пирамида отношений начальник – подчиненный в традиционном социуме держится на компетенциях, деньгах и социальных связях, а также на том, что всё это задействовано в рамках общих проектов. Фактор денег в социальных взаимодействиях играет важную роль и должен быть учтен, если требуется формализовать операции социальных взаимодействий в сети. Как его формализовать в рамках описанной системы объекты – связи? Можно связывать с объектами-людьми и сообществами (организациями) объекты денежного типа — «кошелек», «фонд», «казна» и прочее. В которых будут содержаться условные денежные единицы. С ними необходимы, по-видимому, следующие операции: 1) установление (внутри некоторого пространства – множественного объекта) курса обмена по отношению к реальным деньгам, 2) пополнение счета внутри денежного объекта, 3) обналичивание из денежного объекта, 4) перевод денег в другой объект денежного типа. Соответственно эти операции следует включить в операцию делегирования полномочий. Возможен также другой вариант, если помимо объектов и связей ввести еще одну сущность – атрибут. Например, объекты-люди будут обладать атрибутами денег и рейтинга. Но по сути атрибут – это неявная форма связи и мне пока не очевидно, чем было бы оправдано его введение вместо явных связей.

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

Наверное, без традиционных программных инструкций и конструкций типа if, if – else тоже не обойтись. Еще одна видимая необходимость — операция пересылки контента между контентными объектами.

Интересно было б придумать конкретный пример программного кода на таком языке, реализующего какой-нибудь несложный проект. Допустим, кому-то пришло в голову создать проект блог-пространства, в котором посты в блогах публиковались бы только после одобрения редактора. А редакторами назначать блогеров с высоким рейтингом. Но это в другой раз. Пока мне кажется, что указанных здесь команд (инструкций, операций) достаточно, чтобы реализовать с их помощью значительное разнообразие сетевых проектов. В завершение кратко напомню эти операции: несколько из них относятся к оперированию с контентом (создание-удаление объектов, связей и их типов), операция делегирования полномочий, несколько операций с объектами денежного типа и рейтингами, операция пересылки контента и всё это дополняется некоторыми традиционными операциями программирования. К этому списку я добавил бы еще одну очень продвинутую на мой взгляд фишку, когда видимостью объектов и связей можно манипулировать. Не обязательно, например, кого-нибудь банить (закрывать доступ к операциям создания контента), вместо этого производимый им контент можно сделать невидимым для определенных множеств людей. В этой «операции невидимости» нужно указать объект/множество, которое не будет видеть объектов (и, возможно, связей), производимых другим указанным объектом-человеком (или объектом-множеством). Эта фишка с невидимостями стоила бы более детального рассмотрения, но для него не осталось места.

P.S. Вообще-то первоначально я планировал писать только об операциях социальных взаимодействий, никак не скатываясь в область элементов традиционного программирования. Однако почему-то вот так получилось. Я еще сам не успел всё это обдумать. Тем более что я в разных вещах не специалист, в программировании тоже. Так что можно бить больно :) Если конечно кому-то удастся дочитать до конца :)

Дата публикации: 2009-10-14

Источник