Category: литература

Category was added automatically. Read all entries about "литература".

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 и программного обеспечения.
2021 год
  • ailev

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

Большинство фич скорого уже релиза .15926 Editor версии 1.2 в состоянии "in test", по ним дописывается документация. Самое время подумать о фичах версии 1.3.

В версии 1.2 наш Editor поумнел, пошустрел и стал надёжней, а в версии 1.3 он должен будет обеспечить поддержку методологии разработки RDL. Это означает:

1. Должна быть обновлена наша методология разработки справочных данных (как по содержанию -- с учётом новых наработок в комьюнити ISO 15926, так по форме -- с учётом появления стандарта Essence).

2. Поддерживаем работу с файлами RDL прежде всего (со SPARQL-endpoint тоже будем разбираться, но позже), для файлов поддерживаем версионирование (цель: иметь commit и прочие операции с версиями прямо из Editor).

3. Поддерживаем работу с issue tracker (один редактирует, другой проверяет, ошибки обсуждаются, третий утверждает и публикует, и т.д.).

Конечно, мы понимаем, что ведутся активные споры: разработка онтологий похожа на разработку софта, разработку моделей, разработку инженерных артефактов (архитектурных описаний или чертежей), или ни на что из этого не похожа. Опыта реального ведения RDL, увы, не так много. Так что многое придётся придумывать самим.

Поэтому просим людей, которые как-то используют в работе наш .15926 Editor (мы знаем, такие люди есть!), дать предложения по самым нужным им фичам в части управления конфигурацией RDL и поддержки жизненного цикла разработки RDL. Сюда комментами, или письмом -- всё одно. Вовремя фичу попросите -- вовремя фичу получите!
2021 год
  • ailev

Трудности в освоении ISO 15926

Сначала я хотел дать короткий список абсолютно контринтуитивных мест ISO 15926, в которых путаются все без исключения, и для которых требуется специальная разъяснительная работа:
1. Классы классов, классы и индивиды -- членство в классах. Специализации как противопоставление этому. Как жить без атрибутов.
2. События, изменения, причинность и процессы как отношения временнЫх частей вещей. Виды участия в изменениях (activity). Как жить без процессов.
3. Как моделировать систему: функциональные объекты (PBS) и конструктивные объекты (комплектующие/предметы снабжения). Как жить в системном подходе.
4. Отдельная беда: все три предыдущие контринтуитивности используются одновременно и в сочетании.

Потом понял, что этот список а) слишком короткий, это только главное, что лежит на поверхности и б) у каждого отдельного ученика могут быть затыки даже не в этих местах, а в каких-нибудь других (взять хоть те же presentation и representation).

И решил пока никакого списка не писать.

