Category: технологии

Category was added automatically. Read all entries about "технологии".

Sharge
  • vvagr

Семантические и онтологические технологии - одно и то же или нет?

ISO 15926 – онтология для семантического представления инженерных данных

"Семантика" и "онтология" становятся популярными терминами в ИТ-сфере. Наш новый короткий текст поясняет сферу применения семантических и онтологических технологий, их связи и различия, на примере работы с данными жизненного цикла крупных инженерных проектов.
2021 год
  • ailev

Платформенность .15926

С выпуском версии 1.2 (ждите, это совсем скоро!) нужно обратить внимание на то, куда мы движемся: от Browser к Editor, от Editor к Platform -- если в прошлой версии стало возможным делать пользовательские расширения с использованием Сканера и Билдера графа, то в версии 1.2 добавляются расширения для пользовательских паттернов.

Продукт у нас штучный и сложный, и неплохо бы поглядеть, как в таких условиях развиваются продукты аналогичного класса. Например, Robot Operation System (ROS) -- http://www.ros.org/wiki/ROS/Introduction (число участников тамошнего проекта сильно меньше, чем в Eclipse -- http://eclipse.org/, так что он больше похож на нас нынешних). По большому счёту все эти проекты ползут с ростом числа участников к пониманию "платформенности" как вариантам ручной сборки из разношёрстных и разномастных деталек к какой-то автоматизации и самосборке сложных конфигураций и достижению монструозности, а затем в рамках уже этой монструозности и избыточности софта появляется AppStore.

У нас уже есть:
-- последовательность самообразования (ибо без знания ISO 15926 никакого .15926 софта не нужно), в том числе методология разработки. Конечно, когда всё это собрано в кучку, становится понятным, как это всё компактно переписать и тем самым снизить входной порог.
-- файловые форматы (Часть 8 -- нам свезло, ибо остальным приходится сочинять что-то своё, а тут "безобразно, но единообразно").
-- фриварный движок, который медленно-медленно начинает стабилизироваться и к нему документированные API всех этих расширений
-- сделанные in house примеры расширений (их мало, но они есть)
-- интернет-комьюнити, где все это можно обсуждать (вот это, в котором находится данный пост).

Чего же не хватает для того, чтобы обозваться платформой? Нижняя граница -- пятеро независимых от нас и друг от друга разработчиков расширений, без которых "платформенности" как таковой по факту нет (я ориентируюсь на давнее наблюдение, что вики без пяти активных контрибуторов не взлетают -- с платформами должно быть что-то такое же, отсюда и число "пять независимых").

После этого придётся делать какую-то дополнительную инфраструктуру, чтобы поддержать разработчиков расширений. Интересно, когда наступит этот радостный момент. Конечно, нам уже сейчас время от времени сообщают, что давно и с пользой используют нашу софтинку для работы. Но узнаём мы об этом чаще всего случайно. Думаю, что мы узнаем о разработке пяти расширений, когда их реальное число будет разве что не пятьдесят. Не знаю, радоваться этому (молчат -- значит у них софтинка жужжит, и не падает, что хорошо), или печалиться (очень ведь хочется обратной связи).
2021 год
  • ailev

Почему ISO 15926

