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 может быть составной частью многих других изделий, как [в схеме деления](https://github.com/bpmbpm/SemanticBPM/wiki/%D0%9C%D0%B5%D1%82%D0%B0%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BE%D0%B2#3-%D0%BE%D1%82%D0%BA%D1%83%D0%B4%D0%B0-%D0%BD%D0%BE%D0%B3%D0%B8--%D1%83%D1%88%D0%B8-%D1%80%D0%B0%D1%81%D1%82%D1%83%D1%82-%D1%81%D0%B2%D0%BE%D0%B9--%D1%87%D1%83%D0%B6%D0%BE%D0%B9-%D1%87%D0%B8%D1%82%D0%B0%D1%82%D1%8C-%D0%BE%D0%BF%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE-%D0%B8%D0%BC%D0%B5%D0%B5%D1%82-%D0%BE%D0%B1%D0%B7%D0%BE%D1%80%D0%BD%D0%BE%D0%B5-%D0%B7%D0%BD%D0%B0%D1%87%D0%B5%D0%BD%D0%B8%D0%B5)

Таким образом, применительно к процессам, есть дерево процессов «образ, эталон, концепт» (там – в этом дереве «p1.15» встречается ровно один раз) и дерево схем процессов, где p1.15 используется многократно (в разных gXX графах / схемах разных процессов) как экземпляр \ индивид. То же самое с исполнителями (там образ - орг-штатная структура), инструментами (ИТ-системами) и т.п.
Тут термин «экземпляр» употребляется не как «реально исполняемый экземпляр процесса» (точная дата старта и т.п.) или аналог интстанс для Ит-систем (развёрнуто на сервере с ip = 4.4.4.4).  
Пример детализации отношений из [Методов ARIS](https://docs.aris.com/10.0.27.0/yay-method-reference/en/#/home/494393/en/1) 

Итого: Примерно про это «изобретаем велосипед» [repo-metamodel-trig](
https://github.com/bpmbpm/SemanticBPM/wiki/%D0%9C%D0%B5%D1%82%D0%B0%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BE%D0%B2#repo-metamodel-trig), рис. 1.  
Вдруг мы не заметили и «до нас все придумали»? Вроде указанные в п. 1 и 2 вопросы – «лежат на поверхности». Понимаю, что ожидания завышены - скорее "что выше"  - еще раз убедиться в этом. 
Видимо не хватает «выразительной силы формальных моделей», которые могли бы формализовать «механику» бизнес-процессов, причем с одной стороны максимально математически, а с другой максимально практически, как например, в [ARIS Method](https://github.com/bpmbpm/doc/tree/main/BPM/ARIS/SCHEER/BASE). 

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

### История вопроса:
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