Что не отменяет нужды в учебном материале по хотя бы трём первым пунктам. Ибо более-менее подробные объяснения из книжки BORO делаются в совсем другой онтологии/терминологии, нежели скупые пояснения в книжке HQDM, а в ISO 15926 никаких разъяснений нет (кроме нескольких примеров из 15926.info), а онтология/терминология опять же отличается от используемых в разъяснениях-пояснениях. Можно, конечно, уповать на то, что самые сильные ученики прорвутся через все три варианта -- и просветлятся в понимании общего для всех трёх источников знания принципа, и будет им неизбывное счастье (ну, или неизбывное расстройство, когда поймут, что отцы основатели и основоположники (отцеположники -- для краткости) не договорились, и везде объясняется похожими словами похожее, но совсем разное.

В любом случае, от ISO 15926 ломка головы нешуточная -- и требуется довольно солидное время для привыкания даже к рационально уже понимаемому.

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

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

Russian Semantic Day 2011

Во вторник 6 декабря 2011г. в Москве в офисе TechInvestLab состоялась рабочая встреча по обмену опытом и демонстрации результатов в области применения стандарта ISO 15926 (Russian Semantic Day). На встрече были представлены следующие доклады:

1. Александр Шаманин, Мартин Давтян (Судоэкспорт): "Опыт задания модели данных каталога оборудования в AVEVA NET портале загрузкой справочных данных ISO 15926".



2. Сергей Гумеров (IBM): "Поддержка ISO 15926 в проектах IBM".



3. Павел Сельчуков (Росэнергоатом): ""Библиотека справочных данных Росэнергоатома: план работ"

Видео первых трех докладов:



4. Артем Горбунов (Яндекс): "Опыт характеризации программной системы с использованием ISO 15926".



5. Роман Рябенко: "Редактор диаграмм ISO 15926".



6. Алексей Иванов (V3-services): "Редактор ISO 15926 на основе EMF Eclipse"



Видео вторых трех докладов:



7. Валерий Крылов (TechInvestLab): демонстрация .15926 Editor



8. Виктор Агроскин (TechInvestLab): демонстрация .15926 Tablan

Были использованы слайды июньской 2011г. презентации на Semantic Days в Осло:



Видео демонстраций TechInvestLab:

2021 год
  • ailev

Освоение ISO 15926

Освоение ISO 15926 по сегодняшнему состоянию требует следующих действий:

1. Понимания, для чего это всё нужно -- и уяснение основных принципов:

а) начинать нужно с чтения книжки Chris Partridge "Business Objects: Re-Engineering for Re-Use), она же "книжка BORO": http://ailev.livejournal.com/938647.html
614 страниц текста, но после них становится понятно, почему плохо моделировать данные объектами и атрибутами, а нужно обращение к факт-ориентированному подходу. Проблемы с этой книжкой в том, что она излагает основы BORO-метода (хотя слово "BORO" не встречается в книжке ни разу), она не использует привычной терминологии -- ни ISO 15926, ни какой-либо другой, она вообще не касается формализмов представления информации (там предлагаются очень элегантные диаграммки, которые больше никем и нигде не используются). Тем не менее, книжка обязательна к прочтению: без нее вам не отбиться от любого первокурсника, который будет не понимать, чем подход ISO 15926 лучше подхода если не реляционных, то объект-ориентированных (объекты с атрибутами вместо таблиц) баз данных -- зачем нужно учить что-то новое, если и старое еще не до конца освоено.

При чтении 7 главы (Physical Bodies as Four-Dimensional Objects) нужно обязательно поглядеть фильм с лекциями Юрия Балашова: http://ailev.livejournal.com/913373.html

б) продолжать нужно чтением книжки FIATECH "An Introduction to ISO 15926" -- http://fiatech.org/images/stories/techprojects/project_deliverables/iso-intro-ver1.pdf
Это 181 страница текста, после которых появляется представление об истории появления ISO 15926 и его возможных применениях.

в) заканчивать понимание основных принципов нужно:
-- чтением книжки Matthew West "Developing High Quality Data Models" (книжка HQDM): http://www.amazon.com/Developing-High-Quality-Data-Models/dp/0123751063 (но вы легко найдёте эту книжку в он-лайн библиотеках, она в электронном виде есть).
408 страниц текста, написанных ведущим разработчиком ISO 15926 уже после выхода стандарта. Это не ISO 15926, а "улучшение части 2 ISO 15926, если бы ее пришлось делать еще раз". Книжка очень кратко пересказывает до страницы 151 приложения рассказанной в книжке BORO теории к моделированию данных (книжка BORO вообще данных не касается, там про другое), затем страницы 151-201 рассказывают, как моделировать самые разные предметы окружающего мира -- организации, продукты, системы и т.д.. Далее до конца книжки идет описание модели данных HQDM и мэппинга ее в ISO 15926-2 (эту модель данных можно безболезненно пропустить).
-- чтением диссертации Andries van Renssen "Gellish. A Generic Extensible Ontological Language": http://repository.tudelft.nl/assets/uuid:de26132b-6f03-41b9-b882-c74b7e34a07d/its_renssen_20050914.pdf
Эти 268 страниц тоже не ISO 15926, и эта книжка также написана одним из соавторов ISO 15926 как "улучшение принятых при создании ISO 15926 решений". Можно, конечно, считать эту книжку "необязательной программой" (тем более, что есть многочисленные идеологические расхождения подхода Gellish и ISO 15926), но там содержится очень много знаний, вполне приложимых к ISO 15926. С учётом того, что большинство людей из сообщества ISO 15926 знакомы с подходом Gellish, эта книжка входит в "культурный минимум" модельера данных.

Итого: для понимания теоретических основ нужно одолеть примерно 1200 страниц текста, это (считая 1 страницу в 3Кзнака) примерно 4тыс. Кзнаков, и если читать за час 30Кзнаков (10 страниц в час), то это работа на 120 часов -- без упражнений и времени на разглядывание картинок и понимание. То есть за месяц по четыре часа в день (хотя и без выходных) вполне можно одолеть, нужно только сосредоточиться.