За последнюю пару лет ситуация с объяснением того, почему интеграционные (федеративные, MDM и т.д.) решения нужно делать именно на основе ISO 15926, изменилась. Если раньше нужно было сравнивать реляционные и объект-атрибутные (то бишь традиционные ООП) модели данных традиционных MDM и иных "интеграционных" и "шинных" решений в их конкуренции с ISO 15926, то сегодня на рынке много самых разных игроков:
-- аристотелевская традиция (куда попадают практически все известные на сегодня варианты MDM-решений, SOA-реализаций с ESB, варианты "много интеграций точка-точка, и ничего в этом нет страшного").
-- простая интеграция на основе технологий семантического веба (т.е. факт-ориентированная модель, а не объект-ориентированная, но без какой-то онтологической начинки). Это новые игроки, которые подчёркивают преимущество, гибкость и всеохватность факт-ориентированной модели, считая что они легко моделируют "по потребности" недостающие справочные данные. Более того, они демонстрируют убедительные примеры. Грубо говоря, "всё то же самое, что ISO 15926, только без этих ваших сложностей овладения 201 типом, темплейтами, паттернами".
-- "словарное соответствие" ISO 15926 -- по факту, сюда попадает любая схема данных, если она опубликована и открыта (т.е. её можно пробовать мэппить независимо от разработчика). Например, XMpLant и множество схем данных CAD/PLM вендоров попадает в эту категорию. Это может быть как "семантические технологии" (то есть RDF/OWL), так и "просто XML схема" (в разы чаще).
-- "внеуставное моделирование" для ISO 15926 (попытка использовать кусочек RDL -- но не полностью, например, игнорируя 4D)
-- полноценное моделирование в ISO 15926, "как задумано разработчиками"

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

Аналогичные аргументы используются и для обсуждения MDM-предложений (централизованное ведение RDL внутри компании с надеждой на обслуживание этой RDL партнёров и поставщиков в масштабе отрасли или бизнес-эко-системы).

Вот эти "преимущества ISO 15926" (и огромное спасибо Hans Teijgeler за обсуждение):

1. ISO 15926 -- это стандарт (да, включая и часть, находящуюся в JORD -- POSCCaesar Association "майнтейнер" этого стандарта-базы-данных для ISO). Вкладываться в изучение или написание софта для стандарта -- это вкладываться в что-то, что более стабильно, чем решения какого-то одного вендора или какого-то одного проекта. Стандарт описывает систему накопления знания в виде федерации библиотек справочных данных, но верхушка этой знаниевой пирамиды относительно стабильна. Далее могут быть много конкурирующих между собой вендоров с разными реализациями, много использующих эти реализации проектов, но знания об этой "верхушке пирамиды" будут переносимы людьми из проекта в проект. Обучение в одном проекте сможет быть использовано в другом проекте, где все вендоры другие.

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

2. "Простые решения", как основанные на ISO 15926 (но игнорирующие 4D онтологию), так и основанные на RDF/OWL, хорошо работают только в рамках одной стадии жизненного цикла (только проектирования, или только сооружения, или только эксплуатации). При выходе за рамки стадии жизненного цикла приходится моделировать всю сложность объекта "система", который изменяется во времени.

ISO 15926 за счет использования 4D онтологии предлагает нормализацию до 6й нормальной формы. Если использовать более простые модели данных, то денормализация порождает кошмар управления конфигурацией данных, находящихся у разных участников жизненного цикла: синхронизация изменений становится весьма и весьма нетривиальной, как в любом случае денормализации.

