Можно и нужно использовать онтологию для генерации кода для преобразователей данных?
Учитывая наличие трех основных конкурирующих приложений, каждое из которых реализует несколько другую схему данных для одной и той же проблемной области, я столкнулся с задачей реализации:
- "каноническая" схема данных, достаточно выразительная, чтобы представить что-то вроде набора пересечений функций всех трех приложений, а также дополнительных деталей (метаданных)
- преобразователи для осуществления (двунаправленного) обмена данными между этими 3 приложениями и канонической схемой
Как я сейчас подхожу к задаче
Каноническая схема определяется с использованием XSD и очень похожа на схему данных одного из трех приложений, назовем ее A. Это делает обмен данными с A тривиальным. Чтобы обеспечить двунаправленный обмен данными с приложениями B и C (создать некоторое состояние в A, загрузить его в B, изменить его в B, загрузить измененное состояние в A), я пытаюсь отобразить простые состояния в A на более сложные состояния в B/C, которые можно идентифицировать и деконструировать при обратном отображении.
Пример: в A объекты могут просто "зеркально отображаться" как внутреннее геометрическое преобразование, тогда как в B и C мы должны ввести "зеркальное подпространство", в которое встроен соответствующий объект. Это "зеркальное подпространство" также доступно в A. Таким образом, во время преобразования B->A мы должны решить, должно ли "зеркальное подпространство", обнаруженное в данных, отображаться в "зеркальное подпространство" в A или оно должно быть заменено внутренним геометрическим преобразованием объекта. В настоящее время я делаю это, специально помечая те "зеркальные подпространства", которые были введены только во время преобразования A->B.
Почему я хочу изменить свой подход
- Большинство отображений схемы довольно тривиальны (имя объекта в A просто отображается на имя объекта в B), поэтому я хотел бы избежать написания большого количества тривиального кода вручную. Я предполагаю, что этот тривиальный код может быть сгенерирован с учетом формализованного отображения между схемами данных.
- Что касается нетривиальных частей отображения (например, описанных выше), я ожидаю много изменений в будущем просто потому, что это кажется настолько произвольным. Во многих случаях конкретное соглашение для отображения состояний в A на более сложные состояния в B/C может в какой-то момент зайти в тупик. Например, пользователям может потребоваться изменить метку "зеркальное подпространство", и поэтому может потребоваться другой подход для идентификации артефактов преобразования. Я полагаю, что формализованное отображение может быть инструментом для прозрачного управления этими соглашениями. Возможно, рассудитель мог бы даже автоматически обнаружить несогласованные, непоследовательные отображения. Это также может позволить мне более легко обсудить сопоставление с экспертами и пользователями доменов.
Вопросы
- Из того, что я прочитал об онтологиях, у меня сложилось впечатление, что я хочу получить онтологию. Это правильно?
- Насколько я понимаю, использование онтологии для описания сопоставления также потребовало бы от меня выражения самих схем данных в онтологии (поэтому отношение "сопоставляется" может ссылаться на тип из A и тип из B). Поскольку эти схемы взяты из долгоживущих приложений, они не всегда последовательны. Например, "функция" в приложении может привести к тому, что у некоторого состояния будет другая семантика, которую вы ожидаете от семантики его составляющих. Могут ли существующие инструменты помочь мне справиться с этими сложностями?
- Я ожидаю, что мне потребуются некоторые дополнительные механизмы внутри онтологии, чтобы описать что-то вроде взятой из приведенного выше примера разницы между "постоянным зеркальным подпространством" и "рассеивающимся зеркальным подпространством" (два типа + специальное отношение, соединяющее их?), Было бы много усилий сделать? Предоставляют ли доступные языки онтологии что-то из коробки, чтобы выразить это?
- Является ли это приложение онтологий распространенным приложением для онтологий, или это угловой случай? Знаете ли вы о компаниях, которые предоставляют услуги для этого приложения?
- Какие инструменты вы бы предложили для создания онтологии? Я предполагаю, что нет никаких готовых инструментов для упомянутой генерации кода. Итак, как бы вы подошли к задаче генерации кода?
1 ответ
Абстрагирование системы типов, набора интерфейсов и правил преобразования определяется как подмножество создания онтологий, известное как метамодель. Метаобъект (MOF) является примером:
Интерфейсы MOF и Модель MOF могут использоваться для определения конкретных метамоделей для базы данных, хранилища данных, преобразования модели и областей управления хранилищем
Возможности перевода IDL MOF отображают один класс на два интерфейса. Можно было бы определить преобразования для альтернативных представлений интерфейса, таких как интерфейсы Java.
Существуют и, вероятно, всегда будут существовать различные мнения среди лидеров отрасли относительно определения концепций класса, типа и интерфейса. В качестве среды моделирования, специфичной для предметной области, до тех пор, пока MOF четко понимает значение класса в MOF, он должен оставаться защищенным от подобных проблем.
Тематические карты являются еще одним:
Извлечение знаний в независимый уровень и обеспечение возможности обработки на этом уровне знаний с обратной связью, возвращающейся к источникам, не кажется самым прямым и эффективным способом сделать это. Этот процесс сопоставим с рабочим процессом публикации, где авторы настаивают на использовании Word, но издатели хотят XML. Круговое преобразование между двумя форматами неэффективно, но иногда необходимо. Кроме того, этот уровень косвенности - именно то, что дает нам возможность и свободу обрабатывать знания таким образом, чтобы их можно было сохранять в течение долгого времени, независимо от того, что происходит с исходной информацией, и, более конкретно, с системами, используемыми для обработки. Вся работа, которая была проделана для описания информации, ввода тем, создания отношений, управления многоязычными эквивалентностями, все еще работает. Поскольку управление им осуществлялось независимо, обновление системы просто означает отключение от старой системы и повторное подключение к новой.
Уроки, извлеченные из работы с Тематическими картами на протяжении более двух десятилетий, контрастируют: из-за быстрых темпов технического прогресса мы были поражены успехом информационных технологий. Поиск ближайшего следующего большого события затмил нашу способность думать о фундаментальной природе того, что мы делаем. Понятия доверия, надежности, высокого качества контента по-прежнему имеют ключевое значение для долгосрочного успеха наших предприятий. Мы должны приспособиться к изменяющейся природе способов представления информации, с которой мы имеем дело. Это только начало. Когда мы создали стандарт Тематических карт, мы создали нечто, что оказалось решением без проблем: возможность объединения сетей знаний между организациями. Несмотря на многочисленные ожидания и много усилий в этом направлении, это не оказалось достаточным для удовлетворения требований пользователей. Но мы также разработали концепцию независимости между источниками информации и уровнями управления знаниями. Это может оказаться тем, что остается в долгосрочной перспективе, даже если тот факт, что эта идея когда-то называлась тематическими картами, может оказаться в забвении.
Рекомендации