Архитектура · Принципы

Шесть принципов 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
Документ: principles.html · Версия: v0.1 · Обновлён: 2026-08-03