Методология разработки онтологии строительной отрасли

По результатам анализа международной и российской практики области строительства нашей командой разработки [Сергей Волков, Инна Матюнина, Айрат Ахметов, Виталий Пугачев, Петр Одинцов и Иван Гребенщиков] было принято решение что имеет смысл переименовать онтологию: "Онтология градостроительной деятельности". Во первых, данное наименование соответствует градостроительному кодексу и охватывает все предметные области, связанные с проектированием, строительством и территориальным планированием, а также эксплуатацией, выводу из эксплуатации и реновацией. Во вторых, описание онтологии от деятельности позволит нам выстроить комплексную взаимосвязь между материальными сущностями (материалы, машины и механизмы) и производственными сущностями. В третьих, такой подход может быть прекрасно интегрирован с моделированием, так как моделирование деятельности позволяет увязать материальные сущности и информационные через подход системной инженерии.

Данный подход позволит гармонично вписать информационного моделирование в общую онтологию градостроительной деятельности.

Составляющие эффективного моделирования

Чтобы достичь успеха в моделировании предметной области необходимо следовать следующим шагам (основано на материалах книги Evans E. Предметно-ориентированное проектирование. Структуризация сложных программных систем / E. Evans, перевод Бродовой В.Л., Издательский дом «Вильямс», 2011. 448 c):

1 . Установи связь между моделью и ее реализацией. Уже в самом грубом прототипе должна присутствовать существенная связь с действительностью, и после всех последую­щих доработок эта связь должна сохраняться.

2. Используйте в обиходе язык, основанный на модели. Регулярно обсуждайте с инженерами элементарные понятия предметной области и подходов к ее моделированию на основе объектно-ориентированного подхода. необходимо добиться использования понятий, используемых в модели, чтобы составлять из них предложения, согласующиеся со структурой модели, и в результате необходимо достичь полного понимания без переводчика между всеми специалистами (включая программистов). Один из лучших способов усовершенствовать модель - обкатывать ее на языке, описывая вслух разные конструкции из возможных вариантов модели. Шероховатости будут услышаны сразу же. Неприятности возникают, когда участники процесса считают себя обязанными передавать всю модель или архитектуру программы средствами UML. Если объектных диаграмм слишком много, то одновременно возникает и избыток, и недостаток информации. Избыток - оттого, что все до единого объекты для будущей программы помещаются в модель. А недостаток - оттого, что из-за обилия деталей за деревьями можно не заметить леса.

3. Разработайте информоемкую модель. У объектов должны быть заданы правила поведения и ограничения. Модель должна быть не просто схемой хранения данных, а целостной методикой решения сложных задач. Она должна содержать в себе и обобщать обилие информации разного рода.

4. Дистилляция модели. По мере того как создание модели близится к завершению, в нее добавляются важные понятия. Но также важно и то, что понятия, оказавшиеся бесполезными или второстепенными, должны быть отброшены. Если бесполезное понятие тесно связано с необходимым, то находилась новая модель, в которой существенное понятие легко отделяется, а второстепенное отбрасываете.

5. Экспериментируйте и проводите мозговые штурмы. Наличие общего языка, набросков схем и готовность к интеллектуальным прорывам должны превратить дискуссии в экспериментальную лабораторию по разработке модели, где "обкатываются" и оцениваются сотни опытных вариантов. В процессе пошагового исследования рабочих сценариев даже устные высказывания участников срабатывали как быстрые тесты на пригодность предлагаемой модели, поскольку ухо человека легко отличает ясность и простоту от косноязычия.

Базовая онтология

Для формирования онтологии информационного моделирования была выбрана верхнеуровневая онтология BFO. Верхнеуровневая онтология GFO, которая была выбрана ранее оставлена для дальнейшего анализа в будещем.

Онтология BFO была выбрана по следующим причинам:

• Простая и компактная верхнеуровневая онтология
• На основе онтологии BFO построены онтологии ISO 19526 и онтологии многих военных ведомств
• Может позволить получить быстрый результат

При формировании онтологии используются принципы OBO Foundary

---

В России в поддержку развития онтологического подхода были переведены и утверждены международные стандарты:

