Я все время говорю, что мы работаем в условиях множественных неизвестных.
У нас есть текстовое требование, с помощью которого надо проверять ЦИМ. Но, мы не знаем:
1⃣ по каким правилам разметить схему требования;
2⃣ как интерпретировать схему, уложив её в этапы проверки;
3⃣ как, в конце концов, должен выглядеть результат, который сможет исполнить стороннее программное обеспечение.
Причем, каждое из этих X зависит друг от друга. Такая вот петрушка.
Сперва хотели плясать от структуры профилей проверки на коллизии CADLib Модель и Архив.
Т.е. взять текст требования, вручную, создать на его основе проверку (благо в CADLib есть вполне себе человеческий интерфейс для этого) и, затем, разработать механизм превращения одного в другое с помощью ИИ и прочей магии.
Но, вот в чем шутка, широкие возможности CADLib, открывают множество вариантов по отработке одной и той же проверки. И, нельзя забывать, что кроме CADLib есть и другие решения, в которых свои правила.
А для того, чтобы создать Большую Красную Кнопку для конвертации нужна не другая Большая Красная Кнопка с функцией "Сделай красиво". Нужны алгоритмы, учитывающие все возможные варианты конвертации, зависящие от текста требования и от возможностей ПО для проверки, способные выбрать наиболее эффективные и, главное, более-менее универсальные способы преобразования. Я не говорю "Невозможно ", я говорю "Может есть путь проще"?
Так что, снова возвратились к истокам и стали рассуждать, из каких звеньев будет состоять проверка. И это были:
✅ Выбор объектов в проверку по информационным свойствам.
Тут, внимание, многие программы позволяют даже использовать расчётные значения при выборе. Можно учитывать структурные связи, подчинённость объектов. Но нельзя брать в расчёт расстояния между объектами. Это можно сделать в другом звене:
✅ Условие проверки.
Тут мы уже оперируем исключительно тем, что выбрали на предыдущем этапе. Но можно принять решение на основании проверки информационных значений атрибутов объектов и их положения относительно друг друга. Есть даже программы, которые умеют делать измерения габаритов.
Из всего вышесказанного можно сделать вывод о том, какие типы операций нам надо разглядеть в тексте:
✅ пара "атрибут+значение" для выбора объектов;
✅ информацию о положении объектов для этапа проверки;
✅ пара "атрибут+значение", для принятия решения о нарушении.
Именно поэтому мы стали изобретать разметку текста, которая позволит идентифицировать все перечисленные выше сведения и.. разметку, создание которой можно будет автоматизировать с помощью волшебных современных технологий.
Кажется у нас получается)
У нас есть текстовое требование, с помощью которого надо проверять ЦИМ. Но, мы не знаем:
1⃣ по каким правилам разметить схему требования;
2⃣ как интерпретировать схему, уложив её в этапы проверки;
3⃣ как, в конце концов, должен выглядеть результат, который сможет исполнить стороннее программное обеспечение.
Причем, каждое из этих X зависит друг от друга. Такая вот петрушка.
Сперва хотели плясать от структуры профилей проверки на коллизии CADLib Модель и Архив.
Т.е. взять текст требования, вручную, создать на его основе проверку (благо в CADLib есть вполне себе человеческий интерфейс для этого) и, затем, разработать механизм превращения одного в другое с помощью ИИ и прочей магии.
Но, вот в чем шутка, широкие возможности CADLib, открывают множество вариантов по отработке одной и той же проверки. И, нельзя забывать, что кроме CADLib есть и другие решения, в которых свои правила.
А для того, чтобы создать Большую Красную Кнопку для конвертации нужна не другая Большая Красная Кнопка с функцией "Сделай красиво". Нужны алгоритмы, учитывающие все возможные варианты конвертации, зависящие от текста требования и от возможностей ПО для проверки, способные выбрать наиболее эффективные и, главное, более-менее универсальные способы преобразования. Я не говорю "Невозможно ", я говорю "Может есть путь проще"?
Так что, снова возвратились к истокам и стали рассуждать, из каких звеньев будет состоять проверка. И это были:
✅ Выбор объектов в проверку по информационным свойствам.
Тут, внимание, многие программы позволяют даже использовать расчётные значения при выборе. Можно учитывать структурные связи, подчинённость объектов. Но нельзя брать в расчёт расстояния между объектами. Это можно сделать в другом звене:
✅ Условие проверки.
Тут мы уже оперируем исключительно тем, что выбрали на предыдущем этапе. Но можно принять решение на основании проверки информационных значений атрибутов объектов и их положения относительно друг друга. Есть даже программы, которые умеют делать измерения габаритов.
Из всего вышесказанного можно сделать вывод о том, какие типы операций нам надо разглядеть в тексте:
✅ пара "атрибут+значение" для выбора объектов;
✅ информацию о положении объектов для этапа проверки;
✅ пара "атрибут+значение", для принятия решения о нарушении.
Именно поэтому мы стали изобретать разметку текста, которая позволит идентифицировать все перечисленные выше сведения и.. разметку, создание которой можно будет автоматизировать с помощью волшебных современных технологий.
Кажется у нас получается)