doc/Project/SemanticBPM/method/onto_concept.md

low-level process ontology

Историю и контекст вопроса см. ниже "История вопроса"

Уточнение

1. С одной стороны нужна «процессная онтология» (и практическая), которая формализует примерно такое: У бизнес-процесса есть вход и выход и ресурсы. Ресурсы, например, исполнитель, который в простом случае формализуется через орг-штатную структуру, в более сложном – есть промежуточный уровень: роль в процесс и далее маппинг на орг-штатную структуру. Фактически мы должны рассматривать бизнес-процесс как математическую функцию. Кстати еще до 1992 года (появление ARIS) Шеер и назвал бизнес-процесс как «function» и до сих пор этот синоним к "процесс \ операция" прописан в Методах ARIS. Выше только небольшой штрих к онтологизации бизнес-процесса на нижнем уровне.
2. Кроме того, есть технологический уровень. Назовем это «технологическая онтология». Она уже будет формализовать применимость «процессной онтологии» (см. п.1) в реальных системах (реальном ПО BPM). Например, возьмем процесс «Заколотить гвоздь», например, с id = p1.15. Он имеет собственное описание, например, в схеме (графе) процесса id=g1.15.
   p – от process, g – от graph (например, четвертый элемент в quad / TriG).
   Этот процесс имеет Один образ, эталон, концепт (его и отражает g1.15), где детализированы его подпроцессы и много экземпляров (индивидов одного образа «процесс p1.15») т.е. во множестве других схем процессов, где подпроцессом является p1.15. Следовательно id = p1.15 должно быть во всех этих схемах и отсылать на эталон. Иначе: децимальный номер p1.15 может быть составной частью многих других изделий, как в схеме деления

Таким образом, применительно к процессам, есть дерево процессов «образ, эталон, концепт» (там – в этом дереве «p1.15» встречается ровно один раз) и дерево схем процессов, где p1.15 используется многократно (в разных gXX графах / схемах разных процессов) как экземпляр \ индивид. То же самое с исполнителями (там образ - орг-штатная структура), инструментами (ИТ-системами) и т.п. Тут термин «экземпляр» употребляется не как «реально исполняемый экземпляр процесса» (точная дата старта и т.п.) или аналог интстанс для Ит-систем (развёрнуто на сервере с ip = 4.4.4.4).
Пример детализации отношений из Методов ARIS

Итого: Примерно про это «изобретаем велосипед» repo-metamodel-trig, рис. 1.
Вдруг мы не заметили и «до нас все придумали»? Вроде указанные в п. 1 и 2 вопросы – «лежат на поверхности». Понимаю, что ожидания завышены - скорее "что выше" - еще раз убедиться в этом. Видимо не хватает «выразительной силы формальных моделей», которые могли бы формализовать «механику» бизнес-процессов, причем с одной стороны максимально математически, а с другой максимально практически, как например, в ARIS Method.

Пока изобретаем велосипед в «repo-metamodel-trig» и ему подобных для построения ARIS-based системы BPM c RDF-based концепцией (семантическом движком), но вдруг "все не так" и намного проще или много сложнее, но подробно описано. Конечно «прям готового» не найти, но может какие-то «онто-фрагменты» есть? Это кусок взять отсуда, а этот отсюда, а вместе оно и даст "что было нужно" (см. выше). Нужна Процессная онтология по которой можно (прям почти) кодировать систему управления процессами: семантическую архитектурную (схемы архитектуры, ARIS-based) корпоративную wiki. "Нет ничего практичнее хорошей онтологии".
А «Подобные обсуждения и запросы в этом чате" и будут регулярны, пока ответа на них не найдем …
Про ARIS

История вопроса:

https://t.me/rusontology/9523 (01.03.25)