Все альтернативные решения не гарантируют этой нормализации по всему жизненному циклу системы, а ограничиваются только нормализацией вплоть до 5й нормальной формы на одной стадии жизненного цикла. Но ведь кто-то после этого должен будет проинтегрировать/профедерировать на всём жизненном цикле эти островки интеграции/федерации для одиночных стадий! В этот момент выяснится, что от "простых и быстрых решений" опять придётся переходить к специально предназначенным для этого решениям ISO 15926, переучивать людей, делать очередной мэппинг данных. Ибо модель данных ISO 15926 как раз и получилась такой нетривиальной из-за того, что решала проблему интеграции данных по всему жизненному циклу: в ней полностью поддержано понятие "система", в части постепенной эволюции и уточнения модели системы, а затем замены компонент в ходе функционирования воплощённой "в металле и бетоне" системы (подробнее о сложности понятия "система" и требований к языкам поддержки системы, в том числе необходимость поддержки темпоральных объектов и отношений, см. доклад http://incose-ru.livejournal.com/39744.html).

Управление конфигурацией данных жизненного цикла без активного задействования всей этой сложной модели данных со множественными классификациями (классификацией отношений, аппаратом классов классов), а также 4D (темпоральные части), плюс особенности поддержки понятия системы (физические объекты и функциональные физические объекты) представляется опрометчивым. В случае ISO 15926 есть набор типовых практик решения типовых возникающих при этом проблем, и эти практики не являются ноу-хау каких-то поставщиков: эти практики заложены в стандарт.

3. Стандарт позволяет организовывать массовую (bulk, batch) передачу не только "трансакционных" (проектных) данных как данных об индивидах, но и справочных данных -- данных о классах (классификаторов и справочников НСИ), единиц измерения, ограничений из нормативных актов (типа таблицы номинальных диаметров) и т.д.. Более простые (без использования классов классов и без возможности классифицировать отношения классификации и специализации) модели данных обычно трудно использовать для передачи не только данных, но и сопутствующих им справочных данных (что особенно хорошо проявляется при "странных" видах данных -- вроде каталогов промышленной продукции, которые точно не про экземпляры, а про классы -- много разных железок с серийными номерами для одной строчки каталога, но во многих чертах записи о моделях в каталоге ведут себя как экземпляры. Так же возникают обычно проблемы корректной массовой передачи как проектных, так и справочных данных при "дизайне в классах" и при обсуждении "типовых дизайнов" -- в этих случаях тоже довольно просто запутаться с управлением конфигурацией по всему жизненному циклу.

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

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

ISO 15926 предоставляет детальное описание, как могла бы выглядеть RDL в форме файла, и в форме онлайн-фасада, какие должны быть мета-данные для ведения библиотеки (да, какие-то нюансы этого описания уторговываются прямо сейчас -- но мы же понимаем, что такие неуторгованные моменты всё одно всплывут в любых проприетари реализациях "библиотекоидов". Я намеренно использую суффикс "оид" для указания на объект, который похож на библиотеку, но не библиотка -- типа "гуманоид", который на человека похож, но не человек).

5. Особое внимание к повышению уровня языка:
-- над триплами реализована семантическая сетка из типов Части второй.
-- темплейты, что позволяет резко упростить работу.
-- паттерны, что позволяет ещё больше упростить работу.

Альтернативные интеграционные предолжения содержат какие-то свои собственные способы поднимать уровень высказываний по сравнению с "ассемблером из триплов", но указанных трёх уровней нет ни у кого.
* * *
Конечно, обратной стороной медали тут является сложность освоения модели данных ISO 15926 по сравнению с "простыми и поэтому надёжными решениями" для одной стадии жизненного цикла (неудивительно, что список "трудностей освоения" по факту совпадает со списком "главных достоинств" -- http://dot15926.livejournal.com/30492.html). Но наш опыт показывает, что не так страшен чёрт, как его малюют. Особенно, если учесть:
-- понимание, как осваивать стандарт, потихоньку растёт (см. http://dot15926.livejournal.com/27293.html, довольно много людей успешно продвинулись, следуя этой последовательности).
-- усилия по подъему уровня языка (т.е. освоение работы с паттернами, это писк ISO 15926-моды буквально последнего года) дадут ещё одно снижение образовательного ценза для подключения к работе с модельерами данных обычных инженеров
-- наличие такого софта, как .15926 Editor, который поддерживает всё вышеописанное "из коробки", свободно доступен и позволяет попробовать все решения без привлечения какого-то крупного поставщика RDL и программного обеспечения.
Sharge
  • vvagr

Автоматизация онтологического моделирования документов на естественном языке

TechInvestLab.ru is starting a research program into an automation of formal modelling. The first project is developed together with ABBYY - the leading linguistic company. The project studies possibilities to build a Gellish-like formal model of a natural language technical document, for further transformation into an ISO 15926 compliant data model with TabLan.15926 engine. This presentation shows preliminary comparisons between syntactic and semantic structures parsed by ABBYY Compreno and manually prepared formal text models.

Мы начинаем исследовательскую программу по автоматизации информационного моделирования. Первый проект будет развиваться вместе с компанией ABBYY - мировым лидером в области лингвистических разработок. Проект изучает возможности построения по техническому документу на естественном языке Gellish-подобной модели, которую в дальнейшем можно будет трансформировать в формальную модель ISO 15926 (с помощью технологии TabLan.15926, например). Презентация по ссылке (спасибо дорогому супу за неработающий эмбед) показывает предварительные материалы проекта - сопоставление семантической и синтаксической структуры, построенной с помощью ABBYY Compreno, и подготовленной вручную формальной модели текста.

Ontology Modelling of an Engineering Document – Perspectives of Linguistics Analysis.
2021 год
  • ailev

Обновленный Roadmap

Хотя в использовании софта .15926 до сих пор множество неопределенностей, всё-таки становится понятней, в каких терминах можно обсуждать его настоящее и будущее. В целом, мы продолжаем следовать предыдущим вариантам roadmap (прежде всего http://dot15926.livejournal.com/23803.html, но также и более древним http://dot15926.livejournal.com/20729.html и даже более долгосрочным типа http://dot15926.livejournal.com/20116.html).

Мы делаем language workbench, поддерживающий огромное разнообразие DSL, но это не столько традиционные для language workbench "языки исполнения", сколько языки описания данных (ага, Java и Prolog -- это тоже языки описания данных, причём эти данные понятно как машинно исполнять. Но не будем на это пока отвлекаться). То есть это не "универсальная IDE" для intentional programming и движка "машинного исполнения", а "универсальный моделер" для intentional modeling и движка продвинутого рендеринга для человеков (опять же, меня много лет учили, что все эти "рендеринги" -- это просто сложные случаи семантики исполнения. Любое исполнение одну цепочу символов превращает в другую цепочку символов -- будь это вычисление арифметических операторов регистровой машиной, или рендеринг табличного отчёта по семантической сетке).

Когда я думаю о классе приложений для такого инструмента, то лично мне в голову приходит главным образом софт PraxOS (http://praxos.livejournal.com/12576.html). Но это, конечно, только одно из возможных многочисленных применений.

Другое применение -- это повторение функциональности IRING и XMpLant по интеграции инженерных данных, только в более продвинутой архитектуре и с более удобными программными и пользовательскими интерфейсами. Это как раз тот случай, когда "нужно выйти вторыми, чтобы прийти первыми".

1. В 2011г. мы делаем language workbench с parsing технологией. Отличия от описанного в http://dot15926.livejournal.com/23803.html Roadmap:
-- мы считаем, что это тоже language workbench, поддерживающий много разных DSL. Только это workbench "парсерной" технологии, ибо сейчас технологически различают два типа language workbench (см. табличку http://www.languageworkbenches.net/ar.html): parsing и projectional.
-- сначала (сентябрь 2011) будет реализована часть с builder и templateconstructor. Будет ли реализована функция поднятия шаблонов в семантическую сетку, или сетка будет хранить аксиомы as is -- это вопрос обсуждаемый до сих пор, ибо нужны use cases для такого подъема. Этих use cases пока не удалось придумать.
-- до конца 2011 года будет реализована часть со scanner.

Вопрос с реализацией встроенного экранного редактора хоть какого-нибудь класса DSL (хотя бы диаграммок из типизированных квадратиков и стрелочек) зависит от успеха найма программистов в проект (онтолог из предложения http://dot15926.livejournal.com/23818.html уже принят, а вот программиста по-прежнему ждём).

2. В 2012 году пытаемся реализовать "универсальный моделер" -- т.е. технологию с экранным projectional editor.
2021 год
  • ailev

Компиляции в .15926

Существует два основных варианта "компиляции":

1. С какого-то "выразительного языка" в "язык исполнения".
В .15926 мы планируем для этой цели использовать технологию language workbench. Когда проект только-только начинался, эта технология была очень маргинальна, примеров почти не было. Сейчас ситуация стремительно меняется: на конкурс language workbench 2011г. представлено 11 участников -- http://www.infoq.com/news/2011/03/lwc-2011.

Мы должны представить лёгкие средства разработки "компиляторов" различных (текстовых, графических, табличных и т.д.) DSL в общее представление ISO 15926.

Основная трудность тут в том, что речь идет об интерактивном программировании: нам нужно не просто в одностороннем порядке перевести с какого-то DSL на язык ISO 15926, но и суметь отобразить необходимый фрагмент семантической сетки ISO 15926 представления в DSL.

Аналогичные задачи решаются, конечно, современными language workbench, но в нашем случае речь идет о существенно декларативных представлениях, и заимствовать чужие решения наверняка не удастся. Будем топтать целину.

2. С языка "медленной интерпретации" в язык "быстрого выполнения".
В декларативных языках это получило название "компиляция знаний" (см., например, десятилетней давности обзорную статью http://www.jair.org/media/989/live-989-2063-jair.pdf и современные развороты темы тут: http://www.mpi-inf.mpg.de/departments/rg1/conferences/deduction10/).

Мы ожидаем, что база знаний может получаться неожиданно большой (загрузка начальной библиотеки справочных данных -- это 2.7млн. триплов, и это без проектных данных!), и нужны будут скоростные методы работы.
2021 год
  • ailev

К созданию методологии использования ISO 15926

В настоящий момент мне известны следующие обрывки методологии использования ISO 15926 (кроме разных наборов слайдов, или зачастую одиночных слайдов, которые предполагают устное комментирование авторами):

1. Часть 1 стандарта, описывающая "пирамиду справочных данных" и прочие важные сведения (важность которых трудно понять, пока не приступишь к какому-то конкретному проекту).
2. Раздел 4 Части 2 "Fundamental concepts and assumptions" -- как "кодировать на ассемблере", т.е. в языке Части 2.
3. Часть 7, описывающая способ подъема уровня языка шаблонами, и раздел про полное определение шаблона в части 8.
4. Проект части 6 про то, как оформлять записи (reference data items) в RDL -- как формулировать "определения" и т.д.
5. Полуготовое руководство "Beginners's guide to 15926 modeling", пока всего 15 страниц крупным шрифтом с комментариями -- https://www.posccaesar.org/svn/pub/SIG/MMT/MMT2010_revisedBasedOnComments.pdf
6. Template characterization methodology -- https://www.posccaesar.org/wiki/TemplateCharacterization (старый документы, еще в старинной терминологии short-hand и long-hand templates).
7. ISO15926 Primer -- https://www.posccaesar.org/wiki/ISO15926Primer (больше о том, что такое ISO 15926, чем как с ним работать).
8. ISO 15926 HOWTO -- https://www.posccaesar.org/wiki/ISO15926HowTo_Introduction, но не нужно ждать многого от этих недоделанных страниц
9. Руководство по соответствию -- https://www.posccaesar.org/wiki/IdsAdiComplianceSpecification
10. Ряд демонстрирующихся на разных семинарах слайдов Магне, в которых он приводит почти сотню примеров кодирования шаблонов (на самом деле -- графов поднятия-опускания, а то и вообще "паттернов" в виде куска семантической сетки в языке Части 2).
11. Наша инициатива -- .15926M, но эту методику только предстоит разработать (чему и посвящен этот постинг).

В презентациях можно также усмотреть несколько полностью разных стилей использования, и несколько уровней соответствия. Например, использование только части 2 для мэппинга (так называемое "промышленное использование") против пополнения справочных данных части 4 "промежуточными" классами из учебников и стандартов ("стандартное использование"). Также можно указать на моделирование и мэппинг в терминах сигнатур шаблонов только, и с указанием графов поднятия-опускания. Возможность частичного соответствия также добавляет разнообразия в подходах к использованию ISO 15926.

Тем самым, никакой особой "методологии" на сегодня не существует -- она заключается главным образом в комментариях, которые дают "модельеры с черным поясом". Более того, существую серьезные расхождения во мнениях этих "модельеров с черным поясом" по поводу методологии моделирования -- взять хотя бы дискуссию вокруг FunctionalPhysicalObject, развернувшуюся в группе "ISO 15926" в LinkedIn. Есть различия и в экспертизе самих "чернопоясников", например использование логики (аксиом шаблонов) или упор на "инженерность-без-этой-вашей-FOL".

Возможные роли для методологии:
1. Разъяснять, "с какой стороны подойти к корове". В данном случае -- к слону (любимое сравнение авторов стандарта, подчеркивающее огромность стандарта и неохватность его содержания одним человеком). Проблема в том, что сам многочастный стандарт не является "учебным текстом".
2. Обращать внимание на важные моменты, которые мало кто вычитывает из стандарта с первого раза (например, зачем в стандарте есть не только class, но и class_of_class, и почему столько споров вокруг FunctionalPhysicalObject). Ну, или разъяснять накопившиеся за много лет разночтения (типа невыразимости различения классификации, членства и специализации Части 2 в EXPRESS, но выразимости их в OWL -- "классофклассика" https://www.posccaesar.org/wiki/ISO15926inOWLPart2EntityMembership).
3. Дополнять стандарт тем, что в нем не написано:
-- руководство по локализации. Вообще, "в стандарте есть всё необходимое для создания словарей" -- но никто не знает, как нужно делать многоязычность в RDL.
-- IT-инфраструктура в типичных производственных конфигурациях САПР/PLM/ERP/EAM -- все эти data stores и data warehouse, трехсхемная архитектура, мэппинги, хранилища RDL и т.д.. Тут нужно учесть, что речь даже не идет о будущей Части 9 (которую пока никто не видел, и в которой ожидается стандартизация SPARQL-запросов к федерации RDL, которая предполагается соответствующей Части 8 -- глядите http://www.infowebml.ws/ и http://15926.org для информации двухлетней давности, а для свежей скудной информации http://iringug.org), а о растолковывании невнятного текста Части 1.
-- технология мэппинга и использования адаптеров (IRING, XMpLant и разные другие).
-- технология data handover,
-- как организовать модульность (онтолеты)
-- как организовать и администрировать RDL
-- как воткнуться в федерацию RDL,
4. Разъяснять не только то, что задумывалось в Части 2, но и "что получилось в Части 4", и "что получилось в WIP/RDS" (ибо хотели, как лучше -- а получилось, как всегда). Сейчас это -- устное предание.
5. Разъяснять template characterization в разных "особых случаях", типа "шаблоны для кодировки по KKS" или "выражение закупаемого по каталогу оборудования для тэга в составе функциональной системы".
6. Излагать технологию ISO 15926 для конкретной конфигурации софта какого-то поставщика (или набора софта разных поставщиков).

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

Есть два разных понимания методологии:
а) это стандарт действия, которому необходимо следовать
б) это учебник, по которому можно научиться

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

В случае (б) нормативные высказывания вкраплены в объясняющий и растолковывающий их текст -- и тем самым существенно снижается "нормативный градус" в пользу дидактичности.

Опять же, остается тонкая граница между уточнением и дополнением стандарта новыми нормами, и дидактичной обработкой текста стандарта плюс нормативного текста методологии.

Подход ISO 24744 и ISO 24774 (обратите внимание: это разные номера стандартов, это не опечатка!) предполагает структурное разделение нормативной части и "руководств", но ничего не говорит о возможном формате итогового текста. Пока мы не сделали .15926LMN, у нас нет софта для подобного структурирования. Поэтому придется сразу писать "вордовый документ", склоняясь к "шрифтовому" разделению нормативной, обосновывающей и дидактической/поясняющей информации.

Еще один вопрос -- это предмет методологии (scope). Понятно, что Ontology Handbook (в котором ISO 15926 занимает весьма немного места) -- это книжка на много сотен страниц. Можно начинать с того, "что такое EXPRESS" (что довольно актуально, ибо описания этого языка на дороге не валяются, а Часть вторая написана в нём -- или наоборот, неактуально, ибо реализаций в EXPRESS на сегодня по факту нет). Но тогда можно просто не дойти до сути дела. Можно приступить сразу к сути дела: "как моделировать промышленные кодировки, используя встроенный в Часть 2 парсинг текстовых строк на правую-левую части -- и оформлять это шаблонами", но это явно "дело нижнего уровня" -- и такие дела нужно объединять в мероприятия, мероприятия в практики, практики -- в дисциплины.

Учитывая, что "справочные данные" в ISO 15926 включают в том числе любые часто используемые классы (например, данные каталога оборудования), а RDL определяется просто как "набор/collection справочных данных", мы тут отходим от терминологии с RDL и переходим к терминологии "схема данных" и "НСИ" (считая, что в RDL хранится и схема данных, и НСИ).

Практики дисциплины "Инженерия схемы данных жизненного цикла":
1. Моделирование, с мероприятиями/паттернами кодирования:
-- общие принципы моделирования ("это не объект-ориентированное программирование, а онтологическое моделирование данных", разъяснение 4D)
-- типовые паттерны (архитектура "функциональный тэг, спецификация, объект в каталоге, железка", заводские кодировки типа KKS или RDS-PP, стандарты с типоразмерами и т.д.), таксономия этих паттернов/шаблонов моделирования должна оговариваться отдельно.
-- оформление шаблонами (как "порезать огромную семантическую сетку на шаблоны")
2. Мэппинг ("ISO 15926 outside") и работа с адаптерами для конкретного хранилища/склада данных.
3. Управление схемой данных (разворачивание/организация и ведение схемы данных в форме RDL), в том числе Handover схемы данных.
4. Локализация схемы данных.
5. Управление данными (экземплярами, а не схемой) с использованием схемы данных - handover.
6. Постановка метода инженерии схемы данных жизненного цикла

Дисциплина "Ведение нормативно-справочной информации" (не хочется использовать "управление НСИ", или "инженерия НСИ")
1. Практика ведения Каталогов промышленной продукции
2. Практика ведения Нормативных баз данных (техрегулирование, Sarbanes-Oxley и т.д.)

Дисциплина "Управление данными инжинирингового проекта"
1. Практика Plant Design and Project Data handover

Дисциплина "Инженерия IT-инфраструктуры для ISO 15926"
1. Практики разворачивания систем конкретных поставщиков софта в варианте использования ISO 15926

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

Комментируйте.
2021 год
  • ailev

Семинар по каталогу Росатома, день второй

Маг и волшебник Джохан Клювер убедительно показал, что всё добро в части 7, а в части 8 одновременно ужас и счастье. Счастье заключается в том, что мы попадаем в волшебный мир трипл-сторов с мидлверами, множества учебников OWL и SPARQL, готовых пруверов и таких восхитительных программ, как Protege. А вот ужас в том, что вышивание шаблонов на OWL невыносимо: пара строчек шаблона разворачивается 80-ю строчками на SPARQL в дикую структуру OWL, которую даже поглядеть через Protege очень трудно, не то чтобы в самом тексте на OWL. Опять же счастье, что технически этого развернутого в OWL шаблона никто никогда не увидит. Несчастье в том, что пока нет никакой технологии, которая позволяла бы реализоваться предыдущему предложению: как раз сейчас-то все именно это и видят. И это мейнстрим, куда пойдут все.

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

К проблеме масштабируемости с предлагаемыми в части 8 технологиями страшно подступиться. Вечный вопрос: на какой уровень предварительно всё разворачивать, а что оставлять для разворачивания на лету при любом запросе? Как предлагаемый темплейтный подход будет тянуть стандартный для семантического веба софт, ежели его грузануть каким-нибудь проектом атомной станции или подводной лодки в порядке handover этого проекта в формате ISO 15926? Сколько там будут шуршать проверки при добавлении/удалении какого-нибудь темплейта? Сутки? Двое?

Кстати, iRING не соответствует части 8.

И OIM -- не рекомендованный к применению термин, ибо это дань уважения объект-ориентированным программистам (и именно поэтому в тексте рядом с описанием того, что такое OIM много объектных, т.е. UML диаграмм. Именно поэтому много комментариев, нивелирующих значение OIM). Лучше говорить {local, domain, выберите любое слово по вкусу} ontology.

Вера в осмысленность нашего .15926 в мировом мастабе у меня растёт ежедневно.