October 19th, 2010

2021 год
  • ailev

Онтолёты и их вёрстка

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.

Так что -- пишите тут комментами предложения по названиям, а то и архитектурные предложения. Самое время с идеями: еще через некоторое короткое время это все будет уже отлито в бетоне тьфу, питоне -- и с архитектурными замечаниями и предложениями нужно будет ждать до следующей версии. Хотя с предложениями по именам, понятно, можно будет обращаться в любой момент.
2021 год
  • ailev

.15926L

Набор тезисов, которые я как-то понял по итогам обсуждений с vvagr, algebraic_brain, justy_tylor (начало этого обсуждения, как я помню, заложил avlasov, который подкинул "понимание ISO 15926, как типов" в наших питерских беседах несколько месяцев назад -- но тогда я сам вообще ничего не понял про описываемые ниже механизмы, хотя "дух высказывания" про "модель данных -- это типы в языке программирования" мне был интуитивно вполне понятен и я эти несколько месяцев просто "не знал, но верил". В конце концов, EXPRESS -- это ведь как раз про типы!):

1. Дано: Часть 7 говорит, что ISO 15926 -- это FOL (при этом мы пока игнорируем часть 8, про которую явно сказано, что это уже не суть, а "возможная реализация"). Требуется: определить, как сделать "язык запросов" для RDL -- язык запросов, работающий не в OWL или EXPRESS, а в родных для ISO 15926 понятиях.

2. Из опыта: язык запросов -- это обычный язык программирования, полный по Тьюрингу. Ибо любой язык запросов должен бы дорасти до полного языка программирования. Например, хорошим языком программирования является Питон. Итого: требуется сообразить, как FOL связан с вычисляемым языком программирования.

3. Есть тезис о связи типов (алгебраических -- http://en.wikipedia.org/wiki/Algebraic_data_type) языка программирования, логических высказываний и декартово замкнутых категорий -- http://www.haskell.org/haskellwiki/Curry-Howard-Lambek_correspondence. Важное замечание от algebraic_brain, которому я склонен верить: "алгебраические типы по настоящему можно понять только с использованием теории категорий". Я тут сразу расслабляюсь, и заявляю, что по-настоящему я сам тут ничего не понимаю -- но в предыдущем обсуждении этого вопроса о языке я интуитивно спросил "может ли здесь помочь теория категорий?" (http://community.livejournal.com/dot15926/11924.html). Оказалось, может -- хотя и косвенно: способствуя пониманию алгебраических типов.

4. Теперь нужно четко сказать, что у нас "язык запросов" будет не с регулярными выражениями, а с pattern matching -- http://en.wikipedia.org/wiki/Pattern_matching.

5. Редактор у нас будет профессиональный -- то есть не типа Word для сугубо литературного творчества, в котором консоль на Visual Basic выведена куда-то глубоко под капот, а типа Vim или Emacs, то есть для программирования. В редакторе будет консоль для запросов/фильтров/поисков/команд/скриптов/всего, чего угодно! Программирование на .15926L вполне возможно -- хоть "запросов", хоть чего другого.

6. [еретизм он]Ежели мы договорились, что ISO 15926 -- это система типов языка (что обсуждалось у нас в этом комьюнити уже десяток раз), то и хранилище данных для этих типов может быть не из semantic web. Например, можно смотреть не на triple store, как мы пытались раньше, а на key-value persistence.[еретизм офф]

7. Часть 8 с OWL/SPARQL и другие реализации (XMpLant, например), мы считаем "внешними", и делаем к ним мэппинг. То есть для каждой иной (не нашей) реализации делается адаптер, и мы для нее выглядим белыми и пушистыми реализационно. А сущностно -- так мы не только белые и пушистые, мы вообще ангельские, ибо работаем в терминах шаблонов, родных терминах ISO 15926.

Как всегда, говоря "язык", я говорю не о нотации. Нотация может быть хоть в Питоне, хоть controlled English, хоть фрагментами на Haskell -- это сейчас неважно. Главное, что стало понятно, что такое "язык ISO 15926".