Методология разработки онтологии строительной отрасли: различия между версиями

Текущая версия на 21:07, 22 ноября 2025

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для разработки терминологической основы было предложено использовать модель 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 предшествовало несколько научных отчетов и работ:

The Method of Levels of Abstraction ^[1]

Опредления

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

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"^[2]. Онтология обычно связана с предметной областью, следовательно, мы должны получить представление о рассматриваемой предметной области. Составляющие предметной области 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".

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

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

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

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

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.

Linked Building Data Community Group Use Cases & Requirements

Группа Linked Building Data Community Group разрабатала проекты онтологий для строительной отрасли.

По ссылке Linked Building Data Community Group Use Cases & Requirements можно посмотреть описания сценариев применения онтологий для строительства.

Building Topology Ontology

Онтология топологии здания (BOT) - это минимальная онтология для описания основных топологических концепций здания. Описание онтологии размещено по ссылке: https://w3c-lbd-cg.github.io/bot/ Пространство имен для терминов BOT является https://w3id.org/bot# Данная спецификация была опубликована группой Linked Building Data Community Group. Она не является стандартом W3C и не входит в список стандартов W3C.

Рабочая группа будет сотрудничать с авторами существующих простых онтологий зданий, чтобы завершить разработку новой базовой онтологии топологии зданий, доведя ее до рекомендательного статуса. Эта онтология будет служить небольшой и легко расширяемой справочной онтологией для данной рабочей группы. Эта онтология будет немедленно приведена в соответствие с существующими онтологиями в строительной отрасли (ifcOWL), геопространственной области (W3C Spatial Data on the Web Working Group) и области датчиков (SSN).

Building Element Property Ontology

Рабочая группа будет сотрудничать с авторами существующих онтологий зданий и изделий, чтобы завершить разработку онтологии, которая может отражать свойства и характеристики строительных изделий и материалов (огнестойкость, значения коэффициента теплопередачи и т.д.). Эта онтология будет доработана до рекомендательного статуса. Эта онтология будет немедленно приведена в соответствие с существующими онтологиями в строительной отрасли (ifcOWL) и области датчиков (SSN). Кроме того, он будет направлен на приведение в соответствие с мероприятиями по стандартизации, которые проводятся в этом направлении в CEN/TC442 и в Словаре данных buildingSMART (bSDD).

Geometry Ontology

Рабочая группа будет работать с авторами существующих программ геометрического моделирования для получения 2D- и 3D-геометрических представлений концепций и элементов зданий. При разработке этой онтологии требуется тесное сотрудничество с рабочей группой W3C по пространственным данным в Интернете, которая уже разработала рекомендации по представлению геометрии в геопространственной области. Будут разработаны расширения, позволяющие также представлять трехмерную геометрию в хорошо работающем стандарте данных. Эта онтология будет доработана до статуса рекомендации. Эта онтология будет немедленно приведена в соответствие с существующими онтологиями в строительной отрасли (ifcOWL) и геопространственной области (рабочая группа по пространственным данным W3C в Интернете).

Ontology for Property Management

Онтология для управления недвижимостью (OPM) - это онтология для описания временных свойств, которые могут изменяться по мере развития проекта здания. Описание онтологии размещено по ссылке: https://w3c-lbd-cg.github.io/opm/ Пространством имен для терминов OPM является http://www.w3id.org/opm#

Данная спецификация была опубликована группой Linked Building Data Community Group. Она не является стандартом W3C и не входит в список стандартов W3C.

Damage Topology Ontology

Онтология топологии повреждений (DOT) позволяет определять представления повреждений и их взаимосвязи с другими повреждениями и затронутыми строительными компонентами. Онтология поддерживает общий подход к моделированию повреждений и, следовательно, может применяться для любого типа разрушения, а также для любого типа конструкций (например, зданий или мостов). Повреждения могут быть представлены в виде поврежденных областей (dot:DamageArea) или элементарных элементов повреждения (dot:DamageElement). Таким образом, экземпляры dot:DamageElement должны быть объединены в dot:DamageArea, однако значительные повреждения, например крупные трещины можно смоделировать как dot:DamageЭлемент без dot:DamageArea. Для группировки множественных последовательных повреждений можно определить шаблон повреждения, используя dot:DamagePattern в качестве третьего типа для представления повреждений. Помимо топологических классов повреждений, повреждения также могут быть классифицированы в соответствии с определенным типом повреждений с использованием подклассов dot:ClassifiedDamage, как определено в расширениях DOT. Разделение на структурные и неструктурные повреждения производится с помощью классов dot:StructuralDamage или dot:Defect. В дополнение к топологии документация о повреждениях, которая обычно создается во время проверок и оценки ущерба, может быть связана как с повреждениями, так и с поврежденными компонентами.

Пространством имен для DOT является https://w3id.org/dot#

