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

Вернёмся к примеру с авиарейсом из прошлой статьи. Допустим, у нас есть файл-"понятие" с кратким константным описанием какого-то рейса. Что делать нам с этим файлом? Содержащейся в нём (в самом "понятии") информации явно не достаточно для полноценного его использования. Если же мы дополним понятие изменяемыми сведениями - оно перестанет быть устойчивым - т.е., неизменным на протяжении приемлемого (с точки зрения резонности его использования в системах связанных данных) интервала времени. Кроме того, нам ведь нужны не только понятия, но и связи между ними - иначе какой же это семантик веб? А куда прописывать связи? Создавать для этого специальные базы данных? Или как?

Сам себе БД

А что, если понятие будет неизменяемой частью файла, а относящиеся к понятию дополнительные сведения - изменяемой? CID позволяет опознавать формат идентифицируемого контента, a сам формат мы можем определить по своему усмотрению. В первом приближении, скажем, так:

<c_len><concept>[<addition>]

- где c_len (concept length) - длина понятийной части, concept - само понятие, а addition - дополнительные сведения. Важным моментом здесь является то, что хеш в CID (который станет именем файла) мы будем считать только для понятийного блока - и имя файла будет соответствовать самому понятию, какой бы "прицеп" с доп. информацией мы к данному понятию ни пристегнули. Что из этого следует? То, что по одному имени (CID) можно будет собирать по сети самые разнообразные сведения.

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

<c_len><concept>[<a_type><addition>]

- где a_type (addition type) - код формата доп. части. Это может быть обычный текст или что угодно ещё (html, xml, json, изображение (формат), видео (формат) и т.д и т.п.). Кстати, само понятие тоже может быть представлено в разных форматах, поэтому следовало бы написать так:

<c_type><c_len><concept>[<a_type><addition>]

Ну, а если у нас не одно дополнение к понятию, а несколько? Да в разных форматах? Не пора ли вводить семантические связи - простые триплеты "субъект-предикат-объект", где в роли "субъекта" будет выступать понятие, а точнее - его CID? Тогда изменяемую часть файла можно разметить как простую файловую базу данных, содержащую семантические триплеты. При этом, в качестве "объекта" может выступать другой CID, либо литерал. На иллюстрации ниже показаны некоторые варианты содержимого файлов, построенных на одном и том же понятии. Все эти файлы имеют одинаковое имя: CID содержащегося в них понятия ("Понятие 1").

Например, файл 1 может содержать лишь базовые, неизменяемые сведения (понятие) о рейсе SU2583: название авиакомпании (Аэрофлот), точки маршрута (Лондон-Москва), IATA-код рейса. В файл 2 мог быть добавлен текстовый рассказ-отзыв одного из пассажиров об этом рейсе. В файл 3 кто-то мог добавить видео, связанное с данным рейсом. А файл 4 содержит целый набор связей-триплетов, увязывающих рейс (посредством CID1) со множеством других сущностей и свойств. Теперь гипотетический программный агент мог бы без особых ресурсозатрат шерстить сеть на предмет обнаружения определённого понятия (связанных с ним файлов) - т.е., реализовать подписку на данное понятие в том смысле, в котором мистер Бернерс-Ли говорил: "Вот что я поставлю в закладки".

Без графа не обойтись

Однако, есть кое-что ещё. Хотя CID является одной из базовых концепций IPFS, но для использования этого идентификатора нам IPFS особо и не нужна. Какая же особенность этой распределённой файловой системы способна предоставить нам "любопытную возможность", вынесенную в заголовок статьи?

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

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

Поскольку в имени файла у нас находится CID1, то CID блока дополнительной (изменяемой) информации CID2 разместим в самом файле, вслед за понятийным блоком:

Далее идёт addition info - блок служебной информации, описывающей структуру дополнительной (изменяемой) части файла. Он может включать, например, заголовок файловой БД, содержащей триплеты и доп. объекты, чьи CID задействованы в триплетах. В нашем случае, в упрощенном представлении, этот блок содержит лишь одно поле a_type, несущее код типа содержимого доп. части файла (у нас это - видео в формате mpeg-4). Видео размечается на блоки, каждый из которых получает свой хеш-идентификатор, как и само видео в целом (CID8). Таким образом, этот видеоролик, находясь внутри композитного файла, доступен извне для поиска и использования. Стало быть, с одной стороны, мы имеем преимущество работы с единым файлом (экономия файловых дескрипторов и места на диске, удобство хранения и использования информации, сгруппированной вокруг общей темы (понятия)), с другой стороны - имеем полноценную внутрифайловую адресацию. При желании мы можем подписывать и снабжать уникальными идентификаторами ("контент-адресами") и отдельные триплеты. Снабженные CID информ. объекты и высказывания по ним (триплеты) становятся подобны атомам, из которых слепляются, подобно молекулам, понятийные файлы. Будет всё это шевелиться, конечно, не быстро. Но ведь никто не отменял обычные реляционные БД, в которые заинтересованными сторонами может неспешно собираться информация из распределенной файловой понятийной системы, индексироваться и затем шустро и в удобном для конечного пользователя виде подаваться на стол.

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

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