2. Практика -- ISO 15926 сам по себе
Увы, практика подразумевает обязательное выполнение упражнений -- но упражнений пока нет, их только предстоит разработать

а) нужно освоить ISO 15926 часть 2
Это 241 страница очень насыщенного текста: описание 201 типа, к которым нужно будет относить любую встреченную сущность (entity). Именно этот набор сущностей отличает ISO 15926 от любой другой онтологии -- будь то родственные IDEAS, HQDM, Gellish, или более далёкие CYC и DOLCHE. Это "Отче Наш", это и есть "ключевые слова" языка ISO 15926. Проблема в том, что без знаний из пункта 1 данного учебного плана понять эту часть стандарта невозможно.

б) провести разбирательство с PCA RDL (библиотекой справочных данных POSCCaesar Association, которая должна быть существенно улучшена проектом JORD). Для этого нужно:
-- читать 47 страниц проекта Части 6 (внимание! это еще не стандарт, только проект!) ISO 15926 -- правила ведения RDL, нужные для понимания, откуда что берется в PCA RDL (они также будут полезны для вашей собственной работы: вам же тоже придется разрабатывать корпоративную библиотеку справочных данных).
-- при помощи .15926 Editor разглядывать PCA RDL (см. документацию к этому софту), хотя пользы от этого столько же, сколько от чтения энциклопедии, там ведь порядка 50тыс. сущностей из самых разных предметных областей. Но внимание нужно обращать на общую структуру: как оно устроено хотя бы на верхнем уровне.

Читать Часть 4 не нужно, там просто задавалось начальное содержимое RDL, которое после некоторого развития (некоторые язвят -- замусоривания) привело к появлению PCA RDL в текущем состоянии.

в) Ознакомиться с механизмом шаблонов:
-- читать Часть 7 (механизм шаблонов) -- 126 страниц, без которых с шаблонами не разобраться.
-- увы, нужно читать также и Часть 8 (отображение шаблонов в языке OWL) -- это 58 страниц, которые вроде как предназначены только для программистов, которые пишут реализации ISO 15926, но многие важные для практической работы сведения (например, про пространства имён ISO 15926) приведены именно в этой части стандарта.

г) потратить время на чтение чужих справочных данных ("чтобы научиться писать свои программы/романы, нужно научиться читать чужие"):
-- в качестве обязательного материала (несмотря на то, что у автора этого вебсайта -- тоже одного из соавторов ISO 15926 -- своя точка зрения, не всегда совпадающая с "буквой ISO 15926") -- разбирательство с содержимым вебсайта http://15926.info/
-- можно найти некоторое количество примеров в комплекте поставки .15926 Editor (http://dot15926.livejournal.com/28678.html)

д) прочитать методику ижненерии справочных данных: http://techinvestlab.ru/files/RefDataEng/RefDataEngr_ver_2_25feb11.doc -- 18 страниц, описывающих метод "ISO 15926 Outside"

е) подписаться на дискуссии в комьюнити "ISO 15926" в LinkedIn и почитать их.

Итого: страниц текста всего около 500, но зато много-много разглядывания диаграмм и деревьев со структурированными данными. Времени это займёт много больше, чем чтение первой тысячи страниц -- минимальная оценка тут два месяца.

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

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

Архитектурные языки, архитектурные подходы (frameworks), UML profiles и 4D extensionalism

