Онтологический мэппинг, онтологический рефакторинг и пространство концепций
1. Предположим, что мы хотим записать в RDL компоненты методов, определенные ISO 42010 и ISO 24744. Содержание этих стандартов в чем-то пересекается: каждый из них определяет модели, виды моделей, языки. Как именно пересекается содержание этих стандартов, и что из этого следует -- это предмет особого разбирательства. Очень грубо: пусть эти стандарты оба содержательного объема 1 знаниевых единиц, и содержание этих стандартов пересекается на 0.25з.е каждого из них.
2. У нас есть выбор:
а) Рефакторинг: завести новый "гармонизированный стандарт" -- PraxOS01, и в него загрузить "переваренные" оба стандарта, получив тем самым знания в объеме 1.75з.е. (экономия пересекающейся части в 0.25 одного из стандартов), или
б) Мэппинг: отмоделировать оба этих стандарта как связные куски знания, а затем выполнить мэппинг пересекающихся части, получив тем самым знания в объеме 2.25 (0.25 добавляются на описание мэппинга, плюс каждый стандарт представлен полностью, включая дублирующиеся неотрефакторенные части).
Содержательно вся эта модульно-языковая история укладывается в два разных подхода -- синтетический (то есть "интеграционный", т.е. мэппинг разношерстных денормализованных описаний) и проекционный (не мэппинг, а рефакторинг при презентации, а затем денормализация по мере необходимости репрезентации) --вот об этом из свежего ISO 42010(на стр. 36 из 55): There are two common approaches to the construction of views: the synthetic approach and the projective approach. In the synthetic approach, the Architect constructs views of the system-of-interest and integrates these views within an architecture description using model correspondences. In the projective approach, the Architect derives each view through some routine, possibly mechanical, procedure of extraction from an underlying repository".
Сам ISO 42010 употребим с обоими подходами, ISO 15926 также нейтрален к этим подходам -- это всё реализационные особенности, отражающие стиль реализаторов.
Мир по факту развивается в направлении мэппинга. Цивилизационные скачки происходят в ходе рефакторинга.
Это означает, что для "интеграции приложений" (корпоративных информационных систем, как в iRing, или имитационных моделей, как в Симантикс) лучше подходит онтологический мэппинг, а вот для исследовательского проекта PraxOS лучше подходит онтологический рефакторинг.
Обсуждение того, как изменится стратегия образования в данном случае опускаем, только заметим, что если учить нужно сути дела и компактифицировать знание, лучше путь (а), если нужно выполнять формальные требования compliance, то нужно идти по (б).
3. Для того, чтобы каким-то образом вести обсуждения, аналогичные обсуждениям по пункту 2, нам нужно иметь соответствующий набор понятий. Подходящей кандидатурой для "набора шаблонов, в терминах которых выражена подлежащая мэппингу или рефакторингу одна из предметных онтологий" является пресловутый онтолет (http://community.livejournal.com/dot15926/12093.html -- но там все время говорилось об одной предметной области, а тут их явно две "начальных", плюс "итоговвая", плюс "мэппинг").
4. В каком-то смысле пересекаются разные понятия, имеющие отношение к модуляризации:
4.1. онтолет: набора шаблонов для выражения моделей отдельной предметной области (группировка шаблонов по их тематизму"). Можно осторожно предположить, что каждый онтолет соответствует одному языку моделирования (и мы тут немедленно утыкаемся в проблему модульности языков), который соответствует одному виду моделей (и мы утыкаемся в то, что некоторые виды модели явно используют два языка плюс correspondence rules между их примитивами). Это осторожное предположение я пытаюсь обсуждать тут: http://ailev.livejournal.com/872130.html
4.2. namespace -- в том понимании, каком это слово используется для OWL namespaces в Части 8 (группировка шаблонов по их источнику").
4.3. каталог -- набор инстансов, соответствующих каким-то онтолетам и кем-то проверенных (зарегистрированных). Например, каталог компонент методов -- инстансы компонент методов, соответствующие онтолетам этих компонент.
4.4. workbook: взаимосвязанный набор шаблонов для целей редактирования, хранения, передачи (произвольная часть RDL). Есть гипотеза, что запрос возвращает из RDL как раз workbook -- или наоборот, размещает workbook в RDL.
4.5. сервер: часть шаблонов, находящихся на конкретном сервере федерации
4.6. мэппинг: набор отношений, которые показывают связь понятий одного [?модуля] с другим (и могут включать в себя ссылки на исполняемые команды). Я тут даже затрудняюсь сказать, какого сорта тут модуль -- ибо он может быть вообще "не местный", т.е. не из мира ISO 15926/
5. Все вышесказанное относится к наборам ID, но не labels -- поэтому нельзя говорить о "пространстве имён". Скорее уж, это "пространство концептов", conceptspace (в том числе помянутые namespaces из OWL тут тоже -- conceptspace). Речь тут идет о наборе концептов, понимаемом однозначно во всем богатстве их связей какой-то группой предметных специалистов, независимо от родного языка или предпочитаемого сленга. Все они, например, однозначно понимают шаблон-из-части-7, в этом смысле "Часть 7" тут не пространство имен, а пространство концептов.
Если же говорить именно о "пространстве имён", то нужно выделять "сленги" для labels (например, английские и русские, или жаргонизмы разных профессиональных сообществ, принятые для обозначения одних и тех же концептов). Но это я почему-то к модульности не отношу, это что-то другое -- больше про нотацию, или даже вообще "репрезентацию" (в смысле части 2 -- т.е. детали типа кегля шрифта и цвета букв).
6. Все вышесказанное можно реализовывать несколькими способами:
а) честно факториентированно: делать соответствующие отношения и хранить все связи. Модульность становится лишь одним из способов агрегации единиц RDL (RDI -- reference data items), и этих видов модульности может быть сколько угодно, они могут быть развиваемы по ходу дела. Модульность в таком подходе честный first class object. Платить приходится резким замедлением работы, база дико засоряется.
б) нечестно, как сейчас в RDL/WIP: модульность выражать префиксами прямо в текстовой строке label -- но даже не хочется обсуждать, почему это так ужасно.
в) модульность делать зависящей от реализации, т.е. дополнить число предписанных для thing атрибутов-в-смысле-части-2. И операции выводить в интерфейс (иметь их "в коде", а не "в базе").
2. У нас есть выбор:
а) Рефакторинг: завести новый "гармонизированный стандарт" -- PraxOS01, и в него загрузить "переваренные" оба стандарта, получив тем самым знания в объеме 1.75з.е. (экономия пересекающейся части в 0.25 одного из стандартов), или
б) Мэппинг: отмоделировать оба этих стандарта как связные куски знания, а затем выполнить мэппинг пересекающихся части, получив тем самым знания в объеме 2.25 (0.25 добавляются на описание мэппинга, плюс каждый стандарт представлен полностью, включая дублирующиеся неотрефакторенные части).
Содержательно вся эта модульно-языковая история укладывается в два разных подхода -- синтетический (то есть "интеграционный", т.е. мэппинг разношерстных денормализованных описаний) и проекционный (не мэппинг, а рефакторинг при презентации, а затем денормализация по мере необходимости репрезентации) --вот об этом из свежего ISO 42010(на стр. 36 из 55): There are two common approaches to the construction of views: the synthetic approach and the projective approach. In the synthetic approach, the Architect constructs views of the system-of-interest and integrates these views within an architecture description using model correspondences. In the projective approach, the Architect derives each view through some routine, possibly mechanical, procedure of extraction from an underlying repository".
Сам ISO 42010 употребим с обоими подходами, ISO 15926 также нейтрален к этим подходам -- это всё реализационные особенности, отражающие стиль реализаторов.
Мир по факту развивается в направлении мэппинга. Цивилизационные скачки происходят в ходе рефакторинга.
Это означает, что для "интеграции приложений" (корпоративных информационных систем, как в iRing, или имитационных моделей, как в Симантикс) лучше подходит онтологический мэппинг, а вот для исследовательского проекта PraxOS лучше подходит онтологический рефакторинг.
Обсуждение того, как изменится стратегия образования в данном случае опускаем, только заметим, что если учить нужно сути дела и компактифицировать знание, лучше путь (а), если нужно выполнять формальные требования compliance, то нужно идти по (б).
3. Для того, чтобы каким-то образом вести обсуждения, аналогичные обсуждениям по пункту 2, нам нужно иметь соответствующий набор понятий. Подходящей кандидатурой для "набора шаблонов, в терминах которых выражена подлежащая мэппингу или рефакторингу одна из предметных онтологий" является пресловутый онтолет (http://community.livejournal.com/dot15926/12093.html -- но там все время говорилось об одной предметной области, а тут их явно две "начальных", плюс "итоговвая", плюс "мэппинг").
4. В каком-то смысле пересекаются разные понятия, имеющие отношение к модуляризации:
4.1. онтолет: набора шаблонов для выражения моделей отдельной предметной области (группировка шаблонов по их тематизму"). Можно осторожно предположить, что каждый онтолет соответствует одному языку моделирования (и мы тут немедленно утыкаемся в проблему модульности языков), который соответствует одному виду моделей (и мы утыкаемся в то, что некоторые виды модели явно используют два языка плюс correspondence rules между их примитивами). Это осторожное предположение я пытаюсь обсуждать тут: http://ailev.livejournal.com/872130.html
4.2. namespace -- в том понимании, каком это слово используется для OWL namespaces в Части 8 (группировка шаблонов по их источнику").
4.3. каталог -- набор инстансов, соответствующих каким-то онтолетам и кем-то проверенных (зарегистрированных). Например, каталог компонент методов -- инстансы компонент методов, соответствующие онтолетам этих компонент.
4.4. workbook: взаимосвязанный набор шаблонов для целей редактирования, хранения, передачи (произвольная часть RDL). Есть гипотеза, что запрос возвращает из RDL как раз workbook -- или наоборот, размещает workbook в RDL.
4.5. сервер: часть шаблонов, находящихся на конкретном сервере федерации
4.6. мэппинг: набор отношений, которые показывают связь понятий одного [?модуля] с другим (и могут включать в себя ссылки на исполняемые команды). Я тут даже затрудняюсь сказать, какого сорта тут модуль -- ибо он может быть вообще "не местный", т.е. не из мира ISO 15926/
5. Все вышесказанное относится к наборам ID, но не labels -- поэтому нельзя говорить о "пространстве имён". Скорее уж, это "пространство концептов", conceptspace (в том числе помянутые namespaces из OWL тут тоже -- conceptspace). Речь тут идет о наборе концептов, понимаемом однозначно во всем богатстве их связей какой-то группой предметных специалистов, независимо от родного языка или предпочитаемого сленга. Все они, например, однозначно понимают шаблон-из-части-7, в этом смысле "Часть 7" тут не пространство имен, а пространство концептов.
Если же говорить именно о "пространстве имён", то нужно выделять "сленги" для labels (например, английские и русские, или жаргонизмы разных профессиональных сообществ, принятые для обозначения одних и тех же концептов). Но это я почему-то к модульности не отношу, это что-то другое -- больше про нотацию, или даже вообще "репрезентацию" (в смысле части 2 -- т.е. детали типа кегля шрифта и цвета букв).
6. Все вышесказанное можно реализовывать несколькими способами:
а) честно факториентированно: делать соответствующие отношения и хранить все связи. Модульность становится лишь одним из способов агрегации единиц RDL (RDI -- reference data items), и этих видов модульности может быть сколько угодно, они могут быть развиваемы по ходу дела. Модульность в таком подходе честный first class object. Платить приходится резким замедлением работы, база дико засоряется.
б) нечестно, как сейчас в RDL/WIP: модульность выражать префиксами прямо в текстовой строке label -- но даже не хочется обсуждать, почему это так ужасно.
в) модульность делать зависящей от реализации, т.е. дополнить число предписанных для thing атрибутов-в-смысле-части-2. И операции выводить в интерфейс (иметь их "в коде", а не "в базе").