Выберите какой-нибудь рабочий документ, актуальный для вас. Попробуйте определить самостоятельно, составляет ли содержащаяся в нём информация только эпистему, или это уже можно назвать описанием, или уже моделью, или частично тем, а частично другим. Запишите свою оценку и аргументы в её пользу.
взял для анализа Process Flow Diagram. считаю этот документ моделью - т.к. от позволяет моделировать поведение участников процесса, предсказать их нагрузку и ожидаемые навыки, смоделировать отклонения от happy path
Загрузите в свою LLM, усиленную FPF, этот рабочий документ, и дайте ей команду "Определи как онтолог, является ли информация из этого документа чистой эпистемой/intensional object, описанием или спецификацией. При ответе на вопрос руководствуйся паттернами A1 и E10.D2 из FPF" .
вот онтологический анализ документа «Process Flow: Source Connection, Data Catalog, DQ and Data Lineage» по паттернам E.10.D2 и A.1 из FPF.
Применяю дидактическую память E.10.D2 (use → claims → entity → scheme → one needed neighbor)
-
Use (Принимающее использование): Документ предназначен для координации работы (work use) — он направляет конкретных участников (Data Owner, Data Steward, Data Custodian, Engagement team, Platform team) через последовательность шагов от решения подключить источник до получения DQ-отчётов.
-
Claims (Утверждения): Документ содержит утверждения о том, кто, что и в какой последовательности делает: «Step 10 — Decision to connect Source», «Step 60 — Work on ticket to connect the source», «Step 230 — Create DQ rules based on Business rules» и т.д.
-
Entity (EntityOfConcern — независимо управляемая сущность): EntityOfConcern здесь — это процесс подключения источника данных и обеспечения Data Catalog, Data Quality и Data Lineage в Ataccama. Это реальный операционный процесс, существующий независимо от данного PDF.
-
Scheme (Эффективная ReferenceScheme): Схема идентификации — нумерованные шаги (10, 20, 30… 340), swim-lanes по ролям , и milestone-маркеры (Source Connection enabled, Data Catalog enabled, Data Quality enabled).
-
One needed neighbor: Для текущего использования нужен describing-use viewpoint — документ выбирает точку зрения «операционный процесс с ролями POET/DG/EDGE» и представляет процесс именно через эту линзу.
Вердикт: Описание (Description), не спецификация и не «чистая эпистема»
Table
Критерий (по CC-D2)
Не «чистая эпистема» / intensional object
Результат
Документ — не сам процесс. PDF-носитель несёт форму публикации, которая выражает эпистему-описание; процесс существует независимо (CC-D2-3, CC-D2-7)
Критерий (по CC-D2)
Не спецификация (Spec)
Результат
Отсутствуют проверяемые утверждения (checkable claims) с явным harness или validation relation. Нет формального критерия «прошёл/не прошёл» для каждого шага. По repair move #8: «Replace …Spec names lacking checkable claims and a named harness or validation relation with …Description»
Критерий (по CC-D2)
Является описанием (Description)
Результат
Это эпистема (ClaimGraph), которая несёт утверждения о независимо управляемом процессе (EntityOfConcern), используется дескриптивно, с выбранной точкой зрения (операционные роли + последовательность шагов)
Уточнение по A.1.1
Документ работает в рамках ограниченной модели использования (bounded model-use structure): его scope — один конкретный процесс, и claim scope не выходит за пределы этого процесса. Это подтверждает, что перед нами описание процесса (process-description episteme), а не универсальная спецификация и не сам процесс.
Итого (в деловых терминах)
Документ — это описание операционного процесса, представленное в виде swim-lane диаграммы. Он описывает «как должно работать», но не содержит формальных проверочных критериев, которые позволили бы квалифицировать его как спецификацию. А сам процесс (подключение источников, каталогизация, DQ) — это независимая сущность, которую этот документ лишь описывает.
Если вам не понятен ответ LLM, скопируйте в запрос фрагмент ответа и попросите LLM его пояснить. Попросите её покритиковать этот текст, задайте вопрос, насколько это правильно.
Спросил LLM: Можно ли назвать это описание «моделью процесса»?
Короткий ответ: нет — в строгом смысле FPF слово «модель» здесь неточно и создаёт риск подмены.
Почему «модель» — опасное слово здесь
Согласно FPF, термин «модель» (model) имеет конкретное техническое значение. Паттерн A.22 и его специализация BoundedModelUseStructure (BMUS) определяют: модель — это эпистема, которая используется в рамках явно заявленной bounded model-use structure, то есть структуры с:
точно определёнными допущенными model-use holons (объектами, которые модель обслуживает)
явными obtaining-relation occurrences (отношениями, которые действительно выполняются)
applied constraints (ограничениями)
named bounded-model-use frame (именованной рамкой использования)
Документ не удовлетворяет этим условиям — у него нет:
- формально заявленной рамки model-use
- явных ограничений (constraints), которые можно проверить
- заявленных obtaining-relation occurrences между моделью и её потребителями
Что это на самом деле (в терминах FPF)
Согласно паттерну A.3.2, нужно спросить: является ли EntityOfConcern этого документа допущенным U.Method?
Вопрос
Есть ли здесь один идентифицированный Method (способ делания)?
Ответ
Да — процесс подключения источника к Ataccama с enablement DC/DQ/DL
Вопрос
Говорит ли документ что-то содержательное о том, как этот метод выполняется?
Ответ
Да — шаги, роли, последовательность
Вопрос
Значит это U.MethodDescription?
Ответ
Да — это описание метода (description episteme for a way of doing)
Итого
В деловых терминах:
Называть это «моделью процесса» — привычно, но в FPF это создаёт «display bias» и «graph-overread» (антипаттерн A.22.CGUS:8: «Pretty route as ontology» — когда карточка или граф принимается за саму структуру).
Точная квалификация: это описание метода (U.MethodDescription) — эпистема, чей EntityOfConcern — один допущенный метод , и чьи утверждения говорят, как этот метод выполняется.
Swim-lane диаграмма — это publication form (форма публикации) и presentation carrier (носитель), а не сама структура и не модель.
Если вы хотите использовать слово «модель» в рабочих документах, FPF рекомендует уточнить: «описание метода, опубликованное в форме swim-lane диаграммы» — это честно и не создаёт онтологической путаницы.
Сделайте выводы: где ваши догадки оказались правильными, а где нет. Опубликуйте результат в клубе МИМ.
Моя догадка про модель по мнению FPF оказалась не верной. Хотя возможно критерии FPF того, что такое “модель”, намного более строгие, чем в руководстве?