Онтолёты и их вёрстка
1. Вот для меня есть какой-нибудь ISO 24744, и я начинаю редактировать набор шаблонов, который позволит мне выражать методы так, как это принято в ситуационной инженерии методов. То есть я выражаю знание (метамодель) о предметной области как набор шаблонов. Это и есть «онтолет 24744». Я могу сказать: «методолог, подгрузи онтолет 24744 - и не парься, у тебя все нужные шаблоны для кодирования методов будут».
Или я проектирую набор шаблонов такой, чтобы изобразить им все центробежные насосы (например, взяв штук пять разных бланков datasheets заводов-изготовителей по этим насосам, и пытаясь сделать набор шаблонов, в котором полностью отобразим любой из этих пяти бланков datasheets и надеясь, что кодирование любого типа центробежных насосов уложится в этот набор шаблонов). Я называю это «онтолет центробежных насосов», такая вот микро-предметная область.
Это и есть мои use-cases. Это примерно соответствует термину OIM в стандарте (часть 8), но термин Object Informaion Model deprecated, потому как остался от тяжелых времен объектно-ориентированного прошлого, и Клювер не рекомендовал его употреблять - а использовать любой термин со смыслом «маленькая, ограниченная онтология», я и предложил «ontolet». Ибо термин OIM и объект-ориентированность ушли, а нужда в чем-то подобном осталась.
Поэтому я считаю, что бывший OIM, нынешний ontolet должен стать first class object. Опыт показывает, что при кодировании какого-то ГОСТа имя этого госта ставят прямо в начало строки label для сущности. Например «24744 activity», а не просто "activity". Вот если сделать выборку по всем этим «24744 *» именованным шаблонам, то это и будет «онтолет, явленный в ощущениях». То, что я хочу, это убрать кодирование онтолетов из строк-имён в виде неведомых программе и значимых только для людей префиксов, и сделать его кошерно, т.е. на отношениях. А редактор и сервер должны это отношение как-то понимать, и всяко поддерживать в операциях.
Мне тут все равно, называется это онтОлет, Онтолет или онтолЁт -- если даже распространится последний вариант произношения, это будет весело, но действенно и понятно.
2. Но никакой апплет не используется сам по себе. Чтобы сделать что-то разумное, их нужно несколько. Я думаю, тут тоже нужно идти от программирования. Как называется связка всех нужных подгружаемых компонентов программы (а еще лучше - задействуемых сервисов, и сервисов, задействуемых задействуемыми сервисами)? Понятно же, что какому-нибудь приложению из Линукса нужно много пакетов, но отнюдь не весь дистрибутив. Придумайте сами какой-то термин (насколько я знаю, термина нет, используется всегда сложноподчиненное предложение типа "все нужные пакеты", в нашем варианте -- "все задействованные онтолеты". Гы, "эскадрилья").
Но для меня literary programming в его разных вариантах более главная метафора, чем метафора линкера/таскбилдера (ежели кто еще помнит такие слова). Алан Кей говорит, что «приложения верстаются из отдельных моделек микропредметных областей, как газеты». Мне это тоже нравится - «книжка» или "журнал" (в том числе "бортовой журнал", в котором всё меняется и в котором все записывается -- log), в которой может быть сверстано несколько онтолетов. Примерно соответствует также экселевским book, или workspaces, или project во многих программах. Не хотел бы называть project, ибо у меня это слово зарезервировано под последовательность работ (а не продукт). Остается book или workspace (то есть вид 24744 - work product, или composition of workproducts). Что-то, куда подверстываются онтолеты по мере необходимости. Называть этот объект нужно так, как он выглядит на экране -- какая-то большая страница, или полоса, или книга ("свиток") для верстки.
Книгу пишут/редактируют, рабочее пространство заполняют, кохают и лелеют (это «сборочная площадка» итогового продукта) - а потом оно само вдруг может закончить жизнь новым онтолетом, например (если суть дела была - создать описание новой предметной области на базе какой-нибудь старой предметной области). Ну, или это может быть модель/набор моделей, где набор онтолетов - метамодель, и мы просто моделируем в терминах давно известных предметных областей.
Тут я думаю, что есть еще нечто, называемое «каталог доступных для верстки онтолетов», ибо "библиотека онтолетов" подразумевает их полное собрание, а каталог -- только описание (иногда это обсуждают как разницу между "справочником" и "хранилищем", "directory" и "server", "registry" и "repository").
Я тут не предписываю пока ничего. Это самые общие мысли о том, как могла бы выглядеть онтологическая работа. Как программирование: пишешь библиотеки, а потом на базе их и «внешних библиотек» либо пишешь новые библиотеки, либо пишешь новые приложения. Без модульности каюк. Когда-то паскаль продувал Фортрану, потому как в Фортране через коммон блоки можно было сделать то, что потом в Аде назвали «пакетом», а в «Модуле» модулем - а в Паскале формально можно было писать только монолитные программы, это было даже хуже, чем в Фортране с его коммон блоками, которые позволяли склеиваться огромным кускам кода, которыми можно было управлять как-то независимо. Нам нужно с самого начала это поддержать. Это ключ к успешной работе, это вопрос выживания. Ну, и поддержку нескольких независимых друг от друга недоделанных работ - workspace, или notebook (кажись, в Matematica это так называется), или в Excel это book.
Так что -- пишите тут комментами предложения по названиям, а то и архитектурные предложения. Самое время с идеями: еще через некоторое короткое время это все будет уже отлито в бетоне тьфу, питоне -- и с архитектурными замечаниями и предложениями нужно будет ждать до следующей версии. Хотя с предложениями по именам, понятно, можно будет обращаться в любой момент.
Или я проектирую набор шаблонов такой, чтобы изобразить им все центробежные насосы (например, взяв штук пять разных бланков datasheets заводов-изготовителей по этим насосам, и пытаясь сделать набор шаблонов, в котором полностью отобразим любой из этих пяти бланков datasheets и надеясь, что кодирование любого типа центробежных насосов уложится в этот набор шаблонов). Я называю это «онтолет центробежных насосов», такая вот микро-предметная область.
Это и есть мои use-cases. Это примерно соответствует термину OIM в стандарте (часть 8), но термин Object Informaion Model deprecated, потому как остался от тяжелых времен объектно-ориентированного прошлого, и Клювер не рекомендовал его употреблять - а использовать любой термин со смыслом «маленькая, ограниченная онтология», я и предложил «ontolet». Ибо термин OIM и объект-ориентированность ушли, а нужда в чем-то подобном осталась.
Поэтому я считаю, что бывший OIM, нынешний ontolet должен стать first class object. Опыт показывает, что при кодировании какого-то ГОСТа имя этого госта ставят прямо в начало строки label для сущности. Например «24744 activity», а не просто "activity". Вот если сделать выборку по всем этим «24744 *» именованным шаблонам, то это и будет «онтолет, явленный в ощущениях». То, что я хочу, это убрать кодирование онтолетов из строк-имён в виде неведомых программе и значимых только для людей префиксов, и сделать его кошерно, т.е. на отношениях. А редактор и сервер должны это отношение как-то понимать, и всяко поддерживать в операциях.
Мне тут все равно, называется это онтОлет, Онтолет или онтолЁт -- если даже распространится последний вариант произношения, это будет весело, но действенно и понятно.
2. Но никакой апплет не используется сам по себе. Чтобы сделать что-то разумное, их нужно несколько. Я думаю, тут тоже нужно идти от программирования. Как называется связка всех нужных подгружаемых компонентов программы (а еще лучше - задействуемых сервисов, и сервисов, задействуемых задействуемыми сервисами)? Понятно же, что какому-нибудь приложению из Линукса нужно много пакетов, но отнюдь не весь дистрибутив. Придумайте сами какой-то термин (насколько я знаю, термина нет, используется всегда сложноподчиненное предложение типа "все нужные пакеты", в нашем варианте -- "все задействованные онтолеты". Гы, "эскадрилья").
Но для меня literary programming в его разных вариантах более главная метафора, чем метафора линкера/таскбилдера (ежели кто еще помнит такие слова). Алан Кей говорит, что «приложения верстаются из отдельных моделек микропредметных областей, как газеты». Мне это тоже нравится - «книжка» или "журнал" (в том числе "бортовой журнал", в котором всё меняется и в котором все записывается -- log), в которой может быть сверстано несколько онтолетов. Примерно соответствует также экселевским book, или workspaces, или project во многих программах. Не хотел бы называть project, ибо у меня это слово зарезервировано под последовательность работ (а не продукт). Остается book или workspace (то есть вид 24744 - work product, или composition of workproducts). Что-то, куда подверстываются онтолеты по мере необходимости. Называть этот объект нужно так, как он выглядит на экране -- какая-то большая страница, или полоса, или книга ("свиток") для верстки.
Книгу пишут/редактируют, рабочее пространство заполняют, кохают и лелеют (это «сборочная площадка» итогового продукта) - а потом оно само вдруг может закончить жизнь новым онтолетом, например (если суть дела была - создать описание новой предметной области на базе какой-нибудь старой предметной области). Ну, или это может быть модель/набор моделей, где набор онтолетов - метамодель, и мы просто моделируем в терминах давно известных предметных областей.
Тут я думаю, что есть еще нечто, называемое «каталог доступных для верстки онтолетов», ибо "библиотека онтолетов" подразумевает их полное собрание, а каталог -- только описание (иногда это обсуждают как разницу между "справочником" и "хранилищем", "directory" и "server", "registry" и "repository").
Я тут не предписываю пока ничего. Это самые общие мысли о том, как могла бы выглядеть онтологическая работа. Как программирование: пишешь библиотеки, а потом на базе их и «внешних библиотек» либо пишешь новые библиотеки, либо пишешь новые приложения. Без модульности каюк. Когда-то паскаль продувал Фортрану, потому как в Фортране через коммон блоки можно было сделать то, что потом в Аде назвали «пакетом», а в «Модуле» модулем - а в Паскале формально можно было писать только монолитные программы, это было даже хуже, чем в Фортране с его коммон блоками, которые позволяли склеиваться огромным кускам кода, которыми можно было управлять как-то независимо. Нам нужно с самого начала это поддержать. Это ключ к успешной работе, это вопрос выживания. Ну, и поддержку нескольких независимых друг от друга недоделанных работ - workspace, или notebook (кажись, в Matematica это так называется), или в Excel это book.
Так что -- пишите тут комментами предложения по названиям, а то и архитектурные предложения. Самое время с идеями: еще через некоторое короткое время это все будет уже отлито в бетоне тьфу, питоне -- и с архитектурными замечаниями и предложениями нужно будет ждать до следующей версии. Хотя с предложениями по именам, понятно, можно будет обращаться в любой момент.