DoDAF 2.02 (Department of Defence Architecture Framework Version 2.02, принят в августе 2010г., http://cio-nii.defense.gov/sites/dodaf20/index.html) -- это обязательный для использования архитектурный подход министерства обороны США. Во всех военных проектах США используют предопределенный набор тематических групп описаний.

Этот набор описаний выражен в терминах метамодели MD2 (http://cio-nii.defense.gov/sites/dodaf20/DM2.html), so the architectures can be integrated, analyzed, and evaluated to mathematical precision. Эта метамодель представляет собой ограниченный словарь, в терминах которого описываются модели этой архитектуры. Фишка в том, что логический уровень этой метамодели представляет собой UML-профиль для IDEAS, которая является 4D upper ontology (http://cio-nii.defense.gov/sites/dodaf20/Ontology1.html), ближайшим родственником Части 2 ISO 15926.

Недавно была выложена книжка Chris Partridge "Business Objects: Re-Engineering for Re-Use", 2000г., с изложением основных идей технологии BORO (http://www.brunel.ac.uk/%7Ecssrcsp/BusObj.pdf). Именно технология BORO и легла в основу 4D онтологии IDEAS. В этой книжке педантично расписано (хотя и не в терминологии ISO 15926), какие проблемы решаются переходом от описаний в объектно-атрибутивной парадигме к логической (классы), и почему нужно было вводить 4D. Я бы считал, что для промышленных онтологов это обязательное чтиво, там есть множество объяснений, до которых не снисходят авторы текстов по ISO 15926. Конечно, при этом не нужно забывать, что тамошняя онтология совсем не похожа на ISO 15926, и учиться нужно не представленной там онтологии, а излагаемому в книжке куску философской логики.

А теперь критика DoDAF 2.02:
1. IDEAS там появилась из понимания, что архитектурной информацией нужно обмениваться между разными архитектурными системами. Идея интеграции (в данном случае архитектурных) данных неминуемо влечёт вызов онтологических духов, а современные онтологические духи всё чаще и чаще выбирают 4D, чтобы не запутаться в отслеживании превращения гусеницы Дуси в куколку Дусю, а затем и бабочку Дусю.
Мы вполне могли бы выбрать ISO 15926 для тех же целей: интеграции архитектурной информации, в том числе информации enterprise architecture. Но мы лучше выберем ISO 15926 не для задач outside (как была выбрана модель IDEAS), а для задач offsite и inside. Я пока не чувствую острой необходимости перегонять модели ARIS в модели DoDAF или ToGAF. Мне бы эти модели разрабатывать, и вряд ли с использованием этих архитектурных подходов. Тем не менее, я бы использовал ISO 15926 непосредственно в качестве метамодели: so the architectures can be integrated, analyzed, and evaluated to mathematical precision.

2. Идея сделать UML-профиль для ISO 15926, чтобы работать с UML-редакторами, мне представляется сугубо неправильной. Тут два возможных варианта:
-- поступить, как в BORO, и вместо диаграмм Части 7 придумать богатый графический язык для выражения ISO 15926 (в том числе расширяемый микротеориями, задающими "профили", как в UML)
-- сделать свой "похожий на UML" графический язык с онтологическими расширениями, пройдя по пути OPML (http://www.cesames.net/fichier.php?id=370, http://www.cesames.net/fichier.php?id=371).
-- считать, что будет много разных DSL, и принципиально не заморачиваться одним каким-то базовым графическим или текстовым языком. Много-много projectional editors, показывающих в разных DSL кусочки общей семантической сетки. И сосредоточиться на придумывании этих DSL для разных views. Пока склоняемся к этому варианту, ибо остальные являются частными случаями этого.

3. Что касается использования IDEAS, то два уровня неадекватности (UML-профиль, а поверх него давно критикуемый жестко определенный набор методов описаний собственно архитектуры) полностью закрывают возможные достоинства использования IDEAS -- я писал об этом механизме нивелирования достоинств технологий неудачностью использующих их приложений тут: http://ailev.livejournal.com/936771.html.
Мы тем самым должны отойти от жесткой заданности набора методов описаний, но дать все необходимые механизмы для ситуативного его построения (см. http://praxos.livejournal.com/12468.html).
2021 год
  • ailev

ISO 15926 outside, inside, offsite

На данный момент в дикой природе можно встретить самые разные методы, использующие ISO 15926:

1. "ISO 15926 outside", или интеграция данных. Библиотека справочных данных при этом строится для того, чтобы наладить мэппинг каких-то проприетарных схем/моделей данных к нейтральной схеме данных. Примеры:
-- архитектура современных PLM, интегрирующих данные САПР (хотя это "Проприетарная схема outside", не верьте заявлениям фирм, что это ISO 15926 -- даже если об этом заявлено в документации. В 1997г. еще не было ISO 15926, поэтому "основанные на snapshot 1997г. схемы" не могут соответствовать Стандарту. Мы тут говорим просто о похожести метода использования библиотеки справочных данных, а не ее соответствии Стандарту).
-- Simantics, в котором воспроизводится архитектура PLM, но при этом четко заявляется, что все обработки делаются в специализированных симуляторах, которые работают каждый в своём формате -- а тамошняя онтология служит только для целей "внешней интеграции". Опять же, онтология simantics ни разу не ISO 155926, но это "проприетарная схема outside".
-- наша методика инженерии справочных данных "ISO 15926 outside" (http://techinvestlab.ru/files/RefDataEng/RefDataEngr_ver_2_25feb11.doc )описывает ровно этот метод.
-- IRING поддерживает ровно этот метод.

Главный критерий: если никаких передач данных нет, то это не "ISO 15926 outside".
Особенность: ISO 15926 целенаправленно делался для поддержки ISO 15926 outside, все остальные методы даже не рассматривались.

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

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

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

Это использование напоминает известную технику понимания текстов: чтобы разобраться в тексте, нужно перевести его на другой язык. Таким языком выбирается онтологический ISO 15926, заставляющий в ходе онтологического анализа задуматься о многих важных и интересных вопросах, связанных с разбираемым текстом: какова природа поминаемых в тексте или наборе данных объектов?

Главный критерий: нет ни передачи данных, ни обработки данных -- только разработка справочных данных и "подъем в цифру" каких-то не слишком формальных документов. В лучшем случае для результирующих данных ISO 15926 есть проверка целостности, но и это не факт.
2021 год
  • ailev

Релиз .15926 browser 0.4 alpha 4

TechInvestLab выпускает сегодня первую версию софта .15926 -- freeware браузер данных ISO 15926, версия 0.4 аlpha 4 (брать тут: http://techinvestlab.ru/files/dot15926v04alpha4/dot15926_v04_alpha4.rar). Софт выпущен пока только для Windows.

Я поздравляю нас всех (dot15926 читает уже 61 человек). Очень радостно, что такой софт разрабатывался русскоязычной командой. Особое спасибо vvagr и justy_tylor. В предыдущих версиях этого софта (а перед релизом было написано и выкинуто три исследовательских версии -- было очень много приключений в этом проекте!) нам также помогал algebraic_brain.

.15926 browser понимает файлы в нескольких форматах, и умеет показывать:
-- 201 тип части 2 (информация собрана из трёх разных файлов, взятых в https://www.posccaesar.org/wiki/ISO15926inOWL).
-- классы и отношения из PCA RDS. Текущий экзепляр содержит примерно 2млн.700тыс. триплов.
-- шаблоны части 7 (в формате Части 8, в том числе примеры из самого ISO 15926), поддерживается просмотр файлов, экспортированных из Iring 2. Поскольку эти шаблоны обычно ссылаются на RDL/WIP, а не PCA/RDL, то .15926 browser умеет использовать файл-мостик, в котором прописаны соответствия данных этих двух библиотек.
-- проектные данные (инстансы). Обращаем особое внимание, что на сегодняшний день классы, шаблоны, отношения и их инстансы "в одном флаконе" не умеет показывать ни один другой софт в мире.

Софт содержит примеры, которые взяты из RDL Rosatom (http://iatom.ru/documents/others/) -- поздравляем наших коллег из атомной энергетики, которые сделали публично доступными свои справочные данные! Наш софт позволяет удобно просматривать эту библиотеку.

Более подробное описание вы можете найти в help программы.

Пример скриншота:


Замечания, предложения, восторги и сетования по поводу данного релиза можно оставлять прямо в этом сообществе -- dot15926. Отвечать будем также на письма, приходящие на dot15926@gmail.com

Текущий roadmap прост и незатейлив:
-- выпустить следующую версию как Editor, выпустить исходные тексты
-- далее добавить много-много разных проверок данных
-- потом добавить редактирование аналитических диаграмм
-- затем добавить к Editor с диаграммами возможность мэппинга

Успешных обменов данными!
2021 год
  • ailev

Онтолёты и их вёрстка

1. Вот для меня есть какой-нибудь ISO 24744, и я начинаю редактировать набор шаблонов, который позволит мне выражать методы так, как это принято в ситуационной инженерии методов. То есть я выражаю знание (метамодель) о предметной области как набор шаблонов. Это и есть «онтолет 24744». Я могу сказать: «методолог, подгрузи онтолет 24744 – и не парься, у тебя все нужные шаблоны для кодирования методов будут».

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

Это и есть мои use-cases. Это примерно соответствует термину OIM в стандарте (часть 8), но термин Object Informaion Model deprecated, потому как остался от тяжелых времен объектно-ориентированного прошлого, и Клювер не рекомендовал его употреблять – а использовать любой термин со смыслом «маленькая, ограниченная онтология», я и предложил «ontolet». Ибо термин OIM и объект-ориентированность ушли, а нужда в чем-то подобном осталась.

Поэтому я считаю, что бывший OIM, нынешний ontolet должен стать first class object. Опыт показывает, что при кодировании какого-то ГОСТа имя этого госта ставят прямо в начало строки label для сущности. Например «24744 activity», а не просто "activity". Вот если сделать выборку по всем этим «24744 *» именованным шаблонам, то это и будет «онтолет, явленный в ощущениях». То, что я хочу, это убрать кодирование онтолетов из строк-имён в виде неведомых программе и значимых только для людей префиксов, и сделать его кошерно, т.е. на отношениях. А редактор и сервер должны это отношение как-то понимать, и всяко поддерживать в операциях.

Мне тут все равно, называется это онтОлет, Онтолет или онтолЁт -- если даже распространится последний вариант произношения, это будет весело, но действенно и понятно.

2. Но никакой апплет не используется сам по себе. Чтобы сделать что-то разумное, их нужно несколько. Я думаю, тут тоже нужно идти от программирования. Как называется связка всех нужных подгружаемых компонентов программы (а еще лучше – задействуемых сервисов, и сервисов, задействуемых задействуемыми сервисами)? Понятно же, что какому-нибудь приложению из Линукса нужно много пакетов, но отнюдь не весь дистрибутив. Придумайте сами какой-то термин (насколько я знаю, термина нет, используется всегда сложноподчиненное предложение типа "все нужные пакеты", в нашем варианте -- "все задействованные онтолеты". Гы, "эскадрилья").

Но для меня literary programming в его разных вариантах более главная метафора, чем метафора линкера/таскбилдера (ежели кто еще помнит такие слова). Алан Кей говорит, что «приложения верстаются из отдельных моделек микропредметных областей, как газеты». Мне это тоже нравится – «книжка» или "журнал" (в том числе "бортовой журнал", в котором всё меняется и в котором все записывается -- log), в которой может быть сверстано несколько онтолетов. Примерно соответствует также экселевским book, или workspaces, или project во многих программах. Не хотел бы называть project, ибо у меня это слово зарезервировано под последовательность работ (а не продукт). Остается book или workspace (то есть вид 24744 – work product, или composition of workproducts). Что-то, куда подверстываются онтолеты по мере необходимости. Называть этот объект нужно так, как он выглядит на экране -- какая-то большая страница, или полоса, или книга ("свиток") для верстки.

Книгу пишут/редактируют, рабочее пространство заполняют, кохают и лелеют (это «сборочная площадка» итогового продукта) – а потом оно само вдруг может закончить жизнь новым онтолетом, например (если суть дела была – создать описание новой предметной области на базе какой-нибудь старой предметной области). Ну, или это может быть модель/набор моделей, где набор онтолетов – метамодель, и мы просто моделируем в терминах давно известных предметных областей.

Тут я думаю, что есть еще нечто, называемое «каталог доступных для верстки онтолетов», ибо "библиотека онтолетов" подразумевает их полное собрание, а каталог -- только описание (иногда это обсуждают как разницу между "справочником" и "хранилищем", "directory" и "server", "registry" и "repository").

Я тут не предписываю пока ничего. Это самые общие мысли о том, как могла бы выглядеть онтологическая работа. Как программирование: пишешь библиотеки, а потом на базе их и «внешних библиотек» либо пишешь новые библиотеки, либо пишешь новые приложения. Без модульности каюк. Когда-то паскаль продувал Фортрану, потому как в Фортране через коммон блоки можно было сделать то, что потом в Аде назвали «пакетом», а в «Модуле» модулем – а в Паскале формально можно было писать только монолитные программы, это было даже хуже, чем в Фортране с его коммон блоками, которые позволяли склеиваться огромным кускам кода, которыми можно было управлять как-то независимо. Нам нужно с самого начала это поддержать. Это ключ к успешной работе, это вопрос выживания. Ну, и поддержку нескольких независимых друг от друга недоделанных работ – workspace, или notebook (кажись, в Matematica это так называется), или в Excel это book.

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