Осторожная попытка переосмыслить сложное: Как связать документы, диаграммы и знания?

[anastasiastepanova]

Можно отслеживать зависимости из разных доменов и не держать всё в голове

[mc2]

Выглядит отлично. Где можно загрузить код?

[UnrealPelmen]

Идея не нова, на самом деле. Например, хоть тот же Project Xanadu, который сейчас вроде даже не заброшен (вот ссылка на Журнал Код яндексовский, там доходчиво объяснено). Только у вашего проекта есть один недостаток, из за которого компании, у которых этот когнитивный долг есть, его использовать не будут - отсутствие интеграций со структурными форматами или с системами (Confluence, например). Им не выгодно заставлять каких-нибудь джунов отрывать от работы и заставлять перебивать всю документацию, а потом переучивать сотрудников. А если начинать составлять доки с нуля, то там половина фич избыточны (чисто субъективно).

[Elpiti]

Спасибо! Посмотрю xanadu. Интеграции дело наживное, задумка была показать концепт чтобы понять насколько прототип понятен и потенциально удобен

[Elpiti]

Посмотрел xanadu, визуально выглядит чем то похоже, но они не работают с узлами и связями, а больше про то чтобы собирать новые страницы из кусочков старых

[er-nest]

Очень круто! Можно ещё добавить уровни абстракции (по типу C4), чтобы сворачивать сложность, теоретически их тоже можно выразить слоями особого типа, с зависимостью родитель-потомок

[Elpiti]

Про вложенность тоже думал. С одной стороны она вроде как нужна для выражения дети-родители. С другой стороны если делать все слои одного уровня, то как-бкдто снижается когнитивная нагрузка думать на тему это новый слой или под-слой. А там где есть один подслой, может захотеться ещё и ещё один и мы опять начнем проваливаться в аналогию "вкладки, вкладки,и всюду вкладки"

[itGuevara]

Полагаю, что для решения задачи борьбы со сложностью нужно:
а) иметь полную картину (полный граф объектов и связей)
б) уметь фильтровать необходимые данные (объекты \ зависимости)

Как делать связанные данные, хорошо дает ответ Linked Data (технология, которая из данных делает знания, марка "Семантического клея"). Вопрос как фильтровать и представлять в графическом виде. Как вариант ver4p

Для "фильтрации" используют слои, теги и т.п., однако это все сводится к ведению типов объектов (классов) и типов связей, причем эта классификация может быть многоуровневая (подклассы и т.п.) и "вычисляемая" (reasoning и т.п.). Пока к сожалению известные "rdf-grapher" имеют слабые возможности по визуализации.

[Elpiti]

Да, вспомнил про ваш проект. А как его визуально пощупать? Я так понимаю он про то чтобы фильтрами оставить все также на одном слое - больше или меньше сущностей и связей верно? И это например может быть полезно для просмотра. А что в этом все со сценарием создания?

[itGuevara]

А как его визуально пощупать? 

Так ссылка была на github по ней через run на github Pages.

После запуска (github Pages) в "Загрузить пример RDF данных" выбрать например, Turtle в кнопка "Визуализировать", и будет картинка:

Суть в том, что каждый тип сущности и тип связи - имеет свой значок (легенда) и есть фильтры, которые отфильтровывают не нужное. Можно открыть два (несколько) окна и сравнивать одну исходную модель, но через разные фильтры.

Или совсем простой пример идеи: открыли ссылку, выбрали Turtle VAD кнопка визуализировать, в фильтрах убрали галку с vad:hasExecutor и на схеме VAD исчезли Исполнители под процессами (шагами).

Пока модели создаются через RDF - описание, сделать редактор - не проблема.

[innokentyBo]

Мне здесь не хватает семантики самих связей. Если страница в Confluence, договор и API связаны с одним объектом, граф показывает соседство, но не говорит, на какой источник сейчас можно опираться.

В работе с несколькими источниками мне полезно хранить тип связи, владельца, статус и дату вступления решения в силу. Тогда можно отличить «упоминает» от «следует из», «заменяет» и «утверждено владельцем».

Планируете ли вы различать такие связи? Без этого представление покажет противоречие, но не поможет определить, какое решение действует.