• ГОСТ Р ИСО/МЭК 21838-1-2021 Информационные технологии. Онтологии высшего уровня (TLO). Часть 1. Требования
• ГОСТ Р 59798-2021 Информационные технологии. Онтологии высшего уровня (TLO). Часть 2. Базисная формальная онтология (BFO)
• ГОСТ Р 59791-2021 Информационные технологии. Общая логика (CL). Основы семейства языков, основанных на логике
• ГОСТ Р 59794-2021 СИСТЕМЫ АВТОМАТИЗАЦИИ ПРОИЗВОДСТВА И ИНТЕГРАЦИЯ. ИНТЕГРАЦИЯ ДАННЫХ ЖИЗНЕННОГО ЦИКЛА ПЕРЕРАБАТЫВАЮЩИХ ПРЕДПРИЯТИЙ, ВКЛЮЧАЯ НЕФТЯНЫЕ И ГАЗОВЫЕ ПРОИЗВОДСТВЕННЫЕ ПРЕДПРИЯТИЯ. ЧАСТЬ 12. ОНТОЛОГИЯ ОБЪЕДИНЕНИЯ ЖИЗНЕННОГО ЦИКЛА В СЕТЕВОМ ЯЗЫКЕ ОНТОЛОГИЙ (OWL)

Терминологический базис

Для разработки терминологической основы было предложено использовать модель SKOS и SKOS Simple Knowledge Organization System - Home Page

Схему организации тезауруса можно посмотреть по ссылке Стандарты по словарям базируются на стандарта NISO ISO 25964 – the international standard for thesauri and interoperability with other vocabularies https://www.niso.org/creating-niso-standards

A Method to Convert Thesauri to SKOS

Дополнительно нужно рассмотреть развертывание сервера TemaTres

---

В качестве развития общей методологии построения единой терминологической базы в области строительства можно опереться на проект COLORE, целью которого является разработка скоординированных верхнеуровневых онтологий. Ниже перевод описания проекта: "Многие задачи требуют правильной и содержательной коммуникации и интеграции между интеллектуальными агентами и информационными ресурсами. Основным препятствием для такой совместимости является семантическая неоднородность: разные приложения, базы данных и агенты могут приписывать разные значения одним и тем же терминам или использовать разные термины для передачи одного и того же значения. Даже когда программные приложения используют одну и ту же терминологию, они часто связывают с терминами разную семантику. Это противоречие в значении терминов препятствует беспрепятственному обмену информацией между приложениями. Разработка и применение онтологий играют центральную роль в достижении семантической интеграции. Онтология - это интерпретируемая компьютером спецификация, которая используется агентом, приложением или другим информационным ресурсом для объявления того, какие термины он использует и что означают эти термины. Онтологии поддерживают семантическую интеграцию программных систем посредством общего понимания терминологии в их соответствующих онтологиях.

Одним из препятствий на пути разработки выразительных формальных онтологий для различных областей было отсутствие адекватного набора общих онтологий, которые можно было бы использовать для определения семантики примитивных понятий. Например, любая онтология продукта должна ссылаться на взаимосвязи из геометрии и топологии, а для разных производственных стандартов могут потребоваться разные онтологии для времени. Поэтому необходимо будет сначала определить существующие онтологии в исследовательском сообществе, которые смогут обеспечить эти основы для производственных онтологий, а затем интегрировать эти онтологии с семантикой терминологии производственных стандартов.

Целью проекта COLORE является создание открытого хранилища онтологий первого порядка, которое будет служить испытательным стендом для методов оценки и интеграции онтологий и которое может поддерживать проектирование, оценку и применение онтологий в логике первого порядка. Все онтологии задаются с использованием Common Logic (ISO 24707), который является недавно стандартизированным логическим языком для спецификации онтологий первого порядка и баз знаний.

