Фаза 3: Реестр онтологий и сообщество

Превратить протокол в живую экосистему. Публичный реестр онтологий, пакеты как у npm, голосование за эквивалентности, 100 активных узлов.

Зачем нужен реестр онтологий

В фазе 2 мы доказали, что два узла могут договориться о маппинге. Но если каждый узел использует свою собственную онтологию, маппинги становятся O(n²) задачей, что не масштабируется. Реестр онтологий решает эту проблему: вместо «каждый изобретает своё», сообщество поддерживает набор стандартных онтологических пакетов, которые покрывают общие случаи (фильмы, книги, музыка, наука, путешествия, и т.д.).

Это не возвращение к «единой обязательной онтологии» из Semantic Web — пакеты опциональны, и любой узел может использовать свою. Но если ваша онтология совпадает с пакетом films/v2, маппинг не нужен вообще. Реестр делает общий случай лёгким, а особый случай — возможным.

Как устроен реестр

Реестр — это git-репозиторий (на GitHub), где каждый онтологический пакет живёт в своей папке. Публикация — через pull request, как в npm. Версионирование семантическое (v1.0.0 → v1.1.0 → v2.0.0). Каждый пакет содержит OWL-файл с описанием предикатов, примеры использования, тестовые данные, лицензию. Подпись автора обязательна.

ontology-registry/
├── films/
│   ├── v1/
│   │   ├── ontology.ttl          # OWL description
│   │   ├── examples.json         # Sample triples
│   │   ├── tests.json            # Expected mappings
│   │   └── manifest.json         # Metadata
│   └── v2/
│       └── ...
├── books/
├── music/
├── science/
└── personal/
    └── daily-notes/

CLI-команды для работы с реестром: fss install films/v2 (установить пакет в локальный узел), fss publish my-package (опубликовать свою онтологию), fss search "films" (поиск по реестру), fss update (обновить все пакеты).

Голосование за эквивалентности

Помимо отдельных онтологий, реестр содержит карты эквивалентностей между предикатами разных онтологий. Например, «films/v2:rated эквивалентно personal-ratings/v1:score». Эти карты изначально предлагает LLM-маппер (из фазы 2), а пользователи голосуют за или против через pull requests. После порога голосов карта становится «подтверждённой» и используется всеми по умолчанию.

Это решает проблему «кто решает, что эквивалентно чему». В Semantic Web это делал консорциум (медленно, политизированно). В FSS — сообщество через голосование, с правом вето у автора онтологии. Это медленнее, но демократичнее и устойчивее.

Пакеты онтологий для запуска

Чтобы реестр был полезен с первого дня, core-команда (или партнёры) публикует 10+ пакетов в первые 3 месяца фазы. Это даёт критическую массу, без которой реестр пустует.

Каждый пакет — отдельный репозиторий внутри registry, со своим maintainer-ом. Core-команда поддерживает 4-5 базовых пакетов (films, books, music, daily, people), остальные — сообщество. Если для какого-то пакета нет maintainer-а, он публикуется как «unmaintained» с предупреждением.

CLI-инструмент fss

Командная строка — основной способ управления узлом для продвинутых пользователей. Плагин Obsidian (из фазы 1) остаётся для менее технических, но CLI даёт полный контроль. Команды:

# Управление узлом
fss init                    # Создать новый узел
fss start                   # Запустить локальный API-сервер
fss status                  # Статус узла, статистика графа

# Управление онтологиями
fss install films/v2        # Установить онтологический пакет
fss update                  # Обновить все пакеты
fss publish ./my-ontology   # Опубликовать свою онтологию

# Управление триплетами
fss reindex                 # Переиндексировать все заметки
fss reindex path/to/note.md # Переиндексировать конкретную заметку
fss graph stats             # Статистика графа

# Federated обмен
fss peers list              # Список известных узлов
fss peers add <webid>       # Добавить узел в доверенные
fss query "..."             # Federated запрос

# Поиск
fss search "..."            # Локальный семантический поиск
fss search --federated "..."  # С запросом к peers

Сообщество

Фаза 3 — это фаза сообщества. Протокол не взлетит без активных пользователей и контрибьюторов, и их нужно выращивать сознательно. Несколько активностей: ежемесячные virtual meetups (1 час, демо + Q&A), форум (Discourse или Lemmy instance), чат (Matrix или Discord), Twitter/Mastodon аккаунт с апдейтами, ежеквартальные публичные ретроспективы.

Презентации на конференциях — отдельный важный канал. Целевые конференции: PKM Summit, NAACL / ACL (semantic web трек), FOSDEM, HOPE, OpenSym. Цель — 3+ презентации за фазу 3, что даёт доступ к нужной аудитории (PKM-юзеры и open-source разработчики) и помогает recruiting.

Метрики фазы 3

Риски фазы 3

Три риска. Реестр не набирает критическую массу: если первые 10 пакетов не появляются, реестр остаётся пустым, и пользователи не видят смысла переходить. Смягчение: core-команда сама пишет 5+ пакетов в первые 3 месяца, не ждём сообщество. Раздоры в сообществе: голосования за эквивалентности могут стать предметом споров. Смягчение: чёткие правила голосования, право вето у автора онтологии, медиация от core-команды. Конкуренция с проприетарными решениями: Notion, Anytype, Tana могут выпустить похожие фичи. Смягчение: фокус на открытый протокол, не продукт — даже если Notion добавит типизированные связи, открытый реестр онтологий остаётся уникальным преимуществом.

← Назад к фазе 2 · Вперёд к фазе 4 →