September 18th, 2010

2021 год
  • ailev

Семантический репозиторий

Семантический репозиторий -- это тот, в который можно загрузить отражающую картину мира схему на OWL или похожем языке. Вот примеры:
1. сервера жизненного цикла современных САПР (SmartPlant Foundation, enterprise Bridge, ProjectWise Life Cycle Server, AVEVA Portal и Platform, ENOVIA)
2. специализированные репозитории для промышленных данных (типа Jotna EXPRESS Data Manager)
3. репозиторий Simantics (http://simantics.org)
4. современные triple store с SOA-обвязкой и выходами на контент-анализ (AllegroGraph, OpenAnzo, ORDI, и далее Cogito, Collibra, GATE и т.д. -- http://ailev.livejournal.com/861393.html).

Обратите внимание, что все репозитории ("сервера") 1 и 2 растут из области САПР (а именно -- PLM, ибо они все работают с данными САПР), 3 уникален тем, что взял в область САПР технологию semantic web еще в 2006г. (когда она была не так кучерява. как сегодня), а 4 обслуживает потребности кого угодно, кроме САПР -- и поэтому не тяготеет к структурам данных кого-то из традиционных сапровских/пээлемовских вендоров софта.

Универсальные репозитории существенно отличаются своей онтологичностью от серверов мастер-данных, которые явились высшим пунктом эволюции айтишных баз данных. Онтологи обращают внимание на то, как устроен мир, и фланец у них -- это фланец. Айтишники работают с данными, не обращая внимания на то, что они моделируют -- текстовыми строками, числами и т.д. Они занимаются хранением, копированием, передачей информации без понимания, о чем она. Фланец у них -- это либо отношение, либо атрибут, либо объект, либо выбор из таблицы. У айтишников формальные преобразования, которые обеспечивает где-то хранящийся код. Программа = алгоритмы плюс данные, и данные без алгоритмов для них бессмысленны. У онтологов сами данные знают, что с ними можно делать, данные осмысленны, в том числе и сами по себе. В чем-то это похоже на различие учетной парадигмы инфологии и даталогии (http://ailev.livejournal.com/593013.html), наиболее четко определяемой в DEMO.

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

Ключевой признак базоданческих, моделирования/метамоделирования (по сути -- объект-ориентированное моделирование) и прочих неонтологических схем данных: они кодируют только тот кусок мира, который был в первоначальной постановке задачи. Верхушка схемы никак не связана с моделью мира как такового. Вверху какой-нибудь "Элемент", и далее идут его специализации (например, "Шаблон", "Документ" и т.д.). Ключевой признак онтологических схем данных даже не в том, что экземпляры и классы находятся в одной и той же онтологии/репозитории и не так уж драматически отличаются друг от друга, как схема базы данных и сами данные. Ключевой признак в том, что "верхушка схемы" представляет собой краткое описание устройства мира "впрок" -- то есть в ней так или иначе присутствует деление на абстрактные объекты, физические объекты, феномены и события, действия отличаются от объектов и т.д.

Парадигма моделирования/метамоделирования (включая "трансформации моделей" и MDA) связана с объект-ориентированными (объекты с атрибутами, не-факт-ориентированными) моделерами, которые выдают ОО-схему какого-то крошечного кусочка мира и код, воплощающий семантику для этой схемы. Ибо в самой ОО-схеме этой семантики обнаружить не удастся. Если у вас верхний элемент схемы "модуль", то только из кода вы сможете узнать, что это такое. Если Action в ISO 24744 по сути представляет собой отношение, а не "предмет", то это можно узнать только из комментария, и учесть только в программном коде.

Поэтому эта парадигма "моделирования/метамоделирования" отличненько живет с традиционными (то есть реляционными) базами данных: запросы к данным генерируются из кода модели чаще всего прямо на SQL. Только в последнее время в MDA обсуждают существование каких-то NoSQL баз данных. В любом случае, генерация запросов из кода модели не подразумевает использование предопределенной еще до конкретного проекта моделирования ("нейтральной" по отношению к проектам) схемы данных с самой общей картиной окружающего мира, подразумевающей постепенное расширение и уточнение. В модели (и далее -- в схеме данных, используемой для настройки базы данных -- т.е. в схеме базы данных) присутствует чаще всего только структуры хранения данных помянутых в метамодели объектов.

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

Проблема с универсальными репозиторием в том, что у него датологический низ и инфологический верх. Различия лишь в том, что даталогический низ может быть:
-- основан на допотопном языке EXPRESS
-- основан на проприетарных сапровских моделях данных (всякие "объекты-атрибуты-связи" разных мастей) и особых языках работы с ними
-- основан на OWL/RDF и хранилищах триплов и SPARQL

В проекте .15926 мы делаем следующие выборы (компонента server из Roadmap -- http://community.livejournal.com/dot15926/7723.html):
-- признаём, что без репозитория жить нельзя: все данные (как проекта, так и справочные) нужно где-то хранить
-- не выдумываем собственного даталогического "микропрограммного" уровня для реализации репозитория
-- не берем репозиторий какого-то CAD/PLM: это не только дорого, но и сразу очень нестандартно, плохо документировано, нет специалистов, нет литературы и обмена опытом использования, нет теоретической базы и растущего числа утилит.
-- берем хранилище триплов с надстроенными над ними средствами контроля версий, администрирования, многопользовательской работы, программирования/запросов и контроля целостности (решатели).
-- думаем, какие функции из джентльменского набора SOA/middleware (транспорт данных, регистр приложений, идентификация/аутентификация и т.д.) в этом хранилище триплов уже есть, а какие нужно будет добавлять отдельными серверами
-- думаем, какие спец.базы данных нужно добавить (документов-файлов, временнЫх рядов и т.д.)
-- думаем, какую можно добавить внешнюю workflow engine, business rules engine (если их еще нет составе стандартного middleware -- но вполне возможно, что "низкоуровневые" схемы местных engine не подойдут, и захочется сразу иметь высокоуровневую engine, работающую в общей онтологии, а не "сбоку" -- и тут сразу будут сложности!).

Ключевая идея тут: прикладной проект с использованием такого "заточенного на разработку" и отлаженного в ходе работы со множеством разработчиков репозитория сделать будет быстрее, нежели с использованием репозитория из какого-то САПР. Единственное преимущество репозиториев CAD/PLM -- это наличие готовых конверторов данных (адаптеров) из других САПР в их специфическую модель данных, а также наличие готовых браузеров для каких-то типовых инженерных моделей. Как только мы сталкиваемся с ситуацией отсутствия таких конверторов и/или браузеров (например, при создании каталогов), преимущество традиционных PLM становится призрачным: более приспособленные к разработке на их основе трипл-сторы с миддлвером могут выдать на-гора решение быстрее, нежели какой-то "сервер-из-PLM", который с самого начала был заточен на весьма узкий класс применений.

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

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