О чем будем делать следующий вебинар? Архитектурный трек развивать или аналитический?
Anonymous Poll
46%
Использование C4 в Онто
15%
Классификация требований
15%
Еще покрутим OntoAI
38%
Механики и лайфхаки Онто
15%
Свой вариант в комментариях
🧠 Цифровая тень: когда вам не нужен "живой" двойник
Коллеги, в мире сложных систем все чаще говорят о "цифровых двойниках". Но что, если ваша задача — не управлять процессом в реальном времени, а понимать его, анализировать или проектировать изменения? Тогда "цифровая тень" — ваш инструмент. И в Онто мы строим именно такие тени.
Двойник (Digital Twin)
Представьте живого робота-близнеца, виртуальную копию вашей системы. Он работает в режиме реального времени, "дышит" в унисон с оригиналом через потоки данных. Его задача — контролировать "здесь и сейчас", оптимизировать и предсказывать. Он может влиять на систему. Это инструмент оперативного управления.
Пример двойника:
Виртуальная модель стойки серверов + данные о температуре, загрузке, энергии в реальном времени. Он не только сигнализирует о перегреве, но и моделирует потоки, прогнозирует перегрузки, автоматически регулирует вентиляторы и задачи. Имеет всю информацию о серверах в моменте.
Тень (Digital Shadow)
Это слепок системы из ее объектов и их свойств, сделанный в важный момент или собранный по итогам периода. Она строится на исторических данных и контексте: логах, схемах, моделях, документации. Связь с реальной системой — односторонняя. Ее сила — в понимании "как это устроено и почему". Статичная картина для анализа и проектирования.
Пример тени:
Документация или UML-диаграмма работающей системы. Фиксирует замысел разработчиков. Не синхронизируется с кодом в реальном времени, не отслеживает текущее состояние.
Когда тень практичнее двойника? Когда вам нужно:
— Понять прошлое.
— Спроектировать будущее.
— Зафиксировать контекст.
— Работать с тем, что есть.
🔍 Вопрос вам, коллеги:
В каких ваших сценариях фокус на "тени" (история + контекст) был бы полезнее "живого" двойника? Делитесь кейсами.
Коллеги, в мире сложных систем все чаще говорят о "цифровых двойниках". Но что, если ваша задача — не управлять процессом в реальном времени, а понимать его, анализировать или проектировать изменения? Тогда "цифровая тень" — ваш инструмент. И в Онто мы строим именно такие тени.
Двойник (Digital Twin)
Представьте живого робота-близнеца, виртуальную копию вашей системы. Он работает в режиме реального времени, "дышит" в унисон с оригиналом через потоки данных. Его задача — контролировать "здесь и сейчас", оптимизировать и предсказывать. Он может влиять на систему. Это инструмент оперативного управления.
Пример двойника:
Виртуальная модель стойки серверов + данные о температуре, загрузке, энергии в реальном времени. Он не только сигнализирует о перегреве, но и моделирует потоки, прогнозирует перегрузки, автоматически регулирует вентиляторы и задачи. Имеет всю информацию о серверах в моменте.
Тень (Digital Shadow)
Это слепок системы из ее объектов и их свойств, сделанный в важный момент или собранный по итогам периода. Она строится на исторических данных и контексте: логах, схемах, моделях, документации. Связь с реальной системой — односторонняя. Ее сила — в понимании "как это устроено и почему". Статичная картина для анализа и проектирования.
Пример тени:
Документация или UML-диаграмма работающей системы. Фиксирует замысел разработчиков. Не синхронизируется с кодом в реальном времени, не отслеживает текущее состояние.
Когда тень практичнее двойника? Когда вам нужно:
— Понять прошлое.
— Спроектировать будущее.
— Зафиксировать контекст.
— Работать с тем, что есть.
🔍 Вопрос вам, коллеги:
В каких ваших сценариях фокус на "тени" (история + контекст) был бы полезнее "живого" двойника? Делитесь кейсами.
🔥3
Привет, друзья! 👋
Мы начали работу над открытым Манифестом смыслового мышления и приглашаем вас присоединиться к его созданию. Этот манифест посвящён не платформе Онто, а подходу к мышлению. В нём мы хотим показать, почему граф знаний и «цифровые тени» — это сильная стратегия для проектирования будущего, командной работы, креативного управления и мышления.
Манифест открыт для всех, и любой вклад важен — будь то идея, пример из опыта или правка текста, всё это поможет сделать документ лучше. Если вам близка тема осмысленного подхода к информации и знаниям, заходите на sensemanifest.ru и становитесь соавторами.
Давайте писать манифест вместе — дружно, интересно и с пользой для всех. 🙌
Мы начали работу над открытым Манифестом смыслового мышления и приглашаем вас присоединиться к его созданию. Этот манифест посвящён не платформе Онто, а подходу к мышлению. В нём мы хотим показать, почему граф знаний и «цифровые тени» — это сильная стратегия для проектирования будущего, командной работы, креативного управления и мышления.
Манифест открыт для всех, и любой вклад важен — будь то идея, пример из опыта или правка текста, всё это поможет сделать документ лучше. Если вам близка тема осмысленного подхода к информации и знаниям, заходите на sensemanifest.ru и становитесь соавторами.
Давайте писать манифест вместе — дружно, интересно и с пользой для всех. 🙌
❤5🔥3
Цифровизация без модели — это не MVP, а лотерея
#Варкулевич Артем Александрович
Генеральный директор и основатель ООО Онтонет
выступит на
#UDM25_4 25 Июля в 14:00 онлайн
Проблема:
На большинстве производственных ИТ-проектов MVP определяется не как «минимальный ценный продукт», а как «то, что можно выжать из команды до ближайшего дедлайна». При этом отсутствует общая модель требований, даже на уровне бизнес-архитектуры или доменной схемы. Решения принимаются на ходу, аналитики "режут фичи", а техдолг превращается в норму.
Основная идея:
Без единой модели предметной области и архитектуры MVP — это айсберг: видимая часть не отражает всей сложности, и это приводит к провалам при масштабировании. Даже если модель не реализована в коде, она должна быть зафиксирована и понятна всем участникам — от бизнеса до разработчиков.
Ключевые тезисы:
MVP — это не набор фич, это про цель и смысл, оформленные в модель.
Фича-дривен подход без целостной модели → ведёт к хаосу, снижению качества, и блокирует автоматизацию.
Требования должны укладываться в модель, даже если модули потом будут меняться.
Проекты, где MVP = «что успеем» — это проекты без контроля, где результат невозможно предсказать.
Архитектурная зрелость аналитики — ключевой фактор успеха цифровизации в промышленности.
🏭 Как привязать к промышленности:
Автоматизация производства — это всегда про системное мышление: цеха, материалы, потоки, ресурсы.
Без моделирования этих сущностей — автоматизация становится "рисованием интерфейсов".
Промышленность умеет работать с моделями в физике, логистике, планировании. Почему в ИТ всё иначе?
ontonet.ru
#Онто #Onto
https://t.me/+utYGnhBi0JQ2Mjcy
Страница конференции:
https://aps365.ru/event/udm25-4-it-na-sluzhbe-predpriiatiia-ai-erp-opex-122
#Онто_Мероприятия
#Варкулевич Артем Александрович
Генеральный директор и основатель ООО Онтонет
выступит на
#UDM25_4 25 Июля в 14:00 онлайн
Проблема:
На большинстве производственных ИТ-проектов MVP определяется не как «минимальный ценный продукт», а как «то, что можно выжать из команды до ближайшего дедлайна». При этом отсутствует общая модель требований, даже на уровне бизнес-архитектуры или доменной схемы. Решения принимаются на ходу, аналитики "режут фичи", а техдолг превращается в норму.
Основная идея:
Без единой модели предметной области и архитектуры MVP — это айсберг: видимая часть не отражает всей сложности, и это приводит к провалам при масштабировании. Даже если модель не реализована в коде, она должна быть зафиксирована и понятна всем участникам — от бизнеса до разработчиков.
Ключевые тезисы:
MVP — это не набор фич, это про цель и смысл, оформленные в модель.
Фича-дривен подход без целостной модели → ведёт к хаосу, снижению качества, и блокирует автоматизацию.
Требования должны укладываться в модель, даже если модули потом будут меняться.
Проекты, где MVP = «что успеем» — это проекты без контроля, где результат невозможно предсказать.
Архитектурная зрелость аналитики — ключевой фактор успеха цифровизации в промышленности.
🏭 Как привязать к промышленности:
Автоматизация производства — это всегда про системное мышление: цеха, материалы, потоки, ресурсы.
Без моделирования этих сущностей — автоматизация становится "рисованием интерфейсов".
Промышленность умеет работать с моделями в физике, логистике, планировании. Почему в ИТ всё иначе?
ontonet.ru
#Онто #Onto
https://t.me/+utYGnhBi0JQ2Mjcy
Страница конференции:
https://aps365.ru/event/udm25-4-it-na-sluzhbe-predpriiatiia-ai-erp-opex-122
#Онто_Мероприятия
👍5
Модель C4 — как просто описать сложное
Метод C4 появился в начале 2010‑х, когда классические UML-диаграммы всё чаще казались либо избыточными, либо бессистемными. Аналитики искали способ объяснять сущность контекста, его составляющих в определенной ситуации.
Так возник подход, который многие бизнес-архитекторы до сих пор не отпускают — четыре уровня представления, от общего к частному. Изначально он создавался для описания ПО, но сегодня C4 используют во многих сферах и отраслях для описания бизнес-процессов, оргструктур и даже метамоделей.
⚙️ Как это работает
Метод состоит из четырёх уровней. Когда внимание перемещается от верхнего к нижнему, его фокус меняется от стратегического обзора к тактическим моментам.
Каждый уровень состоит из объектов (или сущностей) и их взаимосвязей. Объекты представляют собой ключевые элементы, а связи - основу функционирования всего контекста. Платформа Онто позволяет создавать объекты и связи, сохраняет их в памяти пространства. Далее из этой базы объектов можно создавать сколько угодно представлений (диаграмм) разной степени детализованности. В том числе можно создать все 4 уровня модели С4.
1. Context (Контекст)
Определяется граница системы и её окружение. Кто в игре? Что на кону? Где проходит линия между "наше" и "внешнее"?
Это может быть отдел компании или контекст, отражающий управление магазином.
Уровень даёт понять «зачем нужен контекст» и «с кем он взаимодействует».
2. Container (Контейнер)
Контекст разбивается на крупные узлы — подразделения, рабочие команды, направления деятельности, блоки интерфейсов программы . Отвечает на вопрос «где» и «между кем».
3. Component (Компонент)
Внимание погружается внутрь каждого контейнера, уровень описывает его составляющие части, крупные блоки объектов. Например, участники команды, компоненты интерфейса.
На этом уровне становится видно, кто или что именно отвечает за какую функцию.
4. Code (Код)
Минимальный уровень абстракции.
Описание конкретных классов, функций, регламентов, шаблонов, протоколов. Изначально, когда С4 разрабатывалась для описания ПО, на этом уровне был код, описывающий действия элемента программы.
Здесь становится видно, как архитектурная модель переходит в конкретную реализацию.
🌐 Пример использования метода с использованием Онто мы приводили в одной из предыдущих публикаций.
Метод C4 появился в начале 2010‑х, когда классические UML-диаграммы всё чаще казались либо избыточными, либо бессистемными. Аналитики искали способ объяснять сущность контекста, его составляющих в определенной ситуации.
Так возник подход, который многие бизнес-архитекторы до сих пор не отпускают — четыре уровня представления, от общего к частному. Изначально он создавался для описания ПО, но сегодня C4 используют во многих сферах и отраслях для описания бизнес-процессов, оргструктур и даже метамоделей.
⚙️ Как это работает
Метод состоит из четырёх уровней. Когда внимание перемещается от верхнего к нижнему, его фокус меняется от стратегического обзора к тактическим моментам.
Каждый уровень состоит из объектов (или сущностей) и их взаимосвязей. Объекты представляют собой ключевые элементы, а связи - основу функционирования всего контекста. Платформа Онто позволяет создавать объекты и связи, сохраняет их в памяти пространства. Далее из этой базы объектов можно создавать сколько угодно представлений (диаграмм) разной степени детализованности. В том числе можно создать все 4 уровня модели С4.
1. Context (Контекст)
Определяется граница системы и её окружение. Кто в игре? Что на кону? Где проходит линия между "наше" и "внешнее"?
Это может быть отдел компании или контекст, отражающий управление магазином.
Уровень даёт понять «зачем нужен контекст» и «с кем он взаимодействует».
2. Container (Контейнер)
Контекст разбивается на крупные узлы — подразделения, рабочие команды, направления деятельности, блоки интерфейсов программы . Отвечает на вопрос «где» и «между кем».
3. Component (Компонент)
Внимание погружается внутрь каждого контейнера, уровень описывает его составляющие части, крупные блоки объектов. Например, участники команды, компоненты интерфейса.
На этом уровне становится видно, кто или что именно отвечает за какую функцию.
4. Code (Код)
Минимальный уровень абстракции.
Описание конкретных классов, функций, регламентов, шаблонов, протоколов. Изначально, когда С4 разрабатывалась для описания ПО, на этом уровне был код, описывающий действия элемента программы.
Здесь становится видно, как архитектурная модель переходит в конкретную реализацию.
🌐 Пример использования метода с использованием Онто мы приводили в одной из предыдущих публикаций.
Telegram
Онто.
Анонс видео: Закрепление ответственности микросервисов за этапы жизненного цикла бизнес-объектов в Онто
Конечно, при детальной проработке контекстов на C4 я традиционно закрепляю ответственность микросервисов за этапы жизненного цикла бизнес-объектов.
Но…
Конечно, при детальной проработке контекстов на C4 я традиционно закрепляю ответственность микросервисов за этапы жизненного цикла бизнес-объектов.
Но…
🔥5
Forwarded from #UDM Уральский Клуб Цифровизации #UralsDigitalMachinery
-
#UDM25_4 ИТ на службе ПРЕДПРИЯТИЯ AI + ERP ≠ OpEx
25 Июля в ПЯТНИЦУ 8:30 МСК
будет онлайн-конференция
Уральского Клуба Цифровизации
#UralsDigitalMachinery
Начнём в 8:30 МСК, как всегда. Страница конференции:
https://aps365.ru/event/udm25-4-it-na-sluzhbe-predpriiatiia-ai-erp-opex-122/
Сыылка на вход в конференцию:
https://uralsdigitalmachinery.ktalk.ru/ifdb96iascye
Заняли тайм-слоты (по Московскому времени):
8:30 МСК #Третьяков Игорь Вячеславович, эксперт автоматизации бизнес-процессов
Приветствие и Повестка , Обзор темы и представление докладчиков
9:00 МСК #IШерман Михаил Семёнович
10:00 МСК #Шебанин Сергей Павлович
#DDMRP в #Модули #ERP. Методология и практика ее внедрения
11:00 МСК #Малышев Станислав Олегович
https://alpeconsulting.ru/
Интеграция 1С и СПМ
12:00 #Широков Федор Сергеевич
руководитель и основатель компании #MAIПрактики
Почему лучшие практики ТОиР, будучи столь успешными, не работают повсеместно
13:00 МСК #Уваев Юрий Александрович
Конфигуратор продукции Aspect CPQ
#AspectAI
14:00 МСК #Варкулевич Артем Александрович
Генеральный директор и основатель ООО Онтонет
Цифровизация без модели — это не MVP, а лотерея
15:00 МСК #Третьяков Игорь Вячеславович
Архитектура автономного ИИ-эксперта
Пост можно пересылать.
Приглашайте в Клуб хороших людей по этой ссылке:
https://t.me/+e5XGtpUQ2IllODIy
Всем Добра! И пусть результаты будут лучше ожиданий!
Sincerely Yours
@Igor_V_Tretyakov
#APS365 - Автоматизация Производственных Систем
#UDM25_4 ИТ на службе ПРЕДПРИЯТИЯ AI + ERP ≠ OpEx
25 Июля в ПЯТНИЦУ 8:30 МСК
будет онлайн-конференция
Уральского Клуба Цифровизации
#UralsDigitalMachinery
Начнём в 8:30 МСК, как всегда. Страница конференции:
https://aps365.ru/event/udm25-4-it-na-sluzhbe-predpriiatiia-ai-erp-opex-122/
Сыылка на вход в конференцию:
https://uralsdigitalmachinery.ktalk.ru/ifdb96iascye
Заняли тайм-слоты (по Московскому времени):
8:30 МСК #Третьяков Игорь Вячеславович, эксперт автоматизации бизнес-процессов
Приветствие и Повестка , Обзор темы и представление докладчиков
9:00 МСК #IШерман Михаил Семёнович
10:00 МСК #Шебанин Сергей Павлович
#DDMRP в #Модули #ERP. Методология и практика ее внедрения
11:00 МСК #Малышев Станислав Олегович
https://alpeconsulting.ru/
Интеграция 1С и СПМ
12:00 #Широков Федор Сергеевич
руководитель и основатель компании #MAIПрактики
Почему лучшие практики ТОиР, будучи столь успешными, не работают повсеместно
13:00 МСК #Уваев Юрий Александрович
Конфигуратор продукции Aspect CPQ
#AspectAI
14:00 МСК #Варкулевич Артем Александрович
Генеральный директор и основатель ООО Онтонет
Цифровизация без модели — это не MVP, а лотерея
15:00 МСК #Третьяков Игорь Вячеславович
Архитектура автономного ИИ-эксперта
Пост можно пересылать.
Приглашайте в Клуб хороших людей по этой ссылке:
https://t.me/+e5XGtpUQ2IllODIy
Всем Добра! И пусть результаты будут лучше ожиданий!
Sincerely Yours
@Igor_V_Tretyakov
#APS365 - Автоматизация Производственных Систем
❤1
🚀 Новая глава в интеграции Онто и ИИ: MCP сервер уже в открытoм доступе! (Proof of Concept, но работает 😉)
Сегодня мы выложили в GitHub первый прототип Onto MCP сервера — теперь любой может:
1. Авторизоваться в Онто с помощью личного токена.
2. Запросить список своих пространств (realm ов) прямо из любимой нейросети — без подписки на OntoAI в ChatGPT.
Что уже готово
• 🔐 OAuth авторизация «как в Telegram боте».
• 🌐 Ресурс onto://spaces возвращает ваши рабочие пространства.
• 🐳 Docker образ → docker compose up и сервер слушает HTTP/STDIO.
Что появится на следующей неделе
• 📂 Доступ к диаграммам и объектам.
• 🛠 Инструменты для создания cтикеров/сущностей прямо из LLM.
• 📈 Метрики и роли доступа.
💬 Залетайте в issues, тестируйте, предлагайте фичи — следующая версия зависит от вашего фидбэка!
#Onto #MCP #AI #OpenSource
Сегодня мы выложили в GitHub первый прототип Onto MCP сервера — теперь любой может:
1. Авторизоваться в Онто с помощью личного токена.
2. Запросить список своих пространств (realm ов) прямо из любимой нейросети — без подписки на OntoAI в ChatGPT.
Зачем вам MCP?
MCP (Model Context Protocol) — это «USB порт» между Онто и LLM ами. Подключив MCP сервер, вы получаете данные из Онто там, где работаете:
• ✍️ Cursor или любой другой AI IDE — автокомплит знает структуру вашего домена;
• 🏄 Windsurf / JetBrains — кодовая база контекстуализируется онтологией;
• 📊 Excel — формулы обращаются к объектам Онто как к ячейкам базы знаний;
• 🤖 Любая LLM (GPT 4o, Claude 3, Gemini…) — выбирайте движок по задаче, а не по интеграции.
Что уже готово
• 🔐 OAuth авторизация «как в Telegram боте».
• 🌐 Ресурс onto://spaces возвращает ваши рабочие пространства.
• 🐳 Docker образ → docker compose up и сервер слушает HTTP/STDIO.
Что появится на следующей неделе
• 📂 Доступ к диаграммам и объектам.
• 🛠 Инструменты для создания cтикеров/сущностей прямо из LLM.
• 📈 Метрики и роли доступа.
Как попробовать
git clone https://github.com/hope4b/mcp
cd mcp
docker compose up # или python -m onto_mcp.server
# В LLM:
# 1) авторизуйся в Онто
# 2) дай список моих пространств в Онто
💬 Залетайте в issues, тестируйте, предлагайте фичи — следующая версия зависит от вашего фидбэка!
#Onto #MCP #AI #OpenSource
🔥4👍2
This media is not supported in your browser
VIEW IN TELEGRAM
🚀 Новая возможность: экспорт и импорт диаграмм в Онто
Онто обзавелась новой полезной функцией: теперь вы можете экспортировать и импортировать целые диаграммы (визуальные контексты) — с сохранением всей метамодели представленного на них фрагмента графа.
Для этого мы используем формат RDF/XML — в качестве транспорта, а не модели хранения. Внутри Онто ничего не поменялось: платформа по-прежнему не перешла на RDF-хранилище.
Онто vs RDF: нейтральные связи вместо триплетов
Помните, что в RDF данные описываются утверждениями вида «субъект — предикат — объект» (триплетами). В Онто же нет понятий субъекта и объекта, нет односторонних утверждений.
Такой подход сильно отличается от RDF, и мы сохраняем эту философию — RDF/XML нужен только для обмена данными.
Важно знать при импорте:
• Импорт диаграммы возможен только в пустую (новую) диаграмму.
• Существующие в вашем пространстве шаблоны и объекты не дублируются: если импортируемый файл содержит то, что у вас уже есть, Онто переиспользует эти элементы.
• На время импорта не вносите изменений в диаграмму — дождитесь, пока процесс завершится.
Попробуйте новую функцию уже сегодня и поделитесь обратной связью — нам очень интересно узнать ваше мнение! 😊
Онто обзавелась новой полезной функцией: теперь вы можете экспортировать и импортировать целые диаграммы (визуальные контексты) — с сохранением всей метамодели представленного на них фрагмента графа.
Иными словами, в файл выгружается не просто картинка, а все шаблоны, объекты и связи из диаграммы, которые затем полностью восстанавливаются при импорте.
Для этого мы используем формат RDF/XML — в качестве транспорта, а не модели хранения. Внутри Онто ничего не поменялось: платформа по-прежнему не перешла на RDF-хранилище.
Онто vs RDF: нейтральные связи вместо триплетов
Помните, что в RDF данные описываются утверждениями вида «субъект — предикат — объект» (триплетами). В Онто же нет понятий субъекта и объекта, нет односторонних утверждений.
Связи у нас нейтральные: представьте, что объекты — как планеты, а связь между ними — как гравитационное поле. Оба объекта влияют друг на друга, но ни один не является «главным» в паре.
Такой подход сильно отличается от RDF, и мы сохраняем эту философию — RDF/XML нужен только для обмена данными.
Важно знать при импорте:
• Импорт диаграммы возможен только в пустую (новую) диаграмму.
• Существующие в вашем пространстве шаблоны и объекты не дублируются: если импортируемый файл содержит то, что у вас уже есть, Онто переиспользует эти элементы.
• На время импорта не вносите изменений в диаграмму — дождитесь, пока процесс завершится.
Что это даёт на практике? Теперь вы легко можете:
• Экспортировать диаграмму и импортировать её в другом пространстве Онто — весь фрагмент знаний перенесётся со всеми типами и связями.
• Загрузить в Онто внешний файл RDF/XML (например, из другой онтологической системы) — платформа корректно интерпретирует его структуру и создаст соответствующие объекты и связи у вас.
Попробуйте новую функцию уже сегодня и поделитесь обратной связью — нам очень интересно узнать ваше мнение! 😊
👍4
Дерево принятия решения: какой инструмент импорта в Онто выбрать?
Платформа Онто предлагает несколько способов импорта данных. В зависимости от вашей задачи следует выбирать тот механизм, который эффективно загрузит информацию и интегрирует её в общую модель знаний. Рассмотрим два типичных сценария и определим, какой инструмент импорта лучше подходит в каждом случае.
Сценарий 1: Аудит и сбор данных из разрозненных источников.
Если необходимо провести аудит объектов (например, инвентаризация серверов по разным цехам) и собрать результаты от нескольких исполнителей, оптимально использовать механизм CSV-импорта. В этом случае данные предварительно структурируются в табличном формате (CSV): каждый исполнитель заполняет свою часть таблицы. Затем все наборы данных объединяются в едином пространстве знаний Онто с помощью CSV-импорта. Такой подход удобен для менеджеров: он позволяет классифицировать информацию, параллельно раздать задачи командам и впоследствии консолидировать полученные сведения в одном месте. CSV-импорт упрощает сбор и загрузку обширных списков объектов и их атрибутов, обеспечивая быстрый перенос данных из электронных таблиц в систему.
Сценарий 2: Синхронизация команд и объединение графов знаний.
Если требуется синхронизировать работу нескольких команд и «сшить» результаты их совместной аналитической (например, форсайтной) работы в виде единого большого графа знаний, рекомендуется воспользоваться механизмом RDF-импорта. RDF-импорт предназначен для загрузки данных, представленных в виде онтологий или связных графов (форматы RDF/OWL). Такой инструмент особенно полезен для инженерных команд: когда каждая группа разрабатывает свою часть модели знаний (свою онтологию), импорт RDF позволяет объединить эти фрагменты, сохранив все взаимосвязи между объектами. В итоге разрозненные части знаний интегрируются в целостную структуру Онто, образуя единое информационное пространство для всей организации.
Платформа Онто предлагает несколько способов импорта данных. В зависимости от вашей задачи следует выбирать тот механизм, который эффективно загрузит информацию и интегрирует её в общую модель знаний. Рассмотрим два типичных сценария и определим, какой инструмент импорта лучше подходит в каждом случае.
Сценарий 1: Аудит и сбор данных из разрозненных источников.
Если необходимо провести аудит объектов (например, инвентаризация серверов по разным цехам) и собрать результаты от нескольких исполнителей, оптимально использовать механизм CSV-импорта. В этом случае данные предварительно структурируются в табличном формате (CSV): каждый исполнитель заполняет свою часть таблицы. Затем все наборы данных объединяются в едином пространстве знаний Онто с помощью CSV-импорта. Такой подход удобен для менеджеров: он позволяет классифицировать информацию, параллельно раздать задачи командам и впоследствии консолидировать полученные сведения в одном месте. CSV-импорт упрощает сбор и загрузку обширных списков объектов и их атрибутов, обеспечивая быстрый перенос данных из электронных таблиц в систему.
Сценарий 2: Синхронизация команд и объединение графов знаний.
Если требуется синхронизировать работу нескольких команд и «сшить» результаты их совместной аналитической (например, форсайтной) работы в виде единого большого графа знаний, рекомендуется воспользоваться механизмом RDF-импорта. RDF-импорт предназначен для загрузки данных, представленных в виде онтологий или связных графов (форматы RDF/OWL). Такой инструмент особенно полезен для инженерных команд: когда каждая группа разрабатывает свою часть модели знаний (свою онтологию), импорт RDF позволяет объединить эти фрагменты, сохранив все взаимосвязи между объектами. В итоге разрозненные части знаний интегрируются в целостную структуру Онто, образуя единое информационное пространство для всей организации.
Вывод: Выбор инструмента импорта зависит от характера данных и целей интеграции. Для табличных сведений и распределённого сбора информации (типично для управленческих задач) лучше всего подходит CSV-импорт. Для комплексных структур знаний и объединения результатов работы разных команд (часто технических или исследовательских проектов) лучше всего подходит RDF-импорт. Применяя правильный подход к импорту, и менеджеры, и инженеры смогут эффективно наполнять Онто данными, ускоряя совместную работу и развитие общей базы знаний.
Интерфейс диаграмм стал удобнее — посмотрите, что изменилось
Мы внесли несколько обновлений в интерфейс работы с диаграммами — всё самое важное мы для вас аккуратно подсветили оранжевыми маркерами.
Вот краткий обзор:
1. Сайдбар теперь разворачивается по-новому — управление им стало более точным и удобным.
2. Появилось меню экспорта и импорта — прямо на верхней панели. Теперь вы можете выгружать диаграммы в SVG или RDF/XML, а также загружать RDF-графы.
3. Кнопка «Поделиться» переехала — теперь она находится рядом с названием диаграммы, чтобы всегда быть под рукой.
4. Кнопка помощи переехала к панели масштабирования — логично и ближе к действиям по навигации.
Мы постарались сделать так, чтобы работа с диаграммой стала понятнее и быстрее. Протестируйте обновления — и, как всегда, будем рады обратной связи.
Мы внесли несколько обновлений в интерфейс работы с диаграммами — всё самое важное мы для вас аккуратно подсветили оранжевыми маркерами.
Вот краткий обзор:
1. Сайдбар теперь разворачивается по-новому — управление им стало более точным и удобным.
2. Появилось меню экспорта и импорта — прямо на верхней панели. Теперь вы можете выгружать диаграммы в SVG или RDF/XML, а также загружать RDF-графы.
3. Кнопка «Поделиться» переехала — теперь она находится рядом с названием диаграммы, чтобы всегда быть под рукой.
4. Кнопка помощи переехала к панели масштабирования — логично и ближе к действиям по навигации.
Мы постарались сделать так, чтобы работа с диаграммой стала понятнее и быстрее. Протестируйте обновления — и, как всегда, будем рады обратной связи.
🔥5
🚀 Онто MCP‑сервер: первый публичный релиз
Я завершил настройку и отладку MCP‑сервера для Онто. Теперь любой внешний инструмент, умеющий говорить по Model Context Protocol, может получать данные из вашего графа знаний — напрямую и без OntoAI‑чата.
Что уже работает
• list_available_realms — возвращает все ваши пространства (realm’ы).
• search_templates — ищет шаблоны внутри выбранного пространства по части названия.
• search_objects — ищет объекты того же пространства (по имени, шаблону или комментарию).
Этих трёх вызовов хватает, чтобы быстро найти нужную сущность в любой IDE, Excel‑плагине или в чат‑клиенте вроде Claude Desktop или Junie for JetBrains (это приложения, а не модели — именно так их и используем).
В чем польза?
Теперь вашим разработчикам не нужно открывать интерфейсы Онто или других систем управления знаниями, чтобы найти информацию о нужном модуле или теме — всё доступно напрямую из их рабочего инструмента.
Что дальше
Следующий релиз добавит создание/редактирование объектов и полную синхронизацию функций с OntoAI. Жду вашего фидбэка в issues GitHub!
#Onto #MCP #GraphKnowledge
Я завершил настройку и отладку MCP‑сервера для Онто. Теперь любой внешний инструмент, умеющий говорить по Model Context Protocol, может получать данные из вашего графа знаний — напрямую и без OntoAI‑чата.
Что уже работает
• list_available_realms — возвращает все ваши пространства (realm’ы).
• search_templates — ищет шаблоны внутри выбранного пространства по части названия.
• search_objects — ищет объекты того же пространства (по имени, шаблону или комментарию).
Этих трёх вызовов хватает, чтобы быстро найти нужную сущность в любой IDE, Excel‑плагине или в чат‑клиенте вроде Claude Desktop или Junie for JetBrains (это приложения, а не модели — именно так их и используем).
Как подключить
Поместите рядом с проектом конфигурацию MCP‑клиента — пример для Cursor, VS Code, Juni и других:
{
"mcpServers": {
"onto-mcp": {
"command": "python",
"args": ["-m", "onto_mcp.server"],
"cwd": "/путь/к/проекту/mcp",
"env": {
"ONTO_API_BASE": "https://app.ontonet.ru/api/v2/core"
}
}
}
}
Запустите клиент и вызовите: найди в моем пространстве кошки среди домашних моего Барсика
В чем польза?
Теперь вашим разработчикам не нужно открывать интерфейсы Онто или других систем управления знаниями, чтобы найти информацию о нужном модуле или теме — всё доступно напрямую из их рабочего инструмента.
Что дальше
Следующий релиз добавит создание/редактирование объектов и полную синхронизацию функций с OntoAI. Жду вашего фидбэка в issues GitHub!
#Onto #MCP #GraphKnowledge
🔥4👍1
Вместе с Катей Костенко (автором замечательного, олдскульного канала Позовите архитектора) собрали максимально простой кейс использования Онто и OntoAI. Спасибо Кате за отличную идею.
Telegram
Позовите Архитектора!
Жизнь IT Архитектора на 360 градусов, добро пожаловать в мои тапки
🔥1
Моделирование Солнечной системы как онтологической структуры
Исходная идея заключалась в создании структурированного пространства, описывающего объекты Солнечной системы и связи между ними. Для реализации была выбрана онтологическая платформа Онто, позволяющая задать иерархию понятий, типы объектов, их отношения и визуализировать модель.
Шаг 1. Создание онтологического пространства
Мы начали с создания нового рабочего пространства под названием «Солнечная система». Это пространство стало базовым контекстом, в котором последовательно развивалась вся структура.
Шаг 2. Определение базовых шаблонов
Для описания объектов была создана иерархия шаблонов (meta-entities). В центре лежал шаблон «Объект», от которого унаследованы специализированные классы:
• Звезда — самосветящееся тело (пример: Солнце)
• Планета — классические планеты, вращающиеся вокруг звезды
• Карликовая планета — объекты, не очистившие свою орбиту
• Спутник — объект, вращающийся вокруг планеты
• Малое тело — астероиды, кометы и прочие малые объекты
Этот подход строго онтологический: каждая категория оформлена в виде шаблона, а не экземпляра. Таким образом, структура остается расширяемой и логически устойчивой.
Шаг 3. Создание объектов Солнечной системы
В пространство были добавлены реальные объекты:
• Солнце
• Планеты: Меркурий, Венера, Земля, Марс, Юпитер, Сатурн
• Карликовая планета: Плутон
Каждому объекту был назначен соответствующий шаблон, обеспечивая тем самым его классификацию в рамках онтологии.
Шаг 4. Связи между объектами
Далее была создана связь «вращается вокруг», которая используется для моделирования орбитальных зависимостей. Все планеты были логически связаны с Солнцем этой связью. Также была введена связь «имеет тип», использованная для привязки объектов к их таксономическому классу, но позже она стала избыточной благодаря переходу на шаблонную модель.
Шаг 5. Визуализация диаграммы
Заключительным этапом стало создание диаграммы «Орбиты планет вокруг Солнца». В центре был размещён объект «Солнце», а остальные — расставлены по кругу, имитируя их орбитальное расположение. Между ними были проведены связи, отражающие факт обращения планет вокруг центральной звезды.
Диаграмма отразила не только структуру, но и взаимосвязи в системе, тем самым завершив формирование семантической модели.
Временные и итерационные затраты
Процесс моделирования занял примерно 1 час активной работы, включая все этапы — от концепции до готовой диаграммы. За это время в OntoAI было выполнено более 25 последовательных операций, включая:
• создание 7 шаблонов (включая базовый и специализированные),
• добавление и классификацию 10 объектов,
• построение 2 типов связей (онтологических и структурных),
• реализация 1 визуальной диаграммы с размещением всех объектов и связей,
• уточнение и корректировка структуры на нескольких этапах (например, отказ от ошибочной модели с объектами-классами и переход на шаблонную архитектуру).
Каждый шаг сопровождался логической валидацией структуры и её расширяемости, чтобы не только отразить текущую систему, но и заложить основу для будущего роста модели (например, добавление спутников, астероидов, миссий и наблюдателей)
OntoAI хорошо помогает убрать элемент взаимодействия с объектами напрямую, а так же поиска дополнительной информации. ссылка на диалог
Итоговая диаграмма вот по ссылке
Исходная идея заключалась в создании структурированного пространства, описывающего объекты Солнечной системы и связи между ними. Для реализации была выбрана онтологическая платформа Онто, позволяющая задать иерархию понятий, типы объектов, их отношения и визуализировать модель.
Шаг 1. Создание онтологического пространства
Мы начали с создания нового рабочего пространства под названием «Солнечная система». Это пространство стало базовым контекстом, в котором последовательно развивалась вся структура.
Шаг 2. Определение базовых шаблонов
Для описания объектов была создана иерархия шаблонов (meta-entities). В центре лежал шаблон «Объект», от которого унаследованы специализированные классы:
• Звезда — самосветящееся тело (пример: Солнце)
• Планета — классические планеты, вращающиеся вокруг звезды
• Карликовая планета — объекты, не очистившие свою орбиту
• Спутник — объект, вращающийся вокруг планеты
• Малое тело — астероиды, кометы и прочие малые объекты
Этот подход строго онтологический: каждая категория оформлена в виде шаблона, а не экземпляра. Таким образом, структура остается расширяемой и логически устойчивой.
Шаг 3. Создание объектов Солнечной системы
В пространство были добавлены реальные объекты:
• Солнце
• Планеты: Меркурий, Венера, Земля, Марс, Юпитер, Сатурн
• Карликовая планета: Плутон
Каждому объекту был назначен соответствующий шаблон, обеспечивая тем самым его классификацию в рамках онтологии.
Шаг 4. Связи между объектами
Далее была создана связь «вращается вокруг», которая используется для моделирования орбитальных зависимостей. Все планеты были логически связаны с Солнцем этой связью. Также была введена связь «имеет тип», использованная для привязки объектов к их таксономическому классу, но позже она стала избыточной благодаря переходу на шаблонную модель.
Шаг 5. Визуализация диаграммы
Заключительным этапом стало создание диаграммы «Орбиты планет вокруг Солнца». В центре был размещён объект «Солнце», а остальные — расставлены по кругу, имитируя их орбитальное расположение. Между ними были проведены связи, отражающие факт обращения планет вокруг центральной звезды.
Диаграмма отразила не только структуру, но и взаимосвязи в системе, тем самым завершив формирование семантической модели.
Временные и итерационные затраты
Процесс моделирования занял примерно 1 час активной работы, включая все этапы — от концепции до готовой диаграммы. За это время в OntoAI было выполнено более 25 последовательных операций, включая:
• создание 7 шаблонов (включая базовый и специализированные),
• добавление и классификацию 10 объектов,
• построение 2 типов связей (онтологических и структурных),
• реализация 1 визуальной диаграммы с размещением всех объектов и связей,
• уточнение и корректировка структуры на нескольких этапах (например, отказ от ошибочной модели с объектами-классами и переход на шаблонную архитектуру).
В процессе потребовалось несколько итераций уточнения подхода:
1. первоначальная идея с шаблоном «Класс объекта» была признана методологически неверной;
2. после обсуждения была внедрена правильная онтологическая таксономия;
3. визуальная часть диаграммы формировалась на основе актуального положения объектов в круговой схеме.
Каждый шаг сопровождался логической валидацией структуры и её расширяемости, чтобы не только отразить текущую систему, но и заложить основу для будущего роста модели (например, добавление спутников, астероидов, миссий и наблюдателей)
OntoAI хорошо помогает убрать элемент взаимодействия с объектами напрямую, а так же поиска дополнительной информации. ссылка на диалог
Итоговая диаграмма вот по ссылке
🔥3
🚀 Onto × MCP — ещё один левел‑ап!
Теперь через MCP можно не только читать граф, но и создавать его:
• новое пространство (realm)
• любой шаблон (meta entity)
• объект с нужным шаблоном и комментарием
Что это значит на практике
1. Пустой проект → рабочий граф за минуту
В IDE пиши /new_realm "CRM‑2025" — MCP заводит пространство, шаблоны “Сделка” и “Клиент” и сразу открывает ссылки для команды.
2. “Одно слово в чате — новый термин в онтологии”
Аналитик вводит в Claude Desktop: “define PaymentGateway as техническая сущность” → шаблон и объект появляются в нужном пространстве без веб‑форм.
3. Синхронизация документации и графа
При ревью PR бот видит тег @Entity(Invoice) и, если его нет в Онто, автоматически добавляет шаблон и пустой объект “Invoice”.
4. Формирование песочницы для R&D
Data‑science‑группа запускает скрипт “/create_sandbox” — MCP поднимает отдельный realm, копирует нужные шаблоны и готовит площадку для экспериментов.
5. Экспресс‑бординг новой команды
В Slack команде пишут /setup_project "Логистика" — получаем realm, базовые шаблоны, стартовые сущности “Склад”, “Маршрут”, “Груз” и всю структуру сразу в их AI‑клиенте.
Напоминаем, что уже умеет MCP
🔍 list_spaces — показать ваши пространства
🔎 search_templates и search_objects — найти нужный шаблон или объект по части имени
✅ login — одна авторизация для всех инструментов
Подключайте любимую нейросеть (GPT‑4o, DeepSeek, Claude, GigaChat), пишите простые команды и стройте онтологию, не выходя из рабочего приложения.
💬 Фидбек и идеи — в комментарии или в GitHub issues!
Теперь через MCP можно не только читать граф, но и создавать его:
• новое пространство (realm)
• любой шаблон (meta entity)
• объект с нужным шаблоном и комментарием
Что это значит на практике
1. Пустой проект → рабочий граф за минуту
В IDE пиши /new_realm "CRM‑2025" — MCP заводит пространство, шаблоны “Сделка” и “Клиент” и сразу открывает ссылки для команды.
2. “Одно слово в чате — новый термин в онтологии”
Аналитик вводит в Claude Desktop: “define PaymentGateway as техническая сущность” → шаблон и объект появляются в нужном пространстве без веб‑форм.
3. Синхронизация документации и графа
При ревью PR бот видит тег @Entity(Invoice) и, если его нет в Онто, автоматически добавляет шаблон и пустой объект “Invoice”.
4. Формирование песочницы для R&D
Data‑science‑группа запускает скрипт “/create_sandbox” — MCP поднимает отдельный realm, копирует нужные шаблоны и готовит площадку для экспериментов.
5. Экспресс‑бординг новой команды
В Slack команде пишут /setup_project "Логистика" — получаем realm, базовые шаблоны, стартовые сущности “Склад”, “Маршрут”, “Груз” и всю структуру сразу в их AI‑клиенте.
Напоминаем, что уже умеет MCP
🔍 list_spaces — показать ваши пространства
🔎 search_templates и search_objects — найти нужный шаблон или объект по части имени
✅ login — одна авторизация для всех инструментов
Подключайте любимую нейросеть (GPT‑4o, DeepSeek, Claude, GigaChat), пишите простые команды и стройте онтологию, не выходя из рабочего приложения.
💬 Фидбек и идеи — в комментарии или в GitHub issues!
👍5
Forwarded from Архитектура ИТ-решений
С составом спикеров разговора об Archimate мы определились. Это:
- Artem Varkulevich
- Roman Tsirulnikov
- Kirill Keker
- Mikhail Zaborov
- Alexander Chertilin, и я
- Maxim Smirnov
а вот на темы разговора еще можно повлиять.
В комментариях к этому сообщению вы можете обозначить интересующие вас темы и задать вопросы спикерам
и, конечно, присоединяйтесь к зуму
📆 7 августа в 19:00 MSK
(ссылка будет в этом канале накануне)
- Artem Varkulevich
- Roman Tsirulnikov
- Kirill Keker
- Mikhail Zaborov
- Alexander Chertilin, и я
- Maxim Smirnov
а вот на темы разговора еще можно повлиять.
В комментариях к этому сообщению вы можете обозначить интересующие вас темы и задать вопросы спикерам
и, конечно, присоединяйтесь к зуму
📆 7 августа в 19:00 MSK
(ссылка будет в этом канале накануне)
🔥2
🎉 OntoRepa — Ассистент клонирования объектов в Onto
👇 Что умеет
• Мгновенно создаёт копии объектов, дублируя все поля и связи
• Позволяет задать, какие свойства и связи должны измениться в копии
• Автоматически формирует новые идентификаторы, исключая дубликаты
• Работает с любыми шаблонами и типами связей в вашем пространстве Onto
⚡ Как это происходит
1. Передаёте ассистенту объект-образец.
2. Сообщаете только отличающиеся данные (например, инвентарный номер или другой объект для связи).
3. Получаете готовую копию с обновлёнными свойствами и корректными связями.
4. Повторяете шаг 2 — создавайте десятки копий за считанные минуты.
---
📌 Пример сценария
Нужно завести много одинаковых датчиков, отличающихся лишь:
своим инвентарным номером;
местом установки — ссылкой на объект «Мачта» (координаты уже заданы у мачты).
С OntoRepa:
1. Указываете существующий датчик как образец.
2. Вводите новый номер и выбираете мачту.
3. Ассистент создает копию датчика и связывает её с выбранной мачтой.
⏱ Итог — быстрое массовое создание корректно связанных объектов без ручной рутины.
---
Попробовать 👉 https://chatgpt.com/g/g-6891e2cfde1481918fefadd5db4f0db0-ontorepa-ontoai-replication-assistant
👇 Что умеет
• Мгновенно создаёт копии объектов, дублируя все поля и связи
• Позволяет задать, какие свойства и связи должны измениться в копии
• Автоматически формирует новые идентификаторы, исключая дубликаты
• Работает с любыми шаблонами и типами связей в вашем пространстве Onto
⚡ Как это происходит
1. Передаёте ассистенту объект-образец.
2. Сообщаете только отличающиеся данные (например, инвентарный номер или другой объект для связи).
3. Получаете готовую копию с обновлёнными свойствами и корректными связями.
4. Повторяете шаг 2 — создавайте десятки копий за считанные минуты.
---
📌 Пример сценария
Нужно завести много одинаковых датчиков, отличающихся лишь:
своим инвентарным номером;
местом установки — ссылкой на объект «Мачта» (координаты уже заданы у мачты).
С OntoRepa:
1. Указываете существующий датчик как образец.
2. Вводите новый номер и выбираете мачту.
3. Ассистент создает копию датчика и связывает её с выбранной мачтой.
⏱ Итог — быстрое массовое создание корректно связанных объектов без ручной рутины.
---
Попробовать 👉 https://chatgpt.com/g/g-6891e2cfde1481918fefadd5db4f0db0-ontorepa-ontoai-replication-assistant
ChatGPT
ChatGPT - OntoREPa (OntoAI Replication Assistant)
Помогает создать клон объекта Онто с настраиваемыми свойствами и связями
🔥3👍1