нету там никакого аппарата

я про классические ориентированные и неориентированные графы

это все бессмысленные абсолютно вещи

Может быть графически это легче решать? Типа дерева r-tree? У меня есть один проект на топологии, реализовал на основе mvstore от h2db

работа с графом одна - это просто прохождение по связям графа

без понятия. у нас хоть и графы с дугами в дуги, но как раз и моделируют все допустимые в системе пути на DAG, так что задача о поиске кратчайшего пути не стоит

хождение по графу это основа, да, но для разных целей уже много всего сделано
но может Вы разбираетесь лучше меня (вполне допускаю) и уже знаете что это всё сделано для гиперграфов, тогда мои вопросы отпадают.

но зачем нам какая то дополнительная вершина, если вершина влияет именно на связь между двумя другими вершинами? Это же самое естественное в данной ситуации, если рисовать: стрелочка от вершины C втыкается в стрелочку от вершины А в вершину B.
Хотя вот в SBGN PD, стандартизированной диаграмме процессов тоже мыслят вспомогательными вершинами. Там вводят специальный process node.
Но вот опять же clojure, совершенно органично ключом можно задать как вершину :с, так и ребро #{:a :b}. При кодировании диаграмм эти промежуточные узлы нафиг не сдаются.

...и ключом и значением

в моей задаче важно было найти паттерны взаимодействий, кстати в кложуре наверняка что то есть насчет матчинга мапов по вайлдкардам/регуляркам? Я делал в ракете, там что то есть, но не очень раскаченное

ну это и есть обход - ты находишь интересующий узел и рисуешь шаблон подграфа как

ой угодно сложности

это и есть поиск паттерна

тот же sql, только для графов

rdf, datalog?

Тут сложность не в кодировании, выше уже было написано что вы при таком подходе стандартный корпус алгоритмов не сможете применить - вам придётся эти алгоритмы модифицировать, но возможно у вас кейсы этого и не требуют

а в чем конкретно-то задача состоит? вдруг на встроенных функциях это все наколхозить можно

в чем я лично не сомневаюсь

кстати да, триплеты rdf позволяют такое делать