Про моделирование Kinds - продолжение
Насколько я понимаю, помещение основных классов метамодели 24744 в контекст онтологии 15926 должно выглядеть так, как это показано на диаграмме ниже:
Для моделирования специфики использования powertype нам необходимо отразить в модели тот факт, что все элементы класса DocumentKind (сами по себе являющиеся классами в терминологии 15926 или клабжектами в терминологии 24744) являются также подклассами класса Document. Для одного из таких элементов - условного класса Report - такая связь показана синим отношением специализации.
Нам необходимо указать наличие этой связи для всех элементов DocumentKind.
Это можно сделать, описав в модели два ограничения:
1. Все элементы класса DocumentKind являются подклассами класса Document.
2. Все элементы класса DocumentKind являются disjoint классами.
Можно ли это сформулировать в Protege - давайте изучим (кажется, нельзя - см. updates 2).
Update:
Расположение на картинке выше классов в горизонтальных полосах означает, что они являются членами (members) соответствующих классов class_of_*. Тем самым все классы на диаграмме являются клабжектами - классами и объектами одновременно.
Кажется, это является основным свойством модели данных 15926 - каждый класс входит в две иерархии (classification и specialization), то есть является клабжектом. Тем самым модель данных 15926 - гораздо более общая, чем модель 24744, и заведомо позволяет работать как с методом, так и с enactment.
Update 2:
Пример классификации, полностью аналогичный использованию Kind, можно найти в частях 4.7.18, 5.2.23.2 и 5.2.23.3 в ISO 15926-2. Кажется, в OWL-модели 15926-2 нет формальной связи между class_of_approval и approval (то есть связи, доступной для автоматического обнаружения). Обнаружить утверждение типа обозначенного выше 1 -- мне не удалось.
Вообще же механизм class_of_* используется полностью аналогично Kind.
Для моделирования специфики использования powertype нам необходимо отразить в модели тот факт, что все элементы класса DocumentKind (сами по себе являющиеся классами в терминологии 15926 или клабжектами в терминологии 24744) являются также подклассами класса Document. Для одного из таких элементов - условного класса Report - такая связь показана синим отношением специализации.
Нам необходимо указать наличие этой связи для всех элементов DocumentKind.
Это можно сделать, описав в модели два ограничения:
1. Все элементы класса DocumentKind являются подклассами класса Document.
2. Все элементы класса DocumentKind являются disjoint классами.
Можно ли это сформулировать в Protege - давайте изучим (кажется, нельзя - см. updates 2).
Update:
Расположение на картинке выше классов в горизонтальных полосах означает, что они являются членами (members) соответствующих классов class_of_*. Тем самым все классы на диаграмме являются клабжектами - классами и объектами одновременно.
Кажется, это является основным свойством модели данных 15926 - каждый класс входит в две иерархии (classification и specialization), то есть является клабжектом. Тем самым модель данных 15926 - гораздо более общая, чем модель 24744, и заведомо позволяет работать как с методом, так и с enactment.
Update 2:
Пример классификации, полностью аналогичный использованию Kind, можно найти в частях 4.7.18, 5.2.23.2 и 5.2.23.3 в ISO 15926-2. Кажется, в OWL-модели 15926-2 нет формальной связи между class_of_approval и approval (то есть связи, доступной для автоматического обнаружения). Обнаружить утверждение типа обозначенного выше 1 -- мне не удалось.
Вообще же механизм class_of_* используется полностью аналогично Kind.