Шесть принципов FSS
Принципы — это контракт между проектировщиками протокола и его пользователями. Если конкретное решение нарушает принцип, оно не попадает в спецификацию. Если соблюдается — принимается, даже если неудобно.
Принцип 1: Локальность знания
Нет «центральной Википедии». Каждый узел (человек, организация, ИИ-агент) содержит свой граф — Obsidian-подобную структуру с типизированными связями. Власть над графом полностью у владельца: что хранить, что публиковать, что удалять. Протокол не может заставить узел реплицировать данные, которые он не хочет хранить.
Это отличается от классического Linked Data, где предполагается, что любой URI dereferenceable и данные доступны публично. В FSS публикуются только семантические дайджесты — список типов сущностей и связей, которые узел готов раскрывать, без самих данных. Получить данные можно только через явный запрос с авторизацией. Это похоже на то, как PGP-ключи публикуются на keyserver, но переписка остаётся приватной.
Практическое следствие: нет единой точки отказа. Если конкретный узел уходит из сети, его триплеты исчезают, но протокол и остальные узлы продолжают работать. Это критически важно для долгосрочной устойчивости: проект не должен умирать вместе с компанией-разработчиком, как это произошло со многими Semantic Web стартапами 2010-х.
Принцип 2: Онтологии как контракты, а не диктат
Не одна глобальная OWL-онтология, а семейство максимальных совместимых
онтологий. Участники публикуют «карты совместимости»: «моя связь
author_of эквивалентна твоей wrote и
создал_произведение». Эти карты подписываются, версионизируются
и кэшируются другими узлами.
Принципиальный момент: маппинги между онтологиями — это двусторонние
контракты, а не унификация. Никто не обязан переходить на единую
онтологию. Если психолог использует связь вызывает_эмоцию, а
нейрофизиолог — активирует_амигдалу, FSS позволяет им сосуществовать,
а LLM-посредник предлагает маппинг только в момент запроса. Маппинг может быть
асимметричным, частичным или вообще отсутствовать — и это нормально.
Эта мягкость критически важна для принятия. Классический Semantic Web требовал согласия всех участников на единую онтологию, что блокировало adoption. FSS явно отказывается от этой цели: достаточно, чтобы два узла могли договориться о конкретном маппинге в момент взаимодействия, без глобального консенсуса.
Принцип 3: Смысл рождается в диалоге
Когда два графа встречаются, между ними работает LLM-посредник, который выполняет четыре функции: сравнивает типы связей, предлагает маппинги, проверяет эквивалентности через тестовые запросы, кэширует найденные маппинги для будущих взаимодействий. Это делает маппинги живыми: они обновляются по мере эволюции онтологий на каждой стороне.
Конкретный сценарий: узел A использует написан_в::1866, узел B
использует year_published::1866. LLM-посредник видит, что оба
узла отвечают одинаково на запрос «когда опубликован „Преступление и наказание“»,
и предлагает маппинг написан_в ≡ year_published. После
подтверждения обеими сторонами маппинг кэшируется и используется автоматически.
Если через год узел A добавляет в написан_в дату рукописи (а не
публикации), маппинг автоматически переходит в состояние «частичный» и
LLM-посредник начинает уточнять при запросах.
Этот принцип невозможен без зрелых LLM. В 2001 году Бернерс-Ли мог рассчитывать только на ручное проектирование маппингов, что и затормозило Semantic Web. Сейчас мы можем делегировать рутину модели, оставив человеку только подтверждение.
Принцип 4: Три уровня представления
Каждый факт хранится в трёх формах одновременно: текст (человекочитаемый, как в Obsidian), триплеты (RDF-подобно, для точных запросов), эмбеддинги (векторы, для семантического поиска и LLM). Машина ходит по всем трём, человек — только по первому.
Это решает давнюю проблему Semantic Web: конфликт между машиночитаемостью и человекочитаемостью. RDF отлично работает для машины, но никому не хочется читать RDF. Markdown прекрасен для человека, но машина не понимает структуру. FSS хранит оба представления синхронно, и LLM-агент отвечает за их консистентность: если пользователь правит текст, агент перегенерирует триплеты; если триплеты обновляются из внешнего источника, агент обновляет и текст.
Эмбеддинги — третий уровень, не заменяющий первые два, а дополняющий. Они нужны для семантического поиска («найди заметки про влияние Достоевского на экзистенциализм, даже если слово не используется») и для контекста LLM («вот релевантные триплеты и текст — ответь на вопрос»). Все три уровня хранятся локально и синхронизируются при изменениях.
Принцип 5: Доказательная достоверность
Каждый узел графа несёт provenance — откуда он, кем добавлен, какой доверительный уровень, когда истекает, какая оценка достоверности. Это решает проблему галлюцинаций LLM: ответ собирается из доказуемых триплетов с указанием источника, а не генерируется из вероятностного продолжения.
Конкретно, каждый триплет в FSS содержит: subject,
predicate, object, source (URI или
локальный ID), author (WebID или PGP-ключ), timestamp,
confidence (0..1), signature. При сборке ответа
LLM-агент обязан указать source для каждого утверждения. Если источник
неизвестен или триплет получен через маппинг с низкой уверенностью —
пользователь видит это явно.
Это принципиально отличает FSS от чистого LLM-подхода, где модель может уверенно галлюцинировать. В FSS модель работает только с триплетами, имеющими provenance; если триплета нет в графе, модель обязана сказать «не знаю» или предложить поискать в других узлах через federated запрос.
Принцип 6: Никаких платформ — только протокол
Как email не принадлежит никому, так и семантический обмен должен быть протоколом, поверх которого строятся продукты (Obsidian, Notion, корпоративные базы, ИИ-ассистенты). FSS явно отказывается от построения «платформы FSS» с регистрацией пользователей и центральным API — это был бы путь к монополизации и смерти протокола.
Reference-имплементация остаётся одной из многих, без привилегированного статуса. Если кто-то сделает лучшую имплементацию на Rust или Go — она имеет точно такие же права в сети, как официальная на Python. Маркетплейс онтологий (фаза 3) тоже не принадлежит никому: это git-репозиторий с pull requests, как npm, но без единого реестра.
Это самый трудный принцип для соблюдения, потому что коммерческое давление всегда толкает к «сделаем свою платформу и будем monetize». Но именно отказ от платформы — условие того, что FSS не повторит судьбу Semantic Web, который умер в значительной степени потому, что каждая компания пыталась построить «свой Semantic Web».
Принципы как чек-лист
| Принцип | Что запрещает | Что требует |
|---|---|---|
| Локальность | Обязательные облака, централизованные реестры | Суверенитет узла над данными |
| Контракты | Единую обязательную онтологию | Двусторонние маппинги |
| Диалог | Статичные маппинги навсегда | LLM-посредник для согласования |
| Три уровня | Только текст или только RDF | Текст + триплеты + эмбеддинги синхронно |
| Доказательность | Галлюцинации без источника | Provenance на каждый триплет |
| Протокол | Платформу с регистрацией | Открытую спецификацию + reference |