Презентация поясняющая работу этой онтологии можно посмотреть по ссылке https://linkedbuildingdata.net/ldac2019/files/LDAC2019_Al-HakamHamdan.pdf

Соответствие требованиям системы управления и автоматизации зданий

Рабочая группа будет работать с авторами существующих онтологий DogOnt, SAREF и SSN, чтобы обеспечить четкое и формальное соответствие этим онтологиям в словарях BOT, PRODUCT и/или PSET. Эти согласования завершены до получения статуса рекомендации. Будут приняты во внимание дополнительные требования, уже определенные в сообществе, занимающемся строительными данными.

Приведение в соответствие со строительными единицами и областью измерений

Рабочая группа будет работать с авторами существующей онтологии QUDT и модели эксплуатации и управления, чтобы завершить разработку этой онтологии до получения статуса рекомендации. Онтология BOT будет приведена в соответствие с онтологией QUDT - Units и онтологией OGC O&M - Observation and Measurements. Будут приняты во внимание дополнительные требования, уже определенные в сообществе building data community.

The Smart Applications REFerence Ontology (SAREF)

Набор онтологий Smart Applications REFerence (SAREF) формирует общую согласованную модель, предназначенную для обеспечения семантической совместимости между решениями от разных поставщиков и между различными секторами деятельности в Интернете вещей (IoT), что способствует развитию пространств данных.

