О методическом пособии по созданию цифровых требований: как исправить проблемы (часть 2/2)
Попробуем предложить решения проблемы. Важность создания методики мы не будем отрицать, но надо подумать над интеграционным фундаментом, когда бы нас понимали все, а не только в рамках данной методики.
Порассуждаем над конкретными шагами, как исправить ситуацию:
🛑 Устранить семантический разрыв. Не вводить новый формат, а надстраиваться над тем, что есть. Для этого надо признать, наконец, IFC основным стандартом представления данных и создать надстройку. А надстройка - это IDS, работающий инструмент для описания описания проверок. Он уже живёт, развивается, под него пишут функционал. Его можно и нужно дорабатывать. Синхронизироваться с мировым опытом и национальными разработками в рамках ТК 505, а не загонять самих себя в технологическую изоляцию. Также не мешало бы скоординировать работу с разработчиками национального расширения IDS-стандарта.
🛑 Не описывать сущности в требованиях кодами по КСИ. КСИ - важный справочник, но его коды не должны жестко вшиваться в структуру требований. В IFC есть механизм, присваивать элементам классификационную ссылку через IfcClassification и IfcClassificationReference. Это позволяет гибко использовать КСИ и любой другой классификатор одновременно, без переписывания правил.
🛑 Использовать стандартные свойства IFC и всю его мощь как онтологии. На первом этапе вместо введения тысяч новых полей - разработать таблицу мэппинга произвольных свойств требований к стандартным наборам IFC (Pset_ и Qto_). Хотите проверять "Предел огнестойкости"? Сопоставьте это требование со стандартным свойством FireRating из Pset_WallCommon. На следующем этапе - начинать работать со связями.
Предлагаемый путь - это переход от создания "ещё одного формата" к интеграции методики в существующую онтологию данных строительной отрасли, описанную в IFC. Это снимет ряд технических противоречий, устранит двойные трудозатраты и, главное, даст на выходе практический инструмент для сложных междисциплинарных проверок.
Кратко:
- IFC - как базовый фундамент;
- механизм классификационных ссылок для гибкости;
- таблицы мэппинга свойств и использование связей IFC;
- развитие IDS.
👥 @IFC_ru
👥 @IFC_club
Попробуем предложить решения проблемы. Важность создания методики мы не будем отрицать, но надо подумать над интеграционным фундаментом, когда бы нас понимали все, а не только в рамках данной методики.
Порассуждаем над конкретными шагами, как исправить ситуацию:
🛑 Устранить семантический разрыв. Не вводить новый формат, а надстраиваться над тем, что есть. Для этого надо признать, наконец, IFC основным стандартом представления данных и создать надстройку. А надстройка - это IDS, работающий инструмент для описания описания проверок. Он уже живёт, развивается, под него пишут функционал. Его можно и нужно дорабатывать. Синхронизироваться с мировым опытом и национальными разработками в рамках ТК 505, а не загонять самих себя в технологическую изоляцию. Также не мешало бы скоординировать работу с разработчиками национального расширения IDS-стандарта.
🛑 Не описывать сущности в требованиях кодами по КСИ. КСИ - важный справочник, но его коды не должны жестко вшиваться в структуру требований. В IFC есть механизм, присваивать элементам классификационную ссылку через IfcClassification и IfcClassificationReference. Это позволяет гибко использовать КСИ и любой другой классификатор одновременно, без переписывания правил.
🛑 Использовать стандартные свойства IFC и всю его мощь как онтологии. На первом этапе вместо введения тысяч новых полей - разработать таблицу мэппинга произвольных свойств требований к стандартным наборам IFC (Pset_ и Qto_). Хотите проверять "Предел огнестойкости"? Сопоставьте это требование со стандартным свойством FireRating из Pset_WallCommon. На следующем этапе - начинать работать со связями.
Предлагаемый путь - это переход от создания "ещё одного формата" к интеграции методики в существующую онтологию данных строительной отрасли, описанную в IFC. Это снимет ряд технических противоречий, устранит двойные трудозатраты и, главное, даст на выходе практический инструмент для сложных междисциплинарных проверок.
Кратко:
- IFC - как базовый фундамент;
- механизм классификационных ссылок для гибкости;
- таблицы мэппинга свойств и использование связей IFC;
- развитие IDS.
👥 @IFC_ru
👥 @IFC_club