Снится ли GGG Тиму Бернерсу-Ли?
В 2007 году знаменитый автор слова из трёх букв 'W' опубликовал в своем блоге рассуждения о востребованности слова нового, на сей раз — из трёх букв 'G'. «Гигантский Глобальный Граф» — так предполагалось это произносить в полном, необрезанном виде. О чём шла речь? О том, что слово «граф» больше подходит для обозначения технологии представления взамосвязанных данных, нежели «паутина», пусть даже и «семантическая». Термин не прижился. Отчасти, возможно, из-за некоторой тавтологичности, отчасти же — из-за того, что привычная «паутина» оказалась милее сердцу обывателя, чем какой-то «граф».
Ну, да ладно, «ГГГ» не всплыло взлетело — не беда, ведь в конце концов — это лишь один из возможных псевдонимов планетарной семантической сети. Но что представлялось сиру Тиму в качестве цели для достижения (с помощью новых-то технологий связывания данных)?… «Важны не документы, а то, что в них содержится. Очевидная истина.» — писал он, — »…когда я бронирую билет на авиарейс, меня интересует именно этот рейс. Не страница рейса на сайте путешествий или страница рейса на сайте авиакомпании, но URI самого авиарейса. Вот что я поставлю в закладки. И каким бы устройством я ни воспользовался для открытия закладки, оно будет иметь доступ к ситуационно зависимому обзору всего, что я знаю об этом рейсе из разных источников. Задача заказа и совершения рейса потребует множества взаимодействий. И на их протяжении, эти задача и рейс будут на первом месте в моём осознании, веб-сайты — на втором, а сети и устройства — на третьем.»
Со времени написания процитированного выше текста прошло уже без малого 14 лет. Но контент-менеджеры авиакомпаний по-прежнему, в массе своей, упорно не спешат присваивать URI авиарейсам, саботируя, таким образом, построение гениального ГГГ. Это возмутительно!… В чем причина такого вопиющего игнора? Однако… тут надо бы поразобраться.
URI и с чем его едят
Как известно, URI — это либо «где» (URL), либо «кто/что» (URN), либо и то и другое в одном флаконе. Допустим, некто Алёна работает менеджером в авиакомпании (скажем, в Аэрофлоте), в которой Тим собирается забронировать билет на рейс «Лондон-Москва». От своего начальства Алёна получила задание присвоить уникальные идентификаторы рейсам компании и разместить их на корпоративном сайте — чтобы программные агенты заинтересованных в данной сфере бизнеса игроков (или даже конечных потребителей информации) могли использовать эти идентификаторы и связанные с ними данные для привязки к ним собственного контента — и отправки оного заинтересованным же потребителям типа Тима. Что делать нашей менеджерице? Она знает коды аэрофлотовских рейсов по схеме IATA (интересующий Тима рейс имеет здесь обозначение SU2583), и первая мысль у неё, естественно — использовать для создания идентификаторов, уникальных в интернет-пространстве, эти коды. Казалось бы, сделать это должно быть элементарно просто: IATA — серьёзная организация, у неё должно быть своё пространство имён (NID) в системе URN, и тогда интересующий Тима рейс получил бы следующий ID: urn: iata: su2583. Алёна открывает страницу с зарегистрированными для URN пространствами имён — и упс, «iata» там нет. Любопытства ради наша вуменджер заглядывает в спецификацию, определяющую порядок регистрации новых пространств имён URN (хотя у неё и мысли не было подавать за ИАТА, или кого бы то ни было ещё, заявку на регистрацию NID) — и понимает, что тут всё не просто, ловить здесь нечего.
Тогда, может быть, тот же ИАТАшный код вставить в URL? Что-то вроде: aeroflot.ru/flights/su2583. А? Выглядит неплохо. Уникальность — в наличии. И по каждой такой ссылке можно разместить информацию о соответствующем рейсе. Алёна так и сделала. Доложила начальству о выполненном задании и забыла о нём…
Обратим же взор на другого нашего персонажа. Борис имеет собственный информационный сервис, собирающий отзывы пассажиров о совершенных ими (посредством разных видов транспорта) рейсах. В разделе, посвященном авиаперелётам, он использует те же IATA-коды для обозначения рейсов. Для эффективного индексирования поисковиками используется микроразметка по схеме schema.org/Flight. На сайте есть возможность подписки на новые отзывы о выбранных рейсах. Реализована мультиязычная поддержка с переводом отзывов «на лету» на требуемый язык. Но, увы, Тим об этом ресурсе не знает, хотя ему он, впоне вероятно, мог бы быть интересен. Не знает он и о том, что в Аэрофлоте придумали URI для интересующего его рейса SU2583. Как сделать так, чтобы Тим смог оперативно и с минимальными затратами времени получать релевантную информацию об интересующем его рейсе?
Ну, во-первых, чтобы пользователь смог «поставить в закладки» ID интересущего его предмета (явления, сущности), этот ID ему надо представить особо — дескать, вот этот самый идентификатор, по которому вы можете отслеживать всё, что связано с соответствующим предметом. То есть, везде, или почти везде, где предмет (в нашем случае — конкретный авиарейс) встречается на сайте, вслед за его наименованием полезно было бы в скобках указывать этот самый «URI», который Тим мог бы поставить в закладки (но что за «URI» это должен быть и URI ли вообще?)
Во-вторых, этот ID должен быть удобен для применения сторонним пользователям, не только тем, кто этот идентификатор придумал. Иначе — грош ему цена. И вот здесь сразу вырисовывается целый ряд нюансов…
Предположим, что к моменту написания данной заметки в списке зарегистрированных пространств имён для URN уже значилось бы NID «iata», и Алёна обозначила бы авиарейсы соответствующими идентификаторами типа urn: iata: su
Вариант же с URL, который применила Алёна, вполне рабочий. Идентификатор не отделён от описания предмета. Это удобно. Но, вот, Борис вряд ли захочет использовать в своей системе такие ID аэрофлотовских рейсов в качестве основных. Почему? 1) Потому, что он не уверен в том, что завтра эти идентификаторы не изменят на другие, он не имеет над ними контроля. 2) Потому, что описание рейса по ссылке идентификатора также в любой момент может быть подвергнуто изменению — как организационного, так и (не исключено) злонамеренного характера. Нет гарантии, что текст описания имеет достоверное авторство. 3) Потому, что само доменное имя авиакомпании тоже, хоть и более устойчиво к изменениям, изменчиво. 4) Потому, что Борис никому не обязан делать неявной рекламы, публикуя у себя ссылки на сторонние сайты. 5) Потому, что подобные ссылки, будучи идентификаторами рейсов, по сути ничем не отличаются от обычных гиперссылок — и не понятно, как представить их для пользователей ресурса, чтобы они видели, что это нечто особое. 6) Потому, что всяк будет горазд придумывать свою форму для подобных ссылок-идентификаторов — и за всем сим зоопарком не уследишь. 7) Потому, в конце концов, что техническая доступность описаний рейсов по данным ссылкам — также величина переменная. Вполне достаточно причин для антипатии, не так ли?
А что, если нам разом решить все эти проблемы? Как говорится, одним махом — семерых убивахом!
CID, твой выход
Мы пойдём другим путём. Мы будем идентифицировать не предмет (чтобы потом невесть где искать его описание), не изменчивое и неопределенное описание предмета (чтобы впасть в печали многия, см. выше), но лаконичное, неизменяемое описание, которое, по сути, само является расширенным идентификатором предмета — и называется понятием (concept). Понятие текстовое содержит лишь атрибуты — то есть неотъемлемые и не изменяемые свойства предмета, которые определяют его суть и позволяют однозначно его идентифицировать. Если один из атрибутов меняется — то меняется и сам предмет. Другая сущность → другой идентификатор. Например, для авиарейса атрибутами будут: авиакомпания, главные точки маршрута, ИАТА-номер. Возможно, расписание вылета. В общем случае, понятием может быть любой лаконичный «слепок» с предмета, любой образ: фото, аудио-запись, рисунок или схема — в общем, не только набор текстовых и числовых атрибутов. Как говорил кот Матроскин: «Усы, лапы и хвост — вот мои документы!» — и он был прав.
Нам важно, чтобы понятие было неизменным — чтобы на него можно было безбоязненно опереться. Как на фундамент укладываются по кирпичику стены, так и на четко определенные, неизменяемые понятия можно накладывать семантические связи, не опасаясь, что вся конструкция впоследствии рассыпется. Как сделать так? 1. Понятие должно быть представлено отдельным файлом. 2. Для этого файла должен быть подсчитан хеш. 3. Идентификатор (имя) файла будет содержать оный хеш. Более того, чтобы достоверно знать, кто ввёл в обиход данное понятие предмета, оно может быть скреплено электронной подписью автора.
Чтобы не зависеть от какого-то одного алгоритма хеширования, будем использовать мультихеш. Чтобы представить хеш-значение в удобной человекочитаемой форме и не зависеть при этом от какого-либо единственного алгоритма кодирования, будем использовать мультибейс. А чтобы наша основанная на хеш-значении ссылка-идентификатор указывала и на формат самого содержимого файла, заложим в неё ещё одно поле: мультикодек. В результате мы получаем самоопределяемый идентификатор контента CID (Content Identifier), используемый в таких проектах, как IPFS и IPLD — и полностью подходящий для того, чтобы быть используемым в качестве идентификатора понятия (Concept Identifier).
Теперь посмотрим, как всё это будет работать. а) Алёна составляет краткие описания рейсов (в общем случае — в произвольном текстовом формате, читаемом браузерами), помещая в них только те данные, которые не планируется менять в будущем. б) Затем она добавляет к каждому такому описанию цифровую подпись, служащую подтверждением того, что автором этих данных о рейсах является Аэрофлот. в) Далее Алёна с помощью нехитрой программы генерирует каждому файлу-понятию уникальный CID и проименовывает файлы полученными идентификаторами, делая, таким образом, понятия неизменяемыми. г) Ей остаётся разместить файлы в выбранной директории сайта, например, в той же aeroflot.ru/flights — и раскидать гиперссылки на них по страницам сайта компании, примерно в таком виде: «Рейс SU2583 (CID)», где URI гиперссылки будет состоять из собственно CID («что») и адресной части («где»). При этом, пока браузер не может открывать подобные файлы, он будет только предлагать их к скачиванию. Впоследствии же он сможет и открывать страницу с соответствующими данными (будь то простой текст, html-страница, данные в xml- или json-разметке, изображение, etc.), верифицировать ЭЦП и т.д.
Что же скажет на это Борис? «О, беллиссимо, это же совсем другое дело!» — пожалуй, что-то в этом роде. И действительно: 1) Теперь идентификаторы рейсов (связанных с рейсами понятий) неизменяемы. 2) Текст минималистичного описания (понятия) неизменяем и имеет подтверждённое электронной подписью авторство. 3), 4) Адресная часть ссылки теперь Бориса волновать не будет, поскольку он может сформировать её (при желании) сам — скачав файлы понятий и разместив их на своём сайте в подходящей директории. 5) Пользователь сайта, увидев за наименованием рейса ссылку на понятие (Concept ID), будет явно уведомлен о наличии неизменяемого идентификатора рейса, по которому можно искать дополнительную информацию. 6) Форма самого CID (без адресной части) единообразна и уже достаточно «устоялась» (недостатки предыдущей, начальной версии CIDv0 были исправлены в новой, зрелой версии CIDv1). 7) Техническая доступность понятий с распространением соответствующих файлов по сети будет лишь возрастать. Более того, сайты, их использующие, могут объединяться (с появлением LibP2P это стало не слишком сложно) в одноранговые сети, обмениваясь информацией по интересующим темам (CIDs) посредством протокола PubSub.
А что наш Тим? Теперь он будет точно знать, какой URI поставить в закладки. И грандиозный ГГГ, как бы он ни назывался впоследствии (ААА, БББ, ВВВ — на что фантазии хватит), из категории сказок и сновидений вполне может стать былью. О том же, как применение IPFS поможет выстраивать семантические связи между понятиями на основе CID, поговорим в другой раз.
