Об каталоги сервисов, методов и акторов
Подход к онтологии сервисов в DOLCHE: https://www.posccaesar.org/svn/pub/SemanticDays/2010/SessionRT_Guarino_OntologicalFoundationsofServicesScience.pdf (версия 2010г., в отличие от разбираемой версии в http://kir-lis.livejournal.com/2359.html версии 2008г., хотя я и не сравнивал подробно, какие появились обновления -- может быть, особых различий и нет).
Подумалось, что:
1. сервисы и методы тесно связаны. Может, более тесно, чем нам сейчас кажется. Если сервис -- событие, то это событие выполнения какого-то метода (с точностью до разбирательства с тем, идет ли речь о типах, или экземплярах и прочими стандартными онтологическими реверансами).
2. каталог сервисов так же осмыслен, как каталог продуктов. Это означает, что в связи с пунктом 1 не менее осмыслен каталог методов.
3. Методы исполняются акторами, акторы (агенты) предоставляют сервисы. Это означает, что так же можно думать о каталоге акторов с их capabilities.
4. Чем отличаются каталог и RDL еще придется уточнить (в RDL хранятся OIM для каталогизируемых продуктов, работ, акторов, сервисов и т.д., а описание конкретных каталогизируемых сущностей согласно этим OIM хранится в каталоге -- но интересно, как это выполняется для иерархии уровней абстракции описания: когда "конкретная сущность" является тоже классом, но подробным и уточненным, находящимся на другом уровне абстракции, а для превращения в экземпляр нужно уточнять-конкретизировать раза три-четыре, и все уровни уточнения осмысленны).
Заодно выяснилось, что для разбирательства с каталогами нужно:
а) разобраться с предметной областью (то есть онтологией) каталогизации, идентификации, кодификации, характеризации, классификации и так далее с заходом в предметную область НСИ.
б) разобраться с предметной областью регистрации метаданных (http://en.wikipedia.org/wiki/ISO/IEC_11179).
в) разобраться с предметной областью master data (отличающихся от product data, но в которых внутри reference data) и электронных словарей в их пересечении с кодификацией -- ISO 8000 и ISO 22745 -- http://www.eccma.org/Presentations.php [интересно, что Matthew West как раз занялся ISO 8000 перед самым своим уходом из Shell, и продолжает этим заниматься прямо сейчас]
Есть смутное ощущение, что "по норме" это все разбирательство должно закончиться какими-то OIM соответствующих стандартов в ISO 15926 -- но не только. Становится понятней, что на входе и на выходе Method Composer: мы будем делать не "репозиторий фрагментов методов" (method fragments/chunks), а "каталог методических комплектующих" (хи-хи, method parts). Можно унаследовать огромное знание, полученное для каталогов комплектующих. Ибо eqhub.org с 1 июля в промышленной эксплуатации, а вот все затеи с каталогами сервисов или методов пока на этот уровень не вышли.
Проблема: у нас до сих пор нет какой-то признанной нотации для записи OIM. Инженеры для этого используют парсируемые Exel datasheet (чей парсинг поддержан, оказывается, не только в iRING, но и во всех ведущих PLM). Мне (почему-то) этот вариант не нравится, но задаю себе вопрос: случайно ли это?! Или это и есть мейнстрим, от которого мы совершенно зря отмахиваемся в пользу "более научных" нотаций?
Очень хотелось бы во время разборки всех этих методов каталогизации, классификации, характеризации и т.д. иметь какой-то инструмент для быстрого мэппинга с типизацией. vvagr предлагает для этого использовать таблички (то есть тот же Exel, или вообще Word), но мне это как-то неуютно.
Не знаю, куда это публиковать -- в dot15926 или praxos. Это застряло посредине, плюс прихватывает тему качества данных, которая пока никуда не пристроена. Так что пусть пока побудет тут, в Лабораторном Журнале.
Подумалось, что:
1. сервисы и методы тесно связаны. Может, более тесно, чем нам сейчас кажется. Если сервис -- событие, то это событие выполнения какого-то метода (с точностью до разбирательства с тем, идет ли речь о типах, или экземплярах и прочими стандартными онтологическими реверансами).
2. каталог сервисов так же осмыслен, как каталог продуктов. Это означает, что в связи с пунктом 1 не менее осмыслен каталог методов.
3. Методы исполняются акторами, акторы (агенты) предоставляют сервисы. Это означает, что так же можно думать о каталоге акторов с их capabilities.
4. Чем отличаются каталог и RDL еще придется уточнить (в RDL хранятся OIM для каталогизируемых продуктов, работ, акторов, сервисов и т.д., а описание конкретных каталогизируемых сущностей согласно этим OIM хранится в каталоге -- но интересно, как это выполняется для иерархии уровней абстракции описания: когда "конкретная сущность" является тоже классом, но подробным и уточненным, находящимся на другом уровне абстракции, а для превращения в экземпляр нужно уточнять-конкретизировать раза три-четыре, и все уровни уточнения осмысленны).
Заодно выяснилось, что для разбирательства с каталогами нужно:
а) разобраться с предметной областью (то есть онтологией) каталогизации, идентификации, кодификации, характеризации, классификации и так далее с заходом в предметную область НСИ.
б) разобраться с предметной областью регистрации метаданных (http://en.wikipedia.org/wiki/ISO/IEC_11179).
в) разобраться с предметной областью master data (отличающихся от product data, но в которых внутри reference data) и электронных словарей в их пересечении с кодификацией -- ISO 8000 и ISO 22745 -- http://www.eccma.org/Presentations.php [интересно, что Matthew West как раз занялся ISO 8000 перед самым своим уходом из Shell, и продолжает этим заниматься прямо сейчас]
Есть смутное ощущение, что "по норме" это все разбирательство должно закончиться какими-то OIM соответствующих стандартов в ISO 15926 -- но не только. Становится понятней, что на входе и на выходе Method Composer: мы будем делать не "репозиторий фрагментов методов" (method fragments/chunks), а "каталог методических комплектующих" (хи-хи, method parts). Можно унаследовать огромное знание, полученное для каталогов комплектующих. Ибо eqhub.org с 1 июля в промышленной эксплуатации, а вот все затеи с каталогами сервисов или методов пока на этот уровень не вышли.
Проблема: у нас до сих пор нет какой-то признанной нотации для записи OIM. Инженеры для этого используют парсируемые Exel datasheet (чей парсинг поддержан, оказывается, не только в iRING, но и во всех ведущих PLM). Мне (почему-то) этот вариант не нравится, но задаю себе вопрос: случайно ли это?! Или это и есть мейнстрим, от которого мы совершенно зря отмахиваемся в пользу "более научных" нотаций?
Очень хотелось бы во время разборки всех этих методов каталогизации, классификации, характеризации и т.д. иметь какой-то инструмент для быстрого мэппинга с типизацией. vvagr предлагает для этого использовать таблички (то есть тот же Exel, или вообще Word), но мне это как-то неуютно.
Не знаю, куда это публиковать -- в dot15926 или praxos. Это застряло посредине, плюс прихватывает тему качества данных, которая пока никуда не пристроена. Так что пусть пока побудет тут, в Лабораторном Журнале.