Дополнительным применением этой работы станет разработка новых производственных онтологий. Существует несколько стандартов, которые поддерживают взаимодействие между производственными программными системами; особый интерес представляют ISO 10303 STEP (Standard for the Exchange of Product data), ISO 14694 ( (NC Data - Данные ЧПУ), ISO 15531 MANDATE (Manufacturing Data Exchange), ISO 5608 (Cutting Tools - Режущие инструменты), ISO 1832 (Cutting Tool Inserts), ISO 16100 (Manufacturing Software Capability - Возможности производственного программного обеспечения), ENV 12204 (Constructs for Enterprise Modelling - Конструкции для корпоративного моделирования) и ENV 40003 (Framework for Enterprise Modelling - Фреймворк для корпоративного моделирования). Существует также несколько новых стандартов в области электронной коммерции Business-to-business (B2B), предлагаемых такими организациями, как Open Applications Group, Object Management Group и RosettaNet; эти стандарты включают Семантический словарь бизнес-правил (SVBR), Язык моделирования бизнес-процессов (BPMN) и SysML.

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

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

General Foundation Ontology

Разработке онтологии GFO предшествовало несколько научных отчетов и работ:

1. The Method of Levels of Abstraction

Опредления

В этих работах сделана попытка разработки методологии структурирования информации. Рассмотрим некоторые определения из этих работ:

Definition: A level of abstraction (LoA) is a finite but non-empty set of observables. No order is assigned to the observables, which are expected to be the building blocks in a theory characterised by their very definition. A LoA is called discrete (respectively analogue) if and only if all its observables are discrete (respectively analogue); otherwise it is called hybrid.

Определение: "Уровень абстракции (LoA) - это конечный, но непустой набор наблюдаемых объектов. Никакой порядок не присваивается наблюдаемым объектам, которые, как ожидается, будут строительными блоками в теории, характеризуемой самим их определением. LoA называется дискретным (соответственно аналоговым) тогда и только тогда, когда все его наблюдаемые объекты являются дискретными (соответственно аналоговыми); в противном случае он называется гибридным."

Definition: the behaviour of a system, at a given LoA, is defined to consist of a predicate whose free variables are observables at that LoA. The substitutions of values for observables that make the predicate true are called the system behaviours. A moderated LoA is defined to consist of a LoA together with a behaviour at that LoA.

Определение: Поведение системы в заданном уровне абстракции определяется предикатом и свободными переменными наблюдаемого объекта в этом уровне абстракции (LoA). Подстановки значений для наблюдаемых объектов, которые делают предикат истинным, называются поведением системы. Модерируемым уровнем абстракции (LoA) называется уровень абстракции вместе с поведением системы в этом уровене абстракции.

Алгоритм разработки онтологии

Мы кратко изложим основные этапы разработки онтологии на основе статьи "General Formal Ontology (GFO): A Foundational Ontology for Conceptual Modelling". Онтология обычно связана с предметной областью, следовательно, мы должны получить представление о рассматриваемой предметной области. Составляющие предметной области D включают объекты D, предполагаемые представления V (возможно, "точки зрения") и принципы классификации, которые будут использоваться для построения концепций. Эти составляющие могут быть проанализированы в рамках онтологии верхнего уровня. Мы описываем подход, ориентированный на верхний уровень, к разработке онтологий и используем в качестве основы GFO онтологии.

1 шаг: Спецификация предметной области и Протоонтология

Предметная область определяется принципами классификации и набором представлений. Первым шагом является построение спецификации предметной области. В частности, должно быть установлено описание объектов предметной области A. Рассматриваемые объекты определяются предполагаемыми представлениями, в то время как принципы классификации обеспечивают средства для структурирования множества объектов Obj(D). Обычно имеется исходная информация, связанная с предметной областью, в частности набор терминов(D) терминов, обозначающих понятия пердметной области. Система Протон(D) =(Спецификация(D), Термины(D)), состоящая из спецификации предметная области Предметная_область(D) и набора терминов Термины(D), называется протоонтологией. Протоонтология предметной области содержит соответствующую информацию, необходимую для дальнейших шагов по разработке аксиоматизированной онтологии о предметной области D.

2 шаг: Концептуализация.

Концептуализация основана на протоонтологии; результатом этого шага является постепенная концептуализация. Следовательно, необходимо определить или ввести основные и элементарные понятия предметной области. Полученные в результате понятия принадлежат либо понятиям, обозначенным терминами Терминов(D), либо они построены с помощью принципов классификации. Еще один подэтап относится к желаемым аспектным понятиям, которые являются производными от элементарных понятий. Наконец, мы должны определить отношения, которые имеют отношение к получению информации об отдельных лицах и концепциях. Было бы полезно, если бы была доступна метаклассификация отношений. GFO уже предоставляет базовую классификацию отношений, которая должна быть расширена и адаптирована к конкретной предметной области D.

3 шаг: Аксиоматизация.

На этом этапе разрабатываются аксиомы. Для этого нужен формализм, который может быть графической структурой или формальным языком. Мы более подробно излагаем структуру формальных баз знаний, которым помогает и поддерживается онтология верхнего уровня. Как правило, аксиоматизированная онтология Ont = (L, V, Ax(V)) состоит из структурированного словаря V, называемого онтологической сигнатурой, который содержит символы, обозначающие категории, индивидов и отношения между категориями или между их экземплярами, и набор аксиом Ax(V), которые являются выражениями формального языка L. Множество Ax(V) аксиом неявно отражает значение символов V. Расширение определения Ontd = (L, V ∪ C(DF), Ax(V)∪ DF), содержащее множество определений, расширяющих значение, и новый набор символов C(DF), введенных определениями. Каждое явное определение имеет вид t := e(V), где e(V) - выражение L, использующее только символы из V (следовательно, символ t не встречается в e(V)). Онтологическое отображение M концептуализации Conc(D) в аксиоматизированную онтологию Ont задается парой M = (tr, DF), состоящей из определяющего расширения Ontd Ont by (набор определений) DF и функцией tr, которая удовлетворяет следующему условию: Для каждого термина t ∈ Tm, обозначающего понятие C из Conc(D), которое определяется выражением Def (t) (естественного языка), функция tr определяет выражение tr(Def(t)) языка L(V ∪ C(DF)), такое, что Def(t) и tr(Def(t)) семантически эквивалентны относительно базы знаний Ax(Ont) ∪ DF. Тогда набор OntMap(Conc(D)) = Ax(V) ∪ DF ∪ {tr(Def(t)) : t ∈ Conc(D)} является формальной базой знаний, которая формально отражает семантику концептуализации D. Понятие семантической эквивалентности по отношению к базе знаний используется здесь неофициально, поскольку строгой формальной семантики для предложений на естественном языке еще не существует; значение должно быть прочитано “значение предложения на естественном языке (или полуформального) Def(t) эквивалентно значению выражения tr(Def(t)). Выражение e считается онтологически основанным на онтологии Ont, если оно выражено в некотором онтологическом расширении Ont. Следовательно, онтологическое отображение концептуализации(D) связывает с каждым термином Conc(D) эквивалентное формальное описание, основанное на формально аксиоматизированной онтологии. Окончательная аксиоматизация для Conc(D) может быть достигнута, если начать с онтологии верхнего уровня, скажем, GFO, а затем путем повторных шагов построить онтологическое отображение из Conc(D) в подходящее расширение GFO. Передовая разработка этой теории, которая исследуется группой OntoMed, представлена в [He 2006a]. Построение онтологического отображения, которое дает аксиоматизацию концептуализации, включает, согласно [He 2006a], три основные задачи: 1. Построение множества PCR примитивных понятий и отношений из множества {Def(t) : t ∈ Conc} (проблема примитивного базиса) 2. Построение расширения TO1 из TO путем добавления новых категорий Cat и отношений Rel и множества новых аксиом.Ax(Cat∪ Rel)(задача аксиоматизации) 3. Построение эквивалентных выражений для Def(t) ∪ PCR на основе TO1 (проблема определимости).

3 шаг: Разработка правил проверки

Для обеспечения проверки аксиом и правильности данных рекомендуется использовать один из языков проверки ограничен онтологии. Наиболее развитым в настоящее время является язык Shapes Constraint Language (SHACL).

С кратким учебным пособием можно познакомиться в виде презентации "RDF Validation tutorial. ShEx/SHACL by example" или в статье "SHACL Tutorial: Getting Started".

Предыдущий опыт

При формировании комплексной онтологии необходимо учитывать опыт разработки онтологий для нефтегазовой отрасли в рамках стандартов ISO 19526.

Ссылки на стандарты ISO 19526

• ISO 15926-1:2004 Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities — Part 1: Overview and fundamental principles
• ISO 15926-2:2003 Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities — Part 2: Data model
• ISO/TS 15926-3:2009 Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities — Part 3: Reference data for geometry and topology
• ISO/TS 15926-4:2019 Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities — Part 4: Initial reference data
• ISO/TS 15926-6:2013 Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities — Part 6: Methodology for the development and validation of reference data
• ISO/TS 15926-7:2011 Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities — Part 7: Implementation methods for the integration of distributed systems: Template methodology
• ISO/TS 15926-8:2011 Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities — Part 8: Implementation methods for the integration of distributed systems: Web Ontology Language (OWL) implementation
• ISO 15926-10:2019 Industrial automation systems and integration — Integration of life cycle data for process plants including oil and gas production facilities — Part 10: Conformance testing
• ISO/TS 15926-11:2015 Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities — Part 11: Methodology for simplified industrial usage of reference data
• ISO/TS 15926-12:2018 Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities — Part 12: Life-cycle integration ontology represented in Web Ontology Language (OWL)
• ISO 15926-13:2018 Industrial automation systems and integration — Integration of life-cycle data for process plants including oil and gas production facilities — Part 13: Integrated asset planning life-cycle

ISO 15926 vs Семантика: сравнительный анализ семантических моделей

Технические системы

на портале W3C сохранилась презентация "ISO 15926 for interoperability" Onno Paap из Fluor Corporation, которую он делал в 9-10 Dec 2008 – Houston TX USA

Проект AIM@SHAPE

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

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

Виртуальные службы визуализации (VVS) - это инфраструктура, объединяющая базы данных для архивирования фигур и программные средства для их обработки. VVS - это пересмотренная версия Digital Shape Workbench (DSW), разработанная консорциумом AIM @ SHAPE, прямым преимуществом которого является предоставление средств для обмена цифровыми ресурсами, такими как инструменты и модели, для подготовки виртуальных сцен и экспериментов для любых графических и виртуальных настроек. В большей степени VVS способствует повторному использованию программных компонентов и моделей тестирования для ускорения исследований в цифровой форме, и как таковой его можно рассматривать как поддержку электронной науки в области научной визуализации. VVS задуман как оперативное, распределенное и веб-хранилище ресурсов, которое включает в себя интеграцию хранилища форм, Хранилища инструментов и Хранилища онтологий и метаданных, а также расширенную среду поиска.

Введение в Shape Acquisition and Processing Ontology

В этом кратком руководстве дается обзор онтологии для получения и обработки форм, разработанной в рамках сети передового опыта AIM@SHAPE. В онтологии для получения и обработки форм модели и инструменты форм рассматриваются как ресурсы, которые можно загружать и загружать вместе с их метаданными в AIM@SHAPE DSW. Метаданные, относящиеся к фигурам, были смоделированы в Общей онтологии форм (SCO), а метаданные, относящиеся к инструментам, - в Общей онтологии инструментов (TCO).

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

Фундаментальной целью онтологии является формализация знаний, связанных с Получением и обработкой Формы. Для создания этой онтологии мы рассмотрели, что цифровая форма может быть создана либо из реального объекта, либо она может быть создана синтетически. Мы в основном нацелены на сохранение полезной информации на разных уровнях (геометрическом, структурном, семантическом) при переходе из Реального мира в Цифровой мир (Рисунок 1 - Сбор) или при выполнении действий в Цифровом мире (Рисунок 1 - Обработка)

Fig. 1: From the Real World to the Digital one.

Два критических этапа связаны с жизненным циклом цифровой формы.

• Фаза получения: Первая критическая фаза - это получение, в которой контекстуальные знания включают различные условия и свойства, относящиеся к сканируемому объекту, окружающей среде или даже к знаниям экспертов по сканированию. Большая часть этой информации должна быть сохранена и передана на другие этапы часто сложных конвейеров моделирования, чтобы улучшить качество результатов и открыть новые исследовательские подходы.
• Фаза обработки: Вторая критическая фаза - это Обработка, в ходе которой могут выполняться различные задачи с различными целями. Цифровая форма может быть структурирована, идентифицируя критические особенности и / или важные части модели, или ее можно улучшить, удалив, например, нежелательные отверстия или изменив ее. Существует множество различных операций, которые могут быть применены к цифровой форме, и все они зависят от различных контекстов применения.

Competency Questions about past, present and future of a digital shape

В случае приобретения реального объекта связанные с ним знания характеризуют жизненный цикл самой формы. Сбор данных должен быть спланирован (например, устройства должны быть выбраны с учетом их доступности и характеристик объекта, подлежащего получению), а данные, поступающие от систем сбора данных, должны быть обработаны на этапе реконструкции для получения формы. Необходимо выполнить дальнейшую обработку для удовлетворения потребностей пользователей, а также подготовить документацию, чтобы усилить семантическое воздействие формы. Онтология SAP предназначена для обеспечения поддержки знаний для исследователей, которым приходится сталкиваться с вышеупомянутыми шагами. Из-за внутренней сложности форм для достижения достаточного уровня выразительности необходимы метаданные, управляемые онтологией. Метаданные должны обеспечивать тщательную характеристику форм путем хранения:

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

Некоторые Вопросы о Компетентности

На многие интересные вопросы о компетентности можно ответить с помощью Онтологии для получения и обработки формы. Некоторые вопросы касаются этапа сбора, некоторые другие касаются инструментов / алгоритмов, использующих цифровые формы, а некоторые другие связаны с цифровыми формами и цифровыми объектами. Мы приводим здесь краткий список вопросов о компетентности, просто чтобы дать представление о теме: Какие реальные объекты принадлежат InstituteXYZ? Какие системы сбора данных способны сканировать Реальный объект, который поглощает свет? Какие трюки были выполнены для того, чтобы отсканировать реальный объект XYZ? При каких условиях освещения был отсканирован реальный объект XYZ? Существует ли инструмент конвертера, способный преобразовать выходной файл в многослойный файл? Какие инструменты способны вычислять расстояние между двумя фигурами? Которая является платформой компиляции для инструмента ABC Какой тип формата поддерживает инструмент ABC? Какова история, связанная с SurfaceMesh XYZ.wrl? Кто является владельцем источника RealObjects для SurfaceMesh XYZ.ply? Какие возможные шаги можно предпринять, начиная с облака точек? С помощью каких шагов можно достичь поверхностной сетки? С помощью какой последовательности шагов можно достичь поверхностной сетки, начиная с облака точек?

Computational geometry and isogeometric representation

Computational geometry and isogeometric representation (изогеометрическое представление) https://www.sintef.no/projectweb/computational-geometry/

SAMOD - современная методология разработки онтологий

SAMOD is a novel agile methodology for the development of ontologies by means of small steps of an iterative workflow that focuses on creating well-developed and documented models starting from exemplar domain descriptions.

Построение абстрактных типов данных (Abstract Data Types(ADT))

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

• What is Abstract Data Types(ADT) in Data Structures ? | with Example
• CS240 -- Lecture Notes: Abstract Data Type (ADT)
• Intro to Abstract Data Types
• Абстрактный тип данных abstract data type (ADT) стек, дек, очередь, куча
• Абстрактные типы данных в программировании
• Абстрактный тип данных. Часть 1: Данные (Тип Данных)
• Абстрактный тип данных. Часть 2: Управление данными

Неотъемлемой частью создания абстрактных типов данных является использование теории категорий.

Материалы по данной теме:

• Applied category theory

Построение пространства имен

В качестве положительного опыта имеет смысл посмотреть на "The SPHN Semantic Interoperability Framework". Это проект по управлению медицинскими данными. Подробнее про этот проект можно посмотреть по ссылке [1]

В рамках этого проекта разработаны:

• Терминологический сервис
• Правила построения пространства имен

Одновременно с этим нужно не забывать что основой многих онтологий является проект Дублинского ядра. Термины этого проекта доступны по ссылке [2]

Онтология времени

На портале W3C содержится очень подробная статья по адаптации различных онтологий времени и формированию общей онтологии времени. Данная статья доступна по ссылке OWL Time Ontology adoption

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

Основное писание онтологии времени доступно на основном портале W3C и на Github.

Управление ограничениями и правилами онтологии

Изначально, при разработке онтологий были выбран исключительно математический подход - аксиматический. Предполагалось, что при описании онтологии разработчики опишу все правила взаимосвязей и логического вывода через аксиомы. Однако практика показала, что реализация данного подхода имеет ряд проблем. Одна из ключевых проблем заключается в том, что системы логического вывода не знают в какой последовательности для каких классов и атрибутов применять эти аксиомы.

Как ответ на этот вопрос появились подходы по описанию правил, один из них SHACL. Подробнее об этом подходе можно посмотреть в лекции SHACL: From Data Validation to Schema Reasoning for RDF Graphs - Paolo Pareti. Подробный учебник доступен по ссылке [SHACL Tutorial: Getting Started]. Еще подробный разбор этого подхода доступен справочном разделе проекта AllegroGraph и в на потале shaclerules.com Understanding the Syntax and Structure of SHACL Rules.

Шаблоны разработки онтологии

Шаблоны разработки онтологии можно подсмотреть по ссылке Ontology Design Patterns