SAREF публикуется в виде набора открытых стандартов, разработанных Техническим комитетом ETSI по интеллектуальным коммуникациям между машинами (ETSI Technical Committee Smart Machine-to-Machine communications (SmartM2M).

Этот портал ETSI для SAREF предоставляет онтологии SAREF и указывает на различные результаты, связанные с SAREF.

This ETSI portal for SAREF exposes the SAREF ontologies and points to the different SAREF-related deliverables.

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

Ядро SAREF

SAREF Core определяет повторяющиеся основные концепции в области интеллектуальных приложений и основные взаимосвязи между этими концепциями. На рисунке ниже представлен обзор SAREF Core.

Расширения SAREF

Для разных вертикальных доменов были разработаны различные расширения. Каждый домен может иметь одно или несколько расширений, в зависимости от сложности домена и различных потребностей:

SAREF4ENER: Расширение SAREF для области энергетики

SAREF4ENVI: расширение SAREF для домена окружающей среды

SAREF4BLDG: расширение SAREF для домена зданий

SAREF4CITY: расширение SAREF для домена умных городов

SAREF4INMA: расширение SAREF для областей промышленности и производства

SAREF4AGRI: расширение SAREF для областей интеллектуального сельского хозяйства и пищевой цепочки

SAREF4AUTO: расширение SAREF для автомобильного домена

SAREF4EHAW: расширение SAREF для домена электронного здравоохранения/Ageinwell

SAREF4WEAR: расширение SAREF для домена носимых устройств

SAREF4WATR: расширение SAREF для домена Water

SAREF4LIFT: расширение SAREF для домена Smart Lifts

Репозиторий на GitHub некоторых расширений доступен по ссылке: https://github.com/mariapoveda/saref-ext?tab=readme-ov-file SAREF4GRID: расширение SAREF для домена Smart Grid

Шаблоны справочных онтологий SAREF

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

SAREF4SYST состоит как из базовой онтологии, так и из рекомендаций по созданию онтологий в соответствии с шаблонами онтологий SAREF4SYST. Базовая онтология - это облегченная онтология OWL-DL, которая определяет 3 класса и 9 свойств объектов.

SAREF4BLDG: расширение SAREF для домена building

Онтология и семантика SAREF4BLDG

Техническая спецификация SAREF4BLDG, расширения онтологии SAREF [1], которая была создана на основе отраслевого стандарта Foundation Classes (IFC) для построения информации. Следует отметить, что стандарт был изменен не полностью, поскольку он выходит за рамки данного дополнения, которое ограничено устройствами и бытовыми приборами в области строительства.

Настоящий документ представляет собой крупную редакцию расширения онтологии SAREF4BLDG, разработанного в контексте стандарта STF 653 (https://portal.etsi.org/xtfs/#/xTF/653/), используя обновленные шаблоны справочных онтологий, указанные в ETSI TS 103 548 [2], для решения задач гармонизации, определенных в ETSI TR 103 781 [i.6], с обновленной структурой разработки и инструменты, определенные в ETSI TS 103 673 [i.7].

ETSI TS 103 410-3 [i.5] был разработан в рамках STF 513, целевой группы специалистов ETSI, которая была создана с целью разработки SAREF Core V2 и расширения SAREF id для областей окружающей среды, зданий и энергетики (см. https://portal.etsi.org/STF/STFs/STF-HomePages/STF513 ). Спецификация IFC разработана и поддерживается компанией buildingSMART International в качестве "Стандарта данных" и, начиная с версии IFC4, публикуется как ISO 16739 [i.2]. SAREF4BLDG предназначен для обеспечения (в настоящее время отсутствующей) функциональной совместимости между различными участниками (архитекторами, инженерами, консультантами, подрядчиками и производителями компонентов продукции, среди прочих) и приложениями, управляющими информацией о зданиях на различных этапах жизненного цикла здания (планирование и проектирование, строительство, ввод в эксплуатацию, эксплуатация, переоснащение/реконструкция)./Реконфигурация и снос/утилизация). Используя SAREF4BLDG, интеллектуальные устройства от производителей, поддерживающих модель данных IFC, смогут легко взаимодействовать друг с другом. Для достижения этой цели SAREF4BLDG следует использовать для аннотирования (или создания) нейтральных описаний устройств, которые будут доступны различным заинтересованным сторонам.

SAREF4BLDG - это онтология OWL-DL, которая расширяет SAREF с помощью 72 классов (67 определены в SAREF4EBLDG и 5 повторно используются из онтологий SAREF и geo) и 77 свойств типов данных (76 определены в SAREF4EBLDG и 1 повторно используется из онтологии SAREF).

SAREF4BLDG фокусируется на расширении онтологии SAREF, чтобы включить в нее устройства, определенные в IFC версии 4 - Дополнение 1 [i.3], и обеспечить представление таких устройств и других физических объектов в пространствах зданий.

Префиксы и пространства имен, используемые в SAREF4BLDG и в настоящем документе, перечислены в таблице 1.

Table 1: Определение пространств имен для SAREF4BLDG
Prefix	Namespace
dct	http://purl.org/dc/terms/
geo	http://www.opengis.net/ont/geosparql#
owl	http://www.w3.org/2002/07/owl#
prov	http://www.w3.org/ns/prov#
rdf	http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs	http://www.w3.org/2000/01/rdf-schema#
s4bldg	https://saref.etsi.org/saref4bldg/
saref	https://saref.etsi.org/core/
vann	http://purl.org/vocab/vann/
xsd	http://www.w3.org/2001/XMLSchema#

Словарь для обозначения общественного освещения

Английская редакция онтологии размещена по ссылке: http://vocab.linkeddata.es/datosabiertos/def/urbanismo-infraestructuras/alumbrado-publico

Репозиторий на Git Hub: https://github.com/opencitydata/urbanismo-infraestructuras-alumbrado-publico?tab=readme-ov-file

Этот словарь позволяет представлять данные, относящиеся к уличному освещению, включая данные, относящиеся к уличным фонарям, светильникам, фонарям, столбам и световым коробам. Он был разработан в контексте инициативы OpenCityData.

Первая версия этого словаря была создана в контексте Международного дня открытых данных. Эта новая версия учитывает результаты, полученные в этой первой версии словаря, проблемы, выявленные в его использовании, и достижения, достигнутые в последние годы в предложении шаблонов проектирования онтологий для городов и в таких моделях, как модель, предложенная FI-WARE. Эта обновленная версия словаря была создана во время разработки дипломного проекта в Высшей технической школе компьютерных инженеров Мадридского Политехнического университета.

DigiChecks Permit Ontology

Онтология разрешений DigiChecks - это онтология верхнего уровня для описания процессов выдачи разрешений, требований и действий по проверке. Онтология основана на платформе семантического моделирования и компоновки (SML, EN 17632) и предоставляет базовую терминологию для служб DigiChecks, позволяющую однозначно сообщать о процессах выдачи разрешений. Публикация также доступна в формате RDF-endpoint.

Ссылка: https://semmtech.github.io/digichecks-ontology/

Ссылка на репозиторий: https://github.com/semmtech/digichecks-ontology

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

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

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

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

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

Инструменты

sparql-visualizer - Visualization of how room requirements can be modeled with BOT and OPM

↑ Floridi L. The Method of Levels of Abstraction // Minds and Machines. 2008.
↑ Herre H. General Formal Ontology (GFO): A Foundational Ontology for Conceptual Modelling // Theory and Applications of Ontology: Computer Applications / под ред. R. Poli, M. Healy, A. Kameas. Dordrecht: Springer Netherlands, 2010. С. 297–345.

[1] Floridi L. The Method of Levels of Abstraction // Minds and Machines. 2008.

[2] Herre H. General Formal Ontology (GFO): A Foundational Ontology for Conceptual Modelling // Theory and Applications of Ontology: Computer Applications / под ред. R. Poli, M. Healy, A. Kameas. Dordrecht: Springer Netherlands, 2010. С. 297–345.

[1]

[2]

@@ Строка 120: / Строка 120: @@
 ## [https://ceur-ws.org/Vol-2159/ Linked Data in Architecture and Construction 2018]
 # [https://github.com/linkedbuildingdata/SummerSchoolOfLDAC Summer School of Linked Data in Architecture and Construction 2019]
+# [https://www.student.dtu.dk/~mhoras/presentations/ssoldac#/ Интерактивная презентация "Introduction to querying Linked Data"]
 === Ссылки на стандарты ISO 19526 ===
@@ Строка 211: / Строка 213: @@
 Рабочая группа будет сотрудничать с авторами существующих простых онтологий зданий, чтобы завершить разработку новой базовой онтологии топологии зданий, доведя ее до рекомендательного статуса. Эта онтология будет служить небольшой и легко расширяемой справочной онтологией для данной рабочей группы. Эта онтология будет немедленно приведена в соответствие с существующими онтологиями в строительной отрасли (ifcOWL), геопространственной области (W3C Spatial Data on the Web Working Group) и области датчиков (SSN).
-==== Building Product Ontology ====
-Рабочая группа будет сотрудничать с авторами существующих онтологий зданий и изделий, чтобы завершить разработку новой онтологии строительных изделий, доведя ее до рекомендательного статуса. Эта онтология будет служить небольшой и легко расширяемой справочной онтологией для данной рабочей группы. Эта онтология будет немедленно приведена в соответствие с существующими онтологиями в строительной отрасли (ifcOWL).
 ==== Building Element Property Ontology ====
@@ Строка 225: / Строка 223: @@
 Онтология для управления недвижимостью (OPM) - это онтология для описания временных свойств, которые могут изменяться по мере развития проекта здания.
 Описание онтологии размещено по ссылке: https://w3c-lbd-cg.github.io/opm/
-Пространство имен для терминов OPM является http://www.w3id.org/opm#
+Пространством  имен для терминов OPM является http://www.w3id.org/opm#
 Данная спецификация была опубликована группой Linked Building Data Community Group. Она не является стандартом W3C и не входит в список стандартов W3C.
+==== Damage Topology Ontology ====
+Онтология топологии повреждений (DOT) позволяет определять представления повреждений и их взаимосвязи с другими повреждениями и затронутыми строительными компонентами. Онтология поддерживает общий подход к моделированию повреждений и, следовательно, может применяться для любого типа разрушения, а также для любого типа конструкций (например, зданий или мостов). Повреждения могут быть представлены в виде поврежденных областей (dot:DamageArea) или элементарных элементов повреждения (dot:DamageElement). Таким образом, экземпляры dot:DamageElement должны быть объединены в dot:DamageArea, однако значительные повреждения, например крупные трещины можно смоделировать как dot:DamageЭлемент без dot:DamageArea. Для группировки множественных последовательных повреждений можно определить шаблон повреждения, используя dot:DamagePattern в качестве третьего типа для представления повреждений. Помимо топологических классов повреждений, повреждения также могут быть классифицированы в соответствии с определенным типом повреждений с использованием подклассов dot:ClassifiedDamage, как определено в расширениях DOT. Разделение на структурные и неструктурные повреждения производится с помощью классов dot:StructuralDamage или dot:Defect. В дополнение к топологии документация о повреждениях, которая обычно создается во время проверок и оценки ущерба, может быть связана как с повреждениями, так и с поврежденными компонентами.
+Пространством имен для DOT является https://w3id.org/dot#
+Презентация поясняющая работу этой онтологии можно посмотреть по ссылке https://linkedbuildingdata.net/ldac2019/files/LDAC2019_Al-HakamHamdan.pdf
 ==== Соответствие требованиям системы управления и автоматизации зданий ====
@@ Строка 334: / Строка 339: @@
 Первая версия этого словаря была создана в контексте Международного дня открытых данных. Эта новая версия учитывает результаты, полученные в этой первой версии словаря, проблемы, выявленные в его использовании, и достижения, достигнутые в последние годы в предложении шаблонов проектирования онтологий для городов и в таких моделях, как модель, предложенная FI-WARE. Эта обновленная версия словаря была создана во время разработки дипломного проекта в Высшей технической школе компьютерных инженеров Мадридского Политехнического университета.
+=== DigiChecks Permit Ontology ===
+Онтология разрешений DigiChecks - это онтология верхнего уровня для описания процессов выдачи разрешений, требований и действий по проверке. Онтология основана на платформе семантического моделирования и компоновки (SML, EN 17632) и предоставляет базовую терминологию для служб DigiChecks, позволяющую однозначно сообщать о процессах выдачи разрешений. Публикация также доступна в формате [https://hub.laces.tech/digichecks/public/production/digicehcks-ontology/versions/1 RDF-endpoint].
+Ссылка: https://semmtech.github.io/digichecks-ontology/
+Ссылка на репозиторий: https://github.com/semmtech/digichecks-ontology
 == Построение абстрактных типов данных (Abstract Data Types(ADT)) ==