1. Может быть есть «практическая Онтология» для бизнес процессов? Низкоуровневая, которая позволяет упаковывать процессы / подпроцессов в treeview, управлять (формализовать в том же treeview) экземплярами одного и того же процесса. Т.е. то, что можно уже прямо программировать (т е. взять готовый концепт и его тупо кодировать). Все Арис - подобные системы имеют одинаковый интерфейс и логика их работы схожа. Хотелось бы найти подобную низкоуровневую онтологию, которая бы позволяла построить подобные системы. При этом сама нотация вторична: vad, epc и т п. Сами отношения, т е. семантика, в них (нотациях процессов) одинаковые, разница лишь в синтаксисе (значках, например, кораблики в vad). Примечание: тут как «раз зацепило»: "настоящая онтология - это математика" и проекция онтологий на некий матаппарат для обеспечения вычислений,
2. Мне тут не очень понятен вопрос. Наверняка вы знаете про DEMO, TOVE, eBPO и что там ещё, что можно считать инфраструктурой онтологизации бизнес-процессов или конкретно онтологиями. Концептуальный инвентарь BPMN также можно считать онтологией бизнес-процессов. Подобные обсуждения и запросы (https://t.me/rusontology/6871) в этом чате регулярны, вы сами в них участвуете. Видимо, что-то не решается. Не хватает чего-то - инструмента или выразительной силы формальных моделей

Дополнительные материалы

Помощь GPT
В каких известных онтологиях встречал формализацию процесса: процесс/ подпроцесс, вход, выход, исполнитель, инструмент, событие, операция, ветвление потока работ (workflow) и т.п.?
ChatGPT ответил:
Формализация процессов встречается в ряде известных онтологий, ориентированных на моделирование бизнес-процессов, производственных операций, научных исследований и других областей. Вот несколько онтологий, в которых можно встретить концепции процесса, подпроцесса, входов/выходов, исполнителей, инструментов, событий, операций, ветвления потока работ и т. п.:

1. Ontology of Plans (Plan Ontology, PSL - Process Specification Language) Разработана для формального описания процессов и планирования.
   Включает такие элементы, как действия (activities), события (events), ресурсы (resources), агенты (agents), входы и выходы (inputs/outputs), временные зависимости. PSL используется ISO (ISO 18629) и поддерживает формализацию рабочих процессов.
2. DOLCE+DnS Ultralite (DUL) Расширение онтологии DOLCE, адаптированное для онтологий, связанных с процессами и задачами. Имеет концепции событий (Event), ролей исполнителей (AgentRole), входов и выходов (hasParticipant, hasOutput), инструментов (hasInstrument). Поддерживает представление ветвлений через ComplexEvent и вложенные процессы.
3. Business Process Model and Notation (BPMN Ontology) Основана на стандартной нотации BPMN 2.0 и используется для описания бизнес-процессов. Включает:

• Tasks (задачи, операции),
• Events (события),
• Gateways (разветвления),
• Actors (исполнители),
• Artifacts (дополнительные элементы, такие как документы и данные). Часто используется в автоматизированных системах управления бизнес-процессами (BPMS).

4. TOVE (Toronto Virtual Enterprise Ontology) Одна из первых онтологий для моделирования предприятий, включает процессы и их исполнителей. Описывает:

• Activity (деятельность),
• Resource (ресурсы, входы и выходы),
• Agent (исполнители),
• Goal (цель процесса),
• Time (временные зависимости).

5. BFO (Basic Formal Ontology) Хотя сама BFO не специализируется на процессах, её расширения включают онтологии процессов, такие как OBI (Ontology for Biomedical Investigations). Включает категории: Process, Role, Object, Input, Output, Agent.
6. YAWL (Yet Another Workflow Language Ontology) Формальная онтология, построенная на основе YAWL, ориентированного на сложные потоки работ (workflow). Поддерживает разветвления, параллелизм, события, роли и исполнителей. Используется для автоматизации бизнес-процессов.
7. Enterprise Ontology (Uschold & King, 1995) Классическая онтология для описания бизнес-процессов предприятий. Включает концепции Activity, Actor, Resource, Commitment, Plan, Goal.

Итог: Если нужен максимально формализованный вариант для workflow-процессов, стоит обратить внимание на PSL, BPMN Ontology и YAWL. Если цель – более общая формализация процессов, то DUL, BFO и TOVE обеспечивают мощную концептуальную базу. https://chatgpt.com/share/67c6936c-3e08-8004-af55-e88ec2ad45f8